Skip to Content
Product Information
Author's profile photo Andreas Krause

Backorder Processing in advanced ATP

What’s backorder processing?

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 fulfillment 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:


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

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.



Additional Information

For more information about Backorder Processing (BOP), including examples, see

Micro learnings for Backorder Processing (BOP) are also available at

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Angel G. Reyes
      Angel G. Reyes

      Hi Andreas,

      Nice document,

      I have these questions about some GATP functions that I don't see in aATP and I would like to know if they are part of the roadmap.

      • At some point in time, all BOP strategies will support PAL? I'd say the most important are WIN and GAIN strategies, AFIK currently, just REDISTRIBUTE strategy supports it


      • Will BOP support MISL/Correlation for items sharing the same delivery group?


      • In the sales order changes log, after aATP BOP changed the ATP situation, tcode field is not being populated with "BOP" string or something like that, do you know why? this is important to track who made ATP changes to the order line

      Hope you can help with those queries,



      Author's profile photo Andreas Krause
      Andreas Krause
      Blog Post Author

      Hi Angel,


      thanks for your questions. Let me answre two out of 3 questions.

      1. PAL is supported with all five confirmation strategies in BOP.
      2. Once MISL/Correlation is available we aim also for support in BOP. Currently the functionality is part of roadmap.
      3. Thanks for the feedback with respect to the change log. We will take this feedback and evaluate it in our internal system.



      Author's profile photo Biswaranjan Biswal
      Biswaranjan Biswal

      Hi Andreas,

      First of all, thanks for the wonderful document.

      We have implemented Backorder processing in aATP . The BOP sorting was done on Sold to Party which means we want to prioritize specific customer orders. The scenario worked fine until we activated PAL functionality.

      Now, the Sales order confirmation is not happening based on customer base. We have the below mentioned scenario:

      Sales Order 1 is created for Customer A which has no. 2 priority in BOP sorting and the confirmation is done at the time of SO creation only.

      Sales Order 2 is created for customer 2 which has no.1 priority in BOP sorting and the partial confirmation is done for the remaining stock material.

      When we run the BOP, system should be able to confirm SO2 for the whole quantity and SO1 should be partially confirmed.

      But this is not happening. Please guide if we are missing something.



      Author's profile photo Andreas Krause
      Andreas Krause
      Blog Post Author

      I think there is a kind of duplicate ->

      Author's profile photo Aleksander Bochynski
      Aleksander Bochynski


      Is it possible, when using redistribute strategy, to split quantity equally for all PO's falling into given segment ? E.g. I have 210 PC on stock and 3 PO's for 300 quantity in total (3x100 PC). With redistribute strategy today, it gives 100 to the first PO, 100 to another, and 3rd one gets 0. For me more intuitive would be to serve 70 to every PO. Would that be in general possible ?

      Author's profile photo Andreas Krause
      Andreas Krause
      Blog Post Author

      Hi Aleksander,

      If I understand it correct, you would like to share the available stock/supply over the STOs (with PO I think you refer to STOs, correct?). This functionality is on the roadmap as so called Fair Share (LINK).  As of today it is not possible.


      Author's profile photo Aleksander Bochynski
      Aleksander Bochynski

      Hi Andreas,


      Yes, exactly. This is STO scenario. Fair Share sounds like the solution that I'm searching for. Nothing but waiting now for it.

      Author's profile photo HAMZA ELMAGHRI

      Hi Andreas,

      First of all, thanks for the wonderful document.

      is it possible to link with app " Release delivery"  to assign automatically the values to be delivered?


      Author's profile photo Andreas Krause
      Andreas Krause
      Blog Post Author

      Hi Hamza,

      a linkage between Backorder Processing and Release for Delivery is not possible.

      Let me try to understand your requirement: Do you want to automatically create deliveries after the BOP run?