Dealing with multiple companies

bhalpin

Hi.

In writing an Excel import routine to update items, I've run into an interesting problem.

There are two companies. The imported data will contain items for both companies. Some items need to be added/updated in one company, some in the other, and some in both.

No problem so far. Before sarting I have two item record variables, and use CHANGECOMPANY to set each to a specific company. Then, when I encounter an item I determine is for company 'A', I call a function that accepts an item records as an arg, and hand it the company 'A' item record. The same for company 'B'. For items that I know must be added/updated in both companies, I call the function twice, once with the company 'A' item and once with the company 'B' record. Works just peachy.

But, part of adding/updating the item is the unit of measure value. When I determine that a new Item Unit of Measure record is required, I create one (for the correct company, of course), then use xxx.VALIDATE to fill in the fields. Here is where the trouble comes. The VALIDATE code in some fields of this table do some lookups in other tables - and I get my teeth kicked in because the lookups will be in table records for the current company (say 'A') but the Item and Item Unit of Measure records I just added are in company 'B'. Poof!

I have reverted to creating the Item Unit of Measure record and simply stamping the field values in with :=, then doing INSERT(FALSE). If I'm a good boy I think this will be fine, so no big problem.

But, I'm wondering if anyone else has run into a similar scenario and perhaps has a more elegant solution.

Bob

kine

This is common limitation of the CHANGECOMPANY function. All business logic called during work with that variable is called over current company, not in the set company. One way is to create NAS (Navision application server) functions per company and call this. It means something like webservices for each company, calling these webservices to insert the data into the companies.

DenSter

bhalpin wrote:

Poof!

You just found out why I always make such a fuss about CHANGECOMPANY

If you really want to do it right, you'll have to duplicate all relevant validation code, in which you will have to change the company for all record variables. You can imagine how much code this affects, and that this can turn into a very big job if you're not careful. You might want to take an approach with staging tables, and have a NAS for each company process the information.

One note, is that CALCFIELDS and CALCSUMS do work for variables that have their companies changed, at least that was the case when I last worked with this, probably in version 3.7. So when you're in company A, you do Customer.CHANGECOMPANY(B), and then CALCFIELD(Balance) it should calculate the balance in company B.

jlandeen

As mentioned this is a common limitation of the ChangeCompany function as it really only changes the company in context to that one record variable and not any child variables.

Could you just add a Company ID field to the data file that you are trying to import. Then only import the record if the Company ID matches or is some constant like 'BOTH'. You would still need to run the import in both companies but it would allow you get around this problem while using almost the same data file.

bhalpin

Hi.
Thanks all for the comments.

Yes, I can have the user run the import once in each company. So far the stuff I'm doing is pretty simple (Adding updating items and at most hitting unit of measure and posting groups), but if it starts to get out of hand in any way I'll go the 'two import' route.

Bob