EBB Paper

EBB Paper CTL Solution Design

CALIDUS Total Logistics

29th April 2020 - 3.0
Reference: REQ 366558

Introduction

This document is the EBB Paper CTL Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from EBB Paper, on 19/12/2019 at the EBB Paper office in Farnborough.

This document has been written in a manner such that it can be approved by non-technical representatives of EBB Paper whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

Scope and Limitations

This document is based on the documentation provided by EBB Paper, as well as information gleaned from site visits and workshops with EBB Paper.

The changes will be made in the latest version of the CALIDUS Total Logistics system.
Changes relating to information passed through to CALIDUS Total Logistics from external systems (i.e. ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.

Client Requirements

Listed below are the proposed processes that will be followed by the operatives using CALIDUS Total Logistics. Also shown are the SCRs required for this to be achieved.

Operational Information

Elliott Baxter is the leading family owned Independent Paper Supplier in the UK. Formed in 1922, the company is now into its fourth generation of Elliott ownership and management.

Sales for last year were £150 million delivering a total of 168,000 tonnes. For comparison purposes, in 1980 sales were £4 million with 4800 tonnes of paper delivered.

EBB Paper express delivery service is supported by a fleet of 95 delivery vehicles, which travel an average of 30,000 miles a year. The Company makes over 1,200 deliveries per day, many of which are delivered same-day.

EBB Paper stocks over 30,000 tonnes (50,000+ pallets) of paper. At current prices our stock value is approximately £24 million.

Main Office Address:

Farnborough Sales Office

Elliott Baxter and Co. Ltd.

Nexus Park

Lysons Avenue

Farnborough

Hampshire GU12 5QE

Tel: 01252 379900

Fax: 01252 379911

There are 9 distribution sites/sales offices:

Birmingham.
Bristol.
Farnborough.
Glasgow.
Hemel Hempstead.
Manchester.
Newcastle.
Sheffield.
Thurrock.

EBB Paper contacts:

Paul Griffiths ([email protected]) - IT.
Rebecca Elliott ([email protected]) - Manager.
Shantal Liebenberg ([email protected]) - Logistics
Mark Ford - Operations.
Terry Dixon ([email protected])

OBS Logistics contacts:

Matt Tipping - Project Manager - [email protected]
Matt Turner - Sales/Account Manager - [email protected]
Warren Wright - Sales/CALIDUS VEhub - [email protected]
Tony Walker - Solution Design - [email protected]
Craig Hopcroft - Implementation - [email protected]

Current Operational Processing

EBB paper currently use the following core systems:

Great Plains ERP (GP) - order creation.
MSA (TMS) - planning.
CALIDUS ePOD - execution.
CALIDUS VEhub - vehicle checks.
CALIDUS Portal TTM - tracking.
TomTom - navigation.

Sales Contact and sales territories are captured as part of the order entry process in GP.

Sales enter the orders (a note).

Sales could (and may) order stock from any depot but use sense i.e. attempting to order from local depots first, if the stock is unavailable, order from any other depot, checking closest first.

Opening times against delivery locations are maintained in the ERP.

Sales can void a note (for order cancellation, or if the product quantity being ordered is reduced). If additional product is ordered after a note is created, typically the user adds an additional order for the additional product.

The team do not amend orders - they either add new orders or they void the order and create a new one.

Voiding the order is always discussed by the sales operative and the warehouse and transport teams before it is voided, to prevent any issues. Typically, if the order has been loaded at any point, the order is not voided as transport has begun.

Voided orders are not exported to the planning system and are not present in the MSA view used by this planning system.

Other order types are also entered into GP. The type is indicated by the first few characters of the order number. The types are:

RTN - Customer returns.
INV - Customer orders.
CAL - Call-off.
ISTIN - Stock transfer between depots.
XINV - supplier-delivered orders - not part of the transport operation and therefore are to be ignored.
COMP - Customer complaint return.

Customer return order are always entered for movement back to the nearest depot. Once they are returned, the operation evaluates the product on the order:

If it is stored at this location, it may stay there, regardless of where it originally came from.
If not, a product transfer order is created to move the product through the trunk network to a depot that does store that product.

Orders in GP are indicated as to whether they are customer collect (i.e. a desk job at a depot).

The orders are then planned in the existing planning system.

The usual cut-off for orders is 1800 for radial deliveries.

The current process uses zonal delivery routes. So, deliveries from each depot are routed through the trunk network through a series of 'cross-dock paths' i.e. If this order starts at depot A and is to be delivered in zone Z, it must be trunked through depots B and C first.

EBB Paper have provided the trunk network plan, as follows:

Figure 1: Southern trunk routes
Figure 2: Northern trunk routes

Note: Subsequent to this, confirmation has been received from the customer confirming all of the cut-off and departure/arrival times of all routes. Additionally, the Sheffield trunk routes have changed times.

The operation also plans some of the trunk movements with trailer swaps, as per the following examples:

1. Vehicle swap between Hemel and Farnborough

A 26 tonne lorry leaves Hemel full of goods at 3m. Arrives at Farnborough at 4am where the drivers leaves that vehicle loaded in the yard and gets in a different 26 tonne, loaded vehicle which he goes back to Hemel in.

Both lorries are used at the sites in which they were left for the daily radial deliveries.

The lorries keep getting swapped every night.

2. Trailer swap between Thurrock and Birmingham

A 26 tonne lorry pulling a trailer leaves Thurrock at 6pm. It arrives in Hemel at around 7:30pm where both the lorry and the trailer is unloaded and reloaded as needed. This then leaves Hemel and arrives in Birmingham around 10:30pm.

The trailer gets unhitched and left at Birmingham. The 26 tonne lorry gets unloaded and reloaded. A new trailer which has been pre-loaded by Birmingham then gets attached to the lorry.

The lorry and trailer go back to Hemel where they may unload any overflow items from Birmingham and load any overflow items at Hemel for Thurrock. Both the lorry and trailer then return to Thurrock.

The trailers get swapped again the following night.

When at the final depot, that depot's catchment area is broken down further into delivery zones, which are typically used to create a single driver run. Each of these delivery zones should be broken down into smaller areas, to ensure that the locations are serviced in a reasonably efficient manner.

The operation then uses the existing system to manually change the sequence of all of the orders so that they are efficient. They also use customer (location) windows to ensure that they are delivering within the correct window.

The operation subs certain trips to 3rd-party carriers. Typically this is based on whether it is financially viable for EBB paper to run the trip themselves or for another carrier to run the trip, based on the order revenue and the carrier cost. This is a manual comparative process.

Note: The current planning process does not distinguish between order types. It is noted that customer orders should be serviced first, then any product movements are then added to the trips if there is capacity to do so.

Any low-volume routes will then be checked for cost and revenue to determine the viability and trips will be manually modified and/or merged to create a reasonable delivery run.

Customer Return orders (RTN) are also be planned onto the final radial trips.

When planned in MSA, the manifests are exported to C-ePOD, which creates loads for the manifests. Currently this is limited to:

Final radial trips.
Customer returns.
Customer collections from depot (desk collections).

Trunk trips are currently excluded, as there is not enough information on the MSA interface to determine which trunk trips should be created.

OBS have requested EBB Paper to provide extracts of the configuration data currently used by the planning system with respect to:

cross-dock paths for the trunk network.
zonal breakdown.

The intention is to potentially use this data to upload directly into CTL for system testing (as a start point).

OBS have analysed the trunk routing information provided and transposed that into data. OBS have provided a breakdown of the current routing to EBB Paper for validation, and to confirm the normal defaults i.e. trailer type, cut-off, times, etc.

Note: Subsequent to this, confirmation has been received from the customer confirming all of the cut-off and departure/arrival times of all routes. Additionally, the Sheffield trunk routes have changed times.

When the order is in GP, the operation produces pick sheets to pick the stock, and driver manifests to load the vehicles.

This leads to a process whereby any orders added to a plan after initial loading being placed on a separate manifest for the same vehicle, so that they can get a distinct sheet showing the new products to be loaded. Experience has shown that, if they do not do this, the operations may load product twice (unaware that it has been loaded already), which then leads to additional picking of product for the subsequent orders (whose picked product has been inadvertently loaded for the first order).

The existing Driver Manifests are as follows:

A manifest summary sheet, showing all stops, orders and quantity of products.
A signature line, so that they can use this sheet to capture signatures in the event of a failure.
A delivery note per order on the manifest, showing the order information, deliverable stock and quantities.

This is printed onto pro-forma stock.

EBB Paper have provided electronic copies of this documentation:

Figure 3: Pro-forma stock
Figure 4: Existing manifest
Figure 5: Existing Delivery Note

The operation trunks the picked product to the correct out-base for final delivery through the trunk network of vehicles. As previously mentioned, this is not executed by C-ePOD.

C-ePOD is used to perform the final radial deliveries and collection of returns.

TomTom navigation is used to navigate to the destination of the job, and then the product quantities delivered or collected are captured on the C-ePOD application, as well as the customer's signature.

Note: The paper delivery notes and driver manifests are used in the event of any system failure. The customers sign the manifest in the provided signature line.

The current process in use to electronically capture these manual PODs is to use the C-ePOD system when back on line, complete the job as per the sheet and then use the unmanned location process to take an image of the signature on the manifest/delivery note. This then uploads as normal to TTM. Several alternative options were discussed in the start-up meeting, but this process seems most consistent and easiest for the operation to follow.

C-ePOD is also used at the depot to complete customer collections, utilising a WAREHOUSE user.

EBB identified that there is an existing issue with customer collections.

It is noted that this is an understood limitation of the system, and is caused by customers not collecting on the day advised. The users then must move the job onto a load on the following day and close the original load to continue.

The operation makes use of Portal TTM to:

track completion of trips and orders.
run extracts of orders.

Currently, the operation utilises some extract from the Portal TTM system to provide information on the completed orders. The operation has recently raised concerns that these reports do not include enough information (i.e. the reason codes and descriptions of any cancelled or amended product, or a cancelled order).

Overview of Solution

The core systems for the business are an externally-provided ERP (GP), with OBS Logistics' systems as follows:

Great Plains ERP (GP) - order entry.
CALIDUS Total Logistics TMS (CTL) - planning.
CALIDUS ePOD (C-ePOD) - execution.
CALIDUS VEhub (C-VEhub) - vehicle checks.
CALIDUS Portal TTM (TTM) - tracking.
TomTom - navigation.

Note: With the exception of CTL, all other systems have already been installed and are in use by the operation.

Figure 6: Solution Schematic

The operational processes will be:

Orders are entered into the ERP.
CTL will pick up the orders from the ERP at regular intervals. A bespoke interface in CTL will poll for new orders.
CTL will automatically plan orders onto trips through fixed route templates, planning them onto timed trunk network trips and final radial trips. The orders will be broadly sequenced by zones within regional operating areas.
CTL users will have the facility to amend the planned trips, and to manually plan any orders that do not plan onto the trips.
CTL users will resource the trips, applying a carrier identifying the depot fleet. When a carrier is selected, they will assign vehicle and trailer to the trips. For 3rd-party carriers, the existing process will continue of assigning a warehouse driver and vehicle (e.g. WAREHOB03).
CTL users will send the trips through to the existing implementation of CALIDUS ePOD.
C-ePOD executes jobs and captures the actual delivery quantities, additional information and signatures.
This information will automatically debrief the orders and trips in CTL.
TomTom Nav is used for navigation to the destination.
C-ePOD will update CALIDUS Portal's Track and Trace module (TTM) with information for order tracking, as it currently does.

Note: The ERP will not be updated with the actually delivered/collected quantities - this information will be held within the CALIDUS systems and can be viewed in CTL, C-ePOD and C-PORTAL.

The vehicles use the TomTom PRO 8xxx devices to run CALIDUS VEhub, the C-ePOD client application and the built-in TomTom navigation applications.

Static and Configuration Data

A list of branches and their details has been provided by the customer.

Roughly 30 new delivery addresses are created each day.

Only one organisation is required within the system (EBB) - the system does not need to be broken down to division.

Certain data is required for configuration of CTL, such as:

Customers (in this case, contractual agreements between EBB and a customer, rather than a delivery address).
Locations.
Location Zones.
Cross-dock routes.
Rates.
UOMs.
Transport units.
Product Types.
Depots.
Sales territories.
Drivers.
Shift patterns.
Driver shifts.
Vehicles.
Vehicle Types.
Trailer Types.
Trailer IDs.

This information has been requested from EBB Paper.

EBB Paper will investigate extracting static data from the existing systems (both planning and ERP) to aid in evaluation and implementation.

OBS will then attempt to use this to drive upload of this existing data into CTL pre-implementation of the test system. Extensive implementation time will be required to upload this information from the existing systems and create a scripted process that can be repeated during implementation to test and for go-live.

Note: Once EBB's test CTL system is initially loaded, it will be EBB's responsibility to maintain any static data in the system. Before the system goes live, a data import of static data will be made into the production system from the test system, to ensure that the system is configured exactly as test before go-live.

Note: CTL will now be the source of all C-ePOD standing data - when standing data is maintained in CTL, this will automatically update C-ePOD. This affects the following data:

Reason codes.
Vehicles.
Drivers.
Transport Unit Types (UOMS in C-ePOD in this instance).

Note however that vehicle information is not transferred to CALIDUS VEhub.

Customers

Note: Customers in CTL determine the rate and account information, and therefore the trip cost. Each order created must belong to a customer in CTL.

The customer code will be extracted from the view from the ERP and created within CTL if this does not already exist, or updated (including the address) if it does exist. It is expected that this will include basic rate information to generate product costs.

Customers can be then maintained within CTL in the customers maintenance screen.

Figure 7: Customers maintenance

This will allow the operation to maintain the following information:

Address.
Accounting information.
Contacts.

Each customer can and should be assigned to a customer group. Only a single customer group is required - EBB.

Sales Territory

After discussion with EBB, the sales territory will be set up through the order groups and this will be used against each order. This will allow users to filter and report on orders for particular sales territories as well as delivery depots.

Order groups can be maintained within CTL in the order groups maintenance screen.

Figure 8: Order groups maintenance

Locations

Locations in CTL are used for multiple purposes, determined by the location type. It is expected that the following types will be available:

CUSTOMER - Delivery/collection locations.
RDC - Depot (RDC) locations.

Locations types are configurable in CTL using the location types maintenance screen.

Figure 9: Location types maintenance

However, location types are expected to be static and will be set up as part of the implementation.

Locations are maintained in the locations maintenance screen. All locations of all types above will be created within the CTL system with unique codes.

Figure 10: Locations maintenance

This will allow the operation to maintain the following information:

Address.
Contact information.
Loading/Unloading rates.
Opening and Closing times - EBB Paper will provide a list of time windows for the locations, which will be created as part of the implementation of the system.
Resource restrictions - EBB Paper will provide a list of resource (i.e. vehicle type) restrictions, which will be created as part of the implementation.

It is expected that locations will be maintained within the ERP and will be created and/or amended as part of the orders interface from the ERP.

Further, it is expected that all existing locations that have been used by the C-ePOD system up until this point will be loaded into the system as part of the implementation of the system. OBSL will map the loosely-formatted EPOD Customer data to the strongly-formatted data in CTL (i.e. town, county).

Note: The use of location in C-ePOD is slightly different to what is described in this document:

- C-ePOD currently does not use the AddrNo field at all.
- Location will now be the AddrNo in the case where it is a non-0000 value.

Therefore the data upload from C-ePOD as part of the implementation of the CTL product will not include these addresses. However, the orders interface being created as part of this solution will automatically create these addresses as orders are imported. EBB Paper have agreed that this is the approach that they wish to take.

In terms of location contacts, there is very little contact data currently passed to C-ePOD and available for extract, so this will not be imported. It will also not be necessary to import this on the orders.

Location Zones

Location zones are used by the system to group locations for routing through the fixed route templates.

Location zones are created and maintained within CTL in the location zones maintenance screen.

Figure 11: Location Zones Maintenance

The zones are expected to be set up to replicate the existing zones and areas used within the existing planning solution. These are not expected to be modified extensively after implementation of the system. However, they may be modified by users, which will directly affect the fixed routes that use them the next time that the scheduling engine process is run against orders.

EBB will provide a data extract of these postal ranges for evaluation.

Cross-dock routes

Cross-dock routes (i.e. the trunking network) will be maintained in the system through the use of fixed route templates.

Figure 12: Fixed route template maintenance

Fixed route templates will be created for the following routes:

All trunk routes.
All radial collection/delivery routes.

The fixed route templates can include restrictions such as:

Operational days.
Owning depot.
Carrier or Vehicle type.
Max trips per day.
Cut-off times.
Fixed times.

EBB Paper have provided outlines of the trunk routes. The OBS implementation team will use this (and the zonal information) to create the trunk trips as part of the initial implementation of the test system. However, these may be modified by users, which will directly affect the fixed routes that use them the next time that the scheduling engine process is run against orders.

Trunk routes will be created to route between the depots, cross-docking the delivery orders' product through the depots until the final regional delivery depot is reached. These route templates will be identified as a trunk route template. Trips will be created for each day as orders are planned onto the routes. These trips will be stamped as trunk routes.

The radial routes will be used to create trip for the final delivery of delivery orders and the collection of collection orders. Sub-zones will be used to partially sequence the orders on the trips.

Note: There is no facility in CTL to pre-assign resources (vehicles, trailers or drivers) to trips built from a fixed route - resources can only be assigned to a trip after it is built.

Loading/Unloading Rates

Loading and unloading rates are used per location to determine how long it will take to load or unload at that location. This includes the amount of time to handle individual transport units.

Figure 13: Load rate maintenance

So, a basic amount of time can be set for the general arrival/departure at a location, as well as an amount of time to handle each TU.

For example, one location may include a lengthy approach which takes 3 minutes to navigate, whereas another may be right outside the delivery point. In that case, the first location may have a basic rate of 6 minutes, whereas the second may only allow for a minute.

The amount of time taken to handle each TU at the locations would be the same i.e. x minutes per TU.

It is expected that TU types will be defined as part of the interface from the ERP, and that standard loading/unloading rates will be used against RDCs and customer delivery locations.

There are also certain known exceptions to waiting times, for example Desktop locations, where the driver delivers the product to many individual locations on a single delivery. These are known locations. EBB will create specific loading/unloading rates for these locations and apply them as required.

Once the waiting times are determined at each site through live running of the system, EBB can then start to input more accurate load/unload times to improve planning.

The rates are expected to be configured initially as follows:

Depots will have their own loading/unloading rates of 30 minutes.
Customer locations will have a standard 5 minute delivery time.
Desktop locations will have a 30 min rate and will be assigned to specific locations, known to EBB.

UOMs

Each order will contain products that have specific product types, expected to be one of:

1.
100.
1000.
1000sqm.
5000.
BOTTLE.
BOX.
BOXES.
CHARGE.
EACH.
ENV.
ENVS.
M2.
METRES.
Misc.
Pack.
PAN.
REEL.
ROLL.
SETS.
Sheet.
SHEETS.
TIN.
TONNE.
TONNES.

There is no concept of UOM within CTL to hold this information.

These instead will be held as transport units within CTL.

Transport units (TUs) are used to determine the loading/unloading rates and to estimate the vehicle fill, based on the quantity of product.

Transport units may be maintained through the transport units maintenance screen.

Figure 14: Transport units maintenance

Each transport unit will be configured with dims, weight and BUE (base unit equivalent) - CTL will use this, combined with the quantity against an order line, to determine the area, footprint and weight of the product being stored and therefore the capacity of the vehicle.

It is expected that TU types will be defined as part of the interface from the ERP, and that standard loading/unloading rates will be used against RDCs and customer delivery locations.

Note:

EBB Paper are reviewing the definitions of the transport units in use in the operation as part of this project, to more accurately represent size of products.
Transport units are being reviewed by and will be maintained by the customer.
This review may result in changed UOMs, for example SHEETS may become SHEETS_SML, SHEETS_STD, SHEETS_LGE, SHEETS_XL. This will reflect in the data sent to the C-ePOD system, and therefore the UOMs on the POD note from C-ePOD. This change in UOM is not expected to present a problem to EBB Paper or to their customers.

Products

Products will be held as product types within CTL.

EBB have confirmed the following information:

Product type description should never change.
A single product is always ordered in the same UOM.

The exception is FOC products, where the description will change with every order. There are multiple FOC products, for each UOM, for example FOC_SHEETS, FOC_ENVS, etc.

OBSL conducted analysis of the existing data within C-ePOD and the following was found:

There are many examples of the same product code with a different description, for example: 002.12005: "... CUT to A2", 02.16001: "... HAS BEEN CUT TO". It has been confirmed that the sales team should not be doing this.
There are examples where the same UOM (SHEETS) are used on many different product sizes. e.g. from 210*297 up to 720*1020. As this is the transport unit in CTL, this directly affects the area and therefore capacity of the vehicle. EBB agreed to maintain these UOMs in CTL.
There are 18 examples of multiple UOMs used on the same product e.g. LF1C75-320-75: 1/PACK, ZZZ100204: TONNE/TONNES, ZZZ101153: 1000/SHEETS, 130.075: BOX/SHEETS.
There are many examples of products without a UOM as well. When CTL creates a new product type, the TU will default to "SHEETS" if it has not been provided.

OBSL will send through examples of duplicated product types and examples of product types using multiple UOMs in C-ePOD, for EBB to analyse and provide instruction to the sales team as to the proper usage when CTL is implemented.

Product types may be maintained in the product types maintenance screen.

Figure 15: Product types maintenance

Each product type in the system is then used to determine the TU type that the product is stored on, and therefore the BUE and vehicle fill that this quantity of product would use on a vehicle. This can also store the default description, dims and weight of the product. These will be created when orders are created, then not updated from that point.

This process of determining the product type and TU type will need to be modified (as part of the orders interface from the ERP) to calculate the total quantity of product (multiplying quantities for example) and will require additional fields against the product type. This is accounted for in the orders interface change listed in following sections. This will be a bespoke interface for EBB.

Note that any additional UOMs that have not yet been used in CTL will be created with default values as part of this interface.

Salesperson

Sales territory and salesperson are required to be stored against each order created from the ERP. This information is required to be passed through to the C-ePOD system for reproduction onto the POD paperwork.

Sales territory will be stored as the group of the order.

There is no concept of salesperson within CTL. However, it is possible to store additional information against orders within the system, utilising order parameters.

Order parameters are user-definable and can be maintained in the order parameters maintenance screen.

Figure 16: Order parameters maintenance

These can then be applied to orders created in the system.

It is expected that a new order parameters will be created to hold this information and that this information will be automatically populated when creating orders through the orders interface.

Note: If orders are created manually within CTL (which is not expected to be part of the process in this implementation), the user must manually add this information to the orders created - the system will not require the entry of these parameters.

This parameter process will be used to store any other non-essential order information that CTL is required to store for the EBB operation (typically to pass on to C-ePOD). This may include (but not limited to) the following:

Loading location.
Order creation date.

Order Types

Order type is not a concept in CTL.

However, CTL does contain the concept of service levels, which are user-maintainable through the service levels screen.

Figure 17: Service levels maintenance

The service levels will be configured to represent the order types within the system, as follows:

RTN - Customer return.
INV - Customer orders.
CAL - Call-off.
ISTIN - Stock transfer.
COMP - Customer complaint return.
COLL - Customer collection.
TIMED - Timed customer orders

Orders will be allocated a service level through the interface.

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this range.

The operation does not normally make a specific delivery run to collect a customer return (type COMP/RTN): the, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

All exceptions will be handled and planned manually by EBB.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

Timed customer orders will be excluded from automatic scheduling and will be planned manually by the operation.

The system will be modified to create schedule rules. These rules will be used when creating the order (or assigning a service level to an order) to determine the correct collection and delivery windows. The system, when configured, will then determine the delivery window from the defined delivery date and location opening times for non-timed deliveries, and will be locked to the time specified for timed deliveries. The collection window will be determined by checking the zone from which the order is scheduled to be sourced from, and the zone of the delivery point. The rules will indicate the number of days that are required to achieve this delivery and will set the appropriate collection window.

The screen will be modified to indicate whether schedule rule associated to the service levels (order types) are excluded from automatic planning. This will be done as part of the scheduling engine, specified later in this document.

Reason Codes

Reason codes are used for many purposes in CTL-TMS, mainly:

Delivery exceptions.
Resource availability.

Reason codes are categorised by the type, which can be maintained.

Figure 18: Reason types maintenance

Delivery reason codes can be maintained in the Delivery Reason Codes maintenance screen.

Figure 19: Delivery reason codes maintenance

These are used when debriefing orders and product quantities, in exception circumstances. These match the reason codes used in C-ePOD when executing the jobs.

Resource reason codes can be maintained in the Resource Reason Codes maintenance screen.

Figure 20: Resource reason codes maintenance

These are used in the resource diary to mark resources (drivers, vehicles, trailers) as unavailable on certain dates and times.

Reason codes will be extracted out of C-ePOD and entered into CTL data as part of the implementation of the system.

Resources

Carriers

Carriers are assigned to trips for execution. The carrier is the top-level resource assigned to a trip, which then determines which drivers, vehicles and trailers are available to be assigned to the trip.

Carriers are maintained in the carriers screen.

Figure 21: Carriers maintenance

Here, the following can be maintained against the carrier:

Details - the carrier type and whether the carrier must start and end at a hub location.
Payments - accounting and rate/tariff information, for generation of trip costs.
Vehicle Type - vehicle types used by the carrier.
Contacts - contacts for the carrier
Addresses - identifying Billing Address; Collection Address; Delivery Address; Headquarters if required.
Restrictions for the carrier, such as:
- Maximum weight and volume carried.
- Product Type.
- Location Zone.
- Service Level.
- Transport Unit.
- Operating Locations.

Carriers are defined by types that indicate whether they are home fleet or 3rd-party. Carriers will be set up for each depot within the EBB network. Drivers, vehicles and trailers will then be allocated to the carriers.

A single carrier will be created per depot, with the same name as the depot.

3rd party carriers are required. currently that is known to be (not limited to):

PALLETLINE.
UK Mail.
ACL.

No 3rd-party carriers will be set up in the system - instead these will be identified by ware WAREHOB driver for the depot's carrier.

Trips assigned to 3PC will still be sent to C-ePOD, will be sent to the normal C-ePOD site, but will be sent as user WAREHOBxxx.

Warning:

This configuration will NOT allow for different rates per carrier.
Changing to add a 3rd-party carrier as a full carrier (rather than just a warehouse user) may require additional development at a later stage, not included in this project or the costs.

Drivers

Drivers must be applied to trips during the resourcing process.

Drivers and their availability are maintained in the drivers maintenance screen.

Figure 22: Drivers maintenance

Here, drivers can be:

created with full reference details, amended or deleted.
assigned to carriers.
excluded from working for customers or at locations.
have a shift pattern assigned.
have their availability modified for non-working time or holidays, for example.

Shift patterns can be created or modified in the shift pattern maintenance screen.

Figure 23: Shift Patterns maintenance

All drivers for all depots will be created and maintained by the EBB operational staff. This includes the warehouse staff e.g. WAREHOB03.

Currently resource availability is managed through a combination of a spreadsheet and/or calendar.

CTL contains a number of facilities to manage resource availability. However, EBB must note that CTL is not a resource management system.

Resources can be limited by:

Availability calendar, showing when this resource is unavailable and why.
Driver shifts.
Vehicle Off-road.

Figure 24: Driver availability calendar

Figure 25: Full-screen calendar

EBB described that they would ideally like a total view of all resources on a single calendar, showing who/what is unavailable on certain dates, so that they can use this to manage resource requirements, driver holiday requests, etc.

Note that CTL allows the user to identify a driver resource, then click the calendar section and add in unavailability information. Users can also use this to set the driver's shift. The same calendar can be accessed from individual vehicles (to make them unavailable at certain times/dates). Vehicles can also be indicated as being off-road or on-road, by checking or un-checking the VOR flag.

The single driver or vehicle calendar can be shown full-screen, but that there is not a single calendar view that shows all of a particular resource type, to give the customer a full view. However, the resource availability information could be extracted from the system through the data extracts to that the operation can get a full view from that extract. EBB have decided that this full-screen calendar is no longer a requirement.

Vehicle and Trailer Types

Categories are created that define whether vehicle types of this category have transport movement capability and/or storage capability.

Figure 26: Vehicle Categories maintenance

For example:

a trailer has storage capability but no transport movement capability.
a tractor unit has transport movement capability but no storage capability.
a van has both.

Types are then created for each tractor, trailer and/or van in the operation.

Figure 27: Vehicle Types maintenance

These define the general outline of vehicles of this type, such as the maximum weight, dims, max BUE and any additional equipment.

Vehicles have different weight limits and not all vehicles are capable of pulling a trailer. A trailer can be added to the trip. This should increase the volume accessible to the trip.

Vehicles and Trailers

Vehicles in CTL define all available transport types, including tractor, trailer and van, through the category and type.

Vehicles can be created in the vehicles maintenance screen.

Figure 28: Vehicles maintenance

Here, the individual vehicles are entered, identifying the vehicle type. The specific characteristics of a that vehicle may be maintained, such as:

Vehicle code (typically the registration plate or trailer ID).
Make/Model/Livery.
VIN number.
Fleet number.
Fuel type.
Fuel efficiency.
ODO reading.
Registration date.

Note: Vehicles and trailers are carrier resources and must be assigned to a carrier.

Note: Vehicles, like drivers (above) can be made available or unavailable through the resource calendar. The vehicle may also be marked as off-road.

Orders

Orders will continue to be created in exactly the same way as they are now, within the ERP.

ERP-CTL Orders Interface

The operation will expect to execute the following movement types:

Radial delivery.
Customer collection.
Customer returns.
Trunk movements.

Customer collections will be interfaced to CTL on a separate manifest per depot, but with a driver of "WAREHOUSE". Note: The view MSA contains a column that identifies whether this is a customer collection (column CustColl).

There are also supplier direct to customer deliveries. As these are not executed through the EBB network, they will not be interfaced into CTL.

SCR-366558-1:

Bespoke import interface.

Note: A version of this interface has already been written as part of the C-ePOD integration. This is not suitable for implementation into CTL (mainly because it is primarily driven from a file sent from the MSA TMS already in place). This, however, may be used as a template as to how orders are created.

The team do not amend orders - they either add new orders or they void the order and create a new one. However, the interface will be written in such a way as to update orders if they already exist, so that re-processing a failed order will not prevent this interface from working as expected.

Note: The import of orders will be designed to utilise the static data created in CTL. Certain areas, such as DU/TU (Despatch/Delivery unit or transport unit) are used to determine the vehicle fill through a percentage BUE (base unit equivalent). The process will apply the product and UOM to the product type and TU type, which will represent a proportionate vehicle fill.

A scheduled import process will be created on the system, running at a timed interval. EBB Paper have requested that this process runs as frequently as possible. The target for this will be every 3 minutes, but this must be evaluated during implementation for efficiency of the process and may need to be changed.

On the day of implementation of the live CTL system, the existing interface in C-ePOD will be disabled, as C-ePOD will now be receiving all orders and trips from CTL through the standard C-ePOD web-service interface.

The current C-ePOD order import is triggered by the transport plan. The process then retrieves the details of only the orders on that transport plan. As CTL will be responsible for creating the transport plan, this will require a change in how this is triggered.

Extracting data for orders will be direct from the MSA data, taken from the existing view of data.

The view currently shown 14 days of orders.

It will not be efficient to retrieve all orders from the view and check whether they have changed. As this will be happening very regularly (the import is expected to look for orders every few minutes), the process must be efficient.

In order to make in the new order import work efficiently, the MSA view must change to show:

Voided orders.
Creation Date/Time.

This will be prototyped by EBB paper as a new view within the existing database for the purpose of evaluation of the new CTL interface. Note that voided orders may instead be through a different view.

Voided orders in the interface will be handled as follows:

The order will be moved to CANCELLED status.
The order will be automatically unplanned from all trips, as long as none of the trips have not yet started (i.e. not status EN-ROUTE or COMPLETED).

Any order that is cancelled after it has begun being transported by the operation (i.e. the order is on any trip that is EN-ROUTE or COMPLETED status) must be manually handled. In this case, this means manually un-planning the cancelled order from any trips that are no longer required and moving the product back to the depot that will store the order's product. The raising of this stock transfer movement will be at the discretion of the operation.

Warning: Voided orders removed from trips will change the product that is delivered and also loaded/unloaded by the operation on the trunk trips. It is likely that the operational documents affected by this will require reproduction by the operation. This should be achieved when the order is taken off trips by the operation.

Opening times against delivery locations are maintained in the ERP. These delivery times must be maintained against the orders in CTL.

These delivery windows will be transposed directly against the customer orders. These will be visible against the orders and may then be used when planning.

The interface will search for all orders created since the last time that the interface ran. For each order found, the interface will create all details of the order, including:

References - the order references, expected to be the CTL order number, the external order number, the customer's reference and/or the IDT Number. The order created date and time will be stored in the Order Placed Date/Time.
Service level - the service level will be determined from the first few characters of the order reference. If the order is specified as customer collect, this will be identified as a different service level, and orders with a timed delivery will be classed as another service level. The service level and appropriate schedule rules will identify whether the order may be automatically planned (through the scheduling engine, described in following sections).
Instructions - any order-specific instructions.
Locations - the origin and destination (from and to) locations. Any locations that do not already exist will be created by this interface.
- If AddrCode is "0000", then CUSTNMBR is the location AND the customer.
- If AddrCode is NOT "0000", the CUSTNMBR is the Customer and AddrCode is the Location.
Scheduling - the collection and delivery windows for the order.
Contacts - any contacts for the order. As already mentioned, it is unlikely that there will be any contact information available to import.
Requirements/Charges - any ad-hoc charges associated with the order. This will be used to generate the revenue of the order and will be taken directly from the ERP gross profit (XTNDPRCE – EXTDCOST).
Transport Units/Products being delivered. This process will also create TU types and product types where required. Unit weights and dims will be stored on product types and UOMs. These will be created when orders are created, then not updated from that point. The process will also be amended to store pack sizes, bin bays and non-stock flags
Customer - the customer and basic rate information will be defaulted in order to generate costs for trip. The customer will be identified through the CUSTNMBR and AddrCode fields in the view and will be automatically created if they do not already exist and updated if they do (including the address):
- If AddrCode is "0000", then CUSTNMBR is the location AND the customer.
- If AddrCode is NOT "0000", the CUSTNMBR is the Customer and AddrCode is the Location.
The sales territory (order group).
Parameters - consisting of:
- Salesperson.
- Route.
- Order Comment ID.
- Any other non-critical cross-reference data required for the order.

Note: The operation has requested that lot numbers for certain order types be captured within the system for execution and reports. This is covered in more detail in the following Lot Numbers section. Note however that this is not being progressed as part of this implementation and will be evaluated at a later time, possibly when WMS operations are being considered.

The collection and delivery windows will be set based on the order type (service level), schedule rules and the zones of the origin and destination locations. The interface will provide the requested ship (delivery) date, and the schedule rules will use that as the seed to determine these windows.

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this region.

Returns (COMP/RTN): the operation does not normally make a specific delivery run to collect a return, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

All exceptions will be handled and planned manually.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

Timed orders will be will be excluded from automatic scheduling and will be planned manually by the operation.

The assignment of the service level, the schedule rules and the zones of the origin and destination locations will determine whether the order is to be automatically scheduled, and this will be stamped against the order.

The process will audit the success or failure of these order interfaces through the EDI Log screen, with a line for each order imported, a status (success or failure) and a showing the reason for any failure in detail.

Note: Voided orders will be audited through the EDI log, in that the description of the process will clearly state that this order has been voided.

Given that the interface is based on the creation date of the orders, if an order should fail, there will be no facility to get the order again. Therefore this auditing process must check the interface type that generated the message (in this case, then bespoke EBB orders interface) and allow for re-processing of the message. The interface should check for any messages marked to be reprocessed in the audit log and get the details of this order again in the next pass. The original audit record will be updated as reprocessed and a new audit record created for the new import.

Note: Failed orders will not automatically re-import - it is up to the CTL administrators to look for failures and mark them to be reprocessed, as this may require modifications to be made to the order in the ERP or the static data in CTL to allow the order to be successfully processed.

Orders Maintenance

All orders created in the system can be viewed and edited through the orders maintenance screen.

Figure 29: Orders maintenance - list of orders

Each order created will have the following information:

References - the order references, expected to be the CTL order number, the external order number and the customer's reference. This also includes the order type (service level).
Instructions - any order-specific instructions.
Locations - the origin and destination (from and to) locations.
Scheduling - the collection and delivery windows for the order.
Contacts - any contacts for the order.
Transport Units/Products being delivered.
Customer.
The sales territory (order group).
Parameters - consisting of:
- Salesperson.
- Loading location.
- Order creation date.
- Any other non-critical cross-reference data required for the order.

Note: The revenue of orders created through the interface will be fixed and cannot be changed in this screen.

The assignment of the service level, the schedule rules and the zones of the origin and delivery locations will determine whether the order is to be automatically scheduled, and this will be stamped against the order.

Figure 30: Orders - status, references, type, instructions

Figure 31: Orders - locations

Figure 32: Orders - scheduling, requirements, transport units

Figure 33: Orders - parameters, audit

A full audit trail is maintained of the creation and each change made to orders, either through the orders interface or manually by users in this screen.

Lot Numbers

Lot numbering is a requirement of the operation.

Note: Lot numbers are not part of this implementation. However, this has been left in for reference. If required, this will require a software change request (not included in the list of SCRs in this document.

Call-off orders are typically large orders, pulled by pallet, where specific lots are identified.

Typically these are full reels of a single product, with a unique lot number and weight within the ERP.

The reels are palletised, one reel per pallet.

The weight of each reel is roughly the same, but never identical.

So, if an order calls off 11 tonnes, and the weight of each reel is roughly 1 tonne, the order will identify 11 pallets (lot numbers) with a weight as close to 11 tonnes as possible.

The lots are identified on the order and on the pick note.

The specific lot numbers are then picked and loaded for the order.

Typically (but not always) this constitutes a full load.

Because this information is not specifically displayed on the C-ePOD device, the driver could technically unload the incorrect lots.

So the operation require that this information is displayed on the C-ePOD device and also potentially onto the POD document produced from C-ePOD.

Note: A view will be required within the ERP accessible by the CTL interface to retrieve the lot numbers, regardless of whether or how CTL intend to store or process the data. This will be a separate view (not amending the main order view) to that this can be implemented separately if required.

This view will contain:

ORDER
PRODUCT
LOT

When importing orders, the process will check for any lot numbers associated with the product. If any are found, these will be stored as separate items under the product (the order line).

This information will be sent to C-ePOD as part of the interface.

The interface will either:

Concatenate these lot numbers into a single field against the order or;
Send these through as individual items to be found and delivered.

This will affect the delivery process for the drivers in different ways:

If concatenated, the information will be displayed against the product being delivered. So, if the product was 247.01 and the lots called off were LOT1, LOT2 and LOT3, there would be 1 product line for 247.01 with an additional text field of "LOT1, LOT2, LOT3" displayed against it.
If sent through as individual pallets, these will be listed as individual containers on the list, showing the lot number, product code and weight. Each item will need to be confirmed separately. So, if the product was 247.01 and the lots called off were LOT1, LOT2 and LOT3, there would be no product lines but there would be 3 containers: 247.01-LOT1, 247.01-LOT3 and 247.01-LOT3, each showing the actual weight of the lots for that product.

Each process would require some development, specifically:

Both:
- Order interface to retrieve and store lot numbers.
- POD format change.
- EPOD Products List layout change.
Concatenation:
- Identify a field on EPOD to store concatenated lot numbers
Lot as separate items:
- Modify the length of the product + lot number, to ensure it can be stored.

Each process has pros and cons:

Concatenation:
- The driver process would not change in EPOD - they would still be prompted only for a single concatenated line.
- The drivers would manually check the lot numbers - the device cannot enforce this.
- The summary of products delivered (at customer signature) would not display the lot number without further development.
Lot as separate items:
- Lots are immediately visible in CTL and EPOD without looking for the additional field.
- Specific lots can be marked as delivered or not.
- Driver will have to identify multiple items to unload - one for each lot.

EBB will confirm the process they want to follow as part of the review and sign-off of this solution design.

Planning

Automatic Route Scheduling

As shown in the Cross-dock routes section above, CTL will replicate the existing fixed route configuration with respect to:

The trunk network.
Delivery zones and areas.

The intention is that CTL will use these created templates and zones to automatically plan each new order onto trips for that day through a scheduling engine process running at a timed interval.

Fixed routes related to the trunk network will be identified with a Trunk flag.

Any orders that do not match or are outside the normal schedule, break vehicle capacities, etc) will remain unscheduled and can then be investigated. This should allow the operation to work much more pro-actively, with the system doing all of the original planning to the template, and then the users investigating just the exceptions, finessing the delivery plans, etc.

The automated scheduling process will check the attributes of the order being scheduled against the fixed route template, checking:

cut-off time.
from location (the depot from which the product is picked).
end location compared to the zones on the fixed route template.
delivery window, in that the order must be delivered within the end window of the order.

Note: Vehicle capacity will not be part of the restrictions of building fixed routes - the process will build the trips according to the specified other attributes, and then the vehicles will be resourced accordingly at the resourcing stage. Should any trips have been automatically planned exceeding the capacity of the vehicle, the operation will assess whether to include a trailer or to manually split the trip or split orders onto other trips.

The collection and delivery windows will be set in the interface based on the order type (service level).

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this window, for longer-haul (north-south and vice versa) - this will be defined by the schedule rules.

If a trip is not found that matches the criteria of the fixed route template, one will be created. If the route templates indicates that this is a trunk trip, the trip created will be stamped with a flag indicating this. All trips created from fixed route templates will be automatically named from the fixed route template description. In this way, trips created from routes and trunk trips can be quickly identified in the system.

If one is found, the order will be added to that trip and the order will be considered to be planned up to the destination of the template.

This process will repeat, finding and scheduling the order onto trips generated by fixed routes until the order has reached its destination.

The process will plan the orders through the fixed route network in the fastest time possible, rather than attempting to reach "just in time" to the destination.

If at any stage the order cannot be planned in full from the origin location to the destination within the delivery window, the process will stop planning the order at that time. However, all planning up to that point will be retained. This allows the users to manually plan the order from that point onwards after discussion with the customer. If they choose to plan via a third party carrier, the order can be unplanned if necessary.

It is requested that the process used to plan the orders within CTL plans only certain order types (service levels). Essentially, only customer-related delivery orders will be planned onto trips. Returns and stock transfers will then be manually planned. In terms of order types, that is:

INV
CAL

The order import process (or order entry process) will mark the order as requiring manual planning based on the service level and schedule rules and this will determine whether the order should be excluded from automatic planning.

Returns (COMP/RTN): the operation does not normally make a specific delivery run to collect a return, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

Timed customer deliveries will be excluded from automatic scheduling and will be planned manually by the operation.

All exceptions will be handled and planned manually as shown below.

Manual Planning

All trips automatically or manually planned can be viewed and amended through the CTL planning screen.

When creating manual trips, the screen shows a view of all orders in the order well. This list can be restricted to the orders that are being planned (i.e. unscheduled orders) and filtered.

The screen allows:

Creating new trips.
Filtering trips by status, trunks, carriers, depots, dates, schedules, trunk trip, etc.
Filtering orders by status, schedule, ownership (by region), customer, etc.
Amending trips.
Resourcing - discussed in more detail in the following Resource Assignment section.
Viewing on a map - discussed in more detail in the following Optimisation section.
Optimisation - discussed in more detail in the following Optimisation section.

The carrier you are planning for is shown in the header, and all trips shown will be restricted to that carrier. The trips can also be further filtered.

Multiple orders can be selected and new trips can be created, either to the destination or through a cross-dock location, using the buttons provided.

Figure 34: Planning Order Well

Existing trips can have orders manually added to them by selecting the orders and dragging them to the trip in the trip panel.

Figure 35: Planning onto existing trips

Each trip can be viewed in more detail through the full-screen view. Each stop can be expanded to show the orders on that stop, along with more stop and order information.

Each trip and stop shows warnings regarding potential planning issues.

Figure 36: Full-screen with expanded details and warnings

The current planning process uses the gross profit to determine the viability of any single trip, so planning must show order revenue and trip cost. This is applicable only to final radial trips.

The order revenue calculated in GP will be picked up as part of the order interface. This will then generate the order revenue - it need not be calculated in CTL.

The screen will displays trip cost and total order revenue on the trip summary.

The screen will also indicate whether this is a trunk trip on the full screen view.

Desk collections can order product from one depot e.g. (Thurrock) to be collected at another (e.g. Farnborough).

The order must be trunked to that location.

Typically collection is at the depot closest to the customer, but could be at any location.

EBB will manually trunk and create collection trips for customer collections and returns, timed customer deliveries and stock transfers.

In order to facilitate that, the users will filter orders by service level on the planning screen.

Optimisation

Trunk trips will naturally be optimised as they are very prescriptive with limited stops and fixed times.

Regarding radial trips, although the fixed route templates will get all of the orders on the trunk and final radial trips as required, the sequence of the orders on the trip will not be fully optimised.

The planning screen will allow the user to see all of the orders on a trip on a map, so that they can see inefficiencies and change them manually. MT confirmed that this cannot be changed on the map - this map is used for information, which the user then replicates on the trip by changing the stop sequence.

Figure 37: Planning map view

There is trip optimisation option built into the planning screen, utilising HERE maps optimisation.

This has been agreed that this is part of the solution that will be built for EBB and that the costs of the HERE maps optimisation are included.

The user can use the icons under a trip to automatically optimise the sequence of orders on this trip.

Figure 38: Optimisation

The HERE maps optimisation supports:

Fixed start times.
Fixed start and end locations.
A single location time window.
Fixed sequencing (i.e. order B before order A).

Note: Optimisation will use these order/customer windows to automatically determine the most efficient run sequence.

Resource Assignment

Once trips are created and optimised, the users will assign resource to the trips.

Note: There is no facility in CTL to pre-assign resources (vehicles, trailers or drivers) to trips built from a fixed route - resources can only be assigned to a trip after it is built.

The current implementation of C-ePOD is enabled for trailer identification, but that it appears not be used at this time. The operation requires that this is used after the implementation of CTL.

Trips are created with carriers assigned to them. The carrier defines the available resources (driver, vehicle, trailer).

The planning screen allows the users to assign resource to trips.

Figure 39: Resourcing Drivers

Figure 40: Resourcing Vehicles
Figure 41: Resourcing Trailers

Users can select the resource type and then drag and drop the selected resource onto the trips. Depending on the trip being resourced, the resources will be displayed with annotations to indicate any limitations with this resource on this trip.

EBB noted that certain locations have restrictions as to what trailer/vehicle type may visit that location (for final radial runs of deliveries and collections). OBS noted that CTL contains the facility to restrict vehicle types or specific vehicles from visiting the location.

Furthermore, drivers themselves can be excluded from delivering for certain customers or locations.

This users enter this information as part of the configuration of the resources (driver, vehicle and trailer).

This information is used when resourcing created trips, by providing decision assistance to the user, indicating why the specific resource (vehicle or driver in this case) may or may not be suitable for this trip, in the form of warnings or information icons and pop-ups against the resource or trip. This will show:

Driver exclusions.
Driver availability (diary).
Driver working hours/shift.
Vehicle/trailer exclusions.
Vehicle/trailer availability (diary or VOR).
Resource already allocated.
Resource (equipment/driver) restrictions.

The screen will also display these warnings against the trip header and against applicable stops.

The operation will plan trailer or vehicle swaps by applying a trailer or vehicle to a trip as normal. The operation can then plan a trailer or vehicle swap at any location on the trip by entering a new trailer or vehicle against that stop.

SCR-366558-2:

Plan trailer swaps.

Execution

Once a trip has been successfully resourced, the users may then export the trip to C-ePOD for execution using the provided button on the trip. The trip will be automatically set to ACCEPTED status.

Figure 42: Send trips to EPOD.

Note: The users may still modify trips after this point, and the trip can be sent to C-ePOD again after modification are complete.

Note: This process could equally be completed after loading is completed.

The interface to C-ePOD will require some change from the standard model to support the requirements of the existing EBB Paper implementation of C-ePOD. The following changes are required:

Map new/changed elements (i.e. Sales territory, Salesperson, loading location, order creation date, etc). Ensure that this is configurable.
The configuration of job group will be required to be set by stop activity (SU, PK, DL, CL).
Job consolidation is required at a loading and unloading stop level at a depot only.
Depot loading and unloading will be identified as loading or unloading jobs in the interface (as opposed to normal collections and deliveries).
Trailer identification.
Importing of any bespoke functionality into the standard C-ePOD webservice interface, such as (but not limited to):
- Creating UOMs.
- Creating drivers.
- Creating trailers.
- Multiplying product quantities.

Note: If lot number functionality is to be developed, this interface must also include the specific lot numbers. This is included as part of the lot number change discussed earlier.

Note: The changes to the mapping of the data through to C-ePOD have been included in the Bespoke Interface Development, shown earlier.

Note: The use of location has changed slightly, as identified in the order import process:

- EPOD currently does not use the AddrNo field at all.
- Location will now be the AddrNo in the case where it is a non-0000 value.
- This drives a change to what is sent to EPOD, in that the location may differ.

This will be reflected in the interface and in the set-up of the C-ePOD system. This is not expected to drive any meaningful change into the process, but more properly defines the data.

The operation will then need to load the product and print out driver manifests and delivery notes for the trips. The system will include the following operational reports:

Driver Manifest.
Delivery Notes.

Note: It is to expected that OBSL will develop these EBB formats within CTL, requiring the following additional development.

SCR-366558-3:

EBB operational reports.

Loading

The operation will load the vehicles based on the trips created. Loading will be controlled through the Driver manifest report produced from CTL.

This will display the stops on the trip, and display a list of the orders and product (lines) and quantity to be loaded. Note: If lot number functionality is to be developed, this report must also include the specific lot numbers to be loaded. This is included as part of the lot number change discussed earlier.

To aid in the issues in the current system where late orders sometimes result in duplicate picking or loading twice, the Driver Manifest report will be modified to help control this.

A mechanism will be introduced in this report whereby a unique ID will be stamped against the reported orders showing when they were added to the Driver Manifest report. This then will immediately identify to the users that these orders are additional to any previously-produced sheet and are awaiting loading, whereas any that have the previous ID were produced on an earlier report and therefore may already be loaded.

SCR-366558-4:

Driver manifest to include run sequence.

Warning: Voided orders may have been removed from trips or may still be assigned to the trips. When producing the documentation (driver manifests or delivery notes), the documents will remove any cancelled orders. When the orders are removed from the trips by the operation, the orders will no longer show on the operational documents for those trips and therefore the operation will need to take great care in ensuring that cancelled orders that have been removed from trips have their operational documents reproduced.

Note: It is noted that voiding orders is subject to operational checks between the salesperson and the operation (warehouse and depot) before orders are voided. If this check is performed, it is highly unlikely that the operation will have issues with voided orders. This manual check must remain, however.

The operation will use the driver manifests and delivery notes to load and unload vehicles at the depots. The operation will re-print driver manifests at each depot on a trunk, so that it includes any orders that have been added to these trips since the manifest was printed at prior depots.

Vehicle Departure

Once the loading of a trip is complete (and the trip is resourced and sent to C-ePOD), the trips can be executed through C-ePOD.

When a trip is started on the C-ePOD device, the trip will be set to EN-ROUTE status within CTL automatically.

Note: EN-ROUTE trips will still be accessible through the CTL planning screen and may still be amended. The planning screen does not, however, display any actual stop times or order quantities that may have been derived through execution through C-ePOD - this information can be seen through the debrief screen discussed in the Trip and Order Debrief section below.

The operation already uses C-ePOD to execute trips for delivery, return collection and customer collection (desk) jobs.

As already mentioned, trunk trips were currently not operated through EPOD.

The following types of trip will now be executed through C-ePOD:

Trunk trips.
Final radial delivery/return trips.
Customer collections at the depot (warehouse/desk jobs).

Delivery/Collection

The operation already uses C-ePOD to execute delivery/collections loads.

The process is as described in the C-ePOD requirements document, referenced in Appendix B below.

This is summarised in this section.

Retrieving the load

The driver will log on to the device with a user name, password and vehicle.

The device will download the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (and/or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Starting jobs

The driver will select Start Job from the Job Details screen.

Delivery instructions are displayed.

The driver may do the jobs in any sequence - the device will warn the user if the jobs are attempted out of sequence.

Once started, the device displays a navigation button. Clicking this will start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp. For non-TomTom devices, the application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.

Once arrived at the destination, the driver switches to the CALIDUS ePOD mobile application.

The driver indicates arrival and starts processing the job by clicking the Arrive Job button.

The device moves on to the Delivery or Collection process, depending on the job type.

Delivery process

The driver confirms delivery of the product and quantities for the order.

The driver can confirm each product on the list as delivered, change the quantity delivered or cancel the delivery of that product.

The driver has the option of clicking Deliver All on the Job Details tab to confirm all product on that job as delivered.

When all products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

Note: If lot number functionality is to be developed, this process may change. This is included as part of the lot number change discussed earlier.

Returns (collection) process

The collection process is almost identical to that described above, substituting Collection instead of Delivery.

When all products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.

Job completion process

The device displays:

The Terms and Conditions.
The Products delivered/collected.

The driver is expected to obtain:

the customer name.
the customer Signature.

The driver has an option of Unmanned location for unmanned locations or delivery out of hours. This process will instead require:

the driver signature (PP customer).
photos to confirm delivery.

When the delivery or collection job is complete, the job is removed from the list. The driver continues the same process for all jobs on the load.

Customer Collection from Depot (Desk Collection)

The operation already uses C-ePOD to execute desk collections loads.

The process is as described in the C-ePOD requirements document, referenced in Appendix B below.

This is summarised in this section.

The above process of working through jobs from a Job List, selecting them and following the delivery process will be as per the above process.

The Load for the depot operatives is created one per depot per day, so all collections from the depot will be visible on that load.

The device shows all jobs as delivery jobs with the destination address and contact information provided. The desk operative requests the information from the customer (reference, post code, etc) and select the job (or consolidated jobs, if there are many to be collected) from the job list.

The depot operative starts the job and immediately clicks Arrive - no navigation is required.

The depot operative checks the goods and 'delivers' the goods as the driver would. Deliver All functionality is available.

The device prompts for the customer signature - no unmanned location process is available.

When the desk collection is complete, the job is removed from the list, as normal.

All collections for the day remain on this load unless they are moved to another day. If any jobs remain on this load at the end of the day, the load is cancelled or deassigned from the "WAREHOUSE" user.

EBB identified that there is an existing issue with customer collections.

It is noted that this is an understood limitation of the system, and is caused by customers not collecting on the day advised.

The users then must move the job onto a load on the following day and close the original load to continue.

CTL will build trips in the same way as EPOD currently does so, without additional work, this problem will persist.

The operation will use CTL planning to manually re-plan any remaining orders on to a trip for the next day, and then manually close the previous load. This will close the load in C-ePOD.

Trunk Trips

EBB Paper desire to start using EPOD for trunk trip execution.

Based on the current known requirements, there are no modification required to the systems to help process trunk movements through CTL and C-ePOD.

It is expected that the trunk trips will be operated through C-ePOD in a similar way as radial deliveries. This is as described in the C-ePOD requirements document, referenced in Appendix B below and summarised above.

The device will be configured with 'Deliver All' functionality, so that the driver would not have to scan each product on or off the vehicle.

Note: During the start-up meeting, it was mentioned that entering the product quantities could be desirable at certain depots, due to inaccuracies when unloading. It should be noted that it is the driver that would be responsible for the unloading and product quantity entry and therefore this may not be suitable.

Note: The system could be configured to run these jobs and that the configuration could be made specific to these jobs. EBB are to decide upon the exact configuration required for the trunk job execution.

The process within C-ePOD for trunk loads will be as follows:

The driver will log on to the device with a user name, password and vehicle.

The device will download the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (and/or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

The list will contain only a single entry per loading or unloading at the depots, no matter how many jobs there are on the load. So, if this were the Sheffield - Birmingham trunker:

1 loading entry at Sheffield planned for 1800.
1 unloading entry at Birmingham planned for 2030.
1 loading entry at Birmingham planned for 2130.
1 unloading entry at Sheffield planned for 2330.

Figure 43: Job List showing consolidated trunk jobs

The driver will start, navigate and arrive the jobs in the same way as normal collections and deliveries. The driver will also be able to view the order level details of all orders to be loaded at that location, using buttons on the header to view each order. All instructions for all orders at that location will be displayed to the driver.

At this point, the device will display all products for all orders. The driver will have a single button to confirm that the jobs are loaded, through a Collect All button. The driver will be able to mark individual products as not loaded or unloaded first, through the standard exception processing on the device, by cancelling or changing the quantity of the product.

Note that the unloading or loading of products for a trip/vehicle is expected to be handled through the operational documents either carried by the driver or produced at the depot.

When the user has confirmed all products are collected (loaded) for that location, the device will then require a signature as normal.

When the loading job is complete, the job is removed from the list. The driver continues the same process unloading at the next depot, and any other jobs on the load in sequence. In the case of unloading jobs, the driver will have a Deliver All button rather than a Collect All button.

Trailer Swaps

C-ePOD contains functionality to control the swap of vehicles at a point in the trip. This functionality could be extended to handle the vehicle or trailer swap functionality required by the operation, or the operation could handle the trailer swap manually as now.

SCR-366558-5:

Execute trailer swaps.

For example, when the driver drops off at Birmingham, the device could display a message to state that the unloading/loading at this stop is a vehicle and/or trailer swap. It could tell them that the vehicle is changing and to:

Drop off the vehicle/trailer.
Pick up the new vehicle.
Perform vehicle checks (not required in this implementation).

This functionality within C-ePOD is bespoke for another customer and would require additional development to extend this functionality to support the job swap process.

Regardless of whether this on-device C-ePOD functionality is enabled, the debrief of trips that have swapped trailers or vehicles will update the availability of the vehicle or trailer in question, so that it is now available for selection for the carrier that now has ownership of it. This will be done as part of the change to plan trailer swaps.

Trip and Order Debrief

Debrief consists of several elements:

Trip debrief, confirming trip, driver and resource information captured.
Stop-level debrief, typically confirming the actual arrival and departure times
Order-level debrief, typically confirming the quantities of products collected, despatched and delivered.

CTL allows all of these elements to be debriefed, largely automatically from use of C-ePOD execution.

Figure 44: Debrief Trip level

Figure 45: Debrief Stop and Order level

Figure 46: Debrief Order Line level

C-ePOD provides GPS tracking and an interface of actual arrival and departure dates and times into CTL-TMS to enable planned versus actual schedule adherence to be measured. This data is captured automatically, near real time.

The C-ePOD system is responsible for the trip/stop-level debrief information (i.e. the On Time aspect of OTIF, the arrival and departure times against stops on a trip). This information is stored within CTL-TMS for reporting purposes.

This update for trunk trips will update the arrival and departure times against each stop on a trip.

For final mile delivery trips executed using the C-ePOD application by the driver, this will update order quantities in CTL-TMS and therefore will set the delivered quantities against the orders and complete the order and the trip, changing the statuses accordingly.

Any modifications to delivered quantity or the product delivered are captured with a clause code in C-ePOD. This information is included in the debrief and reflected in CTL-TMS as part of the reason codes against each line. Note that this is also true of individual items (which may be used for lot number processing). Note: If lot number functionality is to be developed, this process may change. This is included as part of the lot number change discussed earlier.

Most orders will be executed through C-ePOD as described above. In this case, the CTL-TMS debrief screen will provide a view of the information captured from the C-ePOD system.

However, in some instances, the operation may wish to manually debrief orders, for example orders through 3rd party carriers.

CTL-TMS provides a debrief screen that can be used to review the automatic debrief updates from the mobile execution systems and to update and finalise the driver, trip and order debrief (i.e. the In Full aspect of OTIF).

The order debrief allows the quantity of despatched and delivered units to be confirmed for each order line.

The trip stop times enables actual times to be reviewed and input against planned times. This is expected to be automatically populated by C-ePOD.

Any discrepancy of actual quantity input for an order will prompt the user to enter a reason code from a list and narrative can be added.

The screen also allows each individual tracked item to be debriefed for despatch and delivered quantity. This may be used for Lot traceability. Note: If lot number functionality is to be developed, this process may change. This is included as part of the lot number change discussed earlier.

Start and End ODO readings may be entered against a trip at debrief. These may be viewed and entered in the manual debrief screen. These ODO readings will be stored in KM as a base unit. Note that this is not captured automatically from C-ePOD, but may be manually entered if desired.

Fuel drawn by the engine may also entered against a trip at debrief. This may be viewed or entered in the manual debrief screen. Note that this is not captured automatically from C-ePOD, but may be manually entered if desired.

Once the debrief entry is done, the status of the trip can be updated and promoted to COMPLETED using the provided button.

Track and Trace

The operation already utilises CALIDUS Portal TTM for track and trace of trips and orders.

The process will not be affected by the addition of CTL as a transport management system, as C-ePOD will continue to be the source of all TTM-related information.

The system is described in the C-ePOD requirements document, referenced in Appendix B below. No changes are being made to any functionality of this system as part of this implementation of CTL. Therefore it will continue to run exactly as it does now in all instances, including the calculations of ETA times. However, as trunk trips are now being executed by C-ePOD, these trips will be visible within TTM.

Reporting

Currently, C-ePOD generates the POD/POC documentation for each job completed. This will continue.

Note: As part of the Lot Number change discussed earlier, this report format may require modification.

Regardless, there are changes required to the C-ePOD report to reflect new configuration in C-ePOD user-defined fields - this has been agreed to be completed as part of this project.

SCR-366558-6:

Modify POD/POC report to include new UDF fields.

Currently, the operation utilises some extract from the Portal TTM system to provide information on the completed orders. The operation has recently raised concerns that these reports do not provide all of the information that is required, namely the reason codes for product quantity amendment or cancellation.

These reports will be superseded by data extracts within CTL. It is not required that the existing TTM reports be modified to provide this additional functionality before the implementation of CTL.

The TRIP_ORDER and ORDER extracts will report data to a reason code level.

The levels will report to the following levels:

TRIP_ORDER extract: TRIP/ORDER/LINE/ITEM/ITEM_REASONS
ORDER extract: ORDER/LINE/ITEM/ITEM_REASONS

It is acceptable to the operation to have these extracts run by repeating lines dependent on the number of child records.

So for example, with a trip with 5 orders, each with 5 products to deliver:

Reporting at TRIP level will show the 1 line with the trip-related fields.
Reporting at ORDER level will show 5 lines with the trip-related fields repeated and the order-related fields.
Reporting at LINE level will show 25 lines with the trip-related fields repeated and the order- and order line-related fields. The reason code will be populated if present.

When extracted, the data in this form will be easy to pivot in Excel.

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	CTL/EPOD	Integration	Bespoke import interface.	40.00
2	CTL	Resourcing	Plan trailer swaps.	10.00
3	CTL	Reports	EBB operational reports.	5.00	²
4	CTL	Reports	Driver manifest to include run sequence.	3.50
5	EPOD	Execution	Execute trailer swaps.	12.00	²
6	EPOD	Reports	Modify POD/POC report to include new UDF fields.	1.50	⁴

Notes:

Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.
Optional additional development.
Estimates are total number of days, and include specification and unit testing. They do not include project management, system testing, release or implementation costs.
Free of charge - listed here for completeness.

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1	REQ 343463 EBB Paper Solution Design	2.0	01/08/2017

B.2 Glossary

Term	Definition
Transport Terms
Audit Log	A log of events that have happened in the C-TL system. It could include information, error, debug or audit messages. Users are able to search for messages of a certain type, on a certain day and from a certain area of the system.
Activity	The activity at a stop. Usually loading or unloading.
Asset	A traceable DU; the item that is tracked during delivery and collection. This Asset has a type (e.g. Cage, Tet, etc).
Backloads	Orders that are placed on a pre-existing trip at the end of the trip before returning to the depot. They may be for customers other than the customer that is paying for the full trip and may result in a rebate to the customer, and a charge to the backload order’s customer.
Booking	A quantity of a single Product Type on a single DU Type to be delivered from one location to another on particular date but not at a particular time. These records are usually created by the Auto Summary process. These records are displayed in the main view on the Bookings form.
BUE	Base Unit Equivalent. Also RPE (Regular Pallet Equivalent). A means of comparing transport unit type size. For example, a Standard Pallet may equate to 1 BUE, a Large Board may equate to 2 BUEs, a carton may equate to 0.02 BUE. This is used to estimate volume and therefore capacity of vehicles within CTL-TMS. Typically this is based on a standard 1 cubic metre pallet.
C-ePOD	CALIDUS EPOD, OBS Logistics' app-enabled trip execution system.
C-Portal	CALIDUS Portal, OBS Logistics' web-enabled external access system. Also, any electronic internet-based system designed to access functionality for a particular purpose (for example, customer enquiries, supplier activity, track and trace, etc.).
Carrier	The carrier completing the trip. Can comprise any carrier configured in the system, but normally Home Fleet (usually a carrier per depot), 3rd-party carriers, supplier-/customer-own transport, own collection, etc.
Case	A Case of individual packets of a product e.g. a case of Cornflake packets.
Consolidating Centre	A depot that takes delivery of goods from several origins and consolidates them for trunking to out-bases (q.v.) or final delivery to destinations. See also Consolidation.
Consolidation	In execution terms, this is the act of taking several jobs and combining them into a single execution job. This can be by several criteria but is broadly defined as: Same Location consolidation, where the delivery/collection points are identical; Linked Location, where the deliver/collection points have been configured to be seen as the same point within CTL-TMS and; Manual (Ad Hoc) Consolidation, where the driver decides that two jobs should be delivered/collected at the same time.
Containerisation	The action of taking items and placing them inside another item for tracking purposes. See also Asset.
Cost	The cost to the operation of running the trip. The cost is generated from the carrier's rate card. Cost is generated from the trip.
Cross-Dock	Also a specific location at which product is exchanged.
CTL-TMS	CALIDUS Total Logistics TMS, OBS Logistics' Transport Management System.
CTM	This refers to the Carrier Trip Management module within C-TL.
Customer	In 3PL terms, the customer on behalf of which the transport is being operated.
Debrief	Comprises multiple parts: Stop debrief, where actual arrival and departure times against a trip are entered; Order debrief, where actual product and item quantities are entered; Driver/Trip debrief, where additional information is captured from the driver relating to the trip.
Demurrage; Detention	Any time spent loading, unloading or waiting that is outside contractual obligation in execution of a trip. This usually incurs additional charges.
Depot	Any location that schedules and controls transport.
Despatch	In transport terms, the process of loading and despatching items out of a depot. The process of loading and despatching may be controlled by C-MCS (q.v.). See also Loading.
DMS	Document Management Systems: Systems than manage the storage and viewing of (predominantly) scanned documents. Usually these systems also include some automation and indexing routines.
DOT	Delivery On Time - see OTIF.
Driver	Comprising drivers and crew assigned to a trip.
DU	Despatch Unit type e.g. Standard Roll Pallet.
Drivers Day	A schedule of work that a driver would undertake in a day including any rest periods and breaks.
EDI	Electronic Data Interchange - a mechanism by which 2 systems can communicate normally without user intervention.
ERP	Enterprise Resource Planning.
Fixed Route Template	A template in CTL-TMS that provides a series of timed slots into which orders will fit. This can be used to create fixed routes (q.v.) and also as a template for cross-docking and grouping similar orders together.
Fixed Route	In transport terms, a fixed route is a trip comprised of a series of fixed stops that are typically always visited. A CTL-TMS fixed route template (q.v.) can be used to create these.
Fuel Surcharge	An additional charge that may be applied to a Transport charge to reflect the increasing price of fuel.
Item	A single (usually unique) item for delivery/collection. A general terms, distinct from the TU of the deliverable item e.g. Pallet, Package, etc.
Load	CTL-TMS: A trip that encompasses just a vehicle-full of items, or one journey out and back to a depot.
Loading	In transport terms, the process of loading and despatching items out of a depot. The process of loading and despatching may be controlled by C-MCS (q.v.). See also Despatch.
Location	In CTL-TMS terms, a trip comprises visits or drops to many locations. A location can be of many different types.
Location Types	Usually one of: Depot, Customer, Delivery/Collection Location, Store, etc.
Location Zone	Also Zone; A grouping of included or excluded postal regions, zones or post codes. These are used in fixed route templates to determine whether orders from or to locations should be included in any trips created from them.
MCS	Mobile Control System
MSMQ	Microsoft Message Queue – a method of interfacing with another system using Microsoft based technology.
OBD	On-Board Diagnostics - an automotive term referring to a vehicle's self-diagnostic and reporting capabilities. Also CANbus.
ODBC	Open Database Connectivity – A method of communicating with an external database from a program outside of the database environment.
Optimisation	Route Building and Optimisation.
Order	An instruction to deliver specific quantities of one or more Product Types on particular DU types from one location to another at a particular time; a transport movement.
Order Item	An individual, usually unique item for collection or deliver.
Order Line	An order can be made up of different order lines (i.e. an order from one location to another can contain many lines such as 20 ambient pallets and 20 chilled pallets).
Order Status	The lifecycle of an order. Typically: Unscheduled; Scheduled (or Sheduled for Collection for cross-docked orders); Completed; Cancelled.
Order Type	This defines the category of the order, and is intrinsically linked to revenue and cost tariffs.
Organization	A part of an organization to which costs may be charged for accounting purposes. For CTL-TMS, this is used for accounting purposes, and also to generally configure the system.
OTIF	On Time In Full - Success metrics to measure successful completion of an order.
Out-base	A regional depot for collection and delivery in this local area. See also: RDC; ROC.
Payment	Monies paid by a cost centre to a third party such as a carrier.
Plan	A term used to describe the result from scheduling Orders onto Trips. The first set of Trips may be referred to as 'Plan A', with a subsequent, more accurate plan later in the day being referred to as 'Plan B'.
Post Schedule	The period after Orders have been scheduled in the Scheduling Program and then returned to C-TL. Any subsequent manipulation of these Orders would be Post Schedule manipulation.
Pre Schedule	The period before Orders have been scheduled in the Scheduling Program and then returned to C-TL. Any manipulation of these Orders would be Pre Schedule manipulation.
Product Item	Another term for a case or SKU.
Product Quantity	A quantity of a single Product Item or SKU to be delivered from one location to another on particular date but not at a particular time. These records are created by the inbound Bookings interface process. These records are displayed in the View Detail screen on the Bookings form.
Product Summary	Another term for Booking.
Product Type	The category that a Product Item, Case or SKU falls in to, usually associated with temperature e.g. FROZEN, PERISHABLE, AMBIENT.
Rate Card	See Tariffs.
Reason Codes	Of many types, defining exceptions: Adjustment, Non-conformance, Order.
Recalculate Distance and Times	A C-TL function that is applied to a trip. The function checks the properties of the trip to ensure that it meets the defined rules for a trip in respect of drive times and driver’s breaks.
RDC; ROC	Regional Distributions Centre and Regional Operating Centre. For transport operations with multiple depots, these depots are used for the final delivery.
Region	Geographical Region. Also, Postal Region.
Receipt	In transport terms, the process of receiving and uploading items into a depot. The process of receipt and unloading may be controlled by C-MCS (q.v.). See also Unloading.
Resource	General term grouping the executors of a trip. Carriers, Drivers, Crew, Tractors, Vehicles, Trailers.
Revenue	Monies received by an organisation from a third party such as a customer. Revenue is generated from an order, based on the customer's rate card.
Route	A route is a fixed route that is repeated. A Trip is a unique trip, which may be created from a route.
Schedule	The period to which a set of Orders and Trips will be assigned and scheduled. Usually, but not necessarily, a single day of the week so referred to as a Schedule Date that runs from 22:00 – 22:00 e.g. Schedule Date 11th July 2002 runs from 22:00 10-July-16 to 22:00 11-July-16.
Scheduled Order	An Order that has been scheduled onto a Trip by the scheduling process.
Service Levels; Service Types	Typically used to determine additional services for an order, or a quicker transport service.
Shunt	A trunk (q.v.) movement between depots using the trunk network, typically of a much shorter length than a trunk movement.
SKU	Stock Keeping Unit – another term for a Case.
Stop	See Trip Stop.
Stop Type	Along with the activity (q.v.), defines the stop use. Usually: SU - Start-up; PK - Pick-up; DL - Delivery; CL - Close-down.
Supplier	A supplier brings goods to your transport operation for delivery through the transport network. This is used when transport customers have relationships with suppliers for delivery, but the transport operation has a relationship with the customer.
Surcharges	Any changes applied to an invoice at invoice stage, rather than generated from the order or trip itself. Examples are: Fuel Surcharge/Rebate, Demurrage.
Tariffs	Rate Cards, forming the basis of generating trip/carrier costs and order revenue.
TI	Transport Instruction – another term for an Order.
TLM	Transport Logistics Manager.
TMS Ref	A unique transport movement ID, referring to a single transport movement request.
Tractor	The driver cab, pulling the trailer.
Trailer	The trailer carrying the goods. Can be several types.
Trans-Ship	The process of receiving, cross-docking and despatching items within a depot, usually within a single transaction. In this implementation, this is the process at the RDC (q.v.).
Transport	Any portion of an operation that deals with the execution of trips; the transport management office.
Trip	A routed Truck Load of goods. For example, a trip that begins at Depot 1 where an Order is loaded, then travels to Store 1 where the Order is unloaded. Typically the trip would then return to Depot 1 to terminate the trip.
Trip Manipulation	The manipulation of Scheduled Trips, whether it be to add a Carrier or to completely recalculate times on the Trip.
Trip Status	The lifecycle of a trip. Typically: Planned; Tendered; Accepted; En-Route; Completed.
Trip Stop	Stops within a trip at which specific activities would take place such as the loading or unloading of goods.
Trunk	A route between depots, transporting goods usually to be delivered from the destination depot, but any transfer of goods from the original receiving or originating depot in the network to the final delivery depot (the out-base).
TU	Transport Unit - box, tray, cage, tet, etc.; Also Asset, Asset Type.
TTM	CALIDUS Portal TTM; Track and Trace Module; OBS Logistics' application dedicated to tracking and tracing order events with inputs from several external systems.
Unloading	The process of receiving and uploading items into a depot. The process of receipt and unloading may be controlled by C-MCS (q.v.). See also Receiving.
Unscheduled Order	An Order that is yet to be scheduled onto a Trip by the scheduling process.
Vehicle	A generic term for a tractor (q.v.). This term may also be used to specifically identify a fixed tractor/trailer combination, for example a van, luton, etc.
Warehouse	This is a depot in CTL-TMS that is seen to be a warehouse, or origin and storage point for product for delivery.
Application Usage Terms
Check box	A box that when checked indicates that the item to the left is enabled. If unchecked, this is disabled or not in use.
DDL; Drop-down List	A series of pre-designated answers to a particular question on a device, rather than requiring the user to key the answer in in full.
Field	A single point of data entry on a screen, for example, a text box, drop-down list, check box, etc.
Look-up	A pop-up window specifically designed to allow searching for and selected pre-configured data.
Pop-up	A window (q.v.) that appears over the top of the open window.
Screen	The functional area, for example, "the Debrief screen". All functionality for this functional area is contained within this screen.
Window	The area of the browser used to display the screen and all contained entities.

B.3 Authorised By

Paul Griffiths	EBB Paper Representative	_____________________________
Matt Tipping	OBS Logistics Representative	_____________________________

Anonymous

Search

SDD 366558 EBB Paper CTL Solution Design

Introduction

Objective

Scope and Limitations

Client Requirements

Operational Information

Current Operational Processing

Overview of Solution

Static and Configuration Data

Customers

Sales Territory

Locations

Location Zones

Cross-dock routes

Loading/Unloading Rates

UOMs

Products

Salesperson

Order Types

Reason Codes

Resources

Carriers

Drivers

Vehicle and Trailer Types

Vehicles and Trailers

Orders

ERP-CTL Orders Interface

Orders Maintenance

Lot Numbers

Planning

Automatic Route Scheduling

Manual Planning

Optimisation

Resource Assignment

Execution

Loading

Vehicle Departure

Delivery/Collection

Retrieving the load

Starting jobs

Delivery process

Returns (collection) process

Job completion process

Customer Collection from Depot (Desk Collection)

Trunk Trips

Trailer Swaps

Trip and Order Debrief

Track and Trace

Reporting

Appendix A: Table of SCRs and Ballpark Estimates

Appendix B: Document References

Navigation

Wiki tools

Page tools

Categories