Decimal quantities in deliveries

[Former Member]

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

[JL23]

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.

[Former Member]

Hi Jurgen,

If I understand your testing, you manually changed the delivery unit and quantity in the delivery from CS to Boxes? The PO is created in terms of cases, and hence, the delivery will also get created in CS. Did you then go into the delivery manually and change the CS quantity into an equivalent BOX quantity?

If so, then yes, there will be no problem, however, I do not want to manually go into the delivery and change the delivery unit and quantity. I want the system to do either of the following

1. Ensure that there are no decimal quantities in terms of the underlying BOX quantity even if the CS quantity is used for the delivery creation (ie. If the delivery is created for 0.643 CS, the underlying pick quantity in terms of the Base UoM (BOX) should be for 27 BOX and not 27.006 BOX). I have tried setting the rounding indicator (TVLP-RNDSG) in the relevant delivery item category (ZNLC) to X - "Rounding to the nearest whole number" so that the delivery quantity gets rounded to the next whole number. This did not work. Also I have adding a dynamic rounding profile of BOX with Rounding off method of 2 - "Round off to order/sales Un and to log. units" and a rounding rule of BO which is set to round to the next BOX with zero tolerance. I even tested the rounding profile in simulation mode in the configuration node and tested it with 1.357 CS. The simulation rounded it up to 57 BOX without any decimals. I then assigned it as the rounding profile for material 130479T for sales area 1100/90 in field MVKE-RDPRF. Even this did not round the delivery quantity in the STO

2. If the delivery needs to be created in terms of the Base UoM(CS) rather than the Order UoM (CS), how can this be achieved? I have tried assigning a delivery unit of 1 BOX to material 130479T for the relevant sales area in the Sales 1 view (MVKE-SCMNG) hoping that the delivery gets created in terms of the Base UoM and also rounded to a whole number of the) Base UoM. This did not work.

Your help is highly appreciated on this. Could you let me know in case I missed up on anything?

[JL23]

yes I changed the quantities in the delivery manually.

I would expect to enter the delivery unit in the sales view with the sales unit, hence in CS,  which hopefully will not allow to break a case.Which means your first partial delivery had then less quantity, just 1 case.

[Former Member]

Hi Jurgen,

The warehouse would want to ship whatever quantity that they have, even if it is in terms of partial cases (Eg. 10 CS and 2 BX) to the retail plants. Hence, they do not want to be constrained by having to ship full cases only. The only issue we are facing is that the system is proposing fractional quantities of the Base UoM (BOX) for delivery. I had put in a delivery unit in the sales view as 1 (And left the UoM field as blank. In the field help, it states that if a UoM is not entered, it takes the Base UoM into account). However, neither is the delivery getting created in terms of the delivery unit, nor is it preventing fractional units of the Base UoM in the delivery. This is the problem.

[JL23]

I bet you will not have those problems if you stop creating purchase orders in order units.

Order units is a good thing if you work with external suppliers, but it is as well an evidence for a wrong base unit if you need to use it for internal business as well.

[Former Member]

Thanks Jurgen - I have verified that having the whole process in terms of the Base UoM will remove any issues of having fractional values proposed in the delivery.

I was just surprised that this is a limitation in SAP using order UoMs which has not been noticed before. I have tried all types of master data changes to no avail. So is there nothing from a master data standpoint that we can do to avoid this error (other than changing the process to use Base UoM from end to end)? If not, is there a way programmatically (through some user-exits) to influence the rounding of Base UoM quantities at the time of delivery creation?

I do not want to give up on usage of order UoMs in the STO and the follow-on documents as it enables the warehouse to pick in terms of cases rather than pick by boxes. (As the material is usually stored in cases and moved around in cases).

[JL23]

There is a huge variety of exits for deliveries,  And my collegues are using  them a lot and we just step from one issue into the next. In many cases realized after weeks or months, causing endless troubles and reworks. What is good in one plant may effect the approach of one of the other 500, we are thinking to limited. If I encounter an error in a delivery, I fear already contacting SAP, because they first tell me that it is caused by user exit. So I have to rebuilt the case in IDES (without all the exits) to be able to say it is caused by the standard programs.

Base unit of measure = stock keeping unit

you are saying you store and  move in cases. this is an evidence that you do not like your base unit.

picking partial cases is only possible in mathematics, it is not possible physically.

if you have to pick 1.5 cases, then you physically pick 2, just one of them is not as full.as it should be.

Partials make problems in all areas of their life cycle, try to avoid partials and you have a pain less.

[Former Member]

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.