Asychronisation OM

3/5/2020
Integrations and Data Management

Generated on: 2020-03-05
SAP Commerce | 1905
PUBLIC
Original content: https://help.sap.com/viewer/50c996852b32456c96d3161a95544cdb/1905/en-US
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation.
The information included in custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be
missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/viewer/disclaimer.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 1/94
3/5/2020
SAP Back-End Integration: SAP S/4HANA,

SAP ERP, or SAP CRM
Integrate SAP applications with SAP Commerce to leverage powerful back end functionality with the SAP Commerce front end.
Extend your sales channels by reusing master data from the SAP back end, and take full advantage of your standard order ful llment
processes. By repurposing and safeguarding investments made in your SAP back end, you can reduce the implementation costs for
your commerce solution and accelerate time-to-value.
You can integrate one of the following SAP back ends with SAP Commerce:
SAP S/4HANA
SAP ERP
SAP CRM
 Note
For the most part, different back-end integrations cannot co-exist simultaneously. For example, you cannot integrate SAP
Commerce with both an SAP ERP back end and an SAP S/4HANA back end. The only exception to the rule is when using Order
Management Services with asynchronous order management. In this case, you can have a mix of SAP ERP and SAP S/4HANA
back ends.
If integrating with SAP CRM, you cannot integrate any other back end directly with SAP Commerce. There are cases, however,
when you need more than one back end to be part of your system landscape. For example, if integrating with SAP CRM, you can
connect SAP ERP to SAP CRM to access data speci c to SAP ERP, such as invoices and credit checks. But you cannot integrate
both SAP CRM and SAP ERP directly with SAP Commerce.
The SAP S/4HANA and SAP ERP integration scenarios are delivered with SAP Commerce.
SAP Commerce integration with SAP CRM, on the other hand, is delivered as an additional package. The package is available for
download from SAP Service Marketplace (Select SAP Commerce CRM INTEGRATION 1808 > Comprised Software Component
Versions > SAP Commerce CRM INTEG 1808).
About the SAP Back-End Integration

SAP back-end integration is characterized by the following:
SAP Commerce Product Information Management (PIM) is used as the strategic product catalog solution. The SAP back end
remains the system of record for core product master data including pricing and inventory data. SAP Commerce PIM enables
the aggregation, enhancement, and syndication of product data and content necessary to support the omni-channel
customer experience.
SAP Commerce acts as the omni-channel order capture and orchestration engine. The SAP back end remains the system of
record for order ful llment (shipping, billing).
A node in Backoffice Administration Cockpit called SAP Integration allows you to con gure the integration and adapt it to your
needs.
Focus industries of the SAP back-end integration are B2B industries, such as the mechanical engineering industry, as well as
B2C industries.
Scenarios
SAP back-end integration supports the following:
Feature Description Available With More Information
3/5/2020
SAP master data Replicate back-end master data, SAP Master Data
such as customers (B2B),
consumers (B2C), products,
SAP S/4HANA
pricing data, installed base,
business agreements, and SAP ERP
product bundles.
SAP CRM
Asynchronous order Developed for B2B and B2C

SAP S/4HANA
management (loosely-coupled scenarios. Communications run
integration) in the background, and customer SAP ERP
interaction happens only through
and within SAP Commerce. SAP SAP CRM
Commerce stays independent of
the SAP back end, in terms of
data persistence and business
processes.
Synchronous order management Developed for B2B scenarios. Synchronous Order Management
SAP S/4HANA
(tightly-coupled integration) Communication is mainly Module
synchronous, and customer SAP ERP
interaction happens mostly
through SAP Commerce. Data SAP CRM
persistence and business
processes reside in the SAP back
end.
 Note
You can run both order
management scenarios at
once. This allows you to run
one store with synchronous
order management, and
another in parallel with
asynchronous order
management.
Synchronous pricing Use synchronous pricing to SAP Synchronous Pricing Module

SAP S/4HANA
enable your online store to read
pricing information directly from SAP ERP
the SAP back end.
SAP CRM
SAP invoices Allow B2B customers in the SAP Invoice Module

SAP ERP
online store to view invoice
details originating from the SAP SAP CRM
back end. For downloading the
invoice PDF in SAP CRM, you
must have SAP ERP in the
system landscape.
Service request management Replicate service requests Service Request Management

SAP CRM
between SAP CRM and SAP
Commerce.
Complaint Management Replicate complaints between Complaints Management

SAP CRM
SAP CRM and SAP Commerce.
3/5/2020
Service contract management Allow service contract details to Service Contract Management
SAP CRM
be retrieved from SAP CRM and
displayed in the online store. You
can renew the service contract.
Also, you can renew and
terminate service contracts at
item level.
Service order management Replicate service orders created Service Order Management
SAP CRM
in SAP CRM to be displayed on
SAP Commerce. The service
order can be created as a follow-
up from service quotation,
service contract, service request,
or standalone.
Single sign-on to assisted service Streamline the service process to Single Sign-On to Assisted
SAP CRM
module resolve customer issues. Service Module
Product registration Enables customers to register Product Registration

SAP CRM
the products of their interest or
the products that they have
purchased, on the B2C
storefront.
Return orders Enables integration of return SAP Return Order Features

SAP CRM
orders between SAP Commerce
and SAP CRM. Returns can be
initiated for B2C and B2B
asynchronous orders, and the
returns process ow involves
continuous interaction between
SAP Commerce and the back-
end system at various steps
during the process.
Technical Implementation
For asynchronous replication of master data and orders, application link enabling (ALE) and intermediate documents (IDocs)
are used. Master data is inbound, going from the SAP back end to SAP Commerce. Orders are outbound data, owing in the
other direction. Replication happens through an HTTP connection to Data Hub. In Data Hub, the inbound and outbound data is
mapped.
For synchronous calls to the SAP back end, remote function calls (RFC) and the Java connector (JCo) are used.
About the SAP Back-End Integration Documentation

SAP S/4HANA and SAP ERP back-end integration share most functionality, with SAP ERP offering a few additional features such as
SAP credit checks and SAP invoice display. SAP CRM back-end integration offers many of the same features as SAP S/4HANA and
SAP ERP, but diverges in places. For example, only SAP CRM integration offers installed base replication and self service features, but
Order Management Services is only available when integrating with SAP S/4HANA or SAP ERP. Furthermore, certain procedures,
such as master data replication from the back end, can vary between SAP CRM, and SAP S/4HANA and SAP ERP.
Integration Using SAP Cloud Platform Integration Module

You can also integrate SAP Commerce with SAP CRM, SAP ERP, and SAP S/4HANA using SAP Cloud Platform Integration. For more
information, see SAP Cloud Platform Integration Module.
3/5/2020
Related Information
System Requirements for SAP Integrations
Asynchronous Order Management Module

The SAP Asynchronous Order Management module provides integration between SAP Commerce and the SAP back end (SAP
S/4HANA, SAP ERP, or SAP CRM) for order management. Sales orders are captured and saved in SAP Commerce and replicated to
the back end. Sales order ful llment (delivery and billing) is done in SAP ERP, and the status of orders, deliveries, and goods issues is
exchanged between the systems.
You can run a store with asynchronous order management, and another in parallel with synchronous order management. Both
asynchronous and synchronous scenarios can coexist in the same deployment.
Features Architecture Implementation
About Integrating Order Management Services Asynchronous OM Asynchronous OM

Architecture Implementation
Functionality in Asynchronous Order Management
Understanding Data Flows in Asynchronous Order

Management
Using Cart & Checkout with AOM
Using Order Management for SAP Commerce with AOM
SAP Return Order Features
Asynchronous OM Features
In asynchronous order management, order capturing is done completely in SAP Commerce, including price calculation and storing of
orders. Orders submitted in the online store are transferred through Data Hub to the SAP back end (SAP S/4HANA, SAP ERP, or SAP
CRM). Sales order ful llment (shipping, billing) is done in SAP S/4HANA or SAP ERP.
About Integrating Order Management Services

The steps for different Order Management integration implementations vary.
Functionality in Asynchronous Order Management
In asynchronous order management, order capturing is done completely in SAP Commerce, including price calculation and
storing of orders. Orders submitted in the online store are transferred through Data Hub to the SAP back end ( SAP S/4HANA,
SAP ERP , or SAP CRM). Sales order ful llment (shipping, billing) is done in SAP S/4HANA or SAP ERP.
Understanding Data Flows in Asynchronous Order Management
In asynchronous order management, sales order data goes from SAP Commerce to the SAP back end ( SAP S/4HANA, SAP
ERP , or SAP CRM). SAP S/4HANA or SAP ERP then sends sales order con rmations and noti cations to SAP Commerce.
3/5/2020
When you use Cart & Checkout with asynchronous order management (AOM), SAP Commerce stays independent of the SAP
back end ( SAP S/4HANA, SAP ERP , or SAP CRM). Customer interaction happens exclusively through and within SAP
Commerce. Orders are created and stored in SAP Commerce before being replicated to the SAP back end for order ful llment.
Using Order Management for SAP Commerce with AOM
With SAP S/4HANA and SAP ERP back-end integration, you can use Order Management Services with asynchronous order
management (AOM). This allows you to leverage powerful sourcing capabilities from Order Management Services in
combination with order ful llment features from SAP S/4HANA and SAP ERP.
About Integrating Order Management

Services
The steps for different Order Management integration implementations vary.
You can use asynchronous order management with either the standard functionality offered by Cart & Checkout, or with Order
Management Services. The features and con guration steps for either scenario are mostly the same, with only a couple of exceptions.
For more information, see Con gure Order Management for SAP Commerce with One or More SAP Back Ends and SAP S/4HANA or
SAP ERP Extensions for Asynchronous Order Management.
For more information about integrating Order Management Services with an SAP back end, see Using Order Management for SAP
Commerce with AOM.
 Note
This functionality is only available when integrating with SAP S/4HANA or SAP ERP.
Functionality in Asynchronous Order

Management
In asynchronous order management, order capturing is done completely in SAP Commerce, including price calculation and storing of
orders. Orders submitted in the online store are transferred through Data Hub to the SAP back end (SAP S/4HANA, SAP ERP, or SAP
CRM). Sales order ful llment (shipping, billing) is done in SAP S/4HANA or SAP ERP.
With asynchronous order management, prices can also be calculated in SAP S/4HANA or SAP ERP.
All information is exchanged with the SAP back end using IDoc XML. When a sales order is submitted in SAP Commerce, it is
replicated automatically through Data Hub to the back end where a corresponding sales order is created.
Feature Description
Early logon Customers must log on before they can add a product to the
shopping cart. If you use out-of-the-box functionality
(secureportaladdon extension), customers must log on before
they can enter the online store.
Adding products to the cart With SAP S/4HANA or SAP ERP integration, customers can add
standard products, con gurable products, or product variants to the
cart. They must con gure con gurable products before adding them
to the cart. The con guration is taken over to the cart and is saved
with the sales order. For more information about product
con guration, see SAP Product Con guration (On-Premise Edition)
Features.
With SAP CRM integration, customers can add standard products to

the cart.
3/5/2020
Feature Description
Ordering in the B2C online store without replication of registered SAP Customers, either registered as users in SAP Commerce or acting
Commerce customer or guest user (CpD customer scenario) through the guest user, create orders in SAP Commerce. In this case,
the customers themselves are not persisted in the SAP back end.
Instead, a CpD customer (one-time customer) is used in the sales
order IDoc along with document addresses. As a prerequisite for this
scenario, deactivate the Replicate Registered User setting in
Backoffice Administration Cockpit.
Create and con gure a one-time customer in the back end. For more
information, see Setting Up One-Time Customer Accounts.
Ordering in B2C online store with replication of registered user Customers, registered as SAP Commerce users, create orders in SAP
(named SAP Commerce consumer scenario) Commerce. In this case, the customers are replicated upon
registration from SAP Commerce to the SAP back end. In the sales
order IDoc, the named SAP Commerce customer is used (as sold-to
partner) along with document addresses. As a prerequisite for this
scenario, activate the Replicate Registered User setting in Backoffice.
To replicate sales orders placed by guest users (users not registered

in SAP Commerce), set up a one-time customer in the back end. For
more information, see Setting Up One-Time Customer Accounts.
Ordering as a registered B2B user or company B2B customers create orders in SAP Commerce as registered SAP
Commerce users. In the sales order IDoc, the SAP Commerce B2B
unit (as company, sold-to) and the named customer (as contact
person) are used.
In this scenario, replicate your customer master data from the SAP
back end to SAP Commerce. For more information, see B2B Scenario:
Customer and Contact Person Replication.
Pricing from SAP Commerce Prices in SAP Commerce (for example, as shown in the catalog or in
the sales order) are calculated in SAP Commerce. The exact price
 Note components of a sales order item in SAP Commerce are transferred
with the sales order between SAP Commerce and the SAP back end.
Available only when integrating with SAP S/4HANA or SAP ERP.
As a preliminary step, you may want to replicate SAP prices
asynchronously from the back end through Data Hub to SAP
Commerce.
As a prerequisite, deactivate the settings for synchronous pricing in

Backoffice and make the settings for pricing in asynchronous order
management in Backoffice instead. For more information, see Making
Settings in Backoffice for Asynchronous Order Management.
Synchronous pricing Prices in SAP Commerce (for example, as shown in the catalog or in
the sales order) are determined synchronously from the SAP back
end. You can use synchronous pricing in cart and checkout only, or
also extend it to the catalog (list and product details page).
As a prerequisite, activate the settings for synchronous pricing in

Backoffice. For more information, see Backoffice Settings for
Synchronous Pricing.
Live availability to sell (ATS) checks Live ATS checks are available for asynchronous order management
scenarios. For more information, see Features for Product Data
Replication.
Paying by payment service provider (B2C) When you use a payment service provider, payment by credit card is
supported. A subscription ID identi es the credit card in
communications with the payment service provider. The subscription
ID is transferred between SAP Commerce and the SAP back end. For
more information, see Enabling Payment Methods.
3/5/2020
Feature Description
Paying by invoice (B2B) The payment method supported in B2B is payment by invoice, called
account payment in SAP Commerce.
Order Management Services You can use Order Management Services with asynchronous order
management to ful ll orders at consignment level. For more
 Note information, see Using Order Management for SAP Commerce with
AOM.
Available only when integrating with SAP S/4HANA or SAP ERP.
Return orders A return request can be initiated either by a customer from SAP
Commerce storefront or by a customer support agent from
Backoffice Customer Support Cockpit. All return orders initiated in
SAP Commerce are integrated with the SAP back end (SAP CRM /
SAP ERP). You can use Order Management Services with multiple
SAP back ends (SAP S/4HANA and SAP ERP).
Return order cancellation Customer support agent can cancel the return order in SAP
Commerce Backoffice on request by the customer. For more
information, see Cancellation of Return Order.
Delivery modes Delivery modes in SAP Commerce are mapped to shipping methods
in the SAP back end.
Credit checks Credit checks are performed in SAP ERP for B2B orders placed in the
online store. When a customer places an order, a remote function call
 Note
(RFC) is made to SAP ERP to see if they have exceeded their credit
Available only when integrating with SAP ERP or SAP CRM. limit. An exceeded credit limit does not cancel the order. However, the
order status is set to Budget Exceeded Permission and customers
can view this status when they check the details of their order history.
Credit check settings in the back end automatically override any
credit check settings in SAP Commerce.
To use this feature, con gure the back end to perform credit checks,
and deploy the sapcreditcheck extension. For more information, see
SAP Credit Checks for B2B Scenarios, and the documentation under
Monitoring Credit During Sales and Distribution Processing in SAP
Library for SAP Business Suite on SAP Help Portal.
Status updates in the SAP back end replicated to SAP Commerce Information on order con rmation, creation of delivery, and posting of
goods issue are sent back from the SAP back end, through Data Hub,
to SAP Commerce. The order status in SAP Commerce then re ects
the status in the back end. For more information, see Output Control
for Sales Order Con rmations and SAP S/4HANA or SAP ERP:
Maintaining Output Control for Outbound Deliveries and Goods
Issues.
Order cancellation in SAP Commerce You can cancel entire orders in the Customer Service Cockpit of SAP
Commerce.
After canceling, the sales order has the status Canceling. When the
sales order is transferred and con rmed by the back end, the order
status changes to Canceled. You can check the order status in the
online store under Account Order History in the online store. You
can also see the changed status in Backoffice. In the back end, you
can check the status by calling up Display sales order (transaction
VA03 in SAP S/4HANA or SAP ERP, or CRMD_ORDER in SAP CRM).
3/5/2020
Feature Description
Order cancellation in SAP S/4HANA or SAP ERP You can cancel entire orders in SAP S/4HANA or SAP ERP.
You can reject the sales order by calling up transaction VA02 (Change
sales orders), entering an order number, choosing Reject Document
and entering a rejection reason. After the order cancellation has been
replicated back to SAP Commerce, the status of the sales order in
SAP Commerce changes to Canceled. You can check the order status
in the online store under Account Order History . You can also see
the changed status in Backoffice and in the Customer Service
Cockpit.
Replicating Promotion Discounts from SAP Commerce Leverage the bene ts of Promotion Engine by replicating promotion
discounts created in SAP Commerce to the SAP back end (SAP
S/4HANA, SAP ERP).
In an asynchronous order management scenario, you can create a

marketing promotion in SAP Commerce that provides detailed
information to shoppers in the product details, cart, and checkout
pages. These discounts can then be replicated to the SAP back end.
Order cancellation in SAP CRM Web UI You can also cancel the orders in the SAP CRM Web UI:
1. Log in to the Web UI with SALESPRO business role.
2. In the WorkCentre, choose Sales Cycle Sales Orders .
3. In the Sales Order search view, search for the sales order, for
example with the sales order ID.
4. Open the order.
5. Edit the order to ll the Rejection Reason eld, for example

"01 Delivery date too late“.
The order header status is displayed as "Fully Rejected" in the

Rejection Status eld.
6. Save the order.
The order is canceled in SAP CRM. After the order

cancellation is replicated to SAP Commerce, you can see the
canceled status of the sales order in SAP Commerce along
with the rejection reason.
Integrating return orders between SAP Commerce and SAP back-end Return orders created in Backoffice Customer Support Cockpit by
Customer Service agents, are integrated with the SAP back end.
Returns can be initiated for B2B and B2C asynchronous orders, and
the returns process ow involves continuous interaction between SAP
Commerce and the back-end system at various steps during the
process. For more information, see SAP Return Order Features.
Functions Not Supported with Asynchronous Order Management
System Non-Supported Functions
3/5/2020
System Non-Supported Functions
SAP Commerce
Modifying orders
Order changes in SAP Commerce are not replicated to the

SAP back end.
Canceling orders on item level
Only entire sales orders can be canceled.
Credit card payment in B2B
SAP S/4HANA or SAP ERP

Product hierarchies
Modifying orders
Order changes made in the SAP back end are not replicated to
SAP Commerce.
Product bundles
Manual product substitution
Sales order split
Partial delivery
Only complete order delivery is supported, unless integrating

with Order Management Services.
Sales order schedule lines
SAP CRM
Product hierarchies
Product variants
Con gurable products
Modifying orders
Order changes made in the SAP back end are not replicated to
SAP Commerce.
Product bundles
Manual product substitution
Sales order split
Partial delivery
Only complete order delivery is supported.
Sales order schedule lines
3/5/2020
Understanding Data Flows in Asynchronous

Order Management
In asynchronous order management, sales order data goes from SAP Commerce to the SAP back end (SAP S/4HANA, SAP ERP, or
SAP CRM). SAP S/4HANA or SAP ERP then sends sales order con rmations and noti cations to SAP Commerce.
For more information, see SAP S/4HANA or SAP ERP: Data Integration Flow of Sales Orders or SAP CRM: Data Integration Flow of
Sales Orders.
SAP S/4HANA or SAP ERP: Data Integration

Flow of Sales Orders
Sales orders go from SAP Commerce to SAP S/4HANA or SAP ERP. Sales order con rmations, delivery noti cations, and goods issue
noti cations originate from the SAP back end, go through Data Hub, and then to SAP Commerce.
Replicating Sales Orders from SAP Commerce to the SAP Back End
1. A customer submits a sales order after checkout in the online store. The saporderexchange extension (or
saporderexchangeb2b for B2B) extracts the sales order data and calls the Data Hub Adapter to transfer the data to Data
Hub.
2. Data Hub transforms the sales order data into the at structure RawHybrisOrder.
3. The saporder-raw extension contains the metadata to transform the RawHybrisOrder into the canonical item
CanonicalOrder. This canonical item is used by a composition step of Data Hub.
4. In the next publication step, Data Hub transforms the canonical item into a TargetOrder item. The
sapidocoutboundadapter extension transforms the data into an IDoc and sends it to the IDoc/ALE interface of SAP
S/4HANA or SAP ERP using the Spring-Integration Outbound Channel.
Replicating Sales Order Con rmations, Delivery Noti cations, and Goods Issue
Noti cations from the SAP Back End to SAP Commerce
1. Once orders are replicated from SAP Commerce, the SAP back end sends sales order con rmations through Data Hub and on
to SAP Commerce. When deliveries or goods issues are created, the SAP back end sends delivery noti cations or goods issue
noti cations through Data Hub and on to SAP Commerce.
2. The outbound IDocs for sales order con rmations, delivery noti cations, and goods issue noti cations are sent to the
HttpInboundService of the sapidocintegration extension.
3. The sapidocintegration extension receives the outbound IDocs from the SAP back end through the
HttpInboundService that listens to the URL, for example http://<datahub-server>:8080/datahub-
webapp/v1/idoc/receiver. This service creates a Spring-Integration message for the outbound IDocs and sends them
to the Spring-Integration channel IdocXMLInboundChannel.
4. The Spring Integration Flow provides the IdocXMLInboundChannel and routes the incoming messages to the
corresponding mapping services depending on the header eld IDOCTYPE. The mapping services that map IDocs to Raw
Fragment Data are implemented in other Data Hub extensions. The services get XML as input and return Raw Fragment Data.
5. Data Hub extensions also provide the raw and canonical models, as well as the grouping and composition handlers. The
messages returned from the services are routed to the Raw Fragment Data Input Channel of Data Hub. This input channel is
used for fragmented raw data provided by Data Hub.
6. Composition within Data Hub transforms raw items into canonical items.
7. Publication within Data Hub transforms canonical items into ImpEX data that is imported by SAP Commerce.
3/5/2020
SAP CRM: Data Integration Flow of Sales

