SDD 358307 The Delivery Group Solution Design

From Calidus HUB





Aptean Logo.png







The Delivery Group

The Delivery Group Solution Design


CALIDUS ePOD

18th July 2019 - 0.4
Reference: REQ 358307












































Introduction

This document is the solution design for The Delivery Group.

Objective

The primary purpose of this document is to document the requirements gathered from The Delivery Group, during several meetings, including:

  • Sales meetings.
  • Project start-up/review meeting 05/07/2019.
  • Integration meeting 08/07/2019.

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


Scope and Limitations

This document is based on the documentation provided by The Delivery Group, as referred to in the appendices, as well as information gleaned from site visits and workshops with The Delivery Group. Further email review and clarification of the requirements has also taken place.

  • The changes will be made in the latest version of the CALIDUS ePOD system.
  • This document covers the operational processes to be controlled primarily by CALIDUS ePOD. Separate documents may be produced to identify additional systems processes.


Client Requirements

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

Overview

The Delivery Group focus on fast moving ecommerce and specialist mail services, they collect, sort, track, distribute and deliver a variety of post, parcels, pallets and tailored services throughout their network.

They manage almost a billion items of mail and packages in the UK and Internationally, supplying consumables into mail distribution centres, typically Yorks and Magnums used to store and transport bags or trays/tubs of sorted and unsorted mail from their processing depots out to clients for delivery.

The Delivery Group are currently unable to track their assets through the supply chain and are losing them as a consequence.

It has been determined that CALIDUS ePOD is required to integrate with current systems, auditing the delivery of consumables and amount collected back at each delivery location.

CALIDUS ePOD is required as part of the process, to capture the asset tracking processes and close the loop i.e. to confirm all deliverables (Yorks) on the Load are returned back once the delivery process is completed.


There are multiple types of trackable asset. The known assets are:

  • Yorks - Steel Cage Pallet/Trolleys @200kg
  • Magnums - Steel Box Pallet @700kg
  • Pallets @ 500kg
  • Trays

Note Note:

  • 98 Yorks fit on a standard double decker.


A new depot is Bristol opens in August - The Delivery Group would like to aim for start of August for desk testing with user testing with drivers for 2nd and 3rd week in August.


General Comments

The hardware intended to be used by the operation is as follows:

  • Motorola J5 devices.
  • TomTom WEBFLEET head units and tracking devices


The systems that will be in use to control the business in this solution are as follows:

  • MAGware TMS - the transport management system, controlling order and trip workflow and resource management.
  • PTV Route Optimiser (DPS) - route optimiser software responsible for planning orders to trips.
  • TomTom WEBFLEET - vehicle tracking and reporting, with some order status management.
  • CALIDUS ePOD - trip and order execution, and reporting.
  • CALIDUS TTM - customer and transport portal.
  • CALIDUS VEhub - vehicle defect checks and accident reporting.


The primary contacts are as follows:

  • The Delivery Group:
    • Stuart Mylchreest - Head of Operations
    • James King - Project Manager.
    • Katrina Shaw - Head of Operational Performance & Client Services.
    • Stuart Dyet - Business Analyst.
  • MAGware:
    • Miles Griffiths - software and web solutions (TMS).
  • OBS Logistics:
    • Murray Middleton - Project Manager.
    • Matt Turner - Product Manager/Sales.
    • Tony Walker - Consultant/Solution Design.


Configuration/Set-up

C-ePOD will be configured with the sites corresponding to the operational depots:

  • Site "WARR" - Warrington depot.
  • Site "LUTON" - Luton depot.

There are other depots in the operation, to be confirmed whether they are part of this solution:

  • Derby.
  • Kent.
  • London.
  • Portishead.
  • Shotts.


Each depot will be set up as 2 sites, one for the depot and one for the warehouse operations. For example, for Warrington:

  • "WARR" - the depot.
  • "WARR-W" - the warehouse.

Each site configured this way will have a customer created matching the depot, to provide address information.

