Came across an interesting question that I hadn’t thought about and I’m curious what other people are doing.
Epicor determines the due date for the suggested PO based on the date the order needs to ship by. We send the po to the vendor. The vendor interprets that date as their ship by date. In other words, when they come back to us and confirm the po, they are saying yes we will ship the po on the date you requested. Not, yes we will deliver the po on the date you requested.
There is then another day or 2 of transit time between when the vendor ships it and when we receive it.
The disconnect is that time phase goes off the due date of the PO, so it looks like we should have the inventory required to cover demand. But in reality we are late.
Even if we put the expected promise date on the po release once confirmed, and take transit time into account when populating that date, it doesn’t matter because time phase looks at the due date.
I know we can put receive time on the parts, or pad our lead times, to get epicor to back everything up a day or 2. What else are people doing to deal with this scenario?
We treat the PO Due Dates as the date due on our dock, and we communicate that to the vendor so they understand they need to take the transit time into account to be on time to us - I don’t have a PO form in front of me but I think we updated it to say something along the lines of “Due Dates are when orders are due at destination” in the comments or header. We don’t manage the vendor’s transit time for them.
That also ties in with how we’re measuring vendor performance: we calculate whether orders are late or on-time based on the arrived date on packing slips compared to the due date (or promise date, if there is one). Since we’re only measuring against when we received the parts, that’s the date we’re entering on the PO.
The only time we’ll take transit time into account is if we’re ordering tooling or supplies from a vendor like McMaster-Carr or Amazon. In those situations, it’s up to the Buyer to make sure the selected shipping option will have the parts to us in time.
Per the help file, the due date is the date you need to receive the items, so you are using it as intended. If suppliers aren’t finding this clear, maybe modifying the SSRS report to say “Required Delivery Date” instead of “Due Date” would help somewhat.
I guess the part that is still confusing to me is how promise date is supposed to work. If I put a due date on the PO, and then the vendor comes back with a different date for whatever reason, I either have to unapprove the po and change the due date and reapprove if I want epicor to “know” that the po is coming late, which then ruins the possibility of measuring supplier performance. Or I fill in the promise date which allows me to retain the original due date but does not tell Epicor that the po is late.
You are correct. I don’t know what to say, I find it surprising that supplier performance is measured off Due Date and not promise date. Seems like suppliers should be held accountable to what they promised, but you would also want to track when something is actually due to deliver for planning purposes. It wouldn’t be hard for them to update the BAQ’s on the supplier performance tracker.
So if a supplier promised to deliver on 3/7/24 but then tells you that due to bad weather it wont be delivered until 3/8/24 it seems like the promise date should remain 3/7/24 but the due date, when you expect to receive it on the dock, should be updated to 3/8/24.
It almost seems like there ought to be three dates:
The date we need to get this in order not to screw up our plans and promises.
The date the supplier promised to deliver.
The date we actually expect to unload on our dock.
I agree that performance should be measured from the Promise Date. It’s the same with Sales Orders: if you’re going to be late or if you need to reschedule shipment to the customer, you need to change the Ship By Date but keep the Need By date the same (or create a Promise Date field that never changes…) or else Epicor won’t know when you’re actually shipping your parts.
We created our own Supplier Scorecard report that uses the Promise date on the PO Release/Line instead of the Due Date. The only time we’re using the Due Date is if the Promise Date wasn’t entered. This lets us reschedule/update our POs as the vendors move stuff around but also lets us measure performance to the original promise date they gave us. We only change the Promise Date if the date change came from us. We’ve toyed with the idea of adding an Original Promise Date or Original Due Date, but no one’s thought it’s important enough to prioritize here.