Orders
Sales orders go from SAP Commerce to SAP CRM. Sales order con rmations, delivery noti cations, and goods issue noti cations
originate from SAP S/4HANA or SAP ERP, go through SAP CRM, Data Hub, and then to SAP Commerce.
 Note
SAP CRM should be integrated with SAP S/4HANA or SAP ERP to receive the sales order con rmations, delivery noti cations, and
goods issue noti cation.
Replicating Sales Orders from SAP Commerce to SAP CRM
1. When a customer submits a sales order after checkout in the online store, the sapcrmorderexchange SAP Commerce
Core extension extracts the sales order data and calls the Data Hub Adapter to transfer sales order data to Data Hub.
2. In Data Hub, the sales order data is transformed into the at structure RawCrmHybrisOrder.
3. The sapcrmorder extension contains the metadata to transform the RawCrmHybrisOrder into the canonical item
CanonicalCrmOrder. This canonical item is used by a composition step of Data Hub.
 Note
The sapcrmorder extension has three modules: sapcrmorder-raw, sapcrmorder-canonical, and
sapcrmorder-target.
4. In the next publication step, the canonical item is transformed into a target item. The sapidocoutboundadapter
extension transforms the data into an IDoc and sends it to the IDoc/ALE interface of SAP CRM using the Spring-Integration
Outbound Channel.
Replicating Sales Order Con rmations, Delivery Noti cations, and Goods Issue
Noti cations from SAP CRM to SAP Commerce
3/5/2020
1. Once orders are replicated from SAP Commerce, through Data Hub, to SAP CRM (as explained in the previous process), sales
order con rmations are sent back from SAP CRM, through Data Hub, to SAP Commerce. As soon as deliveries or goods issues
are created in SAP CRM, delivery noti cations or goods issue noti cations are sent from SAP CRM, through Data Hub, to SAP
Commerce.
2. The outbound IDocs for sales order con rmations, delivery noti cations, and goods issue noti cations are sent to the
HttpInboundService of the sapidocintegration extension.
3. The sapidocintegration extension receives the outbound IDocs from SAP CRM through the HttpInboundService
that listens to the URL, for example http://<datahub-server>:8080/datahub-webapp/v1/idoc/receiver .
This service creates a Spring-Integration message for the outbound IDocs and sends them to the Spring-Integration channel
IdocXMLInboundChannel.
4. The Spring Integration Flow provides the IdocXMLInboundChannel and routes the incoming messages to the
corresponding mapping services depending on the header eld IDOCTYPE. The mapping services that map IDocs to Raw
Fragment Data are implemented in other Data Hub extensions, such as sapcrmorder, sapcrmpricing,
sapcrmproduct, and sapcrmcustomer. The services get XML as input and return Raw Fragment Data.
5. The Data Hub extensions also provide the raw and canonical models, as well as the grouping and composition handlers. The
messages returned from the services are routed to the Raw Fragment Data Input Channel of Data Hub. That is the input
channel for fragmented raw data, provided by Data Hub.
6. Composition within Data Hub transforms raw items into canonical items.
7. Publication within Data Hub transforms canonical items into ImpEX data that is imported by SAP Commerce.

When you use Cart & Checkout with asynchronous order management (AOM), SAP Commerce stays independent of the SAP back
end (SAP S/4HANA, SAP ERP, or SAP CRM). Customer interaction happens exclusively through and within SAP Commerce. Orders
are created and stored in SAP Commerce before being replicated to the SAP back end for order ful llment.
 Note
When integrating SAP CRM with SAP Commerce, orders are replicated to SAP CRM, and then to SAP S/4HANA or SAP ERP for
order ful llment.
3/5/2020
In AOM, response times are fast, and the availability of your commerce solution is independent of the availability of the SAP back end.
Downtimes in the back end do not impact the shopping experience of your customers. This option is preferred in B2C scenarios
where high numbers of users are simultaneously logged on to an online store, as is typically the case in the retail industry. However,
lean B2B scenarios are supported as well.
Asynchronous process flow with SAP S/4HANA or SAP ERP
3/5/2020
Asynchronous process flow with SAP CRM
Example
The following process is an example of AOM in a B2C scenario (late logon, no synchronous pricing):
1. You replicate master data from the SAP back end to SAP Commerce. The data is then available in SAP Commerce.
Since this example scenario is a B2C scenario, you do not need to replicate customers and contact persons from the back end
to SAP Commerce.
2. To nd products, customers browse the product catalog or use the product search.
3. Customers add products to the cart. For cart and checkout, SAP Commerce functionality is used throughout, for example with
checking of stock levels or calculation of the nal price.
 Note
In the context of this scenario, you could use the pricing from SAP Commerce or synchronous pricing from the SAP back
end. Pricing from SAP Commerce operates on prices and discounts replicated from the SAP back end, whereas
synchronous pricing retrieves pricing directly from the back end. Synchronous pricing is typically used for scenarios
requiring complex pricing. Given that the current example is for a B2C scenario with lean pricing, pricing from SAP
Commerce is used.
4. Customers log on to the online store or register as new users. The customer data is created in SAP Commerce and is
replicated to the SAP back end.
3/5/2020
 Note
In a B2C scenario, customers can be guest users or registered users. They do not need to be available initially in the SAP
back end, and their data does not need to be replicated to SAP Commerce.
5. Customers go to the checkout and place their order. The system displays the order con rmation. The order is created in SAP
Commerce and replicated back to the SAP back end for further processing.
If the B2C customer uses credit card for payment and saves the payment info during checkout, a business agreement is
created automatically in SAP Commerce (if the business agreement extensions are active), and is replicated to the back end.
This is applicable only for integration with the SAP CRM back end. For more information, see SAP CRM: Business Agreement
6. Order ful llment (delivery, billing) takes place in SAP S/4HANA or SAP ERP. Status updates, for example those that result
from delivery noti cation or goods issue, are replicated back from the back end to SAP Commerce. The status of the order in
SAP Commerce is then updated.
 Note
When integrating SAP CRM with SAP Commerce, status updates are replicated back from SAP S/4HANA or SAP ERP to
SAP Commerce through SAP CRM.
Using Order Management for SAP Commerce

with AOM
With SAP S/4HANA and SAP ERP back-end integration, you can use Order Management Services with asynchronous order
management (AOM). This allows you to leverage powerful sourcing capabilities from Order Management Services in combination with
order ful llment features from SAP S/4HANA and SAP ERP.
Order Management Services can, for example, determine warehouses based on geolocation, choosing the warehouse closest to the
delivery address to source the order items. The order management integration is available for both B2B and B2C online stores using
AOM. You can run different scenarios in parallel, such as a B2B store with just Order Management Services, and a B2C store using
both AOM and Order Management Services.
Available Options
The following options are available for using Order Management Services with AOM:
Integration with a single SAP back end
The following diagram shows the order and shipping work ow between SAP Commerce and a single SAP back end:
3/5/2020
 Note
A consignment in SAP Commerce is roughly equivalent to a delivery in the SAP back end.
Integration with a single SAP ERP back end with sourcing from third-party vendors
When using a single SAP back end, you can source order items from third-party vendors for delivery to the store warehouse.
This feature is only available when integrating with SAP ERP. For more information, see Third-Party Vendor Sourcing with AOM.
Integration with multiple SAP back ends
You can use Order Management Services with more than one SAP back end, and this can include a mix of SAP S/4HANA and
SAP ERP systems. You can connect to multiple SAP systems, multiple clients within an SAP system, multiple sales areas
within an SAP client, or any combination thereof. For more information about multiple back-end implementations, see Multiple
Back Ends.
About Con guration

Whether you use one or multiple back ends is a decision made at the base store level. You could, therefore, simultaneously deploy one
store with a single back end, and another with multiple back ends. For more information, see Con gure Order Management for SAP
Commerce with One or More SAP Back Ends.
Integration Considerations
Whether you use Order Management Services with one or several SAP back ends, the following applies:
Numbering for sub-orders in the SAP back end
When using AOM without Order Management Services, the order number from SAP Commerce is replicated and used in the
back end. Order number 123, for example, is used in both SAP Commerce and the back end. When using AOM with Order
Management Services, on the other hand, the order number from SAP Commerce increments in the back end. Order number
123 in SAP Commerce becomes 124 in the back end. If using more than one back end, you have order number 125 in the
second back end, 126 in the third, and so on.
Order cancellation
When using Order Management Services, you can cancel orders only in SAP Commerce and not in the back end. Also, you
cannot cancel items within an order; you must cancel the entire order.
Product con guration
You cannot have product con guration in online stores that use Order Management Services with AOM.
Related Information
Con gure Order Management for SAP Commerce with One or More SAP Back Ends
SAP S/4HANA or SAP ERP Extensions for Asynchronous Order Management
Sourcing Service
Multiple Back Ends

You can use Order Management Services with multiple SAP back ends (SAP S/4HANA and SAP ERP). These back ends could include
a mix of SAP S/4HANA and SAP ERP systems, clients within a single SAP system, or sales areas within an SAP client. This scenario is
available only for online stores using asynchronous order management (AOM).
Candidates for this scenario are businesses using multiple SAP back ends to manage different product lines from a single online
store. Once customers submit their orders, Order Management Services does the following:
Creates one or more consignments for each order line item
3/5/2020
Assigns sourcing locations to each consignment
Assigns an SAP back end to each sourcing location
Triggers the distribution of sub-orders to the back ends
The following diagram illustrates the work ow, using SAP ERP back ends as an example:
An order becomes one or more consignments in SAP Commerce, and then one or more sub-orders distributed to the SAP back ends.
Customers will not know that their order has been split. When checking their order history in the My Account section of the online
store, they see only the single order that they placed.
Integration Considerations
When you use Order Management Services with several SAP back ends, the following applies:
Synchronous calls to the back end are not supported
Synchronous pricing and ATS checks are only supported when using Order Management Services with a single SAP back end.
SAP credit checks are only supported with a single SAP ERP back end.
Data must be properly managed
For more information, see Preparing Master Data for Order Management with Multiple Back Ends.
Preparing Master Data for Order

Management with Multiple Back Ends
When using multiple SAP back ends for order ful llment, manage data for products, pricing, plants, and customers according to your
scenario.
Managing Product IDs

When gathering products from multiple SAP back ends into a catalog for a single online store, use the following guidelines:
Scenario Data Management Approach
3/5/2020
Scenario Data Management Approach
Some products are known to a single SAP back end Make product IDs unique across all back ends.
Example:
Back end 1 manages products with IDs from 000 001 to 100 000.
Back end 2 manages products between 100 001 and 200 000.
Some products are known to more than one SAP back end Use the same ID in each back end that handles the product.
Example:
A product called Monitor has product ID 100 999 in back end 1 and 2.
Some products are known to all SAP back ends Maintain consistent IDs for products handled by all back ends.
Example:
A product called Monitor has product ID 100 999 in all back ends.
Managing Prices and Discounts

While order ful llment can be distributed among multiple SAP back ends, use a single back end to upload pricing data to SAP
Commerce.
Regardless of whether products are known to one, several, or all back ends, the recommended approach is the same. First, maintain
price and discount conditions consistently across all back ends in which order ful llment takes place. Next, replicate pricing data to
SAP Commerce from a single SAP back end.
Managing Plant Data

When replicating stock information, plant data is crucial. Sourcing determination in SAP Commerce leverages all locations where
product inventory is available. Consignment entries are created for each warehouse, and each warehouse must correspond one-to-
one with a plant in the SAP back end.
Do not assign a single plant ID to more than one SAP back end. Maintaining unique plant IDs for each back end ensures that when
ful llment for a product is distributed among multiple back ends, the plant ID can uniquely identify the system to use for ful llment
purposes. The following table provides an example.
SAP Back End System Client Sales Area Plants
ERP 1 100 1000-30-00 1000, 1100, 1200, 1600, 1900,

4000
ERP 2 200 2000-30-00 2000, 2200, 2700
S/4HANA 1 100 3000-30-00 3000, 3100, 3900, 6000, 1300
If 40 pieces of product ʻABCD’ should be sourced from warehouse 2200, then ERP 2 is the target ful llment system as 2200 is only
de ned there.
Managing Customer Data

After order splitting in SAP Commerce, sub-orders are created in the SAP back end. Each sub-order contains a sold-to party. The sub-
order can only be created if the sold-to party is known in the SAP back end. This prerequisite applies to B2B and B2C scenarios.
For B2B customers, the system of record is the SAP back end. If self-registration is enabled, new and updated contact data is
replicated to a single SAP back end.
3/5/2020
For B2C consumers, the system of record is SAP Commerce. Consumers register in the online store to create their accounts. Once
registered, their data is also replicated to a single SAP back end.
In both B2B and B2C scenarios, harmonize customer master data among the SAP back ends involved in distributed order
management. When either B2B or B2C customer data is replicated to a single SAP back end, con gure the receiving system to
forward the data to the other back ends.
Third-Party Vendor Sourcing with AOM

You can enable third-party vendor sourcing with Order Management Services and asynchronous order management (AOM). This
scenario is available when integrating SAP Commerce with a single SAP ERP back end, and is not available if integrating with SAP
S/4HANA.
In this scenario, a customer orders a product that is stocked by one of the retailer's third-party vendors. The customer order triggers
a purchase order requisition that the retailer sends to the third-party vendor. The vendor then sends the product to the retailer. The
product becomes available for processing in SAP ERP, and the retailer ships the product to the customer.
The following diagram illustrates the work ow:
Related Information
Con gure Order Management for SAP Commerce with One or More SAP Back Ends
Con guring Third-Party Vendor Sourcing
Con gure Order Management for SAP

Commerce with One or More SAP Back Ends
Implement Order Management Services with one or more SAP back ends (SAP S/4HANA or SAP ERP). Include required extensions
in your localextensions.xml le, and con gure settings in Backoffice Administration Cockpit.
Choose one of the following methods for performing this task:
Con guring Using sap-oms-order-process

3/5/2020
The sap-oms-order-process is a method of integrating SAP S/4HANA and SAP ERP back ends with Order Management for
SAP Commerce that requires order ful llment to be completed via an SAP back end.
Con guring Using order-process
For SCPI-based integrations only, follow these steps to con gure order management for SAP Commerce with one or more
backends using order-process.
To use third-party vendor sourcing with asynchronous order management and an SAP ERP back end, link the vendor with the
warehouse object.
Con guring Using sap-oms-order-process

The sap-oms-order-process is a method of integrating SAP S/4HANA and SAP ERP back ends with Order Management for SAP
Commerce that requires order ful llment to be completed via an SAP back end.
Prerequisites
You have done the following:
Installed the platform extensions for Order Management Services.
Con gured asynchronous order management.
Synchronized data for products, warehouses, points of service, and stock levels between the SAP back end and SAP
Commerce.
Deployed the Data Hub extensions required for your scenario (B2B, B2C, or both).
Procedure
1. Add the extensions required for your scenario to your localextensions.xml le.
For more information, see SAP S/4HANA or SAP ERP Extensions for Asynchronous Order Management.
2. In Backoffice Administration Cockpit under Base Commerce Base Store , in the Properties tab, enter the following value for
Submit order process code: sap-oms-order-process
3. Navigate to SAP Integration SAP Global Con guration Back-End Connectivity .
4. Use the table to de ne mapping data for one or more SAP logical systems.
a. Either select an existing SAP logical system or select Create New SAP Logical System.
b. When de ning a new logical system, specify SAP ERP or SAP S/4HANA as the back end by selecting from the SAP
System Type dropdown list.
c. Specify the HTTP address.
d. Specify the sender name and sender port of the SAP back end.
However, if replicating customer data from SAP Commerce to an SAP back end, also de ne the sender name and
sender port in the local.properties le.
e. After creating your logical systems, specify the default by entering edit mode for the logical system, and then setting
Default SAP Logical System to True.
If using a single SAP back end, specify it as the default SAP logical system.
5. Navigate to SAP Integration SAP Base Store Con guration Common Settings .
6. Use the Mapping SAP Plant to Logical System and Sales Area table to create mappings for SAP plants to SAP logical
systems and sales areas.
7. To de ne a new SAP sales area, do the following:
a. Map a plant to a logical system and leave the SAP sales area blank.
3/5/2020
After you save the mapping, the SAP sales area displays as Null.
b. After saving the mapping, enter edit mode and de ne the new SAP sales area.
When using Order Management Services with AOM, product availability functionality is provided by the Order Management
Services module. In this case, live ATS checks provided by the sapproductavailability and
b2bsapproductavailability extensions cannot be used with the Order Management Services module.
Con guring Using order-process

For SCPI-based integrations only, follow these steps to con gure order management for SAP Commerce with one or more backends
using order-process.
Prerequisites
Installed the platform extensions for Order Management Services.
Con gured asynchronous order management.
Synchronized data for products, warehouses, points of service, and stock levels between the SAP back end and SAP
Commerce. For more information, see Synchronizing Data between the SAP Back End and SAP Commerce.
Deployed the SCPI extensions required for your scenario (B2B, B2C, or both).
Context
 Note
This feature is supported for SCPI-based integrations only. For more information, see ysapcpiomsful llment Extension. To ful ll
consignments using SAP Commerce Order Management and SAP S/4HANA and SAP ERP back ends using DH, use the
Aynchronous Order Management module.
S/4HANA andERP back-end integration with Order Management for SAP Commerce supports External Consignment Ful llment
Framework and the use of the standard order process (order-process).
Using the External Consignment Ful llment Framework and use of the standard order process allows Order Management for SAP
Commerce to ful ll some consignments locally, and to delegate other to one or more different SAP back-end systems. Candidates for
this scenario are businesses that want to ful ll orders using Order Management for SAP Commerce and multiple SAP back-ends.
When customers submit orders, Order Management Services:
Creates one or more consignments for each order line item
Assigns sourcing locations to each consignment: a local location for consignments that might need to be ful lled by Order
Management for SAP Commerce; an external location for consignments that might need to be ful lled by SAP back-end
systems
Assigns an SAP back end to each sourcing location
Triggers the distribution of sub-orders to the back ends using SCPI
Follow these steps to con gure order management for SAP Commerce with one or more back ends using order-process.
Procedure
1. Add the extensions required for your scenario to your localextensions.xml le.
3/5/2020
2. In Backoffice Administration Cockpit under Base Commerce Base Store , in the Properties tab, enter the following value for
Submit order process code: order-process.
3. Navigate to SAP Integration SAP Global Con guration Back-End Connectivity .
4. Use the table to de ne mapping data for one or more SAP logical systems.
a. Either select an existing SAP logical system or select Create New SAP Logical System.
b. When de ning a new logical system, specify ERP or SAP S/4HANA as the back end by selecting from the SAP System
Type dropdown list.
c. Specify the HTTP address.
d. Specify the sender name and sender port of the SAP back end.
However, if replicating customer data from SAP Commerce to an SAP back end, also de ne the sender name and
sender port in the local.properties le.
e. After creating your logical systems, specify the default by entering edit mode for the logical system, and then setting
Default SAP Logical System to True.
If using a single SAP back end, specify it as the default SAP logical system.
5. Navigate to SAP Integration SAP Base Store Con guration Common Settings .
6. Use the Mapping SAP Plant to Logical System and Sales Area table to create mappings for SAP plants to SAP logical
systems and sales areas.
7. To de ne a new SAP sales area, do the following:
a. Map a plant to a logical system and leave the SAP sales area blank.
After you save the mapping, the SAP sales area displays as Null.
b. After saving the mapping, enter edit mode and de ne the new SAP sales area and Warehouse. The new Warehouse
property determines whether to ful ll the consignment externally and replicate it to SCPI.
When using Order Management Services with AOM, product availability functionality is provided by the Order Management
Services module. In this case, live ATS checks provided by the sapproductavailability and
b2bsapproductavailability extensions cannot be used with the Order Management Services module.

