Mondelez International

Mondelez C-ePOD Solution Design Overview

CALIDUS ePOD

12th March 2020 - 0.1
Reference: REQ 371213

Introduction

This document is the Mondelez C-ePOD Solution Design Overview.

Objective

The primary purpose of this document is to respond to the ITT from Mondelez, referenced in the appendices.

Scope and Limitations

This document is based on the documentation provided by Mondelez International, as referred to in the appendices.

Client Requirements

Listed below are the proposed processes that will be followed by the operatives using CALIDUS ePOD.

The current operational process flow has been described in the documents provided by the customer, as referenced in the appendices.

Operational Information

Customer contacts:

Jamie Broughton - [email protected]

Overview of Solution

Solution components:

WMS:
- AutoStore - used at Minworth, Skelmersdale.
- LWS - used at Bicester.
- iNet - internally developed, creates delivery notes, potentially where the link to C-ePOD will originate, to be confirmed.
CALIDUS ePOD - Collection/Delivery execution, product delivery, signature capture and POD document production.
CALIDUS Portal TTM - Track and Trace module, comprising transport, trusted customer and end customer tracking.
CALIDUS Assist - help pages, training, reference and user guides.
SAP - Mondelez ERP.

The CALIDUS ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface and a client application for use completing tasks.

The system supports three job types at this point, which encompass the functionality to complete many more tasks with them. You can use the system to complete and record; Deliveries, Collections and Services.

The C-ePOD administration software is a web-based application that handles all of the administrative side of the tasks completed on mobile devices by the C-ePOD mobile device application.

The main purpose of the application (amongst others) is as follows:

To create and maintain users of the ePOD devices.
To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
To create Jobs of all types and group them together onto Loads/Workloads, and sequence the jobs appropriately.
To resource Loads (to Users and/or Vehicles).
To view the Jobs and Workloads created.
To print or email a POD.

The CALIDUS ePOD mobile app is an Android-based application, that handles all of the operational functionality for the execution of delivery, collection and service calls.

The mobile device application allows users to connect and receive load data, consisting of a load and a series of associated jobs. It provides the functionality to process and complete these jobs electronically in the field. The application allows processing of Services, Collections and Deliveries. The application is reliant on a network connection either GPRS or Wi-Fi to retrieve load data, but is not reliant on a connection to complete them, as once jobs are complete, data will be stored on the device until the next time the device has a connection and the application is running. Static data (such as site information) will be stored locally - this is downloaded once during the login process, if a connection is present and the data requires updating.

CALIDUS Portal TTM 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.
Contracts/Owners.
Customer Service Queries.
Transport Office.

CALIDUS Portal TTM 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.

CALIDUS Assist provides help pages, from user guides to technical implementation guides, from simple to advanced, to provide as much information on how to get the best out your CALIDUS systems implementation and ease the uptake of the CALIDUS systems and minimize training.

CALIDUS Assist is based around industry-standard MediaWiki systems and is accessible through a browser either directly from your systems (for example, C-ePOD Admin), through a bookmark in your browser, or on your mobile device.

C-Assist C-ePOD page on desktop browser.

Solution Detail

Interface in

Jobs and loads will be interfaced into C-ePOD from the WMS.

C-ePOD supports several standard interfaces, from XML to CSV. Given some of the complexity of the jobs, it is considered likely that the C-ePOD XML formats will be used.

The C-ePOD XML interface import files may be sent to C-ePOD through a flat-file interface or directly sent to a web service endpoint. All details of loads and jobs may be sent through thr interface, as well as the resources and standing data that the operation needs. All resources and standing data may instead be maintained directly within C-ePOD, if the facilities do not exist to maintain this within the existing systems.

Alternatively, OBS Logistics has great experience developing bespoke interfaces for customers, so if the facility doesn't exist to generate these files within the WMS in this format, OBS Logistics can be engaged to develop the interface within C-ePOD and pull the data on request.

It should be noted that a deeper understanding of the WMS capabilities regarding planning orders and trips and interfacing methodologies is required before any decisions can be made regarding the interface structure or content. However, this solution assumes that the orders will be planned onto multiple trips (trunk and radial, loading and unloading) and sent in with all required information to enable the jobs to be assigned and executed through C-ePOD, and tracked through C-Portal TTM. Although 2 WMS systems are in use at the sites, it is currently expected that iNet will be the source of message to CALIDUS systems.

Admin Processes

Once jobs and loads have been sent into C-ePOD, the loads and jobs can be viewed through the C-ePOD Admin console.

Workloads.
Job details.
Job address.
Pallet information.
All products.
Single product details.

