Hi there I have worked with other software where the set up of multiple companies is much simplier than what it seems in Navision. My understanding on Navision multicompanies is that you need to set up seperate companies and then somehow post between these companies (I believe that there is something coming in ver 4). Has anyone set up multiple companies within the one Navision company and simply used Dimensions as a company code? There would need to be some inter-dimension balancing but this seems much simplier, there are assumptions such as same currency, same chart of accounts etc. Am I missing anything in my simple assumptions? Thanks in advance Derek
What about consolidations between the companies and their Eliminations how will you take care of that? Second the inventory Module will be the same for all the companies. Intercompany sales and Purchase can only be handled with an Item Transfer which cannot have a profit or margin. How will you control the security between the companies and the users, with this setup all users can work in all companies.
Derek, We decided to put our two Business Units into one company, and use dimensions to have the financial matters separated. We also use the responsibility centers to have users only working in the Customers, Suppliers, Items, Orders and so on. Only little customizing was needed to have the forms filtered on the user’s Responsibility Center.
thanks for the input guys Groeten did the companies both have inventory that you were dealing with, I can see this being an issue as the posting groups don’t give you the flexibility to assign dimension codes as well as account codes. My thinking was to have seperate inventory locations pointing to different companies. I didn’t see eliminations and consolidation as problems as you could create an elimination department/company and post a journal here and consolidations would just be reporting all companies.
Hi Derek, My only word of caution if you use one company and dimensions is to ensure that you can maintain seperate dimension values across the whole chart of accounts. Remember that you get summary postings in the balance sheet that may not be ideal. Dimensions are (primarily)a p&l reporting tool. It is possible to use dimensions in the way you suggest but you need tight controls to ensure that the integrity of your data is maintained. All things considered (security, number sequences, dimensions, stock, consolidations etc) - I would probably want to use seperate Navision companies and accept the administrative overhead that is naturally brings about. Or buy Axapta!
Originally posted by Kiwilamb
Groeten did the companies both have inventory that you were dealing with, I can see this being an issue as the posting groups don’t give you the flexibility to assign dimension codes as well as account codes. My thinking was to have seperate inventory locations pointing to different companies.
Hi Derek, Actually, Groeten is the dutch word for ‘Best regards’, my name is Michiel [:D] About the inventory: we don’t sepearte them into locations. However, this could be a right solution, imho. Probably you would need Location Transfers if you move goods between locations.
Michiel Sorry about that I noticed it as soon as I posted it!! Derek
I would be very loathe to attempt to combine two different, legal and self-balancing entities into one company via the use of dimensions. The reason is this: in order to force a set of entries to balance (and to retain the integrity of the double-entry system a la the CONSISTENCY command in codeunit 12), you would have to build some sort of user-definable attribute in the dimension indicating that this dimension is not only required, but must self-balance (i.e., all debits must equal all credits). The problem is that the user can turn it off. If the “higher-ups” hear that the “books don’t balance”, they don’t typically care about the reason for such a fundamental gaffe. It will be attributed to either the base product or the NSC. Now having said that, I was confronted with a client who wanted some automated intercompany capabilities. Since the CHANGECOMPANY command only works with one table at a time, I was confronted with three alternatives: 1. Trace every object that could ever conceivably be called by the relevant posting codeunit and imbed logic to decide whether I need to CHANGECOMPANY or not. 2. Have one designated client on constant vigil, surveying the various copmanies for transactions arising from intercompany activity and invoking the posting routines when found. 3. Gingerly placing (that is, without validation) values on the relevant journal line in the other company and making an actual person responsible for periodic posting. None of the above got me too excited. Since none was all that “slick” an operation, client opted for #3. It seems to me the real solution begins with changing the CHANGECOMPANY command within the executable to allow all subsequent references to any table be understood as the “target” (and not the source) company. Anybody solve it any other way?
We are trying to find a solution for a client. They would like to, in company A, create a sales order. They are selling to company B. So, we’ve created the menu option, on the sales order, ‘Create Inter Company Document’. Once choosen, the idea is to copy this sales order in company A to a purchase order in company B. So, I find myself in the same boat as JRN. I can successfully create the purchase order in company B, but I then have other problems that arise. One is the No. Series. If I CHANGECOMPANY to B, and run VALIEDATE(TRUE) on the No.field, it pulls the next number from Company A! Which makes sense, but I hadn’t anticipated it prior. So, to add to JRN’s suggestion, we came up with a 4th alternative. 4. After user clicks ‘Create Inter Company Document’, the sales header is copied to a table in company B. (The customer card has been modified with a few fields on a new tab. It shows the destination company name, destination vendor no. and whether or not inter company transactions are allowed.) All sales lines are posted to a second table in company B. Someone at company B will be responsible for running a code unit which will then post all these records. This allows for all validation to be done against the data. The only other solution we came up with is JRN’s 3rd solution. It’s in the clients hands riht now, but I think, even thought it’s a bit more work, solution 4 is a better solution since validation will occur. Neil Brewer
As far as I know this will be new functionality in 4.0 I wonder how Navision did solve this.