View source for Scheduling Engine Overview

The scheduling engine is an automated process that will select unscheduled orders and apply them to the available trips or create new trips as required based on the routes that exist.

The fixed routes (for own fleet) and the carriers routes (for external carriers but also for own fleet parcel services) will be assessed based on rules to schedule the orders.


== System Parameters ==

* 'AUTO_SCHEDULING'

A cost centre parameter that controls which orders are considered by the scheduling engine, the parameter must be set to 'Y' for the cost centre of the order for the order to be scheduling automatically.

* 'ENGINE_RUNNING'

A cost centre parameter which will be set automatically to 'Y' by the schedule engine process when the process is being run for the database.

This system parameter will be set back to 'N' by the process once all of the available orders have been processed.

* 'MAINTAIN_SCHEDULE_DATES'

A cost centre parameter which will control if the order time windows will be derived for the 'XML' and 'CSV' orders.

The system parameter must be set to 'Y' for the cost centre of the order to be active.

* 'TRIP_PREVENT_PARCEL_CARRIER_ASSIGNMENT'

A cost centre parameter which will control if orders can be planned manually to a trip for a 'Parcel' carrier.

The system parameter must be set to 'Y' for the cost centre of the order to be active.

* 'TRIP_VALIDATE_PARCEL_ORDER_ASSIGNMENT'

A cost centre parameter which will control if orders are validated when they are planned manually to a trip for a 'Parcel' carrier.

The system parameter must be set to 'Y' for the cost centre of the order to be active.

* 'TRM_3PL_REROUTE'

A system parameter that can be set to 'Y' to enable the functionality in the Fixed-Drop Scheduling engine to plan the orders to the next available route.

* 'TMP_ENG_TRIP_PREFIX'

A system parameter that controls the prefix that the trips created from  fixed drop scheduling drops will be prefixed with e.g. TMP, MAN, RTE etc.

If the trips are to be replanned by Paragon, set this to TMP. If the trips are not to be replanned, then set this to RTE (or some other easily recognizable prefix).


== Scheduling Engine Control ==

The scheduling engine may be defined in the 'Scheduling Maintenance' screen.

To use the screen, the user must be logged in as 'EDI_OWNER' so that the process is started with the correct level of access control.

The screen allows users to start and stop the scheduling engine and select which functionality runs and the sequence in which the different aspects of the scheduling engine are run.

Note that if a process is not ticked as being 'Included' IT WILL NOT BE RUN.

The 'Audit' tab page will record each successful completion of the scheduling engine and will also display any errors which occurred during the processing of the orders.

The audit does not record why an order failed to schedule (because it would have to record why it failed to schedule with every route available).

There are different processes that the scheduling engine can use - 'Parcel Carriers', '3PL Carriers', 'Wholesale Schedule', 'Mandated Carriers', 'Top Up Process', 'Network Schedule' and 'NHSBT Schedule':

[[File:SCHDENG-OVERVIEW-1.png|800px]]

The 'Run Order' can be specified to the sequence in which each type of scheduling engine process will be run so that certain types of orders and carriers can be assessed preferentially.

In this example, the 'Mandated Carrier' process will be run first.


== Customer Settings ==

* 'Exclude From Scheduling Engine'

Customers must be actively excluded from the scheduling engine if they do not want to have their orders scheduled automatically:

[[File:SCHDENG-OVERVIEW-2.png|800px]]

* 'Carrier Preferences'

The carrier must exist as a preferred carrier for the customer of the order if the customer has a list of carriers that it will accept for the delivery of its orders:

[[File:SCHDENG-OVERVIEW-3.png|800px]]

In this example, the 'POL' carrier will be assessed first and if that carrier cannot take the order, the 'TBD' carrier will be assessed next.

Note that if a customer has no preference, the orders for that customer may be delivered by any carrier without preference.

* 'Scheduling Threshold'

A threshold value may be set to exclude the order from the scheduling engine until a set period of time prior to its early delivery date and time:

[[File:SCHDENG-OVERVIEW-4.png|800px]]

The number of minutes may be specified and a value of '0' will indicate that the order cannot be scheduled automatically in the particular aspect of the scheduling engine until the early delivery date and time has been reached by the system date and time (i.e. in the local time zone).

