Asychronisation OM
Asychronisation OM
Asychronisation OM
PUBLIC
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 1/94
3/5/2020
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).
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:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 2/94
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
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 3/94
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
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 4/94
3/5/2020
Related Information
System Requirements for SAP Integrations
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 5/94
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.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 6/94
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.
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.
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).
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 7/94
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).
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 8/94
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).
Order cancellation in SAP CRM Web UI You can also cancel the orders in the SAP CRM Web UI:
3. In the Sales Order search view, search for the sales order, for
example with the sales order ID.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f244… 9/94
3/5/2020
SAP Commerce
Modifying orders
Modifying orders
Order changes made in the SAP back end are not replicated to
SAP Commerce.
Product bundles
Partial delivery
SAP CRM
Product hierarchies
Product variants
Modifying orders
Order changes made in the SAP back end are not replicated to
SAP Commerce.
Product bundles
Partial delivery
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 10/94
3/5/2020
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 11/94
3/5/2020
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 12/94
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 13/94
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 14/94
3/5/2020
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 15/94
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.
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:
The following diagram shows the order and shipping work ow between SAP Commerce and a single SAP back end:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 16/94
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.
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.
Integration Considerations
Whether you use Order Management Services with one or several SAP back ends, the following applies:
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.
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
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:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 17/94
3/5/2020
Assigns sourcing locations to each consignment
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 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.
For more information, see Preparing Master Data for Order Management with Multiple Back Ends.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 18/94
3/5/2020
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.
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.
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.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 19/94
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.
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.
Related Information
Con gure Order Management for SAP Commerce with One or More SAP Back Ends
Con guring Third-Party Vendor Sourcing
Prerequisites
You have done the following:
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
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.
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.
a. Map a plant to a logical system and leave the SAP sales area blank.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 21/94
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.
Prerequisites
You have done the following:
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:
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
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 22/94
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.
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.
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.
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.
Prerequisites
You have done the following:
Performed the steps for con guring Asynchronous Order Management with one or more SAP back-end systems.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 23/94
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 24/94
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:
The following table lists the extensions required for AOM with standard SAP Commerce order management, for both B2B and B2C
scenarios:
B2C only
sapcrmorder-raw
sapcrmorder-canonical
sapcrmorder-target
sapcrmorderexchange
ysaporderfulfillment
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 25/94
3/5/2020
sapcrmorder-canonical
sapcrmorder-target
sapcrmorderexchange
saporderexchangeb2b
ysaporderfulfillment
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:
Order cancellation in SAP CRM Order cancel 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:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 26/94
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
Outbound Processing
The following graphic shows a simpli ed view of the extension and layer concept used.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 27/94
3/5/2020
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).
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 28/94
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.
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
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.
Using the replacement of the DefaultCRMSalesConditionsContributor as an example, the following steps must be performed in your
own extension:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 29/94
3/5/2020
// Do the interesting stuff
return conditions;
}
}
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:
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
The following graphic shows a simpli ed view of the extension and layer concept used.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 30/94
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 31/94
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 32/94
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.
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:
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.
Common Settings
The following con guration settings introduced by the sapmodel extension are needed to create an order in the SAP CRM back end:
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
from the store name attached to the order.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 33/94
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
from the store name attached to the order.
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:
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 34/94
3/5/2020
customerReplicationEventListener Listen
replica
succe
sapOr
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 35/94
3/5/2020
enterCancellingStrategy Order
the cre
agains
Comm
orderCancelPaymentServiceAdapter Dumm
OrderC
doing
Comm
warehouseResponseExecutor Overri
injecti
servic
partialCancelRulesViolationStrategy Overri
only a
order
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 36/94
3/5/2020
saporderexchange.orderoutbound.maxRetries Maximum 10
number of
retries for
sending an
order or
order cancel
request to
Data Hub
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 37/94
3/5/2020
The sapcrmorderexchangeb2b extension provides reusable functions related to B2B sales order outbound processing in
asynchronous order management.
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.
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.
Related Information
sapcrmorderexchange Extension
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 38/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 39/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 40/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 41/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 42/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 43/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 44/94
3/5/2020
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 45/94
3/5/2020
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 46/94
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
saporderexchange
ysaporderfulfillment
saporderexchange
saporderexchangeb2b
ysaporderfulfillment
saporderexchange
saporderexchangeoms
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 47/94
3/5/2020
saporderexchange
saporderexchangeb2b
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.
saporderexchange Extension
The saporderexchange extension provides reusable functionality related to B2C inbound and outbound sales orders in
asynchronous order management.
Overview
The following objects are relevant for asynchronous order management:
Order cancellation in the SAP Order cancel noti cation Sales Order Inbound
back end
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 48/94
3/5/2020
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 49/94
3/5/2020
Dependencies
The saporderexchange extension depends on the following extensions:
Outbound Processing
The following graphic shows a simpli ed view of the extension and layer concept used.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 50/94
3/5/2020
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).
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 51/94
3/5/2020
DefaultPaymentContributor: Provides payment information. Note that only payment via payment service providers is
supported.
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.
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:
Create a new class for the contributor, implementing RawItemContributor<OrderModel>, as shown below:
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:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 52/94
3/5/2020
3. De ne a bean for this class, specifying the relevant contributors, as shown below:
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
The following graphic shows a simpli ed view of the extension and layer concept used.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 53/94
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.
saporderexchange supports the three additional data elds that Data Hub uses to generate a raw item batch ID. These data elds
are:
For more information on the Data Hubraw item batch ID, see Tracing Raw Items.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 54/94
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.
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 55/94
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.
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.
Common Settings
The following con guration settings introduced by the sapmodel extension are needed to create an order in the SAP back end:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 56/94
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
from the store name attached to the order.
Distribution Channel saporder extension on Data Hub The distribution channel is read from the
canonical item SAPConfiguration derived
from the store name attached to the order.
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.
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:
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 57/94
3/5/2020
customerReplicationEventListener Listen
replica
succe
sapOr
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 58/94
3/5/2020
defaultOrderCancelStateMappingStrategy Cance
ensuri
with c
Overri
strate
enterCancellingStrategy Order
the cre
agains
defaul
orderCancelPaymentServiceAdapter Dumm
OrderC
doing
Comm
warehouseResponseExecutor Overri
injecti
servic
partialCancelRulesViolationStrategy Overri
only a
order
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 59/94
3/5/2020
saporderexchange.orderoutbound.maxRetries Maximum 10
number of
retries for
sending an
order or
order cancel
request to
Data Hub
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 60/94
3/5/2020
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();
saporderexchangeb2b Extension
The saporderexchangeb2b extension provides reusable functions related to B2B sales order outbound processing in
asynchronous order management.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 61/94
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.
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.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 62/94
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 63/94
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 .
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.
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.
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 64/94
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.
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.
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.
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 65/94
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.
Dependencies
saporderexchange waiting state,: Provides reusable functionality for inbound and outbound processing of order-related
information
sapOrderexchangeRepairCronJob OrderExchangeRepairJob,
created as essential data
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 66/94
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.
Installed the systems required for asynchronous order management as described in System Requirements for SAP
Integrations
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 67/94
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
To reserve a number range for SAP Commerce sales orders, perform the con guration steps described in the following topics:
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 68/94
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.
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.
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.
<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.
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.
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.
You can also reset the start value of the key generator, as described in the following procedure.
Procedure
1. Start SAP Commerce Administration Console.
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.
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
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 70/94
3/5/2020
Groupings and Assign Number Ranges .
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.
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.
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
saporderexchange Extension
Pricing Procedures
Context
For sales orders replicated from SAP Commerce, the following condition types are relevant and are considered in this example:
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
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
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.
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.
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.
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.
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.
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
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 73/94
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.
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.
Implement other kinds of payment as required. For more information, see saporderexchange Extension or
sapcrmorderexchange Extension.
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
1. Navigate to the following Customizing activity (transaction SPRO):
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 74/94
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.
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
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.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 76/94
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.
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
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
a. Choose Order Orders and search for the orders. In the Results list, doubleclick an order.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 77/94
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. 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.
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:
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 78/94
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
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 .
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:
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 79/94
3/5/2020
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.
Application V1
Program RSNASTED
Funct (Function) SP
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:
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 80/94
3/5/2020
Counter 1
Procedure
1. In Customizing for SAP S/4HANA or SAP ERP, go to Assign Output Determination Procedures Allocate sales document
header Change New Entries .
Procedure
1. In SAP S/4HANA or SAP ERP, call transaction NACE.
3. Choose Condition records again, then output type ZBAH and Condition records.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 81/94
3/5/2020
5. Save your entries.
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:
3. Select the distribution model you just created, then choose Add Message Type and enter the following values:
For more information about what happens when you execute the code, see Output Control for Sales Order Con rmations.
Sample Code
*&---------------------------------------------------------------------
*& Report ZCHECK_CHANGE_MESSAGE
*&
*&---------------------------------------------------------------------
*&
*&
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 82/94
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.
* 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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 83/94
3/5/2020
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.
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.
Logistics Execution Shipping Basic Shipping Functions Output Control Output Determination Maintain Output
Determination for Outbound Deliveries
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 84/94
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:
Application V2
Program RSNASTED
1. Choose Maintain Output Determination Procedure and select V10000 Header Output and Control Data. Choose New
Entries and enter the following values:
Counter 0 0
CTyp (Condition Type) ZLDH (Delivery Note) for example ZLDW (Delivery Note) for example
1. Choose Assign Output Determination Procedures Assign deliveries (header) . Choose Change and New Entries. Enter the
following values:
DlvTy (Delivery Type) <Delivery type that you are using>, such as LF for outbound
delivery
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 85/94
3/5/2020
3. Choose Condition records again and choose the output type, such as ZLDH and ZLDW. Enter the following values for each
sales organization:
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:
3. Select the distribution model you just created, then choose Add Message Type, and enter the following values:
Related Information
Message Control
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 86/94
3/5/2020
Prerequisites
You have done the following:
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
saporderexchange Extension
sapcrmorderexchange Extension
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>
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.
Context
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 87/94
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 .
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:
Sales Organization Responsible (SAP CRM only) <Sales Organization Responsible>, such as O 50061093
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:
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 88/94
3/5/2020
Setting Description
Item Price The condition type for the item price that represents the gross or
net price of a product
Payment Costs The condition type for the transaction costs (payment costs)
Example in SAP S/4HANA or SAP ERP: ZPAY
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.
Procedure
1. In Backoffice, navigate to SAP Integration SAP Global Con guration Customer Replication .
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
Procedure
1. In Backoffice, choose SAP Integration SAP Administration Con guration .
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.
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
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 90/94
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.
A default implementation is delivered that you can use to map cancel reasons for both systems.
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
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):
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,
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 91/94
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
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.
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 92/94
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.
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.
saporderexchange.orderoutbound.retryDelay=60000 in ms (milliseconds)
saporderexchange.orderoutbound.maxRetries=10
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 93/94
3/5/2020
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:
For more information about the promotion types, see Promotion Types and Templates.
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 .
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.
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.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=21802335&topics=8c48d2d3866910148793f67f24… 94/94