Take Control of Order Confirmations with Backorder Processing in APO
- by Ranjan Sinha, Senior Managing Consultant, IBM
- March 15, 2007
Find out how the sort profile and filter type affect backorder processing (BOP). In this example based on a real-world scenario, see how the author developed a workaround that allowed the company to use the material availability date as a sort criterion for BOP.
Backorder processing (BOP) is a critical step in sales order confirmations. It aligns the confirmation process with your business goals by prioritizing the sales orders to determine which orders to ship first. BOP is also critical when the supply is constrained and you must decide which sales orders to prioritize for shipping.
Recently, I worked on a Global Available-to-Promise (GATP) implementation. One of the critical points in the implementation was determining how to run backorder processing (BOP). With several options available, my client and I had to decide how to prioritize sales orders for the BOP run. The following criteria were considered important for prioritization:
- The document creation date (First In, First Out [FIFO])
- The material availability date
- Customer priority
- Delivery priority (in the case of rush orders)
How the company handled each order was especially important for products that were in short supply because it would be impossible to fill all the sales orders at once. Furthermore, the sort criteria could change based on the company’s business needs. For example, it considered customer service very important for certain key customers, but it also wanted the option to be able to treat all customers equally with faster inventory turns.
You can meet these requirements by setting the sort profile and filter type for BOP. I will discuss how to configure this in Advanced Planning and Optimization (APO) 4.0. During this implementation, we encountered some issues when we used the material availability date as a sort criterion. We were able to work around this with a user exit priority, which I will explain. If you are familiar with a similar rescheduling functionality in R/3 Enterprise (Release 4.7), refer to the sidebar “Comparison with R/3 Rescheduling” to evaluate the differences between BOP in APO and rescheduling in R/3.
For the purposes of this discussion, assume that Available-to-Promise (ATP) checks happen in the APO system. Although the system has the functionality to change the confirmations on the sales orders interactively through the interactive BOP transaction, this is a manual process. Alternatively, you can schedule it in batch processing for specified times, which is what I did.
Would you like to see this full item?