Is there any way to change were the material and labor cost from scrap reported via end activity goes? We want it to go into a scrap account and not the general COS account like it currently does.
Are you using a reason code for scrap? What does the reason code that you have set up for scrap have set up for the GL account?
Hmm, we got the reason codes to work for DMR’s, but it didn’t seem to work when we selected the scrap option. Probably means we made a mistake, let me try the whole process again.
The Scrap checkbox for a Scrap type Reason code, says:
Scrap
Select this check box to indicate if it is a valid reason to be used for scrap. This reason code can be used for Quality Assurance transactions related to scrap: ASM-INS, MTL-INS, or SUB-INS.
When you say scrap, are you referring to material issued to a job, that doesn’t end up in the final product? Like Scrap Qty on a Job’s Materials details?
When you complete a line on the job it gives you an option to state how many pcs of the finished product had to be scrapped. First time I did that the scrap seemed to go to the COS. I think maybe the reason code had no GL associated to it at all. Second time I tested I made sure it had a GL associated to the reason code, but the scrap didn’t show up anywhere that I could see.
I think I must have made a mistake somewhere, so I am going to double check everything and try again tomorrow.
Wouldn’t reporting the scrapped Qty of completed pieces just reduce the net Qty produced? The total cost to make that net qty is the same. But with fewer made, the unit cost would go up. So the scrap should be included in COS, no?
That all depends on how your jobs and your business and your accounting practices are required. If you jobs are required to have the total good parts be the job quantity, then you would need to keep making part, and the scrapped ones be reported as well to keep inventory to order by issuing the material required to make the. Bad parts (assuming backflushing). If your jobs only require the attempt at the full quantity and bad ones just scrapped, then it would be as you described. That depends on the nature of the business and how the business wants it set up.
As far as scrap and where the costs go, that’s up to the business to decide as well. If they don’t want to count scrap to cost of sales, then can separate it to a different account. If it were me, I would want scrap to go to cost of sales on the job, but I could see arguments either way depending on many other factors.
The scrap field in MES reporting is just for informational purposes. It does not “go” anywhere. The costs stay on the job as part of the cost of manufacture. If you wanted to remove the cost from the job, you would have to create an NCR and a DMR and move the cost to the DMR and then you could select the GL account it goes to.
@Banderson and @ckrusen are correct, standard business practices are that any scrap on a job is part of the COS. You will find that most businesses operate that way and that is why Epicor is configured that way out of the box.
So if you guys wanted to make a scrap report, how would you do it? For example a report which has a list of job lines that have scrap, grouped by product group so you could see how much money was being wasted by product group and what types of jobs tend to have more scrap on them. How can I do that if its all being mushed into COS?
What type of costing do you use?
Actual Cost - FIFO
Are these make to order or to stock?
Do you always produce the desired job qty - issuing more materials as needed? Or just make as much as the original material requirements can make?
Everything is make to order with “fake” part numbers from configurators. Everything is backflushed. We always make the desired job qty, however sometimes a whole part will be scrapped and more material will have to be used. This is being handled either not at all right now or “out of the system” i.e someone goes back later and manually issues more material to the job based on the qty that had to be scrapped.
So, is it safe to say that the MOMs are not accurate? That would be the start of the comparison. But if the configurator is putting out “fake” numbers, it sounds like you have an impossible task on your hands.
The material quantities are correct (or as close to correct as we can get them). Sometimes the person running the machine makes a mistake, sometimes they don’t read the job traveler closely enough.
Whatever the reason, sometimes a whole screen (our product) has to be scrapped and they have to start over. So sometimes some material has to be scrapped, sometimes the whole screen has to be scrapped. This is not captured in the MOM as it is not predictable.
By “fake” part numbers I mean they do not exist in stock. If you right click on the part number and do “Open in Part Entry” it doesn’t open anything.
OK, that makes more sense.
If you are only looking to compare material costs, then all they have to do is issue more material to the job then you can compare the cost of the BOM that the configurator made to the actual material cost of the job.
Getting right back to your original question about whether it’s possible to allocate some costs to a separate GL code, it is possible. It’s likely to be quite a troublesome change, though, so your company would need to be very sure!
Epicor’s posting rules are sophisticated, and you can modify them to do whatever you like as long as you know what you’re doing, including the legal implications of any changes. But in practice, that means you need to get experts involved for anything except quite simple changes, and this one isn’t a simple one.
It sounds like you have some quite particular needs around your costings, and while there might be a few ways of practically seeing what has gone on, if your finance team need it sorted right in the ledger then posting rules are the way of doing it.
1 Like
I think about whether you need to change it in the GL or not. If you are simply looking for a report/data for analysis, you can get that with simple BAQ’s. It might be more complicated with part on the fly, but all of the information is saved on tables in Epicor that can be gotten to.
When you did this test, did you run capture? GL transactions aren’t done real time, so there will be a lag.
1 Like
I did run capture WIP. Can’t look again as we are SaaS users and the Pilot seems to be down.
I think I will have to sit down with management to figure out if we actually need it in certain GL accounts or if we just need a way to report scrap.
We are having issues tracking scrapped product, materials and labor scrapped, as well as rework on RMAs… Trying to figure out how to improve our process so we can get good information on it all. How do you all handle this stuff?
I’ve just looked at some records because we have some similar issues. The detail IS all there in the tables but it does take some ferreting out, particularly if you want it in a form that makes sense to people not intimately involved with the work.
In our case we don’t need to worry about Labour, but the key table for materials is JobMtl. You can use that to see what went into a job, including what was scrap etc. Officially, it looks like the scrap figure in a job method is only an estimation, and it treats all parts issued to the job as costed to that job. You can cross-reference GL to this table and create a breakdown from it, though admittedly it’s fiddly.
But as you say, the key thing will be what your Finance people can accept. They may be fine with a report additional to their ledger, or they may insist on the ledger itself showing the breakdown. Once you know that, you’ll know whether other ways are worth your time or not!
1 Like