Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!
A blog reader has asked me for help about an allegedly strange behavior of items with serial number tracking. They had a customer who had serial number tracking switched on for an item with FIFO costing method. Whenever they posted a sales transaction, they chose the serial number manually. Then they noticed a puzzling behavior.
No matter the specification of the serial number on the sales lines, Microsoft Dynamics NAV seemed to be closing the item entries according to FIFO method. This effectively allowed a serial number to be sold twice (or more). They called for help.
I’ve stumbled recently upon a support request, where a partner asked if there was a possibility to register purchases of services in Microsoft Dynamics NAV. When it comes to selling services, such as consulting, or repairs, NAV is your true friend, because you can use Resources to register sales against them. However, purchase documents don’t offer a possibility of purchasing resources, so you are left to some workarounds.
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.
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.