SDD 371336 MFS C-ePOD Solution Design Overview

From Calidus HUB





Aptean Logo.png







Marshall Fleet Solutions

C-ePOD Solution Design Overview

CALIDUS ePOD

8th April 2020 - 0.3
Reference: REQ 371336











































Introduction

This document is the C-ePOD Solution Design Overview.

Objective

The primary purpose of this document is to document the requirements gathered from Marshall Fleet Solutions, and to provide an overview of the solution that is proposed.


Scope and Limitations

This document is based on meetings with Marshall Fleet Solutions.

The solution contained here is subject to workshops with the customer technical and operational teams.


Client Requirements

The operation primary wants a system by which a text or email link notification can be sent to the the drivers that the engineers are going to service. This email would contain a tracking link, so that the drivers can see when engineers are going to arrive.

The operation also wants to capture a walk-around video, to help with the inspection process and to use to show the additional work that may be required.

The operation wants to host all information regarding calls through a new Portal, for all needs (track and trace, customer access, document downloads, etc).

The whole process should be managed without any additional middle-ware for message transfer.

The operation wants vehicle defect checking, accident reporting and equipment tracking.


The detailed requirements and solution will be gathered through a series of meetings with MFS technical and operational representatives:

  • Call with MFS representatives with an overview, plus interfacing discussions - 20th March - complete.
  • Call with CDK Autoline representatives for interfacing discussions - 3rd April - complete.
  • Follow-up call with MFS representatives regarding interfacing discussions - 7th April - complete.
  • Presentation to the project sponsors on 24th March.
  • 1 day deep dive workshop will be organised with the working MD, technical and operational staff after this (not yet agreed).

CALIDUS VEhub will be set up in the interim and training will be arranged to get demo units on the flow.


Operational Information

Website: https://marshallfleetsolutions.co.uk/

Registered Office:

  • Marshall Fleet Solutions
  • Airport House
  • The Airport
  • Cambridge
  • CB5 8RY


Fleet Management Services operates a premium support network in the UK for LCV operations.

MFS are specialists in fleet management for .com organisations with a dedicated team of controllers and VMU's around London with a full partnership supplier support across UK.

There are over 2,000 assets running on full repair and maintenance contracts nationally.

MFS has proven experienced support team of 200 mobile service engineers and wholly owned service centres across Britain.

Ancillary assets covered include transport refrigeration equipment, tail lifts, shutter doors, lifting decks and couplings, as well as tyres, windscreens.


Their primary ERP tool is CDK Autoline, managing the service execution through RoadsideTech, a module of CDK Autoline.

There are 20 planners using WEBFLEET to find the closest engineer, manually allocating through Autoline and sending to RoadsideTech.


Contacts:


Current Operational Process

Currently, the operation uses the following components:

  • CDK Autoline - Work-flow and order management.
  • RoadsideTech - surface application for service completion.
  • WEBFLEET - tracking vehicles.
  • A variety of timed reports - used for exports to a portal.
  • Bespoke Portal - viewing reports.


Marshall operatives receive a call with all details into Autoline.

Marshall users use WEBFLEET to find the closest engineer to the point of call, using the map facilities within WEBFLEET and the current location of all vehicles.

Marshall Autoline users create the job and assigns to that engineer. That action makes the job available to RoadsideTech.

CDK Autoline is not linked to WEBFLEET.

The operative travels to the service point and does a vehicle inspection. Any additional work that is noticed at this point is referred back to the office staff, for authorisation to do this work as part of the service.

Regardless of this, the operative completes the contracted service work, capturing all details within the RoadsideTech surface application.

On completion, this information is passed back to CDK Autoline.

Timed reports run (both frequently and infrequently) to extract the service report and engineers notes out to an existing Portal.


Overview of Solution

The following systems will be used in the solution:

  • CDK/Kerridge Autoline - Dealer management system - work-flow and order management.
  • RoadsideTech - service job completion, integrated into Autoline.
  • WEBFLEET - vehicle tracking.
  • CALIDUS ePOD/eServ - workload management, resourcing, inspection service job completion, TomTom/WEBFLEET navigation interface.
  • CALIDUS Portal TTM - track and trace, customer tracking alerts, completion report/attachments view/download.
  • CALIDUS VEhub - vehicle defect reports, accident reports, equipment tracking.
  • Solution Schematic

    Solution Schematic

The operation will be using WEBFLEET Pro8 devices for the C-ePOD application and navigation.


