Manufacturing quickie

Today, I got an e-mail from a reader of this blog, who asked me to help them with an actual problem on a project. Their customer is a small manufacturing customer in textile vertical. Whenever they calculate consumption, quantities for certain items get rounded to full numbers. Since the items are usually textile, measured in meters, a consumption of 1.27 meters can end up registered as 2 meters instead. Not that it’s something which can’t be overridden manually, but it is pain in the butt, and hey, why do we have computers in the first place if we have to do their job.

Most of you probably giggle at this point in disbelief, why do I blog about this, as if I rediscovered sliced bread. As much the matter is simple, it definitely isn’t simple to a person who encountered this for the first time in their life. When I decided to start this blog, I promised to myself that I am never ever going to write about something which is covered directly in the documentation, or to the best of my knowledge already available somewhere in the cloud. So before writing this post, I checked about this, and to my surprise, it really wasn’t documented (satisfactorily) either in Help, or available courseware. That’s the first reason I write this.

The second reason is a tragic story, of which I was a protagonist several years back, which forever changed the way I approach people who ask me questions. I was a rookie in Microsoft Dynamics NAV, and at the customer I had a problem with inventory costing, way beyond my capabilities at the time. So I approached a senior consultant, an expert in costing, to ask him for help. The only help I got was an abrupt: “I wasn’t born with that knowledge!”.

Ok, let’s get to the point. Have you noticed how easy it is for me to drift away from the point? Well, if you did, here’s the way to get to the point, in case you want to.

The reason why consumption journal rounds quantities to whole numbers is that it takes the value Rounding Precision from the item card:

Item Card (3)

Help isn’t too helpful about this field. It says: In this field, you can specify how quantities of this item must be rounded in the various calculations that involve the item. If, for example, the item is available only in indivisable units, enter 1 in this field. It doesn’t bother to explain which are these situations, and yes, it comes with the spelling error.

Default value for this field is 1, which according to the help means that whenever you do various calculations with this item, you get your results rounded to the nearest integer greater than calculated value. This field is so easy to oversee when configuring the system, because Replenishment tab, Production column is rarely visited for raw materials, and even less frequently if you don’t replenish your inventory automatically.

Anyway, if you want your consumption journal not to round up all the component quantities, you need to put the lowest desirable precision into this field, or you put 0 if you don’t want any rounding at all. When you give it a thought, I don’t see why the standard system forces any initial value for this field, because the assumption that components are going to be measured in pieces, or any other countable whole units for that matter, is less safe than the opposite. I’ve worked for six different customers in six different manufacturing verticals, and only one of them had items measured in countable units as components, so in my experience you are far more likely to end up not requiring any rounding. In case this is the case, you can design table 27 Item, locate the field Rounding Precision, and set its InitValue property back to its default value of 0.

Thought of the day:
To err is human. To really screw up you need a computer.


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 3 Comments

  1. Dave Roys

    Hi Vjeko. It’s scary that when I was at work I thought of writing about the F5 F4 incident and how poor the C/AL editor was in general. When I got back home I was shocked to see that you had also blogged on the C/AL editor. At first I thought you had cunningly installed some kind of spyware on my computer through my blog. OK so that’s not true and it makes me sound mad, but you have to admit it’s one hell of a co-incidence that we both blogged on the same topic within a few hours of each other. I read your posting first and the other scary thing was the points you made about rules for good programming were exactly the points I needed to consider when a new programmer started a couple of weeks ago. So I decided to include my thoughts on that in the blog inspired by your blog.

    I like reading your blog. It’s a shame more people don’t comment on blogs as I think this makes it kind of fun. Keep up the good posts.

  2. Tatjana Pecek

    Hi Vjeko,

    Thank you for your advice it was very much helpful form me. I did exactly what you told me and now it works. I really thought the solutions is very simple but I couldn’t think of anything. I studied Manufacturing I and Manufacturing II and Inventory but I can not remember that I read that anywhere. Now I am even more sure when you said that you checked in courseware.
    Good, I didn’t miss anything 😉
    So, I have to say again, I really like this blog and I very much enjoy being here.
    And it’s kind of great that here is not lot’s of people, it’s like one small community.

    Thank you Vjeko,

    See you.


  3. Bhushan

    Very helpful.


Leave a Reply