Advice on Multi-Site (Company)

We have two facilities and recently launched Epicor in Feb of this year at the first facility. We are looking into purchasing Multi-site and XL Connect and were hoping to speak to a company who is actively using these modules. We had a demo with an Epicor engineer recently to see the overall functionality, but were hoping to have a brief chat with a company before purchasing these additional modules. Epicor is looking to see if there is a reference for Multi-Site, but just in case I thought I’d reach out on this platform as well.

If you would be willing to share on here or chat briefly about your experience/learnings/pain-points that would be great appreciated. Thanks in advance!

I’m interested in this as well. We already have multi-site but do not really use it.

Wondering about the pros/cons of setting up multiple sites vs multiple warehouses in Epicor, gotchas, etc.

Lisa,

I’m a consultant, and I can tell you what I commonly see as the biggest “gotcha” when I work with Multi-Company clients.

Epicor’s Multi-Company functionality is designed around the need for multiple legal entities that need to transact among themselves at an arm’s length (they can buy and sell to each other, but the “buying” company creates a Sales Order and the “selling” company creates a Purchase Order). Each Company has its own General Ledger, and each Company’s transactions are siloed. Usually there is an additional Consolidation company where Finance combines everything together for combined statements. As an example, if a corporation has a US branch and a Canadian branch, both would need to be separate LEGAL entities for all kinds of reasons, but even if a corporation had 2 branches in the same country but wanted to keep them separate , this would be the way to do it.

Many data tables are sharable between Companies, using what Epicor calls “Global” functionality. Customers, Suppliers, Parts, Contacts, and some other static data records can be flagged as “global” (there’s a checkbox on the screen), after which they can be linked to from the other companies (and there are checks and balances and processes to follow and all that).

The vast majority of setup and operation in a Multi-Company environment is in the Finance area, and the best type of Finance person to help with this will have an idea of why the separate is necessary, and what each company needs to do that might be unique in its environment.

The biggest “gotcha” is insufficient testing. Do you need a Consolidation company? Your Finance people should be able to answer that one right away. Once that is decided, set up the Multi-Company Process between your “operations” companies and work through each area, seeing how sales orders, purchase orders, shipments, associated AR/AP transactions, and any shared data tables link. Get familiar with the processes. Close a period. Run a Year-End close. Then do it all again. And again.

Good luck!

4 Likes

Thanks Ernie! Greatly appreciate you taking the time to respond. I have one question with the “Global” functionality. During the demo we received, he mentioned it was a one way push of data to the other company and after that initial push the tables are separate - unless you constantly run this program to update. We thought one company would own the table and restrict the other company from making changes. It sounds like you can make changes or run a process to keep the tables in sync by pushing the data from the one company to the other.

This is why the testing is SO important. The “main” data tables that are shareable (Customer, Supplier, and Part) will have a “parent” company. Changes that the “parent” company makes to a record will typically be synced down to the “child” companies… and it’s a one-way street. A “child” company cannot make a change to SOME of the fields that a parent company “owns”… but others it can. For instance, on a global Part record, you can’t change the Unit Weight, but you can change the Sales Unit Cost. Most of the time these are pretty sensible, but it should still be tested in your environment so you have a better grasp of what happens. If your two companies deal in different currencies, then you need to be especially careful in using global Customers and Suppliers as the parent currency will follow when a new record is linked and will need to be updated. These are the kinds of things that boring, repetitive, hair-pulling-out, seemingly-never-ending testing will display in stark relief.

1 Like

Right? That’s what I hoped/assumed, too.

For that reason alone, we went multi-site instead of multi-company. Consistency in the Part Master was the deciding factor for me. I shoehorned the financials to make that work. (Only 5 posting rule mods, though.) It was a rough first few months, but that was mostly because of several key managers leaving all at once. It’s been a year now and we are doing fine.

As @Ernie recommended, I tested the daylights out of everything, and had a really good grasp on the accounting. The manuals do not prepare you, though. Much of the part-transfer hierarchy is wrong with the division flexing. You just have to test all of that. (Again, that’s for multi-site, not intercompany sales.)

My biggest personal hurdle was learning a different business model (stock part sales). I’m used to Engineer to Order. Verrrrry different needs.

Something a user came up with, that was really key to success: different vendor IDs for the same vendor in two sites. Ditto for customers. There is no other way to get the financials straight if need be. Also separate payment methods.

Also, you can track part transaction GL through the Inventory-WIP Reconciliation Report.

But for AP and AR invoices, it’s harder to do that en masse except with a BAQ on TranGLC.

Multi company does need some love

@lhamersly1 - We have our sync running every 10 minutes as a scheduled process. It basically looks to see what’s changed, and then flags is as available to the child company (Ernie, please correct me if I’m wrong!). If there’s no global changes, the sync happens in a few seconds. There’s a max record limit of 1000 (If I remember correctly), so set your sync period short enough that you don’t have more records than that, or it’ll save the overflow for the next sync. Global customers that have global credit will constantly be syncing as their open orders affect their available credit.

One thing to keep in mind with sync (at least with customers) is that there is still user action to finish setting up the synced customer in the child company’s Customer Entry menu. You need to search for the unlinked customers, select them, create them, create the missing contacts, etc, so it’s not quite seamless, but it goes fast enough. Ask to see a full quote to cash during the demo that includes showing any steps where you want things synced (customers, parts, suppliers, etc…).

I think the number one thing to figure out, is if you need multi-company or multi-site. It’s the same module, but implemented in entirely different ways.

Do your two facilities do roughly the same thing? Do you ever need to transfer inventory between them?