BTP OMSA Compatibility for Traditional ERP Order Promise Methodology Outside AATP

Alternative Order Promise Methodology

When solutioning BTP Order Management Foundation (OMF), SAP Order Management for Sourcing & Availability (OMSA) is paired with it to ensure product availability & reservation can be done in the BTP layer.

The best recommended practice that accompanies this functionality is AATP. However, SAP S/4HANA Private Cloud and SAP S/4HANA On Premise offer a continuation of many of the transactions previously available in ECC. In short, if the current allocation model is highly desirable, it may be able to be kept when transitioning to SAP S/4HANA depending on the license. There is also the possibility that OMF & OMSA can be integrated with ECC via an SAP collaboration project that can utilize these allocation methods.

We will review traditional order promise strategy and determine potential BTP use cases.

1. Order Confirmation
2. Order Rescheduling Assignment
3. Supply Assignment

 

Order Confirmation: Order confirmation occurs when an agreement is made to ship items to the customer. The features of the order confirmation that will be considered are:

1. Product Availability Check (PAC)
2. Promise Date Creation

Product Availability Check: When entering sales orders, you can confirm the delivery of the goods on the delivery date if they are available for all processing activities preceding the delivery. Confirming the delivery is the creation of a promise date that can be updated in the order and reflected in the BTP layer.

When using OMSA, you can already have a prefilled promise date that has been allocated and promised on the front end. However, using the order rescheduling method V_V2, you are now able to reschedule dates. Some reasons to update the customer delivery date would be:

1. If you promise not only against the product that you have in stock or on order, but you can also have backorders. Orders that were to be fulfilled but cannot be due to:
2. Supplier Delays
3. Manufacturing Delays
4. Warehouse Shipment Delays
5. Warehouse Good Receipt Delays
6. Incorrect Lead Time Maintained
7. All Other Delays (Port, Container, Vessel, Engineering, Procurement)

So how does the product availability check work and how can you use it? The product availability check is carried out based on the ATP (Available to Promise) quantity. The availability check will have a scope of check configured. For example, when ordering, the check will consider:

1. Stock
2. Inbound Deliveries
3. Production Orders
4. Purchase Orders
5. Purchase Requisitions
6. Lead Time Within Planning Horizon

Remember that the scope of check is configurable, and each organization can have many scopes of checks for different types of orders. For example, retail companies may only allow orders that only can be fulfilled by available stock.

Now with this structure, the Product Availability Check becomes critical for solutioning if the OMSA (BTP Layer) could be optimized by order rescheduling. Order rescheduling will ensure that all orders are going to have new promise dates generated for them. This helps us recognize the benefits that are accessible via order rescheduling. Some examples would be:

1. Allowing manufacturing & Supplier product availability dates to be accurately updated in the order promise dates.
2. Allowing rescheduling rules similar to AATP rules to be used. There can be prioritizations based upon the delivery priority or the plant that could help prioritize customers over one another.

 

Order Rescheduling: In the BTP layer, OMSA already has the functionality to confirm the order and create an accurate availability promise date at the time of the order. Orders are then able to be rescheduled in the ERP and then updated order promise dates can be updated in OMSA via the ATP snapshot capability.

The V_V2 Order Rescheduling Transaction: As shown in the visual below, the V_V2 transaction can reschedule all the orders coming from multiple order channels. The V_V2 transaction can be located in SAP ECC, S/4HANA Cloud Private Edition, and S/4HANA On Premise.

The photo to the below shows the program being executed in Fiori. There is flexibility in how the orders can be rescheduled. This is what leads to order promising logic that is similar to AATP.

V_V2 Order Promising Capability: The V_V2 rescheduling has a few functionalities similar but not the same as AATP.

1. Delivery Priority: Similar to AATP, the V_V2 rescheduling can reschedule order promise dates based upon which customers are higher priority. However, the logic is different. Inside each order, is a section for delivery priority that must be fulfilled. Different channels such as direct EDI orders from B2B could have higher priority than the eCommerce OMF orders and therefore would be scheduled first. Note that the delivery priority is found in the shipping tab on the line item in each order. In the example below, you can see that the delivery priority is high.
2. Similarly to AATP, there is also the ability to change the order of the sales order for rescheduling in other ways than just prioritizing customers. It can also separate orders by:
   1. The document category
   2. The date of the order
   3. The document number (Helpful if there is different order number creation methods for different sales channels)
   4. The document number
   5. The document item

Availability Promising Strategy:

OMSA and the V_V2 have different order promising strategy models. Therefore, it must be important to view the differences to recognize if there would be positive or negative effects from utilizing the V_V2 program.

1. OMSA: OMSA does order promising by the entire order. It allows orders not to be split and to only allow a single delivery.
2. V_V2: Using the V_V2 program, order promising is done line by line. The lines themselves can be configured to not be split but if there are multiple lines in an order, there could be different order promise dates. This can lead to multiple deliveries.

The below graphic is a warning showing how the OMSA and V_V2 logic can lead to order splitting.

No Order Splitting Use Cases: If the orders should never have split delivery, then the use case for order rescheduling is very limited. Use cases are:

1. One way that order rescheduling could still be used is if the product availability check only considers stock. In this way, all of the orders would still get stock, it would simply be rescheduling the order fulfillment to optimize which customers receive their products first.
2. The only other use case is if orders are always limited to a single line item. Essentially, there would be no delivery splits because there are no line order splits.
3. Using supply assignment, it is possible to create links to specific products. This allows order rescheduling to provide updated order promise dates to OMSA.

Supply Assignment: Supply Assignment (ARun) ensures that the supply is assigned to the orders. Supply assignment requires materials to be batched. Batch numbers are then placed onto the item number itself.

This methodology is only practical to some industries. High volume industries such as retail and consumer products could struggle with the application of supply assignment. Use this methodology carefully when solutioning.

When supply is fixed to an order, each line itself is considered allocated to a particular stock. The stock could be in stock or on a purchase order. This means that although dates could change when they are rescheduled, the order will always be associated with the source of supply.  This means that orders will not change order with one another but will update the delivery dates based upon updates from:

1. Vendors
2. Production
3. Warehouse

Summary: There are many companies currently satisfied with their order promise & allocation strategies in ECC. Being able to keep them without needing to transition to AATP when upgrading to S/4HANA can be highly desirable. I have tried to keep this summary at a high level so if there is anything that has been left out, let me know and I can update or create another blog.