SDD 370536 Security Plus C-TMS Solution Design
Security Plus
Security Plus C-TMS Solution Design
Solution Design
13th July 2020 - 0.4
Reference: SDD 370536
Contents
- 1 Introduction
- 2 Client Requirements
- 3 New Solution
- 4 Solution Detail
- 4.1 Standing Data
- 4.2 Order Well/Transport Jobs
- 4.3 Transport Planning
- 4.4 Manual Planning
- 4.5 Automatic Trip Building and Optimisation
- 4.6 Transport Resourcing
- 4.7 Transport Execution
- 4.8 Vehicle Checking and Accident Reporting
- 4.9 Track and Trace
- 4.10 Financial Processing
- 5 Appendix A: Table of SCRs and Ballpark Estimates
- 6 APPENDIX B: DOCUMENT HISTORY
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 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).
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.
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.
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: 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 of Items
The user will scan all advised items to be loaded for delivery.
Each item scanned is removed from the list.
Coin to be loaded will be selected. 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.
Warning: Product development to consolidate product quantities for loading/unloading
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.
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.
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 (bags) will be shown.
- Products (coin and potentially keys) will be shown.
If receipt printing is required, this will be added to this signature process.
![]() | SCR-370536-18: | Receipt Printing |
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.
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 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.
Delivery of Items
Scan all advised items to be delivered.
Warning: How to deal with the insurance liability of delivering only a couple of items?
![]() | SCR-370536-19: | Partial Collection/Delivery |
Note: Namely this change will consider insurance liability, therefore identifying value, value limit per customer/location and potentially showing a summary, printing a receipt, etc.
Each item scanned is removed from the list.
Coin to be delivered will be selected. The process will show a list of all of the coin bags required to be delivered. 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.
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.
- Products (coin and potentially keys) will be shown.
Warning: Product development to click on an item and show the value
If receipt printing is required, this will be added to this signature process.
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.
Warning: Product development to remove Start/Arrive and Location Confirmation if auto-starting.
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 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.
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-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 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.
Warning:
- How to deal with the insurance liability of collecting only a couple of items?
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.
- Products (coin and potentially keys) will be shown.
Warning: Product development to click on an item and show the value
If receipt printing is required, this will be added to this signature process.
As collections are completed, the information will be sent back to C-TMS and stored.
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 |
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 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 deliver by type.
- Job/location Instructions - these must be viewed before the job can be started.
The user will not be able to start the unloading job until the collection jobs are completed.
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.
Unloading of Items
Scan all advised items to be unloaded.
Warning: no insurance liability of delivering only a couple of items as at secure destination
Each item scanned is removed from the list.
Coin to be delivered will be selected. The process will show a list of all of the coin bags required to be unloaded. The user will be able to count all of the coin bags required. The user will be required to confirm that all bags are unloaded.
Warning: Product development to consolidate product quantities for loading/unloading
The user will be able to confirm whether items have not been unloaded with a reason code.
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 and customer displays the actual scanned or confirmed items on this page.
- Containers (bags) will be shown.
- Products (coin and potentially keys) will be shown.
If receipt printing is required, this will be added to this signature process.
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, as described in the processes above.
The completed job information is used by C-ePOD to generate Proof of Delivery and Proof of Collection reports, which can then be automatically sent on 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:
Device Screens:
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.
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.
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.
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
SCR# | System | Area | Description | Estimate (Days) | Notes |
1 | SPL | Interface | Standing Data Interface - customer work | 0.00 | 2 |
2 | TMS | Interface | Equipment Interface | 8.50 | |
3 | SPL | Interface | Additional Standing Data Interfaces - customer work | 0.00 | 2 |
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 | |
6 | SPL | Interface | Orders interface - customer work | 0.00 | 2 |
7 | SPL | Interface | Costs interface - customer work | 0.00 | 2 |
8 | TMS | Interface | Costs interface - CTMS work | 3.50 | |
9 | TMS | Interface | Orders interface - receive equipment | 8.50 | |
10 | TMS/EPOD | Order | Add value to order items | 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 | 2 |
13 | SPL | Interface | Interface to assign resource to trips - customer work | 0.00 | 2 |
14 | TMS | Interface | Interface to assign resource to trips | 3.50 | |
15 | TMS | Process | Automatic process to accept trips based on the cut-off time. | 3.50 | |
16 | EPOD/CTMS | Interface | EPOD Interface - send additional information | 8.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 | |
21 | EPOD | Server/Device | Container UDF by Container Type | 7.00 | |
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 | |
26 | SPL | Interface | Import order debrief information | 0.00 | 2 |
27 | SPL | Interface | POD/POC Formats | 3.50 | |
28 | TMS | Finance | Additional charge rate conditions | 0.00 | 2 |
29 | SPL | Interface | Import invoice charges | 0.00 | 2 |

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