We make changes to due dates pretty frequently and want to keep job and order due dates in sync. Before we go down the path of creating a customization to do this I wanted to make sure there isn’t a standard feature in epicor(e.g. in company configuration somewhere) to do this. Does anyone know?
Wouldnt an Order Due date mean delivered, or shipped to the Customer… while a Job Due Date merely means completing the Job internally so others can do their job such as inspect it, package it, schedule it for shipment, invoice it. So by keeping them in sync, wouldnt that mean that you would fulfill the job complete (ship and everything the same date)? Or do they have different meanings in your company?
@timshuwy knows prob alot more about this subject.
@hkeric.wci you are correct, but many people will ship the job as soon as it is complete.
MRP will suggest job changes to meet demands, but that can get very noisy and you have to wait for MRP to run. Even then, it doesn’t change the date for you.
If you want to change the Job’s Due Date, it will likely need a BPM. This BPM won’t be “simple” though as you will have to reschedule the job as well.
Amazing didnt know people owned fleet of trucks 
and guarantee shipments and on time delivery. Wish I could wrap UPS and USPS around my thumb like that. Dont let me get started about 3PLs.
For us its always when the Job is done come the QA Pieces, Inspection, Cleaning, Packaging, Printing out Certificates, Labels, Serial Tags, Registering stuff with the Govt such as VINs etc…
Also how does it affect Job to Stock vs Job to Job vs Job to Order.
Yeah… That “Ship Date” isn’t always when the truck leaves the facility. It is simply when we “told” Epicor it was shipped. This is lying to the system a bit, but often the Shipping Department stops processing todays shipments before UPS arrives.
OH… you want to open THAT can of worms… hahaha… “Due dates” are always complex… the customer wants it one date, you ship it a different date, you need to make it a different date to meet that date, OH, what about packing… you cannot finish the product at 11:59 PM and still ship it the same day. The complex world of scheduling and timing…
BUT, knowing how Epicor ERP is deciding things is very helpful.
- Sales order Ship By date: this is the date it is scheduled to LEAVE THE BUILDING (ie SHIP). MRP uses this date to determine when to have the product ready.
- Sales Order Need By Date: This date is informative… not really “used” by Epicor, but would represent when the customer NEEDS it (onsite?)… Depending on how I ship the product, (or customer pickup) the difference between NEED by and required date could be 0 to 30 days (going across ocean).
- Job Required by date: This initially matches the sales order IF MAKE DIRECT. If not make direct, then this may still match the sales order, but could also be a date to fulfill a shortange (min/safety).
- Job DUE Date: This date is the date that the job is currently scheduled to complete. It may not be the same date as the required date, because of other requirements.
Epicor DOES have an option to synchronize required by date with the order, but this is only semi-automatic. If someone changes the sales order, it requires a few steps AND some setup. One step I believe is that you need to reschedule the job to see it.
The BPM to automate this is not too complex… I just did one where any change to the OrderRel table would automatically update any Linked MAKE DIRECT jobs to have the new required by date. This date did NOT automatically change the DUE DATE or force a reschedule… but then they have a dashboard that shows jobs where the due date is not matching the Required date.
One more thing… there are additional settings for RECEIVE TIME in the PartClass… this can add extra days between the jobs REQUIRED date and the DUE Date giving an extra window for packing.
4 Likes
Just to mix things up a bit… (opening another can of worms here) I always like to throw in a new UD field in Order Release called “Promised Ship Date”… this date is not allowed to be changed UNLESS the customer requests, and you re-promise…
THEN I also like to allow changes to the sales order Ship By date if the schedule is known to be missed. This allows everyone to look at the CURRENT schedule and you can then make proper forecasts of what WILL be shipping (I dont like to hold onto old information when we know it is old… the Ship Date should represent what we truly believe IS the scheduled ship date.
1 Like
@timshuwy thanks so much!!! We already opened the can of works in regards to adding a UD field for promise date - I don’t see how you can accurately calculate OTD without this field:)
For others potentially reading this thread in the future - from a really high level when we need to change due dates we historically only update the OrderHed due date this typically updates OrderRel due dates. Sometimes it doesn’t and I don’t know why. This has worked well for us over the years as we know when to ship orders and we can calculate OTD. We use promise dates as the agreed date with the customer(ship date vs Promise date = OTD), due date reflects changes to original promise date for production planning purposes if materials are late or other delays.
Currently a production manager is looking at all the open jobs and figuring out when we need to have people start work on what operations so we can meet promise dates. This is OK but people make mistakes and it costs money for people to do figure this out. What do you know if you have accurate labor standards(another project we have is to get these accurate) Epicor calculates the Start Date for an Operation for you(JobOper table)! That leads to this post, we need the job due date to be in sync with the OrderHed and OrderRel due dates so we can take advantage of the calculated StartDate.
Sorry for the long explanation, but I get a ton of help from all the great people on this forum so trying to help others down the road in my current situation 
I wish I saw this post ten years ago Tim! We went the opposite direction and provided a UD on the sales order release to be the changeable field for schedule creep. We keep the order release ship by date firm.
A drawback of this of course is that the materials and jobs are all wanting to go for that original order release ship by date and folks are like, oh that’s not a real date anymore so I really don’t need x and so for it yet and the list goes on.
When we did it the original design for this changeable UD schedule creep field we hoped it would be a driver to move quicker on some things, based on comparison with original planned ship by date. But it just didn’t pan out… when production says they are pushing it out, they’re pushing it out. Unless there’s a squeaky wheel, it’s locked in for the next best shot at it.
At this point in time, it’s going to be hard to change, but we probably will one day when we get mgmt more interested in using system scheduling to a greater extent.
Nancy
Yes, I have seen companies try to do the opposite as well to monitor date changes. I find it best to “stop lying” to the system… tell the system what your current plan is (the ship date) and then let the system plan around that.
STORY TIME: I used to work at a company where I was required to forecast next months shipments. In our world, our New Sales (New Backlog) didn’t ship for at least 3-4 months after we took the PO… our manufacturing cycle was long. Typical job would take 3-4 weeks.
So… to “forecast” I needed to know the “Scheduled ship date”… ie… what we were PLANNING on doing. We could also compare this to the “Requested” or Need by date to see if we could bring anything in by working OT. this allowed us to manage our on-time deliveries better, while also deciding how much Overtime to work to make up difference.
If we didn’t constantly re-set the schedule date, we would never know what we were going to do, or what our target was.
Our #1 rule was… if you change the Schedule Ship Date, you MUST inform the customer… so we didn’t take this lightly. BUT, we also didn’t feel it was right to ignore the fact that we were missing delivery dates. We always wanted the customer informed, even if the information didn’t make them happy.
1 Like
OH… One other STORY TIME Moment… Some of our products we made had SOURCE INSPECTION… meaning, the customer had to send an inspector ON-SITE a few days before shipping… we had to schedule this inspection, and the parts had to be ready (but not packed) for the inspection. This caused even one MORE challenge in scheduling the completion.