Skip to main content

There’s a customer order, connected to a shipment. Each customer order line has a quantity of 6,336 (Approximately 6,000). The shipment has handling units, and each handling unit has a capacity of 96 units (approximately 100). The sales part is a serial part and total quantity is serialized. The following steps are performed.

Manual reservation of customer order line - the quantity of 6,336 manually reserved in the form of handling units - Duration 1.5 minutes

Unreserve customer order line - The total quantity reserved above, was unreserved - Duration - 2.15 minutes

Create pick list manually - A pick list was created for one order line manually. Even though the duration was 50 seconds, the create picklist activity keeps executing in the “Create pick list for customer orders” for about 3 minutes. But when I checked the shipment, the report picking option is enabled. 

Report picking of picklist lines (Pick by choice one Handling Unit) - Duration 2.1 minutes.

Report Picking (Remaining quantity as reserved) - Duration10 minutes - Extremely unusual delay.

Complete shipment (Including deliver and close) - Duration 1.1 minutes

Return handling units from shipment inventory (WADACO) - Duration 13 seconds - This is just for one HU with a quantity of 96. In this case, there are 66 handling units with the same quantity. 

 

The Question is, has anyone come across this type of an unusual delay in a cloud 24R1 environment?

Hi,

The reason for this is the sheer number of stock records and transactions to handle from the fact that the part is serialized and handling unit handled and the high quantity on the customer order line. There will be one stock record and transaction per PCS of the part on the customer order line. At report picking it will even be a two transactions as you do pick out from picking location and pick in to shipment inventory e.g. 12000 + transactions at report picking of the shipment. To some extent increased granularity in the tracking comes with a cost. The initial design of the serial solution is more design for high value and low volume environment and not for low value and high volume scenario. 

However there is hope! There is an ongoing multi-release effort to improve this. The approach is to get away from creating one transaction with postings and everything per serial and handling unit. The approach will instead be to create one transaction with the total quantity and then have the detailed information about the delivered serials and handling units in a sub-table to the transactions. In you example it will rather be one inventory transaction with the quantity of 6000 PCS and then all the detailed information about delivered serials and handling units in the sub-table. There are some conditions for when this is not possible e.g. if you have cost per serial, same location etc.

If you are on 24R1 as you indicate there should be an about description in the on-line documentation called “Inventory Transaction Aggregation for Serials and Handling Units” where you can read more.

In your flow above we have enabled this for Deliver Customer Order with and without Shipment. So you can check if your delivery transactions are aggregated? We have found that we can do some further tuning in the delivery step here when handling units are involved, we hope to add this to 25R1. In addition we hope to apply the same concept for report picking in 25R1.

Best Regards

Fredrik

We also have the same issue. It was in Apps 10 as well. We have a multi-level handling unit structure.

A shipment can have hundreds of handling units. We’ve had to overcome timeout issues, etc.

We’ve complained and complained. Great to hear that it is being addressed in upcoming releases!

 

Wonderful to know it will be tackled in the forthcoming updates!

Reply


Terms & ConditionsCookie settings