Note that if a threshold value is not specified that the order will effectively be valid for the aspect of the scheduling engine to process once it has been created, validated and set to 'UNSCHEDULED' status.


== DU Category ==

The DU category can be specified to denote the type of despatch unit for planning purposes:

[[File:SCHDENG-OVERVIEW-5.png|800px]]

A DU category of 'PALLET' indicates that it is a pallet that would normally be transported by own fleet.

A DU category of 'PARCEL' indicates that it is a parcel that would normally be transported by a parcel carrier service by own fleet or by an external 'PARCEL' carrier.

Note that a DU type will have a DU category of 'PALLET' by default unless stated otherwise.

The DU category of an order will be set to 'PARCEL' based on the presence of a DU type having a DU category of 'PARCEL'.

The DU category will then be used to decide which set of routes (fixed for 'PALLET' or carrier for 'PARCEL') to check for the derivation of the order time windows when the orders are created via the 'XML' and 'CSV' files.

Note that some 'PARCEL' carriers will be able to take 'PALLET' items should they be setup to do so in the 'Carrier Rules' screen for the DU types.


== Carrier Type ==

The 'Carrier Type' will determine the scheduling engine process in which that carrier will be assessed:

[[File:SCHDENG-OVERVIEW-6.png|800px]]

The 'Carrier Type' may be '3PL' or 'PARCEL' to apply the specific scheduling engine process.


== Carrier Formats ==

Different formats can be setup for each carrier:

[[File:SCHDENG-OVERVIEW-7.png|800px]]

The current version of the gazetteer data can be stored for the label format.

The label format can be assigned to a routing format to obtain the gazetteer data:

[[File:SCHDENG-OVERVIEW-8.png|800px]]

The carrier can be configured to have a label format and a manifest format:

[[File:SCHDENG-OVERVIEW-9.png|800px]]

The physical manifest can also be requested to be printed automatically when the trip is despatched.

The tracking references can be applied by customer by depot.

The tracking references can be updated with a range of values for the carriers:

[[File:SCHDENG-OVERVIEW-10.png|800px]]


== Carrier Gazetteer ==

The gazetteer data can be imported for each carrier for the latest version to be applied:

[[File:SCHDENG-OVERVIEW-11.png|800px]]

The carrier routing data will be used for the production of the carrier labels and this data should be used to specify the carrier rules for ensuring that the orders are scheduled correctly.

Note that this data is not used in the scheduling engine or the derivation of the order time windows.


== Carrier Rules ==

The carrier rules will apply to the assessment of the parcel carriers:

* Shipment Size

[[File:SCHDENG-OVERVIEW-12.png|800px]]

The carrier must be able to transport the size of the shipment (i.e. based on the total for the order) based on the weight and the volume.

* DU Type

[[File:SCHDENG-OVERVIEW-13.png|800px]]

The carrier must be able to transport the DU types that exist for the order lines (as packed and despatched).

* Product Type

[[File:SCHDENG-OVERVIEW-14.png|800px]]

The carrier must be able to transport the product types that exist for the order lines (as packed and despatched).

* Service Level

[[File:SCHDENG-OVERVIEW-15.png|800px]]

[[File:SCHDENG-OVERVIEW-16.png|800px]]

The carrier route will indicate if the carrier can deliver the order from the source depot.

The source depot and ant cross-docking depots can be listed with a cut-off time to ensure that the order is available prior to the expected loading time of the vehicle.

The days of the week on which the route operates can be specified.

The type of trailer can be specified and further validation will be performed to ensure that the products for the order can be loaded onto the trailer for the trip for the route.

The carrier routes should be based on the gazetteer information that is provided by the external carrier to ensure that the carrier will be able to deliver the order on the specified date and by the specified time.

The service level of the order and the destination will be assessed to ensure that the delivery location is valid for the route.

The service level can be mapped to the appropriate service level for the carrier to indicate how it will be transported within the carrier's own network.

The 'Destination Type' and 'Destination' will indicate how the delivery location of the order is assessed:

'ZONE' indicates that there may be multiple locations that are valid for the route.

'COUNTRY' indicates that all orders for delivery in a country are valid for the route.

'LOCATION' indicates that orders just for that location are valid for the route.

Note that different destination types can apply for the same service level.


== Location Zones ==

