Knowing When to Create a New Company or Company Dimension Entities in Dynamics NAV
*This post was written for Dynamics NAV but the content directly applies to Dynamics 365 for Financials, which is the cloud product based on Dynamics NAV. You may notice some slight differences in the screenshots, but the information and steps are directly applicable to Dynamics 365 for Financials.
When considering how to introduce new entities in Dynamics NAV, such as companies or divisions, etc., there are a number of factors that should be taken into consideration. Sometimes, the right solution is to create a new company in NAV; other times, the better solution may be to create a new dimension instead.
Main points to consider for adding new dimension entities in Dynamics NAV:
- Accounting – Does the balance sheet need to be separated for the new entity, for FEIN or other purposes?
- Master Data – Are the charts of accounts, customers, vendors, items and other master records common?
- Subledgers – Will the new entity co-mingle sub-ledgers for common master records in NAV (sales, purchases, banking, inventory)?
- Currencies – Is the base currency in the new entity different than in the existing companies?
- External Integrations – Are there external systems that talk to NAV and that require segregation between entities/companies?
- Security – Does the new entity need to be segregated for purposes of user access?
- Intercompany Workflow – How much interplay is needed between the existing companies and the new entity?
A dialogue is almost always needed with your partner to work through and better assess the impact of the above variables and determine which option is most appropriate. That said, the highlights of that discussion are relatively consistent. The guiding principle is always simplicity (i.e. fewer companies), but not at the risk of sacrificing your ability to report on and manage the business.
Accounting
As a rule of thumb, if the new entity has a unique federal ID number, you should first consider a separate company in NAV. While it is possible to successfully implement multiple FEIN entities in the same NAV company, the other variables need to be strongly in favor of the single company model. The reason for this usually boils down to accounting, specifically the balance sheet.
Master Data & Subledgers
If you will need the ability to produce a balance sheet for the new entity, independent of the other entities in the database, the single company model starts to become challenging. In concept, you can create a new dimension in NAV, (ex: “COMPANY”), within an existing company in the database, and use that to segregate transactions and report an independent balance sheet. In reality, you will need very good dimension rules on your G/L accounts and independence in the master data.
The master data includes your customers, vendors, bank accounts and items. Because the balances for those areas reside in the balance sheet, it is critical that related transactions are segregated completely. Often, customers, vendors, and banks are unique between entities – or can minimally be managed separately. As an example, you may have a customer with which two different entities do business, but you would never expect to send an invoice or receive a cash receipt common to both entities. Therefore, a common customer could still have completely segregated history and allow per-entity reporting. Likewise, vendors and banks seldom require co-mingled transactions. On the other hand, sharing the common master records themselves, but with segregated histories, is an argument in favor of a new dimension rather than a new company.
The exception to the master data rules is often inventory. If the same part numbers are available and used in multiple entities, the balances will not be consistently maintained by a dimension – “COMPANY” or other. This prevents running a per-entity balance sheet that truly balances within the entity. If part numbers are not common across the entities, we can potentially address the balance sheet segregation requirements through setup rules alone.
Currencies & External Integrations
If we pass the first three tests above, then there are four more considerations to address. The first of these is currency. If the base currency in the new entity is different, then it should be represented by a new company in NAV – always. Likewise, if external integrations require NAV companies rather than a dimension, we must comply. An example would be separate web stores where the connection from NAV inherently presumes no more than one web store per NAV company.
Security & Intercompany Workflow
The final two considerations are security and interplay requirements between entities. If you need users to be limited to one entity, with hard limitations, a separate company is recommended. There are some tools that can help segregate security by a dimension, but they are imperfect for this purpose and require a good deal of planning and ongoing management. Counter to the security argument for multiple companies is the integration argument for a single company. If many workflows require movements (documents, inventory, etc…) or allocations across companies, then the single company model is favored. Intercompany tools exist in NAV, but the workflows are often significantly simpler if both entities reside in one NAV company.
In conclusion, the answer is seldom simple. You should plan on a dialogue with your partner and a pros/cons review of the variables described here. This exercise will inform your knowledge of the possibilities and allow you to make the most appropriate decision for your business.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.