Backorder Processing in advanced ATP

Backorder Processing (BOP) is the mass processing of orders in batch mode, where order
confirmations are changed to accommodate business priorities and changes in the demand/supply
situation of your order fulfilment process.

Solution highlights

Requirement segmentation, classification, and prioritization by choosing from different confirmation

strategies.

Sophisticated yet easy-to-use tool for requirement filtering

Wide range of extensible, pre-delivered characteristics for filter definition

Fallback variants for automated exception handling

Monitor for checking processing status and final results.

How to set up backorder processing

Each of the following apps allows you to configure a specific step prior to running backorder
processing or to monitor the results of a completed backorder processing run:

 Configure BOP Segment- Combinations here we create in S4 HANA

 Configure BOP Variant - Assign BOP Segments to Strategies
 Schedule BOP Run– Tell the system to Perform BOP for a Particular Variant
 Configure Custom BOP Sorting
 Monitor BOP Run

Segments in backorder processing are used to define the filter criteria for selecting requirements and
sorting them accordingly. A filter can consist of inclusion as well as exclusion conditions and can be
configured to use relative date operators to specify timeframes or dates relative to the filter
execution timepoint. Furthermore, the app comes with a simulation capability to identify, prior to
execution, exactly those requirements which would be filtered according to the segment’s definition.

If a sorting sequence that does not follow simple alphanumeric sorting is required, you can use the
Custom BOP Sorting app to define it. The defined custom sort sequence can be used seamlessly
within a segment.
Multiple segments can be defined and used within one or several variants, according to your
business needs. The variant defines how the requirements selected by the segments are combined
and checked in the run.

It is possible to assign a segment to one of six confirmation strategies – Win, Gain, Redistribute,
Improve, Fill, Lose – each serving a specific purpose. Confirmation strategy Redistribute, for example,
allows the redistribution of confirmations according to the requirements sorting within that strategy.
An optional global segment can be defined to restrict the selection of the entire variant.

Assigning multiple segments to a single confirmation strategy can help you achieve a segmentation
of requirements including their own sorting.

The confirmation strategies Win and Gain can be used for the most important requirements which
must be confirmed fully (Win) or whose previous confirmation (Gain) may, at the very least, not be
worsened. If the availability situation prevents this, the run ends with an exception. Exceptions can
be handled automatically by assigning a fallback variant to ensure that customer promises can be
fulfilled: the fallback variant may, for example, include further requirements which may grab
confirmations from similar stock transport orders or other customer orders which are of lower
priority.

For more details on confirmation strategies and how they can help you to prioritize requirements
further, see https://help.sap.com/viewer/32da8359c8ee4e8b8e8c5e15cacba5aa/latest/en-US/
1ba3a457ef816b10e10000000a441470.html

After the variant is configure and saved, it can be run directly in simulative or non-simulative mode. If
the variant is to be scheduled on a regular basis (for example, once a day), the Schedule BOP Run app
can be used.

How to find the results of backorder processing runs

Once a backorder processing run has started, it can be monitored in the Monitor BOP Run app. The
app displays the processing status (for example, Completed, Processing Issues, No Processing Issues,
Confirmation Re-calculation) as well as general information such as the number of processed
requirements and the overall confirmation rate. In addition, you can drill down into the requirements
and see how confirmations have changed within the run.

Confirmation Strategies in Backorder Processing – A Deep Dive

When you reach here, you most probably already know about Backorder Processing (BOP) in
S/4HANA and are eager to get an extra portion of detail. The goal of this blog is to provide a deep
dive into the confirmation strategy concept in BOP, a concept that enables the segmentation of
requirements to meet business priorities.

If you are new to Backorder Processing (BOP), please check out the following blogs before
continuing:

 Backorder Processing in advanced ATP

 How to setup Backorder Processing (BOP) in a dynamic business environment

Confirmation Strategy
We will start with a high-level introduction to the seven confirmation strategies:

 Win

 Gain

 Improve

 Redistribute

 Fill

 Lose

 Skip

But before we start with that, we should have a glimpse to the legend on how to read the diagrams:

Legend (click to enlarge)

Win

Requirements that are assigned to Win must be fully confirmed on time. If this constraint cannot be
met, an exception is triggered – you can react to the constraint violation with two configuration
options:

