I have this client who operates in very specific conditions: majority of their vendors are foreign companies which invoice them in a foreign currency (USD) and almost invariably ask for at least 50% prepayment.
NAV can handle prepayments and foreign currencies like a charm—the issue lies elsewhere: the fluctuations of currency exchange rate can easily cause real and tangible losses.
Even though prepayment invoice is fully closed by a prepayment applied against it, the actual costs of goods is not calculated from prepayment invoice, but from the actual invoice. And if there was difference between currency exchange rate at prepayment and invoicing dates, the inventory value reflects the actual invoiced value (instead of the prepaid value), there is currency exchange gain/loss which is fictitious, but taxable.
I’ve just got a call for help from a partner, about their customer who has decided to move from basic inventory management to full-scale warehouse management system. The question was how to post the opening balances for existing inventory quantities in flat locations to warehouse-managed ones.
I thought this might deserve a quick blog post, you can never know when someone else would want to do the same thing.
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.
It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?
Sorry for this series of totally irrelevant posts, by now you must be thinking that I am either out of ideas, or totally uninterested about the future of this blog. Neither is true, I am actually spending practically all of my time preparing for ten hours of content I have to deliver at a conference next week, and about which I hope I will post a blog in its own right.