To use third-party vendor sourcing with asynchronous order management and an SAP ERP back end, link the vendor with the
warehouse object.
Prerequisites
Performed the steps for con guring Asynchronous Order Management with one or more SAP back-end systems.
In SAP ERP, you have applied SAP Note 2361359
The SAP Note triggers the creation of the purchase order requisition for the third-party vendor.
Context
The vendor code in SAP Commerce must be identical to the vendor ID in SAP ERP. At runtime the vendor ID is added to the order
IDoc, along with a line type for the vendor-sourced order item.
Procedure
1. In Backoffice Administration Cockpit, navigate to System Types and search for the vendor type.
3/5/2020
2. Select Vendor from the results list.
3. Select the Search by Type button, located in the menu bar of the vendor type.
4. Create a vendor by selecting the plus (+) icon, then ll out the required elds.
When creating the vendor, make sure that the value speci ed in the Code eld corresponds to the vendor ID in the SAP back
end. The code should be 10 digits long. If the ID in the back end is numeric and less than 10 digits, add leading zeroes to the
code until it's 10 digits long. If the ID in the back end is alphanumeric, leading zeroes are not required.
5. Once the vendor is created, you can edit it and use the vendor maintenance U to assign a warehouse to be associated with that
vendor.
Using the vendor maintenance UI ensures that warehouses are automatically linked to the vendor. Alternatively, you could
create a new warehouse under Base Commerce Warehouse and specify the third-party vendor to be assigned to that
warehouse.
Results
In Backoffice Administration Cockpit, when you navigate to Base Commerce Warehouse and select the Administration tab, the
internal key appears in the Vendor eld. When you double-click the key, you see the full details including the vendor name and code.
Asynchronous OM Architecture
Deploy extensions for asynchronous order management (AOM) based on your scenario. For example, add the
saporderexchangeb2b extension to the base B2C AOM extension set to enable B2B functionality. If using SAP ERP integration,
decide whether or not to integrate Order Management Services, which requires speci c extensions.
Dependencies
Asynchronous OM Dependencies
Recipes
No recipes contain this module.
3/5/2020
Extensions
The Asynchronous Order Management module relies on extensions that vary by implementation. The following topics describe those
implementations and the required extensions, as well as a eld-mapping reference:
SAP CRM Extensions for Asynchronous Order Management

Asynchronous order management (AOM) scenarios require different sets of extensions for B2B and B2C.
SAP CRM: Field Level Mapping for AOM Scenario
The elds in SAP CRM are mapped to SAP Commerce while replicating orders for an asynchronous order management (AOM)
scenario.
SAP S/4HANA or SAP ERP Extensions for Asynchronous Order Management
Asynchronous order management (AOM) scenarios require different sets of extensions depending on whether you are
running a B2B and B2C scenario. The extensions you use are also largely determined by whether you are using standard Cart
& Checkout, or Order Management Services.
saporderexchange Extension
The saporderexchange extension provides reusable functionality related to B2C inbound and outbound sales orders in
asynchronous order management.
saporderexchangeb2b Extension
The saporderexchangeb2b extension provides reusable functions related to B2B sales order outbound processing in
saporderexchangebackoffice Extension
The saporderexchangebackoffice extension provides settings in Backoffice Administration Cockpit for mapping
pricing components in SAP Commerce to condition types in the SAP back end.
ysaporderful llment Extension
The ysaporderfulfillment extension is a template extension providing a customizable ful llment process and designed
to support asynchronous order management with SAP S/4HANA or SAP ERP as the order ful llment system. This extension
integrates features provided by the system with SAP Commerce services and the Accelerator.
SAP CRM Extensions for Asynchronous Order

Management
Asynchronous order management (AOM) scenarios require different sets of extensions for B2B and B2C.
The following table lists the extensions required for AOM with standard SAP Commerce order management, for both B2B and B2C
scenarios:
AOM Scenario Required Extensions
B2C only
sapcrmorder-raw
sapcrmorder-canonical
sapcrmorder-target
sapcrmorderexchange
ysaporderfulfillment
3/5/2020
B2B and B2C

sapcrmorder-raw
sapcrmorder-canonical
sapcrmorder-target
sapcrmorderexchange
saporderexchangeb2b
 Note
The extensions for SAP credit checks (sapcrmcreditcheck, sapcreditcheck, and sapcreditcheckhmc) are optional,
and applicable only to B2B scenarios.
sapcrmorderexchange Extension
The sapcrmorderexchange extension provides reusable functionality related to B2C inbound and outbound sales orders in the
asynchronous order management scenario. The sapcrmorderexchange extension uses saporderexchange as base for order
replication.
Overview
The following objects are relevant for asynchronous order management:
Activity SAP Commerce SAP CRM Direction
Order creation Order and subsequent entries Sales Order Outbound
Order cancellation in SAP Order cancel request Sales Order Outbound

Commerce
Order cancellation in SAP CRM Order cancel noti cation Sales Order Inbound
Order con rmation Order Sales Order Inbound
Delivery creation Consignment Sales Order Inbound
Goods issue Consignment Sales Order Inbound
Invoice number creation Invoice noti cation Sales Order Inbound
The sapcrmorderexchange extension links the different activities within the order process, and the corresponding items within
SAP Commerce. Furthermore, for the outbound case, it extracts the relevant information from the affected items and sends this
information to Data Hub. The translation between the SAP Commerce and SAP CRM domain models takes place within Data Hub.
The integration between SAP Commerce and SAP CRM is based on Data Hub as shown in the following graphic:
3/5/2020
The datahubadapter extension is responsible for the communication between SAP Commerce and Data Hub.
Dependencies
The sapcrmorderexchange extension depends on the following extensions:
saporderexchange: provides the SAP ERP order exchange used as a base for sapcrmorderexchange
sapcrmcustomerb2c: provides the consumer information successfully replicated to SAP CRM
Outbound Processing
The following graphic shows a simpli ed view of the extension and layer concept used.
3/5/2020
The outbound functions are split into the following parts:
1. The creation of a Data Hub raw item is offered by the RawItemBuilder interface. In the provided implementation, this is
generically implemented by an AbstractRawItemBuilder. The AbstractRawItemBuilder is the super class of all
raw item speci c builders. For the order outbound, the AbstractRawItemBuilders are DefaultRawHybrisOrderBuilder
(which creates raw data for sales order replication to SAP CRM) and DefaultOrderCancelRequestBuilder (which
creates raw data to create a cancel request for replication to SAP CRM).
2. The AbstractRawItemBuilder has a list of references to RawItemContributor instances. A

RawItemContributor provides a speci c part of a Data Hub raw item as a list of name and value pairs. The list of
3/5/2020
contributors to a raw item is injected via Spring into the corresponding raw item builder. For the sales order, the following
contributors exist:
DefaultCrmOrderContributor: Provides order header information. Class extended to implement logic for sending
named delivery date from SAP Commerce.
DefaultOrderEntryContributor: Provides order entry information
DefaultCRMPartnerContributor: Provides partner-related information (role and address)
DefaultCRMSalesConditionsContributor: Provides price-relevant data, such as item prices, discounts, and taxes on
header and item level. Note that if synchronous pricing is active for the cart and order, the sales conditions determined
by SAP CRM during checkout are transferred back to SAP CRM to ensure consistent pricing. Otherwise, the sales
condition information is extracted directly from the SAP Commerce sales order
DefaultCRMPaymentContributor: Provides payment information. Note that only payment via payment service
providers is supported
DefaultCrmOrderCancelRequestContributor: Provides information that is needed for creating a cancel request
3. The orchestration of raw item creation and handover to the Data Hub adapter is done by the SendToDataHubHelper interface
implemented by the AbstractSendToDataHubHelper.
4. If the known customer ID should be replicated for a B2C online store, the outbound of the sales order only takes place once it
is con rmed that the back-end system was able to create the customer. This is indicated by the sapConsumerId eld, which is
added to the Customer via the sapcustomerB2C extension. For this reason, sapcrmorderexchange requires
saporderexchange. The saporderexchange extension requires the sapcustomerB2C extension as prerequisite. The
logic to determine whether the order ful llment can trigger the outbound replication of the sales order is contained in the
B2CCustomerHelper class.
For order cancellations, the same schema applies (apart from the check for the customer replication). Note that order cancellation is
not implemented in the order ful llment process – this could happen at any time. Therefore, there is also no order cancel action. The
creation of the cancellation request is triggered by the SendOrderCancelRequestAsCSVTaskRunner called by the order cancel
framework.
How to Enhance the Mapping
Rede ning a Contributor
Using the replacement of the DefaultCRMSalesConditionsContributor as an example, the following steps must be performed in your
own extension:
Set sapcrmorderexchange as the required extension in the extensioninfo.xml le.
<requires-extension name="sapcrmorderexchange" />
Create a new class for the contributor, implementing RawItemContributor<OrderModel>:
public class MySalesConditionsContributor implements RawItemContributor<OrderModel>

{
@Override
public Set<String> getColumns()
{
return new HashSet<>(Arrays.asList("Column1", "Column2"));
}
@Override
public List<Map<String, Object>> createRows(final OrderModel order)
{
List<Map<String, Object>> conditions = new ArrayList<>();
3/5/2020
// Do the interesting stuff
return conditions;
}
}
De ne a bean, hiding the default implementation:
<alias name="mySalesConditionsContributor" alias="sapSalesConditionsContributor" />

<bean id="mySalesConditionsContributor" class="com.foo.bar.MySalesConditionsContributor">
</bean>
Changing the List of Contributors
If the set of registered contributors for the order outbound needs to be changed, you must de ne a new order builder. The following
steps are required:
Set sapcrmorderexchange as the required extension in the extensioninfo.xml le (see above).
Create a new class implementing RawItemBuilder<OrderModel>. It is recommended to inherit from

AbstractSendToDataHubHelper<OrderModel>.
public class MyRawHybrisOrderBuilder extends AbstractRawItemBuilder<OrderModel>

{
// Nothing else required
}
De ne a bean for this class, specifying the relevant contributors:
<alias name="myHybrisOrderBuilder" alias="sapRawHybrisOrderBuilder" />

<bean id="myHybrisOrderBuilder" class="com.foo.bar.MyRawHybrisOrderBuilder" parent="sapAbstractRawI
<property name="contributors">
<list>
<ref bean="myContributor1"></ref>
</list>
</property>
</bean>
Speci c Extension Tasks
Enhance Payment Mapping
In the delivered example for asynchronous order management, it is assumed that in SAP Commerce the payment authorization takes
place with an external secure payment provider, such as CyberSource. For SAP CRM in particular, this means that credit card
information is not stored, thereby avoiding PCI compliance issues. In SAP CRM, such payments are treated as being done for an
additional credit card company. Therefore, information relevant for payment via the payment provider is collected in the
DefaultCRMPaymentContributor bean. As of now, only one transaction via PSP is supported.
If you want to enable other kinds of payment, you must create your own version of the DefaultCRMPaymentContributor bean.
Inbound Processing
3/5/2020
In inbound processing, data returned by Data Hub is done via ImpEx. In addition to the sole posting of data to the database, the usage
of the translator concept allows for the execution of custom coding. This is done for each noti cation type. As shown in the graphic
for the order creation noti cation (translator class DataHubOrderCreationTranslator), a business process event is created to indicate
that the corresponding noti cation has arrived. The order ful llment process instance waiting for this event can then continue its
execution. Typically, the next step is to set the corresponding order status. In the example, this is done by the
SetCon rmationStatusAction class.
Since the translators are not Spring beans, they delegate the logic to noti cation-speci c helper classes. For the order-related
noti cations (con rmation, cancellation), the logic is stored in the DataHubInboundOrderHelper class. For the delivery-related
noti cations, the logic is stored in the DefaultDataHubInboundDeliveryHelper class. If other translators are used, the target item
mapping in Data Hub must be changed. For more information, see sapcrmorder Data Hub Extension.
Cancelling Orders
Cancellation of sales orders can be triggered from SAP Commerce (within the Customer Service cockpit) or from SAP CRM.
In both cases, only cancellation of the complete sales order is supported. You cannot cancel individual items in an order. You can
enforce this in SAP Commerce by disabling partial order cancellation. In Backoffice, choose Base Commerce Order Cancel
Con guration .
The following graphic shows how the integration into the existing SAP Commerce cancel framework is done. The red font indicates
the integration points for speci c logic or coding for the SAP CRM integration.
3/5/2020
In the Customer Service cockpit of SAP Commerce, the clerk cancels the order of an online store customer.
The request is propagated to the DefaultOrderCancelService, which consults the OrderCancelStateMappingStrategy for how
to proceed with the cancel request.
The DefaultOrderCancelStateMappingStrategy is overwritten with DefaultSAPOrderCancelStateMappingStrategy, which

returns OrderCancelState.CANCELIMPOSSIBLE, if the sales order is already cancelled or completed. Otherwise, it returns
OrderCancelState.SENTTOWAREHOUSE to indicate that further processing of the cancellation will be processed in the
warehouse.
Within the further processing of the orderCancelService, the OrderStatusChangeStrategy bean is called, which is overwritten
again with the DefaultSapEnterCancellingStrategy bean. Here, we set the status of the sales order to CANCELLING.
Furthermore, a task (sapSendOrderCancelRequestAsCSVTaskRunner bean) is triggered.
The triggering of the task causes further processing to be asynchronous. This means that the user of the Customer Service
cockpit gets immediate response, while the data is sent to SAP CRM and Data Hub independently. Using a task for sending the
data has the following advantages:
If Data Hub is temporarily not available, the task will retry to send the data (default: ten times).
If all resendings have failed, a cron job (sapOrderexchangeCancelRepairCronJob) collects all these tasks and calls the
standard orderCancelCallbackService's onOrderCancelResponse method with parameter withResponseStatus.denied .
The user in the Customer Service cockpit sees that the cancel attempt has been denied. The order is then restored to
the state before the cancellation attempt.
When the cancellation arrives in Data Hub, it passes the usual raw/canonical/target stages: RawCrmOrderCancelRequest,
CanonicalCrmOrderRequest,CanonicalCrmOrderItem doctype=CRMXIF_ORDER_SAVE_M01.
In Data Hub, the sapRejectionReasonConverterOutbound bean does the mapping from the SAP Commerce cancel
reason to the SAP CRM rejection reason.
An order IDoc of type CRMXIF_ORDER_SAVE_M01 is sent to SAP ERP, causing all items in the order to be cancelled. As
response, a CRMXIF_ORDER_SAVE_M01 IDoc is sent back to Data Hub.
Alternatively, the cancellation of the order could have been triggered within SAP CRM (for example in transaction
CRMD_ORDER). In that case, the same CRMXIF_ORDER_SAVE_M01 IDoc is sent to Data Hub.
In Data Hub, the message passes the raw, canonical, and target stages. As this message is purely for noti cation purposes
(without much information content), we call the corresponding Data Hub items CanonicalCrmOrderCancelNoti cation and
3/5/2020
TargetCrmOrderCancelNoti cation. A mapping from SAP ERP rejection reason to SAP Commerce cancel reason takes place in
the sapRejectionReasonConverterInbound bean.
To trigger further processing within SAP Commerce, we use the ImpEx translator mechanism. This allows for the direct calling
of a method of a java class, and passing of a parameter.
This is the DataHubOrderCancelTranslator translator class. The only parameters passed are the orderId, cancelReason, and
isCancelRequest. The isCancelRequest eld is used to identify that this raw item if for cancel request or order creation.
The translator class only propagates the call to DefaultSapOrderCancelService, which checks whether the cancellation was
triggered from SAP Commerce. If the call orderService.getCancelRecordForOrder() does not return a record, it was triggered
from SAP ERP. In that case, orderCancelRecordsHandler.createRecordEntry () creates such a record and further processing
can continue in the same way.
Further processing consists of calling orderCancelCallBackService.onOrderCancelResponse (OrderCancelResponse.

ResponseStatus .full) .
The original delivery requires the orderCancelPaymentServiceAdapter bean to be overwritten, otherwise the process will not
succeed. This bean is overwritten with a dummy implementation that allows the process to nish successfully.
 Note
It is still assumed that this bean ( orderCancelPaymentServiceAdapter ) gets overwritten in a customer project in order to contain
real payment relevant logic.
Con guration
The following con guration settings determine the behavior of the sapcrmorderexchange extension:
SAP Global Con guration
Depending on the setting Replicate Registered Users , either the known user for a newly created B2C order is taken for the mapping
to the RawHybrisOrder or the reference user speci ed in the store-dependent con guration. This setting has no effect for B2B orders
and for orders created by a guest user.
SAP Base Store Con guration
Common Settings
The following con guration settings introduced by the sapmodel extension are needed to create an order in the SAP CRM back end:
Setting Where used? Comment
Reference Customer sapcrmorderexchange, outbound Only used in the order as one-time customer
mapping in case the order is a B2C order and the
global setting "Replicate Registered Users" is
not active or if the user is a guest user (see
above).
Order Type sapcrmorder extension on Data Hub The order type is read from the canonical
item SAPCon guration derived from the
store name attached to the order.
Sales Organization sapcrmorder extension on Data Hub The sales organziation is read from the
canonical item SAPCon guration derived
from the store name attached to the order.
Distribution Channel sapcrmorder extension on Data Hub The distribution channel is read from the
canonical item SAPCon guration derived
3/5/2020
Division sapcrmorder extension on Data Hub The division is read from the canonical item
SAPCon guration derived from the store
name attached to the order.
Shipping Method Mapping saporder extension on Data Hub The SAP shipping condition is read from the
canonical item DeliveryModeMapping derived
Settings for Asynchronous Order Management
Within this extension, additional attributes of the base store speci c con guration relevant for pricing from SAP Commerce are made.
The base store speci c con guration is enhanced by the following attributes used for creating the sales conditions:
Condition type for item total price
Condition type for shipping cost on header level
Condition type for payment cost on header level
These condition types must exist in the corresponding pricing procedure on CRM side. No con guration is offered for item discounts.
It is assumed that the SAP Commerce discount code is the same as the corresponding CRM condition type. No con guration is
offered for tax values on item level - see section Relevant Java Properties.
If SAP Commerce is enabled to use the pricing extension, the asynchronous order management can also run with synchronous
pricing. In this case, synchronous pricing can be activated via the Setting CRM Pricing for Orders on the pricing tab and only the
pricing settings introduced by the sappricingbol extension are used to ll the sales conditions and prices. For more information
about these settings, see extension sappricing.
Provided Spring Beans
Name Alias Descr
defaultSapAbstractRawItemBuilder sapAbstractRawItemBuilder Abstra

functi
RawIte
defaultCRMSapRawHybrisOrderBuilder sapCrmRawHybrisOrderBuilder Builde

on con
defaultSapCRMOrderContributor sapCrmOrderContributor Contri

provid
inform
defaultSapOrderEntryContributor sapCrmOrderEntryContributor Contri

provid
inform
defaultSapCrmSalesConditionsContributor sapCrmSalesConditionsContributor Contri

provid
inform
defaultSapCrmPartnerContributor sapCrmPartnerContributor Contri

provid
inform
defaultSapCrmPaymentContributor sapCrmPaymentContributor Contri

provid
inform
3/5/2020
Name Alias Descr
defaultCrmOrderCancelRequestBuilder crmOrderCancelRequestBuilder Builde

RawHy
Depen
defaultCrmOrderCancelRequestContributor crmOrderCancelRequestContributor Contri

RawHy
sapDefaultAbstractSendToDataHubHelper sapAbstractSendToDataHubHelper Abstra

sendin
De ne
to raw
sapCrmOrderexchangeDefaultSendOrderToDataHubHelper sapOrderexchangeSendOrderToDataHubHelper Helpe

items
to abs
sapOrderexchangeDefaultSendOrderCancelRequestToDataHubHelper sapOrderexchangeSendOrderCancelRequestToDataHubHelper Helpe

RawHy
to Dat
abstra
customerReplicationEventListener Listen
replica
succe
sapOr
defaultSapAbstractDataHubOrderInboundHelper sapAbstractDataHubOrderInboundHelper Abstra

of ord
neede
and re
defaultSapDataHubInboundOrderHelper sapDataHubInboundOrderHelper Helpe

creatio
noti c
trigge
proces
defaultSapCRMDataHubInboundDeliveryHelper sapDataHubInboundDeliveryHelper Helpe

delive
noti c
consig
busine
sapOrderexchangeDefaultB2CCustomerHelper sapOrderexchangeB2CCustomerHelper Helpe

replica
replica
ful llm
consu
defaultSAPCrmOrderCancelStateMappingStrategy orderCancelStateMappingStrategy Cance

ensuri
with c
Overri
strate
sapOrderexchangeDefaultOrderCancelService sapOrderexchangeOrderCancelService Helpe

order
cance
defaultSapSendOrderCancelRequestAsCSVTaskRunner sapSendOrderCancelRequestAsCSVTaskRunner Task r

cance
usage
bean e
3/5/2020
Name Alias Descr
sapOrderexchangeDefaultOrderExchangeRepair sapOrderexchangeOrderExchangeRepair Servic

proces
cance
enterCancellingStrategy Order
the cre
agains
Comm
orderCancelPaymentServiceAdapter Dumm
OrderC
doing
Comm
warehouseResponseExecutor Overri
injecti
servic
partialCancelRulesViolationStrategy Overri
only a
order
defaultSapDataHubInboundInvoiceHelper sapDataHubInboundInvoiceHelper Helpe

invoice
numb
Relevant Java Properties

