Setup tables vs Master Table attribute: think globally (with an example)!
Before making a customizazion, we should always try to understand if the solution we thought to solve the specific customer's problem can be "extended" to solve similar but not identical requisitions. We could say in other words: think globally, act locally. This is particularly true if the purpose of our work is not simply making a single customization, but to create an app that can be virtually downloaded by many customers in the world.
In this post I would like to focus the attention about the role of the Setup Tables in Business Central. As you know, every module in the application has its own setup table, so we have the Sales & Receivables Setup table for Sales and Marketing module, the Inventory Setup table for Inventory module, General Ledger Setup for General Ledger and so on.
These tables are very important for Business Central, because are the first place in which you have to go when you want to activate a module. The main concept is that their role is to contain parameters that set the behaviour of the entire module.
But when we take a look at the standard application, we often find some fields appearing in a setup table and as an attribute of a master table.
As an example we can see the field Dampener Period defined in the Manucfacturing Setup table
and in Stockkeeping Unit table
As you can understand just by the field name, the first is used as a default value for all the items, the second one is specific for an item (variant) at a specific location.
In this way, the application can cover different requisitions: a customer having just one dampener period to be applied to all the items, a customer having different dampener periods for different items, and a customer having most of the time a default dampener period but with some exceptions.
A practical example
Let me give you know a little example by starting from a requisition. Suppose you need to create a procedure that must create a Purchase Order for a Vendor making some works for you and inserting its hours in a time sheet table: we read the time sheets by vendor and period and we create the order.
When we create an order, we always need to specify on the line what we are buying: an Item, a G/L Account etc.
For our purpose we can now think about a first solution: place this information in the Purchases & Payables Setup table, like this (suppose we want to use an Item used as a Service):
Below are the table and page extensions created:
Now, let's try to think globally: this solution can be useful just for customers using one item for every possible vendor they have. So this can cover just one scenario.
Ok, now the second solution could be to add the same field at the Vendor level, like this:
I this way we can cover the scenario in which a customer has different items for different vendors.
But taken alone, this second solution is terrible for the first customer, having just one Item for all the vendors, because they need to insert the same item on each vendor card. Really bad!
So now we can think about the third possible solution: using the setup field as a default item, and the vendor field as a specific item to be used just if you need it.
Below you can see the example of the procedure (please note that I used the Error instead of Testfield...):