Security Plus

Security Plus C-TMS Solution Design

Solution Design

23rd July 2020 - 0.06
Reference: SDD 370536

Introduction

This document is the Security Plus C-TMS Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Security Plus through the sales process and through workshops with the customer at the head office and Stoke depot on 30/06 - 01/07/2020.

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

Scope and Limitations

General:

The changes will be made in the latest version of the C-TMS and C-ePOD systems.

Changes relating to information passed through to CALIDUS TMS from customer systems 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 will be required to the customer systems to achieve the functionality described in this document.

Relating to Requirements:

Site Keys will be managed by the existing customer systems and will be interfaced to CTMS as part of the orders - not as order lines (which will not work in most scenarios) but as equipment, which C-TMS will send to C-ePOD as a display-only item. This does not match the existing customer system, which allows scanning of keys.

C-ePOD will update Security Plus systems when jobs are completed, as well as updating C-TMS. Note that this C-ePOD update is now critical path: if C-ePOD fails to update for any reason, there is not an easy work-around/fall-back position. Essentially, this would require the following manual actions from the users:

Update CTMS orders with items collected manually (for charging purposes). This requires depot access to C-TMS and may incur additional licenses.
Update bags into Security Plus systems manually to trigger the onward processing.

The necessary changes to alleviate this risk through an interface through C-TMS have been identified and listed.

The suggested process for assignment of drivers/vehicles to trips will be completed within existing customer systems and will be interfaced to C-TMS, which introduces a delay to the loads reaching C-ePOD - this could be several minutes. This is primarily because CTMS is not to be used in the depots. Alternative processes have been suggested.

Value of the individual bags will not be stored in C-TMS or passed to C-ePOD. This is primarily because the solution does not need this, as C-ePOD is updating Security Plus system (to reduce development costs) and because the partial collect/delivery process (which would require this change) has not been included within the solution as a core development.

Load Start information (such as crew 1, crew 2, vehicle keys and smoke box) are data capture only on C-ePOD - they are not validated.

The system is not consolidating collections and deliveries onto a single job as the existing Security Plus systems do - this is not how either C-TMS or C-ePOD works and cannot be changed. This is not thought to be an issue. Note that adding functionality like this to C-TMS and C-ePOD will be costly to develop, and all efforts have been made to reduce additional costs and use existing system functionality.

Partial Collect/Delivery due to insurance liability has no work-around. The driver will not be shown when value exceeds a maximum amount, and the driver has no facility to confirm the partially delivered items on C-ePOD. The receipt printing change may be used for this, but this will require multiple additional changes (such as advising and storing value against order items and liability threshold against orders/customers), which are also not accounted for in the core solution.

Outer/Inner bag collection is constrained to a maximum number of bags. If Security Plus have more bags to put in than that constraint, there is no work-around. A change that does support any number of internal bags has been provided.

Costs and revenue will be calculated based on a provided delivery type when the order is created. It will be up to the Security Plus system to inform C-TMS when a collection or delivery is being done on the same trip together or whether this is being charged differently for a non-working day. A change to allow C-TMS to calculate these charges without requiring Security Plus systems to define specific delivery types has been provided.

The core solution does not include the ability for the customer systems to send cash processing service charges to CTMS. This is an optional change, to be confirmed if this is required by the customer.

Assumptions:

Assumptions have been made where the workshops have not clarified some areas. Should these assumptions not be correct, this may incur additional effort to resolve them.

Driver and Crew IDs are the ACC card barcodes.
The location barcode contains the location code itself.
The number of inner bags never exceeds a defined amount (e.g. 10).
Outer bags are unique DU types i.e. 503 - trunking sack or 509 - General Use Bag. Only these bags will allow entry of inner bags.

Client Requirements

The current solution comprises customer-developed bespoke systems as follows:

Contract Manager - Head office application to create customers and contracts, associated locations, manage status, etc
Depot Manager - depot-specific customer based operations. Can't create, just update.
Route Manager - creation/amendments of fixed routes.
Bag Capture - driver application. Driven entirely by BagTracker app.
Reporting - remains.
Finance - creation, amendment and issuing of invoices to customers.
Customer portals - Must remain, as they have stated that C-PORTAL TTM will not be provided to the customer (security concerns).
Bag Tracker - controls the mobile application, generates jobs (orders in C-TMS), uploads to device, keeps track of bags within the depot, runs reports. All functionality bar BlueTooth export to mobile application will remain, and will be extended to generate orders to C-TMS.
Money Manager - taking coin orders from customers on the phone, importing coin orders placed over the internet/FTP that are applicable to the depot and processing cash received in bags, if the customer requires that service.

New Solution

Objectives

Aim	Aims & Objectives	Achieved in Phase 1 via	Achieved in Phase 1.5 via
1	Allow Security Plus developers to integrate current system to the TMS for phase 1	Existing and new interfaces	As 1.0
2	Fixed route management and easy change as necessary to accommodate changes to existing contracts and new contract take on	Through Fixed Route maintenance and manual planning	As 1.0, plus PTV Route Optimised (strategic and tactical)
3	Automated billing and charging against adjustable rate cards	Through maintainable rate cards and tariffs per customer	As 1.0
4	Real time ePOD app and management to allow debrief of routes to affect billing meaning less manual intervention in billing	Through C-ePOD	As 1.0
5	Configurable ePOD work-flow and reason codes per Security Plus contract	Through C-ePOD UDF	As 1.0
6	Allowing for real time route execution view and full route E.T.A with Arrival departure board for depot use	Through CALIDUS Portal TTM	As 1.0
7	Configurable DVSA compliant app for vehicle checks/asset scanning/accident reporting	Through CALIDUS VEhub	As 1.0
8	Cost vs Revenue reporting for planned work and completed work	Through configurable data extracts in C-TMS	As 1.0
9	Planned vs Actual reporting	Through configurable data extracts in C-TMS and views through C-PORTAL	As 1.0
10	Access to exports, configurable reporting or database views/exports for reporting on financials or job performance by tools like power B.I or excel or other Security Plus reporting methods	Through configurable data extracts in C-TMS	As 1.0

Overview of Solution

The following systems will be used in the solution:

Contract Manager - Head office application to create customers and contracts, associated locations, manage status, etc
Depot Manager - depot-specific customer based operations. Can't create, just update.
Route Manager - creation/amendments of fixed routes.
Reporting - remains.
Finance - creation, amendment and issuing of invoices to customers.
Customer portals - Must remain, as they have stated that C-PORTAL TTM will not be provided to the customer (security concerns).
Bag Tracker - controls the mobile application, generates jobs (orders in C-TMS), uploads to device, keeps track of bags within the depot, runs reports. All functionality bar BlueTooth export to mobile application will remain, and will be extended to generate orders to and assign orders in C-TMS.
Money Manager - taking coin orders from customers on the phone, importing coin orders placed over the internet/FTP that are applicable to the depot and processing cash received in bags, if the customer requires that service.
CALIDUS ePOD - workload management, resourcing, job completion.
CALIDUS Portal TTM - track and trace, customer tracking alerts, completion report.
CALIDUS VEhub - vehicle defect reports, accident reports, equipment tracking.

Solution Schematic

Solution Detail

Standing Data

Standing/Static data will continue to be maintained in the current systems

These will pass data along to C-TMS when created, so that the requisite data can be created.

Including but not limited to:

Customers - when new customers are created (ACTIVE or INACTIVE), the customer information will be sent to C-TMS immediately.
Locations - when locations of the following types are created, the locations will be sent to C-TMS immediately.
- Depots.
- Banks.
- Branches.
- Customer addresses.
- Collection/Delivery addresses.
Equipment (e.g. site keys).

Note that many of the locations (i.e. collection and delivery locations) could be primarily created and maintained as part of the orders interface.

SCR-370536-1: Standing Data Interface - customer work

Note: This solution expects that keys (equipment) will be maintained by the existing Security Plus systems and will be interfaced as part of the orders. To achieve this, change is required.

SCR-370536-2: Equipment Interface

Note: Managing equipment more fully within C-TMS may also require additional change - this has been specified in later sections below.

Additionally, the following static data will be maintained within C-TMS:

Fixed Route Templates
Drivers
Vehicles
Driver shifts
Driver/vehicle availability
Transport Units (bag types in this case)
Carriers (i.e. one carrier per depot, linking all of the drivers and vehicles based at that depot).
Reason codes - these will be kept in line with current reason codes.

Potentially, other interfaces could be created for some of this standing data, making use of the existing interfaces within C-TMS:

SCR-370536-3: Additional Standing Data Interfaces - customer work

Locations

All locations of all types will be defined and maintained in this screen, for example:

Depots.
Banks.
Branches.
Customer addresses.
Collection/Delivery addresses.

Note: Managing equipment more fully within C-TMS may also require additional change.

Locations maintenance may be required to be modified to maintain a link between equipment and location, to maintain a relationship for the customer site keys. Many keys should be maintainable for one site, although this may be a single equipment entry.

SCR-370536-4:

Modify Locations and Vehicles to allow equipment to be assigned

Resources

Tractors/Vehicles

All vans used by all depots (and their depot/carrier assignment) will be maintained in this screen.

Note: Managing equipment more fully within C-TMS may also require additional change.

Vehicles maintenance may be required to be modified to maintain a link between equipment and vehicle, to maintain a relationship for the vehicle keys. This is specified in the change above.

Transport/Despatch Unit (DU) Types

Transport units (i.e. bags) will be created as part of the implementation, including but not limited to:

500 - 15K Bag
501 - Cheque Bag
502 - Float Bag
503 - Trunking Sack
504 - 20K Bag
505 - Car Park Vault
509 - General Use Bag
510 - Inner Cash Bag

A full list will be supplied by Security Plus.

Any other bag or unit types may be created if required, for example:

530 - Mixed Coin
Barrows
Coin bags

Equipment

Equipment will be used to track individual required items for deliveries and collections, primarily:

Site keys
Vault keys
Smoke boxes

Note: Managing equipment more fully within C-TMS may also require additional change, in this case , the type will define the equipment type, and a unique ID and barcode will be added to ID individual equipment.

SCR-370536-5:

Modify Equipment to add a unique ID and barcode

Order Well/Transport Jobs

All transport orders will be generated by the existing system and will be sent to C-TMS when created.

SCR-370536-6:

Orders interface - customer work

Note that only transport orders where the customer is ACTIVE will be sent to C-TMS.

The orders will consist of:

General order information e.g. references, customer, etc
The order type (delivery type) used to calculate rates.
Keys (equipment) required for the order.
Location and contact information:
- From location
- To location
An indication of the number of bags to be collected or delivered.
For deliveries, the specific bag information for the collection.
For coin deliveries, the amount of coin of each type to be delivered.
For orders that are related to cash processing, it is expected that the system will be modified to allow the import to add that service to the order when importing the order, so that the charge can be generated. This is a potential phase 1 deliverable - this is still being evaluated by Security Plus for feasibility, to be confirmed.

In order to receive services on the order from the external systems, change is required:

SCR-370536-7: Costs interface - customer work
SCR-370536-8: Costs interface - CTMS work

In order to receive keys (equipment) on the order, change is required:

SCR-370536-9: Orders interface - receive equipment.

Note that this solution has C-ePOD updating Security Plus systems with completed jobs and has no provision for partial collection/delivery (insurance liability), so the value of the cash bags is not required to be held within the core C-TMS database. Should this not be acceptable, further change may be required, as follows:

SCR-370536-10: Add value to order items

This change includes (but is not limited to):

Adding cash value to order items (possibly use units)
Importing cash value
Displaying cash value on Items screen

Note that the following would be dealt with by other changes below:

Sending to EPOD
Importing from EPOD

Transport Planning

Orders received into the system will be auto-planned through Fixed Routes.

Carrier (executing depot) will be set based on the fixed route provided.

Manual Planning

Trips created from fixed routes can be manually modified after they are created.

Note: This functionality requires access to the C-TMS screens. If this is required within the depot operations, additional C-TMS licenses must be purchased beyond those provisioned.

Automatic Trip Building and Optimisation

Note: This requires purchase (through additional monthly subscription charge) of a route optimisation package, such as PTV Route Optimiser or Paragon.

Trips can be optimised based on the orders that have been added to them through the fixed routes.

Trips can be created automatically based on resource availability and time/distance/weight/volume efficiency rather than using the fixed routes.

Note: This tactical planning functionality requires access to the C-TMS screens. If this is required within the depot operations, additional C-TMS licenses must be purchased beyond those provisioned.

The optimisation system may also be used for strategic planning (i.e. determining how a new contract's locations will fit within the existing route plans) without affecting tactical (i.e. real time) planning

Transport Resourcing

The trip will be resourced with the appropriate carrier when the trips are automatically created from fixed routes.

The standard process for resourcing and preparation for execution is as follows:

Trips that are ready for execution will be set to status ACCEPTED and have (at least) a driver assigned to them.

This will trigger the loads being sent to the C-ePOD system for execution.

Note: This functionality requires access to the C-TMS screens. If this is required within the depot operations, additional C-TMS licenses must be purchased beyond those provisioned.

In order to preserve existing functionality within the current Security Plus systems, it is expected that, when trips are created or modified in C-TMS (through the process of orders being automatically assigned to trips through the route, or from trips being manually modified by any C-TMS user, depot or otherwise), the created trips will be interfaced back to the existing Security Plus systems, showing the trips and stops (locations) with all of the planned orders.

Existing Security Plus systems will then import those trips back in and update their existing data to show the planned trips (the 900 routes) - any orders not planned in this way will be considered on a 999 route (unplanned).

To achieve this, change is required:

SCR-370536-11: Export of created/updated trips
SCR-370536-12: Import of created/updated trips into existing SPL system data - customer work.

Note: It is requested that the C-TMS planning system be kept separate from the depot operations, for various reasons. In that case, there will be no capability within the depots to manually set trips to ACCEPTED.

In that case, the following processes have been proposed regarding transport resourcing.

Process 1:

When trips are created or modified in C-TMS (through the process of orders being automatically assigned to trips through the route, or from trips being manually modified by any C-TMS user, depot or otherwise), the created trips will be interfaced back to the existing Security Plus systems, showing the trips and stops (locations) with all of the planned orders.

Existing Security Plus systems will then import those trips back in and update their existing data to show the planned trips (the 900 routes) - any orders not planned in this way will be considered on a 999 route (unplanned).

When the users of the existing systems assign a trip to a vehicle or user, this information will be sent to CTMS. This will trigger resource assignment, setting the trip to ACCEPTED status and updating C-ePOD with the trips.

This will require the following development effort in both C-TMS and customer systems:

SCR-370536-13: Interface to assign resource to trips - customer work
SCR-370536-14: Interface to assign resource to trips

Note: Given the nature of the interface, it is likely that this process will introduce a delay in the trips and jobs being available on the device. This could be up to several minutes.

Process 2:

Trips will continue to be added to up until a cut-off time for that fixed route.

A process will be created to set the trip to ACCEPTED status automatically within C-TMS.

The trips will then be sent to EPOD.

The depot users will use the C-ePOD Admin console to assign trips (loads) to drivers or vehicles.

When the trip is accepted and started on the device, C-TMS will be updated with the driver and vehicle selected.

To achieve this process, change will be required:

SCR-370536-15: Automatic process to accept trips based on the cut-off time.

Transport Execution

Note: This proposed solution may require some changes to the data sent from C-TMS to C-ePOD, depending on many of the optional changes that have been documented here. In order to achieve some of these, change is required. The following changes are in place to capture these changes required, and are place-holders only - this will be re-estimated once decisions are made over the functionality required.

Changes are required to the data sent to and/or stored by C-ePOD.

Including (but not limited to):

Keys added as items for loading (if scanning keys)
Summary of individual equipment (if C-TMS retains control)
Route sent to C-ePOD (for resourcing within C-ePOD)
Crew added to Load (if validating crew).
Coin sent over as container and contained products.
Value of items
Insurance liability threshold.
Vehicle Keys (if validating vehicle keys)
Smoke Box (if validating smoke box)
Driver ACC card (if different to user iD)

SCR-370536-16:

EPOD Interface - send additional information

SCR-370536-17:

Store additional load/driver/vehicle information

Jobs will be completed through the C-ePOD mobile device application.

This will be styled for the following:

The following text will be replaced, to make the device more suitable to this operation:
- Products - Coin (or Coin/Keys)
- Containers - Items
- Code 1 - Outer Bag (TBC)
- Code 2 - Value
- Ad Hoc - Ad Hoc Bags
The customer log will be displayed.
The container (items/bags) list will be configured to display only required information, and perhaps value if provided.
The product (coin/keys) list will be configured to display only relevant information.

This will be done as part of the implementation of the system, when completing other required changes for the operation (for example, the POD/POC formats).

Note: Screen-shots of the application within this document have been sourced using several jobs worked through during the design and production of this solution. They are based on a standard style that has not been configured yet as stated above. They are provided to show an indication of the flow of the process and are not intended as a indication of the final look and feel of the implemented application.

The following are selected screen-shots of the C-ePOD Admin system, focussing on load and job visibility, assuming the core processes as outlined in the following sections.

Loads.
Load details and assignment.
Load start details.
Jobs on a load.
Job details.
Job keys and coins.
Containers (bags).
Container details.
Collected bag details.

Login

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

It is expected that either the user name or password will be set to the user's ACC card.

Note: If this app is run on a WEBFLEET device, and the user is logged into WEBFLEET, the device may automatically default the user and vehicle and log in for the user.

Login

Workload Start

The device will automatically download the workload. All of the jobs will be displayed, and the user will have the facility of seeing further information about the load through a provided Information button, and to accept the load.

The user will start the load with the provided button, where they will be asked to capture additional information.

ACC Card (Authorised Contractors Card) Note: This is not expected to be captured here, as this will have been captured during the login process.
Crew 1 - ID card 1 - barcode.
Crew 2 - ID card 2 - barcode.
Vehicle Keys - barcode.
Smoke Box - barcode

Note: This data entry is not validated as being correct. So, invalid barcodes can be scanned and vehicle keys are not validated against the vehicle selected. If this requires validation, further development will be required. It is expected that this will be captured in the general data changes referred to in the top of this Transport Execution section.

Accepting the load
Entering additional details

Loading Vehicle

Job List

The user will select the Loading job from job list.

Job Details

Loading jobs must be completed before all other jobs.

Note: An ongoing product fix is being undertaken to ensure that the user does not have to state that they have both started and arrived at loading jobs, as this is not required as part of the process.

Start Job requires scanning of location barcode, configured through pre-job UDF. This will be validated that it matches the value expected (the location code itself) and will allow keyboard override (for the case where barcodes are damaged).

Note: It is assumed that the location barcode contains the location code itself, rather than a unique reference assigned to the location. If this is not the case, additional change is required.

Note: The solution specified here will display the keys that are required to be collected in the job instructions, but does not allow for the users to scan the keys. If this is required, further development will be required. It is expected that this will be captured in the general data changes referred to in the top of this Transport Execution section.

Loading details
Loading Instructions
Location Confirmation

Loading of Items

The job information will be displayed. If there are multiple jobs, the user will be able to move between them to show the information of each job being loaded as part of this consolidated loading process.

The job information tab will display any keys required for that particular job, as well as any of the coin bags required for that job.

If there are multiple jobs being loaded for that load, all of the items for all of the jobs will be displayed on a list of items to be scanned.

The user will scan all advised items to be loaded for delivery.

Each item scanned is removed from the list.

Coin will be loaded as now, counted from either the documentation for the jobs being loaded, or from the display of coin required on the job screen.

Note: There is a potential to allow coin to be displayed as a separate tab, showing the coin to be loaded. In this case, the process will show a list of all of the coin bags required to be loaded for every coin order to be delivered. They will not be consolidated. The user will be able to count all of the coin bags required.

The user will be required to confirm that all bags are loaded. The user will be able to confirm whether items have not been loaded with a reason code.

Note: This approach will require a product fix to be completed to show all coin for each job separately. It may also (based on requirements) be necessary to introduce a development to consolidate product (coin) quantities for loading or unloading. Regardless, this also requires development of the interface to C-ePOD from C-TMS for specifying the coin as product (included in a change later in this document) and also has an impact on how the coin is sent to C-TMS by the Security Plus existing systems. For the purposes of this solution, it is assumed that displaying the coin for loading, unloading and delivery is sufficient, as it matches the existing process.

Items will be able to be ad-hoc scanned onto the vehicle if desired. The process will allow the user to scan the item. The process will request the user to confirm the type (from a drop-down list) and select the destination.

Loading Details
Items to scan
Item Information
Items removed when scanned

Completion of Loading

When all items are scanned onto the vehicle, the user will confirm and will be prompted to complete the loading.

The process here is configurable, but could request driver signature, data entry, display of terms and conditions, photo capture, as required.

The signature process for the driver and customer displays the actual scanned or confirmed items on this page.

Containers (loaded cash bags) will be shown.

Note: If coin bags are specified as a confirmable product, they will also be shown here. If they are not confirmable product, they will not be displayed here. The same is true of keys.

If receipt printing is required, this will be added to this signature process.

SCR-370536-18:

Receipt Printing

Driver Signature and T&Cs
Jobs
Scanned Items
Coin Bags (if confirmable)
Job Photos

Delivery Process

Note: C-ePOD separates collections and deliveries into separate jobs. Deliveries are always completed first.

Job List

The user will select the next job from the list of jobs to be delivered from the job list.

Delivery jobs at a location will always be shown before the collection jobs.

Next delivery job

Job Details

The process will display the contact and job information:

Name
Address
Contact information
Phone (1 and 2)
Customer Key information
Coin bags required
Summary of the number of items to deliver by type.
Job/location Instructions - these must be viewed before the job can be started.

The user will start the job - this begins the tracking process against the user (i.e. job in progress).

The user will be able to use any navigation application on the device to navigate to the location. Note that the the device will navigate to the identified GPS point against the location, which may be changed in the C-ePOD Admin console.

When the user arrives at the destination, they will click Job Arrival.

This will then prompt the user to scan the location barcode, configured through pre-job UDF. This will be validated that it matches the value expected (the location code itself) and will allow keyboard override (for the case where barcodes are damaged).

Note: It is assumed that the location barcode contains the location code itself, rather than a unique reference assigned to the location. If this is not the case, additional change is required.

Note: The solution specified here will display the keys that are required to be collected in the job instructions, but does not allow for the users to scan the keys. If this is required, further development will be required. It is expected that this will be captured in the general data changes referred to in the top of this Transport Execution section.

Start job
Arrive job

Delivery of Items

Note: This solution has no provision for partial collection/delivery (insurance liability). Should this be required, a solution must be developed - the following change is a ballpark of what this may cost to develop.

SCR-370536-19:

Partial Collection/Delivery

Namely this change will consider insurance liability maximum value, therefore identifying value the value of the bags being delivered/collected, the value limit per customer/location and potentially showing a pop-up summary on the device or printing a receipt.

Note also that this may require additional changes to be brought into scope, as listed elsewhere.

The job information will be displayed.

The job information tab will display any keys required for that job, as well as any of the coin bags required for that job.

The user will scan all items to be delivered.

Each item scanned is removed from the list.

Coin will be delivered as now, counted from either the documentation for the job being delivered, or from the display of coin required on the screen.

Note: There is a potential to allow coin to be displayed as a separate tab, showing the coin to be delivered. In this case, the process will show a list of all of the coin bags required to be delivered for the job. The user will be able to count all of the coin bags required.

The user will be required to confirm that all bags are delivered. The user will be able to confirm whether items have not been delivered with a reason code.

Note: This is dependent on the prior loading of coin bags as scannable items.

Job details
List of bags
Scan removed from list
Coin bags (if confirmable)

Completion of Delivery

When all items are scanned out of the vehicle, the user will confirm and will be prompted to complete the delivery.

The process here is configurable, but could request customer or driver signature, data entry, display of terms and conditions, photo capture, as required.

The signature process for the driver and customer displays the actual scanned or confirmed items on this page. Containers (bags) will be shown.

Note: If coin bags are specified as a confirmable product, they will also be shown here. If they are not confirmable product, they will not be displayed here. The same is true of keys.

If receipt printing is required, this will be added to this signature process.

Signature and T&Cs
List of bags
Coin bags (if confirmable)
Driver Signature
Job photos

Collection Process

Note: C-ePOD separates collections and deliveries into separate jobs. Deliveries are always completed first. If there are collections at this location, they will be automatically started for the user.

Note: An ongoing product fix is being undertaken to ensure that the user does not have to state that they have both started and arrived at collection jobs that automatically follow on from delivery jobs, as this is not required as part of the process.

If the user exits, they can choose the collection from the job list to return to the job details screen.

If there is no planned collection at this location, the user can add an unplanned collection - through configuration, they can be automatically prompted to do this, or they can choose to do this from the job list, by choosing the option "Unplanned Ad Hoc Collection". The actual process of an unplanned or planned collection will be the same in all cases, as even planned collections will not plan the individual items to be collected.

Job Details

The process will display the contact and job information:

Name
Address
Contact information
Phone (1 and 2)
Customer Key information
Summary of the number of items to collect by type.
Job/location Instructions - these must be viewed before the job can be started.

The user will start the job - this begins the tracking process against the user (i.e. job in progress).

The user will be able to use any navigation application on the device to navigate to the location. Note that the the device will navigate to the identified GPS point against the location, which may be changed in the C-ePOD Admin console.

When the user arrives at the destination, they will click Job Arrival.

This will then prompt the user to scan the location barcode, configured through pre-job UDF. This will be validated that it matches the value expected (the location code itself) and will allow keyboard override (for the case where barcodes are damaged).

Note: It is assumed that the location barcode contains the location code itself, rather than a unique reference assigned to the location. If this is not the case, additional change is required.

Note: The solution specified here will display the keys that are required to be collected in the job instructions, but does not allow for the users to scan the keys. If this is required, further development will be required. It is expected that this will be captured in the general data changes referred to in the top of this Transport Execution section.

Job Details

Collection of Items

Note: This solution has no provision for partial collection/delivery (insurance liability). Should this be required, a solution must be developed, as described earlier in this document.

Namely this change will consider insurance liability maximum value, therefore identifying value the value of the bags being delivered/collected, the value limit per customer/location and potentially showing a pop-up summary on the device or printing a receipt.

Note also that this may require additional changes to be brought into scope, as listed elsewhere.

The user will scan an item to be collected.

The process will request the user to confirm the type (from a drop-down list). The use must select the DU type. If this is to be defaulted for the customer from the first characters of the bag ID, this requires change to the application.

SCR-370536-20:

Custom DU type default

Depending on the bag type, the device will prompt for more information. This will be achieved by UDF configuration against the specific DU types of the bags, selected previously.

SCR-370536-21:

Container UDF by Container Type

For Coin bags, the app will prompt for the following:

£2 - count of full bags. None are required to be entered.
£1.
50p.
20p.
10p.
5p.
2p.
1p.

For Vault collections, the app will prompt for the following:

Collection Point ID - required.
Vault into machine - required.
Barrow - required.
Value - required.
Manual Entry - a check box, can be left unchecked (the default).

For Outer bags, the app will prompt for up to a fixed number of inner bag IDs.

For cash, cheque or float bags, the app will prompt for the cash value.

Note: For outer/inner bags, the proposed process may not be suitable or acceptable. An alternative process of scanning as many bag IDs as required will require additional development.

SCR-370536-22:

Outer/Inner Bag Collection

Note that other solutions have been considered, but are either not suitable for the operation (requiring scanning of inner bag when unloading) or increased cost. Details can be provided on these alternatives if required.

As each item is scanned and entered, the device will display the item information on the list.

The user will be able to remove item that have been scanned, and will be able to view and amend the additional information entered against the item.

The user will scan all of the items to be collected.

Details and keys
Scan Bag and enter type
Enter value
Enter coin bags
Scan Inner Bags
Vault details
List of all scanned bags

Completion of Collection

When all items are scanned at the site, the user will confirm and will be prompted to complete the collection.

The process here is configurable, but could request customer or driver signature, data entry, display of terms and conditions, photo capture, as required.

The signature process for the driver and customer displays the actual scanned or confirmed items on this page.

Containers (bags) will be shown.

The app will be changed as part of an in progress product fix to display the data captured against each bag (including the value) by clicking the bag on the list.

If receipt printing is required, this will be added to this signature process.

Signature and T&Cs
List of bags
Bag details

Unloading process

At the bottom of the job list, the device will show a single consolidated unloading "Return to Base" job. This will be completed when all other jobs on that device are completed.

Note: If the run requires that the user returns to base several times on a run, there may be several unloading jobs - these will be positioned in the correct point in the job list for the user to execute.

Job List

The user will select the unloading job from the job list.

Unloading jobs

Unloading Details

The process will display the contact and job information:

Name
Address
Contact information
Phone (1 and 2)
Job/location Instructions - these must be viewed before the job can be started.

The user will not be able to start the unloading jobs until the collection jobs are completed.

The user will start the jobs - this begins the tracking process against the user (i.e. job in progress).

The user will be able to use any navigation application on the device to navigate to the location. Note that the the device will navigate to the identified GPS point against the location, which may be changed in the C-ePOD Admin console.

When the user arrives at the destination, they will click Job Arrival.

This will then prompt the user to scan the location barcode, configured through pre-job UDF. This will be validated that it matches the value expected (the location code itself) and will allow keyboard override (for the case where barcodes are damaged).

Note: It is assumed that the location barcode contains the location code itself, rather than a unique reference assigned to the location. If this is not the case, additional change is required.

Unloading details

Unloading of Items

The job information will be displayed. If there are multiple jobs, the user will be able to move between them to show the information of each job being unloaded as part of this consolidated unloading process.

The user will scan all advised items to be unloaded. This will include all items collected at the locations, and also any bags that have been marked as not delivered at location, and the bags for jobs that were cancelled.

The user will scan all items to be unloaded.

Each item scanned is removed from the list.

Coin will have been collected in a coin sack containing the coin bags and therefore will be unloaded as any other cash bag.

Unloading details
List of bags

Completion of Unloading

When all items are scanned out of the vehicle, the user will confirm and will be prompted to complete the unloading.

The process here is configurable, but could request driver signature, data entry, display of terms and conditions, photo capture, as required.

The signature process for the driver can display the actual scanned or confirmed items on this page.

Containers (bags) will be shown.

If receipt printing is required, this will be added to this signature process.

Driver Signature

Completed Jobs

As each job is completed, the completion information is recorded in the C-ePOD server and sent to C-TMS, which then debriefs the orders and trips.

This solution proposes that C-ePOD will also send that update of jobs completed out to the Security Plus systems to confirm the jobs completed.

However, if it is decided that C-TMS must pass this information on instead (to account for manual debriefing or a fall-back process in case of failure) then several changes will be required in this area:

SCR-370536-23: Create items for outer/inner bag and coin collection
SCR-370536-24: Store UDF detail entered for export

This will be exported to external systems through a standard interface, which may require modification.

SCR-370536-25:

Additional information on export

The information will be imported by Security Plus existing systems, for onward processing.

SCR-370536-26:

Import order debrief information

The completed job information is used by C-ePOD to generate Proof of Delivery and Proof of Collection reports, which can then be automatically emailed to the customer.

It is expected that there will need to be two formats (one for collections and one for deliveries) that will need to be created for the operation. Further, some work may be needed to support some of the data captured above, such as vault and coin bag information.

SCR-370536-27:

POD/POC Formats

Vehicle Checking and Accident Reporting

The driver will use the C-VEhub application predominantly for:

Vehicle defect checks at the start and/or end of a day or trip.
Accident reporting.
Tracking scans

Note: CALIDUS VEhub is a stand-alone system and is available to be configured for the customer's use when required by the customer

Vehicle checks can be configured with customizable checks - core vehicle checks can be enabled or disabled, and custom checks can be added. Multiple configurations can be held, which the driver can selected based on the vehicle types.

Checks include general details, check boxes, taking images associated with checks and a signature at completion.

Accident reports allows drivers to capture the necessary details of any accidents or incidents while on runs. Details of involved participants can be captured, along with images of any damage or incident.

Tracking scans allow drivers to track resource through the scan of any barcode.

This facility of tracking any scanned items is stand-alone, outside of any other CALIDUS system control.

Checks, accident reports and tracking scans are stored with location tags and can be reported within the C-VEhub Admin system.

The Admin system allows users to rectify defects, provide resolution notes and receive alerts based on configurable criteria.

As part of this project, C-VEhub will be created for each depot to access their vehicles and the data entered through the mobile application. C-VEhub Admin access will be provided for every branch.

The drivers will be provided a user-name and password. The users and their passwords must be configured within C-VEhub. It is recommended that these user-names and passwords match between C-ePOD and C-VEhub.

It is expected that C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot.

The C-VEhub Administration system will be used in this operation for visibility of the checks and reports made through the device application, and to control the configuration of alerts.

The Dashboard itself may be used to visualise where equipment was last located. So, the user may select what is being tracked (Vehicles, Vehicles with overdue checks or Tracked Scans) and refresh the map to show the items. The map will show the items being tracked with labels that may be clicked for more information.

Admin Screens:

Main Menu
Checks - List
Checks - Details
Checks - Rectification
Accidents - List
Accidents - Details
Accidents - Details

Device Screens:

Main Menu
Vehicle Checks - Details
Vehicle Checks - Checks
Signature Capture
Accident Report - Details
Accident Report - Details

Track and Trace

CALIDUS Portal provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:

End customers - end customers can access tracking information about a single consignment through a link - no login is required.
Contracts/Owners - trusted customers and internal staff can access the system through a provided user name and password to get at detailed information. Restrictions on the log-in will ensure that they can only see the data that pertains to them.
Customer Service Queries - internal staff can access detailed information about consignments from within C-Portal from anywhere, and view, report on and send the information onto the querying party without accessing additional systems.
Transport Office - transport staff can use departure boards (and others) to view the now/next transport tasks and prepare pro-actively for them. These views are typically designed for use on large screens or projectors.

CALIDUS Portal is kept updated at all times by CALIDUS TMS of all states of the loads and jobs, for example:

The trip itself.
The order itself.
The sequence of the order on the trip
When an order is in transit.
When an order is collected and/or delivered.
When an order is cancelled.

The messages identify any changes to quantities and reasons for these changes at all stages.

The following is a brief description of functionality available within CALIDUS Portal.

This Trip Order Enquiry screen allows CALIDUS Portal users to track the status and events held against trips and orders, selecting them through a large variety of parameters.

The screens display matching trips or orders, which can then be drilled-down into to see additional details.

Order Enquiry Parameters.
Order Enquiry Results.
Trip Enquiry Parameters.
Trip Enquiry Results.
Order and Event Details.
Order Info Details.
Order Route Details.
Trip Details.

CALIDUS Portal supports several airport-style screens:

Arrive/Depart screen.
Order Status screen.

Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries. The recommended screen is the Order Status screen.

The screen allows the user to drill-down or expand on data to get more details, through pop-ups or further details screens.

Order Status Screen.
Order Status Parameters.

The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.

The system also supports sending track and trace links to customers with ETA and full vehicle track to door, through a customer tracking gateway.

Enter Consignment.
Consignment Tracking.

If provided to CALIDUS Portal, this screen can also display the ETA at the location of the order being checked, the signature and a link to view the POD report, when the order being checked is marked as Delivered.

CALIDUS Portal TTM also allows reporting through data extracts.

Each enquiry screen allows exporting of data, usually at most of the following levels (depending on the query)

Trip - trip information.
Trip/Stop - trip/stop information.
Trip/Order - trip/stop/order information.
Order - order header information.
Order Detail - order header / order detail information.
Pallet - order pallet information.

Financial Processing

Trip Cost, Order Cost and Order Revenue

Order revenue will be automatically calculated per order, based on planned or actual quantities and any additional services posted against the orders. This will be generated based on a rate card assigned through a contract between the carrier and the cost centre.

Trip cost will be automatically calculated per trip, based on planned or actual distance and time, fuel and additional costs against the trips. This will be generated based on a rate card assigned through a contract between the customer and the cost centre.

Order revenue will be assigned to the trips and carriers that fulfilled the orders, to determine margin per trip.

Trip cost will be apportioned to the orders on the trips, in order to determine margin per order.

Costs can be exported through the invoicing module of the system, which will generate CSV backing sheets of all charge lines generated against the orders.

The following rates are most common:

Standard collection/delivery rate e.g. £15
Different rates on non-working days
Additional collection/delivery at that location discount e.g. £10 discount.
Excess bag surcharge e.g. £5

Rates will be configured based on delivery type, as well as the contract level (cost-centre/carrier, cost-centre/customer), with breakpoints, rates and levels defined per rate card.

The delivery type will be sent through on the orders, determined by Security Plus systems.

For example, standard collection and delivery might be sent through as "STANDARD" delivery type.

Where there is a collection and delivery on the same trip, the first order would be sent through as "STANDARD" and all subsequent orders might be sent through as "ADD" delivery type.

Where these collections are to be scheduled on a Sunday at additional cost, they might be sent through as "EXCESS" or "EXCESS_ADD".

As an optional change, C-TMS charging can be modified to calculate the following revenues based on fixed cost conditions:

Subsequent Delivery surcharge - whether orders are being delivered and collected on the same stop. This would calculate whether the subsequent stop is the same location, and therefore apply the delivery charge.
Day of the week surcharge - if the delivery of collection date matches the day of the week, this charge is added.
Non-working day surcharge - if the delivery or collection date matches a non-working day (based on the country non-working days and exception calendar), this charge is added

Example charges would be set as follows:

Standard Delivery Charge: £15, no conditions.
Subsequent Delivery surcharge: -£10
Day of the week surcharge: £5, on Saturdays
Non-working day surcharge: £10

Examples:

Delivering to location A is stop 2, followed by collection at the same location on stop 3.

Both orders would be charged as £15 delivery charge. The subsequent order would receive a £10 discount, so the full charge would be £5.

Delivering on a Saturday would we charged as £15 delivery charge, plus a £5 surcharge for delivery on a Saturday, so £20 in total.

Delivering on Bank Holiday Monday would be charged as £15 delivery charge, plus a £10 surcharge for delivery on a non-working day, so £25 in total.

SCR-370536-28:

Additional charge rate conditions.

Note: Typically, rates will be recalculated when the order or trip status changes. So, if an order is removed from a trip, the subsequent order charge will not immediately be recalculated.

This can be achieved manually, by re-validating the whole trip, but will automatically be recalculated when the trip is moved to ACCEPTED, EN-ROUTE or COMPLETE status.

Costs and revenue per order are expected to be completed and imported into the existing financial package used by Security Plus. That package will generate the invoices to the customer.

SCR-370536-29:

Import invoice charges

One of the standard C-TMS backing sheet formats will be used to import the charges, or a bespoke export can be generated through the included Oracle Reporting Suite. It is not expected that any development in C-TMS is required in this area.

Appendix A: Table of SCRs and Ballpark Estimates

Appendix A1: Core Changes

The changes listed in this section have been confirmed to be required to be developed in order to provide the described core solution in this document.

SCR#	System	Area	Description	Estimate (Days)	Notes
1	SPL	Interface	Standing Data Interface - customer work	0.00	²
3	SPL	Interface	Additional Standing Data Interfaces - customer work	0.00	²
6	SPL	Interface	Orders interface - customer work	0.00	²
9	TMS	Interface	Orders interface - receive equipment	8.50
11	TMS	Interface	Export of created/updated trips	2.75
12	SPL	Interface	Import of created/updated trips into existing SPL system data - customer work.	0.00	²
13	SPL	Interface	Interface to assign resource to trips - customer work	0.00	²
14	TMS	Interface	Interface to assign resource to trips	3.50
16	EPOD/CTMS	Interface	EPOD Interface - send additional information	8.50
21	EPOD	Server/Device	Container UDF by Container Type	7.00
26	SPL	Interface	Import order debrief information	0.00	²
27	SPL	Interface	POD/POC Formats	3.50
29	SPL	Interface	Import invoice charges	0.00	²

Note:

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.
These changes identify customer work required - they are 0 development for CALIDUS systems.

Appendix A2: Optional Changes

The changes listed in this section have been determined to be outside the core solution. These changes can be entered into at additional cost to the customer.

SCR#	System	Area	Description	Estimate (Days)	Notes
2	TMS	Interface	Equipment Interface	8.50
4	TMS	Equipment	Modify Locations and Vehicles to allow equipment to be assigned	3.50
5	TMS	Equipment	Modify Equipment to add a unique ID and barcode	7.00
7	SPL	Interface	Costs interface - customer work	0.00	²
8	TMS	Interface	Costs interface - CTMS work	3.50
10	TMS/EPOD	Order	Add value to order items	8.50
15	TMS	Process	Automatic process to accept trips based on the cut-off time.	3.50
17	EPOD/CTMS		Store additional load/driver/vehicle information	8.50
18	EPOD	Printing	Receipt Printing	8.50
19	EPOD	Col/Del	Partial Collection/Delivery	8.50
20	EPOD	Device	Custom DU type default	2.75
22	EPOD	Collection	Outer/Inner Bag Collection	13.75
23	TMS	Interface	Create items for outer/inner bag and coin collection	5.25
24	TMS	Interface	Store UDF detail entered for export	5.25
25	TMS	Interface	Additional information on export	3.50
28	TMS	Finance	Additional charge rate conditions	0.00	²

Appendix A3: Product Changes/Fixes

During the production of this solution, several fixes and enhancements were identified as potentially required, based on the potential solutions outlined here. The following is a list of those defined changes and fixes. Note: Product fixes will be completed before delivery of the software, if that fix is required for the selected solution. Product change is not guaranteed to be included or available at any stage - product change is governed solely by OBS Logistics Limited.

SCR#	System	Area	Description	Estimate (Days)	Notes
1	EPOD	Device	Consolidated Products Development	13.75	¹
2	EPOD	Device	Consolidated Products - fix visibility of loose products container entry	3.50
3	EPOD	Device	Auto-start job - continue job	1.75
4	EPOD	Device	Allow Containers to be clicked to show details, including UDF (read only)	5.25
5	EPOD	Device	Do not display Arrive Job for Loading jobs	1.00
6	EPOD	Device	Fix issue displaying Job UDF per job on the Collection/Delivery Info tab.	1.75
7	EPOD	Admin	Fix issue displaying received Job UDF on the Job Details screen pop-up.	1.75

Note:

This is a product change.

APPENDIX B: DOCUMENT HISTORY

References

Ref No	Document Title & ID	Version	Date
1

Glossary

Term or Acronym	Meaning
Ad Hoc Collection	Ad Hoc Collections are collections at a consignee or other point, where the actual items to be collected have not been defined, allowing for a free-form scanning of items.
AI	In barcode terms, an Application Identifier; some pre-defined characters in a barcode that define the data content rather than the format.
Asset	A traceable DU; the item that is tracked during delivery and collection. This Asset has a type (e.g. Cage, Tet, etc).
Audit Log	A log of events that have happened in the C-TMS 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.
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.
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 outbases (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 C-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 Centre	A part of an organization to which costs may be charged for accounting purposes. For C-TMS, this is used for accounting purposes, and also to generally configure the system.
C-Portal	CALIDUS Portal, Aptean's web-enabled external access system to the Calidus systems. Also, any electronic internet-based system designed to access functionality for a particular purpose (for example, customer enquiries, supplier activity, track and trace, etc.)
Cross-Dock	Also a specific location at which product is exchanged.
C-ePOD; EPOD, APOD	Electronic Proof of Delivery. The Aptean EPOD system is CALIDUS ePOD or Aptean POD.
C-TMS	CALIDUS TMS, Aptean's Transport Management System.
CSB	This refers to Carrier Self Billing, the process that C-TMS uses to produce and send invoices to carriers.
Customer	In 3PL terms, the customer on behalf of which the transport is being operated.
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.
Debrief	Comprises 3 parts: Trip debrief, where general trip notes and vehicle information is captured; 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.
Delivery Types	This defines the category of the order, and is intrinsically linked to revenue and cost tariffs.
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. In this implementation, the process of loading and despatching is predominantly 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.
Drivers Day	A schedule of work that a driver would undertake in a day including any rest periods and breaks.
Drop	A stop on a trip.
DU	Distribution/Despatch/Deliverable Unit - box, tray, cage, tet, etc.; Also Asset, Asset Type.
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 C-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 C-TMS fixed route template (q.v.) can be used to create these.
Fixed Schedule	An order that occurs at a fixed time. Differing from the above, the order will be created in the schedule; Also Milk Run.
Fuel Surcharge	An additional charge that may be applied to a Transport charge to reflect the increasing price of fuel.
Isotrak	A third party software package that allows users to be informed of the whereabouts of their vehicles using GPS technology. Interfaces with C-TMS in order to provide ‘actuals’ information for trips (i.e. the time a trip arrived at a stop and the amount of pallets that were delivered).
Item	A single item for delivery/collection.
Load	C-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. In this implementation, the process of loading and despatching is predominantly controlled by C-MCS (q.v.). See also Despatch.
Location	In C-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.
MCS	Mobile Control System
OBD	On-Board Diagnostics - an automotive term referring to a vehicle's self-diagnostic and reporting capabilities. Also CANbus.
OMS Ref	A unique transport movement ID, referring to a single transport movement request.
OPS13	Vehicle Checks; Defect Reporting
Optimisation	Route Building and Optimisation
Order	Equiv: OMS Ref; a transport movement.
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, usually UNSCHEDULED->SCHED-COLL->SCHEDULED->DELIVERED/FAILED/CANCELLED.
OTIF	On Time In Full - Metrics to measure successful collection or delivery.
Outbase	A depot whose purpose is to deliver to final delivery destination within a geographically-restricted subsection of the whole catchment area; also ROC, RDC.
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-TMS. 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-TMS. 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
Reason Codes	Of many types: Adjustment, Non-conformance, Order.
Recalculate Distance and Times	A C-TMS 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.
Receipt	In transport terms, the process of receiving and uploading items into a depot. In this implementation, the process of receipt and unloading is predominantly controlled by C-MCS (q.v.). See also Unloading.
Region	Geographical Region. Also, Postal Region. Regions are allocated to Depots and are used to determine ownership of a particular Order.
Resources	Drivers, Crew, Tractors, Vehicles, Trailers
Revenue	Monies received by a cost centre from a third party such as a customer.
Route	A route is a fixed route that is repeated. A Trip is a unique trip, which may be created from a route.
ROC	Regional Operating Centre; a depot whose purpose is to deliver to final delivery destination within a geographically-restricted subsection of the whole catchment area; also Outbase.
RDC	Regional Distribution Centre.
RPE	Regular Pallet Equivalent - This is used to estimate volume and therefore capacity of vehicles within C-TMS.
Schedule	A day's plan, usually consisting of 24 hours, not necessarily from midnight to midnight.
Service Levels; Service Types	Typically used to determine additional services for an order, or a quicker transport service. This defines the order windows i.e. the collection and delivery windows and offsets relating to the service level, through schedule rules.
Shunt	A trunk (q.v.) movement between depots using the trunk network, typically of a much shorter length than a trunk movement.
Sourcing Unit	A second entity that can be applied to a Lane, and all charges relating to that Lane will then be applied to the Sourcing Unit and not the Customer.
Stop	Also Trip Stop. A stop on a trip. In this solution, Drop is the pre-assigned fixed route drop number, whereas Stop is the generated CTMS stop ID.
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
Tractor	The driver cab, pulling the trailer.
Trailer	The trailer carrying the goods. Can be several types.
Transport	The transport management office.
Trip	C-TMS: A selection of work to be completed, specifically a workload that lasts for an entire shift for a driver.
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
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).
TTM	CALIDUS TTM; Track and Trace Module; Aptean's 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. In this implementation, the process of receipt and unloading is predominantly controlled by C-MCS (q.v.). See also Receiving.
WCS	Warehouse Control System
WMS	Warehouse Management System

Authorised By

Stephen Owen	Security Plus Representative	_____________________________
Matt Turner	OBS Logistics Representative	_____________________________

Anonymous

Search

SDD 370536 Security Plus C-TMS Solution Design

Introduction

Objective

Scope and Limitations

Client Requirements

New Solution

Overview of Solution

Solution Detail

Standing Data

Locations

Resources

Tractors/Vehicles

Transport/Despatch Unit (DU) Types

Equipment

Order Well/Transport Jobs

Transport Planning

Manual Planning

Automatic Trip Building and Optimisation

Transport Resourcing

Transport Execution

Login

Workload Start

Loading Vehicle

Job List

Job Details

Loading of Items

Completion of Loading

Delivery Process

Job List

Job Details

Delivery of Items

Completion of Delivery

Collection Process

Job Details

Collection of Items

Completion of Collection

Unloading process

Job List

Unloading Details

Unloading of Items

Completion of Unloading

Completed Jobs

Vehicle Checking and Accident Reporting

Track and Trace

Financial Processing

Trip Cost, Order Cost and Order Revenue

Appendix A: Table of SCRs and Ballpark Estimates

Appendix A1: Core Changes

Appendix A2: Optional Changes

Appendix A3: Product Changes/Fixes

APPENDIX B: DOCUMENT HISTORY

Navigation

Wiki tools

Page tools

Categories