Note that functionality exists within C-ePOD to manually create work loads, assign resource and sequence jobs.

In terms of resourcing, C-ePOD requires trips to be assigned to either a vehicle or to a driver, so that they can be picked up by the mobile device application - drivers aren't allowed to selected their own trips. Jobs can be assigned to either driver or vehicle or even both.

The C-ePOD admin system links directly to the CALIDUS Assist help system to help users through using the system and discovering new features. The same is true of the mobile application, and other CALIDUS systems.

CALIDUS Assist for C-ePOD.

Mobile Devices

The C-ePOD mobile device application runs on Android mobile devices. They can be be tablets, phones, phablets or any other configuration, in landscape or portrait orientation - the mobile device application will display the screens making the best use of the available space and orientation. There is a special tablet mode that can also be used on certain devices, which makes the display make best use of high resolution, large screen space devices like this.

The mobile app supports barcode scanning for most data capture fields, for app configuration and for scanning products and containers. The app supports integrated barcode scanners used as a 'keyboard wedge', and also has an integrated or BlueTooth camera scanner function, where any Android device with a camera can be used to scan a barcode for a field, when this field is configured to capture barcodes.

The style of the application can be modified for Mondelez International if required, although the standard style will display the site logo for the application. Certain screens within the mobile application benefit the users if they are styled to add or remove items from the screen - the areas that will most benefit the operation will be indicated in the individual sections below.

Typically, our customers like to control the downloading of the mobile device application themselves. OBS Logistics can host the mobile application as part of the solution - as long as the Android mobile device allows side-loaded applications, the application can be installed on any device from Android KitKat (4.4) onward.

Typically, we provide QR barcodes to our customers for downloading the app, and for configuring the application to talk to their system. That streamlines the commissioning of new devices and should make the app easily usable for third-parties or substitute carriers.

The app has been built to modern standards - this is not a web page, but a full Android application that sits on the device. The app responds like any other application, so if the user is used to the standard Android features like clicking, swiping, zooming, tabs, switching apps, etc, they will be very comfortable using the C-ePOD mobile app.

The CALIDUS Assist pages will also be available in a mobile form, meaning that the users can access help at all times through a browser.

C-ePOD Assist on mobile.

Logging in

Once the app is downloaded and configured on the mobile device, the driver can start the app and log in to the app. They are always prompted for a user, password and vehicle.

Styled login.

Vehicle checks

Once the driver has logged in, the app will check whether the vehicle needs any vehicle checks. These can be configured for the organisation with any number of checks and data entry and support tracking defects and resolution notes within the C-ePOD admin application.

Configured vehicle checks.

These checks need not be enabled.

Getting a workload

At this point, the device will download the next workload assigned to the driver. It is thought at this point that the seal numbers may need to be captured against the trailer.

List of jobs on the workload.
Capturing configurable data at the start of the workload.

These checks at the start of the load are fully configurable - you can add any number of items here for the driver, including check lists, reminders, ODO readings, etc. They can also be disabled.

The jobs on the workload will be shown on a list like an electronic summary driver manifest. The details that are shown against each job are configurable, so the application can provide the best information to the driver.

Workloads support collection and deliveries, loading and unloading at depots, trunk loads and radial deliveries. For the purposes of this document, we will assume a standard radial delivery.

The driver selects the job from the list to start it.

Starting Jobs

The mobile application will show the details of the selected job from the list in a multi-tabbed display.

Job details.

At this stage, the driver has not yet departed - they can check the details of the address and any contact information for the customer. If the phone supports it, they can contact the customer (through phone or SMS).

The app will always make sure that any instructions on a job have been viewed by the driver before starting the job.

Once the job is started, the date, time an position are captured and sent on to the CALIDUS systems, so that you and your customers can see the job in progress. From this point, the app will track the position of the driver and periodically let the CALIDUS systems know the current location, to that ETAs can be calculated and displayed.

The map button allows the driver to select and start their favourite installed mapping application for navigation to the destination - whatever is installed on the mobile device will start and immediately navigate to the provided address or co-ordinates.

Arriving jobs

Once the driver has used the navigation app to get to the destination, they can easily return to the C-ePOD mobile app and indicate that they have arrived. The driver will at that point be asked to enter the trailer seal. This can be validated against the expected seal if provided.

Configurable arrival process, capturing Seal information.

This arrival process can be extended to capture any other data required by the operation, even providing site arrival terms and conditions and driver signature of acceptance if required.

Again, the CALIDUS core systems are immediately updated with the arrival to the location, and the device will move on to executing the job.

Job Details

The app will the job details on a multi-tabbed display.

