No we aren’t using AUOM.
If JobHead.ProdQty is actually a summation of JobProd records and has a ProdQty of 1, that would tell me that the JobProd record(s) is/are being deleted?
Your second comment sounds more to the point. It seems that something is breaking in the process between the JobHead record having been created and the creation of a subsequent JobProd record.
JobHead record is being created successfully as far as I can tell. If there was a problem there, the whole job wouldn’t exist since the child records would have nothing to attach to. And yes, ignore JobHead.ProdQty. ProdQty is recalculated on any change to JobProd. So if the system tried to write to JobProd, and then that failed, it could still trigger the system to recalculate the JobHead field (resulting in zero qty on the header).
The focus on your investigation should be why JobProd record isn’t being written by MRP. In fact, I’d try to see if I can manually trigger a write failure to JobProd (via client, Function, or even DMT (though DMT & UBAQ uses UpdateExt so results might not be applicable to MRP).
@jkane’s suggestion of going down the next level to the DB is also a good idea. Just make sure whatever method you use works even in the case of rollbacks, as some kind of rollback would explain what we’re seeing here.
If you are on prem and have someone who understands SQL, I am sure you could get a log of what is happening to the table in SQL instead of Epicor.
@jtownsend I agree on all points. I think a SQL trigger is probably a good idea as well. I am going back to Texas and be out of pocket for the weekend, leaving tonight and returning next Tuesday. I will be taking this back up then. Thank you for your input thus far.
@jkane I am the SQL guy here. 
Between setting up a trigger on record deletion and/or setting up a logger, both are good suggestions. I will be looking into this more when I get back. Thanks for the suggestion(s).
This issue normally happens when JobProd gets out of Sync from JobPart/JobHead. Essentially JobProd records for MRP jobs are not deleted properly and when MRP tries to create a Job with the same MRP number it fails since the Part Numbers do n ot match and leaves the Job with 0 Qty.
Epicor has a Fix, contact support and ask for the fix, the name referenced by the fix was CR36561MPS, if you are using the inspection module you also need to clear the remaining items from JobOperInsp (If you don’t you will get an error when MRP tries to copy the BOM), fix for that is CR7330BRK.
Do you have recycle MRP jobs turned on during your MRP run? I have seen this do a similar behavior in the past. Essentially the recycle MRP jobs removes most of the job data except some of the top level tables, it is possible that it is not clearing out all of the data. The feature itself was useful back in the day, but since the new framework I haven’t seen a significant performance improvement with turning it on. Also it would be good to verify that your start date and end date(if used) are set to a dynamic value if run in a schedule this can also cause issues with the results especially when your end date is set before today and historical dates are turned off.
Thank you for the suggestion. We ran this by Epicor support and they told us that this particular fix doesn’t address our problem. See below thread as we have found new information about our issue.
We are now finding out that our original results were not the same as what we are getting now. In my original test database I deleted all customizations and disabled all method and data directives and running MRP produced jobs with ProdQty = 0. In the next version of the test database I deleted all customizations and deleted all method and data directives. Running MRP versus that database produced 0 jobs with ProdQty = 0. I would think that the results would be the same versus either, but go figure. Your/my first thought would be that I missed one or more, maybe the important one, but I double-checked and that was not the case. At this point, the next step will probably be to go through adding BPMs until we find our culprit. I will post our final results summary here once we have resolved this issue. Thank you all for your help.
As a follow-up and not let this dangle without a solution, it seems that there was a scheduling process that was occasionally not running due to a previous process running longer than originally tested/designed and also was not setup in the correct order. Once we reshuffled the schedule and lengthened the time in between each process, the problem went away. As always, thanks to all who gave answers and insights.
Hi Jim,
We are currently experiencing the same issue that you had experience with our MRP run. You said you reshuffled the schedule and lengthened the time between each process. May I ask how did you achieve that? Is that via schedule process set or somewhere else? Please let me know.
Thank you.
It’s been a minute but yes. our “MRP run” is now made up of 5 scheduled jobs run from the System Agent: 1) Process MRP Recalc, (2) Process MRP. (3) Scheduling Set Order Process, (4) Scheduling Process and (5) Generate PO Suggestions. I took the longest time that each process ran and added 30 minutes to it to calculate the start of the next job and ensure they wouldn’t run into each other. MRP has run like a champ since then. Hope that helps.
I would do this in a process set this allows one to finish and the next one to start right afterwards.
Noted. Thank you for your response Jim.