We’re acquiring a company soon and looking into the best way to integrate them into our exising Epicor company. What are the Gotya’s for setting up a new multi-site? This will be my first multi-site experience so any helpful information is most welcome.
Initially I was told their current production operations were all going to be moving out and they’d be coming in as a Quote/Order/Customer Service hub. We’d planned then to just roll into our existing site. Now they’ve decide to continue a certain amount of Production, Shipping & Rec, etc there too.
What are the finance / GL implications?
Any Order / PO management headaches keeping track of sites?
Multi-Site or Multi-Company?
we are currently multi-site. In my option, best way to know if you need to have a seperate site or have it under one site is do you want to have Supply and Demand separated between the 2 locations. Each location having its own supply and demand and managing inventory between the 2 places with Transfer orders.
Some things to keep in mind about the second site that you will need to be mindful of
Revs are Site specific. so if you make the same thing at both sites, you will need to have to use Alternate Revs and make sure that each Operation has a Resource at each site for that Operation.
Sale order Release are site specific, so you sales team will need to be pick what site they want to supply the part.
PO Release are site specific. not a big deal if you are using MRP as MRP will create Supply for where ever the Demand lives.
Jobs are site specific.
If Finance needs separate P&L and Balance sheet, its easier to maintain with 2 sites. it can still be done with Product groups, Part classes and GL controls with 1 site, but I think it would be more to manage.
@Randy I’ve done several of these and I would strongly encourage a business process review of the company’s processes and how they will interface with yours. There are many different acquisition scenarios and depending on yours, you might or might not need multi site.
For multi site, I usually say, if it is a physically different location, and if you ever had to move product and you’d have to use a truck, then setup a seperate site. Otherwise MRP nets out per site, so if you used one site for two locations, the inventory for both are netted.
If they are shutting down their location and physically moving all inventory and resources to your facility then, one site would make sense.
Some companies aquire their sub contractor or supplier, in those cases supply chain becomes an opportunity and would mean switching from POs to Transfer Orders and the processes for that is a bit different but there are options.
Also when Sales Orders are created the Releases default from the Plant the Order Entry user is logged into and that becomes the source demand link for Jobs and Fulfillment.
I’ve found it best to setup everything virtually just as it is physically, it’s easier to understand and to develop solutions and processes that way.
Probably our most annoying errors to track down have come from the financial errors that occur when Site A’s revision gets Site B’s resource or operation, and it doesn’t show up until a transferred part becomes a manufactured part;
Also version control between revisions when the manufacturing process is forced to be slightly different between sites.
Probably won’t hit you right away in the case of an acquisition, but "Hey, we could make this cheaper in [your_city], can we tool up in a week?" is bound to happen eventually!
The-powers-that-be have of course kept me in the dark about their plans so far. Reading the tea-leaves, I think the new company is being absorbed and anything they’re making that is unique to them --and that we don’t have ability to mfg-- is moving to a supplier (off shore of course). Doesn’t mean that someone will do the “If we get X machine, can’t we make it cheaper here?” question someday
@timshuwy
Yes, you are right, forgot about that! (look there, a gotya!)
So if all the parts that belong to a Product Group are fulfilled from the same site, setting that can help, but that is a bit rare in my experiance, but it make sense.
IF these are in two different places (locations) that are separated by any distance not within walking distance, then they should be a separate site… REASON: MRP considers all inventory within the “four walls” of the SITE as available for any work that is needed at that site. This goes for Jobs, Shipping, etc… making 2 sites for 2 locations will better delineate the work and inventory out to those locations and separate out the controls.
Whether or not having two different sites will impact Financials is totally up to you and how you setup the system.
GL: The SITE can drive the “Division” segment in the Chart of accounts.
COSTING: you can set a different CostID for both sites (or keep them equal) and the system will use the assigned Cost ID. If they are different, then the two sites can have the same inventory part number in both sites with two different values. They can also have two different costing methods.
MRP & Planning:
MRP runs by SITE… Min/Max/Safety levels are by site
purchase recommendations are by site.
Jobs are by site.
Engineering is by site.
Allocations & Shipping is by site.
Physical Inventory is by WAREHOUSE… but a WAREHOUSE is in a SITE… so therefore…
OTHER: P&L by Site BUT this does not include All financials… AR/AP are by COMPANY not SITE. Customers are by Company (not site). Price Lists are by Company not Site.
First of all, be super careful about the terminology. Epicor used to call sites “plants”, which you can still see in database column manes. They changed plants to “sites”, but there was already something called “multi-site” that referred to the physical location of the servers in a multi-company setup. If you start reading the docs about “multi-site” and find yourself very confused, that’s why.
Most of the multi-plant issues I’ve run into are related to the configurator. Transfer orders cannot carry a MoM or configurator inputs, so you cannot set up configured parts as transfer. (Unless maybe you’re using the options to create part master parts, which I’m not.) The configured items have to be manufactured and shipped from the manufacturing plant. This is fine for drop-shipping to the customer. Otherwise, set the OTS address to the store. The product sits there untracked until the customer picks it up.
As mentioned, revisions (and therefore MoMs) are site-specific. This is a problem if you’re quoting things in a retail site, because the UI won’t let you run Get Details for a part manufactured in another site. But in a BPM, you can call Get Details cross-site by creating a temporary context changed to the manufacturing site. I’m doing this in a post directive on the last method called when a quote line is configured. Side bonus, the guy behind the counter just has to click the Configure button. He doesn’t have to (and in fact can’t) run Get Details from the menu.
When the quote is converted to a sales order, OrderRel.Plant should be set to the manufacturing site, not the retail site where the order was placed. This creates accounting issues that I haven’t delved into very deeply myself. My limited understanding is that OrderRel.Plant is what actually controls which site receives the revenue.
Resources - these are defined at the SITE level… although you can transfer resources from one site to another.
Site Calendar… each site can have its own calendar (just like each Resource can).
MES Login… When you log into MES, (the main login, NOT the Employee login) the system remembers the last site you were logged into with the full client. This makes it sometimes difficult. It is best if the login used to log into MES screen is site specific.
If you have not had multiple sites yet, there is a good chance you have not flexed your GL Accounts before. GL Account Flexing allows the system to flex the GL account based on the site doing the transaction. Site A, Division 01 vs Site B Division 02… when you ship a product from site A, the Division in the GL will flex to 01 even if the product group says it is a Division 02 product. This is because of flexing.
NOT site-specific (but maybe should be?):
Shop Employees… yup… they can work in any site. within the company
Some tracker and entry screens will only work if you are logged into the correct site (aka plant). e.g. if a job belongs to Site A and you open job tracker in Site B, you will not be able to view that job’s data. Job tracker at least gives a warning that the job belongs to another site. Others windows may behave as if the data simply doesn’t exist, if you are trying to view the record while logged into the ‘wrong’ site.
One other thing I’ve seen alluded to but not blatantly stated. For the system to recognize what to do with a part number, you need to setup that part with two sites. The partplant record made for a site inherits what is on the front part detail tab for many fields. If someone changes the site data, you can get different data on the front page-part detail, and differences between site 1 and 2. It’s a hassle. We do audits every 2-3 years to do a bulk cleanup because people go in with the plan to fix something but only change it on one site (e.g., processMRP, vendor id, purchased or mfrd, minimum order qty, etc).
So part setup disconnects and make to job across sites not working from a financial standpoint makes for difficulty for us. We need to make jobs to work on a single part in each site. No starting work, transferring and continuing work on same job. We need to take it to inventory in site 1 then do transfer order, ship to site 2, then issue to next job.
Thanks @timshuwy, we’re in WI and the new site is in Spokane WA so would be quite a long walk.
Yeah, I’ve been in Epicor since the Vantage 8.03 days when it was still “Plant”. Sounds like you’re also another long time user. My previous companies have always been multi-company single-site. So this is going to be my first experience in (censored) years of working with Epicor.
