Scheduling Engine - Fixed Drop Scheduling

From CTMS

This guide is intended to show the requirements of running a fixed drop scheduling engine, and what processes can be used with it.

Overview

The Fixed drop scheduling engine is just one part of the whole fixed drop scheduling processes:

  • Order Import with defined Run Number
  • Fixed drop scheduling
  • Depot Sweep processing

In summary, the process is as follows.

  • Order Import with defined Run Number
    • Orders are received and created with a defined Run Number
  • Fixed drop scheduling
    • Orders are planned onto the route specified in Run Number
    • They are planned onto the drop specified against that delivery location, unless no config exists for that run/location, when they will be planned as drop 998
    • If they have missed cutoff (the only validation applied to these routes), the process will attempt to carry the order forward to another valid route on that day for that location. If found, the order will be planned.
    • If not found, the order will remain in an unscheduled state, and will not be automatically planned again.
  • Manipulation
    • The order can be manually planned.
    • The order can be pushed through the fixed drop scheduling again.
    • The order can be pushed to another day.
  • Depot Sweep processing
    • At 1900, a depot sweep process will carry forward any remaining unscheduled orders to the next schedule day, when the scheduling process will begin again immediately, attempting to schedule for the next day.
    • At 2350, any incomplete desk collection orders will be moved to a trip on the following schedule day.


Configuration

Route Headers

Route headers must be created for all of the routes, specifying:

  • ID and description
  • Active days
  • Start Time
  • Cutoff Time
  • End Time
  • Automatically Scheduled

Ref: Fixed Routes


Route Drops

Locations must be assigned to Route Drops - if not, then the orders for that location will be planned onto the route, but will not be sequenced by drop number - they will be at the end of the trip (drop 998).

Ref: Locations#Route_Details


Paragon Strategic Planning

Should the Paragon Strategic Planning interface be enabled, then any newly created locations will be interfaced to the Paragon Strategic instance. This will then allow Paragon users to route fresh locations onto existing runs, create new runs, move locations around on runs and eventually set the drop numbers.

This information when confirmed will be imported back into Calidus TMS and automatically populate the route header and route drop information.

Any issues importing this information can be viewed within the Calidus Web Service Audit screen, with direction set to Paragon API. This will identify any issues processing the records.

Ref: Paragon_Interface#Strategic_Interface


CSV Upload

If required, route headers can be imported in bulk into CTMS through the configurable imports.

Ref: Imports_Details#FIXED_ROUTE


Operational

Orders

Orders must have a reference "RUN_NUMBER" specifying a valid route header.

Ref: New_Order#Add_Details_Tab

Orders may also be imported with this reference, through the Trip Order XML, through EDI or the API.

Ref: TripOrder_Interface_XML

The order will be imported as unscheduled (i.e. not INVALID) if the route header specified in the reference exists (so that it can determine the start and end times for the order).


Visibility

It is recommended that Drop Number (as well as Stop Number) is added to the Planning screen, so that the generated drop numbers can be seen.

Ref: Planning#Stops_Tab


Controlling the Scheduling Engine

The scheduling engine can be automated to run and is completely under user control. Users are able to control which orders are selected by the scheduling engine (based on both Cost centre and customer) and when the scheduling runs and how often.

A cost centre parameter controls which cost centres use the scheduling engine. Multiple parameters may be created for systems with more than one cost centre.

If an order is selected for the scheduling engine, by the cost centre, there is a further level of control available to the user. Users are able to exclude certain customers from the scheduling engine. This is controlled by a flag in the customer maintenance screen.

A screen has been created to control when the scheduling screen is run. A specific user name has been created with the ability to start and stop the scheduling engine. Users will be able to access the screen to check when the engine is running.

Ref: Scheduling_Maintenance#Scheduling_Engine_Tab


The engine has been created to run several flavours of scheduling, for carrier selection and 3PL carriers. To run the scheduling rules from the fixed routes maintenance screen , users must select the Fixed Drop schedule.

Selecting start will create a database job to run the scheduling functionality. The interval will indicate how often the engine looks for Unscheduled orders and tries to apply the orders to trips. If no minutes are entered, a default value of 15 minutes is entered, to run the engine every 15 minutes.

A status is also available to indicate if the engine is Idle or running. The Audit tab will allow users to see when the engine has run and will report any errors encountered.


Fixed Drop Processing

The process will assess the order after it is created.

  • The order will attempt to plan for the scheduled day.
  • The order will attempt to plan onto the run number provided.
  • The route will be validated:
    • If the order has missed the cutoff time for the route, then the order will not be planned and will be available for carry forward on the day.
  • If no route stop is set up against that location, it will be added to the trip created from that run number on that day with a drop number of 998.
  • If the route number does not exist, the order will not be planned and will be available for carry forward on the day.
  • If the order remains unplanned, then the process will check for any other route drops configured against that location, looking for routes that may be available later in the day.
  • Each is checked (in start time sequence) and validated. If one is found, the order will be planned onto a trip generated for that route, with the drop number set to the drop number of the route drop configuration against that location.
  • Failing that, the order will remain unscheduled and will be marked as requiring manual planning.

If an order is selected by the engine, but fails to find a suitable route, a flag will be set next against the order to prevent the engine from attempting and failing to schedule the order every run.

In addition if a user chooses to manually remove an order from a trip, which was applied by the engine, a Manual schedule flag is ticked against the order to prevent the engine from applying the order to the same trip again.

Users are able to manually change the values of the flag to allow an order to available to the engine, or prevent the engine from selecting an order.


Depot Sweep Processes

Several processes can be set up at a timed interval to carry forward orders from one schedule to the next. It is expected that several would be set up for:

  • Carrying over incomplete desk collections at midnight.
  • Carrying over unscheduled jobs at various times of the day (generally after cutoff for those jobs).

Ref: Scheduling_Engine_Overview#Depot_Sweep_Processes


Manual Manipulation

Several manipulations of orders on trips are possible, with particular reference to:

  • Manual auto-scheduling reset
  • Manual carry forward
  • Manual change schedule

Ref:

Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/MTS/index.php?title=Scheduling_Engine_-_Fixed_Drop_Scheduling&oldid=7904’