We know that customer requirements can be translated into different possible solutions. Before starting writing AL code, we should try to understand the impact of each of the possible solutions we have.
I would like to give you an example of this by making a little customization and showing what could be the correct approach.
Let's start from the requirements: the customer needs to close a location, so it wants to be sure that after transfering all the items to the other locations, no one could be able to post inventory transactions into the old one.
We can start by adding a new boolean field into the Location table, called Blocked
Now, before doing any other customization, we need to answer a main question: how should we manage the checks?
We can think about three possible solutions:
Block the user everytime it chooses a blocked Location
Block the user when it tries to post transactions in a blocked Location
Apply all of them (1 + 2)
From the end user point of view, the best solution should be the first, in which it is blocked at the same time in which it tries to select a blocked Location. But this has two problems:
Backlog orders: if there are opened orders which refer to a blocked Location, the user will never be blocked. We have also to consider that the Blocked field on the Location card can be changed after the user inserted the order.
We have too many tables containing the Location Code to be modified. Just as a first view, think about the main ones: Customer, Vendor, Sales Header, Sales Line, Purchase Header, Purchase Line, Item Journal Line etc. This solution is too complex to be applied.
From the developer's point of view, Solution 2 is the best one: just one object to be modifed in order to be sure that every inventory transaction will be blocked if the Location is blocked.
Obviously this solution is not so good from the end user point of view: try to insert an order made of 100 lines, then block everything just at the end, during the posting, then ask yourself if this can be acceptable.
Please note that in any case, Solution 2 must be adopted, otherwise you will never be sure about transaction consistency. This point is important to understand:
Checks must always be placed in the posting procedures
Managing them at the data entry level improves the end user experience, but does not guarantee data consistency. That's why in Business Central you find the same checks at table levels and at posting levels.
So probably the best solution can be the third one, but with checks on the Location placed just on the most used tables, first of all Sales and Purchase Header/Lines.
Below you can see my code to manage this solution. Please note that it does not cover all the possible scenarios.
コメント