Work with the standard data model
Every application area in Business Central follows the same principles and has a similar data model. Master, subsidiary, document, journal, ledger, and other tables all have the same role. Certain patterns are applied consistently across all application areas. Depending on the types of patterns, you can follow certain code patterns in all tables of the same type.
The consistency of the data model and data flow patterns is important for users and developers. When users master one application area and understand data model principles, they can also quickly understand other application areas. As a developer, when you understand the principles of data models and patterns, you can customize the standard application. You can also build new application areas and maintain a consistent experience in the standard application. This capability helps ensure that users are as productive as possible.
Every application area contains three groups of tables:
Configuration
Operational transaction
Posted transaction
Configuration tables
Configuration tables are static or slowly changing tables where users enter information one time and then rarely, if ever, change it. The application uses these tables during creation, modification, or deletion of records in other tables, such as transaction tables. These tables are frequently checked by various processes, such as posting. Changing information in these tables changes the way that data is processed or alters other aspects of the functionality of an application area.
Operational transaction tables
Operational transaction tables are the primary work tables for users. Users enter information in these tables regularly. Adding, changing, or deleting information in these tables typically does not affect the application or the business.
Posted transaction tables
With posted transaction tables, information is generated automatically by the application during posting and similar processes. Users can't create new records in these tables and can't change or delete records. A few examples exist in which users can change or delete information. All of these examples have clear business logic justification.
The following diagram explains the relationships of various tables in a typical application area.