General information, extensible with any additional information required by the operation.
Products - details of all the products being delivered on the job.
Notes - any driver notes.

The tabs that appear and the layout of the data on the tabs can be configured, especially the products list, to ensure that the most important information is displayed to the driver.

Note: Although this document focusses on delivery, the same application is used for collections, loading and unloading jobs, on trunk and on radial trips. The processes for each of those activities can be configured and modified such that the driver is only asked to complete the stages and data entry as is required on the job at that time.

The summary job information will be display first, including the driver instructions as a reminder. This will be extended to allow the driver to see the pallet information.

Summary delivery information.
Pallet information, with entered data.

The product tab shows all of the products to be delivered.

Configurable list of products.
Product actions.
Delivered product removed from list.
Full product information pop-up.
Product exception process.

The driver can deliver a product by scanning the product code from a barcode, maunally keying the product code or selecting the product from the list. The application will display a pop-up list of actions, where the driver can elect to deliver all, some or none of the product, see more product information, enter some comments or cancel the product delivery altogether.

Any exceptions from the norm of delivering all of the product will start an exception process where the driver can select a reason code for the change, see the quantity (with cases and units displayed if the product requires it) and take photos of the product if required before confirming the change. This can even be extended to allow data capture relating to individual reason codes if needed.

Once all products have been confirmed as delivered, the application will move onto job confirmation.

Confirmation of job

As with other aspects of the mobile application, job confirmation is a configurable process. For end customer deliveries on radial trips, it is expected that the application will request the following:

Customer signature.
Driver signature.
Optional photo capture.

Customer signature with configurable T&Cs.
Delivered products summary.
Driver signature.
Job photo.
List of job photos.

The mobile application supports the customer signature with name (signatory) capture, customisable terms and conditions and a list of all products delivered.

The terms and conditions are expected to consist of a "Signed Unchecked" tick box and customer comments, to enhance the existing offering of reason codes and clauses. Any standard T&Cs can be added as labels for the customer to read before signing.

The driver signature can be configured for data capture and T&Cs as well, although this is not expected to be required.

After that, the app can be configured to ask the driver to take photos of the delivery or be enforced to do so. On that, images are unlimited on the application, and are all stored against the job for viewing later, or even exporting to customers and external document management systems. They can be configured at any point in the application where additional data can be configured.

If the customer is unavailable (or this is an unmanned delivery), the driver can sign alone, in which case at least one photo is required, to prove delivery.

Job Completion

As soon as the driver completes the job, the gathered information is sent back to the CALIDUS systems (data connection permitting). This tracks amendments and cancellations, with reason and clause codes, as well as actual times.

Once this has arrived, the information is available for viewing within the C-ePOD Admin system.

Completed job information.
Completed pallet information.
Completed product information.

Once all the information has arrived (including all of the photos, if required), this information is available to be reported and exported.

The reporting system within C-ePOD allows us to perform quick modifications to style and layout to produce reports in customers' own formats.

The POD report can be called off on demand through the Admin system, automatically generated and emailed to end customers or only sent when there are errors or amendments, all configurable within the system. The reports are produced to the screen and/or emailed/sent as PDF or image files.

The report format provided has been prototyped and can be seen below:

Custom POD format as produced from C-ePOD.
Images as part of POD.

The format is configurable as to how images are added to the report, whether they are included in exports, emails, etc, so once configured, you will be in control of the data presented to your customers.

The C-ePOD system supports export to many external tracking systems, such as Palletline, Pallex, Fortrack, Hazchem and of course our own C-Portal TTM. It can also be configured for document management systems exports and pushed updates to web services in the C-ePOD XML format. In most cases, these can be configured at the same time. So, there is plenty of scope within the product to export in our dedicated format.

Alternatively, this information is available on demand, pulled by external systems through other web services methods.

In many cases, OBS Logistics have been approached to write bespoke interfaces, sometimes through EDIFACT gateways, to get information exported to the right final destination. Once we have discovered the requirements in this area, we will be able to include this in the project costs.

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.

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.

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

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

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.

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.

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

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: 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: 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: 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 No	Document Title & ID	Version	Date
1	Scope of Work.docx	N/A	N/A
2	Delivery Process v1.pdf	1.0	N/A
3	DN POD Example.pdf	N/A	N/A
4	Pre-delivery Process v1.pdf	1.0	N/A

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

Warren Wright	OBS Representative	_____________________________
Jamie Broughton	Customer Project manager	_____________________________

Anonymous

Search

SDD 371213 Mondelez EPOD Solution Design Overview

Namespaces

More

Page actions

Contents