Configuration of new site

Kinetic ERP
1

We currently have one site, but we are planning to create a new site due to business needs. I would like to understand the impact on master data and business processes for the second site from a production perspective.

IF any checklist?

2

Sites within the same company are really a production (warehouses and resources) and financial (GL Controls) differentiator.

A lot of folks create sites to ā€˜holdā€™ things they want out of the way from standard processes like Cycle Counting and the like. The setup and usage will depends on what your true purpose is.

For real usage, there is a lot to consider. You can separate the financial transactions by site by applying new GL Controls at the right places. Also decide if there will be any site-to-site transactions like inventory moves, and get some new processes set up and documented.

When you have only one site, you sort of ignore all the places on screen that Site is a requirement. Iā€™d make some changes in test and then start doing your processes to find out where this is going to need some employee re-education.

3 Likes
3

It may exist, but it would be neat to make a chart of ā€œwhat you can do without switching sitesā€ and what you cannot.

This should be organized, but hereā€™s a rambling list:

  1. You CAN make or edit a PO (release) for site A from site B (regardless of that userā€™s site permissions, I think?)
  2. You CAN make a sales order (release) for site A from site B as well
  3. POs have nothing saying ā€œthis entire PO is for site Bā€ - because they are not.
    a. Ditto for sales orders
  4. You CANNOT make or edit a job for site A from site B
  5. You CAN do AP and AR across sites
  6. You better pay attention what site you are in when doing cost adjustments, though.
    a. Pro tip: make separate home-page shortcuts for cost adjustment for each site
  7. You CANNOT designate a supplier or customer to be used only in site B.
  8. You CAN set up a supplier or customer financially (GL Control) to hit only accounts that are (mentally) associated with site B. On that noteā€¦
  9. You CANNOT force a GL account to be used only in site B. (You can set it up so as to be [probably] used only in one site, but you canā€™t natively force it.)
  10. MRP and inventory will always respect site boundaries
  11. Transfers (from site A to site B) are just generally painful.
3 Likes
4

Thanks a lot Jason and Mike. Very helpful points.

1 Like
5

I just worked with a company where we didnā€™t create sites, only warehouses.

Benefit was that jobs could cross over to the other locations seamlessly.
More details if you would likeā€¦

Using standard posting rules to capture transactions to each location as they are making and shipping from stock.

2 Likes
6

One of the biggest hurdles Iā€™ve seen is having to create different methods (can be an alternate) for each site. Especially when the other ā€œsiteā€ is in the same facility and runs through the same resources!

7

@JasonMcD - is right if you donā€™t work some magic around customers and suppliers.

I have setup another company where they didnā€™t want to share suppliers or customers across sites, but they didnā€™t want to do multi-company.
Using Predictive search and a UD field, I made it easy for them to find Suppliers and Customers related to the logged in site. We also setup a BPM to prevent using a supplier/customer in the wrong site.

For GL - if you assign a GL control to the supplier - you can map a different AP or AR account to track the balance. The Aging report then can be run using the GL Controls to help you manage the receivables and payables by site.

When product is received to a Site (or Warehouse) - you can flex the Division or Department segment for splitting out your stock status to match you inventory account balance.

1 Like
8

YES! I donā€™t know how I forgot that.

I get the reasoning (I mean, to a point), but this gets painful fast when there is overlap between the sites.

<begin rant>
The revs have to be different (or alternates as you say) because operations are site-specific, because that press brake only exists in one physical location. OK fine. But

  1. There is a press brake in both sites. A generic op would be just fine for me.
  2. We donā€™t use Epicor scheduling. If you do, then sure, you need this limitation (I guess?).
  3. The BOM (meaning just the part numbers) probably hardly ever changes across sites. Could we at least share that across sites? Would help sales kits, for example.

<end rant>

9

Just saw this by accident today:

1 Like
10

When adding a ā€œnew to youā€ functionality that has actually existed in the software mostly forever, it can pay to think of how that functionality was originally designed to be used. Although there are certainly updates and improvements, the base plumbing of the thing probably hasnā€™t changed a lot.

The Sites functionality (originally called Plants) was designed for a manufacturer that had physically separate facilities with possibly different Resources (and even Resource Groups) that could make the SAME part. This means there would have to be an ALTERNATE revision with a different BOO to account for the different resources.

This is a reason why, in the Site Maintenance program, you can select a different Time Zone for each Site.

If you keep this kind of thing in mind, it will make troubleshooting the eventual problems you come across (perhaps) slightly less annoying.

1 Like
11

what about PO suggestion? Is that site specific or calculating same? if when we separate the sites would this continue to calculate the same or would it be site specific or could it show the quantities per site?