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:
We will start with a high-level introduction to the seven confirmation strategies:
But before we start with that, we should have a glimpse to the legend on how to read the diagrams:
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:
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.
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.
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.
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:
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:
As the name suggests, requirements assigned to this confirmation strategy will not receive any confirmed quantity:
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:
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.
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:
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:
By defining a variant that combines the two segments from the example above, the following situation arises:
In case a confirmation strategy is used more than once in a variant, the sequence of those segments does matter.
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.
For more information about Confirmation Strategies in Backorder Processing (BOP), including examples, see Product Assistance.
Micro learnings for Backorder Processing (BOP) are also available at https://microlearning.opensap.com/.
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
Additional Information
For more information about Confirmation Strategies in Backorder Processing (BOP), including examples, see Product Assistance.
Micro learnings for Backorder Processing (BOP) are also available at https://microlearning.opensap.com/.
- SAP Managed Tags:
