Transportation Planner considerations

Authorized users are allowed to create/update/delete dock commitments while optimization is active.

Users can assign a dock commitment to a stop even if the corresponding load is currently undergoing re-planning (that is, an existing load has been sent to Optimizer for potential modification). If a change is applied manually or via API during optimization, any changes proposed by the Optimizer will not be applied on write back.

Loads where a dock commitment has already been assigned to one or more stops are eligible to be sent to the Optimizer.

Optimizer will generate dock commitments based on the snapshot of the dock schedule and docks as they exists at the start of the optimization request. Optimizer will not propose dock commitments that conflict with the dock schedule as it existed at the time the optimization request was initiated. Also, Optimizer will not assign new dock commitments to a dock that was on hold when the optimization request started.

If the Restricted Start Times for Dock Commitments flag in the Global Settings is True, Start Times for Dock Commitments created by Optimizer will commence at arbitrary times based on the configuration of each dock. See "Global Settings - Transaction Management - Load 2 tab fields" and Dock fields.

TP Scheduling and Re-Planning

For loads being re-planned, when a dock commitment exists for a stop will also exist and the Start and End Dates/Times for the dock commitment will be identical to the From and To Dates/Times for the appointment. Therefore, the appointment constraints and tolerances will generally also apply to stops with dock commitments. Unlike appointments not linked to dock commitments, loading/unloading handling time will be computed and evaluated for any pick or drop stop with a dock commitment.

During re-planning, for loads with stop appointments in a status equal to or greater than Planned, Optimizer will not attempt stop insertion or stop re-sequencing.

For shipment consolidation and load re-planning, when an appointment in Planned status or greater exists, the appointment window will constrain scheduling.

Scheduling will succeed when the proposed Computed Arrival Date/Time for a stop is later than the Appointment From Date/Time and the Computed Departure Date/Time for the stop is earlier than the Appointment To Date/Time).

If the proposed Computed Departure Date/Time for the stop is later than the Appointment’s To Date/Time for a stop with an existing appointment that is linked to a dock commitment, the Dock Commitment Tolerance hours from the global settings will be considered. Scheduling will succeed if the Computed Departure Date/Time is no more than xxx hours later than the To Date/Time for the appointment. For example, for an appointment window of 08:00-08:30 and a 5 minute tolerance, a computed window of 08:00 – 08:33 will be acceptable. In this case, the stop will be scheduled as 08:00-08:33 and the date range for the stop appointment will remain 08:00-08:30. If the stop’s Computed Departure Date/Time would be more than xxx hours later than the To Date/Time for the appointment, scheduling will fail. For example, for an appointment window of 08:00-08:30 with a 5 minute tolerance, a computed window of 08:00 – 08:36 will fail scheduling, and the potential route will be discarded.

Dock Commitment Tolerance will not be considered when the Arrival Date/Time for the stop is earlier than the Appointment From Date/Time.

Note: The Dock Commitment Tolerance Hours only applies to existing appointments that are linked to a dock commitment.

The same scheduling approach will apply to routing/rating/scheduling requests triggered from TM.

Optimization Write Back

A housekeeping step is performed at the end of the optimization request to identify the following situations:

• Cases where a date/time range for a dock commitment created based on optimization conflicts with a dock commitment that was manually created or modified during optimization. If a conflict is identified, the "Over Commitment Violation" violation flag for both (or all) of the conflicting dock commitments will be set to True.
• Dock commitments created by Optimizer that refer to a dock that was put on hold during optimization. For new dock commitments for the dock created by the Optimizer where the dock is now on hold, the "Dock on Hold" violation flag for the dock commitment will be set to True.
• If a dock commitment (or a stop appointment for a location without docks) is created or modified during optimization either manually or based on an API request, any changes proposed by the Optimizer that impact the applicable stop, load or trip will be discarded. This includes all of the following events:
  • Dock commitment created
  • Dates/Times and/or Dock ID modified for an associated dock commitment
  • Dock commitment deleted
  • Swap operation performed for two dock commitments
  • Dock commitment has become associated with a load/stop (i.e. unassociated dock commitment has been linked to a stop)

The only change that could occur to an existing dock commitment would be if the Carrier ID for the load was modified by the Optimizer. Should this occur, the Carrier ID for the dock commitment will be updated to stay in synch with the new Carrier ID for the load.

Since Dock Equipment Types and Dock Excluded Commodities are relatively static, the “Commodity Violation” and “Equipment Type Violation” will be audited during write back.

When a dock commitment is created for a stop based on the results of optimization:

• A corresponding appointment will also be created. Unlike the case where an appointment is created to mirror a dock commitment created from TM, when an appointment is created during optimization write back, the setting for the “Appointment Scheduling Control” flag in the global settings will not be considered. In this case, the Scheduling Active flag for loads and trips from will always remain True. The flag in the global settings will be checked when subsequent user or API updates occur in TM.
• Event Notification messages for appointment and dock commitment events will be generated, contingent on configuration.
• The Dock Scheduling Status for the stop will be updated will be updated to indicate that a required appointment does exist.