The location zones can be specified in the 'Business Data Maintenance' screen:

[[File:SCHDENG-OVERVIEW-17.png|800px]]

In this example, the 'P09_1' location zone incorporates various postcodes (using the prefix as a postal string) for the delivery locations.

The 'Inc/Exc' flag indicates if the type of zone is being included or excluded from the location zone to enable greater flexibility to specify the delivery locations that are valid for the particular location zone.


== Fixed Routes ==

The fixed routes will apply to the assessment of the own fleet carriers:

[[File:SCHDENG-OVERVIEW-18.png|800px]]

[[File:SCHDENG-OVERVIEW-19.png|800px]]

In this example, the route is being used to collect from, and deliver to, specific locations.

The 'Stop Type' can be specified to include 'Zone' as well as 'Location' to enable orders to be valid for the route without having to specify each location as a stop.


== Schedule Rules ==

The schedule rules are used to calculate the time windows for the ''''PARCEL' orders''':

[[File:SCHDENG-OVERVIEW-20.png|800px]]

For example, 'HUK' orders will be provided with an early delivery date and the time windows will be calculated for that date and time.

The 'Rule' is the service level of the order.

The 'Offset' is a number of days for the delivery to be made (i.e. the order must be available 2 days before the delivery date for the 'STD' service level for the 'ACV' customer).

The 'Cut Off' is a time after which a day will need to be added for the expected delivery for it to be made.

Note that the weekends will be offset automatically.


== Location Fixed Route Details ==

Note: Applies to fixed drop scheduling only.

Each location that can be planned as a destination may have multiple routes (run numbers) assigned to the location.

[[File:SCHDENG-OVERVIEW-21.png|800px]]

The routes can be specified as being applicable solely to bank holidays.


== Order Time Window Derivation ==

The time windows can be derived for the orders that are created via the 'XML' and 'CSV' files by assessing the stock being ordered and the service level.

The assessment of the service level and the delivery type will be performed for the orders when they are created via 'CSV' or 'XML' files and the ''''MAINTAIN_SCHEDULE_DATES'''' system parameter is 'Y' for the cost centre of the order.

The '''DU category''' of the order is used to decide whether to check the fixed routes for 'PALLET' or the schedule rules for 'PARCEL'.

'PARCEL' will only be specified if the order only contains DU types with a category of 'PARCEL'.

'PALLET' types will assess the fixed routes for a direct or a radial route for the early delivery date, the locations of the order and the mandated carrier if provided.

If the '''early delivery date''' is known the route will be checked that it is active on that day of the week.

Future early delivery dates will not offset the date:

''Service Level      'Standard'''

''Delivery Type    'On Sched'''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date at Late Target Time''

''Early Del               Delivery Date at Early Target Time''

''Late Del                Delivery Date at Late Target Time''

Or

''Service Level      'Standard'''

''Delivery Type    'Off Sched'.''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date at 17:00''

''Early Del               Delivery Date at 08:00''

''Late Del                Delivery Date at 17:00''

Same day early delivery date may offset the date:

''Service Level      'Standard'''

''Delivery Type    'On Sched'''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date at Late Target Time''

''Early Del               Delivery Date at Early Target Time''

''Late Del                Delivery Date at Late Target Time''

Or

''Service Level      'Standard'''

''Delivery Type    'Off Sched'.''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date + 3 days at 17:00''

''Early Del               Delivery Date  +3 days at 08:00''

''Late Del                Delivery Date + 3 days at 17:00''

Note that the delivery date may also be offset to avoid the weekends so it may be +4 or +5 days.

Past early delivery date will offset the date:

''Service Level      'Standard'''

''Delivery Type    'On Sched'''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date + 3 days at Late Target Time''

''Early Del               Delivery Date + 3 days at Early Target Time''

''Late Del                Delivery Date + 3 days at Late Target Time''

Or

''Service Level      'Standard'''

''Delivery Type    'Off Sched'.''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date + 3 days + 3 days at 17:00''

''Early Del               Delivery Date  +3 days + 3 days at 08:00''

''Late Del                Delivery Date + 3 days + 3 days at 17:00''

Note that the delivery date may also be offset to avoid the weekends so it may be +4 or +5 days.

No early delivery date will offset the date:

''Service Level      'Standard'''

''Delivery Type    'On Sched'''

