SDD 370536 Security Plus C-TMS Solution Design

From Calidus HUB
Revision as of 13:47, 30 November 2020 by Anw (talk | contribs) (v1.02 - Changes after review and demo with customer.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)






Aptean Logo.png







Security Plus +

Security Plus C-TMS Solution Design

Solution Design

30th November 2020 - 1.02
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.

The customer is not currently intending to use data SIMs in the Android scanning devices at this time, although this is being discussed. Therefore, data will only be returned from the devices when the devices return to base and connect to a depot's WiFi.

The existing customer portals may remain in the final solution, as these have been tailored for the purposes of this operation. CALIDUS Portal will be included in the final solution for track and trace purposes, and customers will be provided logins for this. however, tracking gateway emails will not be used in this implementation, (due to security concerns). Note that no changes have been specified in this solution regarding tailoring CALIDUS Portal, and no order entry facility has been included. Note Note: This requires further review and may then require to be included.


Scope:

The solution described has been tailored so that the requirements have been adapted to fit the existing CALIDUS processes wherever possible and any optional changes are highlighted. It was determined in this initial phase that to minimize license cost and exposure to new systems CTMS should not be accessed by the individual depots.


The solution outlined in this document specifies replacing Route Manager with C-TMS and mobile Bag Tracker with C-ePOD. Additionally, CALIDUS Portal TTM will be available in its standard configuration for track and trace, and CALIDUS VEhub for vehicle checks and accident reporting.

This solution does not include porting any other existing customer systems into C-TMS, including but not limited to:

  • Existing customer portals, data or functionality into CALIDUS Portal.
  • Contract Manager.
  • Reporting.
  • Finance (other than generating transport charges from C-TMS).
  • Money Manager.


Assumptions:

Assumptions have been made where the functionality was not clearly defined in the workshop sessions. Should these assumptions not be correct, this may incur additional effort to resolve them.

  • The location barcode contains the location code itself.
  • The number of inner bags never exceeds a defined amount (e.g. 20).
  • Several bags can include inner bags, for example, 500 (15K Cash Bag), 504 (25K Cash Bag), 503 (trunking sack) and cage seal (TBC). 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
  • Contract Information - depot-specific customer based information, for example bank, schedule, contact names, sites overview/list, etc. Note Note: The depot users can only view information, not edit or create it. Note also that it may be a requirement for this to change in the future, as the operational staff have expressed an interest in allowing depot staff to update addresses, add notes, etc. C-TMS will import locations and therefore, if C-TMS logins are provided to the depot staff, they could have the facility to update addresses and add notes. however, it is not the customer's intention to provide C-TMS access to the depots at this time.
  • Route Manager - creation/amendments of fixed routes.
  • Reporting - remains.
  • Finance - creation, amendment and issuing of invoices to customers.
  • Customer portals - customer viewing completed collections and deliveries (tracking; also larger customers enter their own collection details through the existing portal. Note Note: The existing customer portals may remain in the final solution, as these have been tailored for the purposes of this operation. CALIDUS Portal will be included in the final solution for track and trace purposes, and customers will be provided logins for this. however, tracking gateway emails will not be used in this implementation, (due to security concerns). Note that no changes have been specified in this solution regarding tailoring CALIDUS Portal, and no order entry facility has been included.
  • 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 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.

Note 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.

Note 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 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 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 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 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 before implementation stage.

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

  • 530 - Mixed Coin.
  • Barrows.
  • Coin bags.
  • Cage Seals.
  • Bulk Coin collection.

Note Note: Neither Bulk Coin collection nor vault/car park collections will have a uniquely-identifiable barcode for scanning.


Equipment

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

  • Site keys
  • Vault keys
  • Smoke boxes

Note 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 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 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.

Informational narrative/notes to be displayed to the driver.

  • 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:

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


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 Note: This functionality requires access by the depots to the CTMS screens.


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 Note: This functionality requires access to the C-TMS screens from within the depot.

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 SCR-370536-10: Export of created/updated trips
  • SCR SCR-370536-11: Import of created/updated trips into existing SPL system data - customer work.


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

To cater for this the following processes have been proposed regarding transport resourcing.


Proposed Process

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:

Note 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.


Optional Process

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 SCR-370536-14: Automatic process to accept trips based on the cut-off time.


The operation currently creates a series of reports for drivers runs, including but not limited to:

  • Inward Vault Log.
  • Outward Vault Log.
  • Weight on Van report.
  • End of Run report.

It is expected that that the existing systems will be used to continue to produce those reports. Note that, given that C-TMS will now be generating the runs, and that those runs may be modified by C-TMS users, the existing system reports that reply on this data may require extensive modification to work as before.

Currently, C-TMS supports Driver Manifest reports and Delivery notes formats. However, none will match the bespoke formats required by this operation. Alt

C-TMS may be modified in some areas to produce the reports in exactly the same format as the existing systems. However, this is likely to require porting all existing systems and/or data to OBS Logistics for development and support, which is not expected to be included in this phase of the implementation.

If required, this can be estimated, but at this time is not within the scope of this solution.


Transport Execution

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
  • 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).


