Who has adopted the promise date in order entry and what does it mean to you?
3 Likes
I think if you miss your Ship By dates so often you need this feature you should step back and re-asses.
4 Likes
Weâve had a UD field for this nearly the entire time weâve been on Epicor since E9. I think it was one of the first customizations added, and once we upgrade to 2025, weâll be migrating all the data and reports to the new field.
The Promise Date is the date we agreed to the customer to ship parts on when we first agree to the PO. This is the date we measure ourselves against for our on-time delivery to customers. This date never is updated unless a customer requests a date change that would be reflected on an updated PO and their supplier scorecard to us.
The Ship Date on the other hand needs to remain flexible in case we need to pull orders in or push them out for planning. Itâs all well and good to say you should never be late, but if you are you need to be able to update the Ship Date to a reasonable date so your backlog and MRP planning are accurate to what you think you can actually accomplish. Because the Promise Date does not change, you can still measure your on-time performance to that original date.
The Need By date is the date the customer needs the parts on their dock. This includes transit time. We donât use the Need By date as the Promise Date since weâre measuring our on-time delivery based on when our shipments ship, not when they arrive. Having the third field lets us get the logic from transit time with Need By Date and the traceability of the original promise date with the Promise Date.
4 Likes
My understanding (which may be wrong, because I often am) is that it is supposed to be the ORIGINAL promiseD date.
If things go south, you have to change the need-by and/or ship-by as they drive other functionality like scheduling, etc., but should leave the Promise Date alone.
IF Iâm correct about that, they should (or I may) change the label on those fields to:
âPromised Dateâ (past tense) - OR -
âOriginal Promise Dateâ
I think it is the field label that doesnât quite work and creates confusion.
4 Likes
We always used OrderDtl.NeedByDate as our promised date. Even re-labeled it on Order Entry. We had very specific advertised turnaround times, and the Promised Date / NeedBy Date would always be today plus the turnaround time for that specific product. The ship by date was based on scheduling or the date the customer said they absolutely needed it. We then added a BPM to suggest adding a rush fee or expedited shipping if the RequestDate / ShipBy date was ahead of the Promised Date / NeedBy Date.
3 Likes
Yeah I think that is part of what I am trying to figure out. Is it the original needby date or is it the original ship by date? Obviously it can be whatever we want it to be.
Between the two, I would say it should be the original Need By.
ie. âWe Promise to have it to you by this date.â
Internally, that means we need to ShipBy this date.
If weâre behind⌠we could air freight (rush delivery) and still meet the Promise Date.
Thatâs the other weak point in the whole scheme. The ShipBy Date should have some kind of relationship with the ShipVia method.
If ShipVia is Ocean Freight, then ShipBy is NeedBy - (2) months!
If ShipVia is standard ground, then ShipBy is NeedBy - (2) days.
If ShipVia is air freight, then ShipBy is NeedBy - (1) day.
If ShipVia is âSame Day Redâ, then ShipBy = NeedBy.
⌠But thatâs just another whole âcan or wormsâ.
IncoTerms also add a lot of fuzziness.
2 Likes
MANY years ago, i wrote a sales order tracking system that monitored new orders, backlog, shipments, etc. we wanted to also keep track of three values:
- the date the customer NEEDS the part. While this is not what you promised, it was sometimes helpful to determine if the customer might take something earlier than PROMISED (if we were ahead of schedule).
- the date that we PROMISED the parts to the customer when the order was accepted. This was used to calculate performace of ACTUAL ship date vs the PROMISE.
- the current scheduled ship date. This was used to determine our projected SHIPMENTS (ie⌠backlog) for the following months.
When I came to Epicor, I found that the Promise Date was missing. As i went to each customer i visited as a Consultant for 16+ years, this seemed like a common customization to add⌠either that, or they would use the Need by date as the promised date, or they would leave the Required By date as a pseudo Promise date.
So, we added the promise date so that people could keep track of when they promised the order.
This allows you to actually change the Required By date to be when you will actually ship the parts (also known internally as the SHIP DATE). Since everything in the system is driven by this date, it is imparitive that it be accurate. Otherwise MRP will constantly hammer you to tell you to reschedule jobs and POs to meet this date.
Right that makes sense. I think part of the challenge is defining a process for how/when to update the need by and ship by dates given the promise date shouldnât be changed after the order is originally accepted.
This is interesting because I think if I used the Promise Date at all I would use it and the Ship By in the exact opposite way folks are suggesting. I would opt for leaving the Ship By as is and use the promise date to convey reality when something goes south.
A sales order is basically a contract, the details of which should not be changed unless agreed upon by both parties. Thinking about that, and how Epicor works (MRP, scheduling, etc) it is hard to think of a more critical piece of data to get right than the Ship By date on a sales order release.
I believe using fields as they are intended to be used is extremely important, so understanding what is intended by âShip Byâ is pretty key.
I always understood it as: If we are going to honor our commitment, this thing needs to ship out on this day.
Need By is when said thing needs to arrive at itâs destination to honor the commitment.
Measuring on-time shipment rates is important, but it isnât the only metric. Need By can be used in conjunction with Ship By to analyze the performance of your carriers, as well as the accuracy of your delivery day/transit time assessments to various destinations.
We also monitor the performance of our manufacturing cells, looking at things like on-time completion rate for jobs, Vendor on-time ship rates for POs, etc.
The thought of changing the ship by with the intent of rescheduling things upstream makes me think it would make it harder to keep track of those metrics and understand why I might be missing my Ship Bys in the first place.
The thought of Epicor changing the definition of Ship By is also concerning.
1 Like
That doesnât make sense though because ship by is what drives MRP. If your ship by is no longer accurate, then MRP is not going to be giving you the right suggestions.
1 Like
Makes perfect sense to me. If my system is set up correctly then all of my suggestions are accurate. If I donât hit my ship by I would like to know which suggestion I didnât follow to end up there.
Correct⌠thatâs how it works. But I see @hackaphreaka 's point, and it was actually my belief on how the system worked for a long time.
We get an order with a specific ShipBy Date. The job to fulfill that order adopts that ShipBy Date as its Due Date.
The schedule falls behind and suggestions go haywire, and Epicor wants us to update the ShipBy Date to something more realistic.
But⌠that WAS and IS the agreed upon ShipBy date according to the sales contract.
Like I said, I agree with what Garret is saying, and it was a hard learning curve to realize that Epicor didnât use it in this way.
2 Likes
As several have said, the ship by or aka required by is what drives the entire system. none of the other fields are utilzied by MRP.
If you are using the ship by date as a contract date, then that is something different than the intent of how the software works.
My rules that I always tell customers;
- the ship by date field NEEDS to be accurate
- MRP uses the ship by date to determine all recommendations. If the ship by date says to ship by march first, it will do everything possible to tell you and make recommendations to fix jobs and POs to match this date. This date always wins.
- adjusting the ship by date to be when you are PLANNING TO SHIP, then the rest of the system will balance to that date, and you will stop getting false recommendations to adjust your schedule.
If you truly want to have a âcontract dateâ, then I would recommend that you use the PROMISE date for this purpose.
1 Like
Was this always the purpose of Ship By, since Promise did not even exist before 2024.1?
Hard to imagine this is true when you consider things like EDI where things like contract date are critical in that space.
Definitely some valid points here, and I think someone mentioned this in another thread. I am sure we all agree using fields for an unintened purpose is a very bad ideal.
I would say that it would be great to have a white paper or such that discusses these fields in their entirety with respect to functionality and not bury it in the MRP tech reference. They may well be one already and I am not aware.
As Tim rightly pointed out many customers just customise the form and put the Promise date field on it, and if thatâs the change then you can choose to use it or not, modifying all the existing reporting and analysis behind it then the job gets bigger, thatâs if you are wanting to perform some sort of metrics.
@hackaphreaka is totally correct the âorder is a contractâ of what you are promising to deliver and when. So really the Promise date is a reassertion of the ship by, but without all the MRP magic. And if the MRP runs and the ship by changes⌠Thatâs my understanding.
This is one of those situations where a piece of functionality is being added that needs to not effect customers that have been using the existing fields, and /or MRP for a very long time and it works, vs broadening the appeal/audience.
Two questions:
- I wonder how many people would customise to remove the field
- I also wonder how many times does the question âWhere is the Promise Date?â come up in the Sales Demo.
I am on the fence, and appreciate both arguments for and against.
If there is no epimagic processing tied to it (and Iâm assuming itâs going to go all the way to the release lines) Then thatâs ok, but if functionally changes MRP or any other nuanced functionality around order dates (generically all of them at all levels) then that would make me pretty uncomfortable.
Making changes to a key part of the system is risky at any time, particularly the part that generates your revenue stream.
When we added the promise date, we did not change any functionality in how MRP works for this very reason. We simply put something in that many people did as a customization. we have no plans to modify MRP logic and would be very hard pressed to do such a change in MRP logic in the future.
3 Likes
@timshuwy You spelled this out very well in your original post, which @aosemwengie1 included at the beginning of this thread.
I think some are missing the (original) point of this thread and assuming functionality is changing⌠it is not.
In their defense, the discussion has drifted a bit⌠but the question asked up top was:
1 Like
I donât think I would go so far as to hide it if we didnât use it. I imagine folks here would like the idea of using it to convey the realistic date. Not sure how thrilled I would be designing anything that supported that usage though.
Here at least, the Ship By has been and always will be THE DATE, and it doesnât get changed. If itâs late, it sticks out like a sore thumb until it ships, as do my late mfg jobs and late POs. Thatâs the way I like it. 
Itâs easy enough to prevent MRP from suggesting changes to things that are late, so we should be fine.
2 Likes
We do have it hidden right now - donât want to expose it until we can clearly instruct people how it should be used.