Spinning Up Epicor in a New Location

We’re working on implementing Epicor in our Mexico location.
This location is nearly identical to how we run things in our Wisconsin location.
We plan on them using the same processes, customizations, screens, etc. as we do here, so we’d like to copy + pasta our database to them, but we want to clear out our transactional and master data and import theirs.
What’s the best way to go about doing that?

1 Like

Couldn’t they operate remotely over a WAN/VPN to a new company in your installation? We have UK and Netherlands operating that way. Create the new company for them and DMT their stuff in? Plus, company level security will hide your company from them unless they have access via SQL or SSRS or something…

If the motivation to actually create an installation down there is substantial(bad internet, legalities, etc.) then I would create a solution of all your customizations, create a new install down there, a new company, and import the solution?

Their infrastructure is atrocious where they’re located.
It was decided to have them host their own on prem to mitigate network issues.
For the solution–I know I can do customizations, BPMs, BAQs, dashboards, etc…
What about menu paths, menu securities, UD fields, etc?

You can just add a new company toi your existing DB (in their server) then remove the old Company (Access) from all users. That will keep all the customs and stuff. However nothing will work unless you copy it to your new company (or save as ALL Companies)

2 Likes

Totally understood! We’ll need to get other advice on these, but I don’t think menu items are part of the solution, but I think UD fields are (in 10.2+). Plus yo’ll have to redeploy all the dashboards, set up external BAQ datasources, copy SSRS RDL’s and a bunch of other stuff too…

@josecgomez will that retain stuff like menu paths, GL accounts, company and site configs, etc.?

Yes but in the separate company (which nobody will have access to)
And Menu paths yes (everywhere)

You (as an admin) could have access to both companies and allow , copy , etc things (customizations, dashboards, baqs etc) from one company to the other fairly easily.

1 Like

Wouldn’t that leave a bunch of data in the actual Database that would get out of date as the two got into operating independently?

WI SQL Database file: Company ABC (Live DB) | Company XYZ (Mexico)
Mexico SQL Database file: Company ABC (data snapshot as of -date-) | Company XYZ (Mexico Live DB)

Right but nobody would have access to that data… is just an old company record (that could eventually be deleted)

Is that true even if a BAQ was written to specifically access data keyed to the original company?

When I first started in V8, I was rather lazy with making sure that I included the Company field in joins, and filtered on it in BAQs and reports, and whatnot. [ hangs head in shame ]

1 Like

in 9+ there’s an “All Companies” or “Cross” Company Flag in the BAQ which by default filters stuff out (unless you have the right rights)

1 Like

[quote=“ckrusen, post:10, topic:51181”]
When I first started in V8,… [/quote]

Shivers, I also did the same thing.

besides looking at the tech part, I’d first take a very close look at their country business processes. sometimes things can be kind of different regardless of the head company’s main BPs.
ie… how to manage taxes and financial report, that will determine the way you COA and books have to be defined.