''Early Avail            SYSDATE''

''Late Avail             Next Delivery Date at Late Target Time''

''Early Del               Next Delivery Date at Early Target Time''

''Late Del                Next Delivery Date at Late Target Time''

Or

''Service Level      'Standard'''

''Delivery Type    'Off Sched'.''

''Early Avail            SYSDATE''

''Late Avail             Delivery Date + 3 days at 17:00''

''Early Del               Delivery Date  +3 days at 08:00''

''Late Del                Delivery Date + 3 days at 17:00''

Note that the delivery date may also be offset to avoid the weekends so it may be +4 or +5 days.

'PARCEL' types will use the delivery date, cost centre, customer and service level provided (or a default service level from 'OMS_DEFAULT_SERVICE_LEVEL') to assess the schedule rules.

An early delivery date will calculate the collection date using the delivery offset days for the schedule rule:

''Early Avail            Collection Date at 00:00''

''Late Avail             Delivery Date at Late Time''

''Early Del               Delivery Date at Early Time''

''Late Del                Delivery Date at Late Time''

No early delivery date will offset the date when before the cut-off time for the SYSDATE:

''Early Avail            SYSDATE at 00:00''

''Late Avail             SYSDATE + Delivery Offset Days at Late Time''

''Early Del               SYSDATE + Delivery Offset Days at Early Time''

''Late Del                SYSDATE + Delivery Offset Days at Late Time''

No early delivery date will offset the date when after the cut-off time for the SYSDATE:

''Early Avail            SYSDATE at 00:00''

''Late Avail             SYSDATE + 1 day + Delivery Offset Days at Late Time''

''Early Del               SYSDATE + 1 day + Delivery Offset Days at Early Time''

''Late Del                SYSDATE + 1 day + Delivery Offset Days at Late Time''

If SYSDATE is Friday the weekend will be offset at the start for the above calculations when no early delivery date is provided.

Note that the derived delivery date may also be offset to avoid the weekends.

'XML' orders will assess the above rules if not all of the order time windows are provided.

'CSV' orders will assess the above rules if not all of the order time windows are provided.

The delivery type of 'On Sched' and 'Off Sched' can be set for the 'CSV' and 'XML' orders but this code is not run elsewhere, therefore the order should not have changed automatically the delivery type when the order was unscheduled.


== Scheduling using Parcel Carriers ==

The 'Parcel Carriers' will assess the carriers that have been setup with a 'Carrier Type' of 'PARCEL'.

The orders will be selected provided that the carrier accepts the type of goods that are being transported.

This process will either create a new 'PCL' trip for the order or it will add the order to an existing 'PCL' trip for the same route for the same delivery date minus the nunber of offset days for the service level.

The '''capacity''' of the current trip(s) for the route will be assessed against the '''total RPE, weight and''' volume of the order being processed:

* If there are no trips for the day for the route and the capacity of the trailer will not be exceeded by the order then a new trip will be created.
* If there is spare capacity then the current trip will be used.
* If there is no spare capacity and the total number of trips for the route for the day has reached the maximum number of trips for the route then the order will remain unscheduled.

The schedule of the trips will be based on the early delivery date and time of the order being processed minus the nunber of offset days for the service level of the order.

Note that the ''''PCL' trips''' will be handed-off to an external carrier so they will be assigned to a '''schedule for a previous day''' based on the number of 'Offset Days' for the carrier route for the service level of the order.

The intention is to advise the external carrier when they need to collect the orders from the depot for delivery within their own network.

The orders for the 'Parcel' carriers can be cross-docked prior to their delivery trips.

The 'Auto Processed PCL' flag will be set if the order has been assessed for this aspect of the scheduling engine.


== Scheduling using 3PL Carriers ==

The '3PL Carriers' will assess the carriers that have been setup with a 'Carrier Type' of '3PL'.

The orders will be selected provided that the carrier accepts the type of goods that are being transported.

The same logic will apply to the '3PL' carriers as to the 'Parcel' carriers and the orders for the '3PL' carriers can be cross-docked prior to their delivery trips.

The 'Auto Processed 3PL' flag will be set if the order has been assessed for this aspect of the scheduling engine.


== Scheduling using Wholesale Schedule ==

