Acquiring a Basic Understanding of Backorder Processing (BOP)

Objectives

After completing this lesson, you will be able to:

  • Explain why reconfirmations of sales orders are needed

Another Sales Order is Received

Note
See the following video where Liv is asking Sally to enter a sales order in the system for customer Motormarkt Heidelberg:

Note
Use the following simulation to learn how to add a second sales order with multiple items for a customer with a high priority:

The Second Sales Order is Entered

Note
See the following video for a discussion between Sally and Jim about the sales order for Motormarkt Heidelberg:

Note
Use the following simulation to analyze the situation in the system before backorder processing is executed:

The Concept of Backorder Processing (BOP)

Backorder Processing (BOP) can be used to revise sales orders with regard to the availability situation. The reasons for this are manifold.

For example, sales orders may not be confirmed, or not confirmed as requested due to the Available-to-Promise (ATP) situation. In combination with the transfer of requirements, receipts can be planned. However, without backorder processing, the confirmation for entered requirements does not change. This means that once a sales order has been saved, the system does not check whether the ATP situation has changed in order to achieve a confirmation of the sales order or to improve the confirmation.

Another reason for backorder processing is the first come, first served principle of the availability check. Incoming requirements are checked for availability in the sequence in which they are entered. Confirmed requirements reduce the cumulative ATP quantity. A sales order entered later may not be able to be confirmed even though it has a higher priority. With backorder processing, cumulative ATP quantity can be distributed according to different priorities (for example, according to the delivery priority of the item) than the entry sequence of the documents.

Another reason for backorder processing is that a sales order is confirmed based on a planned receipt. The receipt date is shifted into the future. Without backorder processing, the now unrealistic confirmation remains in the order.

An Example of aATP

SAP S/4HANA backorder processing in the solution Available-to-Promise (ATP) is fundamentally different from options in the business function Advanced Available-to-Promise (aATP). If aATP is activated for the material, the classic transactions CO06 "Backorder Processing: Initial Screen", V_RA "Order Processing: Selection List", and V_V2 "Rescheduling sales and stock transfer documents: by material" can no longer be used. Advanced Available-to-Promise (aATP) in SAP S/4HANA offers several (new) SAP Fiori apps for automated processing of backorders and the manual release of orders for delivery. In this unit, we only learn about the basic concept of automated processing of backorders in aATP and focus on interpreting the results. The configuration and execution of the BOP is not part of this training.

In aATP, you first define BOP segments. Technically, a segment is a saved selection of settings that determines which requirements are selected and the sequence in which the requirements are prioritized. With segments, order items are selected in the BOP run and sorted according to the prioritization. A confirmation strategy is then applied to each of the requirements of this selection in the BOP run. This makes it easier to imagine a segment as a selection or group of requirements to which a confirmation strategy is then applied in the BOP run. With only one segment, you can recheck the requirements of this segment or distribute cumulative ATP quantity according to priorities other than the entry sequence of the documents. The first requirements in the segment are first checked for availability. This means that the probability of a confirmation is high. The next sales order items of the segment are then checked. The probability of a requested confirmation decreases. With the definition of multiple segments, you can also distribute cumulative ATP quantity between the segments based on confirmation strategies in the BOP run.

A confirmation strategy defines how a requirement is handled in a run. Each requirement in a run is assigned to one of six potential confirmation strategies. The assigned confirmation strategy determines which requirement receives available quantity first. Confirmation strategies are assigned in the configure BOP Variant to segments app. In SAP S/4HANA there are 6 confirmation strategies: Win, Gain, Improve, Redistribute, Fill, Lose, and Skip:

  • Win:

    Assigned requirements are fully confirmed on the requested date (or immediately, if their requested material available date is in the past).

  • Gain:

    Assigned requirements retain, at least, their confirmation or, if possible, improve.

  • Improve:

    Assigned requirements try to retain, at least, their confirmation and, if possible, improve. But could also lose their confirmation.

  • Redistribute:

    Assigned requirements can get a better, equal, or worse confirmation.

  • Fill:

    Assigned requirements don't gain additional quantity or get an earlier confirmation date. They get an equal, or worse confirmation.

  • Lose:

    Assigned requirements lose their current confirmation and aren't confirmed.

  • Skip:

    Assigned requirements retain their current confirmation and aren't included in an availability check.

For example, you can apply the strategy "Add to Lose" to a segment. These sales order items then lose their confirmed quantity. The cumulative ATP quantities increase and can then be distributed to other segments using the "Improve" strategy.

A BOP variant defines which segments are included in a run and with which strategy they are checked. You schedule runs with variants as a background job. With the Monitor BOP Run app, you can check the results of BOP runs.

Log in to track your progress & complete quizzes