SCR SCR-370536-15: EPOD Interface - send additional information

Note 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 - this will need to be reviewed following any decisions made to add any of the optional changes to the functionality required, such as:


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 logo 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 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, focusing on load and job visibility, assuming the core processes as outlined in the following sections.

  • Loads.

    Loads.

  • Load details and assignment.

    Load details and assignment.

  • Load start details.

    Load start details.

  • Jobs on a load.

    Jobs on a load.

  • Job details.

    Job details.

  • Job keys and coins.

    Job keys and coins.

  • Containers (bags).

    Containers (bags).

  • Container details.

    Container details.

  • Collected bag details.

    Collected bag details.


Login

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

Users will be provided with a user name, and the password will be their current password from a scanned barcode on a driver card.

  • Login

    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 (Authorised Contractors Card) - ACC cards are a randomly-assigned daily card with a unique ID, and contains this barcoded ID as well as a depot phone number. This is used by the locations visited to confirm that the goods are being collected by an authorised driver.
  • Crew 1 - ID card 1 - barcode.
  • Crew 2 - ID card 2 - barcode.
  • Vehicle Keys - barcode.
  • Smoke Box - barcode

Note 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

    Accepting the load

  • Entering additional details

    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.

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 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.


Once the loading job is started, the device will move immediately on to scanning items for loading.

  • Loading details

    Loading details

  • Loading Instructions

    Loading Instructions

  • Location Confirmation

    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 Note: Coin and keys for all locations will be displayed as a separate tab, showing the coin and keys to be loaded. The process will show a list of all of the coin bags required to be loaded for every coin order to be delivered and the keys for every location that requires them.

The coin will be consolidated together for loading. So, if one location requires 2 £2 coin bags, and another requires 3, then the system will show a quantity of 5.

Keys will always be unique, so they will always show uniquely in the list, and as a quantity of 1.

The user will be able to count all of the coin bags required.

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

Note Note: This approach will require a product development to be completed to consolidate product (coin) quantities for loading. 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.


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

    Loading Details

  • Items to scan

    Items to scan

  • Item Information

    Item Information

  • Items removed when scanned

    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.

The screen defaults to showing the terms and conditions if they are defined, with the user being able to press the tab to show additional information, such as the cash bags loaded. It has been requested that the screen be modified so that the cash bags tab is always shown first, rather than the terms and conditions. This is an additional optional change and will affect all signature screens on all jobs: loading, unloading, collection and delivery.

SCR SCR-370536-17: Always display cash bag (container) tab if present rather than T&Cs.


Containers (loaded cash bags) will be shown. This will include a display of the value of each bag. Each container can be clicked, which will display the details of the loaded items, including the value. Note Note: This display of value on the screen is subject to product development.

Coin bags and keys are specified as a confirmable product and will be shown here on a separate tab.

If receipt printing is required, this will be added to this signature process. Note that this is not expected to be required at Loading, but may be required for collection and delivery jobs.

SCR SCR-370536-18: Receipt Printing, configurable by site.

Note Note: The operation has requested whether certain locations can be made to be forced to print receipts, whether others can be optional or others not at all. This functionality will be made configurable through the job group selected for the job, which is configurable in CTMS through the location type or location configuration. This is included in the change above.

  • Driver Signature and T&Cs

    Driver Signature and T&Cs

  • Jobs

    Jobs

  • Scanned Items

    Scanned Items

  • Coin Bags

    Coin Bags

  • Job Photos

    Job Photos


Delivery Process

Note 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

    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 to reflect the correct entry to the location or the best place to park the vehicle for access to the location.

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

Note Note: The operation has confirmed that the device must not prompt for location barcode at this time. Instead, this must be capture before confirming delivery of the bags.


Note 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

    Start job

  • Arrive job

    Arrive job


Delivery of Items

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.

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 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.

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


Note Note: The standard ePOD solution does not cater for partial partial collection/delivery (insurance liability) process. Should this be required in the solution further development is required - the following change is a ballpark of how this may be to developed.

SCR SCR-370536-19: Partial Collection/Delivery

