I have a custom process that I brought from our previous system. In inspection processing if the scrap is ours and not a vendor defect the inspector can add the material at the bottom of the material list and then accept the bad material back to the job on the added material. This also make jobs gone wrong easy to spot in job tracker.
@utaylor , got it. Iâm having flashbacks because we have had this conversation on the forum before. 
Iâm just going to be quiet now.
The Production Yield Recalc will only address your issue by lowering the Prod Qty on the Job where something was scrapped. With the loss of supply, theoretically it should create a new Job to make up the fall in supply. I donât think this is what either of you are looking for. You are looking to have the system automatically create a material requirement when something is scrapped from a job.
Have either of you thought about using GL Control Codes to handle this? You could set the scrap context on the GLCC to point to the material account?
I love ya man, thank you for always engaging.
We are currently using the est % and recording scrap elsewhere.
If I think about where I would like to get, it would be some modified form that kicks off the âissue material to jobâ with set reason codes going into the reference.
Everyone has materials backflushing which is driving this need to add additional material used as scrap?
Thatâs the thing though, I wish the reason codes also counted it as scrapped and didnât count it as issued material so that MRP and timephase still noted that more material was needed AND so that it would stay on the job.
What is your costing method?
We are avg on most parts. std on a select few like vmi/kanban.We donât really hold inventory as most parts are very custom to a single project.
Okay, we hold raws and some semifinished goods so a little like you. We donât use average, but either way you and I both want all costs on jobs so we can see just how much it costs⌠Who is your CAM by chance?
Is there anyone else out here in this forum that needs this functionality? I would get an idea posted and reach out to Epicor to see if we canât band together and create a special interest group.
exactly this. We are going to build a custom screen into the issue material to try and help with this or something like thatâŚ
Emily A. is my CAM.
I created a Kinetic idea.
I keep running into on-the-fly job manipulation to be too cumbersome. Someone gathers the scrap number, opens the job up for editing, changes that number and releases it?
Itâs almost like you would need duplicate lines at req qty 0 to issue the scrap to. We would be okay just over transacting as we donât need to drive additional demand. The thought of double the BOM size just to add scrap layers also seems inefficient.
Right?? Thatâs way too much work to be doing and keep up with. The transactions that the operator makes should be invoking that change automatically, not us having to go back into the job and update it⌠but thatâs what doesnât exist, thatâs the functionality we are missing.
Thatâs a great idea! wow. But yeah, duplicative.
Yeah and if we find the part that we scrapped because we lost it we have to go back and change the scrap to 0 and return it to inventoryâŚdefinitely a very manual process that people have to remember to do.
This is where I get confused. I guess because I donât have all of the requirements. I would just say over-transact then. If you just over-transact, all of the cost stays on the job. I know there is a piece I am not understanding, I just donât know what it is.
You over transact because thatâs the reality haha, you used too much material.
And you used too much material because A., you scrapped some finished product (at the end operation as you originally suggested) OR B., because you ruined some of material sequence XX when trying to run the job.
Now as you pointed out, scenario A still drives demand if you recalc yield, so we are good there, but scenario B, which happens in many industries I am sure, would show that youâve already issued X amount even though you over issued because you scrapped some⌠Again, assuming we leave the scrapped amount on the job for costing purposes.
Ok, so when you review the job, you see that it cost x and took y more material.
Over transacting shows you the true cost and material usage. Still confused here.
I like this option the best, seems quickest to implement. You wait until the operation is complete and then accept all related inspections back in. With the right reason codes it could make sense to inspectors, built in double check basically requiring a sign off. Are you using inspection processing for other functions? What are the downsides you have?