Multiple Sites, Multiple Site Cost IDs & Sharing Cost IDs

[Mark_Wonsil]

• If you are standard cost, the columns for last cost are populated as zero (even when they currently do have nonzero values)

One might argue that is correct. If you are standard, that’s the only thing that matters. For that Cost ID/Plant, Last (and Average) are calculated only when something is received, and nothing has been received yet.

• It does not automatically copy 100% of the rows. My experience was the best I could do was for 16,000 of 19,000 parts. (First pass was 11,000; pics below of those posts.)

Do the missing parts not have a Site/Part relationship?

• It’s not easy for it to leave the purchased parts alone when rolling the standard, especially if the purchased part has a revision/method. I spent some time on this and it assigned all sorts of random costs to those purchased parts. Sometimes zero, sometimes a value that was not anything I could replicate.

I agree here. I’m used to other ERP systems stopping the roll up at a buy part whether or not it has a method.

• Even if you wanted to live with all of that, how would you rectify the errors? There is no DMT for it. Yes, there is a Cost Adjustment DMT, but Plant is a required field - it won’t let you modify an unassigned cost set.

Yes, you are correct about that.

The tooling for setting up a new site is fine. The process of trying to move non-standard costs to a plant that used to be a part of another site is definitely a miserable process and I wonder if it happens enough for Epicor to add tooling for it. Maybe add Average/Last/FIFO stuff to CostPart?

[JasonMcD (Jason McDermott)]

@Mark_Wonsil

If you are standard, that’s the only thing that matters.

Well, this is just lazy programming, I suppose, but I love having Last Cost columns in the same table as the Standard Cost columns. My users often want to know both.

@Mark_Wonsil

Do the missing parts not have a Site/Part relationship?

This was 2 years ago, so I can’t guarantee what I researched. But this statement makes it sound like I was comparing [number of rows in PartPlant for MfgSys site] to [number of rows in PartCost for the new CostID]. And they were 3,000 apart (well 8,000 at first).

[Mark_Wonsil]

@JasonMcD

My users often want to know both.

But doesn’t zero mean, “You haven’t received any at this site yet, so there isn’t an average/last/lot cost.”? All of these costs are not updated with buy direct either.

Now, last PURCHASED price is an entirely different thing, and yes we do want to know what that is.

No doubt, keeping costs by site can get complicated very quickly!!!

[JasonMcD (Jason McDermott)]

I mean, I think we agree basically.

[JevonJoseph]

Wow - lots of good new comments - thanks.

Just to address the point about DMT:
Yes, there is a Cost Adjustment DMT, but …
(1) Don’t necessarily want to create all those PartTran records, and
(2) Don’t want to necessarily want to post to GL if that’s the active Costing Method.

[jdlester (Justin Lester)]

Wow. This gets fairly complex, however i may have a more unique situation. What if site X mfg a part at a cost id 1. Site Y then buys from site X via purchase order that part at cost id 20? What happens then?

[JasonMcD (Jason McDermott)]

@jdlester

via purchase order

Different companies, too? Or same company?

If you are asking about a PO instead of doing a transfer across sites in the same company, I will warn that the communal wisdom here is that it is bad to do the PO:

Need advice - thinking of abandoning Transfers in favor of sales orders and POs

Meaning: We are multi-site We are not multi-company We hate transfer orders (don’t worry; I will rant later) Couldn’t we just do POs and sales orders? (Not ICPOs; just normal ones) Any disadvantages?

[jdlester (Justin Lester)]

I completely understand but I cant change that method at the moment. Too many opponents. Same company. Standard po not icpo. One site is source type M and the other is source type P with site X having a vendor id for site Y.

[JasonMcD (Jason McDermott)]

I assume you use standard cost? (Otherwise average or last cost do what they do.)

@jdlester

What happens then?

At face value, what happens is the same thing that happens with any PO or shipment - inventory goes up or down at std cost and PO variance goes to some account.

I think you are implying that the std. cost might be different in each site?

So that happens here and we do transfers, not POs. With transfers there is a built-in variance mechanism. But is that functionally any different than a PO variance? Honestly I haven’t sat and mapped it all out.

---

For anyone that is thinking, “That’s stupid - why can’t you people get the same std. cost on all sites?” – Oh it’s not us. This is reality.

