- SAP Managed Tags:
Nowadays online stores are becoming much more popular throughout the Customers way of thinking about shopping and seems as a “Must be” for companies. Good online store or mobile app for sales can be very profitable for a company, brand and on the other hand stands for a diversification of sales channels. Brick and mortar stores combined with online platforms and mobile channels bring challenge to integrate Omnichannel sales like having same sales price, managing promotions/bonus buys or finally stock availability. All these aspects bring us to a question what could be the best way to integrate your e-shop with SAP?
A bit of theory...
SAP CAR Omnichannel Article Availability and Sourcing (OAA) is a service to support integration for Retailers in area of e-commerce (e-commerce platforms, e-shops etc). As the name indicates solution provides information about availability of the articles based on business defined sequences of sources and supports shopping cart processing. Basically, it allows connected system to read sources, their availability and create a temporary reservation as a follow on by checking the customer cart availability.
The typical online sales process
As an example, I took Ikea online store (I don’t know if Ikea uses SAP or any other system and how integration is done, here it’s just an example of online store). The process for Customer seems to be quite straight forward. At the first step the Customer is informed about the online purchase allowance and then about stores availability indicator (I think in the past is was also possible to see exact stock level at store).
Following that Customer is selecting way of delivery (click and collect, click and ship), delivery address and time, payment method and process is finish for Customer.
From system perspective sales process is more complex and else couple steps are needed to be done, with more detailed explanation below.
Rough Stock Indicators – at the entry point for online sales. System informs Customer about general product availability at stores for click and collect scenario or for delivery in case of click and ship scenario.
Detailed availability calculation – system is presenting to Customer accurate information about availability of product at store or in delivery.
Each type of source for delivery has a different way of calculating availability information:
Delivery scenarios selection supported in standard:
Souring – system is executing in the background search for optimum sources of delivery for a shopping cart and selected delivery scenario.
Temporary reservation – system is making temporary reservation for a Customer’s shopping cart.
System configuration
As the solution of OAA is spread across number of system customizations need to be done in CAR and S/4 and then solution configuration (stored in CAR) via Fiori.
In SAP CAR customizing is done in node of CAR – Omnichannel Article Availability and Sourcing (OAA)
Sales Channel mode vs. OAA Profile mode.
There are two ways to perform necessary customizing. First one – OAA Profile Mode, a bit older and most of the configurations like defining sourcing network are done within Badi implementation. That means that either your implementation of Badi has been done in the way that it reads Z-table or you need to change a code every time you want to do any changes in a source determination. Second one is much more flexible as in customizing of CAR you only define Sales Channel ID and remaining configuration of solution is done over the Fiori apps. Additionally, according to documentation only this version is supported in S/4 environment. Here I will focus only on Sales Channel mode.
In SAP S/4 configuration is related to area of ATP snapshot availability check for articles delivered from DC. This configuration is performed in node of SD – Availability Check with ATP Logic or Against Planning – Retail: Omnichannel Article Availability and Sourcing.
At first use “Define System Connections” option to set the RFC connection used to send back results of ATP check to CAR. The reason behind it is that ATP can be executed for a long list of articles and despite of optimization still it can be a long lasting operation. ATP snapshot results in case of integration with online platform where SAP CAR is not used are distributed with Idoc to target system. In this case customizing contains details about receiver system, port etc of the Idoc and is triggered with transaction OAA_GENERATE_ATP_SNAPSHOT for ATP calculation. Second step for ATP snapshot replication is to “Define ATP Parallelization Profiles for DC Articles” where column connection Id defines how data of ATP result is handled (RFC back to CAR or Idoc).
To fulfill Customer requirements, company instead of or as an extra need to use purchase goods from its supplier. As mentioned above quantity that vendor can deliver at particular date is stored at the backend in tables OAA_VEND_STOCK_H/I after the replication take place with Odata services (OData service for upload of vendor stock information S/4: <S/4>/sap/opu/odata/sap/OAA_VENDOR_STOCK_SRV)
Fiori solution configuration
Customizing done in CAR (not so much, only Sales Channel Id) is a baseline for solution configuration with Fiori apps. It’s important to differentiate that there are separate apps for configuration where the target system is SAP Retail and SAP S/4. Below presented apps are for S/4 integration and in sequence in which they should be executed.
Manage Sources - SAP S/4HANA
This app is used only to setup pick and pack operations capacities. Each online transaction if sourcing indicates DC or Store requires a time needed to fulfill it. If we don’t want to overwhelm there is an option to set maximum number of transactions that DC or Store can do per day. If you use Vendor as a source or you do not want to use capacity limits this step is optional.
Landscape of the solution is spread over number of systems. Beside the frontend which can be SAP Commerce, most of the data comes from S/4 and logic of processing reside on SAP CAR.
Manage Sourcing Networks SAP S/4HANA
In this Fiori app you set list of potential sources for your products. What is important to remember is that sequence of added sources doesn’t matter here as it’s only available list of sources that can be used to fulfill the order.
As presented above I use all potential source of supply for Customers in this part of country but as mentioned before this list doesn’t mean from where and how orders are fulfilled.
Manage Sourcing Strategies
This is the most important part of Fiori app solution configuration. As the sources have been already defined in this app we decide which one are used when and how.
With support of all possible variation of sources of deliveries I would like to have: first from Store if article is available there then form DC and then at the latest delivery from Vendor (third party replenishment).
Configuration contains couple of steps that are well described in application help. In general system needs to read potential sources, read their availability, sort it, filter it (not used here but option could be for example a distance from source to Customer etc) and at the end business logic decision, how delivery should be done.
What I personally like about this configuration and generally OAA solution is flexibility for extensions. If you want for example to add your logic regarding filtering based on shipping costs you need to create a class that implements a respective abap interface and with metadata method you can collect input parameters straight in Fiori app.
Manage Sales Channels
The final step in configuration is to combine all of these single elements with sales channel Id for:
Example:
I will use two articles with following stock and availability level.
Article 1: OAA_ART_T1
Available in Store in Liverpool with quantity of 15 PC and then deliveries take place from DC current stock 10 PC then replenishment with RLT: 2d planned delivery time and 1d GR time.
Article 2: OAA_ART_T2
Available in Store in Leeds with quantity of 5 PC and then deliveries take place from DC current stock 15 PC then replenishment with RLT: 1d planned delivery time and 1d GR time. Vendor can deliver 25 PC till 01/12.
Step 1 – Fetch the availability data to CAR
In CAR, I run report (in live system better to have a background job) /OAA/ATP_SNP_CALC to fetch information about the availability as an ATP snapshot. To generate availability information for DC articles, the system triggers the parallelized ATP run in S/4 and for availability information of vendor’s articles system reads vendor stock information from tables (tables OAA_VEND_STOCK_H/I) uploaded in advance with Odata services to S/4.
Result of execution of ATP snapshot replication report (/OAA/ATP_SNP_CALC) presented below:
Interesting is the last line where ATP quantity is reaching unlimited number. This is because at S/4 ATP procedure is calculated with considering RLT of article.
Step 2 – Send Rough Stock Indicators (RSI) information to store
A rough stock indicator (RSI) is a visual or textual indication whether an article is available for shopping or delivery without showing the exact available quantity. RSI is populated with use of Idoc that is triggered with report /OAA/ATP_RSI_GENERATION_SC. As RSI indicator information is very much depending on company requirements, so standard only checks if there is as least one source with available quantity to determine Its value. To implement your own logic use badi: /OAA/BADI_ATP_RSI_GENERATION.
In the Idoc that have been used to distribute information about Rough Stock Indicator (RSI) each segment is information about the availability with emphasis on field ROUGH_STOCK_VALUE that is used for RSI indicator representation value.
Step 3 – Detailed availability
To display detailed availability of article per source webservice is used.
Sourcing, availability and temporary reservations are all based on webservices. More details about the structure of a messages is in a note 2841700 and nice documentation about webservices is here
Address of service : <SAP CAR>/sap/car/rest/oaa/availability/[ARTICLE_ID]/[SOURCE]?sap-client=[SAP_CLIENT]& &salesChannel=[SALES_CHANNEL]&unitSap=[UNIT]
Example of fetch current OAA_ART_T2 availability in store 04.
Step 4 – Sourcing
This step will tell the truth about shipping cart availability, potential sources and deliveries etc. Here I would split tests into three scenarios:
Address of service : <SAP CAR>/sap/car/rest/oaa/sourcing?sap-client=[SAP-Client]
Result for case 1:
For quantity more than 15 PC no source can be determined.
Result for case 2:
For quantity more than 15 PC external vendor is determined.
Result for case 3:
If you increase quantity of item 1 to 12 PC system is not able to determine the source despite quantity is available. The reason of it is that single delivery has been requested in Manage Sourcing Strategies for business configuration.
Step 6 – Temporary reservation
In standard integration with SAP Commerce, CAR creates an internal temporary reservation as soon as sourcing is carried out in checkout. This step reduces available quantity for sourcing. Customer creates the sales order (in S/4) based on shopping cart and then temporary reservation is removed followed by ATP availability decrease due to the placed order. In standard integration temporary reservation is created on item level and when a sourcing is executed. Synchronization between S/4 order and temporary reservation is done via field of synchronization timestamp. As not every Customer’s reservation is finishing with sales order there is a report to delete outdated temporary reservations /OAA/ATP_RESV_DELETION.
Address of service to create a reservation: <SAP CAR>/sap/car/rest/oaa/reservation?sap-client= [SAP-Client]
Report to check configuration – very useful.
Please check SAP Note ‘2806767 - Check of System Setup and Configuration for OAA’ that contains code for report /OAA/CHECK_SYSTEM_SETUP. This is very useful tool that allows you to check configuration for designed scenario in all systems.
A bit of theory...
SAP CAR Omnichannel Article Availability and Sourcing (OAA) is a service to support integration for Retailers in area of e-commerce (e-commerce platforms, e-shops etc). As the name indicates solution provides information about availability of the articles based on business defined sequences of sources and supports shopping cart processing. Basically, it allows connected system to read sources, their availability and create a temporary reservation as a follow on by checking the customer cart availability.
The typical online sales process
As an example, I took Ikea online store (I don’t know if Ikea uses SAP or any other system and how integration is done, here it’s just an example of online store). The process for Customer seems to be quite straight forward. At the first step the Customer is informed about the online purchase allowance and then about stores availability indicator (I think in the past is was also possible to see exact stock level at store).
Source: Ikea.com
Following that Customer is selecting way of delivery (click and collect, click and ship), delivery address and time, payment method and process is finish for Customer.
Source: Ikea.com
From system perspective sales process is more complex and else couple steps are needed to be done, with more detailed explanation below.
Rough Stock Indicators – at the entry point for online sales. System informs Customer about general product availability at stores for click and collect scenario or for delivery in case of click and ship scenario.
Detailed availability calculation – system is presenting to Customer accurate information about availability of product at store or in delivery.
Each type of source for delivery has a different way of calculating availability information:
- Distribution center – RFC call is executed from CAR towards S/4 to execute ATP function for a range of articles. In case of third part online solution Idoc can be used for integration.
- Vendor stock – stock of article delivered by Vendor is uploaded with Odata service and stored in the tables OAA_VEND_STOCK_H/I on S/4 side. If Vendor is in sourcing sequence and there is no available stock information system assumes unlimited availability.
- Store – this is a single type for sourcing where availability information resides only on SAP CAR (most of them previously migrated with SLT). System use predefined view InventoryVisibilityWithSalesOrderReservedQuantity (take into account unrestricted stock, unprocessed transactions at CAR) to calculate availability.
Delivery scenarios selection supported in standard:
- Click and ship – Customer will receive delivery to requested address
- Click and collect – Customer will pick up goods at the store.
Souring – system is executing in the background search for optimum sources of delivery for a shopping cart and selected delivery scenario.
Temporary reservation – system is making temporary reservation for a Customer’s shopping cart.
System configuration
As the solution of OAA is spread across number of system customizations need to be done in CAR and S/4 and then solution configuration (stored in CAR) via Fiori.
In SAP CAR customizing is done in node of CAR – Omnichannel Article Availability and Sourcing (OAA)
Sales Channel mode vs. OAA Profile mode.
There are two ways to perform necessary customizing. First one – OAA Profile Mode, a bit older and most of the configurations like defining sourcing network are done within Badi implementation. That means that either your implementation of Badi has been done in the way that it reads Z-table or you need to change a code every time you want to do any changes in a source determination. Second one is much more flexible as in customizing of CAR you only define Sales Channel ID and remaining configuration of solution is done over the Fiori apps. Additionally, according to documentation only this version is supported in S/4 environment. Here I will focus only on Sales Channel mode.
In SAP S/4 configuration is related to area of ATP snapshot availability check for articles delivered from DC. This configuration is performed in node of SD – Availability Check with ATP Logic or Against Planning – Retail: Omnichannel Article Availability and Sourcing.
At first use “Define System Connections” option to set the RFC connection used to send back results of ATP check to CAR. The reason behind it is that ATP can be executed for a long list of articles and despite of optimization still it can be a long lasting operation. ATP snapshot results in case of integration with online platform where SAP CAR is not used are distributed with Idoc to target system. In this case customizing contains details about receiver system, port etc of the Idoc and is triggered with transaction OAA_GENERATE_ATP_SNAPSHOT for ATP calculation. Second step for ATP snapshot replication is to “Define ATP Parallelization Profiles for DC Articles” where column connection Id defines how data of ATP result is handled (RFC back to CAR or Idoc).
To fulfill Customer requirements, company instead of or as an extra need to use purchase goods from its supplier. As mentioned above quantity that vendor can deliver at particular date is stored at the backend in tables OAA_VEND_STOCK_H/I after the replication take place with Odata services (OData service for upload of vendor stock information S/4: <S/4>/sap/opu/odata/sap/OAA_VENDOR_STOCK_SRV)
Fiori solution configuration
Customizing done in CAR (not so much, only Sales Channel Id) is a baseline for solution configuration with Fiori apps. It’s important to differentiate that there are separate apps for configuration where the target system is SAP Retail and SAP S/4. Below presented apps are for S/4 integration and in sequence in which they should be executed.
Manage Sources - SAP S/4HANA
This app is used only to setup pick and pack operations capacities. Each online transaction if sourcing indicates DC or Store requires a time needed to fulfill it. If we don’t want to overwhelm there is an option to set maximum number of transactions that DC or Store can do per day. If you use Vendor as a source or you do not want to use capacity limits this step is optional.
Landscape of the solution is spread over number of systems. Beside the frontend which can be SAP Commerce, most of the data comes from S/4 and logic of processing reside on SAP CAR.
Manage Sourcing Networks SAP S/4HANA
In this Fiori app you set list of potential sources for your products. What is important to remember is that sequence of added sources doesn’t matter here as it’s only available list of sources that can be used to fulfill the order.
As presented above I use all potential source of supply for Customers in this part of country but as mentioned before this list doesn’t mean from where and how orders are fulfilled.
Manage Sourcing Strategies
This is the most important part of Fiori app solution configuration. As the sources have been already defined in this app we decide which one are used when and how.
With support of all possible variation of sources of deliveries I would like to have: first from Store if article is available there then form DC and then at the latest delivery from Vendor (third party replenishment).
Configuration contains couple of steps that are well described in application help. In general system needs to read potential sources, read their availability, sort it, filter it (not used here but option could be for example a distance from source to Customer etc) and at the end business logic decision, how delivery should be done.
What I personally like about this configuration and generally OAA solution is flexibility for extensions. If you want for example to add your logic regarding filtering based on shipping costs you need to create a class that implements a respective abap interface and with metadata method you can collect input parameters straight in Fiori app.
Manage Sales Channels
The final step in configuration is to combine all of these single elements with sales channel Id for:
- Sourcing network – sources where to check for the article.
- Sourcing strategy – how to fulfill the order based on sourcing network.
Example:
I will use two articles with following stock and availability level.
Article 1: OAA_ART_T1
Available in Store in Liverpool with quantity of 15 PC and then deliveries take place from DC current stock 10 PC then replenishment with RLT: 2d planned delivery time and 1d GR time.
Article 2: OAA_ART_T2
Available in Store in Leeds with quantity of 5 PC and then deliveries take place from DC current stock 15 PC then replenishment with RLT: 1d planned delivery time and 1d GR time. Vendor can deliver 25 PC till 01/12.
Step 1 – Fetch the availability data to CAR
In CAR, I run report (in live system better to have a background job) /OAA/ATP_SNP_CALC to fetch information about the availability as an ATP snapshot. To generate availability information for DC articles, the system triggers the parallelized ATP run in S/4 and for availability information of vendor’s articles system reads vendor stock information from tables (tables OAA_VEND_STOCK_H/I) uploaded in advance with Odata services to S/4.
Result of execution of ATP snapshot replication report (/OAA/ATP_SNP_CALC) presented below:
Interesting is the last line where ATP quantity is reaching unlimited number. This is because at S/4 ATP procedure is calculated with considering RLT of article.
Step 2 – Send Rough Stock Indicators (RSI) information to store
A rough stock indicator (RSI) is a visual or textual indication whether an article is available for shopping or delivery without showing the exact available quantity. RSI is populated with use of Idoc that is triggered with report /OAA/ATP_RSI_GENERATION_SC. As RSI indicator information is very much depending on company requirements, so standard only checks if there is as least one source with available quantity to determine Its value. To implement your own logic use badi: /OAA/BADI_ATP_RSI_GENERATION.
In the Idoc that have been used to distribute information about Rough Stock Indicator (RSI) each segment is information about the availability with emphasis on field ROUGH_STOCK_VALUE that is used for RSI indicator representation value.
Step 3 – Detailed availability
To display detailed availability of article per source webservice is used.
Sourcing, availability and temporary reservations are all based on webservices. More details about the structure of a messages is in a note 2841700 and nice documentation about webservices is here
Address of service : <SAP CAR>/sap/car/rest/oaa/availability/[ARTICLE_ID]/[SOURCE]?sap-client=[SAP_CLIENT]& &salesChannel=[SALES_CHANNEL]&unitSap=[UNIT]
Example of fetch current OAA_ART_T2 availability in store 04.
Step 4 – Sourcing
This step will tell the truth about shipping cart availability, potential sources and deliveries etc. Here I would split tests into three scenarios:
- Single item OAA_ART_T1 with quantity 12 PC (Store will do a delivery)
- Single item OAA_ART_T2 with quantity 7PC (DC will do a delivery)
- Both items in single shopping cart with quantity T1 – 10 PC and T2 – 15 PC
Address of service : <SAP CAR>/sap/car/rest/oaa/sourcing?sap-client=[SAP-Client]
Result for case 1:
For quantity more than 15 PC no source can be determined.
Result for case 2:
For quantity more than 15 PC external vendor is determined.
Result for case 3:
If you increase quantity of item 1 to 12 PC system is not able to determine the source despite quantity is available. The reason of it is that single delivery has been requested in Manage Sourcing Strategies for business configuration.
Step 6 – Temporary reservation
In standard integration with SAP Commerce, CAR creates an internal temporary reservation as soon as sourcing is carried out in checkout. This step reduces available quantity for sourcing. Customer creates the sales order (in S/4) based on shopping cart and then temporary reservation is removed followed by ATP availability decrease due to the placed order. In standard integration temporary reservation is created on item level and when a sourcing is executed. Synchronization between S/4 order and temporary reservation is done via field of synchronization timestamp. As not every Customer’s reservation is finishing with sales order there is a report to delete outdated temporary reservations /OAA/ATP_RESV_DELETION.
Address of service to create a reservation: <SAP CAR>/sap/car/rest/oaa/reservation?sap-client= [SAP-Client]
Report to check configuration – very useful.
Please check SAP Note ‘2806767 - Check of System Setup and Configuration for OAA’ that contains code for report /OAA/CHECK_SYSTEM_SETUP. This is very useful tool that allows you to check configuration for designed scenario in all systems.
19 Comments
