Planning Workbench suggestions not factoring in Receive Time

Assembly XYZ had a suggestion in Planning Workbench to postpone a firm job until the SO release ShipBy Date.
But we want the the job to be targeted to be completed 1 day prior to the ShipBy date, so any suggestions should also incorporate this.

  1. I changed the Receive Time on assembly XYZ from 0 to 1 days.
  2. Deleted the original suggestion in Planning Workbench.
  3. Re-ran MRP for assembly XYZ.
  4. The same postpone suggestion was recreated for the same firm job, and the suggestion still said the job should be postponed until the ShipBy date, rather than 1 day prior to the ShipBy date.

Note that in Site Maintenance > Planning for this site, that Receive Time is checked, under Include in Manufacturing Lead Time Calculation section.

Receive Time is subtracted against the Required By Date, not the Ship By Date. If you have your Ship By and Required By synced, it should work. Double check the Required By on the job to the Job Complete Date to see if it is working.

If this is a Make-to-Order job, Receive Time is not one of the factors in play. Receive Time (according to the MRP Tech Reference manual):

Manufactured Parts- The Receive Time value indicates how many days required to move a manufactured part quantity either to stock or the next job.

For MTO jobs, you need to use the Need By and Ship By dates on the sales order to affect the Due Date on jobs… MRP will ALWAYS use the Ship By date for MTO jobs.

1 Like

That is a nuance that I missed, if it is a MTO, there is no next job or move to inventory. Thanks for pointing out.

This is not an MTO job; it is make to stock.

It may be helpful to make this situation more concrete by stating some specifics:

Goal: We want make-to-stock product to be finished and ready for palletization the day prior to shipment.

  • SO Release ShipBy Date: 12/24/2024
  • Job# 1234 RequiredBy Date: 12/24/2024
  • Job# 1234 Due Date: 12/23/2024
  • Suggestion for job: “Postpone Job, Earliest Due Date:12/24/2024”

So, there are actually two questions:

  1. Why are our job Due Dates always 1 day prior to the RequiredBy Date on all of our unfirm jobs for all assemblies? (Which, of course, then remains 1 day prior when the job is firmed. I understand Due Date is calculated, but I don’t see where the modifiers are that are generating this.)
  2. How do we get MRP (and its suggestions) to set the RequiredBy Date to the day prior to ShipBy Date? (My assumption was that adding a Receive Time of 1 day to the assembly part’s Planning tab would, at the least, prevent a suggestion from being created to postpone the job, but if the suggestion is deleted, then it is recreated by MRP’s next run. This also suggests that any new unfirm jobs for that assembly would similarly not have its RequiredBy date moved to 1 day prior.)
  1. You will need to check to see if there is a BPM that sets the receive time of every part created to 1. OR. See if Receive Time is set on the Part Class. Those are the 2 things that would be making every part have a receive time.

  2. You cannot (without a customization/BPM). The way Epicor works is the Required By date is the Required By date. Receive Time only affects the Due Date. This is because Required By is the absolute date. If you were in a crunch, you can ignore the Due Date as you know that the Due Date is the GOAL and not the absolute need by. The system is providing the dates to help you make decisions when you are over capacity.

  1. No BPMs to set Receive Time at the Part level (I write all the BPMs). All Part Receive Times are zero unless manually altered. No Part Class has Receive Time defined.
  2. Ok, so the procedural discipline needs to be around Due Date. That’s fine. But I still don’t see why setting a Receive Time of 1 day would still prompt MRP to create a postpone suggestion to recommend a Due Date = Required Date. Of course, we can lock the job dates to prevent suggestions, but I’m troubled by the logic.

Just went to the Scheduling Reference Guide. There are too many dates in the system!!!

the Due Date is the Required By Date.

Then why not just call it Required By Date Epicor?!?!

So, the date that you actually want to use is End Date (as defined by the manual). But I have not been able to find a field on the JobHead, JobProd, JobAsmbl, or JobOper tables that is “End Date”. My best guess is that you have to get this from the JobAsmbl.DueDate or the JobOper.MoveDueDate fields. Sorry I can’t give you an exact answer, but I would write a query that pulls a bunch of the date fields from the various job tables and see which one is the date that you want.

Logic
The End Date functionality uses this logic to calculate its results.

  • When Backwards Scheduling, you enter the End Date value manually.
  • End Date (Forward Scheduling) = Start Date + Assembly 0 Time + Assembly 1 Time + Assembly 2 Time + and so on…

Ok, playing around with an unfirm job I think I understand it slightly better.

As generated by MRP:

  • RequiredBy Date: 3/12/2025
  • Start Date: 3/5/2025
  • Final Op Date: 3/11/2025
  • Receive Days: 0
  • Due Date: 3/11/2025

Then, I updated the Receive Days on the assembly to 1.

In Job Entry I chose Actions > Schedule > Job Scheduling, then for our backwards scheduling it defaults Due Date in the popup to the RequiredBy Date. However, when I click OK to schedule, it results in:

  • RequiredBy Date: 3/12/2025
  • Start Date: 3/4/2025
  • Final Op Date: 3/10/2025
  • Receive Days: 1
  • Due Date: 3/11/2025

So, Due Date is not altered by Receive Days. Instead, Receive Days pushes back the Start and Final OP dates, to accommodate the extra day needed due to Receive Days.

This also explains why the suggestion to move the Due Date was unaffected by adding Receive Days.

So, for the production floor Final Op date will actually be more important as a target completion date than Due Date, if Receive Days are used.

As importantly, I also suddenly realized when I had the Actions > Schedule > Job Scheduling popup open that the Due Date defaulted to the RequiredBy Date, but as importantly the Due Time defaulted to 12:00am!! So, this was saying that all operations had to be completed by the moment the Required Date started, or stated alternatively, by midnight on the day before the Required Date! Hence, this would explain why the Due Date defaults on our jobs to the prior day.

So, the scheduling is more like (going backwards in time from RequiredBy):

RequiredBy Date
Due Date
[ReceiveDays]
FinalOp Date
[OperationTime & Move Times Total]
Start Date
[Kit Time]
[Production Preparation Buffer Time]