The warehouse sites will be set up with the following settings configured (amongst others):

  • No arrival times captured.
  • Completing jobs out of sequence not allowed.
  • Warehouse-specific PDA users and at least one admin user.
  • Warehouse-specific reason codes for shortages.
  • Warehouse-specific vehicles (without WEBFLEET connection information).
  • No site email.
  • FTP Import settings in OBS XML format.
  • FTP Export settings in OBS XML format.

There will be one job group set up for each of the warehouse sites, called "WAREHOUSE". This will control the warehouse loading and unloading tasks. This job group will be set up as follows:

  • A basic POD/POC format.
  • No customer or driver signatures for jobs.


The depot sites will be set up with the following settings configured (amongst others):

  • Arrival times captured.
  • Warning Warning: Completing jobs out of sequence not allowed.
  • Optional photo (with required comment) on cancellation of jobs or changing of quantities.
  • Depot-specific PDA users for each drivers (linked to the WEBFLEET users by name) and at least one admin user.
  • Depot-specific reason codes for shortages.
  • Depot-specific vehicles (with WEBFLEET connection information).
  • FTP Import settings in OBS XML format.
  • FTP Export settings in OBS XML format.
  • WEBFLEET integration settings for export and import.

Each site will have the following standing data created in the following areas:

  • Users - both admin console and PDA users (drivers of the trips).
  • Vehicles - for the execution of the trips.
  • Codes - normally clause and cancellation codes used by the drivers when failing of changing jobs.
  • Customers - usually created with the jobs on trips, these can also be manually created and maintained.

Note that it is expected that the C-ePOD username and password for drivers is expected to be set up to match the WEBFLEET user name and password, to simplify logon for the drivers. Additional agency drivers not on WEBFLEET may also be added with standard agency log-ons.

There will likely be a mix of Admin users:

  • Some to input information.
  • Some just to view information.


Load Start Metrics will be set up against the depot, to be displayed as a reminder to the driver to check vehicle weights and dims before departure.

There will be several job groups set up to reflect the different processing of certain jobs, expected to be as follows:

  • "COLL" - a job group controlling general collection processing.
  • "DEL" - a job group controlling general delivery processing.
  • "RMCOLL" - a job group controlling Royal Mail collection processing.
  • "RMDEL" - a job group controlling Royal Mail delivery processing.
  • "RTD" - a job group controlling return to depot jobs.

The return to depot job group ("RTD") will be configured as follows:

  • A basic POD/POC format.
  • No customer or driver signatures for jobs.
  • No email.
  • Deliver All functionality enabled.

General job groups ("COLL" and "DEL") will be configured as follows:

  • A basic POD/POC format.
  • Customer signatures for jobs.
  • No email. Warning Warning: Confirm we are not automatically emailing customers a POD or POC on completion of the job.
  • Deliver All functionality disabled.

The Royal Mail job groups ("RMCOLL" and "RMDEL") will be configured as follows:

  • A basic POD/POC format.
  • Customer signatures for jobs.
  • Deliver All functionality disabled.
  • Royal Mail contact information through UDF.


No vehicle checks will be configured in CALIDUS ePOD for the any sites - this task will be completed solely through CALIDUS VEhub.


Integration

It is expected that all trips (loads in C-ePOD terms) and orders activity (jobs in C-ePOD terms) will be interfaced to C-ePOD from the TMS. The trigger point of this export of data to C-ePOD is still to be confirmed. It is expected to be at or after the point of resourcing (i.e. assigning driver, vehicle and/or trailer).

It is expected that last minute changes and updates to the planned route will be sent to C-ePOD as changes to routes are made on the fly in the afternoon - switching Jobs from one manifest (load) to another.

Regardless, this interface will match the C-ePOD XML format for importing data into C-ePOD, as defined in other documents provided to the TMS development supplier.

It has been confirmed that this interface into C-ePOD will be flat-file, sent to C-ePOD servers over an FTP connection. C-ePOD servers will supply an FTP username and password and control the receipt of the files. A timed process will pull in the files, with any issues reported to the audit log.


