Just wanted to float a business process financial issue to see what others maybe doing.
Currently Customers sometimes need parts that were sold to them repaired under warranty, but that is not done in the field, instead an RMA is issued for the part, received to a Job and then shipped back to the customer on a Sales Order. Part is standard costed and the Sales Order’s Unit cost is the cost of the repair, usually just labor. This results in a Financial Loss, example:
Part’s Standard Cost: $1000
Sales Order Price: $250
Job Costs: $175
COS: $1000
Invoiced: $250
Loss against GL: $750
Tried creating a separate part with different costs but since the repair cost is variable, it’s not reliable.
If the COS that is captured was the Job Cost instead, it would be appropriate.
What else are people doing?
At the time you receive the RMA (or Dispose, don’t recall at the moment), you have an opportunity to change the cost. Previously, we set it to zero and issued it to a job then shipped directly from the job. Zero goes in, add material and labor, and then use a Product Group on the order that has Warranty Expense for the COGS and I think you’ll get what you want.
Thanks Mark,
Already tried this. Since the part is Standard Costed it doesn’t matter what costs go into the job for the COGS, COGS always picks up the Standard Cost Elements to hit the COGS mapped account (per Product Group), which account it hits doesn’t matter, the fact that the Standard Cost hit’s any account is incorrect because the part Rec’d to the Job does not have the same value as a new part.
Are you sending it back to Inventory? If the job is Make Direct then I’m pretty certain that the Std Cost does not apply. (Unless we used a Non-Stock part on the Job… )
Confirmed with support and tests that Make to Order or Make to Stock both will use the Standard Cost for all Receipt and Shipment transactions.
I tried Non-Stock part, but the Cost that comes through is still the Standard not the Actual Job Cost.
The only way to do it is to use any other Costing Method but Standard, then Make to Order is actual Job Cost. Trouble is a different part number and different costing method creates their own problems… or hoops to jump through.
I kinda wish that there was some type of Job Cost override that when a Job Shipment or Receipt is done, it could use the Job Cost instead of Standard but all other times use Standard.
Another scenario I have seen where this is a problem is when a part is sourced both via an internal job or from a Supplier. While it may be cheaper to manufacture internally sometimes resource bandwidth forces parts to be sourced from suppliers.
Create a separate part with Non-Stock and Non Qty bearing, and add to the sales order. During shipment it won’t generate COS. Once the job is closed, MFG-VAR will post to COS/Variances based on Company Configuration Direct Ship Std. Cost Job Variances flag.
After thinking about it over night, we did use a different part number - -R (for refurbed). We were also serialized, so the same serial number was used on both parts which gave use a link back to the original part number. The advantage of the -R part was it could have a different cost basis and sales price if we sold the part as a refurb. This is more important in an exchange/repair program than straight warranty.
I have used “Override Costs” on Job Receipt to Inventory. However, that was for a Last-Costed part. I’ve never tried with a standard-costed part, since having it hit variance always made sense.
But then the shipment is at standard (as you said), so I think you’re still in the same place as before anyway.
Also, on a tangent, I set the MFG-VAR account to go to COGS on the product groups we use for last-costed sales. Well, that was a mouthful. Let me try that again.
For a last-cost part, made direct to a sales order:
When you ship the job, all costs go to COGS
If you charge time or materials after that shipment, costs go to MFG-VAR
I set the account on a mfg-variance to hit our COGS account for certain product groups - the groups we use for last-costed, make-direct items.
My thought is that the costs were supposed to hit COGS anyway, so there’s no point in ths costs hitting the same variance account we use for, like, welding.
@jkane
Yes, this is the direction we are considering, since there is no good way to get COGS to reflect the actual cost when the Part is Standard Costed.
Epicor’s Field Service module doesn’t fit our business model. We create a Case (for notes) > issue RMA against the serialized part > RMA Receive > RMA Disposition (select Override costs and wipe out Material dollars) > Job (Change group to Service Sales Standard > tab Job Details > Materials > Detail > Under Unit Cost Breakdown, zero out Material dollars). This keeps the GL clean. Also create a SO to ship out on. BUT the SN is not released from WIP because we add a -Service to the original Part Name but this doesn’t affect overall WIP because the group is Service Sales. To release the SN from WIP, go to SN maintenance and change WIP to Ship. There will be a ‘are you sure’ warning but we ignore with zero issues. Wish it could be cleaner.
Rick, I’m going to make a plug for my idea again. I mapped this out a bit better.
So, the big assumption that I am making is that the product group that you sell it under is NOT the same as the group that you use when making it to stock. If they are the same, then, yes, my plan is hosed. Here, they are different.
When we make to stock, MFG-VAR always hits an account called “Manufacturing Variance.” That’s because stock jobs always use the product group on the part itself.
But for make-direct, we often use a different product group - the one that it will be sold under. Thus any variance hits COGS instead of… variance.
You can still use Field Service, I did at an old company. It was really nice because it actually broke out the repair costs. You could also have a parts price list if there is an upcharge on using parts to repair. We had the same process flow you outlined.
@Rick_Bird - Could you customize the posting rules to override the COS with the sales order price? Maybe the condition could be triggered by a boolean on the sales order.
This was already mentioned but figured I would offer some advice based on our experience since we had this exact issue.
When dispositioning the warrantied part to a job, the override costs box must be checked and zeroed to prevent this part from coming back into WIP at cost and a credit against COS. If it is not checked, once the job is closed and completed WIP will be credited and COS will be debited. This will wreak havoc on the books if you have multiple COS GL accounts setup (standard sales, warranty/service, etc.). We also have to manually zero out the cost of the warrantied part on the job to prevent sales margin reports from being inaccurate since this data is pulled from the job.
So the issue isn’t with the Disposition Costs coming into the repair Job, we’ve been zeroing those out for years. And actually for a Standard Costed Part those costs that come into the Job never impact COS, it would just end up as part of the Variance if the Cost if above the estimate for the Job Material… which can also be set to zero as well in Job Entry. However, none of this actually addresses the COS impact of the Job Part if it’s Standard Costed. A Standard Costed part will always hit COS at the Standard no matter what the Job does or how crazy your variance is.
The only way around is is to use an Average or Last Costed part for the Job Part. THEN, the actual Job Costs will hit COS, which is what we need.
Of course, in that case, if the part being Dispositioned was the Job Part’s ‘first generation’ part with Lots of costs, the Disposition Costs need to zeroed or adjusted or that Cost will end up in COS.
In the end we created new Parts that are Average Costed, so we don’t hit COS twice for Refurb Jobs.
Thanks to everyone for the input and stirring up lots of thoughts and tests!
@askulte
Perhaps, but that seems messy, and we don’t want the Sales Order Price, we want the Job Actual costs.
We do want to see a real Profit Margin, which is part of the problem now… we are double dipping on the COS.
)
