Blog

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.

So, what are setup-dependent requirements? It’s those functional requirements that depend on a specific type of setup, and when functionality is developed if that setup is changed, you can’t support the new setup, but have to actually reprogram the functionality to be able to continue working properly.

And here I am not referring to small configuration changes—things like requirement depending on Automatic Cost Posting or Register Time configuration settings. Of course if the customer wants automatic cost posting to occur, that the functionality will stop working as expected if you switch it off. I am actually referring to setup.

There is a subtle difference between setup, and configuration.

When I refer to setup, I use the word setup as in Posting Setup. Or as in User Setup. VAT Posting Setup. Approval Setup. That kind of setup. Those table that end in Setup but don’t sport the Primary Key field. Or those kinds of setup where you enter a value, instead of selecting an option or turning on a checkbox.

Having logic depending on configuration switches (this is what I prefer calling checkboxes and options) is of course good. If you have logic which works when a boolean switch is on, then of course it won’t work (or at least it shouldn’t) when the switch is off—that’s kind of expected.

But having logic depending on setup values, something like business logic supporting only one specific combination where normally NAV can support many different combinations, this is wrong. That’s kind of a point of those setup tables (especially posting setup): enabling multiple value flow paths through NAV’s ledger bloodstream. Having code actually depending on it that it supports only one possible path, is just plain wrong. Think of a sales report ignoring currency exchange rates, because all the customers are domestic. Or a report which shows sales, but ignores invoice discounts, because only line discounts are used. What happens with your first foreign customer? What happens if you decide to start offering invoice discounts.

Things like these are not always simple to spot, they may be disguised awfully well. And they are patient. They know their turn will come. Tomorrow, or in two years, doesn’t really matter. They lurk deep in the obscure corners of C/AL and wait, because they know you will extend your setup. They know you’ll want to add that new posting group. And then the fun is going to be all theirs.

So I didn’t comply.

I told my customer that this would be a bad practice, and that the design had to be changed. It’s a small change, after all, at this point. But might be days or weeks of goose-chasing through general ledger in the future.