Solution Detail

Job Creation and Interface

Marshall operatives receive a call with all details into Autoline.

Currently, most jobs are to defined addresses (i.e. street/postcode level). However, some jobs are to less defined addresses without a postcode. In this instance, it would be desirable for the job to have defined GPS co-ordinates, so that navigation to the call is accurate. MFS have confirmed that functionality to select a point on a map to capture GPS co-ordinates is available in Autoline, but that this feature has not been evaluated in some time.

Marshall users use WEBFLEET to find the closest engineer to the point of call, using the map facilities within WEBFLEET and the current location of all vehicles. This process is expected to continue.

Marshall Autoline users create the job and assigns to that engineer. That action makes the job available to RoadsideTech. At this point, the job will be interfaced to C-ePOD.

The interface has been subject to further technical discussion with CDK regarding the capabilities.

C-ePOD supports a standard XML web service endpoint for creating jobs or maintaining standing data. At this time, Autoline does not have an interface with C-ePOD, although it is to be noted that we are working with customers on other projects with CDK Autoline at this time.

However, CDK Autoline (of which MFS have the latest version installed) has a standard interface module, including web service interfaces. In that case, the likely implementation will be through CDK Autoline immediately sending the job to C-ePOD through a web service message, likely in CDK/Autoline format, and that C-ePOD will host that web service end point and create workloads and jobs from that message.

Note that this has been investigated during a meeting with CDK. The web service interface (repairOrder) does not push data across to another system - it must be requested. Furthermore, this interface does not show just the orders that have changed, but instead all orders for a date (not time) range. This then supports only a timed interface, with considerable lag due to processing jobs that have been processed before.

CDK mentioned that they have had multiple requests to provide a push interface only of changed repair orders and jobs. However, there is no time-line provided for delivery of this interface, or indeed any commitment to provide this level of interface at all.

There are pre-requisites of using this interface:

  • The system used must be the latest (E32+) version of the CDK Autoline rev8 or drive system.
  • The system must be hosted by CDK - on-premises hosting by customers does not permit the use of this interface.
  • The access to this interface comes at an additional per vehicle per month cost.
  • The access to the API for OBS Logistics requires a significant partner fee investment.


In further discussions with MFS representative, it has been decided that this API is not at this time suitable for the purpose of interfacing data to C-ePOD. Therefore, a flat-file transfer interface through FTP will be created, whereby a CSV report is automatically run every few minutes (or triggered by a user immediately) which is placed into an FTP-accessible outbound directory. C-ePOD will pull these files onto C-ePOD's server, where a process will then upload this CSV and create workloads and jobs. It is to be noted that this type of interface will likely introduce longer delays in the jobs being sent between the systems and therefore a delay in starting the jobs.

Note that the FTP server exists within Marshall networks (albeit another part of the business) and the use of this is subject to confirmation with that part of the business and configuration for this use.


The base requirements of the interface are as follows:

  • Autoline engineers must be kept in line with C-ePOD users - an interface exists to do this as standard, although this is likely also required to be created by the interface.
  • Engineers vehicles must also be maintained within C-ePOD and kept in line with the fleet vehicles.
  • The jobs must contain at least one unique reference, typically a job code (or service ID) and a customer reference.
  • The job must have a planned start date and time. Preferentially a planned end (arrival) date and time would be beneficial to measuring KPIs and adherence to plan within C-PORTAL TTM.
  • The job must have a unique customer code and address information. Preferentially, this would include the GPS co-ordinates of the address.
  • Contact information (for example, email address) will be required to send tracking links to customers.
  • Any specific driver instructions.
  • Service/service item details - to be confirmed, but should consist of at least the service type, driver name, vehicle reg, etc. This information is to be confirmed by the deep dive session, which is to be planned after acceptance of this overview.


The details of the interface for these orders will be part of a deep-dive workshop, and will identify the data required to be sent to C-ePOD. Subsequently, a mapping exercise and full solution design document will be created, comprising this overview and a more detailed description of the use of the solution components.

Note Note:

  • Repair order (WIP) tasks can comprise multiple jobs for the engineer to complete. If all jobs are not completed, a job can then be re-scheduled at another time. This retains the same repair order reference. This reference must be unique to C-ePOD, and therefore the interface must provide a suffix to the job to keep it unique.
  • Repair orders can be assigned to multiple engineers. In this case, the repair order ID must be suffixed to ensure that each driver has a unique job reference.
  • Order details may be sourced from the repair orders themselves or from another file structure (Warning Warning: What is this called?), which has fewer details but is easier to access and report from.


