A few days ago, I’ve got a question from a customer, about an alleged bug in Microsoft Dynamics NAV. According to online help, when you are posting output in manufacturing module, the last line of the type Output in the journal will actually adjust the inventory level. However, what is not explained is how the figure in this field is calculated, and why exactly that way.
When you decide to post an output of a production order, you specify the released production order for which you want to post the output, then call the function Explode Routing. After this function completes its chore, users unfamiliar with how manufacturing works can get quite confused, because two of the fields the procedure fills in contain unexpected values. These two fields are Output Quantity, and Scrap Quantity.
Field Output Quantity contains the quantity of the item that got out of the operation, and Scrap Quantity contains the value of unusable items that got out of the operation. When you explode the routing, field Output Quantity gets the value from the field Input Quantity from production order routing line, and field Scrap Quantity gets the value of zero. And users may see this as a bug.
However, it’s not a bug. And it is also logical that it works exactly that way. Most of the theory behind why this works the way it does I explained in my two previous posts, Scrap doesn’t just happen and Cut the (s)crap, but in order to understand how exactly Microsoft Dynamics NAV works, it is important to understand a single field which users sometimes have a lot of trouble with. That field is called Input Quantity.
Input Quantity equals the requested production order Quantity, plus all the scrap, fixed and running, on the operation. If you assemble 1,000 bicycles, this is pretty straightforward. You may define a routing which specifies 1 unit of fixed scrap and 1% of running scrap on all operations. Regardless of components you put into operations, the fixed scrap and running scrap are always expressed in produced item and its base unit of measure. So, if first operation is called Wheel Assembly, and you feed components of a wheel into it, when you look at production order routing, and it says that the input quantity is 1,044.6.
It means, that the input of the first operation is 1,044.6 bicycles. It has nothing to do with the components, in this case wheels or their parts. It means, that with current routing setup, in order to get 1,000 bicycles out of your production process, you must expect that 44.6 bicycles are going to be scrapped. These 44.6 bicycles probably aren’t going to be scrapped in the way you are going to throw them out the window at some point. Rather, this figure is used in order to be able to plan your material requirements. So, instead of planning for 5,000 bolts (in case you need 5 bolts per bicycle), you must increase the number of bolts by 5 x 44.6 = 223 bolts. Which means that in order to assemble 1,000 bicycles, you need to have 5,223 bolts ready. Not that you are going to throw 223 bolts away, but you just might end up throwing them away, so you better have them handy, just in case.
But when expressing the input quantity of an operation, you can’t add wheels, and bolts, and brakes and whatnot to get a uniform number. You have to express the input quantity in exit units. Which is bicycles in our example. So, input is always expressed in exit unit.
When you setup your routing as in the example above, the last line of output journal will look something like this:
As you can see, Output Quantity on the last line is 1,011 and Scrap Quantity is 0. However, the requested output quantity of the production order was 1,000, and 11 is exactly the calculated scrap for last operation (1% of running scrap over 1,000 total, plus 1 unit fixed scrap). So, why doesn’t Microsoft Dynamics NAV simply put 1,000 into Output Quantity and 11 into Scrap Quantity? This must be a bug!
Well, not exactly. Your operation is expected to give you 1,000 units of output, and at the same time it is expected to generate 11 units of scrap, however, the actual process is not guaranteed to do so. As far as the system knows, 1,011 bicycles will come out of the last operation, useful or not. It is the responsibility of the user to enter the actual Output Quantity and actual Scrap Quantity. What if your process didn’t cause any scrap at all? Or what if it caused more scrap than expected? Scrap is not simply (s)crap. Scrap is there to help you with planning, not to define the execution as if it was Holy Scripture.
So no, there is no bug in Microsoft Dynamics NAV in filling out these values. But confusion doesn’t necessarily end here. When the system fills the output journal as in the picture above, it is your duty to fill in the values for Scrap Output, and adjust Output Quantity. Total quantity is not Output Quantity but Output Quantity + Scrap Quantity. So, if you simply put 11 into Scrap Quantity, and leave 1,011 in Output Quantity, total base quantity for this operation will not be 1,011, but 1,022, and output of 1,011 will still be posted into Item Ledger.
So, in order to have correct numbers in both your Item Ledger (used to track your inventory), and your Capacity Ledger (used to track your capacity usage), you must manually fill actual information into Output Quantity, and Scrap Quantity. And remember, base quantity (or total operation quantity) is output + scrap, not just output.
But why doesn’t the system suggest the expected values, why does it suggest these “incorrect” values? Well, expected values are usually as incorrect as these act-as-if-there-were-no-scrap values. The only correct values are the actual values, and the system has no way of knowing them. So, I figure that by putting input values into output, and leaving scrap empty, system will make more pressure on the user to feed in correct values, than it would if it simply put in expected values and gave users confidence that they don’t need to take care of these fields at all.