Future design principles for Business Central

This week has been hectic at work, but I took the time to add three fixes for issues on our per tenant extension on github. Writing this blog is taking longer.

Fix 1 addresses a long standing annoyance. If you need to apply a vendor payment in order to re-allocate it in the corresponding worksheet page only the internal purchase invoice number if visible and the actual vendors invoice number is not only hidden - it doesn't exist on the page.

Principle 1: When possible and practical use the real world reference number that makes sense to the user and hide internal references unless necessary.

Below you can see the highlighted page field added. Now if an error is made I can easily fix.

Fix 2 addresses a ridiculous (and likely buggy) decision that any purchase order line that refers to a blanket purchase order must utilise the same location as specified on the line of the blanket order. The goods purchased on blanket agreements could be destined for multiple locations and you might not know which ones when it is created.

Principle 2: Never introduce business rules that prevent an action without exploring the potential unexpected constraints you are creating that might seem capricious or unnecessary.

Thankfully the application can be extended. One would hope instead they add a configuration on the blanket agreement to ask whether blanket contracts need to be location specific- (although my guess is almost no one would request that feature).

BTW - pretty sure the actual code has a bug. If the purchase order is related to a special order you can't change the blanket contract line even if it has the same location and item, as the code forces a validation of location which triggers a preventative rule around changes related to special orders. Principle 2, notwithstanding it should only trigger those validations if the location is actually changing.