The following properties are relevant for the saporderexchange extension:
Name Description Default Value Comment
keygen.order.code.digits Number of 10 The order ID

digits of must have the
order ID same length
as in the ERP
system
keygen.order.code.start Start value The order ID

of order ID on SAP
Commerce
and ERP side
must be
identical. Set
the start value
for the order
ID to the lower
limit of the
corresponding
number range
de ned in ERP
3/5/2020
saporderexchange.orderoutbound.retryDelay Minimum 60000

retry delay
in
milliseconds
in case an
order or
order cancel
request
could not be
sent to Data
Hub
saporderexchange.orderoutbound.maxRetries Maximum 10
number of
retries for
sending an
order or
order cancel
request to
Data Hub
saporderexchange.orderoutbound.datahub.feed Default feed SAPORDER_OUTBOUND_FEED

for outgoing
orders and
order cancel
requests
saporderexchange.orderoutbound.datahub.rawOrderItemType Data Hub RawCrmHybrisOrder This must be

raw item to an existing
which the raw item on
SAP Data Hub side
Commerce
order shall
be mapped
saporderexchange.orderoutbound.datahub.rawCancelRequestItemType Data Hub RawCrmHybrisOrderCancelRequest This must be

raw item to an existing
which the raw item on
SAP Data Hub side
Commerce
order cancel
request
shall be
mapped
saporderexchange.itemtax.code1 Condition MWST

code for
item tax
Note that it is not sufficient to set the start value for the order ID to be generated. The speci ed value only becomes effective once the
used number generator is reset. This is done via the following command in the BeanShell console of the SAP Commerce
Administration Cockpit:
spring.getBean("orderCodeGenerator").reset();
sapcrmorderexchangeb2b Extension
3/5/2020
The sapcrmorderexchangeb2b extension provides reusable functions related to B2B sales order outbound processing in
The sapcrmorderexchangeb2b extension is an enhancement to sapcrmorderexchange. Within

sapcrmorderexchangeb2b extension, the bean DefaultCRMPartnerContributor is rede ned to support B2B orders as
well for the outbound mapping.
Dependencies
The sapcrmorderexchangeb2b extension depends on the following extensions:
sapcrmorderexchange: Provides basic functions for the outbound mapping enhanced via this extension.
sapcrmcustomerb2b: The B2B order ful llment is based on the replication of SAP S/4HANA or SAP ERP customers.
Features
For more information about features, see sapcrmorderexchange extension.
B2B-Speci c Enhancements
As this extension enhances sapcrmorderexchange, the default partner contributor from sapcrmorderexchange is also used
for the B2B scenario.
Handling of B2B Customers
In a B2B scenario, the SAP CRM customers have been replicated to SAP Commerce where they can then be accessed. Specify the
following partners when creating orders in the SAP back end:
Sold-to party: This is the company. This corresponds to the root B2B unit in SAP Commerce.
Contact person: The person who created the sales order. This corresponds to the B2B customer in SAP Commerce.
Ship-to party: The user may have created his or her own shipping addresses locally in SAP Commerce. This can be identi ed
by an empty SAPCustomerID attribute of the shipping address. For this, a document-internal ship-to address is created in
the IDoc and the company is used as the ship-to party.
Bill-to party: The user may have created his or her own payment addresses locally in SAP Commerce. This can be identi ed by
an empty SAPCustomerID attribute of the payment address. For this, a document-internal bill-to address is created in the
IDoc and the company is used as the bill-to partner.
Name Alias Description
defaultSapCrmB2BPartnerContributor sapCrmPartnerContributor Contributor to a RawCrmHybrisOrder

providing all B2B-related partner attributes.
Alias hides corresponding B2C contributor.
Related Information
3/5/2020
SAP CRM: Field Level Mapping for AOM

Scenario
The elds in SAP CRM are mapped to SAP Commerce while replicating orders for an asynchronous order management (AOM)
scenario.
SAP CRM - SAP Commerce Field Mapping

IDoc Name: CRMXIF_ORDER_SAVE_M01
IDoc Field SAP Commerce Model SAP Commerce Model Attribute
EDI_DC40-OBJECT_ID OrderModel orderId
EDI_DC40-MESTYP sapcrmorder.properties sapcrmorder.ordermessagetype
E101CRMXIF_BUSTRANS-OBJECT_ID OrderModel orderId
E101CRMXIF_BUSTRANS-OBJECT_TASK sapcrmorder.properties sapcrmorder.object.task.insert
E101CRMXIF_BUSTRANS- SAPCon gurationModel transactionType (Con gured in

PROCESS_TYPE Backoffice)
E101CRMXIF_BUSTRANS-OBJECT_TYPE sapcrmorder.properties sapcrmorder.object.type
E101CRMXIF_BUSTRANS-CREATED_AT OrderModel date
E101CRMXIF_BUSTRANS- OrderModel orderId

E101CRMXIF_PARTNER_XT-OBJECT_ID
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.partner.datax

E101CRMXIF_PARTNER_XT-DATAX

E101CRMXIF_PARTNER_XT-
E101CRMXIF_PARTNER-OBJECT_ID
E101CRMXIF_BUSTRANS- PartnerRoles partnerRoleCode

E101CRMXIF_PARTNER-PARTNER_FCT
E101CRMXIF_BUSTRANS- CustomerModel partnerCode (For guest customer,

E101CRMXIF_PARTNER_XT- Partner_No comes from Backoffice)
E101CRMXIF_PARTNER-PARTNER_NO
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.partner.object.task

E101CRMXIF_PARTNER-OBJECT_TASK
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.partner.kind.of.entry

E101CRMXIF_PARTNER-KIND_OF_ENTRY
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.partner.display.type

E101CRMXIF_PARTNER-DISPLAY_TYPE
E101CRMXIF_BUSTRANS- SaporderexchangeConstants documentAddressId

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-ADDR_TYPE
3/5/2020

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-OBJECT_ID

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-PARTNER_FCT
E101CRMXIF_BUSTRANS- AddressModel rstName

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-NAME
E101CRMXIF_BUSTRANS- AddressModel middleName

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-NAME_2
E101CRMXIF_BUSTRANS- AddressModel lastName

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-NAME_3
E101CRMXIF_BUSTRANS- AddressModel city

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-CITY
E101CRMXIF_BUSTRANS- AddressModel district

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-DISTRICT

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-OBJECT_ID

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-PARTNER_FCT
E101CRMXIF_BUSTRANS- AddressModel documentAddressId

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-ADDR_NO
E101CRMXIF_BUSTRANS- AddressModel street

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-STREET
3/5/2020
E101CRMXIF_BUSTRANS- AddressModel telNumber

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-TEL1_NUMBR
E101CRMXIF_BUSTRANS- AddressModel houseNumber

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-HOUSE_NO
E101CRMXIF_BUSTRANS- AddressModel postalCode

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-POSTL_COND1
E101CRMXIF_BUSTRANS- AddressModel regionIsoCode

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-REGION
E101CRMXIF_BUSTRANS- AddressModel pobox

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-PO_BOX
E101CRMXIF_BUSTRANS- AddressModel fax

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-FAX_NUMBER
E101CRMXIF_BUSTRANS- AddressModel countryIsoCode

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-COUNTRY
E101CRMXIF_BUSTRANS- AddressModel countryIsoCode

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-COUNTRYISO
E101CRMXIF_BUSTRANS- AddressModel languageIsoCode

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-LANGU_ISO
E101CRMXIF_BUSTRANS- AddressModel building

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-BUILDING
3/5/2020
E101CRMXIF_BUSTRANS- AddressModel appartment

E101CRMXIF_PARTNER-
E102CRMXIF_ADDRESS-
E104CRMXIF_ADDRESS-ROOM_NO

E101CRMXIF_BUSTRANS_ITEM-
OBJECT_ID
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel entryNumber

ITEM_NUMBER
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.properties

OBJECT_TASK
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel productCode

PRODUCT_ID
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel productName

ORDERED_PRODUCT
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel productName

PRODUCT_DESCRIPTION

E101CRMXIF_PRCD_COND_XT-
OBJECT_ID

ITEM_NUMBER

E101CRMXIF_PRCD_COND_XT-DATAX

E101CRMXIF_BT_PRCD_COND-
OBJECT_ID

ITEM_NUMBER
E101CRMXIF_BUSTRANS- SAPCon gurationModel/SAPPricingConditionModel conditionCode (Con gured in Backoffice)

COND_TYPE
3/5/2020
E101CRMXIF_BUSTRANS- OrderModel/AbstractOrderEntryModel conditionValue

COND_VALUE
E101CRMXIF_BUSTRANS- OrderModel/AbstractOrderEntryModel conditionValue

COND_RATE
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.partner.object.task

OBJECT_TASK
E101CRMXIF_BUSTRANS- OrderModel orderCurrencyIsoCode

CURRENCY_ISO

E101CRMXIF_PRODUCT_I_X-OBJECT_ID

E101CRMXIF_PRODUCT_I_X-
ITEM_NUMBER

E101CRMXIF_PRODUCT_I_X-DATAX

E101CRMXIF_PRODUCT_I-OBJECT_ID

E101CRMXIF_PRODUCT_I-
ITEM_NUMBER
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel entryUnitCode

PROCESS_QTY_UNIT
E101CRMXIF_BUSTRANS- OrderModel languageIsoCode

PROCESS_QTY_UNIT_ISO

E101CRMXIF_SCHEDLIN_I_X-OBJECT_ID
3/5/2020

E101CRMXIF_SCHEDLIN_I_X-
ITEM_NUMBER
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.item.schedlin.datax

E101CRMXIF_SCHEDLIN_I_X-DATAX

E101CRMXIF_SCHEDLIN_I-OBJECT_ID

E101CRMXIF_SCHEDLIN_I-
ITEM_NUMBER
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel quantity

E101CRMXIF_SCHEDLIN_I-ORDER_QTY

E101CRMXIF_SCHEDLIN_XT-OBJECT_ID

E101CRMXIF_SCHEDLIN_XT-
ITEM_NUMBER
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.item.schedlin.datax

E101CRMXIF_SCHEDLIN_XT-DATAX

E101CRMXIF_SCHEDLIN-OBJECT_ID

E101CRMXIF_SCHEDLIN-ITEM_NUMBER

E101CRMXIF_SCHEDLIN-SCHEDLIN_NO
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel quantity

E101CRMXIF_SCHEDLIN-QUANTITY
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.schedlin.object.task

E101CRMXIF_SCHEDLIN-OBJECT_TASK
3/5/2020

E101CRMXIF_ORGMAN_X-OBJECT_ID
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.order.datax

E101CRMXIF_ORGMAN_X-DATAX

