Happy New Year, everyone!
With the new year, here’s a new pattern to warm us up. Coming from a Danish partner, this pattern describes how to handle data entities when they need to be in a consistent or in a certain state before further processing can be allowed. Thank you Henrik Langbak and Kim Ginnerup from Bording Data for sharing this knowledge with the NAV developers community.
The NAV Patterns team
Meet the Pattern
This pattern prevent data from being used elsewhere before it is in a system consistent state.
Microsoft Dynamics NAV inserts a record as soon as the primary key has been set. But the record may not be in a valid state at this point in time. How do you know if a newly inserted record is ready for use?
Know the Pattern
Whenever you need to stall the release of data, you can use this pattern.
Because Microsoft Dynamics NAV decides when a record is written to the database, it may not be in a system consistent state. Nobody should use the record before everything is in place and the record is valid. An inserted record may even have data in other tables that needs to be inserted and in a valid state before other parts of the system can use the data without running into a problem.
Data entered into the system may have to be approved by a second person before it can be used.
Data requires different parties (e.g. Departments) to add information before data is valid.
The solution is an Option Field with two or three values:
(Open, Released) or (Open, Pending, Released)
The states should be interpreted as:
Not all data is in place. The record is system inconsistent. The record or record hierarchy is invisible for all other parts of the system.
The record is system consistent. But is awaiting someone to manually raise the state to Released.
All data is in place and the record is system consistent, and ready for use. It is now visible for the rest of the system. The state can never be reversed.
The option field name: Release State.
This pattern is very similar to the Blocked Entity pattern, but it has one significant difference.
The record is not visible to any part of the system, before it is in the Released state.
There is no going back. When the Released state is reached, it will stay that way for the life of the record. In case of a tri-state, it is ok to bypass Pending seen from a system state perspective.
If there is a hierarchy, e.g. Header and Lines, then the Release State field resides on the Header. As long as the Header remains unreleased, the lines are considered inconsistent and must not be used.
The important and critical part of this pattern is that the whole application needs to obey the “Release State”-contract or the system will fail.
Use the Pattern
To use this pattern you need to create an Option Field named: “Release State” with at least the two states: Open, Released.