Microsoft Dynamic AX 2009 : The Database Layer - Company Accounts

The business and system information in Dynamics AX is associated with company accounts and their interactions with the database tables. Several company accounts can share the same database infrastructure and use the same application logic. However, each company account must have its own set of data that other company accounts can’t directly access. Tables can contain information that can be reused by several company accounts. The design of company accounts involves the following elements:

• Companies A company account can be based on one or more virtual company accounts. When you add data to a table that isn’t in a virtual company account, the data is stored directly in the company account.

• Virtual companies A virtual company account is a collection of data from several company accounts that is common to all the companies and uses a list of one or more table collections to define the tables that it contains. The data in the tables included in the table collections is stored in the virtual company account. The user can’t work directly in a virtual company account, but the contents of the shared tables can be changed through the company account.

• Table collections A table collection is a specification of a list of table names. Table collections define a graph of tables that have no foreign key relationships with tables outside the table collection. Developers define table collections. Each table and view in the system can occur only once in any one table collection, but tables and views can be added to more than one table collection. A table collection stores no table data; only companies and virtual companies store data.

The Dynamics AX application runtime uses these components to provide a powerful framework for integrating and optimizing the available and required business data across the enterprise, allowing chosen processes and structures to be centralized. The virtual company feature also improves data integrity because identical information is administrated only once and doesn’t have to be saved in multiple companies. Another significant benefit is that users don’t perceive the virtual company as a separate company account because it is completely transparent to users who are using the current company account.

Figure 1 illustrates how three virtual company accounts interact with company accounts and how a virtual company account can have multiple table collections associated with the individual virtual company account. Company AAA and Company BBB share the maintenance of currencies, whereas Company CCC and Company DDD share the chart of accounts. All companies share the maintenance of zip codes and countries. The last virtual company account also shows how company accounts can use multiple virtual company accounts.

Company accounts translate the organizational structures of the enterprise into elements that can be configured using Dynamics AX applications. Building the company structures by using company accounts involves the following straightforward steps:

When you create a table collection, the foreign keys must not be part of the table in a virtual company where the key is in the (nonvirtual) company. When developing the table collection, you might have to adjust the data model to get the full benefit of the collection. Figure 2 shows the location of the table collection within the AOT and the tables included in the particular table collection.

Identification

Company accounts are identified by any four characters within the Unicode-supported character set in arbitrary combination, covering both real company accounts and virtual company accounts. So the Dynamics AX application can host thousands of companies within the same database using the same application logic. When choosing identification characters, be aware of characters that can affect the generated SQL statement (such as reserved words, !, ‘’ and “”) because the company identifier is an important part of the statement.

The DataArea table the application runtime uses when saving data stores information about company accounts. The SaveDataPerCompany table property determines, on a table level, whether data should be saved per company or exist as general available data without company account affiliation. If the property is set to Yes, the DataAreaID column is applied automatically for storing the company account reference.

The data flow diagram in Figure 3 illustrates how records are evaluated before they are inserted into tables. The process for inserting records into non-company-specific tables is important to recognize because data is related across companies, installation, database, AOT, tracing, or OLAP and is therefore accessible from all company accounts.

Changing the Company Account

You can change the company account context at run time by using multiple methods, but you can also change the context at startup by using the configuration utility or by adding a company parameter directly in the application shortcut. Within the application runtime, users can launch the selection form to change the context by double-clicking the company name in the system’s status bar or by clicking File\Open\Company on the menu bar.

Changing the company account from within the code is even more interesting when working across company accounts, such as with consolidations, sales between operations, or multisite planning. MorphX supports changing of the company account by using the changeCompany function in X++, which also exists as a reserved keyword. The changeCompany statement alters the database settings to another (separate) company account. Here is the syntax of the statement.

changeCompany ( expression ) { statement }

In this statement, expression is a string that defines the company to be used. The statement is executed on the new company. The following code example shows how to use the changeCompany statement.

static void main()
{
    CustTable custTable;
    ;

    // Assume that we are running in company 'dat'.
    changeCompany('dmo') // Default company is now 'dmo'.
    {
        custTable = null;
        while select custTable
        {
            // custTable is now selected in company 'dmo'.
        }
    }
    // Default company is now set back to 'dat'.

    changeCompany('int') // Default company is now 'int'.
    {

    // Clear custTable to let the select work on the new default company.
        custTable = null;

        while select custTable
        {
            // custTable is now selected in company 'int'.
        }
    }
    // Default company is now 'dat' again.
}

					  

The changeCompany function is heavily used by the classes tagged InterCompany*, but you can also find it elsewhere.

External Accessibility

You can access the company-specific data in Dynamics AX from external sources by using COM Business Connector or .NET Business Connector and the X++ application logic for extracting or modeling the required data sets, or by using the Application Integration Framework (AIF). You can also access the data by interacting directly with the database.

Consultants often prefer to work directly with the database because they usually know the database tools well but sometimes don’t have experience with Dynamics AX. This approach can be challenging, however, if virtual company accounts are part of the company account data set. The database doesn’t include any information about references between company accounts and virtual company accounts.

You can use business views to expose a collection of data as self-contained database views that provide an accurate picture of a company’s status translated into human-readable format. Using business views can also provide valuable details about natively calculated fields (based on either edit or display methods), numeric field values, grouping of data, and company accounts, thereby increasing the data visibility for external parties. The Dynamics AX administrator defines and populates the business view to the database for further external processing. Creating business views doesn’t necessarily require changes to the application logic or Data Dictionary because the views are created from the application side and are data driven. Business views use existing tables and views from the AOT, but they create new database views within the same transactional database that the application runtime uses.

Here is the process for creating business views: