Explaining aATP Backorder Processing

You have promised several sales orders based on the quantity and inbound delivery date of a purchase order. Now the vendor of this purchase order informs you about a production delay. In addition, only a partial delivery will be possible.

You want to reflect these changes in the confirmed delivery dates and quantities of your sales and store orders.

Relevant customizing is maintained in IMG → Cross-Application Components → Advanced Available-to-Promise (aATP).

The use case for reATP is to re-confirm orders (sales orders and stock transfer orders) if supply and demand has changed (significantly). Previous ATP confirmed dates and quantities get replaced if necessary.

In the example above two orders had been confirmed against future supply (a purchase order). Later the purchase order had been updated because the vendor faced some production capacity issues resulting in a later delivery with a lower quantity. ReATP therefore confirms both orders for the new stock availability date. Being of lower priority the sales order can not be completely confirmed completely any more.

Classical rescheduling selects all requirements of a selected material/plant combination.

BOP however allows for more individual requirement selection by various selection criteria. Also the sorting options of such a selection of requirements has be enhanced. Selection and sorting criteria a defined in a "so called" segment. One or several segments are linked to a BOP variant and will be executed together. The segments which are linked to a variant can use five different confirmation strategies. The strategies decide to which extend the requirements should be confirmed.

If several segments with different strategies are part of the variant the confirmation quantities will be higher (and closer to requested date) the higher the rank of the strategy is.

The figure illustrates, how BOP segments are linked:

1. BOP segments are defined independently with their specific selection and sorting criteria
2. When used together in a BOP variant the selection criteria may overlap
3. No item can be selected by two segments. In the BOP variant each segment belongs to a strategy. In case of overlapping selections the segment linked to a BOP strategy with higher importance has preference. "Lose" however has selection preference over all other segments

A BOP variant can have as many segments with the same strategies as needed. In that case the order of segments with the same strategies define which selection criteria have preference.

A global segment can be defined in addition to the normal segments to restrict or increase the detailed selection of the segments by one more general selection.

Set up and execution of backorder processing is only supported in SAP Fiori. There are no transactions available in the back end system.

The graphic shows the interdependency of the apps.

To the left is the maintenance view of BOP segments.

Here, users can specify the selection criteria and the sorting sequence for the requirement documents.

To the right the specific sorting definition is shown.

This is the maintenance view of the stock sorting rule.

Here, users can specify the sorting criteria and their usage.

The figure illustrates the basics about BOP-Variant configuration.

Next step in BOP variant is to specify the BOP strategies to be used and also mention the BOP segments for each of the strategies. Multiple segments can be defined under each strategy.

In case of multiple BOP segments specified under same BOP strategy, the priority of execution will be in the order sequence as specified under the strategy.

Once the BOP variant is created, users can specify the BOP variant name which needs to be scheduled.

The jobs can be schedule for immediate run or for a later date and time. The frequency of the job runs can also be defined and set up.

Users can specify if it's a simulation run or actual execution with order updates.

Users can also choose the log option, if selected the logs will be created and can be seen in the BOP monitor app.

During BOP execution, exceptions can occur due to Win segment not getting full on time confirmations or Gain segment getting worse confirmation than before. Using Fallback Variants these exceptions can be handled more intelligently. It can be maintained in the BOP Variant configuration app.

The executed jobs including simulations, can be seen here with details of:

• Variant name, user name, job details and processing status
• Overall confirmations and details of old confirmation quantity vs. the new confirmation quantity
• Overall supply assignment quantity and details of old vs. new assignment quantities

In this view, users can see the overall quantity at different levels.

E.g. for each material/plant combination, you get to know the on time confirmation, overall confirmations as well as overall supply assignment quantities.

It also shows the quantity change between the old and the new quantities derived based on this BOP run.

The 2nd level of drill down in BOP monitor appshows the overall quantity for each combination of requirement (SO/STO), item and requested schedule line.

For each combination, you get to know the on time confirmation, earliest confirmations, overall confirmations as well as overall supply assignment quantities.

It also shows the quantity change between the old and the new quantities derived based on this BOP run.

The 3rd level of drill down in BOP monitor app is a pop-up where you can see the overall quantity at the material availability date of requirement (SO/STO), item and requested schedule lines.

For each unique date, you get to know the confirmations as well as supply assignment quantities.

It also shows the quantity change between the old and the new quantities derived based on this BOP run.

The example shows five orders which are created while a PO is available as future supply. Wholesale orders are created first, followed by retail and finally web channel. ATP during order creation confirms on a first come first serve. The result is that retail and web orders are not getting confirmed.

BOP can pick up the orders and one segment per channel is used. Within each segment the sorting could be first come first serve again.

As a result the web order gets fully confirmed. Same is true for retail. Wholesale has only 250 left which are confirmed against the two orders. The order that was created first gets fully confirmed the other only partially.