This is a cross-company STO with delivery and intercompany billing. The

material is setup with a PIR with the vendor as the supplying plant in

the receiving plant's purchasing organization. The PIR has a order unit

of measure (CS) which is a higher unit of measure than the base unit of

measure (BOX). This order unit of measure has been setup as an

alternate UoM in the respective material master (ie. 1 CS = 42 BOX)

The IC STO PO is created in terms of cases. When a delivery is created

for this STO, only partial quantity is available in the warehouse to

satisfy the requirement. The system picks the entire remaining

available quantity which can be picked for the delivery. This is in

terms of full units of the Base UoM (eg. 57 BOX), which corresponds to

1.357 CS. When subsequently in the future, inventory is available to

satisfy the remaining quantity, the system creates the second partial

delivery. However, in the calculation of the quantity in the second

partial delivery, the system uses the quantity in terms of the

alternate order UoM (CS) instead of recalculating the remaining

quantity in terms of the Base UoM.

For example in the above scenario, if the initial PO order quantity = 2

CS (which is equal to 84 BOX). Initially, only 57 boxes where available

in inventory, so the system created a partial delivery for 57 box. The

system calculated the delivery quantity in this first partial delivery

as 1.357 CS. When the subsequent inventory arrives and the second

delivery is created, the system should know that 57 boxes have already

been delivered, hence the remaining quantity should be 27 boxes.

However, the system recalculates the remaining quantity in terms of the

order UoM (i.e. Remaining quantity = 2 CS - 1.357 CS = 0.643 CS). This

is then converted into the equivalent of the Base UoM (which is 27.006

BOX). As a result, the follow on documents such as transfer orders

direct the picker to pick 27.006 boxes which is not possible because

the BOX is the ultimate Base UoM and cannot be broken down. As a

result, the picker either has to confirm short the TO due to which

there is an open quantity of 0.006 BOX on the delivery, and hence

cannot be PGId, or confirm the TO with 27.006 BOX, which leads to

subsequent decimal places in remaining inventory.

Why does the system recalculate the remaining delivery quantity in

terms of the order unit of measure instead of the Base UoM? This leads

to lots of decimal quantity and fractional inventory. Please let us

know how to resolve this situation

## Add comment