Change Companies on the fly in NAV 2009

This is a generic question. We are looking to upgrade to NAV 2009 (from NAV 5.0 sp1), and I was wondering with the new three-tier structure if it will be possible to switch which company you are connected with based on certain criteria.

For example: you are entering a sales order and you select a customer from a pre-defined geographical region, so you apply the sales order against company A. Whereas if it were in a different pre-defined geographical region you would apply the sales order against company B.

Any thoughts would be appreciated.

You could do it if you use webservice, You could built the solution outside of NAV and then the user would login into NAV.

Ifyou build it inside of NAV, you still will need to login into a Company and then have to have to change.

I suggest to create new tables for sales header and sales line and then send the order to the correct company using webservice.

Is it possible to change companies programatically in NAV?

Yes, you can use the CHANGECOMPANY command.

That’s fantastic! Thanks!

However I just spoke with my project manager and got a better understanding of what the requirements are. Is there a way to read data from another company while still logged into the original company, from inside of NAV.

Yes, Matt already told you how. [;)]

Just be careful with how it is used. You don’t want to create a document in one company, then post it and have half the ledger entries in another company.

To elaborate a little bit. You will have to do CHANGECOMPANY on each and every record variable in code. So regular validation will not work for triggers that read from other tables, or insert into other tables. So let’s say you are i company A and you want to create a sales order in company B. You would write code to do SalesHeader.CHANGECOMPANY(‘B’). Now let’s say you want to validate a customer number. You’d think that would be easy, just do SalesHeader.VALIDATE(Sellto,‘SOMENUMBER’). That’s where you are wrong, because the validation code will read the customer from the company that you are in by default, even though it is set to the other company. You would have to either change all record variables to change to the other company, or write your own codeunit that replicates the validation code. Trust me, you don’t want to go down that road…

If you just need to read from another company it’s pretty safe to use. If you need to validate any data, or if you need to create records and run processes, you should NOT use CHANGECOMPANY. You would have to change the code for all record variables to change to the same company. I can tell you from personal experience that this gets VERY complicated VERY quickly. We ended up spending 2 weeks developing the original solution, 4 weeks tweaking, months of trying to solve issues and fixing data, and in the end we started the whole thing from scratch and redesigned it to use staging tables and NAS instead.

Your safest bet is still to either create records in staging tables in the other company, and have a NAS process in that other company process that information, or go the web service way that Rashed suggests.

I was referring to this question. Its really easy to view data from another company.

Yes I realize that, and then Matt started talking about posting. I just elaborated a little to offer some more insight. It’s a small step from “cool I can read from other companies” to “that probably works with validating and writing too”. I know, that’s how I got in trouble [:D]

Dniel I wasn’t commenting on your post (i’d have quoted you otherwise), just clarifying to Ben what my earlier post meant. [;)]

Wow. Thanks for all your comments and suggestions. I now have a clearer understanding of how to use (and not use) the CHANGECOMPANY trigger.

As my eventual goal is to make it so that we can enter a sales order with lines in different companies, that validate with proper prices and credit checks, I will not be using CHANGECOMPANY.

Have you thought about using Dimensions to separate your data instead? Then there’s no switching companies at all.