merging data base companies 1

[almaragni]

do you have a checklist/quideline document that would cover the issues that may come up during an attempt to merge two separate data base companies into one?

do you have a document that might have some good discovery questions that would help determine the account setup? such as .. do you require comkbined voucher payment? are you purchase order numbers required to be separate? how do you plan to produce income statements (separate/combined?)

any help would be appreciated.
thank you

 

[karenoden]

I do not know of anyone who has ever succesfully accomplished to merge two databases into one. Can you get me more specifics? How do you attempt to do this from a MS SQL point of view? Create one new database and bcp the data from both into this new one? When it comes to the data inside the database, remember each transactions has its own trx_ctrl_num and pcontrol number. How do you intend to resolve that without having duplicates? Maybe if you could tell me what exactly you are trying to accomplish, I could tell you of another way to do this.

 

[almaragni]

Well thanks for the reply.

We're not looking to combine all past transactions and history.

What may occur is that a company - which currently resides on a separate SQL DB (under the same DBControl) - will now be converted into "just an inventory location" of another company DB.

We would expect customer, vendor, GL, asset master conversions as required.

However, we're looking for words of wisdom on how to approach this.

Thank you

 

[karenoden]

You would have to import the contents of numerous tables into the "leading" database. This is very dangerous because there is a lot of tables involved. Vendors are in the apmaster table, customers in the armaster table. That's the easy part (always assuming that there is no customization on the tables in either one of the company databases). However - you are running the risk that you overlook to bring data from one table over which would lead to inconsitency in the tables. Besides - you won't be able to withstand an IRS audit because the auditors would not be able to see a full audit trail. This puts your company under totaly scrutiny during an IRS audit. If I were you I would explain to your controller or whoever wants you to do this that certain things cannot be done. Not everything is possible. Explain to them that the only save way would be to only bring the vendors, customers and possibly inv_master data over. If I were in your shoes, I'd open up a call with installation team of Epicor and have them give you in writing that they do advise against it or have an Epicor consultant do it for you. If a consultant screws this up, you are out in the clear. I wish I could be of more help but I just got through talking to an Epicor consultant, asking her advise. She said she would never attempt anything like that. She'd rather only bcp apmaster, armaster data and have accounting manually re-enter assets and inventory items in the "leading" company.

 

[almaragni]

Thank you for your help.
Maybe we'll take that route.
But I do have a question.
Can you explain the scope of the IMPORT MANAGER.
I dont understand why it cannot be safely used.
Thank you

 

[karenoden]

Epicor Import Manager is an application that provides a fast and accurate transaction gateway of importing business data into Epicor Enterprise. You can import General ledger balances and transactions, and all other major transaction types in Accounts Receivable, Accounts Payable and Distribution. Import Manager has a graphical interface to map any ODBC compliant data source and set up translation rules for import. Epicor Import Manager is a powerful, flexible and easy to use application that provides fast and accurate transaction gateway of importing business data into Epicor Enterprise. You can import General ledger balances and transactions, and all other major transaction types in Accounts Receivable, Accounts Payable and Distribution. Import Manager features an intuitive, graphical interface to map any ODBC compliant data source and set up translation rules for import into Epicor Enterprise. Mapping of Data requires that every field in the source databases must be mapped to identify a corresponding column (or columns) in the receiving system. This is often a time consuming task and requires a detailed understanding of both the source and destination databases. Before data is imported, you can manipulate data values using the Import Manager Workbench. Import Manager ensures data integrity and automatically completes any missing default information, such as a customer posting code or tax code.
I have used Import manager before and it is not an easy to learn and understand program. This is the only method I would support to bring data into an existing database because it is the only program that does a data validation before import. Data goes into staging tables, then a process is run and if there is anything wrong with the data that you are trying to import, the program will prevent you from importing the data. "Wrong" data could be i.a. that you are trying to import a vendor code that already exists, a duplicate transaction control number etc. Epicor does not provide training on Import manager. Technical support will naturally support you if you are having problems to bring transactions in. However, you are required to know the program and to understand how to clean up data and manipulate it.

 

[almaragni]

Wow - that was quite thorough. Thanks

I think maybe we should consider training/consulting on the import manager - as it appears to be the tool to use.

Additionally, I can see this type of activity possibily being done again in the future.

THank you very much.

 

[almaragni]

Will IMPORT MANAGER WORK on the asset master - or is there a better way to export / import assets ... that are currently in use (ie. not new)
thanks

 

[karenoden]

I don't have a check list because like I stated before - nobody I know has ever attempted to do this. You would have to make sure that you don't have any duplicate trx_ctrl_num in any of the tables. You would have to make sure that you have no duplicate pcontrol numbers. Same for vendors, customers, General Ledger account numbers. If you combine two databases, they will be handled by the system as one that means all the finance figure get mingled up. I would rather make the second database like an intercompany so that you could do intercompany transactions and reconcile the two against each other from a financial point of view. That would be easier with your financial statements too. This way you have two separate company databases under the same control database. you could then select in A/P to do intercompany vouchers etc. You would still produce PO's in each company database. You would just switch from inside eBackOffice to the other company database.
If you really desperately want to merge the two company databases into one, I could provide you with the name and contact info of a former Epicor consultant who works freelance now. This person is the only one that I know of that would have enough knowledge and expertise to be of any help to you and might get this accomplished if it is doable at all.

 

[almaragni]

sure that would be great

 

[karenoden]

You could ask Gwen Ford if she knows of a way to do it and can be off assistance to you. Her e-mail address is gwenherbst@cox.net

 

[DA22]

I've managed to merge two databases together without any issues. It was a long a painfull task, took 2 days and 4000 lines of SQL Scripts, but it worked and 2 months down the line there have been no problems.

I basically looked at every single databases table individually, re-mapped every customer/vendor code incase of duplicates, and prefixed all control numbers from one database with a character. There are loads of other things to check, such as all the setups need to exist and company codes need to be correct and so on.

Feel free to get back to me if you want more info.

 

[almaragni]

DA ... 2 days sounds like a flash in the pan - considering what you had to do ... do you have a check list of items that were addressed that you would be willing to share? thx

 

[DA22]

I didn't use a check list, I basically selected from sysobjects where type = 'u' and then went through each table manually. It would be completely different for every customer, due to different modules and setups etc, so virtually impossible to use the same set of scripts. One tip, if you still need to report historically on the different entities, is to use things like territory codes and journals types to define transactions originating from different sources. This way a TB, for example, can be printed off for each separate company that you have merged, from within one set of data.