CALIDUS Systems Workload Creation

When the C-ePOD Interface imports the job from Autoline, the job is assigned to that engineer's current workload, or one is created for them. The tracking information is sent to TTM as soon as the job is created, to show that the job is received. An email message can be triggered to the contact to show that the order is received.

If the workload is already in progress, the job will be pushed out to the engineer's device within in a few minutes. This interval is configurable - typically, the mobile device will poll for work every minute.

If the workload is not in progress, when the engineer picks up the workload, the job will be on there.


C-ePOD Mobile Execution

On the WEBFLEET PRO8 device, the engineer will be logged in to the C-ePOD mobile app and perhaps also WEBFLEET - note that there is functionality for single sign-on through the WEBFLEET driver and vehicle. However, it is expected that the user name and password of C-ePOD will be kept in line with that of the RoadsideTech users and passwords, to simplify processes for the engineers.

The job will be shown on the C-ePOD mobile app in a job list, showing all work assigned to that engineer. This job list is configurable as to what it shows, but typically this would consist of:

  • The main job/service reference.
  • The start/end date/time
  • Customer Name.
  • Postcode.

Jobs can be selected from the job list and details will be shown, including enforced viewing of any job instructions.

The job is started on C-ePOD mobile app using the Start Job button. The tracking information is sent to TTM to show that the job is started. ETAs will then be available for that job. An email message can be triggered to the contact to show that the order is in progress.

The engineer uses the Map button in the C-ePOD mobile app to switch to WEBFLEET and navigate to the destination. This is automatic - the destination or co-ordinates will be automatically passed to the navigation application by C-ePOD.

When the engineer arrives at the destination, they use the tool-bar button to switch back to C-ePOD mobile app and click the Arrive Job button. The tracking information is sent to TTM to show that the job is arrived.

The C-ePOD application will display some basic information about the service job, and will be configured to capture:

  • Video - a walk-round inspection video, to ascertain if any further work other than the requested work is required.
  • Photographs.

Note that the standard service functionality within C-ePOD can be configured over multiple stages for extensive data capture, such as:

  • Pre- and post-work checks.
  • Parts used or returned.
  • Activities undertaken.
  • Part references (such as barcodes).
  • Diagnosis information/engineers comments.

However, it is expected that this implementation will simplify this process as much as possible, as the RoadsideTech surface application will be capturing the majority of the information.

Any video capture will be capable of being sent directly to the C-Portal TTM job, where is can be downloaded and reviewed by users of that system, which may be MFS customer service or administrative staff, or end customers.

Any photos captured by this application will be available only when the service job is completed in C-ePOD.

The engineer will use the RoadsideTech application on the surface to complete the service, and any additional work on the service.

Once the service is complete in RoadsideTech, the engineer will return to the C-ePOD application, to complete the job there. The job is completed in C-ePOD mobile app by clicking the Complete button. The tracking information is sent to TTM to show that the job is complete. An email message can be triggered to the contact to show that the order is received.

At any point from the order being received, the end customer can track the progress of the engineer through the link in the email. After the job is complete, the customer can view and download the service report generated from RoadsideTech.


Completion

RoadsideTech sends back the service completion information and engineers notes.

CDK Autoline is configured to automatically generate service sheets - this is currently sent to a portal, which has been deemed end-of-life. Under this solution, this information will be instead sent to C-Portal TTM, which will add it as an attachment.

CDK Autoline also separately produces engineer reports, at this time as a timed report, in CSV format. If desired, these may also be sent to C-Portal TTM, and will also be available as attachments.

Note Note: Given that jobs sent to C-ePOD (and therefore being tracked in Portal TTM) may have a different reference to the repair order, it is important that the files are named appropriately so that the attachments are uploaded to the correct job in Portal TTM. The files will need to be correctly named as per the job that was sent to C-ePOD i.e., with the suffix identifying the sub-set of the job or engineer.

C-Portal TTM will also be able to display a service report generated by C-ePOD, which will contain:

  • Basic job information, such as start and end times, references, service information.
  • All captured photos from the C-ePOD service, on a separate page of the report.

C-ePOD will also ensure that the walk-around inspection video is also available as an attachment on TTM.


C-Portal 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 ePOD 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.


Trip/Order Enquiry

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


Order Enquiry

  • Order Enquiry Parameters.

    Order Enquiry Parameters.

