How to extract ATP stock snapshot 20-400x faster from standard ERP and S/4 (by using OAA's parallelization capabilities)

[ingo_woesner]

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:

1. Real-time ATP calls via RFC into your SAP back end


2. 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

1. 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.


2. 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

 

[Ritz]

Great one, thanks for sharing it ingo.woesner.

Regards

RD

[andrrr]

Thanks for sharing ingo.woesner !

Could you please advise if the OAA ATP stock snapshot can consider aATP objects like product allocation (PAL) and supply protection (SuP)?

To clarify, it can happen that there is an on-hand stock and some open orders, which block the stock. But on top of that, there could be additional restrictions in aATP like SuP reservations for some wholesale customer groups etc. In this way, stocks available for a webshop could be lower than stock-open demand and it would be good to consider these restrictions in the stock feed.

If not yet, do you have plans for that?

Best regards,

Andriy.

[ingo_woesner]

Hi Andriy,

OAA ATP stock snapshot does not consider any allocation/segmentation/reservation, and certainly not any specific aATP features.

However, there is a OAA DC stock separation option introduced with S/4 1909 on premise, to only use a portion "segment" of the ATP stock for a certain sales channel, mostly ecommerce. The "context" is assigned in SAP Customer Activity Repository (a SAP Retail solution) to the Sales Channel of the corresponding OAA sales channel.

 

If you want to use the DC stock separation functionality, you need to maintain so-called "contexts" as a means of separating DC stock into logical or physical units in the SAP back end.

However, the report OAA_GENERATE_ATP_SNAPSHOT in the SAP back end will only include the context "field" as such in the extract, but does not "filter" for it. So all ATP stock info is transferred, including those without a "context". That means you have to filter for it in the receiving ecommerce solution it.

I hope the docu above gives you more details. I am not much familiar with the configuration and content of the OAA DC idocs.

 

I hope this helps.

Best regards,

Ingo

 

[andrrr]

hi Ingo,

thanks a lot for the prompt clarification!

Although, do hope to see a bit more of aATP integration in the future. The point is that the stock segmentation is getting much less popular for supply protection of sales channels, giving the way to 'softer' mechanisms of aATP. I've seen such requests already in several fashion retailers.

Technically, it's actually nice to have the 'context' communicated from CAR for the ATP snapshot calculation. Maybe, this string could be used as an input to aATP?..

arno.meyer , maybe could be interesting for you?

Thanks a lot and best regards,

Andriy

[thielsen]

Hi

 

Also thank you from my side for a very good and interesting information.

I have one question regarding the OAA_GENERATE_ATP_SNAPSHOT report :

Is GATP in APO supported with this report, or is it only working with the normal ATP or AATP in S/4 Hana   ?

 

Thanks a lot and best regards

Claus

[ingo_woesner]

Hi Claus,

the gATP has no relation to OAA_GENERATE_ATP_SNAPSHOT as it only takes ATP into account. So the OAA service is independent from gATP, AATP, and/or ATP.  

Best regards,

Ingo

[thielsen]

Hi

 

Ok, understood.

Thanks for your quick reply.

 

 

[andrrr]

Just to save time for those who face same requirements.. Out of the box, the ATP snapshot considers all relevant aATP SuP reservations. In other words, if any stock was reserved by SuP, this quantity will be excluded from the snapshot.

In my current project, we also need availability without consideration of SuP. For that, we've implemented a minor (explicit) enhancement deactivating the SuP depending on the input parameters of the program.

hope it can be helpful,

Andriy.

[former_member850379]

Hi Ingo,

Thanks for the great sharing!

We're very interested in OAA_GENERATE_ATP_SNAPSHOT, since we are from retail company and ATP is one of the most important things. We're using ECC6 EHP6 SP14 now, do you think it's applicable?

Thanks a lot!

Regards

Yohanna

[ingo_woesner]

Hi Yohanna,

thank you.

 

Unfortunately, you need a higher release to benefit from the OAA snapshot:

SAP Retail 6.0, EHP7 SP14 / EHP8 SP07 or higher

S/4 Hana Version 1709 or higher

 

Best regards,

Ingo