Decimal quantities in delivery split

[palhota]

Hello,

During the creation of an outbound delivery from a STO and subsequent delivery split, some of the items aquired decimal units. For example, one item in the STO had 2 CRT and the subsequent split converted it to 37.992 EA (instead of a round 38 EA). Or  even an item with 0 CRT was converted to 0.009 EA.

Fearing this could become a recurring situation, what would you recommend as a preventive measure to solve this situation?

Only tomorrow will I be able to enclose scrrenshots, so I'm hoping I was clear enough to start a discussion.

Many thanks

DP

[JL23 · Accepted solution]

A stock transfer between to plants is a very close relationship, it  happens in one SAP system, where both partners work with. It is not like doing business with an external vendor where you cannot really influence many things. But in your own system, why is it needed to order or ship  in a different unit than the base unit?

Physical quantities are always posted accurate to 3 decimals in SAP

And for this case " 0 CRT was converted to 0.009 EA" I would really like to see a screen shot, as I do not believe that you can order 0.

You probably just see 0 CRT in MMBE, because decimals are not displayed, or the mathematical conversion does just not have a number different than 0 at the 3rd decimal place.

[palhota · Accepted solution]

Forgot to mention we are working in a dWM scenario. Where the stores are on the main ERP machine and create STO and subsequent outbound delivery which is then transmitted by IDOC to the WH's dWM system. 

Although, as I noticed the problem in the delivery splits, I was able to pinpoint the origin in the creation of the picking OT. Below is the example where the item is created with 0 CX (KI) and the Quant field assumes 0.009 UN.

Message was edited by: David Palhota Changes to internal Unit of measure

[JL23 · Accepted solution]

The material is managed in the base unit  which is UN

and the WM unit in the material master is CX

Assuming (from your initial question) that 1 CX equals 38 UN then the formula is like this:

1 x 0,009

-------------  = 0,000236842105263158

38

And a quantity field (domain MENG) has only 3 decimals, hence you get 0,000 for the alternative unit CX

I think this delivery split is just a follow on problem to an earlier posting which left these fractions in your stock.

So you would need to analyze when this began.

And you certainly need to do something to stop this.

Looking again into you initial question, you wrote "37.992 EA (instead of a round 38 EA)."

What is your conversion ratio between CX and UN?

Is it really such crooked? How can that be for each in crates?

[palhota · Accepted solution]

First of all, addressing your questions.

Looking again into you initial question, you wrote "37.992 EA (instead of a round 38 EA)."

What is your conversion ratio between CX and UN?

Is it really such crooked? How can that be for each in crates?

The conversion rate for this article is 1 CX <=> 19 UN. And yes, th stock is quite crooked due to the fact that the conversion rate changed at a certain point. But in the meantime, we must guarantee that these decimals don't seepin to the outbound deliveries. Even though the stock is crooked, what I can'tunderstand is how a TO created with 0 CX the Quant field could assume a value of 0.009 UN.

I also can't figure out how the other conversions play out. I would assume that in the 2nd example, 2 CX would be always 38 UN no matter what.

[JL23 · Accepted solution]

What is your base unit?

[palhota · Accepted solution]

Base unit UN

WM unit CX

[JL23 · Accepted solution]

Then it is so like explained.

SAP stores the quantity in base unit. And since you have 0.009 UN  you have this quant in the warehouse. you can even double check in MMBE, MMBE allows to list the stock in alternative unit.

try it with UN and then with CX, you will see the same results. 0.009 for UN and 0 for CX.

To get out of this loop you have to count your inventory. I dont believe that you have 0.009 UN physically in your bins. Hence you need to count it to zero to get rid of this (these) decimal dust.

Nevertheless you need to find the movement that caused this fractions. Once this movement is found you can analyze the root cause and can take measures that such thing will not happen again.

[palhota]

Managed to replicate a similar situation in DEV for a different material where each CX <=> 12 UN. Created a STO and outbound delivery for 2 CX. I indicated 2 different storage bins for picking, one with decimals (0,004 UN) and another storage bin with round numbers (decimal 1st).

So it took 0.004 UN from the first storage bin and 23,996 UN from the 2nd. Besides generating a delivery split with decimals it ruined the stock of the storage bin, now with decimals.

You are most likely right, they need to perform inventory asap.

The root cause were changes in conversion ratios throughout time I believe.

Thanks Jürgen, you've been most helpful!