All warehouse jobs will be sent with job group "WAREHOUSE" for the correct warehouse site as outlined above.

All depot jobs will be sent with a variable job group for the correct depot site as outlined above.

When a route is ready for processing (to be confirmed in TMS), the load will be sent to C-ePOD.

If the load includes delivery jobs, the load will be replicated on to the warehouse for that depot, including a loading job for each delivery job. The loading of the delivery jobs will be in reverse sequence to the delivery sequence.

Warehouse loads will be sent with the vehicle to load without a user assigned, so that any warehouse user can pick up this task.

Depot loads will be assigned to a vehicle and a driver, to lock them to this driver.

Depot loads will include a Return to Depot job for each collection job on the load. These jobs will be the last job on the load, and will be linked together (i.e. consolidated for the driver). If there are no collections on that load, there will be a single empty return to depot job.


Mobile Application

The mobile application will be styled to:

  • Show the logo (The Delivery Group) on the login screen.
  • Display the Planned Start and End date and time on the Job List screen.

Other customisation may be required, to be confirmed during implementation. Some suggestions:

  • "Product" to be translated as "Asset".
  • Product list to show DU Type and quantity only.
  • Basic device colours.
  • Other label changes, to be confirmed during implementation sessions.


SCR SCR-358307-1: Mobile Device Customisation


Operational Processes

Transport Operations

The TMS will control entry of orders and the planning onto routes through DPS.

When routes are confirmed and resourced, the routes and all orders will be sent to C-ePOD for execution, including loading tasks if required.


Warehouse Operations:

Where there are loading tasks in the warehouse for a load, the delivery load in the depot site will not be available to be started until the warehouse loading jobs are completed.


SCR SCR-358307-2: Warehouse loads blocking and updating Delivery Loads.

Note Note: This change encompasses updating delivery jobs with the loaded quantity on completion of the loading job, as well as blocking the delivery load from starting.


The warehouse users will log onto the PDA, which will be configured for the appropriate warehouse site.

The users will enter their provided username and password and select the vehicle to load. Only one loader is allowed per vehicle. Once the loader has picked up the load, they must complete the load, unless this load is allocated to a new loader through the C-ePOD admin system.

The user will be provided a list of all jobs to load onto the vehicle.

The user will prevented from loading the product out of sequence - they must follow the sequence on the job list.

On selecting the job, the user will be shown a summary and allowed to start the job.

Once started, the device will display the products to load. This will consist of all planned DUs to load onto the vehicle for that order.

The user will confirm the quantity of each DU loaded onto the vehicle.

If there is a discrepancy, the user may indicate this through entry of a reason code and a change of quantity

Warning Warning: Are we allowing 20% increase of quantity at loading or not?

When all products are loaded for this job, the job will automatically complete and the user will be returned to the list of jobs to be loaded.

All jobs will be completed in sequence.

When load is completed, the application will display a confirmation that the load is complete and attempt to request another for that vehicle. As there will not be any other loads for that vehicle, the application will inform the user and allow them to either exit the app, log off or change vehicle. If the user is loading another vehicle, they will select the Change Vehicle option. If they are going on a break, or have finished their shift, they will choose one of the other options.

As each job is completed, the job will be marked as completed and the job will be queued for export back to TMS. Each delivery job will be updated with the actual loaded quantity per DU. If none has been loaded for the job (or the job was cancelled), the delivery job will be cancelled.

As the load is completed, C-ePOD will release the delivery load for execution.


Driver Process

The driver will log onto the PDA, which will be configured for the appropriate depot site.

The driver will enter the provided username and password and select the vehicle to deliver.

The application will prompt the driver to check the vehicle weight and dimensions before departure to update WEBFLEET, to ensure that navigation is optimised.

The driver will be provided a list of all jobs to collect and deliver on this load. It is expected that there will also be a final "Return to Depot" job at the end of the load, which will be a consolidation of all collection jobs on that load. If there are no collection jobs on the load, it is expected that there will be a single empty job.