Our two sites are an OEM and an OES (aftermarket). Some companies (Bendix) charge literally 5x the price for an OES to purchase the same part vs. the OEM price. So there are truly two different costs depending on the site.

[JasonMcD (Jason McDermott)]

And maybe the concern is, how is accounting supposed to reconcile the differences?

Sorry if this is rude, but that’s their job to work it out. Like I said, this happens even with transfers. It’s messy. They get paid to deal with it.

In a similar vein, we have additional divisions that don’t use Epicor at all, and so we have to do sales orders to them. For some reason which makes sense to me if I don’t think too hard, we have a rule that we must sell parts to them at exactly (our) standard cost. I have a BPM that populates that cost into the sales order unit price.

But naturally there are times that things go wrong (say an order is created before a std. cost change but is shipped after the change), and we have BAQs to monitor for that.

[jdlester (Justin Lester)]

So assume the following. Part A is mfg in site X and purchase frome site X into site Y via Std PO. Site Y the use said part in Part B. What we are seeing is labor and burden being reapplied in the job for Part B in site Y for Part A (purchased item). Why is this happening? Is it because we are using POs to transact between sites instead of TOs? Also both sites are in the same company.

[JasonMcD (Jason McDermott)]

Standard cost in both sites? Or something else?

[jdlester (Justin Lester)]

Std cost in both sites. Site X is cost id 1 and site y is cost id 20. Labor and burden is from the mfg site thats being reapplied on the job.

[jdlester (Justin Lester)]

Its as if the background script is looking at part.type rather than partplant.sourcetype if that makes sense.

[JasonMcD (Jason McDermott)]

This involves settings that I have not touched in a few years, but…

First, it sounds like you have a std. labor and std. burden as part of the standard in cost ID 20.

Is yours like option 1?

There’s probably an argument for option 1 or option 2.

Option 2 would seem to solve your problem.

But you can still stick with option 1. In that case, you’d probably want to uncheck this setting, “Enable Mfg Cost Elements,” in the Company Configuration. This will roll the cost of the part as all material into a job it gets issued to.

Now, that’s for jobs - if you ship the part, then it would stay in the “buckets” of material labor and burden when going to cost of sales.

Also, it’s a company-wide setting! So you have to live with it everywhere! That is, unless you get creative and have a BPM toggle the parallel setting on every job. A user did that at some point here.

Ah here that is:

Enabling Manufacturing Cost Elements for Job-to-Job Links Only

Does anyone know of a way to maintain manufacturing cost elements (i.e. use the functionality enabled when “Enable Mfg Cost Elements” is checked) in one scenario, while using the default job costing method in all other scenarios? Essentially, we need to maintain the split-out cost elements if we manufacture a part to directly fulfill a material line on another job using a direct job-to-job demand link. We’ll use the cost elements to pass along labor cost from one job to a separate job that isn…

[JasonMcD (Jason McDermott)]

@jdlester

Is it because we are using POs to transact between sites instead of TOs?

And no, is the answer to this.

[timshuwy (Tim Shoemaker)]

so it really doesnt (or shouldnt) matter if you transfer or purchase the item between two SITES… if your purchase price is higher than the standard cost, there will be a variance.

Site 1, CostID 1, Cost $10

Site 2, CostID 1, Cost $10

PO created in site 2 to purchase part from site 1 for $15

This means you also have a SO in site 1 to sell the item for $15.

When you ship the item in site 1, it will have a $5 profit

When you receive teh item into site 2, it will have a $5 variance.

These two should cancel each other out… you did not make a profit in any way. you might be claiming a profit, but since you are all one big happy company, it all washes away.

Not sure how many of you remember this, but there was a scandal in 2004 involving Enron where they were claiming profits by moving sales around between COMPANIES.. this made them look more profitable than they really were. This came at a high cost to the company, the auditors, and the 85,000 employees who lost a job. It also caused the Sarbaines Oxley (SOX) act to be created.

So, my advice is to have certified accountants look at the practice of “selling” between sites for different values. Make sure that everything is being done correctly, and not rely on the advice from a this forum. While we (including myself here) all have the best intentions in trying to help, we dont know the whole story, and it would be best to have your company follow best practices, whatever they may be from an accounting point of view.