E101CRMXIF_ORGMAN_X-
E101CRMXIF_ORGMAN-OBJECT_ID
E101CRMXIF_BUSTRANS- SAPCon gurationModel salesOrganization (Con gured in

E101CRMXIF_ORGMAN_X- Backoffice)
E101CRMXIF_ORGMAN-SALES_ORG
E101CRMXIF_BUSTRANS- SAPCon gurationModel distributionChannel (Con gured in

E101CRMXIF_ORGMAN-DIS_CHANNEL
E101CRMXIF_BUSTRANS- SAPCon gurationModel division (Con gured in Backoffice)

E101CRMXIF_ORGMAN_X-
E101CRMXIF_ORGMAN-DIVISION
E101CRMXIF_BUSTRANS- SAPCon gurationModel salesOrgResponsible (Con gured in

E101CRMXIF_ORGMAN-
SALES_ORG_RESP

E101CRMXIF_PRICING_X-OBJECT_ID
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.order.datax

E101CRMXIF_PRICING_X-DATAX

E101CRMXIF_PRICING_X-
E101CRMXIF_PRICING-OBJECT_ID
E101CRMXIF_BUSTRANS- OrderModel orderCurrencyIsoCode

E101CRMXIF_PRICING_X-
E101CRMXIF_PRICING-CURRENCY

E101CRMXIF_SHIPPING_X-OBJECT_ID
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.shipping.datax

E101CRMXIF_SHIPPING_X-DATAX

E101CRMXIF_SHIPPING_X-
E101CRMXIF_SHIPPING-OBJECT_ID
E101CRMXIF_BUSTRANS- SAPCon gurationModel deliveryMode (Mapping Con gured in

E101CRMXIF_SHIPPING_X- Backoffice)
E101CRMXIF_SHIPPING-SHIP_COND

E101CRMXIF_PAYPLAN_X-OBJECT_ID
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.payment.datax

E101CRMXIF_PAYPLAN_X-DATAX

E101CRMXIF_PAYPLAN_X-
E101CRMXIF_PAYPLAN-OBJECT_ID
3/5/2020
E101CRMXIF_BUSTRANS- sapcrmorder.properties sapcrmorder.payplantype

E101CRMXIF_PAYPLAN-PAYPLAN_TYPE

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-OBJECT_ID
E101CRMXIF_BUSTRANS- PaymentTransactionModel requestId

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-AUTH_REF
E101CRMXIF_BUSTRANS- PaymentTransactionModel paymentProvider

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-CARD_TYPE
E101CRMXIF_BUSTRANS- CreditCardPaymentInfoModel subscriptionId

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-CARD_NO
E101CRMXIF_BUSTRANS- CreditCardPaymentInfoModel validToYear,validToMonth

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-
CARD_EXP_DATE
E101CRMXIF_BUSTRANS- CreditCardPaymentInfoModel ccOwner

E101CRMXIF_PAYPLAN-
E101CRMXIF_PAYPLAN_D-
CARD_HOLDER
E101CRMXIF_BUSTRANS- AbstractOrderEntryModel namedDeliveryDate

E101CRMXIF_SALES_X-
E101CRMXIF_SALES-REQ_DLV_DATE
SAP S/4HANA or SAP ERP Extensions for

Asynchronous Order Management
Asynchronous order management (AOM) scenarios require different sets of extensions depending on whether you are running a B2B
and B2C scenario. The extensions you use are also largely determined by whether you are using standard Cart & Checkout, or Order
Management Services.
 Caution
The scenarios for AOM with standard SAP Commerce order management and with Order Management Services are mutually
exclusive. Once you deploy the SAP extensions for use with Order Management Services, AOM for standard SAP Commerce order
management no longer works. So if you deploy the SAP extensions for Order Management Services without also deploying the
platform extensions for Order Management Services, you cannot use asynchronous order management AOM. The system does
not revert back to standard AOM, as the SAP extensions for Order Management Services overwrite all existing SAP order
management functionality.
3/5/2020
Required Extensions
The following table lists the required extensions for AOM with standard SAP Commerce order management and with Order
Management Services, for both B2B and B2C scenarios:
B2C only
saporder-raw Data Hub
saporder-canonical Data Hub
saporder-target Data Hub
saporderexchange
B2B and B2C

saporderexchange
saporderexchangeb2b
B2C only with Order Management Services

saporderoms-raw Data Hub
saporderoms-canonical Data Hub
saporderoms-target Data Hub
saporderexchange
saporderexchangeoms
ysapomsfulfillment (Uses the SAP business process

sap-oms-order-process with Data Hub and SAP Cloud
Platform Integration. It is not the recommended extension to
use with SAP Cloud Platform Integration.)
ysapcpiomsfulfillment (Uses the SAP business process

order-process, and it is the recommended extension to
3/5/2020
B2B and B2C with Order Management Services

saporderoms-raw Data Hub
saporderoms-canonical Data Hub
saporderoms-target Data Hub
saporderexchange
saporderexchangeb2b
ysapomsfulfillment (Uses the SAP business process

sap-oms-order-process with Data Hub and SAP Cloud
Platform Integration. It is not the recommended extension to
ysapcpiomsfulfillment (Uses the SAP business process

order-process. It is the recommended extension to use
with SAP Cloud Platform Integration.)
saporderexchangeoms
saporderexchangeomsb2b
 Note
This last extension is only required for third-party vendor
sourcing in B2B scenarios.
 Note
The extensions for SAP credit checks are optional, and applicable only to B2B scenarios (either standard SAP Commerce order
management or Order Management). The extensions are also only available for SAP ERP integration.
The saporderexchange extension provides reusable functionality related to B2C inbound and outbound sales orders in
Overview
The following objects are relevant for asynchronous order management:
Activity SAP Commerce SAP Back End Direction
Order creation Order and subsequent entries Sales Order Outbound
Order cancellation in SAP Order cancel request Sales Order Outbound

Commerce
Order cancellation in the SAP Order cancel noti cation Sales Order Inbound
back end
3/5/2020
Activity SAP Commerce SAP Back End Direction
Order con rmation Order Sales Order Inbound
Delivery creation Consignment Outbound delivery Inbound
Goods issue Consignment Material document Inbound
The saporderexchange extension links the different activities within the order process, and the corresponding items within the SAP
Commerce platform. Furthermore, for the outbound case, it extracts the relevant information from the affected items and sends this
information to Data Hub. The translation between SAP Commerce and the SAP back end domain models takes place within Data Hub.
The integration between SAP Commerce and the SAP back end is based on Data Hub as shown in the following graphic:
The datahubadapter extension is responsible for the communication between the SAP Commerce platform and Data Hub.
3/5/2020
Dependencies
The saporderexchange extension depends on the following extensions:
sapmodel: Provides con guration items needed for outbound mapping
sapcustomerb2c: Provides information about the B2C consumer replication status
datahubadapter: Provides connectivity to Data Hub
saporderexchange Inbound and Outbound

Processing
Understand how saporderexchange handles inbound and outbound processing, and learn how to cancel orders.
Outbound Processing
3/5/2020
The outbound functions are split into the following parts:
The creation of a Data Hub raw item is offered by the RawItemBuilder interface. In the provided implementation this is
generically implemented by an AbstractRawItemBuilder. The AbstractRawItemBuilder is the super class of all raw item
speci c builders. For the order outbound, the AbstractRawItemBuilders are DefaultRawHybrisOrderBuilder (which creates
raw data for sales order replication to the SAP back end) and DefaultOrderCancelRequestBuilder (which creates raw data to
create a cancel request for replication to the SAP back end).
The AbstractRawItemBuilder has a list of references to RawItemContributor instances. A RawItemContributor provides a

speci c part of a Data Hub raw item as a list of name and value pairs. The list of contributors to a raw item is injected via
Spring into the corresponding raw item builder. For the sales order, the following contributors exist:
DefaultOrderContributor: Provides order header information.
DefaultOrderEntryContributor: Provides order entry information.
DefaultPartnerContributor: Provides partner-related information (role and address).
DefaultSalesConditionsContributor: Provides price-relevant data, such as item prices, discounts, and taxes on header
and item level. Note that if synchronous pricing is active for the cart and order, the sales conditions determined by the
SAP back end during checkout are returned to the back end to ensure consistent pricing. Otherwise the sales condition
information is extracted directly from the sales order.
3/5/2020
DefaultPaymentContributor: Provides payment information. Note that only payment via payment service providers is
supported.
DefaultOrderCancelRequestContributor: Provides information that is needed for creating a cancel request.
The orchestration of raw item creation and handover to Data Hub adapter is done by the SendToDataHubHelper interface
implemented by the AbstractSendToDataHubHelper.
If the known customer ID should be replicated for a B2C online store, the outbound of the sales order only takes place once it
is con rmed that the back-end system was able to create the customer. This is indicated by the sapConsumerId eld, which is
added to the Customer via the sapcustomerB2C extension. For this reason, saporderexchange requires the sapcustomerB2C
extension as prerequisite. The logic to determine whether the order ful llment can trigger the outbound replication of the
sales order is contained in the B2CCustomerHelper class.
For order cancellations the same schema applies (apart from the check for the customer replication). Note that order cancellation is
not implemented in the order ful llment process - this could happen at any time. Therefore there is also no order cancel action. The
creation of the cancellation request is triggered by the SendOrderCancelRequestAsCSVTaskRunner called by the order cancel
framework.
Rede ning a Contributor
Using the replacement of the SalesConditionsContributor as an example, the following steps must be performed in your own
extension:
Set saporderexchange as the required extension in the extensioninfo.xml le, as shown below:
<requires-extension name="saporderexchange" />
Create a new class for the contributor, implementing RawItemContributor<OrderModel>, as shown below:
public class MySalesConditionsContributor implements RawItemContributor<OrderModel>

{
@Override
public Set<String> getColumns()
{
return new HashSet<>(Arrays.asList("Column1", "Column2"));
}
@Override
public List<Map<String, Object>> createRows(final OrderModel order)
{
List<Map<String, Object>> conditions = new ArrayList<>();
// Do the interesting stuff
return conditions;
}
}
De ne a bean, hiding the default implementation, as shown below:
<alias name="mySalesConditionsContributor" alias="sapSalesConditionsContributor" />

<bean id="mySalesConditionsContributor" class="com.foo.bar.MySalesConditionsContributor">
</bean>
Changing the List of Contributors
If the set of registered contributors for the order outbound needs to be changed, you must de ne a new order builder. The following
steps are required:
1. Set saporderexchange as the required extension in the extensioninfo.xml le (see above).
2. Create a new class implementing RawItemBuilder<OrderModel>. It is recommended to inherit from

AbstractSendToDataHubHelper<OrderModel>, as shown below:
public class MyRawHybrisOrderBuilder extends AbstractRawItemBuilder<OrderModel>

{
// Nothing else required
}
3/5/2020
3. De ne a bean for this class, specifying the relevant contributors, as shown below:
<alias name="myHybrisOrderBuilder" alias="sapRawHybrisOrderBuilder" />

<bean id="myHybrisOrderBuilder" class="com.foo.bar.MyRawHybrisOrderBuilder" parent="sapAbstractRawI
<property name="contributors">
<list>
</list>
</property>
</bean>
Enhance Payment Mapping
In the delivered example for asynchronous order management, it is assumed that in SAP Commerce the payment authorization takes
place with an external secure payment provider, such as CyberSource. For the SAP back end in particular this means that credit card
information is not stored, thereby avoiding PCI compliance issues. In the SAP back end, such payments are treated as being done for
an additional credit card company. Therefore, information relevant for payment via the payment provider is collected in the
DefaultPaymentContributor bean. As of now, only one transaction via PSP is supported.
If you want to enable other kinds of payment, you must create your own version of the DefaultPaymentContributor bean.
Inbound Processing
3/5/2020
In inbound processing, data returned by Data Hub is done via ImpEx. In addition to the sole posting of data to the database, the usage
of the translator concept allows for the execution of custom coding. This is done for each noti cation type. As shown in the graphic
for the order creation noti cation (translator class DataHubOrderCreationTranslator), a business process event is created to
indicate that the corresponding noti cation has arrived. The order ful llment process instance waiting for this event can then
continue its execution. Typically, the next step is to set the corresponding order status. In the example, this is done by the
SetCon rmationStatusAction class.
Since the translators are not Spring beans, they delegate the logic to noti cation-speci c helper classes. For the order-related
noti cations (con rmation, cancellation), the logic is stored in the DataHubInboundOrderHelper class. For the delivery-related
noti cations, the logic is stored in the DefaultDataHubInboundDeliveryHelper class. If other translators are used, the target item
mapping in Data Hub must be changed. For more information, see saporder Data Hub Extension.
Raw Item Batch ID
saporderexchange supports the three additional data elds that Data Hub uses to generate a raw item batch ID. These data elds
are:
dh_batchId - which is populated with the order code
dh_type - which is populated with "HYBRIS"
dh_sourceId - which is populated with "SALESORDER_CREATE"
For more information on the Data Hubraw item batch ID, see Tracing Raw Items.
3/5/2020
Cancelling Orders
Cancellation of sales orders can be triggered from the SAP Commerce (within the Customer Service cockpit) or from SAP S/4HANA
or SAP ERP.
In both cases only cancellation of the complete sales order is supported. You cannot cancel individual items in an order. You enforce
this by disabling partial order cancellation. In Backoffice, choose Base Commerce Order Cancel Con guration .
The following graphic shows how the integration into the existing SAP Commerce cancel framework is done. The red font indicates
the integration points for speci c logic or coding for the SAP back-end integration.
Explanation of the graphic:
In the Customer Service cockpit of the SAP Commerce, the clerk cancels the order of an online store customer.
The request is propagated to the DefaultOrderCancelService , which consults the OrderCancelStateMappingStrategy for
how to proceed with the cancel request.
The DefaultOrderCancelStateMappingStrategy is overwritten with DefaultSAPOrderCancelStateMappingStrategy, which

returns OrderCancelState.CANCELIMPOSSIBLE, if the sales order is already cancelled or completed. Otherwise, it returns
OrderCancelState.SENTTOWAREHOUSE to indicate that further processing of the cancellation will be processed in the
warehouse.
Within the further processing of the orderCancelService, the OrderStatusChangeStrategy bean is called, which is overwritten
again with the DefaultSapEnterCancellingStrategy bean. Here we set the status of the sales order to CANCELLING.
Furthermore, a task (sapSendOrderCancelRequestAsCSVTaskRunner bean) is triggered.
The triggering of the task causes further processing to be asynchronous. This means that the user of the Customer Service
cockpit gets immediate response, while the data is sent to the SAP back end and Data Hub independently. Using a task for
sending the data has the following advantages:
If Data Hub is temporarily not available, the task will re-try to send the data (default: ten times).
If all re-sendings have failed, a cron job (sapOrderexchangeCancelRepairCronJob) collects all these tasks and calls the
standard orderCancelCallbackService's onOrderCancelResponse method with parameter
3/5/2020
withResponseStatus.denied . The user in the Customer Service cockpit sees that the cancel attempt has been denied.
The order is then restored to the state before the cancellation attempt.
When the cancellation arrives in Data Hub, it passes the usual raw/canonical/target stages: RawHybrisOrderCancelRequest,
CanonicalOrderCancelRequest, E1EDK02/ idoctype=ORDERS05
In Data Hub, the sapRejectionReasonConverterOutbound bean does the mapping from the cancel reason in SAP
Commerce to the rejection reason in the SAP back end.
An order IDoc of type ORDERS05 is sent to the SAP back end, causing all items in the order to be cancelled. As response an
ORDERS05 iDoc is sent back to Data Hub.
Alternatively, the cancellation of the order could have been triggered within the SAP back end (for example in transaction
VA02). In that case, the same ORDERS05 IDoc is sent to Data Hub.
In Data Hub, the message passes the raw, canonical, and target stages. As this message is purely for noti cation purposes
(without much information content), we call the corresponding Data Hub items CanonicalOrderCancelNoti cation and
TargetOrderCancelNoti cation. A mapping from the rejection reason in the SAP back end to the cancel reason in SAP
Commerce takes place in the sapRejectionReasonConverterInbound bean.
To trigger further processing within SAP Commerce, we use the ImpEx translator mechanism. This allows for the direct calling
of a method of a java class, and passing of a parameter.
This is the DataHubOrderCancelTranslator translator class . The only parameters passed are the orderId and the
cancelReason.
The translator class only propagates the call to DefaultSapOrderCancelService, which checks whether the cancellation was
triggered from SAP Commerce. If the call orderService.getCancelRecordForOrder() does not return a record, it was triggered
from the SAP back end. In that case, orderCancelRecordsHandler.createRecordEntry () creates such a record and further
processing can continue in the same way.
Further processing consists of calling orderCancelCallBackService.onOrderCancelResponse (OrderCancelResponse.

ResponseStatus .full).
The original delivery requires the orderCancelPaymentServiceAdapter bean to be overwritten, otherwise the process will not
succeed. This bean is overwritten with a dummy implementation that allows the process to nish successfully.
 Note
It is still assumed that this bean (orderCancelPaymentServiceAdapter) gets overwritten in a customer project in order to
contain real payment relevant logic.
saporderexchange Con guration

Con guration settings determine the behavior of the saporderexchange extension. You can con gure both global and base store
settings.
SAP Global Con guration

Depending on the setting Replicate Registered Users, either the known user for a newly created B2C order is taken for the mapping
to the RawHybrisOrder or the reference user speci ed in the store-dependent con guration. This setting has no effect for B2B
orders and for orders created by a guest user.
SAP Base Store Con guration
Common Settings
The following con guration settings introduced by the sapmodel extension are needed to create an order in the SAP back end:
3/5/2020
Reference Customer saporderexchange, outbound mapping only used in the order as one-time customer
in case the order is a B2C order and the
global setting "Replicate Registered Users" is
not active or if the user is a guest user (see
above).
Order Type saporder extension on Data Hub The order type is read from the canonical
item SAPConfiguration derived from the
store name attached to the order.
Sales Organization saporder extension on Data Hub The sales organziation is read from the
canonical item SAPConfiguration derived
Distribution Channel saporder extension on Data Hub The distribution channel is read from the
canonical item SAPConfiguration derived
Division saporder extension on Data Hub The division is read from the canonical item
SAPConfiguration derived from the store
name attached to the order.
Shipping Method Mapping saporder extension on Data Hub The SAP shipping condition is read from the
canonical item DeliveryModeMapping
derived from the store name attached to the
order.
Settings for Asynchronous Order Management
Within this extension, additional attributes of the base store speci c con guration relevant for pricing from SAP Commerce are made.
The base store speci c con guration is enhanced by the following attributes used for creating the sales conditions:
Condition type for item total price
Condition type for shipping cost on header level
Condition type for payment cost on header level
These condition types must exist in the corresponding pricing procedure on ERP side. No con guration is offered for item discounts.
It is assumed that the discount code in SAP Commerce is the same as the corresponding ERP condition type. No con guration is
offered for tax values on item level - see section Relevant Java Properties.
If the SAP Commerce installation is enabled to use the pricing extension, the asynchronous order management can also run with
synchronous pricing. In this case, synchronous pricing can be activated via the ERP Pricing for Orders setting on the Pricing tab and
only the pricing settings introduced by the sappricingbol extension are used to ll the sales conditions and prices. For more
information about these settings, see sappricing Extension.
Provided Spring beans
Name Alias Descr
defaultSapAbstractRawItemBuilder sapAbstractRawItemBuilder Abstra

functi
RawIte
defaultSapRawHybrisOrderBuilder sapRawHybrisOrderBuilder Builde

on con
3/5/2020
Name Alias Descr
defaultSapOrderContributor sapOrderContributor Contri

provid
inform
defaultSapOrderEntryContributor sapOrderEntryContributor Contri

provid
inform
defaultSapSalesConditionsContributor sapSalesConditionsContributor Contri

provid
inform
defaultSapPartnerContributor sapPartnerContributor Contri

provid
inform
defaultSapPaymentContributor sapPaymentContributor Contri

provid
inform
defaultSapOrderCancelRequestBuilder sapOrderCancelRequestBuilder Builde

RawHy
Depen
defaultSapOrderCancelRequestContributor sapOrderCancelRequestContributor Contri

RawHy
sapDefaultAbstractSendToDataHubHelper sapAbstractSendToDataHubHelper Abstra

sendin
De ne
to raw
sapOrderexchangeDefaultSendOrderToDataHubHelper sapOrderexchangeSendOrderToDataHubHelper Helpe

items
to abs
sapOrderexchangeDefaultSendOrderCancelRequestToDataHubHelper sapOrderexchangeSendOrderCancelRequestToDataHubHelper Helpe

RawHy
to Dat
abstra
customerReplicationEventListener Listen
replica
succe
sapOr
defaultSapAbstractDataHubOrderInboundHelper sapAbstractDataHubOrderInboundHelper Abstra

of ord
neede
and re
defaultSapDataHubInboundOrderHelper sapDataHubInboundOrderHelper Helpe

creatio
noti c
trigge
proces
defaultSapDataHubInboundDeliveryHelper sapDataHubInboundDeliveryHelper Helpe

ofdeliv
noti c
consig
busine
3/5/2020
Name Alias Descr
sapOrderexchangeDefaultB2CCustomerHelper sapOrderexchangeB2CCustomerHelper Helpe

replica
replica
ful llm
consu
defaultOrderCancelStateMappingStrategy Cance
ensuri
with c
Overri
strate
sapOrderexchangeDefaultOrderCancelService sapOrderexchangeOrderCancelService Helpe

order
cance
defaultSapSendOrderCancelRequestAsCSVTaskRunner sapSendOrderCancelRequestAsCSVTaskRunner Task r

cance
usage
bean e
sapOrderexchangeDefaultOrderExchangeRepair sapOrderexchangeOrderExchangeRepair Servic

proces
cance
enterCancellingStrategy Order
the cre
agains
defaul
orderCancelPaymentServiceAdapter Dumm
OrderC
doing
Comm
warehouseResponseExecutor Overri
injecti
servic
partialCancelRulesViolationStrategy Overri
only a
order
Name Description Default value Com
keygen.order.code.digits Number of 10 The o

digits of must
order ID same
as in
syste
3/5/2020
keygen.order.code.start Start value The o

of order ID in bo
Comm
and t
back
must
ident
the s
for th
ID to
limit
corre
numb
de n
ERP.
saporderexchange.orderoutbound.retryDelay Minimum 60000

retry delay
in
milliseconds
in case an
order or
order cancel
request
could not be
sent to Data
Hub
saporderexchange.orderoutbound.maxRetries Maximum 10
number of
retries for
sending an
order or
order cancel
request to
Data Hub
saporderexchange.orderoutbound.datahub.feed Default feed SAPORDER_OUTBOUND_FEED

for outgoing
orders and
order cancel
requests
saporderexchange.orderoutbound.datahub.rawOrderItemType Data Hub RawHybrisOrder This

raw item to an ex
which the raw it
SAP Data
Commerce
order shall
be mapped
saporderexchange.orderoutbound.datahub.rawCancelRequestItemType Data Hub RawHybrisOrderCancelRequest This

raw item to an ex
which the raw it
SAP Data
Commerce
order cancel
request
shall be
mapped
3/5/2020
saporderexchange.itemtax.code1 Condition MWST

code for
item tax
Note that it is not sufficient to set the start value for the order ID to be generated. The speci ed value only becomes effective once the
used number generator is reset. This is done via the following command in the BeanShell console of the SAP Commerce
Administration Cockpit:
Setting the start value for the Order ID
spring.getBean("orderCodeGenerator").reset();
saporderexchangeb2b Extension
The saporderexchangeb2b extension provides reusable functions related to B2B sales order outbound processing in
The saporderexchangeb2b extension is an enhancement to saporderexchange. Within the saporderexchangeb2b

extension, the beans DefaultPartnerContributor and the DefaultOrderContributor are rede ned to support B2B orders as well for
the outbound mapping.
Dependencies
The saporderexchangeb2b extension depends on the following extensions:
saporderexchange: Provides basic functions for the outbound mapping enhanced via this extension.
sapcustomerb2b: The B2B order ful llment is based on the replication of SAP S/4HANA or SAP ERP customers.
Features
B2B-Speci c Enhancements
As this extension enhances saporderexchange, the default order contributors from saporderexchange are also used for the B2B
scenario. The mapping is enhanced for two parts of the sales order:
For the partner and address data, a different mapping is needed (see below).
For the B2B order header data, the external purchase order number and the channel (B2B or B2C) are added.
Handling of B2B Customers
In a B2B scenario, the SAP S/4HANA or SAP ERP customers have been replicated to SAP Commerce where they can then be
accessed. Specify the following partners when creating orders in the SAP back end:
The sold-to party, that is, the company. This corresponds to the root B2B unit in SAP Commerce.
The contact person, that is, the person who created the sales order. This corresponds to the B2B customer in SAP
Commerce.
The ship-to party. The user may have created his or her own shipping addresses locally in SAP Commerce. This can be
identi ed by an empty SAPCustomerID attribute of the shipping address. For this, a document-internal ship-to
address is created in the IDoc and the company is used as the ship-to party.
3/5/2020
The bill-to party. The user may have created his or her own payment addresses locally in SAP Commerce. This can be
identi ed by an empty SAPCustomerID attribute of the payment address. For this, a document-internal bill-to address
is created in the IDoc and the company is used as the bill-to partner.
B2B-Speci c Order Fields
In a B2B scenario, the customer can enter the external purchase order number in the online store during checkout. Hence the
external purchase order number is read in the DefaultB2BOrderContributor beanand transferred to the Data Hub. The site channel is
an additional part of the eld mapping.
defaultSapB2BPartnerContributor sapPartnerContributor Contributor to a RawHybrisOrder providing

all B2B-related partner attributes. Alias hides
corresponding B2C contributor.
defaultSapB2BOrderContributor sapOrderContributor Contributor to a RawHybrisOrder providing

all B2B-related header attributes. Alias hides
corresponding B2C contributor.
Related Information
saporder Data Hub Extension
saporderexchangebackoffice Extension
The saporderexchangebackoffice extension provides settings in Backoffice Administration Cockpit for mapping pricing
components in SAP Commerce to condition types in the SAP back end.
Under SAP Integration SAP Base Store Con guration , the extension de nes the Asynchronous Order Management tab and its
elds.
Use this extension with the saporderexchange and sapordexchangeb2b extensions.
ysaporderful llment Extension

The ysaporderfulfillment extension is a template extension providing a customizable ful llment process and designed to
support asynchronous order management with SAP S/4HANA or SAP ERP as the order ful llment system. This extension integrates
features provided by the system with SAP Commerce services and the Accelerator.
The ysaporderfulfillment extension is designed to be used with modulegen and extgen to create the ful llment processes
required for projects.
When generating from the Accelerator, a speci c extension based on the ysaporderfulfillment extension is created. Begin by
modifying the generated extension and not the template.
The ysaporderfulfillment extension can also be used with extgen, as with other template extensions, to create a
customized ful llment process that you can use with or without the rest of the Accelerator. For more information, see Customizing
the Accelerator with extgen and modulegen and Creating a New Extension.
Order Ful llment Process
3/5/2020
The following graphic illustrates the implemented order ful llment process.
The process focuses on the status handling of the order and associated consignment. The central action is sendOrderToErp. It is
executed as soon as it is ensured that the SAP back-end system has all information needed to create the order. In a B2C scenario,
creating an order is only possible for a known customer after this customer has been successfully created. The gray bubbles
represent logic executed outside the order ful llment process. After the transfer of the order from SAP Commerce to the SAP back
end, the sales order ful llment process, such as delivery or billing, takes place in the SAP back end. The SAP Commerce order is
provided with updates on the processing status of the sales order in the back end. Technically this is done by modelling actions
waiting for a business process event. The corresponding event is raised via a custom translator called during the ImpEx import. By
setting the order and consignment status within the business process, even if some messages arrive in the wrong sequence, a status
representing a more advanced ful llment status (such as Completed) is not overwritten by a status representing a less advanced
status (such as Created).
 Note
The process is tailored for complete deliveries only. There is no logic to identify which consignment holds which products
ordered. There is no logic to determine whether all the ordered products are shipped.
Order cancellation is not modeled within this process. This is because the cancellation could occur any time within the
process ow, triggered either in SAP Commerce or in the SAP back end. Once an order is cancelled, its status is set to
Cancelled. The corresponding ful llment process is terminated by a dedicated cron job (see below).
Replicating Sales Orders from SAP Commerce to the SAP Back End
1. When a customer submits an order at the end of checkout in the online store, a business process instance of the sap-
order-process in the SAP Commerce is created. This business process instance controls the follow-on replication of that
order in both directions.
 Note
3/5/2020
Business process instances can be monitored within Backoffice by choosing System Business Process and using the
order number and the comparator contains of the search attribute code.
2. The rst action of the checkSAPOrder process can perform basic checks on the order. In the current implementation, it
sets the order header status to CHECKED_VALID. In a customer implementation, the check can be adapted to be more
precise. In case of a negative check (NOT OK), the order is set to status CHECKED_INVALID and the business process instance
has the status Error.
3. When the checkSAPOrder has passed with OK, the next action is CheckSAPCustomerReplication. This action
checks whether the customer has already been replicated from SAP Commerce to the SAP back end. If the customer has not
been replicated yet, the process goes into the waitForERPCustomerReplication waiting state, which waits for the user
management to throw the corresponding ERPCustomerReplicationEvent_<customerID> event.
 Note
The check is only performed if the replication of customers is enabled. You activate the customer replication in Backoffice
under SAP Integration SAP Global Con guration Customer Replication Replicate Registered Users .
4. SendOrdertoERP sends the order document to the Data Hub.
a. The order data is transformed into a at structure RawHybrisOrder.
b. The order data is transferred to the Data Hub using the Data Hub adapter of the SAP Commerce core system. The pool
and data-feed can be con gured in Backoffice.
c. The export status of the order is set to EXPORTED.
5. The business process enters the waitforERPConfirmation waiting state. There is no feedback from the subsequent
processing in the Data Hub until a successful order con rmation noti cation is sent back.
6. The next processing steps take place in the Data Hub. The saporder Data Hub extension handles the order-related
processing.
a. The data just imported into RawHybrisOrder is transformed into a CanonicalOrder item by means of a
composition step in the Data Hub. The composition is triggered by an automatic composition strategy.
b. The CanonicalOrder item is transformed into a TargetOrder item.
c. The TargetOrder item is transformed into an order IDoc with SALESORDER_CREATEFROMDAT2 IDoc type by the
sapidocoutboundadapter Data Hub extension.
d. The sapidocoutboundadapter Data Hub extension sends the IDoc to the SAP back end using a spring integration
outbound channel adapter.
 Note
The destination data used can be con gured in Backoffice under SAP Integration SAP Global Con guration Back-
End Connectivity HTTP Destination .
7. The order IDoc is processed in the SAP back end. A sales order is created automatically in the back end, which triggers the
creation of an outbound order IDoc (order con rmation). The order con rmation is sent back to the Data Hub.
Replicating Sales Order Con rmations, Delivery Noti cations, Goods Issue
Noti cations from the SAP Back End to SAP Commerce
1. The processing in the Data Hub runs through the following steps:
a. The order IDoc sent by the SAP back end is received by the sapidocintegration Data Hub extension.
b. The IDoc is transformed into the RawSapErpOrder item using generic logic that is not speci c to the IDoc type.
c. The RawSapErpOrder item is transformed to CanonicalOrderCreationNotification and

CanonicalOrderItemCreationNotification.
d. The canonical items are transformed into the following target items: TargetOrderCreationNotification and
TargetOrderItemCreationNotification.
2. The Data Hub adapter of the SAP Commerce core system exports the target items to the order and orderEntry SAP
Commerce core items. For the order process to allow subsequent processing to be triggered, the ImpEx translator mechanism
3/5/2020
is used.
3. The DataHubOrderCreationTranslator class receives the call from the ImpEx import of the Data Hub adapter and
raises the ERPOrderConfirmationEvent_ <orderID> business process event.
4. This event causes the waitforERPConfirmation waiting state to be left and the setConfirmationStatus action to
be entered; this sets the order header status to CREATED and the order delivery status to NOT_SHIPPED.
5. The process goes into the waitforConsignmentCreation
6. Subsequent processing of the delivery creation noti cation works in the same way as the processing of the order creation
noti cation:
a. The SAP back end sends a delivery IDoc, which is transformed into RawSapErpDelivery in the Data Hub.
b. RawSapErpDelivery is transformed into CanonicalDeliveryCreationNotification and

TargetDeliveryCreationNotitification.
c. TargetDeliveryCreationNotitification uses the translator mechanism of ImpEx to trigger subsequent

processing in SAP Commerce core.
d. The receiving translator class causes the consignment (called consignment in SAP Commerce and delivery in the SAP
back end) to be created. As the SAP Commerce-SAP Solution Integration currently only supports complete delivery for
asynchronous order management, the consignment service that creates one consignment for the whole order in one
step is used.
e. The ConsignmentCreationEvent_ <orderID> business process event is raised, which causes the
waitforConsignmentCreation waiting state to be left and the waitForGoodsIssue waiting state to be
entered.
7. Subsequent processing of the goods issue noti cation works in the same way as the processing of the delivery creation
noti cation:
a. The SAP back end sends a delivery IDoc, which is transformed into RawSapErpDelivery in the Data Hub. Since the
IDoc here is the same as the one for delivery creation, it contains some information that allows to distinguish it from
the delivery noti cation. This information is used in the transformation step from raw to canonical and allows to create
a different canonical item, which is implemented in the sapFilterGroupingHandlerDeliveryOutbound bean.
b. RawSapErpDelivery is transformed into CanonicalGoodsIssueNotification and

TargetGoodsIssueNotification.
c. TargetGoodsIssueNotification uses the translator mechanism of ImpEx to trigger subsequent processing in

SAP Commerce core.
d. The receiving translator class causes the shipping date of the consignment to be updated.
e. The GoodsIssueEvent_ <orderID> business process event is raised, which causes the waitForGoodsIssue
waiting state to be left and the setCompletionStatus action to be entered. setCompletionStatus sets the
order header status to COMPLETED and the order delivery and consignment status to SHIPPED.
8. The business process ends with the status SUCCEEDED.
Cron Jobs
OrderExchangeRepairJob
The action to send the SAP Commerce order via Data Hub to the the SAP back-end system can fail, in particular if the Data Hub
cannot be reached. The process is con gured so that a xed maximum number of retries to send the order is performed
automatically. Once the retry counter reaches the maximum and the order can still not be sent, the process goes to
ErpReplicationError status and terminates. To continue such terminated processes once the Data Hub can be reached again,
the OrderExchangeRepairJob class can be used (exposed as sapOrderexchangeRepairCronJob bean and
sapOrderexchangeRepairCronJob cron job). This class searches for all ful llment processes in ErpReplicationError
status and restarts them with sendOrderToErp action.
OrderCancelRepairJob
3/5/2020
As mentioned above, the cancellation of an order takes place outside the order ful llment process. Therefore it is necessary to
perform a clean-up of all ful llment processes for orders already cancelled. In addition, by default the the SAP back-end system does
not send an order cancellation con rmation if the requested cancellation was rejected. As a consequence, an order that could not be
cancelled in the SAP back end would stay on the status CANCELLING forever. To overcome this issue, orders that have been on
CANCELLING for too long are treated as if the cancellation failed.
This is done by OrderCancelRepairJob class (exposed as sapOrderexchangeCancelRepairCronJob bean and

sapOrderexchangeCancelRepairCronJob cron job). This class selects all order ful llment process instances in waiting state
and terminates them for orders in status CANCELED. In addition, for orders in status CANCELLING the cancel process is aborted.
Dependencies
The ysaporderfulfillment extension depends on the following extensions:
saporderexchange waiting state,: Provides reusable functionality for inbound and outbound processing of order-related
information
defaultSapOrderProcessDefinitionResource sapOrderProcessDefinitionResource Resource for SAP order ful llment

process de nition
sapOrderexchangeRepairCronJob OrderExchangeRepairJob,
created as essential data
sapOrderexchangeCancelRepairCronJob OrderCancelRepairJob, created

as essential data
ysaporderfulfillment.repair.job.cancel.minutes De nes how long a sales 60 minutes

order can have the
CANCELLING status
until it is set back to its
previous status by the
order cancel repair job.
SendOrderToErp
Asynchronous OM Implementation
There are several con guration steps required to enable sales order data replication from SAP Commerce to an SAP back end (SAP
S/4HANA, SAP ERP, or SAP CRM). The replication uses the IDoc Interface/ALE (Application Link Enabling) technology, which is a
classic SAP technology based on the SAP NetWeaver application server.
The con guration steps are the same regardless of whether or not you are integrating Order Management Services with the SAP ERP
back end.
 Note
3/5/2020
The procedures in the con guration topics that follow are only meant as examples. The con guration of asynchronous order
management depends on settings in both SAP Commerce and the SAP back end, and on the scenarios you use.
Perform the prerequisites and procedures in the order provided. Unless otherwise speci ed, they are relevant for all SAP back ends.
Prerequisites for Asynchronous Order Management

Before starting the con guration procedures for asynchronous order management, there are several prerequisites to satisfy.
De ning Sales Order Numbers
Sales orders submitted in SAP Commerce are assigned a number. When the order is replicated to the SAP back end ( SAP
S/4HANA, SAP ERP , or SAP CRM), a corresponding sales order is automatically created with the same number. To guarantee
the consistency of order numbers, number ranges in SAP Commerce must not con ict with the range used in the back end.
Setting Up One-Time Customer Accounts
You can allow customers to submit orders as guest users. In a B2C scenario, you can also allow registered users to submit
orders without replicating user data between SAP Commerce and the SAP back end ( SAP S/4HANA, SAP ERP , or SAP
CRM). For these scenarios, you need a one-time customer. This customer is used as sold-to partner, bill-to partner, and ship-
to partner in the IDoc interface.
Selecting and Con guring a Pricing Method
In the asynchronous order management scenario, you can use either synchronous pricing or pricing from SAP Commerce.
Enabling Payment Methods
Perform steps in the SAP back end ( SAP S/4HANA, SAP ERP , or SAP CRM) to enable payment methods for B2B and B2C
scenarios using asynchronous order management.
Output Control for Sales Order Con rmations
Con gure output control for IDoc types representing sales orders and sale order con rmations. By con guring these controls,
updates to sales order statuses are replicated from the SAP back end ( SAP S/4HANA, SAP ERP , or SAP CRM) to SAP
Commerce.
SAP S/4HANA or SAP ERP: Maintaining Output Control for Outbound Deliveries and Goods Issues
Con gure output control for IDoc types representing deliveries and goods issues so that when a sales order status is updated,
the change is replicated from SAP S/4HANA or SAP ERP to SAP Commerce.
Making Settings in Backoffice for Asynchronous Order Management
Make settings in Backoffice Administration Cockpit to replicate sales order data between SAP Commerce and the SAP back
end ( SAP S/4HANA, SAP ERP , or SAP CRM).
Con guring Data Hub for Asynchronous Order Management
Make entries in the local.properties le in Data Hub to replicate sales orders asynchronously from SAP Commerce
through Data Hub to the SAP back end ( SAP S/4HANA, SAP ERP , or SAP CRM).
Mapping Reasons for Canceled Sales Orders
You can cancel a sales order either in SAP Commerce or in the SAP back end ( SAP S/4HANA, SAP ERP , or SAP CRM). You
map reasons for sales order cancellations so that they are replicated with the sales orders from one system to the other.
Clean-Up Cron Jobs for Asynchronous Order Replication
Use cron jobs to resend sales orders and sales order cancellations that are not yet replicated to the SAP back end ( SAP
S/4HANA, SAP ERP , or SAP CRM).
SAP S/4HANA or SAP ERP: Replicating Promotion Discounts from SAP Commerce
Leverage the bene ts of Promotion Engine by replicating promotion discounts created in SAP Commerce to the SAP back end
( SAP S/4HANA, SAP ERP).
Prerequisites for Asynchronous Order

Management
Before starting the con guration procedures for asynchronous order management, there are several prerequisites to satisfy.
Installed the systems required for asynchronous order management as described in System Requirements for SAP
Integrations
3/5/2020
Performed the steps related to asynchronous order management (AOM) in Getting Started with SAP S/4HANA or SAP ERP
Integration or Getting Started with SAP CRM Integration
De ned an RFC destination to Data Hub, a port, logical systems, and a partner pro le as described in Con guring Basic
Settings for Data Replication
In Data Hub, included the server certi cate for the SAP back end in the JRE trust store (cacerts): <%java_home%>
\keytool< -import -alias> server_alias <- le> certificate_file.cer< -keystore %my_key_store%>
Deployed the extensions for your scenario. For more information, see Asynchronous OM Architecture.
In a B2B scenario:
Replicated your product data. For more information, see SAP S/4HANA or SAP ERP: Product Master Data Replication or SAP
CRM: Product Master Data Replication
Replicated your customers and contacts. For more information, see SAP S/4HANA or SAP ERP: Replicating Customers and
Contact Persons or SAP CRM: Replicating Customers and Contact Persons
In a B2C scenario:
Replicated your product data. For more information, see SAP S/4HANA or SAP ERP: Product Master Data Replication or SAP
CRM: Product Master Data Replication
Related Information
Setting Up System Connections for SAP Integrations
Setting RFC Destinations and HTTP Destinations
IDoc Interface/ALE
Message Control
De ning Sales Order Numbers

Sales orders submitted in SAP Commerce are assigned a number. When the order is replicated to the SAP back end (SAP S/4HANA,
SAP ERP, or SAP CRM), a corresponding sales order is automatically created with the same number. To guarantee the consistency of
order numbers, number ranges in SAP Commerce must not con ict with the range used in the back end.
To reserve a number range for SAP Commerce sales orders, perform the con guration steps described in the following topics:
SAP Back End: De ning Number Ranges
SAP Commerce: De ning Number Ranges
SAP Back End: De ning Number Ranges

To ensure consistent order numbers when passing data between SAP Commerce and the SAP back end (SAP S/4HANA, SAP ERP, or
SAP CRM), start by de ning a range in the back end.
Context
Perform the following steps in the SAP back end.
Procedure
1. Navigate to the following Customizing activity (transaction SPRO):
SAP S/4HANA or SAP ERP: Sales and Distribution Sales Sales Documents Sales Document Header De ne
Number Ranges for Sales Documents
3/5/2020
SAP CRM: Customer Relationship Management Transactions Basic Settings De ne Number Ranges Number
Ranges for Sales Transactions
2. Select Change intervals and insert line to add a new number range.
3. Enter the following values:
In the From No. (From Number) eld, enter a start value of a number range. Enter the same start value in the
local.properties le when you de ne number ranges in SAP Commerce.
Mark the Ext eld to de ne the number range as external.
In the No (Number) eld, enter the number that to identify the range, such as 02. Assign the same value to the sales
document type for SAP Commerce sales orders.
No From No. To Number NR Status Ext
<number for the <start value of your <end value of your <current number level Mark this eld to
number range>, such number range>, such number range>, such of the number range>, de ne the number
as 02 as 0005000000 as 0005999999 such as 0 range as an external
number range.
De ne sales document types in the following Customizing activity (transaction SPRO):
SAP S/4HANA or SAP ERP: Sales and Distribution Sales Sales Documents Sales Document Header De ne
Sales Document Types
SAP CRM: Customer Relationship Management Transactions Basic Settings De ne Transaction Types
Specify the number range for external assignment in the No. range ext. assg. eld.
4. Save your entries.
SAP Commerce: De ning Number Ranges

Ensure that the number ranges for sales orders in SAP Commerce match what is de ned in the SAP back end (SAP S/4HANA, SAP
ERP, or SAP CRM).
Context
For the sales order IDs, key generators are used. The key generator needs a start value, which you de ne in your
local.properties le in SAP Commerce. In <start value of your number range>, enter the same number that you de ned in the
SAP back end. For more information, see SAP Back End: De ning Number Ranges.
keygen.order.code.start=<start value of your number range>
You can also reset the start value of the key generator, as described in the following procedure.
Procedure
1. Start SAP Commerce Administration Console.
2. Navigate to Console/Scripting Languages.
3. Choose beanshell in the Script type drop box.
4. Insert the following in the text box: spring.getBean("orderCodeGenerator").reset();
Setting Up One-Time Customer Accounts

3/5/2020
You can allow customers to submit orders as guest users. In a B2C scenario, you can also allow registered users to submit orders
without replicating user data between SAP Commerce and the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM). For these
scenarios, you need a one-time customer. This customer is used as sold-to partner, bill-to partner, and ship-to partner in the IDoc
interface.
Context
Create an account group for one-time customers (CpD customers) in Customizing for SAP S/4HANA or SAP ERP, then assign this
account group to a customer that you create. Enter the one-time customer as the reference customer in Backoffice Administration
Cockpit.
If integrating with SAP CRM, use transaction code CRMC_BUPA_CONSUM to replicate the reference customer to SAP CRM from SAP
S/4HANA or SAP ERP.
For more information, see Common Settings in Backoffice for SAP Integrations.
SAP S/4HANA or SAP ERP: De ning One-Time Customer

Accounts
Perform steps in SAP S/4HANA or SAP ERP to set up one-time customer accounts.
Procedure
1. Navigate to the following Customizing activity (transaction SPRO): Logistics -General Business
Partner Customers Control De ne Account Groups and Field Selection for Customers
2. Choose New Entries and enter the following values:
Field Name Value
Account group <Account group for CpD customers>, such as CPD
Number range <External number range>, such as XX
One-time acct (One-Time Account) Select this checkbox to de ne the account group as a group that
is used for one-time customers.
PartnerDet.Proc. (Partner Determination Procedure) <Abbreviation for the partner determination procedure>, such as
AG (Sold-To Party)
4. Create a customer account (transaction XD01, VD01), and assign the account group to the customer. Make sure that you
have entered the order-relevant elds, such as incoterms, terms of payment, and tax classi cation.
SAP CRM: De ning One-Time Customer Accounts

Perform steps in SAP CRM to set up one-time customer accounts.
Procedure
1. De ne number ranges in the following Customizing activity (transaction SPRO): Cross-Application Components SAP
Business Partner Business Partner Basic Settings Number Ranges and Groupings De ne Number Ranges .
2. De ne groupings and assign number ranges to the groupings in the following Customizing activity (transaction SPRO): Cross-
Application Components SAP Business Partner Business Partner Basic Settings Number Ranges and Groupings De ne
3/5/2020
Groupings and Assign Number Ranges .
Field Name Value
Number range <External number range>, such as XX
Grouping De ne grouping, such as XXXX, and assign grouping to the

number range XX.
4. Using the transaction code CRMC_BUPA_CONSUM, replicate the SAP ERP reference customer to SAP CRM.
5. Once the reference customer is replicated to SAP CRM, maintain the same reference customer in Backoffice Administration
Cockpit.
Selecting and Con guring a Pricing Method

In the asynchronous order management scenario, you can use either synchronous pricing or pricing from SAP Commerce.
Synchronous pricing retrieves data directly from the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM). When a customer
places an order, SAP Commerce makes synchronous calls to the back end to determine product prices. When the order is completed,
SAP Commerce replicates the prices along with the sales order to the back end.
To use synchronous pricing, activate settings in Backoffice Administration Cockpit.
Pricing from SAP Commerce either originates there, or is replicated from an SAP back end. When a customer places a sales order,
discounts and taxes are calculated in SAP Commerce and replicated with the sales order to the back end.
To use pricing from SAP Commerce, rst ensure that the settings for synchronous pricing in Backoffice are deactivated. Then specify
condition types for item prices, payment, and shipping costs in Backoffice. For more information about condition types, see
Con guring Pricing from SAP Commerce: SAP Back End Settings.
Related Information
Con guring Pricing from SAP Commerce: SAP Back End Settings
Con guring Pricing from SAP Commerce: SAP Commerce Settings
Con guring Synchronous Pricing
Making Settings in Backoffice for Asynchronous Order Management
Backoffice Settings for Synchronous Pricing
Pricing Procedures
Con guring Pricing from SAP Commerce:

SAP Back End Settings
To replicate pricing from the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM), you rst set up a pricing procedure to de ne
pricing settings.
Context
For sales orders replicated from SAP Commerce, the following condition types are relevant and are considered in this example:
Net or gross prices for the item total

3/5/2020
Item tax: Already included in the item total for gross prices, but not included for net prices.
The name of the condition type for item tax is coded as a property of the implementation bean. If you use a condition type
other than MWST, or have more than one condition type for item taxes, enhance the coding delivered for asynchronous order
management. For more information on MWST, see saporderexchange Extension(SAP ERP) or sapcrmorderexchange Extension
(SAP CRM).
Item discounts (SAP S/4HANA or SAP ERP): The item discount is already included in the item total and only relevant for
statistical purposes.
Shipping costs
Payment costs (known as transaction costs in SAP S/4HANA or SAP ERP)
These condition types must be part of the pricing procedure that you de ne in Customizing for the SAP back end.
Procedure
Navigate to the following Customizing activity (transaction SPRO), and de ne the pricing procedure:
SAP S/4HANA or SAP ERP: Sales and Distribution Basic Functions Pricing Pricing Control De ne and Assign Pricing
Procedure
SAP CRM: Customer Relationship Management Basic Functions Pricing De ne Settings for Pricing Create Pricing
Procedure
Related Information
Pricing Procedures
Con guring Pricing from SAP Commerce:

SAP Commerce Settings
After setting up the pricing procedure in the SAP back end, input the names of the condition types in SAP Commerce.
Context
Enter the condition types for item price, transaction costs (valid only for SAP S/4HANA or SAP ERP), and delivery costs in the SAP
base store con guration. For more information, see Making Settings in Backoffice for Asynchronous Order Management.
SAP S/4HANA or SAP ERP: For the item discounts that have an identi er in SAP Commerce, you don't have to de ne a setting. If you
replicate discounts via the pricing interface from the SAP back end to SAP Commerce, the discounts in both systems have identical
names. For more information about replicating pricing information, see Replicating Pricing Data from the SAP Back End.
The following procedure is relevant for all SAP back-end integrations.
Procedure
1. In Backoffice, choose SAP Integration SAP Base Store Con guration . Click Search and double-click the desired entry in the
results list.
2. In the Editor - SAP Base Store Con guration, choose the Asynchronous Order Management tab and enter the settings.
Mapping for Pricing Components

3/5/2020
Condition mapping exists to allow you to replicate pricing data from SAP Commerce to the SAP back end (SAP S/4HANA, SAP ERP,
or SAP CRM).
Component in SAP Commerce Description How the Component is Mapped to its

Counterpart in the SAP Back End
Price Single Field Setting in Backoffice for SAP Base Store

Con guration on the Asynchronous Order
The item price can be a gross price or a net
Management tab.
price.
 Note
In an online store, you either use net
prices or gross prices. A mix of net and
gross prices is not supported when
integrating with the SAP back end.
Delivery Costs Header Setting in Backoffice for SAP Base Store

Con guration on the Asynchronous Order
Single Field
Management tab.
Transaction Costs (SAP S/4HANA or SAP Header Setting in Backoffice for SAP Base Store
ERP) Con guration on the Asynchronous Order
Single Field
Management tab.
Taxes The rst tax item in a list of tax items (either

in percent or as an absolute value) is mapped
to the MWST condition type.
Global Discounts (SAP S/4HANA or SAP Header

 Note
ERP)
List In this example, global discounts are not
mapped at all and are not replicated to
SAP Commerce.
Item Discounts (SAP S/4HANA or SAP ERP) Item Item discounts are written to the IDoc with
their SAP Commerce name. When item
List
discounts are replicated to SAP Commerce
from SAP S/4HANA or SAP ERP, they have
identical names in both systems.
Con guring Synchronous Pricing

To use synchronous pricing with asynchronous order management, make settings in the SAP back end (SAP S/4HANA, SAP ERP, or
SAP CRM).
Procedure
1. In the SAP back end, navigate to the following Customizing activity (transaction SPRO):
SAP S/4HANA or SAP ERP: Sales and Distribution Basic Functions Pricing Pricing Control De ne Condition Types
SAP CRM: Customer Relationship Management Basic Functions Pricing De ne Settings for Pricing Create
Condition Types
2. Select the Maintain Condition Types activity.
3. For the selected condition, make the following settings under Changes which can be made:
Mark the Item Condition eld so that conditions of this type are allowed to be entered in the document items.
In the Manual entries eld, enter C to state that a manual entry has priority.
3/5/2020
This priority indicates that the system does not check whether a condition record already exists in the back end.
4. In Backoffice Administration Cockpit, enter values for the attributes applicable to your SAP back end. For more information,
see Backoffice Settings for Synchronous Pricing.
Enabling Payment Methods

Perform steps in the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM) to enable payment methods for B2B and B2C scenarios
using asynchronous order management.
For asynchronous order management, the following payment methods mentioned are supported:
In a B2C scenario: payment by credit card via external secure payment provider
A customer places a sales order in SAP Commerce. The data is replicated to the SAP back end, where a sales order is created
automatically. Further processing (sales order ful llment), such as delivery and billing, takes place in SAP S/4HANA or SAP
ERP. In a B2C scenario when you pay by credit card, we assume that the payment is settled by an external secure payment
provider, such as Cybersource. The external secure payment provider performs the payment authorization, which means that
credit card information does not have to be stored in the SAP back end. This scenario avoids PCI compliance issues.
In the SAP back end, you con gure an additional credit card type for the external secure payment provider, and the credit card
settlement. For more information, see Con guring an Additional Credit Card Type for Payment and SAP S/4HANA or SAP ERP:
Con guring the Credit Card Settlement.
In a B2B scenario: payment by invoice (called account payment in SAP Commerce)
Implement other kinds of payment as required. For more information, see saporderexchange Extension or
sapcrmorderexchange Extension.
Con guring an Additional Credit Card Type for