Namely this change will consider insurance liability maximum value, therefore identifying 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 an interim receipt. Regardless, it is expected that this is required only for collection jobs, not delivery, loading or unloading jobs.

  • Job details

    Job details

  • List of bags

    List of bags

  • Scan removed from list

    Scan removed from list

  • Coin bags

    Coin bags


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 application will 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 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 Note: Scanning of the location barcode after scanning of the items requires a change to be made to the device. This will be achieved as a product change.


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 (loaded cash bags) will be shown. This will include a display of the value of each bag. Each container can be clicked, which will display the details of the loaded items, including the value. Note Note: This display of value on the screen is subject to product development.

If receipt printing is required, this will be added to this signature process. This will be configurable as to whether the receipt is required, optional or not required at this location.

Coin bags and keys are specified as a confirmable product and will be shown here on a separate tab.

  • Signature and T&Cs

    Signature and T&Cs

  • List of bags

    List of bags

  • Coin bags

    Coin bags

  • Driver Signature

    Driver Signature

  • Job photos

    Job photos


Collection Process

If there is a planned collection from this location, the device will automatically start the collection for the user and display the details, ready for scanning. In this case, the user will not be prompted to scan a location barcode to confirm that they are at the correct location. Note Note: This is subject to a product development.

If the user exits, they can choose the collection from the job list to return to the job details screen. In this case, when starting the job, they may be prompted to confirm the location barcode, if the user has elected to visit another location in the interim.

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.

Note 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.


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 to reflect the correct entry to the location or the best place to park the vehicle for access to the location.

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 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 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

    Job Details


Collection of Items

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 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 SCR-370536-21: Container UDF by Container Type

For Bulk Coin collection, 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 any bag type that includes inner bags, the app will prompt for up to a fixed number of inner bag IDs. As there have been occasions in the last were up to 18 inner bags have been collected, this will initially be configured for capturing up to 20 bags.

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

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.


For bags without a unique identifier to scan, a facility must exist to add a collected item and for the system to generate a unique bag ID.

SCR SCR-370536-22: Vault/Bulk Coin collections - Collect an unknown item and generate a unique id.

This is required for vault/car park collections and bulk coin collections.

The process will be developed to allow the user to press a button and select the type to be generated from a drop-down list of types.

When clicked, a unique ID will be generated from the date and time. This will then be treated as any other item collected.


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

Note Note: For outer/inner bags, the proposed process should be reviewed. An alternative process of scanning as many bag IDs as required will require additional development.

SCR SCR-370536-23: 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.


Note Note: The standard ePOD solution does not cater for partial collection/delivery (insurance liability). Should this be required in scope, 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 an interim receipt. Regardless, it is expected that this is required only for collection jobs, not delivery, loading or unloading jobs.

  • Details and keys

    Details and keys

  • Scan Bag and enter type

    Scan Bag and enter type

  • Enter value

    Enter value

  • Enter coin bags

    Enter coin bags

  • Scan Inner Bags

    Scan Inner Bags

  • Vault details

    Vault details

  • List of all scanned bags

    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 (loaded cash bags) will be shown. This will include a display of the value of each bag. Each container can be clicked, which will display the details of the loaded items, including the value. Note Note: This display of value on the screen is subject to product development.

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. This will be configurable as to whether the receipt is required, optional or not required.


  • Signature and T&Cs

    Signature and T&Cs

  • List of bags

    List of bags

  • Bag details

    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 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 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 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 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.

Note Note: Scan off is done by the existing in-depot scanning systems. It is therefore expected that the Unloading process will be configured to allow the user to click "Deliver All", without scanning all items - this will take the user straight to the confirmation process. Note Note: This functionality requires product development.


If this is not enabled, or the process changes so that the user must scan, 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

    Unloading details

  • List of bags

    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.

Note Note: It is expected that the Unloading process will be configured to not require any signature or photos, but to just complete the job. However, if the user requires a receipt, then this process will be required. The following is a description of the driver signature plus receipt, if required.

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

Containers (loaded cash bags) will be shown. This will include a display of the value of each bag. Each container can be clicked, which will display the details of the loaded items, including the value. Note Note: This display of value on the screen is subject to product development.

If receipt printing is required, this will be added to this signature process. This will be configurable as to whether the receipt is required, optional or not required.

  • Driver Signature

    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, note that this is acceptable - the existing systems in place allow for fall-back processes.


This will be exported to external systems through a standard interface.

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

SCR SCR-370536-24: 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 SCR-370536-25: 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 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 within CALIDUS VEhub allow drivers to track resource locations through the scan of any barcode. This resource might be trailers, trolleys, stair steppers, barrows, etc.

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

    Main Menu

  • Checks - List

    Checks - List

  • Checks - Details

    Checks - Details

  • Checks - Rectification

    Checks - Rectification

  • Accidents - List

    Accidents - List

  • Accidents - Details

    Accidents - Details

  • Accidents - Details

    Accidents - Details


