Hi @tricia.roth 

Core functionality calculates the Planned Receipt Date by using the below logic:

Planned Receipt Date = (Planned Arrival Date + Internal Time + Internal Inspection Time)

The Internal Time is set-up in the Supply Chain Matrix and the Internal Inspection Time is set-up in the Supplier for Purchase Part.  

That said, what business requirement are you hoping to solve or achieve with a Planned Receipt Date that is always in the future?  This will help to provide some additional direction.

Have you set the Supplier Manufacturing Leadtime and the Inspection Leadtime (if applicable) on the SFPP?  This in conjunction with the Ship Via/external transport times etc on the Supply Chain Matrix will calculate the dates for you. This information calculates the “Latest Order Date” and warns you if you are requesting the parts sooner than the leadtimes set.

We have lead times, inspection lead times in SFPP, but we don’t use ship via and external transport time in Supply Chain Matrix. 

We’d like to be able to use Auto PO Processing, but one of our concerns is that the PO will go out to our suppliers with due dates shorter than lead time. Purchase reqs currently will sometimes calculate due dates that are shorter than lead time. 

We are using MRP, but we aren’t using a forecast or a fully loaded MPS. This means we are often ordering when inventory is below safety stock. It gets a little confusing here. Sometimes, the planned receipt date is today and sometimes, it’s correct, and sometimes, it’s early, but not today. We haven’t been able to figure out what it’s doing. Instead of warning me, I’d like it to use the calculated due date.

Hi, on the Purchase Requisition the latest order date will be based on the leadtimes from the Supplier, however if there is a demand for this part sooner than when the IFS deems it possible to get the stock in this will be the “wanted delivery date” on the Purchase Requisition. 

The reason that you are seeing it sometimes being correct is when the demand is in accordance with the leadtimes and therefore the wanted date is in line with the latest order date, when it is  incorrect  is when there is a demand for that part where you need additional stock which is required outside the leadtimes of the supplier.

Example I have a part that has a 2 day leadtime on the SFPP 

Tuesday morning - demand goes on for Thursday - run MRP - latest order date =Tuesday (today)/Wanted delivery date = Thursday

Tuesday morning - demand goes on for Wednesday - run MRP - latest order date = Monday (which means I am late in ordering it)/Wanted delivery date = Wednesday (below the supplier leadtime but that is when the system needs it

Tuesday morning - demand goes on for Friday - run MRP - latest order date = Wednesday (tomorrow)/Wanted delivery date = Friday

The wanted delivery dates are driven by the demand in the hope that the Supplier maybe able to deliver earlier and meet your required delivery dates.

It may be worthwhile reviewing your safety stock levels ensuring that you will always have enough in stock to meet your “urgent” demands or alternatively use planning method b or C and use order points.

I hope the above has helped explain why you are seeing different dates.

Regards

Jackie

Thanks for the explanation. Do you know of any way to force it to just use the calculated due date regardless of when the system thinks we need product? 

Hi, unfortunately there is nothing as standard and it would mean a CRIM.  I would consider reviewing your SS and order points before going down that route as this should resolve the issues that you are experiencing.

Kind regards

Jackie

We’re using the system a little off book. Although we are using MRP, our safety stocks are typically  order points (safety stock + demand over lead time) because we don’t have much of a forecast and don’t use MPS. We prefer MRP so we can see ahead when there is something to see. Most of our purchase orders are created when inventory is below the IFS safety stock value since there isn’t much to see in the future. We are working on implementing DP which may help, but that is probably still several months off.