Payment
Create additional credit card types for external secure payment providers.
Context
Maintain new payment card types in Customizing for the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM). If necessary, assign
a check routine to the new credit card type. The routine veri es the transferred payment card number according to the needs of the
payment provider. If it is necessary to decide between the different supported payment card types, do this for each payment card
type.
Procedure
SAP S/4HANA or SAP ERP: Sales and Distribution Billing Payment Cards Maintain Card Types, Maintain Card
Categories Maintain Payment Card Plan Types .
SAP CRM: Customer Relationship Management Basic Functions Payment Cards Basic Settings Maintain Payment
Card Types, Maintain Payment Card Category
2. Assign the Credit Card category to each newly created credit card type and assign a number range to it.
3. Maintain the Validity Period of Authorization for each newly created credit card type.
SAP S/4HANA or SAP ERP: Sales and Distribution Billing Payment Cards Authorization and Settlement Maintain
Clearing House Account Determination Assign G/L Accounts . Maintain the account determination for each newly
3/5/2020
created credit card type and assign G/L accounts on sales organization and card type level.
SAP CRM: Customer Relationship Management Basic Functions Payment Cards Payment Cards Setting for
Authorization Assign Merchant ID . Maintain the merchant ID determination for each newly created credit card type
and assign Merchant ID on sales organization and card type level.
SAP S/4HANA or SAP ERP: Con guring the