On obtaining this load, C-ePOD will generate jobs out to WEBFLEET for that vehicle for each job on the load, in the same sequence as on C-ePOD.

Warning Warning: Unloading jobs must be excluded from the orders sent to WEBFLEET.

WEBFLEET will also be configured to generate and internal notification when the driver is 15 mins away.

Both of these will require a slight modification to the existing C-ePOD-WEBFLEET interface.


SCR SCR-358307-3: Modifications to C-ePOD-WEBFLEET interface.


The driver will log on to the WEBFLEET head unit and log in to WEBFLEET with their WEBFLEET credentials. Note that it is expected that the C-ePOD username and password is expected to be set up to match the WEBFLEET user name and password, to simplify log on for the drivers.

The driver will prevented from completing the jobs out of sequence - they must follow the sequence on the job list.

Warning Warning: TBC

Note Note: In this configuration, the driver will have the following general process:

  • Start the job on EPOD.
  • Start the job on WEBFLEET.
  • Navigate to the address on WEBFLEET.
  • Complete the job on WEBFLEET.
  • Arrive the job on EPOD.
  • Complete on EPOD.

Equally, this could be configured as follows:

  • Start the job on WEBFLEET.
  • Navigate to the address on WEBFLEET.
  • Complete the job on WEBFLEET.
  • Start the job on EPOD.
  • Complete the job on EPOD.

On selecting the first job, the driver will be shown a summary and allowed to start the job.

The driver will then select the same order from the WEBFLEET order list on the head unit and will navigate to the address.

Once the driver has arrived, they will complete the job on WEBFLEET. They will then click the Arrive button on EPOD.

Once started, the device will display a screen with multiple tabs:

  • Information about the job, such as job instructions, contact information, etc.
  • Products to deliver or collect. This will consist of all planned DUs to load onto the vehicle for that order.
  • Notes for the driver to enter if required.

For Royal Mail deliveries and collections, the Royal Mail contact information will be included on the Information tab for the job.

The driver will confirm the quantity of each DU collected or delivered.

If there is a discrepancy, the driver may indicate this through entry of a reason code and a change of quantity.

The process will be changed to allow a maximum of 20% increase of quantity at collection only.

Warning Warning: At collection only?


SCR SCR-358307-4: Allow a maximum of 20% increase of quantity at collection only


When all products are collected or delivered for this job, the application will prompt for customer signature. Any configured terms and conditions will be displayed here.

Once the customer has signed for the job, the job will automatically complete and the user will be returned to the list of jobs to be completed.

Note Note: The system will be configured to allow jobs to delivered or collected from unmanned locations. In these cases, the application will prompt for driver signature and require that a photo is taken.

Note Note: Royal Mail jobs may be configured to require a phot to be taken for each job.

All collection and delivery jobs will be completed in sequence, following this process.

When all collection or delivery jobs are completed, the driver will return to base.

The driver will select the Return to Base line from the job list. They will start the job and return to base.

Once arrived, all collected products will be shown on this job, along with a "Deliver All" button, which the driver will use to complete the job. No signature will be prompted for.

When load is completed, the application will display a confirmation that the load is complete and attempt to request another for that vehicle or driver. As there will not be any other loads for that vehicle, the application will inform the user and allow them to either exit the app, log off or change vehicle. If the user is changing to another vehicle, they will select the Change Vehicle option. If they are going on a break, or have finished their shift, they will choose one of the other options.

As each job is completed, the job will be marked as completed and the job will be queued for export back to TMS.

C-ePOD will generate an Unloading warehouse load for the products returned to depot.

Warning Warning: Should this generate one job or many? If many, in reverse order? If one, just consolidate all the quantities together?


SCR SCR-358307-5: Generate an Unloading warehouse load


Outbound Integration

Note Note: Outbound integration back into TMS is a potential future Phase 2, outside the scope of this initial project.

As the jobs are complete, C-ePOD will generate an email containing the documentation to the customer (if the customer email has been provided on the job) and to the site email address (if configured).

