I’ve written something similar to this before. I have a problem with two costs of the same part.(Std cost, one site). The cost differs depending on the outsourcing location.
On this matter, one of the staff came up with the following idea. Can Epicor support this?
The sales order is created as part “A”. (The sales team does not know which outsourced production will be made at the time of ordering.)
A job is created as a part of the production site.
Shipment is created as part of Sales Order. And it is automatically shipped as a part created in the job.
*Since Epicor doesn’t know if it will process as Part “C” or Part “D”, it sets priority and if the 1st part is out of stock, it will be processed as the 2nd part.
All of our jobs are MTS(Make to Stock).
Part “A”, “C”, and “D” are actually the same product. Parts “C” and “D” are only products manufactured by other subcontractors. So Part “C” and “D” actually cost different. However, since Epicor’s Std cost only allows one cost for one part, we want to use Part"C" and “D” to enter different costs.
The accounting department wants parts with different costs to appear as those costs. Conversely, the sales team wants to put it as Part “A” because it does not know which outsourcing company will produce that part when creating a sale order.
So I came up with this idea. But I don’t think Epicor will support it.
If I treat it as Part"A" in Shipment, I want it to be depleted as Part"C" first, and then as Part"D" when the stock of Part"C" is exhausted (automatically).
What is the goal here? “Two costs in one part,” I know, but I mean more specifically.
The last time this came up, others explained the benefit of variances, etc., so I won’t rehash that.
But I assume one of two goals:
You want to know how much profit/margin you made on a particular sale. If you had to spend more to make part A, you made less on that sale.
In this case, you need it to be make-to-order, so that the costs stay linked from a job to a sale. That’s not your business model, though, and that’s fine. But it’s the only way to link them. (Can be a one job to many order relationship, but that gets thorny.)
You want to know how much the jobs are costing for part A - and that should be data you can research today.
You want MRP to pick which place to outsource from.
That, ooh, I don’t know. If it is an issue with being inside a lead time, maybe MRP can get smart. Otherwise I can’t see it using the logic you want.
My company’s business background is as follows. To help understanding this issue
Usually, the delivery of the customer is about a month. However, the raw material supply of the product is about 6 to 10 months. So we have to make it in advance.(Make to Stock). So we couldn’t even use MRP. We made a forecast and entered Forecast/MPS, but it wasn’t too accurate.
We are producing the same product from two outsourced companies, and my accounting department wants to appear separately in the inventory report because the Std cost is different.
So we also considered generating part numbers per outsourced, but the sales team was against this method. This is because the sales team does not know which outsourced products will be shipped when entering sales power/sales orders. After the FG to be shipped is confirmed, the sales team must frequently make corrections.
So, we are thinking about alternatives that satisfy the needs of the accounting team without affecting the Salesforce/Sales order input of the sales team.
So, first, Sales always wins, and that’s fine; they pay the bills. So sales order is for part A every time, and I would agree with that anyway. So we start there.
Second, you have C and D (and I hope these are indeed two different part numbers separate from A). These need to be stocked.
So now you need a way to turn C or D into A. That’s a job.
Now, understand that a job does not need to correlate to anything physical. The process to make C might be a job, but that’s not what I am talking about. After C is done (made, bought, whatever) and received to stock, you make another job to turn it into A.
I’d suggest that A is a non-stock part and thus made to order (as it’s really a placeholder for C or D). So you only complete the jobs for A as needed (and at that point you’d use up C or D, similar to shipping those parts).
Then you’d see the variances in the jobs and could even trace them to their sales orders if needed.
Yes, it’s work and takes some management (hello, dashboards!) but this is what you are dealing with.
I have some thoughts about revisions, but I don’t want to throw too much out there.
Read if you are ready...
(I’d say have two approved revisions for part A – one uses C and one uses D – but with different effective dates, to try to balance the demand for C and D.)
Sorry to keep bothering you, but I have two questions about your comments.
I’m interested in a way to utilize revision. Because I’ve been told that someone can use Revision for this issue. So, we made different revisions for each outsourced and tested it. However, as a result, since the cost is one per part, it was not possible to put the cost per revision. Could you please explain on your revision solution?
How to convert “C” and “D” to “A”. Converting through Job seems to be cumbersome. Is it possible to convert through MoM’s Kit feature?
For example, if “C” is registered as a kit material in the MOM of “A”, when “A” is shipped from Shipment, “C” will also be exported to STK-KIT. “D” will inevitably have to be converted to “A” via Qty adjustment, but “C” is more frequent.
The revision idea is just a branch off of the job idea. Just a way to coerce MRP to give you a little demand for each of C and D.
Converting through job is definitely cumbersome. No disagreement there. But when you want to do two opposing things at the same time, this is the answer.
The kit thing, you’re not making any progress there, since you wind up with quantity adjustments anyway. Plus you end up with part C on the packing slip and the customer is wondering what that’s about and where is it. It’s just an extra step with no real benefit that I see.
Here’s the thing though Pilio, you can still see profit margin regardless of the revision so you’re good there.
What you are asking to do is create two standard costs… I think the idea of standard costing is that you have 1 standard cost so you can measure against that standard. The whole purpose of setting one cost is so that you can analyze why you didn’t meet that goal.
If I said I want to achieve something and then just lowered/changed my standards because I was failing to meet my original goal am I really achieving anything?
In the case of this revision if you want to track efficiencies you can use the production detail report for it. It uses the estimated costs which are sourced from the BOM/BOO (AKA the Rev). Then you can see how it ran.
When it comes to analyzing variances you will be shown how manufacturing at this different rev affected your organization’s original goal of producing it at rev A. In other words, if you use more material or more time in Rev B, it will shake out in the variances and let you know just how much more it cost you to make Rev B. Or maybe it’s the opposite, maybe you are using less money.
In either case, it prompts you to assess why you are making B and what you can do to stop that.
I see where you are going though and I see how creating a standard based on a rev could help, but does it really help? Don’t you want to see how much money you wasted by producing Rev B that costs more than Rev A? Maybe you don’t. In that case, I see your point, let us make standard costs based on Revs.
Rambling here, but in short, changing your standards every other job defeats the purpose of standard costing, IMO.
Maybe I am completely misunderstanding what you are trying to do here, but I am going back to foundations of standard costing to refresh.
Thanks for your comments. I am already familiar with the concept and purpose of Std cost.(especially analyzing PPV)
Although not mentioned earlier, one outsourced company is a domestic company and one is an overseas company. So the cost is fundamentally different(Assembly cost difference between domestic and overseas, import/export incidental cost, etc.)
Because the innate cost is different, I think the cost analysis should be done separately.
So I’m arguing to separate the parts, but the sales team is against it. Because they don’t know it at the time of entering Salesforce/SO, and have to change it later.
I’m looking for ideas to see if Epicor can solve my problems. The optimal way to satisfy the opinions of all departments is always difficult.