Stop Failed Material-Plant Combinations

Stop BOP Completely

A description of these options and consequences can be found under Configuration Options for
Exception Handling in product assistance.

Note that resolving the exception is compulsory.

The following diagrams illustrate nine different cases where it is clear that Win is a confirmation
strategy with high standards when it comes to confirmation.
 

Gain
Confirmation strategy Gain requires that selected requirements must at least retain their
confirmation and, if possible, improve the confirmation situation. Like Win, the constraint must be
met, otherwise an exception is triggered. The exception is handled according to the variant
definition, where two configuration options are available, please see above.

The following diagrams illustrate nine different cases where it is clear that Gain can help to improve
the confirmation with a weaker constraint than Win.
 
Improve

If you reach here, you will have read the word ‘improve’ multiple times. This is no coincidence and
the general purpose of BOP is to break the first come, first served (FIFO) principle and improve the
confirmation if the availability situation allows it.

Confirmation strategy Improve embodies the basic essence of BOP and can, therefore, be treated as
the standard confirmation strategy. Requirements assigned to Improve try to retain, at least, their
confirmation and if possible, improve. These requirements can also lose their confirmed quantity if it
exceeds the availability situation. The following diagrams illustrate the behavior of the confirmation
strategy and enable us to understand what leads to a confirmation worsening. Cases 2, 4 and 9
illustrate how over-confirmations are resolved and reliable order confirmations are generated.

 
Redistribute
By using the confirmation strategy Redistribute, you may expect a strict hierarchy between the orders
when it comes to confirmations. According to the sorting of the requirements in the segment, the
confirmation is redistributed so that the requirements at the end of the list must donate their
confirmations to those requirements further up the list. This donation leads to a worsening of the
confirmation situation towards the end of the sorted requirements list if the availability situation is
restricted. Cases 6-9 in the following diagram illustrate this clearly:
 
Fill

Requirements assigned to Fill don’t gain additional quantity or get an earlier confirmation date. This
is true also if the availability situation would theoretically allow it. At very best, the requirements get
an equal confirmation:
 

Lose
As the name suggests, requirements assigned to this confirmation strategy will not receive any
confirmed quantity:

Skip

Requirements assigned to Skip do not participate in the availability check, even if they have been
selected for backorder processing. This confirmation strategy cannot consciously be selected during
variant definition. Instead, the system assigns requirements to Skip independently when backorder
processing is executed. There can be multiple reasons for assigning requirements to Skip:

The Fix Date/Quantity flag is set in the order line item and is not consciously incorporated by the
user in the variant used for backorder processing.

The requirement in question is neither relevant for the Product Availability Check (PAC) nor Product
Allocation (PAL).

Evaluation Sequence

Requirement filtering is done on the basis of the segment which can be generic or specific. The
following example illustrates these extremes. The segment SegmentGeneric selects requirements
based on a single selection condition which can be translated to ‘All requirements within plant 1010’.
The segment SegmentSpecific select only a single requirement by having two selection conditions,
one for document number 59 and one for item 10.

Generic selection criterion: SegmentGeneric

Specific selection criterion: SegmentSpecific

If multiple segments are combined in a single variant, the question arises to which segment the
requirement is assigned: this is important as it not only impacts the confirmation strategy to which a
requirement belongs but also how the requirement is placed in the overall check sequence. Each
confirmation strategy has a defined evaluation and check sequence as the following table illustrates:

Evaluation and Check Sequence of Confirmation Strategies

Let us have a look at a short example: we assume there is a set of eight requirements in plant 1010.
One of the requirements is item 10 in document 59:
Set of requirements

By defining a variant that combines the two segments from the example above, the following
situation arises:

Number of requirements selected by segment

Visualization of requirement selection

In case a confirmation strategy is used more than once in a variant, the sequence of those segments
does matter.

Check Sequence

The check sequence is very similar to the evaluation sequence between confirmation strategies.
However, each segment definition comes with its own sorting. Bringing things together during the
requirements selection defines how the check sequence of that very backorder processing run will
look like. Here a brief example of a run: assume four segments are used within a variant where a
total of 7,300 requirements are being selected.
Sankey diagram showing the selection and processing of requirements
Requirement assignment to segment and derived Check Sequence

 Manage Characteristic Catalogs