Credit Card Settlement
In SAP S/4HANA or SAP ERP, payments made using an additional credit card type are treated as though they were done for another
credit card company.
Context
Payment types are handled in the back end with tokenization. For more information, see
http://www.cybersource.com/resources/collateral/Resource_Center/whitepapers_and_reports/Payment_Tokenization_Overview.pdf
.
The token is a replacement for the credit card information that the payment service provider saves securely. By saving the token
instead of the credit card, merchants can avoid having to meet special security requirements or certi cations. The authorization step
of the payment process takes place in SAP Commerce. The corresponding payment settlement step takes place in the SAP back end.
The back end supports payment by credit card, but it does not support by default the payment token. The SAP back end allows the
settlement process to be adapted to speci c payment provider when you implement a function module that performs the actual
settlement.
 Note
To simulate the authorization of credit cards, use the CCARD_AUTH_SIMULATION function module. To simulate the settlement
of credit cards, use CCARD_SETTLEMENT_SIMULATION. These function modules are not intended for productive use. See SAP
Note 513449 for information about payment card processing (not to be used for implementation purposes). The contents of
the SAP Note are applicable to all supported back-end integration systems.
Procedure
1. Implement the function module that performs the settlement by navigating to the following Customizing activity (transaction
SPRO):
SAP S/4HANA or SAP ERP: Financial Accounting (New) Accounts Receivable and Accounts Payable Business
Transactions Payments with Payment Cards -> Assign G/L Account to Cash Clearing Account
2. Select the clock symbol of the Assign G/L Account to Cash Clearing Account customizing step. This action assigns the
general ledger (G/L) account that records open items per credit card type to a cash clearing account.
3. Select an entry and then select Details. Under Settlement control functions in the Settlement eld, enter the name of the
function module for the settlement.
4. Determine your chart of accounts using the following Customizing activity (transaction SPRO):
Financial Accounting (New) General Ledger Accounting (New) Master Data G/L Accounts Preparations Assign
Company Code to Chart of Accounts
Related Information
Supporting Data for Credit Card Settlement
Supporting Data for Credit Card Settlement

3/5/2020
Data replicated from SAP Commerce provides the necessary information to support the settlement in SAP S/4HANA or SAP ERP
within the E1BPCCARD segment of the SALESORDER_CREATEFROMDAT202 IDoc. The data is also available in the settlement
function module in the import parameter T_SETTAB (structure CCSET).
The data provided in E1BPCCARD includes the following:
CC_NUMBER: Contains the token (SubscriptionId in SAP Commerce terms) instead of the actual credit card number.
Corresponding eld in structure CCSET is CCNUM.
CC_TYPE: Contains a key for the payment service provider (instead of the actual credit card type). All information about the
credit card, including its type, is implicitly contained in the token. Corresponding eld in structure CCSET is CCINS.
AUTH_REFNO: Contains the authorization ID. The authorization ID corresponds to the request ID of the
PaymentTransaction object in SAP Commerce. This eld does not contain the original format of the authorization ID, in
case of Cybersource a 22 digit number, but an encoded version of it. To t into the CHAR 15 eld AUTH_REFNO the number is
converted into a base32-encoded number. The conversion is a special case to be taken into account when implementing this
function module for the settlement process. The authorization ID is the decimal representation of this eld.
CC_VALID_T: Valid To Date of the credit card
CC_NAME: Credit card owner
You can reconstruct the decimal representation of the authorization ID when invoking the settlement. See the following ABAP
program including a decoder class with methods for decoding a base32hex-encoded number according to RFC4648:
REPORT z_decode_authorization_id.
PARAMETERS input TYPE string.
CLASS lcl_decoder DEFINITION.
PUBLIC SECTION.
METHODS decode_base32 IMPORTING i_base32string TYPE string
RETURNING value(r_result) TYPE string.
ENDCLASS. "lcl_decoder DEFINITION
CLASS lcl_decoder IMPLEMENTATION.
METHOD decode_base32.
FIELD-SYMBOLS <digit_as_bytes> TYPE x.
DATA l_idx TYPE i.
DATA l_dec TYPE p LENGTH 16 DECIMALS 0.
DATA l_uppercasestring LIKE i_base32string.
DATA l_base32digit TYPE i.
DATA l_digit TYPE c LENGTH 1.
l_uppercasestring = i_base32string.
TRANSLATE l_uppercasestring TO UPPER CASE.
DO strlen( l_uppercasestring ) TIMES.
l_digit = l_uppercasestring+l_idx(1).
ASSIGN l_digit TO <digit_as_bytes> CASTING.
l_base32digit = <digit_as_bytes> / 256 - 48. " Unicode -> ASCII Coding 0..9
IF l_base32digit > 9.
l_base32digit = l_base32digit - 7. " ASCII Coding A..Z
ENDIF.
l_dec = l_dec * 32 + l_base32digit.
ADD 1 TO l_idx.
ENDDO.
r_result = l_dec.
ENDMETHOD. "decode_base32
ENDCLASS. "lcl_decoder IMPLEMENTATION
START-OF-SELECTION.
DATA go_decoder TYPE REF TO lcl_decoder.
DATA g_result TYPE string.
CREATE OBJECT go_decoder.
g_result = go_decoder->decode_base32( input ).
WRITE: 'Result:' , g_result.
You can nd the request ID (authorization ID) in SAP Commerce as follows:
1. In Backoffice Administration Cockpit, choose Order Orders and search for the orders. In the Results list, double-click an
order.
2. Choose Administration. Under Unbound Payment transactions , double-click a payment transaction and nd the request ID
listed under Unbound.
3/5/2020
You can nd the subscription ID (credit card token) in SAP Commerce as follows:
1. In Backoffice Administration Cockpit, choose Order Orders and search for the orders. In the Results list, double-click an
order.
2. Choose Administration. Under Unbound Payment transactions, double-click a payment transaction. Under Entries, double-
click one of the entries, and under Unbound you can nd the subscription ID.
SAP CRM: Con guring the Credit Card

In SAP CRM, payments made using an additional credit card type are treated as though they were done for another credit card
company.
Context
Payment types are handled in the back end by means of tokenization. For more information, see
http://www.cybersource.com/resources/collateral/Resource_Center/whitepapers_and_reports/Payment_Tokenization_Overview.pdf
).
The token is a replacement for the credit card information that the payment service provider saves securely. By saving the token
instead of the credit card, merchants can avoid having to meet special security requirements or certi cations. The authorization step
of the payment process takes place in SAP Commerce.
 Note
If you want to simulate the authorization and settlement of credit cards, you can use the CCARD_AUTH_SIMULATION function
module for authorization. This is only meant as an example and is not intended for productive use. See SAP Note 513449 for
information about payment card processing. Note that the above mentioned SAP Note is for information only and not for
implementation.
The replicated data from SAP Commerce provides the necessary information to support the payment card info in SAP CRM within the
E101CRMXIF_PAYPLAN_D segment of the CRMXIF_ORDER_SAVE_M01 IDoc. The data provided in E101CRMXIF_PAYPLAN_D
includes the following:
CARD_NO: Contains the token (known as the Subscription ID in SAP Commerce) instead of the actual credit card number
CARD_TYPE: Contains a key for the payment service provider (instead of the actual credit card type)
AUTH_REF: Contains the authorization ID. The authorization ID corresponds to the request ID of the
PaymentTransaction object in SAP Commerce
CARD_EXP_DATE: Valid to Date of the credit card
CARD_HOLDER: Credit card owner
Procedure
1. Implement the function module that performs the settlement by navigating to the following Customizing activity (transaction
SPRO):
SAP CRM: SAP Customizing Implementation Guide Customer Relationship Management Basic
Functions Payment Cards Setting for Authorization Determine Authorization Module
2. To nd the request ID (authorization ID) in SAP Commerce perform the following:
a. Log in to Backoffice Administration Cockpit using this link: http:// <server>:<port>

/backoffice/hybris
a. Choose Order Orders and search for the orders. In the Results list, doubleclick an order.
3/5/2020
a. Choose Administration. Under Unbound Payment transactions , doubleclick a payment transaction and nd the
request ID listed under Unbound.
3. To nd the subscription ID (credit card token) in SAP Commerce perform the following:
a. Log in to Backoffice Administration Cockpit using this link: http:// <server>:<port>

/backoffice/hybris
a. Choose Order Orders and search for the orders. In the Results list, doubleclick an order.
a. Choose Administration. Under Unbound Payment transactions , doubleclick a payment transaction. Under Entries,
double-click one of the entries, and under Unbound you can nd the subscription ID.

Con gure output control for IDoc types representing sales orders and sale order con rmations. By con guring these controls,
updates to sales order statuses are replicated from the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM) to SAP Commerce.
The procedures outlined here are for a scenario in which sales orders are created in SAP Commerce and replicated to the SAP back
end. Once replication is complete, the sales order ful llment process, including delivery and goods issue, is carried out in SAP
S/4HANA or SAP ERP. With SAP Commerce connected to an SAP back end, we recommend designating the back end as the leading
system for changes to sales orders.
Before starting the procedures for con guring output control for sales order con rmations, de ne the following:
RFC destination to Data Hub
Port
Logical system
Partner pro le
Related Information
Con guring Basic Settings for Data Replication
SAP S/4HANA or SAP ERP: Con guring Output Control for Sales Order Con rmations
SAP CRM: Con guring Output Control for Sales Order Con rmations
SAP S/4HANA or SAP ERP: Con guring

Con gure output control for sales order con rmations by maintaining output determination for sales documents, and de ning a
condition record and distribution model.
Maintaining Output Determination for Sales Documents

To maintain output determination for sales documents, you maintain output types, maintain output determination
procedures, and assign output determination procedures.
De ning a Condition Record
For the order type (sales document type) representing sales orders that originate in SAP Commerce, an order con rmation is
triggered. For order type ZTAH, for example, order con rmation ZBAH is triggered. Create a condition record for the order type
representing sales orders that originate in SAP Commerce to trigger order con rmations.
De ning a Distribution Model
De ne a distribution model as part of the process for con guring output control for IDoc types representing sales orders and
sale order con rmations.
Example Code for Output Type Order Con rmation
3/5/2020
This document provides example code (example program name ZCHECK_CHANGE_MESSAGE) for the output type order
con rmation.
Related Information
SAP S/4HANA or SAP ERP: Maintaining Output Control for Outbound Deliveries and Goods Issues
SAP S/4HANA or SAP ERP: Data Integration Flow of Sales Orders
Message Control
Maintaining Output Determination for Sales

Documents
To maintain output determination for sales documents, you maintain output types, maintain output determination procedures, and
assign output determination procedures.
Context
Perform all the following procedures in Customizing (transaction SPRO) for SAP S/4HANA or SAP ERP, under Sales and Distribution
(SD) Basic Functions Output Control Output Determination Output Determination Using the Condition Technique Maintain
Output Determination for Sales Documents .
Maintaining Output Types

Maintain output types as part of the process for output determination for sales documents.
Procedure
1. In Customizing for SAP S/4HANA or SAP ERP, go to Sales and Distribution (SD) Basic Functions Output Control Output
Determination Output Determination Using the Condition Technique Maintain Output Determination for Sales
Documents Maintain Output Types .
2. Select Change, and then select output type BA00 (Order Con rmation) and copy as ZBAH, for example. In General data,
enter the following values:
Field Name Value
Access to conditions Select this eld to ensure that the system determines the output
by searching for valid condition records.
Multiple Issuing Select this eld to ensure that the system can resend the same
output to the same partner multiple times.
3/5/2020
Field Name Value
Change Output Program Create the program with transaction SE38, for example
ZCHECK_CHANGE_MESSAGE. For more information about the
example code for this program, see Example Code for Output
Type Order Con rmation.
The program ZCHECK_CHANGE_MESSAGE ensures that an IDoc

of type ORDERS05 is sent again to SAP Commerce only if each
item contains a rejection reason. This rejection reason has to be
the same for each of the sales order items, which only happens in
the following cases:
After canceling an order in the back end.
After canceling an order in SAP Commerce, at which point

an IDoc of type ORDERS05 is sent to the back end that
cancels the order.
If you do not enter a program name, the system resends the

ORDERS05 IDoc to SAP Commerce whenever a sales order is
changed.
Form routine CHECK_MESSAGE_NECESSARY
3. In Processing routines, enter the following values:
Field Name Value
Application V1
Medium Distribution (ALE)
Program RSNASTED
Form routine ALE_PROCESSING
4. In Partner functions, enter the following values:
Field Name Medium
Funct (Function) SP
Name Sold-to party
Maintaining Output Determination Procedures

Maintain output determination procedures as part of the process for output determination for sales documents.
Procedure
1. In Customizing for SAP S/4HANA or SAP ERP, go to Assign Output Determination Procedures Allocate sales document
header Change New Entries Maintain Output Determination Procedure .
2. Select V10000, Order Output and Control Data. Choose New Entries and enter the following values:
3/5/2020
Field Name Value
Step 60 for example
Counter 1
CTyp (Condition Type) ZBAH (order con rmation) for example
Requirement 2 (order con rmation)
Assigning Output Determination Procedures

Assign output determination procedures as part of the process for output determination for sales documents.
Procedure
1. In Customizing for SAP S/4HANA or SAP ERP, go to Assign Output Determination Procedures Allocate sales document
header Change New Entries .
2. Enter the following values:
Field Name Values
SaTy (Sales Type) ZTAH (order con rmation)
Out.pr (Output determination procedure) V10000 (order output)
Output Type ZBAH (order con rmation)

For the order type (sales document type) representing sales orders that originate in SAP Commerce, an order con rmation is
triggered. For order type ZTAH, for example, order con rmation ZBAH is triggered. Create a condition record for the order type
representing sales orders that originate in SAP Commerce to trigger order con rmations.
Procedure
1. In SAP S/4HANA or SAP ERP, call transaction NACE.
2. For Application, select V1 (Sales) and choose Condition records.
3. Choose Condition records again, then output type ZBAH and Condition records.
4. Choose Execute and enter the following values:
Field Name Value
SalesDocTy (Sales Document Type) ZTAH (standard order)
Funct ( Partner Function) SP (sold-to party)
Medium A (distribution (ALE))
Date/Time 4 (send immediately (when saving the application))
3/5/2020

De ne a distribution model as part of the process for con guring output control for IDoc types representing sales orders and sale
order con rmations.
Procedure
1. In Customizing for SAP S/4HANA or SAP ERP, go to SAP NetWeaver Application Server IDoc Interface / Application Link
Enabling (ALE) Modelling and Implementing Business Processes Maintain Distribution Model and Distribute Views .
2. Choose Change, then Create Model View, and then enter the following values:
Field Name Value
Short text <Short text of the distribution model>
Technical name <Technical name of the distribution model>
3. Select the distribution model you just created, then choose Add Message Type and enter the following values:
Field Name Value
Sender <Sending System>
Receiver <Receiving System>
Message Type ORDERS
Example Code for Output Type Order

Con rmation
This document provides example code (example program name ZCHECK_CHANGE_MESSAGE) for the output type order
con rmation.
For more information about what happens when you execute the code, see Output Control for Sales Order Con rmations.
Example Code: ZCHECK_CHANGE_MESSAGE

The following example code shows how you could con gure the output program to ensure that the system only resends an IDoc of
type ORDERS05 when an order is canceled in either the SAP back end (SAP S/4HANA or SAP ERP) or SAP Commerce. By
implementing code such as this, you can prevent the system from resending an IDoc to SAP Commerce every time an order is
modi ed.
 Sample Code
*&---------------------------------------------------------------------
*& Report ZCHECK_CHANGE_MESSAGE
*&
*&---------------------------------------------------------------------
*&
*&
3/5/2020
*&---------------------------------------------------------------------
REPORT zcheck_change_message.
TYPES: t_vbapvb TYPE STANDARD TABLE OF vbapvb.
TYPES: t_vbpavb TYPE STANDARD TABLE OF vbpavb.
*&---------------------------------------------------------------------
*& Form check_message_necessary
*&---------------------------------------------------------------------
* text----------------------------------------------------------------------
FORM check_message_necessary.
DATA: lv_subrc TYPE i.
FIELD-SYMBOLS: <xvbap_t> TYPE t_vbapvb.
FIELD-SYMBOLS: <yvbap_t> TYPE t_vbapvb.
* Initialize: do not send changed output (lv_subrc = 4).

lv_subrc = 4.
* Access item data table in SAMPV45A.

* XVBAP is the new state after saving.
ASSIGN ('(SAPMV45A)XVBAP[]') TO <xvbap_t>.
ASSERT sy-subrc = 0.
* YVBAP is the old state before saving.

ASSIGN ('(SAPMV45A)YVBAP[]') TO <yvbap_t>.
ASSERT sy-subrc = 0.
PERFORM check_all_items_cancelled USING <xvbap_t> <yvbap_t>

CHANGING lv_subrc.
* Take result.
sy-subrc = lv_subrc.
ENDFORM. "check_message_necessary
*&---------------------------------------------------------------------
*& Form CHECK_ALL_ITEMS_CANCELLED
*&---------------------------------------------------------------------
* text----------------------------------------------------------------------
* <--PV_SUBRC text----------------------------------------------------------------------
FORM check_all_items_cancelled USING pt_xvbap TYPE t_vbapvb
pt_yvbap TYPE t_vbapvb
CHANGING pv_subrc TYPE i.
DATA: lv_abgru TYPE abgru.
FIELD-SYMBOLS: <xvbap> TYPE vbapvb.
FIELD-SYMBOLS: <yvbap> TYPE vbapvb.
IF pt_xvbap IS INITIAL OR pt_yvbap IS INITIAL.
EXIT.
ENDIF.
pv_subrc = 0.
* Check whether an item has been rejected in this session.

LOOP AT pt_xvbap ASSIGNING <xvbap>.
READ TABLE pt_yvbap ASSIGNING <yvbap> WITH KEY posnr = <xvbap>-posnr BINARY SEARCH.
* Send message only if abgru filled in all items.

IF <xvbap>-abgru IS INITIAL.
pv_subrc = 4.
EXIT.
ENDIF.
* Send message only if the same abgru is in all items.

IF lv_abgru IS NOT INITIAL AND lv_abgru NE <xvbap>-abgru.
pv_subrc = 4.
EXIT.
ENDIF.
lv_abgru = <xvbap>-abgru.
IF <yvbap> IS ASSIGNED.
IF <yvbap>-abgru IS NOT INITIAL.
pv_subrc = 4.
EXIT.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM. "CHECK_ALL_ITEMS_CANCELLED
3/5/2020
SAP CRM: Con guring Output Control for

