I would like to make scrap functionality work a little easier in MES and expand it’s usefulness. Currently (as far as I know) - you can only report scrap in MES when you End Activity - it is attached to the LaborDtl. This means I can only have one scrap qty and reason attached to a labor dtl.
We would like to be able to report many different scrap types and quantities. For example during a job an emp may have:
4 short shots
8 color splay
The only way (without creating a new table) I can see to do this is to make additional LaborDtl’s against the job to report that. They would have production qty of 0, but have some scrap qty and reason code. Is it a bad idea to do this?
My company currently gets the labor cost of employees based on parts produced, not actual time.
Also, another issue I’ll have to tackle is scrap on assemblies. Currently, when they report scrap on an assembly, it counts against every part in the assembly - there seems to be no easy way to scrap a sub component of an assembly without scrapping the whole thing. It sure makes scrap $$$ look horrible.
This is something else on my bucket list - an area in Report Quantity and/or End Activity that would allow for more then one scrap reason! I haven’t had the time to work on anything yet but if and when I do, I’ll share it with you.
I think you can report non-conformance on the fly which starts the convoluted, way too many screen process that Epicor has of reporting issues. Then someone (QA) would go through the list in inspection, then DMR and scrap them out that way.
In base Epicor, that is the only other option but it causes too much data entry for items that just need to get scrapped. The only reason we want to do it on the fly is because you can only add one scrap reason code when you end activity. We want to track the type of scrap so we can improve our processes. If you don’t non-conform the scrap, then you would have to start activity and end activity for every type of scrap for that day. Way too cumbersome!! Thanks for the idea though…
We have exactly the same problem - scrap produced for various reasons but no way to record more than one type and no way to record scrap without ending the activity. Did you come up with any solutions at all?
That sounds like what we want to do. How did you create the scrap workbench? I’ve been trying to follow the coding but I think I haven’t quite understood where that code goes… We have only been running on Epicor for 6 months now so still learning the customization processes…
Read through this posts (it’s a long one) but it works through how the labor transactions are done using C# code. I based mine off of the dashboard, since you’ll need the BAQ anyways. And I wasn’t doing anything with scrap, but that would just be one of the parameters to set when you make the labor transactions.
And then have it create a time and expense entry (laborHed/Labordetail) record in the same way that one would when entering a time and expense entry as below. The circled items would be entered by the employee, the purple squares are entered by context, and the red squares are set regardless.
Not with scrap but rework, taking a non-customisation route we wanted to capture rework - whether it be on a final assembly or sub assembly and recognising we wanted the operator to capture the rework not faff about looking for paperwork for a particular job assembly as we run 100’s of different part numbers through the shop floor each day. Similar to Chris we would be reworking parts of major assemblies. For us it was about catching an indicative cost/time for rework.
For example at our paint shop we created three rework jobs each with a single paint op, time per part and setup as report quantity basis and with a ridiculous job qty (9999999) and scheduled for 31/12/2099 so it does not appear in any reports; small part job, medium part job, large part job - small part takes 10 minutes, medium part 20 minutes, large part 60 minutes. These jobs are set as report quantity.
When the operator wants to book rework they just log a report quantity transaction against the relevant rework job and we added a field to write to the ops comment field for that labour transaction. We do lose granularity on being able to id exactly what jobs required rework but it meets our purpose of capturing a real time indicative measure of rework cost, something we did not have before.
Unless you have a large amount of scrap causes at each operation, you could theoretically adopt the same process to scrap so applying Chris’s original post you could have a short shot scrap job, colour splay scrap job and flash scrap job.
This is not a one size fits all suggestion and is really about capturing time and quantities, but depending on the complexity of your ops/products and the level of granularity/tracability you need it may work.
So @RobHunter. Here’s a little advice for using the forum to help you get stuff done. You have to remember that the people helping at other working folk like you. So while we are all willing to help, we aren’t going to be able to do it for you. The approach above where you listed out what you want is a perfectly valid approach when you hire someone to do this for you. And that’s a viable route to go if that’s what you need, and you explained your needs very well. But, If you really want to do it yourself, what you need to do is to start something, get as far as you can, then ask the smaller questions when you get stuck. Basically explain what you want do, (which you already did) then, here’s what you have started so far and here’s how you understand it should work. You’re at X piece and it’s not working the way you expect. What are you missing?
Ultimately the majority of the work needs to be done by you, and if that’s the case case you can get lots of help. You just have to remember what type of resource this place is. It’s a great one with lots of knowledgeable people, but this isn’t the place for consultant work.
I hope that helps you out. I hope I don’t sound rude or condescending, I just know how hard it is to hit a wall like you did with Chris and I. I just want you know why.