Capturing Initial JobOper Start/End Dates - MRP not playing nice

As with many things, I thought this would be simple…

We wanted to capture the initial scheduling dates for each individual operation (JobOper) when a job first gets scheduled.

We created UD Fields to store the values for JobOper.StartDate and JobOperEndDate and a Data Directive to fill in the UD fields. When we schedule a job, it works fine.

However… when creating jobs via MRP, it doesn’t behave the same way. I half expected this which is why we chose the less than elegant Data Directive in the first place. I’ll have to see if there’s a clean way to trace the MRP process.

However, during this troubleshooting I’ve noticed that MRP does not follow the rules put in place by Epicor themselves and bypasses the EpiMagic to some extent. Nothing from the MRP process shows entries in the change log, for example. Despite the fact that MRP schedules the jobs as they are created, there are 0 entries in the change log for the modified JobOper records.

Mostly, I am venting, but I would not be offended if someone has already come up with an answer for this and wanted to share it before I beat my head against the MRP wall some more.

Well, MRP does not “really schedule” the jobs. Right?

Should you be triggering off of RTU instead?

Based on what I am seeing in the data, I assume that MRP creates the Job and must put a filler date of today in the JobOper tables until it passes the job off to the scheduling engine. I still need to dig into that a bit more to be sure, but it is putting a date into my UD fields, it just so happens that it’s always the current date.

I can check when RTU gets updated and see if that’s a better fit.

1 Like

So every operation has a start date of today after MRP processes the job? That’s interesting. I’d be interested to know what is changing the date. I would assume it is whatever schedules the job when it is released as “global” scheduling is not run.

Well, when you run Process MRP you can include the Run Finite Scheduling During MRP Calc or not. In this case, they do check it.

What surprised me is that it looks like MRP bypasses a least a portion of the development framework.

I’m not that surprised. They are going to want MRP to be as efficient as possible, so I am sure they skip a lot of the framework. Plus, you have the MRP logs catching everything that is happening.