Over time there have been multiple posts and questions on how multiple sites can have different (or same) costs. The purpose of this post is to describe how it works.
Definitions: Company: A group of Sites… SITE: A place with warehouses… typically I like to define a site as a group of warehouses that are close enough that there is 0 transport time between warehouses. If the warehouse is across town, and requires a truck for transport, then it might need a new site. Site Cost ID: Each site MUST be assigned to a CostID. “Typically” by default, CostID “1” is assigned to every new site, NOTE: This “assumption” is erroneously used many times in BAQs. CostID 1 is NOT a rule, it is a default. PartCost: There is a TABLE called PartCost… the index to the table is the Company/PartNum/CostID. Note that it does NOT have the Site (Plant) as part of the key. To find the cost for a part, you need to know the Site (Plant) and lookup the CostID from the PLANT table, and then use that (instead of assuming CostID = “1”).
OK… onto the options assuming you have three SITES X, Y, & Z:
Sites X, Y, and Z can all share one common CostID…
Sites X, Y, and Z can each have different CostIDs
Sites X & Y can share one CostID, and site Z can have a different cost ID
So… what does this all mean?
With option 1, when you move an item from site X to any other site, the cost remains the same. there is only one Cost record per part. if you change the cost, the inventory value in all three sites (and all their warehouses) adjusts as well.
With option 2, each site is independent. you can adjust the cost in site X, without affecting the other two sites. BUT… if you transfer inventory from site X to site Y, and if their costs are different, this will cause a “Transfer Cost Variance” to be posted (the money must go somewhere).
Option 3 is simply a combination of the above 2 options, transfers between X & Y are at the same cost, but site Z is independent.
Special Note about CostID…
You can create a new CostID, you can calculate new costs, but never associate it to a site.
you can copy costs from an unattached CostID to a CostID that is in use (using Costing workbench).
you can reassign a new CostID to a site in the Site Maintenance. WHEN YOU DO THIS, you will journal entries for any costs that change for parts… This process can create 10000s of cost adjustments if the two cost tables are different.
If you are AVERAGE COST, and you are using Option 2, then every CostID will have its own average calculation. the parts can literally cost different for every part because of the average calculation.
Other IDEAS:
I have created new CostIDs to “store” historical costs… at the end of each year, we create a new CostID and copy the costs into the new year. Then you can create your own BAQ/Dashboard to do historical tracking of costs.
One “OldSchool” method of doing recosting involves 1. create new CostID. 2. Develop all the new costs for “next year”… create dashboards to compare current to “next year”… once ready to make this live, you go into the Site Maintenance and Switch the cost ID to the new year.
How do you all use CostIDs in a special way? Has this giving you any additional ideas?
When you are creating new Cost IDs for the next year do you implement during a stock take when setting qty to zero? It seems from what I’ve just seen in my test environment changed IDs with a qty produces alot of transactions.
yes, when you change cost IDs, it will generate a journal entry for each difference… for example, if you have a part X with the CostID of 2021… it has a cost of 1.25… but you create a new CostID called 2022, and you change the cost of part X to 1.26… When you change the cost ID, it will examine the current Qty On Hand, and if any, it will produce a cost adjustment of .01 per qty… But this same thing would have happened if you posted a cost change in the Costing Workbench.
Many thanks Tim. We have yet to implement our main manufacturing site yet so as part of or go-live and stock count I will Zero all QOH for and the new cost ID to MfgSys and then bring in QOH for both sites.
I’ve tested a few parts and transferred from one site to the other but one thing I expected to see but didn’t was Epicor unable to handle the cost variance. All posting went to known accounts i.e. not our catch all clearing account of 99999… and went smoothly. I tested with parts initially at $1,000 and purposefully raised POs at a higher price and received them in one site then bought and received under that in the other. Both sites had different costs but the transfer went smoothly. Did I see another post mentioning Epicor posting a variance somewhere?
Transfer variance is a big topic. If you want to break down and cry, read this post and all its 37 replies:
We went on several tangents, but it might prove useful to your endeavors. (We are std. cost here; sounds like you might use average?)
But, point is, there is a place for transfer variance, even without “interdivisional accounting,” which thankfully we decided against.
Do you have GL controls on the plant transfer definition (site maintenance, I think)?
EDIT: You know, it’s something else when I am the only person in the history of this forum to ever mention “interdivisional accounting.” Twice - once here and once in the post I linked to above. And we avoided it after all. So, this is not exactly a well-beaten path, I guess!
The transfer variance will only happen if you are Standard Cost (or the dreaded Last cost). If you are Average, Lot, Fifo, or LotFifo, then there will be no variance captured.
If standard cost, here is what happens:
Site 1: Std Cost of $1000, purchase at $1200 - a $-200 variance. the cost in the system is now $1000
Site 2: Std Cost of $1500, purchase at $1200 - a $300 variance. the cost in the system is now $1500
transfer the part from site 1 to site 2. It will
transfer OUT $1000 from site 1,
transfer IN $1500 into site 2…
there will be a $500 variance due to the change
If Average cost then here is what happens: the cost will adjust the average when you move the parts, just as though they were purchased. It follows all the normal average costing rules.
Site 1: purchase at $1000 - If none on hand before trx, the cost in the system is now $1000
Site 2: purchase at $1500 - if none on hand before trx, the cost in the system is now $1500
transfer the part from site 1 to site 2. It will
transfer OUT $1000 from site 1,
transfer IN $1000 into site 2…
The new cost in site 2 will change from 1500 to 1250 due to averaging. No variance will be posted.
And, as @JasonMcD pointed out, you need to make sure that you have the GL Controls for Plant Transfer definition setup correctly so that variances (if needed) go the right places.
@timshuwy I am finally able to try this here for the first time, and this is definitely the right way to do things.
But how do you copy the costs from the old ID to the new one? I assumed Costing Workbench, but the help doesn’t show a way to do that, not that I see.
Of course I can do a BAQ and a DMT, and I probably will do that. But is there no way to duplicate the entire cost set with a new ID?
For example, our parts are standard-costed, but I would still like to retain all of the Last cost data on the parts for reference. Is DMT the only way to do that?
I think I got what you are saying (I’ll explain after this), but I’m not liking the results.
First, we use standard cost and that data came over, but the Last cost data is all zeroes, as is Average, etc.
So if I want to retain that info, is DMT the only way? Seems so.
Second, it only pulled in 11,000 parts to the new ID, but the old ID had 19,000 parts. I’m assuming there is some setting I missed there and so be it, but I’m curious what happens if I were to assign the new cost set to the site (that has all 19,000 PartPlant records). Kind of a moot point if the Last cost data isn’t there anyway.
I think I found a way forward. This is rough, though.
Big thing I learned is that DMT really does not handle this well for an unassigned cost set. One of the required fields of the DMT is Plant and that’s silly and is a problem because it’s checking my changes against the assigned cost set. So when all I want is to load in the costs for other costing methods, I can’t do it. I am able to modify it with an updatable BAQ, so there’s that.
And so also, that’s terrifying because I was actually able to modify the assigned cost set also and no GL activity happened, so hey don’t ever do this, okay people!
And about not getting all parts, the step I missed previously was to check off “Retrieve unlinked purchased parts.” It got me to 16,000 instead of 19,000 but that’s close enough.
So the procedure as I see it for moving ALL costs from the existing set to a new one is this:
Make a BAQ of the PartCost table. Download all of the parts for old Cost ID.
In Site Cost Maintenance, make a new Site Cost ID. You can set the primary site already; this won’t hurt anything. A later step will actually link the two.
In Costing Workbench, make a group; use the current cost set (not the new one) for the “Copy from Site Cost ID”
Also in Costing Workbench, go to Actions > Load Cost Details. Be sure to check the setting of “Retrieve unlinked purchased parts.”
Wait till the process is complete
In Costing Workbench, go to the Cost tab and then search and return all purchased parts and all manufactured parts
In Costing Workbench, go to Actions > Post. Then change the Site Cost ID to the new one.
a. I unchecked Labor and Burden rates here since I am not updating those. YMMV.
Make an updatable BAQ of PartCost and publish a dashboard of it.
In your dashboard, load in the new costs and the historical costs
Export this dashboard and save the file for next time. Then DELETE THIS DASHBOARD! No one should know this exists. Yeesh.
In Site Maintenance, go to Actions > Change Cost ID and pick the new one. Click Process. This is it - try not to panic.
Also, this skips inactive parts. If you reactivate one, this part is untethered to any cost and always transacts at zero. Yay.
So really, I guess you need to use the updatable dashboard to add in the inactive parts to the cost set as well. At this point, I could ditch Costing Workbench altogether (steps 3-7).
I have to be missing something. Do other people do this, with a new cost ID every year?
Since you got me rereading this, I should say that I did go through with the new cost ID a few days after the July 8 post.
For some reason, when I did the change (step 11 above), it errored out during the endless ADJ-CST portion. So, that was a nightmare, trying to explain to people:
Yes, the new costs are loaded and all future transactions are at the new costs
But the GL activity didn’t complete, so $800,000 is in the wrong account(s).
In their words, the “subledger” was right but the General Ledger was wrong.
Believe it or not, I’ll still do it again this way next year. But I’ll be more prepared.
Hello all, ignoring the “necro” warning because this is like an encyclopedia article not a problem/solution .
Has anyone done a CostID change going from one option to another? In our case, we have two sites sharing a cost ID due to a setup error 5 years ago, and with FIFO that means we’re constantly getting FIFO errors as one site’s transactions consume the other’s FIFO stacks.
What steps would be required to make the switch? I’m unsure how the costs would be assigned to the site that didn’t change. Will it use the warehouse onhands to calculate?
.