Eliminating SAP Unit of Measure Rounding Issues:

A Fresh Look at an Old Problem

David A. Beldyk                                                                                                                                                                                                                                                                                          IT Application Manager                                                                                                                                                                                                                                                                             E. I. DuPont de Nemours, Inc.

 

© 2013 David A. Beldyk

 

Abstract – This paper provides a step by step approach for eliminating rounding issues during SAP Unit of Measure (UOM) conversions.  Using plain language and simple graphics, this paper explains in an intuitive and easy to understand manner how SAP UOM conversions work, and why and how rounding issues occur.  Armed with that knowledge this paper then lays out a step-by-step, robust approach to systematically prevent rounding issues by design.  Amongst several other techniques, this paper takes on the challenging task of explaining how SAP internally calculates UOM conversion factors based on the mathematical technique of Continued Fraction, and provides a practical tool built on that technique which readers can use to perform complex UOM calculations.  By careful application of the principles outlined in this paper, readers should be able to eliminate most of the troubling rounding issues normally encountered in SAP.

(See attachments)

To report this post you need to login first.

26 Comments

You must be Logged on to comment or reply to a post.

  1. Stefan Weisenberger

    Hello Dave,

    this is a discussion we often have, and I appreciate your insights and ideas on the topic.

    One additional approach I often see in the mill industries is the combination of calcutation and measurements. For example, in metals customers would calculate the weight of a steel tube by its dimensions and a “theoretical” density.

    This would result in a “theoretical” weight (e.g. KT, aka calculated kilogram) – which typically is used as base uom, for valuation, reporting etc. The dimensions are typically attritubes (or characteristics). The mathematical formula to calculate the volume and weight is most often in an object dependency (or even in an own custom function module). This would be a good place to do some smart rounding, calculation of conversion factors etc.

    In most cases, customers would additionally create another unit of measure in the material master. This is the actual, measured weight – typically in KG (here in Europe :-).

    There are several motivations for this second weight unit – and I hope the experts will add on this one:

    • The theoretical weight might be awkward for the business. You may calucate 9.999 KG as a weight for one piece. On any end-customer facing business document, you may prefer to print 10 KG.
    • You scale may actually measure slightly more or less, and you need to capture this e.g. per batch to be exact for delivery papers etc.
    • Some customer may even use this, to play with valuation and use a different theoretical density in buying and selling goods.

    So, once again – thanks a lot for this very helpful article. I still hope for a day when every country will be “metric” and use one currency. Until then, there’s a lot of rounding to counter.

    Stefan

    (0) 
    1. Dave Beldyk Post author

      Hi Stefan,

      Good builds!  Yes, you are quite right in saying that many times theoretical calculations are preferred.  The good news is that the techniques described in the paper are indifferent to the source of the weight.  So whether it comes from a scale, or a theoretical value from a shop floor system, or a theoretical value derived by an SAP object dependency, it doesn’t really matter.  The key thing, as you pointed out, is that you need to do some “smart rounding” to avoid rounding issues.  And it doesn’t always have to involve imperial to metric conversions.  For example, consider the case where a company makes pipe sold at various ODs and lengths.  Let’s say one particular OD weighs 0.375 KG/M and they sell it in standard lengths of 1.000 M, 1.250 M, 1.375 M, and 1.500 M.

      The traditional approach is to define the M to KG conversions based on a single global standard (in this case 0.375 KG/M).  Converting that to SAP conversion factors we get 1000 M <=> 375 KG.  But when we look at inventory based on this technique we see the following:

      Material

      Length

      Length

      (M)

      SAP

      Inv.

      Qty.

      (KG)

      DENOM

      Alt

      UOM

      NUM

      Base

      UOM

      SAP Inv.

      Qty.

      (M)

      Material1 1.000 0.365 1000 M <=> 365 KG 1.000
      Material2 1.250 0.456 1000 M <=> 365 KG 1.249
      Material3 1.375 0.502 1000 M <=> 365 KG 1.375
      Material4 1.500 0.548 1000 M <=> 365 KG 1.501

      So right away, even based on a single length of pipe, we immediately encounter rounding issues with Material2 & Material4.

      To avoid this problem we could apply the techniques described in the paper and calculate slightly different conversion factors for each material.  To do that we again start with the global standard, and use that to calculate the weight for each material.  Then we establish material specific UOMs based on the input length and weight.  In this particular case, since the math is easy, we can derive those by inspection like so:

      Material

      Input

      Length

      (M)

      SAP

      Inv.

      Qty.

      (KG)

      DENOM

      Alt

      UOM

      NUM

      Base

      UOM

      SAP

      Inv.

      Qty.

      (M)

      Material1 1.000 0.365 1000 M <=> 365 KG 1.000
      Material2 1.250 0.456 1250 M <=> 456 KG 1.250
      Material3 1.375 0.502 1375 M <=> 502 KG 1.375
      Material4 1.500 0.548 1500 M <=> 548 KG 1.500

      This is a little more data maintenance work for sure, but it does result in nice, clean, rounding-free inventory.

      I hope this helps.

      Dave

      (0) 
      1. Stefan Weisenberger

        Hi Dave,

        I would like to add a few thoughts that came up after I read through your paper a second time, and I am curious if you ever applied some of these as well.

        In variable size products – which we have most of the times in the mill products industries – we typically define the material master by attributes – so length, width, thickness would be characteristics. We use these characteristics both in variant configuration to model the demand spec in the sales order, and as well in the batch classification to model the actual production result, the “real” roll (which typically differs from the planned roll).

        Already in the sales order you can influence the conversion factor through object dependencies and use ABAP function calls to optimize the conversion factor e.g. with ROUND_TO_FRACT5 and related modules.

        Paul Barney has presented this during the 2012 North America Conference of the SAP Configuration Workgroup.

        Equally, you can use these object dependencies in batch classification.

        This is not as beautiful and as “verifiable” as your Excel spreadsheet, but can be automated quite well.

        Hope this helps as well,

        Stefan

        (0) 
        1. Dave Beldyk Post author

          Stefan,

          Actually no, I did not take this function into account, but I am intrigued by the concept.  Let me do a little homework and self-educating and I will then circle back with you.  Thanks for making the connection between the two thoughts and bringing it to my attention.

          Dave

          (0) 
        2. Dave Beldyk Post author

          Hi Stefan,

          As you suggested, I have read Paul Barney’s paper.  Very helpful document.  It gave me a few function modules (CONVERT_FRACT5 and MURC_ROUND_FOR_FRACT) and a few OSS notes (362932, 391710) to chase down and digest, which I will do shortly.  That paper and your question to me also got me to thinking.  Although I haven’t tried to use either of these function modules yet, from what I read, it appears that I should be able to pass a ratio and return a numerator / denominator pair.  My thoughts on that are:

          –     – For a variant config material, which is dynamically created during a sales order, this seems perfect. 

          –     – For a variable size product, which uses batch specific UOMs, this seems unnecessary because BS UOMs perform this operation automatically via the Product Unit(s).

          –     – For conventional products I do not see this helping much UNLESS it is possible to call these functions during material creation, perhaps through an application like BODS.  If that is possible, this could have widespread applicability for everyone!

          –         

          Do you or anyone else who wants to join the discussion know if either or both of the above mentioned function modules can be called by BODS?  If so, does anybody have experience with that?

          Thanks,

          Dave

          (0) 
        3. Dave Beldyk Post author

          Stefan,

          I’ve done some more investigation of the function modules.  First, it appears that CONVERT_FRACT5 is not active in our system.  Any chance I have the name wrong?  Second, I have run MURC_RUN_FRACT and I must say I am less optimistic about it’s widespread use than I was previously.  It seems to be overly restictive in always attempting to determine the closest approximation of conversion factors with a denominator composed exclusiively of prime factors 2 and 5.  Consequently is often skips over other exact results in an effort to satisfy the “2 and 5” constraint.  I would have preferred to see logic that first looked to find an exact result, and if that was not possible, then look for an approximate result.

          But if there is one thing I’ve learned about SAP over the years it’s that there is always some logic behind every decision.  I just don’t happen to understand the logic applied to this situation.  Well… not yet anyway.  I’m hoping others may be able to explain it to me.

          Thanks,

          Dave

          (0) 
          1. Stefan Weisenberger

            Hello Dave,

            sorry for taking to long to respond.

            Whether you use CONVERT_TO_FRACT5 or MURC_ROUNDFOR_FRACT depends mainly on whether the batch specific unit of measure is defined with decimals or not.

            Both modules deliver slightly different results – as described in note 362932.

            But this is clearly a consulting issue and depends on what the respective use case is.

            Thanks,

            Stefan

            (0) 
            1. Dave Beldyk Post author

              Hi Stefan,

              I did a little more investigation on the function module CONVERT_TO_FRACT5 and found that it is not RFC enabled so we likely will not try to call it from BODS.  Still it could be helpful if called from MDG, but it will be a while before we make that determination.  I just wanted to close that loop with you.

              Dave

              (0) 
        4. Dave Beldyk Post author

          Hi Stefan,

          I just wanted to let you know that we did have the name of the function module incorrect.  The proper name is CONVERT_TO_FRACT5, and it does indeed give equivalent results.  I’m going to see if we can call that from BODS and make that part of our master data set-up process.  Thanks for the lead!

          Dave

          (0) 
  2. Gina Costa

    We actually implemented a Variant Configuration solution with some simple pfunctions within sales order entry (Imperial vs. Metric lengths) — it takes care of the rounding there, so all follow-on documents are in base unit of measure (no decimals) and then we display the characteristics on outputs for the alternate quantities that the customer requested.

    I’d love to share our basic design, but I don’t know how to attach a Powerpoint here.  If someone would explain how, I would be happy to share!  I actually presented our solution at a VC conference in Chicago in April and I’ve shared our design with Brian Dickenson as well as Paul Barney.

    It’s an alternative to what Dave presented considering his document stated that if you have materials with inventory, open transactions, etc. with Imperial, you can’t use his techniques for conversion to Metric.

    Gina

    (0) 
    1. Dave Beldyk Post author

      Hi Gina,

      Very interesting.  I’d love to see it!  I belive if you save your file in XML format (and there are several other formats you can use) I think you will be able to insert it as an image (the camera icon).  Looking forward to see it.

      Thanks,

      Dave

      (0) 
      1. Gina Costa

        When I used the camera button to insert my file, it tells me the file format isn’t allowed.  I tried XML and .pdf formats.  Any other ideas how I can share what I have?

        Gina

        (0) 
        1. Dave Beldyk Post author

          Gina,

          Well I think JPEG format will work, but I hope you don’t have to save each slide as a separate file.  If you don’t like that, or can’t make that work, you might try searching in help, or we can take the discussion off-line in email.  But of course the drawback to that is you only get to share it with me, not the whole community, so I know that’s not really what you want to do.  Sorry I couldn’t be more helpful, but now you’ve got me thinking as well.  I’ll keep poking around, and if I do come up with something, I’ll circle back with you.

          Thanks for trying and good luck.

          Dave

          (0) 
          1. Gina Costa

            Dave Beldyk – my email address is in my profile.  Please message me and I’ll send you the file directly.  It’s been suggested to me that the only way I, as a user (not an SAP employee), can upload my file is to paste in my text as document and attach my screen-shot images separately…which will completely be confusing and not flow like my presentation.

            I will send you the file as a .pdf.

            You’re right, I’d rather not take this discussion off-line in email, but it seems to be the only logical option at this point.

            Gina

            (0) 
            1. Stefan Haag

              Hi Gina,

              you can sent the file to me: Stefan.haag@sap.com.

              Only SAP employees are allowed to add/ publish appendix files to blog postings.

              Sorry for late response. I did not see your last statement.

              Greetings,

              Stefan

              IBU Mill Products

              Solution Management

              (0) 
  3. Brian Grant

    I have read this file before and it is very good; however, when I came back to reference it, I also could not view the file.

    Please fix the issue.

    (0) 

Leave a Reply