SAP CAR Omnichannel Article Availability and Sourcing (OAA)
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:
- 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.
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.
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.
It is very nice article, thank you.
I have one question for you about click&collect with pick up point, when source is selected "Is Pickup Point Only" on manage sources.
How system calculates article availability for those locations?
Even if I define supplying DC for that kind of pick up points, I could not see correct available quantities on availability rest service response.
I am expecting that when I execute availability service for a pickup point location, system will get available quantities from supplying DC, but it just get it from pickup point location.
Indeed in sourcing steps you set a sequence for potential pick up points. Then when you execute sourcing rest service this sequence is taken into account and you receive as a response list of sources. As a last step when you execute availability service then you need to put in the address of service what you call "pick up point".
Than means in you case i would use sourcing service for basket availability and availability service only for detailed article availability.
I just asked about click&collect business scenario, end customer is selecting exact location from possible list of locations on commerce interface in this scenario. I wander how end customer is informed about stock level of pick up points that have not any stock at all.
when executing sourcing, sourcing request must be populated with source number with preselected indicator. Sourcing steps does not include any information about potential pick up points as I know.
do you have any business flow about click collect with pick up point?
there are some explanations on below document, but available calculation logic is missing.
When Customer is selecting store in commerce then you know exact location to check product availability in particular store. Then if in the store there is a 3PC and your Customer wants to order 5PC, sourcing will result alternative source if possible (in your case DC). But if Customer watns to order 2PC sourcing will return store as source (of course it depends on customizing).
Link that you shared is for STO configuration for DC to store.
your example scenario is not possible according to link that I shared.
it says it is not possible to use a store in both scenarios, a store can be used in click&ship or click&collect pickup point.
"Stores may either take active part in the online store business by offering their stock for the click-and-ship scenario or the click-and-collect scenario, or they may act as a pickup point only".
Let's assume Store A has no stock for article A, Store A is selected as pick up point and DC is supplying plant which have 10 PC.
When customer wants to click&collect article A from Store A, somehow I believe customer need to see 10 PC is available at StoreA on commerce interface. But I could not see any functionality like that.
A source that is marked as "pick up point" is not a regular store, but a place where online orders can be collected. E.g. a gas station, an automated box that opens for the specific customer, etc.
The order is delivered from another source (which is able to fulfill orders = pick/pack/ship) to this pickup point.
When you maintain a pickup point, you have to define from where this source is delivered with the online orders.
A pickup point has no own stock and is excluded from sourcing. It is just a location where customers can collect their orders. That's it.
It's well described in the docu link Maciej has shared above:
Please note pick up points have been introduced to OAA with CAR 4.0 FPS02, so it is quite new.
Dr. Ingo Woesner
Product Manager, SAP Customer Experience
everything is so clear that you explained, I just define pick up points and supplying plants on OAA.
there is just one thing that is not clear for me.
there is a click&collect pick up point (Store1) that have zero stock for article A,
there is also another click&collect store (Store2) have zero stock for article A.
when customer clicks on possible click&collect points on commerce interface, how customer can understand he/she can order from Store1 but not from Store2.
A pickup point is typically fulfilled from a dedicated distribution center or a large store.
There is no sourcing optimization for pickup points. In case this fufillment source has no stock that's it, and this is shown already on the website.
Which retailers use pickup points? These are typically grocery retailers, of retailers selling products for daily use. These types of products should always be in stock, and if not there should be a substitute product.
And in case the product cannot be substituted, e.g. a DVD, the order cannot be collected from this pickup point. In that case the webshop should offer a clic&ship to the home address, so sourcing optimization can be applied and the DVd can be shipped from a different location.
I hope this answers your concerns.
thank you for your interest, it is clear for me now
In my opinion it's just an used terminologi but most of it depends on business requirements how each scenario is implemented.
Example you refer to is exactly click and collect. In this case Customer is not fully interested from where the stock comes from. What could be interesting from his point of view is perhaps earliest pickup date. Then you can do a sourcing and check the results, if quantity available in the store do a reservation (or any other business process) if not run replenishment process and describe delivery date.
thank you for your valuable comments
I've two questions:
Context: We will not use Hybris Commerce as E-commerce platform. We want to connect SAP CAR OAA to an third party E-commerce platform.
for 2) I had to reach out to the OAA developers.
ad 1) the sourcing location OAA has computed is added to the commerce order document, and - when transferred to S/4 - also to the ORDERS idoc.
ad 2) in the same way the vendor Id and purchasing site is stored in the commerce order document and then transferred to the ORDERS idoc. The vendor sourcing data are provided as "purchasing site" with partner function vendor (ID). the item category for drop ship items is provided e.g. as "TAS"
Hope this helps.
this is a very nice article, thank you for that!
Have you ever had the requirement to include OAA with sourcing in S4 Sales Order?
Assuming the customer does not use either SAP commerce or any other 3rd Party Webshop but instead want's to benefit from Availability and Sourcing functionalities while creating a sales order in S/4H System.
Is there any Standard way, or is it necessary to develop something here?
Thank you for good word about the article.
As the OAA is based mainly on data coming from S/4 (or ECC) like ATP for article, status of sales orders etc, you can achive it in your S/4 system.
The case is only about real store stock. Sales data from POS to Car are sent either in some interval or more probably sales data is aggregated in Car and sent to S/4 once per day. If this is valid as well for your landscape then during the day you will not be able to see real stock in S/4.
To see real stock in store in Car you can use the odata service for inventory visibility.
Hi Maciej Jarecki,
This was really descriptive and will help ; Big Thanks
In our project we will not be using SAP Commerce as E-commerce platform. We want to connect SAP OAA to an third party E-commerce platform.
I have few questions.
Very nice document with the detailed steps.