MRP Message for PO has Start Date in the Past

Michelle D.

Active Member
Hi list,
At the beginning of March, we suddenly started having an issue where MRP is creating messages to create POs with a Start Date that's in the past. We didn't make any system changes, promotions, etc and the user said they didn't make any changes. We run MRP once a week on Sunday's as a gross regeneration. Attached is a text file that shows our processing options.

I've shown the users how they can revise the Start Date and then process the message. However, they never have had to do this before and we need to figure out why this started happening and how to fix it.

Any thoughts?



  • R3483_PO.txt
    13.5 KB · Views: 14
Have you checked your calendars to make sure you're not running into an end-of-calendar situation?
Make sure the Generation Start date is not in the Past.
Date Validations can be bypassed by removing the "A" Warning Messages from UDC 34/MT. This will affect all data going forward and all users. This will allow all message types with past due start or requested dates to process.

Hi Matt, our generation start date is blank; so that's not the issue. The problem with date warning is not the warning itself. The issue is that for the messages with a Start Date in the past, when you process the message, the resulting purchase order transaction date is also in the past (the TRDJ comes from the Start Date). So we are sending our suppliers PO's with an order date in the past. That's definitely not okay.
Are you using lead time offset on your BOMs? Though that should not really affect start dates. Did the daylight Savings time have anything to do with this? The program uses the system date of the server where MRP is running. Can you set the generation start date for 1 run to today's date(actually type in the date) to see if that makes a difference?
You say your calendars are up to 2021, but do you have the "ALL" calendar setup into the future as well?
I am asking because I noticed you have a date branch setup for multi-facility.