Device Screens:

  • Main Menu

    Main Menu

  • Vehicle Checks - Details

    Vehicle Checks - Details

  • Vehicle Checks - Checks

    Vehicle Checks - Checks

  • Signature Capture

    Signature Capture

  • Accident Report - Details

    Accident Report - Details

  • 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:

  • 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.
  • End customers - end customers can access tracking information about a single consignment through a link - no login is required - this functionality is not expected to be in use for this project due to security concerns.

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 Parameters.

  • Order Enquiry Results.

    Order Enquiry Results.

  • Trip Enquiry Parameters.

    Trip Enquiry Parameters.

  • Trip Enquiry Results.

    Trip Enquiry Results.

  • Order and Event Details.

    Order and Event Details.

  • Order Info Details.

    Order Info Details.

  • Order Route Details.

    Order Route Details.

  • Trip 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 Screen.

  • Order Status Parameters.

    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, this functionality is not expected to be in use for this project due to security concerns.

  • Enter Consignment.

    Enter Consignment.

  • Consignment Tracking.

    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 SCR-370536-26: Additional charge rate conditions.


Note 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 SCR-370536-27: 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.


Automatic Trip Building and Optimisation

Though not expected to be part of the initial phase, Tactical and strategic planning were areas highlighted in the workshops where clear efficiencies can be made by optimising depot planning.

Note 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 Note: This tactical planning functionality requires access to the C-TMS screens from within the depot.

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.


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#SystemAreaDescriptionEstimate (Days)Notes
1 SPL Interface Standing Data Interface - customer work  0.00  2
3 SPL Interface Additional Standing Data Interfaces - customer work  0.00  2
6 SPL Interface Orders interface - customer work  0.00  2
9 TMS Interface Orders interface - receive equipment  2.75 
10 TMS Interface Export of created/updated trips  2.75 
11 SPL Interface Import of created/updated trips into existing SPL system data - customer work.  0.00  2
12 SPL Interface Interface to assign resource to trips - customer work  0.00  2
13 TMS Interface Interface to assign resource to trips  1.75 
15 EPOD/CTMS Interface EPOD Interface - send additional information  12.00 
21 EPOD Server/Device Container UDF by Container Type  7.00 
22 EPOD Device Vault/Bulk Coin collections - Collect an unknown item and generate a unique id.  3.00 
24 SPL Interface Import order debrief information  0.00  2
25 EPOD Interface POD/POC Formats  3.50 
27 SPL Interface Import invoice charges  0.00  2


Note Note:
  1. 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.
  2. 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.

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.


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.


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 using the standard ePOD process. 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 bring additional changes into scope (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.


SCR#SystemAreaDescriptionEstimate (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  2
8 TMS Interface Costs interface - CTMS work  3.50 
14 TMS Process Automatic process to accept trips based on the cut-off time.  1.75 
16 EPOD/CTMS Store additional load/driver/vehicle information  8.50 
17 EPOD Device Always display cash bag (container) tab if present rather than T&Cs.  3.50 
18 EPOD Printing Receipt Printing, configurable by site.  17.00 
19 EPOD Col/Del Partial Collection/Delivery  8.50 
20 EPOD Device Custom DU type default  2.75 
23 EPOD Collection Outer/Inner Bag Collection  7.00 
26 TMS Finance Additional charge rate conditions  7.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 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#SystemAreaDescriptionEstimate (Days)Notes
1 EPOD Device Consolidated Products Development  13.75  1
2 EPOD Device Prompt for post-job UDF  1.75  1
3 EPOD Device Auto-start job - continue job.  1.75 
4 EPOD Device Auto-starting a collection after a delivery takes you straight into the Col/Del process, not just to the Job Details screen.  1.75  1
5 EPOD Device Allow Containers to be clicked to show details, including UDF (read only).  5.25  1
6 EPOD Device Fix issue displaying Job UDF per job on the Collection/Delivery Info tab.  1.75 
7 EPOD Device Allow configuration of what is displayed on the Signature screen for Products and Containers.  2.75  1
8 EPOD Admin Fix issue displaying received Job UDF on the Job Details screen pop-up.  1.75 
9 EPOD Device Check validation on check items on collection/delivery.  0.50 
10 EPOD Device Deliver All to be allowed to be set from Job Group  3.50  1
11 EPOD Device Must use configurable labels on Container/Products admin screen.  1.75 


Note Note:
  1. This is a product change.


APPENDIX B: DOCUMENT HISTORY

References

Ref NoDocument Title & IDVersionDate
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 Group Financial Controller
_____________________________

Murray Middleton
OBS Logistics Project Manager
_____________________________

Tony Walker
OBS Logistics Solution Architect
_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=SDD_370536_Security_Plus_C-TMS_Solution_Design&oldid=9219’