It is expected that the system will be configured to send Site emails only if there are discrepancies, for all jobs.

The Delivery Group may require that they only get the email for Royal Mail job group, in which case a change will be required.


SCR SCR-358307-6: Email Site discrepancies only for specific Job Groups.


Reporting/Admin Console

The CALIDUS ePOD Admin console provides the facility to:

  • maintain loads and jobs.
  • maintain standing (reference) data.
  • view and track the completion of loads and jobs.
  • produce reports.


The following reports are required:

  • Standard POD/POC reports when jobs are completed.
  • Asset Count report
  • Collection Performance report.

Note Note: It is also possible that a Royal Mail POD format will be required, different to the standard POD format. This has not at this time been included in any estimate of cost.

The latter two will require development within C-ePOD.


SCR SCR-358307-7: Asset Count report


The Asset Count report will allow Assets to be maintained at Location (Customer and Branch) and movement and Totals to be reported on.

A search prompt with To and From Date and Customer Location will produce an Excel Spreadsheet with 2 Tabs:

  • Tab 1: Current Total of Product by Location.
  • Tab 2: Breakdown of movements in and out over the period.

The Admin system will be modified to allow the user to maintain the current position of assets within locations.

It is expected that the initial position of assets at locations will be updated and maintained before go-live.


SCR SCR-358307-8: Collection Performance report


The Collection Performance report format has been provided.


Appendix A: Table of SCRs and Ballpark Estimates

SCR#SystemAreaDescriptionEstimate (Days)Notes
1 EPOD PDA Mobile Device Customisation  1.00   
2 EPOD Loading/Unloading Warehouse loads blocking and updating Delivery Loads.  5.50   
3 EPOD Interface Modifications to C-ePOD-WEBFLEET interface.  1.50   
4 EPOD Collection Allow a maximum of 20% increase of quantity at collection only.  2.75   
5 EPOD Loading/Unloading Generate an Unloading warehouse load.  3.50   
6 EPOD Interface Email Site discrepancies only for specific Job Groups.  3.00  2
7 EPOD Reports Asset Count report.  3.00  3
8 EPOD Reports Collection Performance report  4.25   


Notes:

  1. Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of a software change request (SCR).
  2. This change has been deemed not required.
  3. Additional development to the asset report being developed for the product.


Appendix B: Document References

B.1 References

Ref NoDocument Title & IDVersionDate
120190624 DELG Initial Meeting Notes.docxN/A24/06/2019
220190705 DELG Project Review Notes.docxN/A05/07/2019
34th July 2019 - TMS Customer Collection Performance Report v5.xlsxN/A04/07/2019
4Order Extract.xlsxN/A08/07/2019
5EPOD Import Mapping v4.5.00.05.xlsxv4.5.00.0509/07/2019


B.2 Glossary

