While designing a custom functionality for a customer, there was an issue with posting groups: the way the custom functionality was designed would result in value entries being always posted to a single posting group, resulting in inventory balances always going to the same inventory account.
When I brought this issue to my customer’s attention, they said: “but we only have one single inventory account, and we only use one single posting group, so we don’t need this functionality to be smart about this”.
This was an example of what I like to call setup-dependent requirements.
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.
Microsoft Dynamics NAV Classic client has some features which are simply unbeatable when it comes to productivity and speed, one of them being primary-key filtering. When you set a single-value filter on primary key fields in a table, and then insert a new record in the same table, primary key fields are automatically populated with values from the filter.
Well, there are so many ways to (ab)use this feature, that sometimes it has a potential to save ridiculous amounts of time. As it just did for me, so I felt an irresistible urge to share it with you. Even though it is so ridiculously simple.