Skip to Content
author's profile photo Former Member
0
Former Member

Decimal quantities in delivery split

Posted on Dec 03, 2014 at 11:16 PM 362 Views

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

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    author's profile photo Jürgen Lins
    Jürgen Lins
    Posted on Dec 04, 2014 at 02:17 PM
    2

    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.

    Add a comment
    10|10000 characters needed characters exceeded

    • Jürgen Lins Former Member
      Dec 04, 2014 at 08:55 PM

      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.

    Comment on This Answer
  • author's profile photo Former Member
    Former Member
    Posted on Dec 04, 2014 at 11:01 PM
    1

    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!

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.