Term or Acronym Meaning
General Definitions
EPOD Electronic Proof of Delivery. The OBSL EPOD system is CALIDUS ePOD. This also comprises the basis of the Service Completion system CALIDUS eServ.
Server The portion of the CALIDUS ePOD/eServ systems that controls all the data and sends information to and receives updates from the mobile device.
Mobile Device; PDA The device used by the driver to perform the jobs. Typically an Android mobile device or tablet.
Site The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. An EPOD user, on a device or in the Admin screen, can only see data for one site at a time.
Load A single journey for the driver with a set of work attached. A load is identified by a unique load ID. This may also be referred to as a worklist or workload.
Job Also Consignment. A single task for the driver as a specific location. This could be the collection of goods or the delivery of goods. Jobs may also be Services (for example, servicing, installing or de-installing a boiler). A job is identified by a unique job ID but can also have other references held against the job (e.g. job code, SO number, customer reference and external reference).
Job Group Jobs must be tagged with a Job Group. All jobs tagged with a single job group are processed in the same way. The job group has configuration associated to it to control such items as: POD/POC Report settings; Pre-Job actions (such as signing at a gatehouse); Post-Job actions (such as who signs for the item, are photos required); configurable fields required for entry for the jobs; Terms and Conditions displayed and; driver/user process (such as photos required for cancellation, comments/notes allowed). The job group can be used for any or all Sites, and the configuration against the job group can be different in each site. Job Groups can also be restricted from Admin and Remote users, so that certain users only see jobs for certain groups.
Container A generic term for any object that contains the items being collected or delivered. Examples of containers are: Pallet; Package; Carton; Item; Cage. A special container "Loose Products" - see Product below. A container is identified by a container ID which is unique to this physical container.
Product A product is any goods that are being collected or delivered where the product has a 'Product Code' which identifies what the product is but which does not uniquely identify each individual item. A product will also have a quantity associated with it to indicate how many items of this 'Product Code' are being collected or delivered. Products can either be processed within a 'Container' or as 'Loose Products' without a 'Container'.
Owner The owner of the order that created the job. Typically this is the sales team that took the order and will be responsible for dealing with queries from the customer regarding the status.
Operator; Executor The Site (depot or carrier) that is executing the load or loads that are involved in the delivery of the items.
Item Related Definitions
Job Code A reference associated with a job or job(s). This reference is common to connected jobs, for example this would be the same on both the collection of goods and the associated delivery of the same goods. Typically this would be the transport unique reference.
SO Number A reference associated with a job which indicates the "Sales Order Number" this job is associated with.
Customer Reference A reference associated with a job which has been provided by and will be recognised by the customer.
External Reference A reference associated with a job which does not match any of the existing references, usually because it has been provided by an external system.
Pallet An alternative for 'Container'. The term pallet is used when the operation only uses portable platforms as the container for goods.
Package An alternative for 'Container'. The term package is used when the operation only uses boxes or wrapping as containers for goods.
Package Code A code representing the type of 'Container'.
Package Desc A description of the type of 'Container'.
Product Code A code which identifies what a product is.
Item A generic term for any individual item that can be collected or delivered. An item can represent a 'Container' or a 'Product'. This can also be used as an alternative for 'Container' when the operation only treats the goods as individual items, i.e. not as identifiable products.
Service Item An item which will be serviced by a service job. See action 'Service'.
Issue Life The time after which an item is no longer fit for purpose.
Pack Size; Case Quantity A product may consist of a full quantity of items, inside a pack. The Pack Size (or Case Quantity) defines the amount of this product contained in a single pack. For example, if there are 85 items to deliver, with a pack size of 24, the number of full packs is determined to be 3 (24 * 3, or 72), with the remaining (13) being 'loose' quantity. This is displayed as "3/13" on the mobile application.
UOM; Item Type Unit of Measure; The major (case) UOM. This can optionally be displayed on the mobile device when changing product quantities.
Product Type A classification of the product being delivered. For example, a company may deliver 7 different mortar products and 80 different concrete slab products. The Product Types may be set to "MORTAR" and "SLABS". This may be used to attach additional configuration, changing the data required when collecting or delivering these product types.
Status Definitions
Status An indicator of how far through the processing a 'Job', 'Container' or 'Product' has progressed.
Pending A status indicating that the processing has not yet started, but is required to be completed.
In Progress A status indicating that processing has started but not yet finished.
Complete A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered.
Complete (Amended) A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered but that some changes or amendments have been made. This means that not everything that was planned to be collected or delivered was collected or delivered, some items may have been cancelled or some products may only have had some of the planned quantities collected or delivered.
Complete (Claused) A status indicating that the processing has been finished but that a 'Clause' condition has been recorded for this item.
Claused See 'Complete (Claused)' and action 'Clause'.
Cancelled A status indicating that the processing of this item or job is no longer required.
Cancelled at Collection A status indicating that the delivery of a container or product is no longer required because the associated collection of this container or product was cancelled.
Submitted An optional status that applies only to a 'Job' and which occurs after the 'Job' has been completed. This indicates that any time and expenses information recorded for the 'Job' has been submitted back to the server and can no longer be altered.
Action Definitions
Start An action associated with a 'Job' meaning the driver is about to start the processing of this job or jobs. This action will mark the job(s) with a status of 'In Progress'.
Arrive A conditional action associated with a 'Job' meaning the driver has arrived at the location the goods should be collected from or delivered to.
Continue An action associated with a 'Job' meaning the driver has previously performed the 'Start' and/or 'Arrive' action and has exited the processing screen but is now going to continue the processing.
Collect An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Collect Claused An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product' but with a condition under which the collection was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Deliver An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Deliver Claused An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product' but with a condition under which the delivery was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Clause An action associated with a specific 'Container' or a 'Product' that has already been collected or delivered meaning the collection or delivery has been accepted with a condition. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Cancel An action associated with a 'Job', 'Container' or 'Product' meaning the collection or delivery will not be performed for this 'Job', 'Container' or 'Product'.
Submit An optional action which can conditionally be carried out after a 'Job' has been collection or delivered meaning that any/all required expense or time recording for this 'Job' has been completed and can be submitted back to the server.
Service A service of a service item or items. Typically, Installation, Deinstallation or Service. The process of a service usually encompasses Pre- and Port-work checks, information gathering and diagnosis and resolution notes. Additional references (MC Refs) may also be captured.
Actioned A general term describing completing a job. So, 'Actioned' may be used instead of 'Collected', 'Serviced', 'Delivered'.
Consolidate The action of taking several jobs and linking them together, so they are actioned at the same time with one start, arrive and signature.
Deconsolidate The action of taking a consolidation of jobs and breaking them down into the component jobs again.
Job Swap The action of selecting an existing load not assigned to the user, and picking jobs to transfer onto the user's load.
Signature Capture Usually the final action of a job, where the customer's name and signature are entered.
Other Definitions
Reason Code A code which represents the reason that a job was cancelled or an item was cancelled or claused.
Vehicle The vehicle used for transporting the goods.
Vehicle Checks Also Defect Checks. A series of questions representing the results of checks intended to ensure the vehicle is in an acceptable condition.
Metrics Entry A series of questions to capture information either at the start or end of a 'Load'.
Driver The person performing the collections or deliveries; the user of the device/application.
Engineer The person performing the services; the user of the device/application.
Customer The person/company the goods are being collected from or delivered to.
Signatory The name of the person providing a signature.
T&Cs Terms and Conditions. The T&Cs are shown when signatures are prompted for. The text of the T&Cs are defined in the system itself.
Transfer Load A load select from which to swap jobs to the user's load.
Base E.g. 'Return to Base'. Typically the depot from which the driver departed.
Unplanned Ad Hoc Collection A collection job that is created by the driver, usually after delivering to a customer.
Ad Hoc Container Entry/Scanning The process of adding containers (items) to a job that have not been pre-advised on the job.
Completion Report POD, POC, Service/Work Report.
Load Assignment The action of assigning a vehicle and/or a driver to a load.
Job Assignment The action of putting jobs onto a load.
Collection/Delivery Windows; Access Windows Periods of time between which it is acceptable to deliver or collect from that customer. This has limited use in the system, mostly for reporting purposes.
Location/Map Terms
Lat-Longs; GPS Co-ordinates, GPS Position Latitude and Longitude co-ordinates, specified together as a single entity, identifying the exact position of a location. There are multiple formats - CALIDUS ePOD uses decimal notation, for example "53.3490818,-2.8521498" identifies the OBS Logistics office building in Liverpool.
GPS Global Positioning System; the satellite system used to obtain a GPS position, for use with navigation and location positioning.
Geocode; Reverse Geocode Geocoding is the process of obtaining lat-longs from an address. Reverse Geocoding is the process obtaining an address from lat-longs.
Geofence; Geofence Break A Geofence is a perimeter around a location. A Geofence Break occurs when a device passes through this perimeter on entry or exit from the location.


B.3 Authorised By


Stuart Mylchreest

Customer Representative
_____________________________

Murray Middleton

OBSL Project Manager
_____________________________

Matt Turner

OBSL Product Manager
_____________________________