The requirement is to cancel few quantities of the PO which are in sentToNode status, owing to the shortages. The corresponding quantities in SO have to be backordered and the rest to be shipped. To achieve this, a multi API call is made with changeRelease and confirmShipment inputs. Here during confirmShipment the API fails with the message– “OMP10079-Quantity is greater than the allowed over-shipment percentage limit”.
Issue in pipeline configuration
Diagnosing the problem
In the sales order pipeline, a chained order listener is configured after ChainedOrderCreated status.
This listener is listening to the Purchase order execution, with Listen To Statuses configured as ‘sentToNode’ and ‘cancelled’ and corresponding drop statuses as ‘ChainedOrderCreated’ and ‘backordered’ respectively.
A sales order is created for say 10 items. On creating chained order and running the send purchase order release agent, there are 10 qty at the SO in chainedOrderCreated status and 10 qty at the PO in sentToNode status.
Now, during the multi API call, changeRelease is called where the shortages (2 qty) are cancelled.
After cancellation, there are 2 qty in backordered and 8 in sentToNode status at the PO. The corresponding statuses at sales order should read as – 2 in unscheduled and 8 in chainedOrderCreated state.
However, since the chainedOrderListener is listening to cancelled status with the corresponding drop status as backordered, as soon as the shortages are cancelled at the PO, 2 more quantites get backordered at the sales order thus actually making the corresponding statuses at SO as – 2 qty in unscheduled state, 2 in backordered state and 6 in chainedOrderCreated state.
The next input in multi API call is confirmShipment, which is being used to confirm the shipments in one shot. Based on 8 qty in sentToNode status at the PO end, the system tries to ship 8 qty at the SO end, where it actually has only 6 qty in shippable state. Hence this error is thrown – “OMP10079-Quantity is greater than the allowed over-shipment percentage limit”.
Resolving the problem
As part of the solution, the listener is made to listen to Backordered status at the PO end instead of listening to Cancelled status. This ensures that chainedOrderListener at the sales order gets triggered only when the corresponding quantities at the PO get backordered (after cancellation) and not at the cancellation stage itself. As the quantities get backordered at PO, corresponding quantities at SO get unscheduled which are then picked up by the listener and dropped to backordered state. Hence during confirmShipment now 8 qty are in shippable state while 2 in backordered.