Sales Order Con rmations
Con gure output control for the IDoc type representing sales orders or sales order con rmations. This is required when a sales order
status is updated, and the status change needs to be replicated from SAP CRM to SAP Commerce.
Prerequisites
You have de ned an RFC destination to Data Hub, a port, logical system, and a partner pro le as described in Con guring Basic
Settings for Data Replication.
Context
The procedure outlined here is for a scenario in which sales orders are created in SAP Commerce and replicated to SAP CRM, and in
which the sales order ful llment process, including delivery and goods issue, is carried out in the SAP ERP system. With SAP
Commerce connected to SAP CRM, we recommend that SAP CRM be the leading system for changes to sales orders.
Procedure
SAP CRM sends the outbound IDocs CRMXIF_ORDER_SAVE_M to SAP Commerce for con rmation.
Message Type CRMXIF_ORDER_SAVE_M
Basic Type CRMXIF_ORDER_SAVE_M01
SAP S/4HANA or SAP ERP: Maintaining

Output Control for Outbound Deliveries and
Goods Issues
Con gure output control for IDoc types representing deliveries and goods issues so that when a sales order status is updated, the
change is replicated from SAP S/4HANA or SAP ERP to SAP Commerce.
The procedures outlined here are for a scenario in which sales orders are created in SAP Commerce and replicated to the SAP back
end, and in which the sales order ful llment process, including delivery and goods issue, is carried out in the back end. With SAP
Commerce connected to the SAP back end, we recommend that the back end be the leading system for changes to sales orders.
Prerequisites
You have de ned an RFC destination to Data Hub, a port, logical system, and a partner pro le as described in Con guring Basic
Settings for Data Replication.
Maintaining Output Determination for Outbound Deliveries

The procedures in this section are all performed in the following Customizing activity (transaction SPRO):
Logistics Execution Shipping Basic Shipping Functions Output Control Output Determination Maintain Output
Determination for Outbound Deliveries
Maintaining Output Types for Deliveries and Goods Issues
3/5/2020
Do the following in SAP S/4HANA or SAP ERP:
1. Follow the Customizing navigation path provided above and choose Maintain Output Types. Choose Change, select output
type LD00 (Delivery Note), and copy as ZLDH and ZLDW, for example. In Processing routines, enter the following values:
Field Name Value
Application V2
Program RSNASTED
Form routine ALE_PROCESSING
2. In Partner functions, enter the following values:
Field Name Value
Funct (Partner Function) SP
Name Sold-to party
Maintaining Output Determination Procedures
1. Choose Maintain Output Determination Procedure and select V10000 Header Output and Control Data. Choose New
Entries and enter the following values:
Field Name Value
Step 230 for example 240
Counter 0 0
CTyp (Condition Type) ZLDH (Delivery Note) for example ZLDW (Delivery Note) for example
Requirement 1 (Delivery Goods Issue Posted)
Assigning Output Determination Procedures
1. Choose Assign Output Determination Procedures Assign deliveries (header) . Choose Change and New Entries. Enter the
following values:
Field Name Value
DlvTy (Delivery Type) <Delivery type that you are using>, such as LF for outbound
delivery
Out.pr (Output Determination Procedure) V10000 (Output procedure)
Output Type LD00 (Delivery note)
3/5/2020

In this step, you create condition records for both condition types created before, for example ZLDH and ZLDW. For condition type
ZLDH, an IDoc is sent as soon as the delivery has been created, and for condition type ZLDW, an IDoc is sent as soon as a goods issue
is posted.
1. Launch Conditions for Output Control (transaction NACE).
2. For Application, select V2 (Shipping) and choose Condition records.
3. Choose Condition records again and choose the output type, such as ZLDH and ZLDW. Enter the following values for each
sales organization:
Field Name Value
SalesOrg (Sales Organization) <Sales organization>, such as 1000
Funct (Partner Function) SP (Sold-to party)
Medium A (Distribution (ALE))
Date/Time 4 (Send immediately (when saving the application))

1. Navigate to the following Customizing activity:
SAP NetWeaver Application Server IDoc Interface / Application Link Enabling (ALE) Modeling and Implementing
Business Processes Maintain Distribution Model and Distribute Views . Alternatively you can call transaction SALE.
2. Choose Change, then Create Model View, and enter the following values:
Field Name Value
Short text <Short text of the distribution model>
Logical system <Technical name of the distribution model>
3. Select the distribution model you just created, then choose Add Message Type, and enter the following values:
Field Name Value
Sender <Sending system>
Receiver <Receiving system>
Message Type DELINF
Related Information
Message Control
3/5/2020
Making Settings in Backoffice for

Make settings in Backoffice Administration Cockpit to replicate sales order data between SAP Commerce and the SAP back end (SAP
S/4HANA, SAP ERP, or SAP CRM).
Prerequisites
Made settings on the Common Settings tab as described in Common Settings in Backoffice for SAP Integrations
Created an HTTP destination for the SAP back end as described in Setting RFC Destinations and HTTP Destinations
Con gured an SAP base store con guration as described in De ning an SAP Base Store and Global Con guration
Related Information
Setting Up Local Properties

Before making settings in Backoffice Administration Cockpit for asynchronous order management, make entries in the
local.properties le.
Procedure
1. Maintain the following entries in the local.properties le located in the con guration folder of the SAP Commerce
installation:
# Cache size for order code number series. Larger values mean less DB access, but more order Ids ar
numberseries.cache.size.order_code=100
# Start value for the Order ID. Must correspond to number ranges maintained in SAP ERP
keygen.order.code.start=<TBD>
#Enable Data Hub based integration

sapcoreconfiguration.datahuboutbound.enabled=true
datahubadapter.datahuboutbound.url=http://localhost:8080/datahub-webapp/v1
2. Set a start value for the order code according to the number range maintained in the SAP back end.
A change of the property keygen.order.code.start only becomes effective if the corresponding number series is reset.
For more information, see saporderexchange Extension or sapcrmorderexchange Extension.
Con guring the SAP Base Store for

After setting up local properties, con gure settings in the Base Store tab.
Context
3/5/2020
Make these settings in addition to the general settings described in De ning an SAP Base Store and Global Con guration.
Procedure
1. In Backoffice Administration Cockpit, choose Base Commerce Base Store .
2. Select the relevant base store.
3. In the editor, choose the Properties tab.
4. In the Submit order process code eld, enter the value sap-order-process.
5. If the SAP Con guration eld is empty, create a new SAP base store con guration via the context menu and assign a name to
it. Otherwise choose Edit from the context menu.
6. In the editor for the SAP base store con guration, make the following entries on the Common Settings tab:
Field Name Value
Order Type <Order type>, such as ZTAH or TA
Reference Customer <One-time customer>
Sales Organization <Sales Organization>, such as 1000 or O 50000001
Sales Organization Responsible (SAP CRM only) <Sales Organization Responsible>, such as O 50061093
Distribution Channel <Distribution Channel>, such as 10 or 14
Division <Division>, such as 00
7. On the same tab, maintain the table of delivery modes for SAP Commerce with the corresponding SAP shipping conditions.
Each entry can be created via the Create context menu function:
Field Name Value
Delivery Mode <Delivery mode>, such as premium-gross
Delivery Value <SAP shipping condition>, such as 01
8. If you are not using synchronous pricing anywhere in the online store, make entries under Pricing Conditions for Sales Orders
in the Asynchronous Order Management tab. For more information, see Mapping Price and Cost Values.
Mapping Price and Cost Values

Map price components to condition types in the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM). Mapping makes it possible
for price components to be replicated with sales orders from SAP Commerce, through Data Hub, to the SAP back end.
Context
The following settings are relevant when using pricing from SAP Commerce with asynchronous order management.
Procedure
1. Under SAP Integration SAP Base Store Con guration Asynchronous Order Management enter the following values:
Setting Description
3/5/2020
Setting Description
Item Price The condition type for the item price that represents the gross or
net price of a product
Example in SAP S/4HANA or SAP ERP: PB00
Example in SAP CRM: ZPR
Payment Costs The condition type for the transaction costs (payment costs)
Example in SAP S/4HANA or SAP ERP: ZPAY
Example in SAP CRM: ZPAY
Shipping Costs The condition type for the shipping costs

Example in SAP S/4HANA or SAP ERP: ZSHN
Example in SAP CRM: 0KF0
 Note
Include each condition type that you specify in the pricing procedure used in the back end. You de ne the condition types
in the following Customizing activity:
SAP S/4HANA or SAP ERP: Sales and Distribution Basic Functions Pricing Pricing Control De ne Condition
Types
SAP CRM: Customer Relationship Management Basic Functions Pricing De ne Settings for Pricing Create
Condition Types
2. Ensure that the Synchronous Pricing for Orders setting on the Pricing tab is deactivated.
This setting is only applicable if your scenario uses synchronous pricing. For more information, see Backoffice Settings for
Synchronous Pricing.
Using SAP Customer Data in the B2C

Scenario
To ensure that consumer data from the SAP back end is replicated with sales orders, set the Replicate Registered Users setting in
Backoffice Administration Cockpit.
Procedure
1. In Backoffice, navigate to SAP Integration SAP Global Con guration Customer Replication .
2. Activate the Replicate Registered Users setting.
If you don't activate the setting, the ID of the one-time customer (entered in Reference Customer under Common Settings) is
transferred with the sales order.
Related Information
B2C Scenario: Consumer Replication
Transferring the Con guration to Data Hub

3/5/2020
Con guration settings you make in Backoffice Administration Cockpit are transferred automatically to Data Hub. In case of issues, for
example if Data Hub was started after Backoffice con guration took place, transfer the con guration manually.
Procedure
1. In Backoffice, choose SAP Integration SAP Administration Con guration .
2. Click the Send to Data Hub icon.
If the Send to Data Hub icon is inactive, generate an instance of the SAP Administration. You do this in Backoffice under
System Types .
Results
The con guration is transferred to Data Hub.
Con guring Data Hub for Asynchronous

Order Management
Make entries in the local.properties le in Data Hub to replicate sales orders asynchronously from SAP Commerce through
Data Hub to the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM).
The con guration of Data Hub mainly takes place via Java properties. The properties are maintained in the local.properties le
located in the classpath of Data Hub. A possible location is in the WEB-INF/classes folder of the Data Hub Web application.
The following example from SAP ERP provides an example of entries you could make in Data Hub local.properties file for
asynchronous order management:
#Hybris Core
targetsystem.hybriscore.url=http://localhost:9001/datahubadapter
targetsystem.hybriscore.username=admin
targetsystem.hybriscore.password=<password>
#sapidocoutboundadapter settings, defining logical sender system DATAHUB using sender port DHUB_PORT -> m
sapidocoutboundadapter.senderport=DHUB_PORT
sapidocoutboundadapter.sendername=DATAHUB
#enable automatic composition & publication, 5000ms interval

sapcoreconfiguration.autocompose.pools=SAPORDER_OUTBOUND_POOL,SAPORDER_INBOUND_POOL,SAPCONFIGURATION_POO
sapcoreconfiguration.autopublish.targetsystemsbypools=SAPORDER_INBOUND_POOL.HybrisCore,SAPORDER_OUTBOUND_
sapcoreconfiguration.autopublish.sleeptime=5000
sapcoreconfiguration.autopublish.initialsleeptime=5000
#Pool holding SAP configuration settings
sapcoreconfiguration.pool=SAPCONFIGURATION_POOL
3/5/2020
# Enable dynamic offset for IDoc numbers - deactivate in case of a persistent DB!
sapidocoutboundadapter.usedynamicidocnumberoffset=true
 Note
You have completed the last mandatory step in the con guration process. From here, you can map order cancellation reasons
between systems, set up clean-up cron jobs, and con gure SAP credit checks. For more information, see Mapping Reasons for
Canceled Sales Orders, Clean-Up Cron Jobs for Asynchronous Order Replication, and SAP Credit Checks for B2B Scenarios.
Mapping Reasons for Canceled Sales Orders

You can cancel a sales order either in SAP Commerce or in the SAP back end (SAP S/4HANA, SAP ERP, or SAP CRM). You map
reasons for sales order cancellations so that they are replicated with the sales orders from one system to the other.
A default implementation is delivered that you can use to map cancel reasons for both systems.
The following table shows the available cancel reasons:
SAP Commerce SAP Back End
OutOfStock Assigned by the System (Internal)
LateDelivery Delivery date too late
Warehouse Poor quality
CustomerRequest Too expensive
Other Competitor better
NA Guarantee
In SAP Commerce, these are called cancel reasons, and you can nd Unreasonable request
them in the basecommerce extension as value codes.
Cust.to receive replacement
Transaction is being checked
In the back end, these are called rejection reasons, and they are
delivered with the standard SAP system. You can con gure the
rejection reasons in the following Customizing activity (transaction
SPRO):
SAP S/4HANA or SAP ERP: Sales and

Distribution Sales Sales Documents Sales Document
Item De ne Reasons For Rejection
SAP CRM: Customer Relationship

Management Transactions Settings for Sales
Transactions De ne Reasons For Rejection .
In the saporder Data Hub extension, under com.hybris.datahub.saporder.publication, the mapping is handled by the
SpEL expression <expression spel></expression>. For example,
<expression spel="true">#root.getField('E1EDP01-ABGRU') == null ? null : '01'.equals(#root.getField('E1ED
3/5/2020
In the sapcrmorder Data Hub extension, the mapping is handled by
DefaultCrmCompositionHandlerOrderCancelNotification, which is de ned in sapcrmorder-raw-datahub-
extension-spring.xml with the alias sapCrmCompositionHandlerOrderCancelNotification.
Related Information
saporder Data Hub Extensions
sapcrmorder Data Hub Extension
Clean-Up Cron Jobs for Asynchronous Order

Replication
Use cron jobs to resend sales orders and sales order cancellations that are not yet replicated to the SAP back end (SAP S/4HANA,
SAP ERP, or SAP CRM).
For more information, see the following:
Using sapOrderexchangeRepairCronJob
Using sapOrderexchangeCancelRepairCronJob
Using sapOrderexchangeRepairCronJob
Use this cron job to resend sales orders that have not yet been replicated from SAP Commerce to the SAP back end.
Context
Use this cron job to resend sales orders that have not yet been replicated from SAP Commerce to the SAP back end.
The system automatically tries, after a speci ed time interval, to resend sales order requests from SAP Commerce to the back end,
using IDocs. If the maximum number of retries is exhausted, you can execute this cron job manually or schedule it to run regularly. A
cron job might be necessary, for example, after a downtime of the back end due to regularly scheduled service intervals.
By default, this cron job is executed once a day at midnight.
Procedure
1. In Backoffice Administration Cockpit, choose System Background Processes CronJobs .
2. For Jobname choose equals as Comparator from the dropdown list, enter sapOrderexchangeRepairCronJob, and
choose Search.
3. Select sapOrderexchangeRepairCronJob from the Results list.
4. To start the cron job immediately, choose Run CronJob.
5. To schedule the cron job, choose Time Schedule and click Create new Trigger to specify when the cron job should be
executed.
Retry Parameters
Maintain parameters for the minimum retry delay and the maximum number of retries for sending sales order requests to the back
end.
3/5/2020
In the config.properties le of the ysaporderfulfillment extension, modify the following parameters as required:
saporderexchange.orderoutbound.retryDelay=60000 in ms (milliseconds)
saporderexchange.orderoutbound.maxRetries=10
Using
sapOrderexchangeCancelRepairCronJob
Use this cron job to resend sales order cancellations that have not yet been replicated from SAP Commerce to the SAP back end.
Context
The system automatically tries, after a speci ed time interval, to resend sales order cancellation requests from SAP Commerce to the
back end, using IDocs. If the maximum number of retries is exhausted, you can execute this cron job manually or schedule it to run
regularly. This cron job might be necessary, for example, after a downtime of the back end due to regularly scheduled service
intervals.
The sales order cancellation is processed independently of the business process of creating sales orders. Some of the business
process instances might still have status Waiting even though the sales order has been canceled. Use this cron job to restore these
running business process instances, and set their status to Complete, and the order status to Canceled.
We recommend that you schedule this cron job to run once a day, which is also set by default.
If expecting a high number of sales order cancellations, or frequent system downtime, you can schedule the cron job to be executed
several times a day. You only need this cron job if you allow sales order cancellations..
Procedure
1. In Backoffice Administration Cockpit, choose System Background Processes CronJobs .
2. For Jobname, choose equals as Comparator from the dropdown list, enter sapOrderexchangeCancelRepairCronJob,
and choose Search.
3. Double-click sapOrderexchangeCancelRepairCronJob in the Results list.
4. To start the cron job immediately, choose Run CronJob.
5. To schedule the cron job, choose Time Schedule and click Create new Trigger to specify when the cron job should be
executed.
Cancel Parameters
Set parameters to de ne how long a sales order can have the Canceling status until it's set back to its previous status. The default is
60 minutes.
In the project.properties le of the ysaporderfulfillment extension, maintain the

ysaporderfulfillment.repair.job.cancel.minutes parameters as required:
saporderexchange.orderoutbound.retryDelay=60000 in ms (milliseconds)
saporderexchange.orderoutbound.maxRetries=10
3/5/2020
SAP S/4HANA or SAP ERP: Replicating

Promotion Discounts from SAP Commerce
Leverage the bene ts of Promotion Engine by replicating promotion discounts created in SAP Commerce to the SAP back end (SAP
S/4HANA, SAP ERP).
In an asynchronous order management scenario, you can create a marketing promotion in SAP Commerce that provides detailed
information to shoppers in the product details, cart, and checkout pages. These discounts can then be replicated to the SAP back
end.
You can replicate the following promotion discount types to the SAP back end:
Order threshold percentage discount on cart
Order threshold xed discount on cart
Product/category percentage discount
Product xed price
For more information about the promotion types, see Promotion Types and Templates.
To replicate promotion discounts to the SAP back end, do the following:
1. In the SAP back end, navigate to the following Customizing activity (transaction SPRO): Sales and Distribution Basic
Functions Pricing Pricing Control De ne and Assign Pricing Procedures .
2. Assign a condition type to your pricing procedure. For example:
HA00: Applies a percentage discount to the gross total of an order.
HB00: Applies a xed discount to an order.
KA02: Applies a percentage discount to an item in an order.
RB00: Applies a xed discount to an item in an order.
Use a condition type that has either calculation type A (percentage) or B ( xed amount). For more information about pricing
procedures, see the documentation under Pricing and Conditions in the SAP Help Portal.
3. In SAP Commerce, deploy the promotionengineservices and ruleengineservices extensions.
For more information about the extensions, see the extensions and dependencies topics for Promotion Engine and Rule
Engine.
4. When creating promotion rules in Backoffice Administration Cockpit, navigate to Marketing Promotion Rules and select the
Rule Properties tab.
5. In the SAP Condition Type eld, enter the condition type that you assigned to the pricing procedure in the SAP back end.
 Note
Promotion discount replication and synchronous pricing cannot be used within the same deployment.

Asychronisation OM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asychronisation OM

Uploaded by

Copyright:

Available Formats

3/5/2020

Integrations and Data Management

SAP Commerce | 1905

Original content: https://help.sap.com/viewer/50c996852b32456c96d3161a95544cdb/1905/en-US

For more information, please visit the https://help.sap.com/viewer/disclaimer.

SAP Back-End Integration: SAP S/4HANA,

About the SAP Back-End Integration

Feature Description Available With More Information

Feature Description Available With More Information

Asynchronous order Developed for B2B and B2C

Synchronous pricing Use synchronous pricing to SAP Synchronous Pricing Module

SAP invoices Allow B2B customers in the SAP Invoice Module

Service request management Replicate service requests Service Request Management

Complaint Management Replicate complaints between Complaints Management

Feature Description Available With More Information

Product registration Enables customers to register Product Registration

Return orders Enables integration of return SAP Return Order Features

About the SAP Back-End Integration Documentation

Integration Using SAP Cloud Platform Integration Module

Asynchronous Order Management Module

Features Architecture Implementation

About Integrating Order Management Services Asynchronous OM Asynchronous OM

Understanding Data Flows in Asynchronous Order

Using Cart & Checkout with AOM

Using Order Management for SAP Commerce with AOM

SAP Return Order Features

About Integrating Order Management Services

About Integrating Order Management

Functionality in Asynchronous Order

With SAP CRM integration, customers can add standard products to

To replicate sales orders placed by guest users (users not registered

As a prerequisite, deactivate the settings for synchronous pricing in

As a prerequisite, activate the settings for synchronous pricing in

In an asynchronous order management scenario, you can create a

1. Log in to the Web UI with SALESPRO business role.

2. In the WorkCentre, choose Sales Cycle Sales Orders .

4. Open the order.

5. Edit the order to ll the Rejection Reason eld, for example

The order header status is displayed as "Fully Rejected" in the

6. Save the order.

The order is canceled in SAP CRM. After the order

Functions Not Supported with Asynchronous Order Management

System Non-Supported Functions

System Non-Supported Functions

Order changes in SAP Commerce are not replicated to the

Canceling orders on item level

Only entire sales orders can be canceled.

Credit card payment in B2B

SAP S/4HANA or SAP ERP

Canceling orders on item level

Only entire sales orders can be canceled.

Manual product substitution

Sales order split

Only complete order delivery is supported, unless integrating

Sales order schedule lines

Con gurable products

Canceling orders on item level

Only entire sales orders can be canceled.

Manual product substitution

Sales order split

Only complete order delivery is supported.

Sales order schedule lines

Understanding Data Flows in Asynchronous