The 'Wholesale Schedule' will assess the fixed routes to potentially cross-dock the orders multiple times prior to delivery.

There are 3 different types of trips that can be assessed for '''unscheduled orders''':

* Collection

The orders will be assessed based on the source and delivery locations of the order for any 'Cross-dock' stops that exist for a route.

* Trunk

The orders will be assessed based on the stops for collection from the current location of the order.

* Direct

The orders will be assessed based on the stops for collection from the source location and delivery to the location/zone of the delivery location of the order.

These orders will not be cross-docked.

There are 2 different types of trips that can be assessed for '''partially scheduled orders''':

* Trunk

The orders will be assessed based on the stops for collection from the current location of the order.

* Radial

The orders will be assessed based on the stops for collection from the current location and delivery to the location of the delivery location of the order.

The capacity of the current trip(s) for the route will be assessed against the total RPE, weight and volume of the order being processed to decide if a trip can be used:

* If there are no trips for the day for the route and the capacity of the trailer will not be exceeded by the order then a '''new trip''' will be created.
* If there '''is spare capacity then the''' '''current trip''' will be used.
* If there '''is no spare capacity''' and the total number of trips for the route for the day has reached the '''maximum number''' of trips for the route then the order will '''remain unscheduled'''.

Note that is a ''''PARCEL' order''' is being processed, it '''can be added to a 'RTE' trip''' but it '''cannot create a 'RTE' trip.'''

The schedule of the ''''RTE' trips''' will be based on the '''schedule for the''' '''early delivery date and time''' of the order being processed.

The orders for the 'Wholesale' carriers can be cross-docked prior to their delivery trips.

The 'Auto Processed WS' flag will be set if the order has been assessed for this aspect of the scheduling engine.


== Scheduling using Mandated Carrier ==

The orders that have a mandated carrier in the 'Carrier' field will be assessed for the appropriate '3PL, 'Parcel' or 'Wholesale' aspects of the scheduling engine depending on the 'Carrier Type' of the mandated carrier:

[[File:SCHDENG-OVERVIEW-22.png|800px]]

In this example, 'DHLTD' must be used to deliver the order.


== Scheduling using Top Up Process ==

The 'Top Up Process' has parameters that can be used to decide which orders can be used to 'top-up' which trips:

[[File:SCHDENG-OVERVIEW-23.png|800px]]

In this example, the 'HUK' orders can be topped-up onto trips for 'HUK', 'HDS' and 'BAX' networks in that sequence.

The delivery location of the order will be used to assess onto which trip the order can be added and trunk trips can be created to ensure that the order is transported between depots in time for the departure of the delivery trip.

There must be an existing stop on the trip for the order to be added to the same stop on that trip.

The 'Master' locations will be suitable to ensure that the same location code is used in the different networks for the different cost centres for the orders.


== Scheduling using Network Schedule ==

The 'Network Schedule' will be used to schedule orders between for collection into depots and delivery out of depots, or direct deliveries between supplier and customer locations, using the fixed routes and carrier routes.

This process may be used for cross-docking across country or between countries to include flight trips and sea crossings.


== Scheduling using NHSBT Schedule ==

The 'NHSBT Schedule' is a specific process to assess the fixed routes and add orders to the trips that have been created for the fixed routes.

This process will be used to schedule orders up to a week in advance.


== Scheduling using Fixed Drop Schedule ==

{{Incomplete}}

The Fixed Drop scheduling engine is a specific process that schedules according to fixed drops on fixed routes.

The fixed drops are stored against each location.

The orders received MUST include an order reference "RUN_NUMBER" set to a valid route code, and that fixed route MUST have a roue end time.

The process can schedule:

* Desk collection jobs onto DSK trips
* Collection/Delivery radial jobs onto fixed route trips labelled as RTE trips (the prefix is configurable through system parameters).
* Trunk movements between depots
* 3rd-party trips routed onto trips labelled as 3PL trips.

Each RTE trip created will be marked with the fixed drop number (visible in the planning screen). Jobs will be placed on the trips in drop number sequence. CL stops will be marked as drop number 999, whilst any jobs automatically planned onto these trips by the route number will be marked as drop 998.


== Scheduling Engine Processing ==

The different aspects of the scheduling engine will be run in sequence as described above.

