Dynamics 365 Business Central contributes to become real professional developers throughtout the whole application and encourages us to think developments like a general app to be deployed in several customer enviroments. They has to be a common base for furthers development making us to change our mindset. A customer request should not be seen as something inherent to a client but as something that has many points in common for all of them.
In my beginnings in NAV, i remember that the way dimensions works caught my attention. I was struck by how the name of these fields “Global Dimension 1” and “Global Dimension 2” were managed and how they changed their captions based on a configuration made in general ledger setup.
A recurrent requisition entails us to create new fields in master tables in order to clasificate data. Categorizate Customers, item features, invoicing ways… Usually to make that we create needed fields on master tables and fill their captions. That’s not bad and if there ir further logic to implement this is a good way to take but this wake implies a low capacity to code reuse.
One day i began to review how dimensions work focusing in achieve this way of work to make a common base app to create this fields. Customers will be able to configure all their classification fields.
Now, i will show you the output:
First of all I show the configuration. It consists of two tables with different fields that manage the different possible fields of the master tables and their possible values:
Third column is used to fill the field caption and fourth column references a field on the Customer or Vendor table.
To manage values of that field i have another table with values. It is the way Dimensions work:
Thus, the configuration is simple and the optimal result:
The caption management is carried out, in Business Central, through Codeunit 42, the event «OnResolveCaptionClass».
This way of development, as opposed to creating the field in the table with the desired caption, obviously takes more time. We must take into account everything that can be done based on this development. Making an extension, based on this, in which instead of code-type fields were numerical, it does not entail greater difficulty.
Other extensions could be made in order to extend its functionality. Some examples could be: Transfer values to document and entries tables or use the values to implement any business logic that is required (maybe this is out of place).
We must change the mentality of the particular to the general, base extensions that must be extended to grant that particular functionality that is required by a client.
In order to be able to do everything detailed, as I mentioned, the “OnResolveCaptionClass” event of codeunit 42 is used so that we have the subscription:
Field caption management:
New fields in a Customer tableextension:
And finally, the customer card will use, in new fields, “CaptionClass” property that is the one that manages the return of the function used in codeunit 42 (The Visible property is managed based on the fact that there is configured each classification):