To identify the jobs (collection and delivery) that have exceptions (i.e. were not collected/delivered in full), this selection screen allows the user to define the orders to be reported, entering date/time from/to, and selecting delivery exceptions only.

The enquiry responds with a results table summarising the matched orders:

  • Order Enquiry Results.

    Order Enquiry Results.

These results can be expanded for further details of the stops, and the order can be clicked to drill-down into specific details of the order.


Trip Enquiry

  • Trip Enquiry Parameters.

    Trip Enquiry Parameters.

  • Trip Enquiry Results.

    Trip Enquiry Results.

These results can be expanded for further details of the orders, and the order can be clicked to drill-down into specific details of the order.

The screen supports configurable RAG colouration, to highlight trips that are late or incomplete, and ETAs.


Order Details

  • Order and Event Details.

    Order and Event Details.

Details can be found of the following:

  • Events – the Messages received by the TTM system.
  • Info – Details of all of the header information stored on the system
  • Route – Details of the trips/stops that the order is currently assigned to, including all trunk and radial trips and stops.
  • SO Details – the product details received.
  • Reasons – Details of the order level reasons placed against the order.
  • Map – A map of the current location of the order (if co-ordinates have been supplied by an external system). The mapping page will only be available to groups where the 'Mapping' parameter against the User Group is set to 'Available' and where licensing is available.
  • Notes – Allows the entry of user notes against the order. These are only kept on the Portal system.
  • Documents - Allows the upload/view of documents held in the Portal against the order.
  • Order Info Details.

    Order Info Details.

  • Order Route Details.

    Order Route Details.


Trip Details

  • Trip Details.

    Trip Details.

You can drill down into order details from here.


Arrivals/Departures (Order Status) Screen

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.

  • Order Status Screen.

    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.

  • Order Status Parameters.

    Order Status Parameters.


Customer Tracking Gateway

On clicking the tracking link from the external system, the customer is asked to enter the consignment reference (the customer reference) they have been provided and the post code for the delivery location of the order being checked. Note that the consignment number can be sent through from the calling system, to help the customer obtain their details but post code must always be entered by the customer as a security measure.

  • Enter Consignment.

    Enter Consignment.


The gateway then checks the order on the system, matching the customer reference and post code to the information on the system. The search for the order to be checked is not case-sensitive - the gateway will match the entry if entered in upper or lower case, and the postcode entered can be in any format, with or without spacing. If an order is not found that matches the information entered, the screen will display that no information can be found in a pop-up message.

If a unique order is found, the gateway displays a summary of the information on the order being checked, similar to the following:

  • Consignment Tracking.

    Consignment Tracking.


Note Note: Only information from the order being checked is displayed on this screen, as well as some information relating to times and execution of the Trip on which this order is being delivered. At no time is any information from any other order (on this trip or otherwise) displayed on this screen.


The screen displays:

  • The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
    • Ordered.
    • Loaded.
    • Out for Delivery.
    • Delivered.
    • Cancelled
  • Last Delivery Sequence - The number of the last stop serviced on the trip that is delivering the order being checked. Note Note: This is only the stop number, not the full address of the last stop serviced.
  • Your Delivery Sequence - The stop on which the order being checked will be delivered. Note Note: This is only the stop number, not the full order address - this is displayed below.
  • Order Reference - The customer's order reference of the order being checked.
  • Full Address - The full delivery address of the order being checked.
  • Courier - If known, the courier completing the delivery of the order being checked.
  • Driver - The full name of the driver completing the trip on which the order being checked is being delivered.

The screen also displays a time-line bar, showing all the statuses the order being checked has passed though. Successfully-completed statuses are coloured green, and the date/time the status was changed (if provided) is displayed under the status on the bar.


If the order being checked is out for delivery, the screen displays a map showing:

  • The last known location of the vehicle making the delivery.
  • The customer’s delivery location

Note Note: The last known location of the vehicle making the delivery could be the address of another customer receiving a delivery on that trip. However, no address information or labels are shown against the locations displayed in the map and no information is divulged regarding the reason the vehicle is currently at that location.


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.


TTM Reporting

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.


Appendix A: Document References

A.1 References

Ref NoDocument Title & IDVersionDate
1   


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


A.3 Authorised By


Dan Titheradge
OBSL Representative		_____________________________

Martin Heap
MFS Representative		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=SDD_371336_MFS_C-ePOD_Solution_Design_Overview&oldid=8771’