Only the orders that have not been marked for manual scheduling, or that have previously been processed automatically, will be processed if the cost centre and the customer allow automatic scheduling.


== Pack Confirmation/Labelling ==

There are 2 methods of scheduling the order ready for when it is being picked and packed and labelled:

* C-TMS Pack Confirmation

A 'Pack' button can be pressed in the 'Order Summary' and 'Order Details' screens to schedule the order and then print a label to a default printer (for the user and also for the carrier for the user).

These 'Pack' buttons are designed to be used for orders that have been entered manually in C-TMS rather than in the source warehousing system.

Note that the orders can be scheduled automatically when the scheduling engine is running and the orders can be scheduled without delay because the scheduling threshold will not apply to this packing process.

* WMS Pack Confirmation

A pack 'XML' file can be generated from the source WMS system (e.g. 'SAP') to pack the order and print a label optionally.

A pack 'CSV' file can be generated from the source WMS system (e.g. a 'CIPD' file from 'Unison') to pack the order and print a label optionally.

The EDI parameter 'PRINT_LABEL' must be set to 'Y' for a label to be printed to either the advised printer or a default printer for the user.

Note that the order for such pack confirmation must already be scheduled for the label to be printed in the required format for the carrier of the delivery trip.

* Print Label

All of the labels, or a selection of the labels, may be printed or reprinted in the 'Print Label' screen in C-TMS.

However, a fresh set of the labels will be printed via the generation of a new pack 'XML' file from the source WMS system.


== Tracking References ==

The tracking references will be generated for the labels as they are printed.

These tracking references will be printed on the labels and they will be used by the external carriers for tracking the items for the orders as they are being delivered.

Each carrier can have its own format and sequence numbers so that the labels and the tracking references are unique for that carrier.

The tracking references will be stored against the carton numbers if the order is packed via a 'CSV' file called 'CIPD' from 'Unison'.

The tracking references may be displayed in the 'Print Label' screen in the 'Orders' screen:

[[File:SCHDENG-OVERVIEW-24.png|800px]]


== Unscheduling Orders ==

If an order is unscheduled from its delivery trip, the existing tracking references will be removed because the order will have to be potentially repacked and relabelled when it is rescheduled in case a different carrier is used to deliver the order.

The 'Manual Schedule' flag will be set to indicate that the order will not be reprocessed automatically by the scheduling engine to ensure that the order is not simply rescheduled onto the same trip.


== Manual Trip Planning ==

The orders can be scheduled manually if they have failed to schedule automatically or they have been unscheduled for replanning.

The same rules can be applied for the manual planning to ensure that the order can be taken by the carrier, the 'TRIP_VALIDATE_PARCEL_ORDER_ASSIGNMENT' system parameter will control this validation when it is set to 'Y'.

The 'TRIP_PREVENT_PARCEL_CARRIER_ASSIGNMENT' system parameter can be used to prevent orders being assigned to trips for 'Parcel' carriers when it is set to 'Y'.


== CITD Files ==

Files can be generated for the 'Unison' source WMS system to return the tracking references for storage against the packs that have been created there.

The file can be triggered when the trip status is updated to 'ACCEPTED' and the order has been packed in 'Unison' and a carton number has been provided.


== Despatch Confirmation ==

A check can be performed when the trip is despatched in the trip planning screens to ensure that all of the orders on the trip have been fully packed.

The system parameter 'X' will control this validation for the trips for the external carriers.

Note that the unpacked orders will have to be unscheduled or packed before the trip can be despatched.


== Physical Manifests ==

A physical manifest may be printed when the trip is updated to 'EN-ROUTE' status.

The physical manifest will be printed to the default printer for the user if the carrier of the delivery trip is setup to print a report.


== Electronic Manifests ==

An electronic manifest may be generated as a 'XML' file when the trip is updated to a specified status and/or when it is updated to 'EN-ROUTE' status.

The trip status may be specified as an EDI parameter called 'STATUS' (e.g. 'PLANNED' and 'TENDERED').

Some carriers (e.g. 'Polarspeed') cannot accept multiple files for the same order so they will only send a single electronic manifest when the trip is 'EN-ROUTE'.

Other carriers will accept multiple updates as the trip is planned with more orders and when those orders are packed differently.

Only the changes since the last file was generated will be included in the next file for the specified trip status.


