Advanced Available-to-Promise (aATP) in S/4HANA 1610 Execution (Part 2)
In case you missed our first SAP Tech Tips blog, we documented the detailed aATP configuration, activated Product Allocations, and updated Master Data to set the foundation for running with aATP in our new S/4 HANA 1610 system. With business benefits identified to improve our order management, we are ready to move forward with the transactional data to put the aATP process in motion.
Increase Logistics Efficiency with aATP
Initially, we will set up the Product Allocation Objects using 3 Fiori apps. These Objects establish the selection parameters and build the foundation for the Back Order Processing (BOP) that we will create later in the process. Details on these 3 apps will be explained in a separate blog to be published within a few weeks.
We next proceed to four BOP apps that will create the parameters to decide what inventory is allocated to certain sales orders. The first BOP app, Configure BOP Segment, creates specific components that will be incorporated into the larger planning landscape. These segments will filter and sort data per the selection criteria documented. As an example, we can select Sold to Party to include a customer’s orders within a segment. There are a host of standard options available, such as Sales Organization, Document Type, Date Ranges or Plant, providing broad flexibility in segment creation. Once complete, a segment may appear as shown below, where we are selecting all orders shipping from the Supplying Plant 1710.
A display of the Fiori screen to build segments is shown below. This displays a few of the Selection Criteria choices available.
The second part of Segment Creation is the Prioritization. The Prioritization defines how the confirmed quantities will be redistributed among the orders identified from the Selection Criteria setting. There are 30 choices for this value, which display in a list similar to that shown above, and you can also build them in a series by adding multiple Prioritizer attributes into your segment. For our example, we will select Delivery Priority, the Sort Order = Ascending, and Save the BOP Segment. When complete, the BOP Segment appears as shown below.
With this BOP Segment, we are instructing the system to take all of the Documents within Sales Organization 1710 and distribute the confirmed quantities based upon their Delivery Priority, with Priority 1 first, 2 second, and so forth.
After we identify the Selection Criteria and Sort priorities, we save each segment.
The next BOP app, Configure BOP Variant, will provide the key tool to drive the aATP functionality. We build a variant by adding any number of the segments created above to drive system adjustments. The important step is the strategy we select. Summarized below are the five new categories to adjust confirmations, displayed in their order of merit:
- Win: These orders are confirmed in full/on time as the top priority
- Gain: Maintain initial confirmation and possibly gain up to the full quantity
- Redistribute: Middle ground that should gain but may also lose confirmed receipts depending on the two factors above
- Fill: Will not increase confirmed quantity, can either keep current or lose
- Lose: All confirmations will be deleted and assigned to higher priorities
The slide picture below demonstrates how each strategy can acquire inventory from the lower-priority strategies.
In our example, we will select the Redistribute strategy, and add one segment into our BOP Variant. You can add multiple Strategies and segments with the buttons in the display below based upon your business needs. Once complete, save your BOP Variant.
With BOP Variants created, we move on to the Schedule BOP Run app, containing multiple Scheduling Options for one time runs or the more common scenario of Background jobs running periodically. This app is also available as a GUI transaction, ATP_BOP. For our example, we will select our BOP Variant created earlier and the Start Immediately option to run it one time.
Clicking the “Schedule” button starts the actual BOP job.
The last BOP app, Monitor BOP Run, is a report to display the completed jobs and the business impact for each one. Users see the Processing Status and Confirmation data with %s indicating where confirmed inventory changed based upon the Variants within the job. This data is also visible in SM37.
We can click a Variant Name to drill down into a specific job run to analyze data further. In this example we see an improvement, no change, and a decrease for three sample materials.
Clicking a Material Number, we drill down further to identify Sales Order level changes. We can see Sales Order 21 gained an additional 90 pieces to now be confirmed in full.
In this blog, we reviewed the different Fiori apps used to schedule, execute, and monitor the aATP process including steps to create the building blocks.
Please share comments, corrections and experiences using S/4HANA 1610 or send us a tweet @CenturyLinkENT with your questions.
This blog has everything need to know for aATP, I really appreciate it!
I would like to add one thing, to enable BOP segment configuration, I have activated Odata Service VOCABULARY_SRV both in frontend and backend.
This is very good document and absolutely great work.....
Could you give an example in case we need to add more than 1 strategy to BOP variant?.
If we want to add more than 1 strategy, we need to create the new BOP Segment first.
We have a high priority customer and want to ship their orders in full. We begin by creating the new Segment using the "Sold To Party of the ATP Document" as the Selection Criteria and identify the Customer number as the Prioritizer value.
Next we open the BOP Variant and use the "Add New Strategy" button. When we select "Win" and add our new Sold to Party Segment, this customer's orders will be confirmed in full, and then the Redistribute strategy will act as the next step and adjust confirmations based upon the delivery priority we originally designed.
These options provide wide flexibility to build simple or more complex BOP Variants that meet business requirements.
Hi George, great post and really helped me get started with this topic. My 'Redistribute' strategy works every time according to my sort criteria such as requested delivery date and will increase a confirmed qty on some orders with a matching decrease in others.
But no matter how many times I try run a variant with a 'Win' strategy, it never uplifts the confirmed qty to the original requested qty. I've run the win on its own in a variant with just that strategy and also as per your suggestion above with the Win first followed by the Redistribute. The selection criteria works as i can see the log showing the Win line for the customer selected, but never updates beyond the lesser confirmed qty.
Just a long shot asking you in case it was something you experienced in your testing and then overcame.
There shall be enough quantity available to improve confirm quantities for WIN, if you release (unallocate) some quantities through LOSE or so , then WIN is expected to confirmed as per requested quantity.
Great blog thanks for sharing valuable inputs. I had a small query may seem silly but wanted to ask you about this statement
2. Also is there any blog which you have written on how the back order processing works for AATP in terms of de allocation of stock from sales order A where the stock has got confirmed and it allocates to Sales Order B which has come later and is more important
Appreciate if you could let me know..
All settings related to BOP variant need to be done in Fiori only . Only the activation of PAL through AATP is done in IMG.
I have implemented above strategy configuration in my system but at the time of BOP scheduling run I got below error with log
Please let me know how to rid of this error.
Hello Sushant Katekar, did you ever find out about this problem? I have the same issue, but having a hard time resolving this. Also, I am not sure how to display the "log details", where did you find that?
That’s an error that occurred since the pre-request HRF Setup hasn’t been done in your system. You need to ensure that the pre-req to run ABOP is setup (details in the note 2400537) first before you could run the ABOP. Cheers !