Dear SAP Community,
Imagine you have a large online business, with 100k’s of products and dozen(s) of warehouses. Your ecommerce solution is selling like crazy, and you want to give your customers the best (stock availability) experience.
Basics
The silver bullet for B2C businesses is certainly to invest in an SAP Retail back end and use SAP’s Omnichannel Article Availability and Sourcing solution closely integrated your Retail business with SAP Commerce Cloud.
But what if you are no retailer, but maybe a Consumer Products company selling directly to consumers (D2C), or a wholesale/machinery/high tech/sports /spare parts/Telco/etc. business selling to consumers or even to business partners (B2B).
This blog explains how ATP stock information is replicated out of a standard SAP back end 20x-400x faster, without the need of a SAP Retail or SAP Customer Activity Repository
In that case one of these options might solve your issue with replicating stock information to your ecommerce solution:
- Real-time ATP calls via RFC into your SAP back end
- Replicate ATP stock information to your ecommerce solution
Well,
1) works when you have a low-volume ecommerce business and can afford stock information is NOT shown when ERP is in maintenance on some Saturday nights. This might apply for some mid-size B2B businesses.
But when speaking about big volume business, 2) is the more reasonable option.
What is ATP Stock information?
In your SAP back end (ERP or S/4, independent of sATP or aATP) your ATP check determines the real-time stock availability in your warehouses. It not only considers the actual stock in the storage locations, but also sales orders reducing and goods receipts increasing your stock. And a lot more. So, ATP is the most precise stock information your SAP back end system has to offer. A typical ATP check for a product in a warehouse takes 10ms (milliseconds) = 0.01 seconds. aATP is usually >3x faster.
Time is Money …and good Customer Experience
Imagine your web shop sells 100k products which are shipped from 12 warehouses across many countries.
This simplified extrapolation shows you the magnitude of how long the ATP determination run takes:
100.000 products multiplied with 12 warehouses = 1.2 million ATP checks
1.2 million ATP checks multiplied with 0.01 seconds = 12000 seconds = ±3.3 hours.
In addition, the ecommerce solution needs time to process the 1.2 million ATP iDocs (typically as XML files), which might last another 5-15 minutes.
So until your next full ATP results come in, 3.5 hours have passed. A lot of sales, goods receipts and stock movements can happen in between.
Pedal to the Metal – make it 20x faster! or even 400x faster!
What if you can make it 20x faster. Without additional license costs of course:
3.3 hours will shrink into 10 minutes.
And this is only for the initial (full) ATP run. For the subsequent runs, you can only consider the “delta” of products which have seen sales, goods receipts and stock movements. Say 5% of them.
10 minutes will shrink into 30 seconds
So after the 10 minutes of the initial ATP run, the following delta runs only take 30 seconds. And save 95% time on the ecommerce side with 20x less XML files to process too.
How does it work in standard S/4 resp. ERP?
In 2015, a SAP back end report for an ATP snapshot parallelization have been introduced along with the shipment of SAP Retail’s Omnichannel Article Availability and Sourcing.
With minor SD customizing, a small extension and a BAdI implementation to get rid of a SAP Retail specific prerequisite, the report OAA_GENERATE_ATP_SNAPSHOT provides you the ATP iDocs in the fast fashion we are talking about.
These small fixes have been implemented with a Standard S/4 based wholesale distributor in a matter of hours, so it is live and working with regular SAP back end (non-SAP Retail) systems!
Works out of the box with SAP S/4HANA 2020 on premise and higher
The report OAA_GENERATE_ATP_SNAPSHOT was adapted in S/4HANA from 2020 on premise release, to make it compliant to non-Retail SAP back end systems. So steps 4 and 5 in section “Implementation” below are not needed.
Earlier S/4 releases as well as ERP releases need a little fix to get the ATP snapshot parallelization.
Implementation
- Select the material/DC combinations
for this please check this blogin chapter “Configure S/4HANA and ATP snapshot replication” where this step is explained.You can ignore the different context – just the customizing matters. - Customizing steps:
a. Define technical settings for Business systems
b. Define ATP Parallelization Profiles for DC Articles
c. Define system connections
Although the customizing nodes are mentioning Retail, every S/4 system contains the config.
3. The selection screen for the report requires an entry for Assortment. Here you can enter any WERKS ID but the selection itself will be handled via BADI.
The replication mode must be set to “ALE”.
Below you see the flag for the “Delta mode”, as mentioned above.
4. The Report OAA_GENERATE_ATP_SNAPSHOT comes with a selection on a Retail specific WERKS setting. This setting must be eliminated in a standard (non-Retail) SAP back end system (as implicit enhancement)
5. For the selection of products that should be considered can be defined in BAdI BADI_OAA_ATP_CTRL_SET_ARTICLE. Here a corresponding selection must be implemented – the below EXAMPLE selects on ‘Material type’ and ‘Cross-Plant Material Status’. Method DETERMINE_PROD_LOC_FOR_ATP:
That’s it!
Release requirements
- SAP ERP EhP7 SP11 (full run), SP12 (delta run) or higher
- SAP ERP EhP8 SP01 (full run), SP02 (delta run) or higher
- SAP S/4HANA 1709 or higher
Enjoy,
Michael & Ingo
Michael Osthof
Global VP Digital Transformation Retail
SAP SE
Dr. Ingo Woesner
Product Manager, SAP Customer Experience
SAP SE
