Former Member

# Decimal quantities in deliveries

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

10|10000 characters needed characters exceeded

• Aug 20, 2012 at 09:40 AM

you only need to perform the second parrtial like you did with the first partial shipment. your problems only come up because the approach was changed between those 2 shipments.

I am not sure how you pick the quanitities, I just tested it in my system, ordered 2 cases a delivery was created, I changed the delivery quantity and pick quantity to 57 boxes and posted goods issue.

I can see a delivered quantity of 1.357 in PO history

then I created a second delivery for the PO, of course it is coming up in CS as this is the order unit, But I change it manually the delivery and pick quantity to 27 boxes, and have no problem to post a goods issue and all my documents have then the boxes listed instead of CS with decimals. Only in PO history I will see a delivery for 0.643 CS

In general I recommend to do intercompany business in base unit instead of order unit, why do we need order unit for internal business, where both work with the same base unit?

breaking packages and send incomplete units is always a problem. We usually restrict this by usage of delivery unit field in sales view of material master, so that only a quantity or a multiple of this quantity can be send, but no partials.