Skip to Content
avatar image
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

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • 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.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Jürgen Lins

      Thanks a lot Jurgen, the issue here is that they can ship single boxes or partial cases for external customers, but they want retail plants to order in full case quantities. Hence the Base UoM was set to BOX, whereas the order unit in the STO PIR was set to CS. At any point in time, there is bound to be partial cases present since the warehouse might have shipped single BOXes to external customers. As a result, when they want to pick Cases for retail STOs, due to some partial cases being present, this results in the situation that I described.

      I will try to push for using Base UoMs in the retail STO process as well. I could set up some rounding in terms of the Base UoMs itself to match rounding to case quantities, so that the order comes in terms of BOXes, but rounded to a full case quantity. And since the STO itself is in terms of boxes, the follow-on processes should not involve any problems regarding partial BOX quantities.

      This was the fall-back approach I had even prior to creating this discussion, but just wanted to check whether there was any other option that could be used. Looks like there is nothing else we can do other than introducing custom development in user-exits which could lead to greater issues in the future.