== Paragon Considerations ==

There are limitations for using Paragon to plan all of the orders rather than to plan the orders for the own fleet and then allow the scheduling engine to plan the remaining orders and the orders that have been mandated for an external carrier:

* Paragon will need to assess the individual gazetteer data for the external carriers.
* Paragon will need to assess the shipment size, DU type and product type for the external carriers.
* Paragon will need to derive the carrier service level for the carrier based on the service level of the order.
* Paragon will need to ensure that a mandated carrier is used.
* Any orders that have been printed and that have generated a tracking reference will lose those references if they are unscheduled (which is what Paragon does to respin a trip).
* Some of the labels display a 'Trip ID' so they will need to be reprinted if the order is rescheduled (e.g. 'Standard', 'Penguin').
* Some of the labels display data from the carrier route code name and this route code will not be provided by Paragon (e.g. '(EMA)' and '(OXF)' are translated as the origin code for the DHL Express labels).
* The trip stop times will not be calculated for the external carriers based on the time windows of the orders on the stops but they will be calculated based on the distance and time from the previous stop.
* The trip stop times are used to advise the external carrier when the orders will be delivered in their network via the 'Electronic Manifest'.
* Files may be generated for the 'Electronic Manifest' when the orders are unscheduled temporarily.


== Depot Sweep Processes ==

{{Incomplete}}

The Depot Sweep EDI processes can move orders between schedules automatically if not completed.

These processes are most commonly associated with fixed drop scheduling and are useful for Paragon planning, as the schedule is linked to the Paragon working area for each day.


The fundamental principles are:
*	Part of scheduling engine
**	Any order than cannot be planned to look for a further run on that day and automatically plan instead. The process will check the routes and change the order reference to plan onto a different run, reset the manual schedule flag and let the next schedule engine run pick it up. If no runs found on that day, then remains unscheduled (and will be carried forward on planning day end).
*	Planning Day end
**	Any orders of any type not fully planned at the end of the day carried forward to next day (including non-working days). The scheduling engine process above will then pick up the order and plan according to the rules above.
**	Expected to be scheduled process once per day, on or around 1830-1900.
*	Actual day end
**	Any DSK (Desk Collections) orders that have not been completed (debriefed) at end of day to carry forward to next day and planned automatically onto the next DSK collection trip.
**	Reset any TOTD orders and next day orders that remain unscheduled.
**	Expected to be scheduled process once per day, around (before) 2359.

This is the definition of the automated scheduling and carry-forward rules. It will also be possible to carry an order forward manually (for example, when determining on Monday that you will not deliver until Thursday, you can carry the order forward to Thursday’s schedule manually from the planning screen.

The depot sweep processes can be configured with parameters to control which depot is affected by the process, what route types are affected and what action to take, as shown below:

{| class="wikitable" border="1" width="100%"
|- bgcolor="silver"
!width="20%"|Parameter	!!Value	!!Purpose
|-
|DEPOT_SWEEP	||Y	||Identifies that the EDI process is to perform the depot sweep.
|-
|DEPOT	||blank or RDC location	||Identifies the depot that is affected by this depot sweep, or all depots if blank.
|-
|ROUTE_TYPE	||COLLECT_DESK	||Identifies that the EDI process will assess the orders for the collection desks based on the run number of their route.
|-
|ROUTE_TYPE	||RADIAL	||Identifies that the EDI process will assess the orders for collection from the customers or for delivery to the customers based on the run number of their route.
|-
|ACTION	||CARRY_FORWARD	||Identifies that the EDI process will assess the orders and carry forward any unscheduled orders to the next day.
|-
|ACTION	||RESCHEDULE	||Identifies that the EDI process will assess the orders and unschedule any incomplete orders from their incomplete trips and carry forward any unscheduled orders to the next day.
|}

{{Note}} The Route Type can include a list of types of routes that are separated by a comma.


== Potential Developments ==

There are potential developments to enable the scheduling engine to be more specific for the operations:

* Include a matrix for the deliveries for the own fleet for the carrier routes and fixed routes to indicate when the location will accept the order.
* This matrix would be used to set the order time windows to use the next delivery date for the location should an invalid delivery date be provided.
* The gazetteer data can be assessed instead of the carrier routes if appropriate routes and zones cannot be maintained effectively.