I have a client running a number of modules in Adagio.
Currently there are three separate companies, each in their own folders.

Following their year-end in Sep 30, they would like to merge all three companies into one. They will use different Dept’s in the GL to track the various companies.

The question is regarding the AR and AP data from the two smaller companies.
Assuming that we have the same Vendor & Customer Codes in each company, the client is asking if the history from AP and AR from the two smaller companies can be brought into the larger company (which is the main company)?

I imagine that this would be done as an import.

I am not sure if we would want to do this, especially if it is going to compromise data.

My posting here is to ask the community, if anyone has ever had this situation, and what you might be able to advise.

Samuel:

You wouldn't be able to do the AR & AP as an import as you would need to post both invoices and payments (receipts). Converting the Matching file into an import would be a big job.

We did a merge once for a company that was one entity with three branch offices, each with their own database. They wanted to move to a terminal server and consolidate the three databases into one. It was a big job and we had Bob W assist us by doing the actual merges. This was in pre-GV-RW days. Today I might consider doing the entire project myself using the people who work for me to have multiple steps being completed concurrently.

Hi Sam,

I've done merges. Typically, it's GL/AR/AP with supporting tables and posted transactions. The trick is to make the acct/customer/vendor lists unique just prior to the merge. Once it's all combined, you can use the Toolkit for Adagio to change or combine codes. For example, each GL should be assigned a unique department or at least a range that's unique. Again, the Toolkit can be used to prep the data.

Also consider the supporting tables. For example, a control account '1' might have different meaning in each dataset. You should review control accounts, bank accounts, terms codes, etc.

if you're interested, send me an email to work through the details.

Hi Samuel

I just went through this exercise with a client, and I argued strongly not to merge the datasets. I won. You REALLY don't want to manage multiple companies using Ledger departments if at all possible - the chances of miscoding are enormous.

The key is to find out why they want to merge the datasets. In my case the companies were in the same business with the same customers, but in different areas of the country. They transfer inventory back and forth between companies, and they want to see a consolidated customer lookup.

Since you didn't mention inventory, I won't go into how I worked around that one. As for consolidated customer lookup, I created a GridView to do it. They purposely use unique customer codes for each company (so they know by looking at the code which company it is), so the GridView prompts for the phone number.

On the plus side (for the client), merging uses up fewer Lanpaks, but on the negative side, there are going to be more conflicts when posting. Security becomes problematic. And in my client's situation, the clincher against merging was that Invoices/OrderEntry can have only one series of invoice numbers, which was unacceptable.

In any case, a customer can only be linked to one Control Account Set, so the same customer must be entered once per company in order to track Receivables at the department level.

Steve

Samuel:

My hand goes out to Steve. I should have thought your request through further. I would never merge three separate legal entities into one database.

In my example my client was a single legal entity operating in three locations. They should never have had separate databases in the first place.

Wow - the power of the Internet and especially the Adagio Forum!
In only a number of hours, I am receiving feedback that is tested, up-to-date and of value!
Thank you to all my colleagues tor your thoughtful input.
I will discuss this with my client and proceed cautiously.