Sending out an SOS, sending out an SOS, sending out an SOS…
@jkane@Nancy_Hoyt@Banderson have any of y’all been able to get a material non-conformance originating from a job to post according to the job’s product group when inspecting it - rejecting it, DMRing it and then rejecting that?
The idea being that scrap costs could be allocated to a product group…
@utaylor We use a general MTL-INS account, but break down the PG for INS-DMR, DMR-REJ, etc for each cost layer. We have a cost center attached to a product group.
I have not looked at it in a couple of years, but due to our historical problems with processing it, we have a “rule” to return the job material to inventory and then do the nonconformances from inventory. We also put the job material on “rework” jobs sometimes as well.
Also, do you know off the top of your head how reporting scrap during end activity hits the GL? I reported a quantity in there, but I see no financial transaction for it… is it purely notational?
Reporting SCRAP does nothing with the $$. You need to report it as an NCR to get the $$ to move. That setting is on the Company and is what allows the $$ to move off the job. If it is not set to true, then the $$ will always stay on the job.
Important: Assembly costs are not removed from the job when the assembly is in inspection. They are removed only when the assembly is failed in inspection and then moved to DMR. Also, this check box applies only to assemblies.Material costs are taken off the job as soon as a specific material is moved to inspection, regardless of the setting for Move Costs to DMR."
Here’s my predicament… We have scrap % set in our method.
When we generate scrap or have scrap we want to record it using non-conformance so we can understand it later on…
Standard costing is what we want to use to understand costing discrepancies. Standard costing uses the scrap % on the method to come up with the cost. But when measuring scrap via non-conformance, it said right there in the last documentation I posted, non-conformance removes the material cost from the job.
Therefore we get an INSTANT favorable variance as compared to the standard that was calculated with scrap. I have to be missing something right?
Am I really seeing that if you want to record scrap via non-conformance you can no longer generate a variance from it? Seems really odd that on one end they use scrap to establish a standard, but then when measuring actual cost they ignore non-conformance scrap.
You know what man, let me detail out exactly what’s happening.
In my method I have a raw material that we run through a slitting operation to cut it to a different width.
There are times where the raw material is bad and we can’t use it at all in the product. This sunk cost shouldn’t be allocated to the job I guess is the thought, right?
Are you backflush? If not, I would expect the employee who is bringing the material to the operation to do a quick visual inspection to see if the material can be used. If it can’t, I would then expect them, or QA, to do an inventory NCR.
I think that I need to re-assess what we are defining as scrap % on a method.
Because I think that we are making it something it’s not here. Like our definition of scrap does not align with Epicor’s internal engine and thought process of scrap.