SINGLE COMPANY / MULTI COMAPMY IN DYNAMICS AX IMPLEMENTATAION

Many time there comes a discussion, whether to go with multi-company or a single company, when it comes the time of new implementation of Dynamics AX.
So, here are the factors, which must be taken in to consideration, before start of implementation.

 

Factor to Consider	Single Company	Multi Company	Decision point
Reporting	In single company, there is not a huge need for modification of reports/ creation of new reports.  E.g. if there are 10 Cost-Centers in a single company environment, and it’s needed to view sales order report only for cost center#5 ; this could be achieved simply by filtering the Existing Report. In short for majority of reports you don’t need to do any modification.	For case of Multi-Company, if I need to see the report for a specific cost center, I don’t need to even put a filter; because here each cost centers are basically a different company. But what becomes worse in this case; when Head Quarter (Company) need to see sales report for all cost centers/companies. Your developer need to create a new report by fetching data cross companies to show data of all companies/cost centers at one place. This is just the example of one report. In a multi-company environment, client may ask to have cross-company report for sales order, purchase order, Production order, etc. numberless reports may be needed.	From reporting point of view, single company is the best approach, in terms of less effort, by developers/number of hours.
Workflow	Workflow work fine without any problem/ any extra efforts by developers.	In multi-company one can have problem; the reason behind the problem is; Microsoft Dynamics AX Architecture allows you to have workflow batch setup only once. E.g. if you have 10 companies and you setup workflow infrastructure    in one company say company-6; you will see that this setup is done automatically in each company. The reason behind this is that as per architecture of Microsoft Dynamics AX, BatchJob (Table) has a property (Save data per company) as No. This makes dynamics ax workflow structure complex and less useful. So if you have to operate a workflow across the companies, you need to have shared table and you need to operate your workflow on that table. The examples for this can be found in PurchReqTable and TrvExpTable. Both of these table have the property (Save data per company) as No. If you want to operate some workflow across the companies, and you don’t follow the mechanism, you will be getting wrong notifications as well as security error/warning for insufficient rights. Microsoft fixed this problem for 1 workflow in CU3. https://mbs2.microsoft.com/Knowledgebase/KBDisplay.aspx?scid=kb;EN-US;2709934 But make sure that you may have your own customized business processes or even standard processes. And in case if you want to operate your workflow across the companies you will be struck in multi-company with more efforts to resolve that.	From Workflow point of view, single company is the best approach, in terms of less effort, by developers/number of hours. But if it’s must to go with multi-company, and you have some work flows to be operated across the companies you developers need much more efforts as compared to single company.
Security	For single company it’s achievable, almost any kind of security. But to implement advance security, one needs to go with options of security policies.	In multi-company, also, the security is achievable, almost at any level. You don’t need to create/develop too many security policies.	From Security point of view, multi company is the good approach, in terms of less effort, by developers/number of hours. But make sure that security is achievable in both cases(multi-company and single company)
Sequence Numbering	In case of single company you don’t have too many options to implement different number sequences for each different cost-center or business unit.	In multi-company, you have more control on number sequences, in terms of a requirement, that if customer wants different formats for each company/cost-center, you can easily manage it in multi-company.	From number-sequence point of view, multi-company gives you more flexibility.
Inter-Company Transactions	Using cost-center approach i.e. considering each cost center a company and going with a single company environment; it’s easy to achieve transactions among cost-centers/business units. E.g. to transfer inventory from one site to other, one may use simply a transfer order.	Going with real, multi-company environment, inter-company transactions need little more efforts.
Consolidation	Not needed any consolidations.	Consolidation of e.g. financial statement is needed in a single company.	More efforts in multi-company
Master Data	If your master data (customer, vendors, items etc.) is shared/ same the single company could be a good approach. Because if you have shared/ same and still you are thinking of multi-company, you need to use Virtual company accounts to share data across companies. But If you don’t have same/shared data across legal entities, it’s good to think for multi-company.	If you have shared/same master data, multi companies is asking you more effort by creating shred table collections and share those collections using Virtual Company Accounts. But If your master data is not shared/ same, across the legal entities, you have selected best approach, using a mutli-company.	If you have same/shared master data, think for single company, otherwise think for multi-company.
COA (Chart of Accounts)	If you have same chart of accounts in each company, you should favor single company, more.	If you have different chart of accounts, multi-company will make your life easy.
Business Line/Business Process	If there is same business process, in each cost-center/business unit; single company is a good approach.	In case one business unit is of pure production and other is of pure Trading, means diverse businesses across legal entities/cost centers, multi-company should be more likely the approach.

Conclusion:-

It’s always a combination of factors which should be considered, before implementation. Keeping in mind the factors an organizations (implementation partner) should decide about best approach, which may lead to accurate needs as well as least possible resources (time, number of resources etc.)