Order Entry on Epicor has multiple date fields that drive the system.  I will list the label they are known by on the page, and the backend database field name in parentheses.

1. The header has 3 fields that are relevant. 
   1. Order Date (OrderHed.OrderDate) – This will default to the date the order is being entered, but it is not locked down, so it can then be changed to any other date, either in the past or in the future.
   2. Need By (OrderHed.NeedByDate) – This will drive all the order line ‘Need By’ dates, as well as the order releases.  This is when the customer expects to have the parts delivered and in hand.
   3. Ship By (OrderHed.RequestDate) – this is the date we should ship an order for the customer to receive it by the ‘Need By’ date.  This will drive all the order lines, then the order releases.  
2. The line has the ‘Need By’ and ‘Ship By’ dates on them. 
   1. Need By (OrderDtl.NeedByDate)
   2. Ship By (OrderDtl.RequestDate)
3. The Order Release also has the same fields on them.  These fields are what the system uses, as they are more granular, and may also be different from the dates on the Header and Line.  They will default to the upper level values, but quite often are changed, as if we are doing a SO with multiple releases, the order entry people will spread out the dates on the releases. 
   1. Cust ATS/Need By (OrderRel.NeedByDate) – this should be when the customer receives the unit / item.  
   2. Ship By (OrderRel.ReqDate) – this should be when we plan on shipping the line
   3. Original Promise Date (OrderRel_UD.OrigPromiseDate_c) – this is a custom field we added to track the original promise date.  The system automatically sets this date to match the OrderRel.NeedByDate when the release is created from the line.  Once it is set, it cannot be changed except by members of a Security Group (SO Change Promise Date) in Epicor, to prevent abuse.  The setting of this field was only enabled for  the TMC company, but I just enabled it for all companies.  The change prevention is still only enabled for the TMC company currently.  
4. There is one date check when setting the Release dates.  If the OrderRel.ReqDate is less than the OrderRel.NeedByDate, the system will throw an exception/error message.
5. The release -> Job tab on the Sales Order will list the Job that is linked to the release.  If the job is linked, then two of the dates are also linked.
6. The job has multiple dates on it.
   1. Req By (JobHead.ReqDueDate) – this date is linked to the Ship By date on the Sales Order (JobHead.ReqDueDate = OrderRel.ReqDate).  This is kept in sync via 2 methods.
      1. We have a BPM in place for when we change the Req By date on the Job, it will update the Ship By on the related Order Release.
      2. Notice the ‘Synchronize REeq By Date With Demand Links’ checkbox.  If this is checked on a job, when they change the OrderRel Ship By date, when we run a global rescheduling process, it will then set the Job Req By date to match.  By default it is set to match what the company configuration is set for that field, either true or false.  For TMC it is set to true.
   2. Start (JobHead.StartDate) – this is set when the job is scheduled, based on all the operation times and sequences and queue times I the system and resource groups.   It cannot be manually set.
   3. Final Op – this is not an actual database field, but is a calculated field based on the date of the final operation.  
   4. Last Printed (JobHead.TravelerLastPrinted) – this will be the most recent time the job traveler was printed for this job.  
   5. Locked (JobHead.SchedLocked) - When selected, this check box indicates that this job’s schedule will not be changed by the Global Scheduling or Load Leveling features. Only actual schedule dates are locked.
   6. Synchronize Req By Date With Demand Links (JobHead.SyncReqBy) - If this check box is selected, the Required By date of the job is synchronized to match the date when it is needed. This date can originate from a sales order or from a successor job associated via a demand link.