Greene King

CALIDUS ePOD/TTM Solution Design

CALIDUS ePOD

27th November 2015 - 0.2
Reference: REQ 314432

Introduction

This document is the CALIDUS ePOD/TTM Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Greene King from various sales meetings.

This document has been written in a manner such that it can be approved by non-technical representatives of Greene King 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 Greene King, as referred to in the appendices, as well as information gleaned from site visits and workshops with Greene King.

The changes will be made in the latest version of the CALIDUS ePOD system, operating the Android version of the ePOD Client application.
Changes relating to information passed through to CALIDUS ePOD from external systems (i.e. Aurora, DIPS) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
Due to the ad-hoc nature of the expected Returns functionality, no additional process is driven from the entry of these returned products or packaging, for example, the driver will not be prompted to unload all collected products or packaging at the end of the load.
This document covers the implementation of the CALIDUS ePOD and Portal TTM systems for Greene King. A separate project exists to integrate Planned Vs Actual reporting with information from TomTom WEBFLEET, and will be covered in another design document, or integrated into this one at a later stage.

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.

Operational Overview

Warning: Greene King Distribution information here.

Overview of operation
Geographical coverage
Number of depots
Number of devices/drivers
Number of loads
Number of jobs per load
Average products per job
Average products per category

Project information

Device Type
Contact information
Project team
Timelines

General System Overview

The core systems are Aurora (ERP) and DIPS (Route Planning), with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal TTM).

Orders come into Aurora.
Aurora interfaces the orders to DIPS, for Routing purposes, then back to Aurora.
Aurora interfaces loads and orders to CALIDUS ePOD (trigger to be defined).
CALIDUS ePOD sends driving instructions to TomTom WEBFLEET on demand.
TomTom WEBFLEET used for navigation to destinations.
CALIDUS ePOD executes the deliveries and returns.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.

System Overview

Data Import

All files (inbound to and outbound from CALIDUS ePOD) will be transferred using an FTP method in OBS XML format.

All data sent to CALIDUS ePOD will be uniquely identified through a Site ID. This is predominantly used to organise hauliers or depots, ensuring that the data is kept separate for resourcing and execution purposes. All data (for example, loads, jobs, drivers, vehicles, etc) are organised by this Site ID. It is expected that all distribution centres will require their own Site ID within CALIDUS ePOD. Note: This is not strictly necessary, as this could also be categorised by Job Group, as below. It is, however, recommended.

All jobs of any type will be sent to the CALIDUS ePOD system with a configuration element known as Job Group - this will define the process to be followed against each job, such as:

Driver Signature.
POC/POD document format.
POC/POD business address and logo.
Terms and Conditions displayed.

The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will possible need for several Job Group configurations:

Deliveries
Returns (Product and/or Packaging)

Note: Collections of Packaging alone may require a different Job Group, depending on the functionality required. However, this will be entirely ad-hoc by the driver on the device (i.e. not a preadvised product return) and therefore requires no interface from Aurora.

If Job Groups are sent to CALIDUS ePOD that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration.

The exact confirmation of the Job Group configuration will be decided at implementation stage.

The Jobs and Loads themselves will be interfaced with the data required to complete the jobs. This will be mapped outside of this document.

Details for each Delivery job include: Warning:

Load ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within CALIDUS ePOD unique.
Product Descriptions are 40 characters within the CALIDUS systems - this is consistent with the length supported by Aurora, which appears to be up to 30 characters.
Planned Delivery Product quantities are required.
Planned Return quantities may be defaulted to 0 and will be forced to be entered (if advised - see the Product Returns process later in this document for details).
Customer Details:
- The addresses shown on the POD are expected to be the final delivery or collection address, set from the customer.
- Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
Consolidation - When delivering orders, there could be multiple deliveries per address. Consolidation of orders at delivery/collection is required. This may be controlled manually by the driver, but is more commonly controlled by the jobs being linked together on the loads received by CALIDUS ePOD from Aurora.
An Owner must be specified against each job. It is expected that this will be the same for all jobs and will be agreed during the mapping exercise. This is used to consolidate all jobs for the purposes of track and trace (through CALIDUS Portal).
Optionally, products may be 'containerised' i.e. categorised by product group for deliveries (e.g. Cask, Wine, Spirits) etc, if this is helpful to the drayman.
Multiple Time Windows may be required to be sent to CALIDUS ePOD - these are subject to a change detailed later in this document.

Several types of collection jobs may be specified:

Product Returns - these may be planned by Aurora, but may also be Ad Hoc collections generated by CALIDUS ePOD, or ad hoc product returns as part of the deliver process.
Packaging Returns - these may be Ad Hoc collections generated by CALIDUS ePOD, but could also be captured as part of planned product returns or planned delivery jobs if required.

Note: OBS Logistics have created standard Interfacing documentation and this will be passed to the Aurora development team. At this time, no mapping exercise has started. There are no expected modifications of the interface within CALIDUS ePOD, but it falls to OBS Logistics to specify and control the modifications to external systems.

SCR-314432-1:

ePOD-Aurora Integration meetings and specification.

There are additional interfaces to CALIDUS ePOD in order to keep standing data in line within the system, for example:

Drivers - used to allocate loads to drivers
Vehicles - used to allocate loads to tractors/trailers/vehicles
Reason Codes - used when exceptions are encountered (cancelling jobs, containers, products, changing quantity)

Each of these items can be agreed in advanced or administered within CALIDUS ePOD, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in CALIDUS ePOD, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created.

As part of the interface mapping exercise, this standing data will be agreed, regardless of whether the interfaces above are implemented within Aurora.

Note: It is expected that the standing data will not be transferred through from Aurora to CALIDUS ePOD. It will be a manual process to keep both systems in line. At a later data Greene King may perform development to send standing data to CALIDUS ePOD.

Note: Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Aurora or any routing systems attached to it, then the CALIDUS ePOD Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into CALIDUS ePOD, CALIDUS Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

Administration

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 ePOD administration software is a web-based application that handles all of the administrative side of the ePOD devices.

The purpose of the application can be broken down into the following sections:

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.
To assign Loads to Users.
To view the Jobs and Loads created.
To view, print or email a POD.

Note: If loads are not assigned to Drivers or Vehicles through the Aurora interface, CALIDUS ePOD provides a facility to manually assign Loads to drivers, through the following mechanisms:

Through the Load, assigning a user directly
Through the User, selecting from any Pending Load.

Assigning a User to Loads

Assigning Loads to a user

Vehicles will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens.

Multiple Time Windows may be required to be sent to CALIDUS ePOD - these are subject to a change detailed later in this document. These will be visible and maintainable within the Jobs admin screen.

A full guide to the use of the system can be found referenced in Appendix A.

PDA Login

The application will have a customised style created for Greene King, which will include:

Customer colour scheme
The logo on the login page.
An appropriate level of information on the Product list.

SCR-314432-2:

Create customer-specific style on device.

Login

Additionally, the layout of certain on the tables and may be modified if required, and confirmed before development begins on the project work.

The drivers will be provided a user-name and password, and the loads will be allocated to specific drivers, ensuring that they can complete only the loads required. The users and their passwords must be configured within CALIDUS ePOD.

A driver logs on to a device using their provided user name, password and vehicle. The device will remember the last used User name and Vehicle, but will always require that the password is entered.

Obtain Workload/Job List

When logged on, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. Again, this is fully configurable as to what is requested and could include:

ODO - Required numeric entry
Load Secure Visual Check

If configured, Load Metrics must be completed before the trip may be started. It is not expected that Load Metrics are required for Greene King.

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

Job List

The list of the jobs on this load will show the following:

Job Reference - configured to be one of the following:
- Job ID - ePOD internal unique job reference
- Job Code - as mapped from Aurora
- Cust Ref - as mapped from Aurora
- SO Ref - as mapped from Aurora
- Ext Ref - as mapped from Aurora
Job Type - Collection/Delivery
Customer Name
Postcode
Planned Date/Time

The screen will display the status of the jobs on the load through a coloured outline, as follows:

Red - Cancelled
Green - Completed
Blue - Completed (with amendments)
Yellow - In Progress
None - Pending/Incomplete

Note that this status is also displayed prominently in the Job Details screen (detailed in the following section).

The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.

The Menu button can be used here to allow the following options:

Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
Refresh - Refresh the Load/Work-list
Consolidate or Deconsolidate groups of jobs

The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:

No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed.
Confirm re-sequencing allowed - this requests the user to confirm first.
Always allowed - no confirmation.

This configuration will be decided at the point of implementation, but is expected that re-sequencing is not allowed.

If any jobs have been added to a Load while the load is in progress, the Refresh option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing Cancel from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

The system may be configured for Image Capture in the following ways:

Force Image Capture at all times when cancelling or changing quantity (i.e. at Job and Detail level)
Optional Image Capture at all times.

Separate to the above configuration, Image Capture at the end of a job (if enabled) may be configured to be optional or required.

The driver may choose to consolidate jobs together, to process them together for speed. This is available through several options on the device, allowing:

Manual consolidation, by selecting all jobs to be consolidated individually, accessible through the Consolidate menu option.
To group single jobs with other consolidations, through the Create Group option accessed when long-pressing against a job or consolidated group.

Additionally, jobs may already be consolidated together when the load was created - this is expected to be the case for the appropriate jobs received from Aurora. Note: This functionality can be disabled if not required.

When consolidated jobs are present, a single line is shown summarising the information from all the jobs (i.e. total number of consignments, etc). These can be seen in more details when seeing the details of the job (see later in this document).

The driver also has access to several functions to deconsolidate consolidated groups of jobs:

Singly, by selecting the job to split out, through the Deconsolidate menu option.
Breaking the entire group back to single jobs, through the Break Group option accessed when long-pressing against a consolidated group.

Note: This functionality can be disabled if not required.

Job Details

Selecting a job from the Job List will show the driver the job report and customer contact details (on a Job Details screen). The driver can back out of the selected Job and view any Job on the list.

Job Details - Address and Contact
Instructions

The screen has several Tabs, showing:

The Job Type (Collection, Delivery, Service)
The customer details (Customer Code, Name, Address and Postcode)
The contact information (Contact name and number)
The Instructions for the job

Clicking on the tabs will display the information.

If the jobs are consolidated, the < and > buttons can be used to move between the all the consolidated jobs, to see any specific details. The Instructions tab will show all instructions for all the jobs, as well as any additional information passed through for the job.

The screen allows the user to contact the customer (through text or phone).

Warning: Initially, it is expected that Aurora map no contact number on the jobs sent to ePOD.

Regardless, if Greene King do not want drivers directly contacting customers through the devices, by phone or SMS, a central phone number may be provided on the jobs from Aurora, to allow the driver to easily contact base.

When the user has selected their Job, they can choose the Job with the Start Job button.

If there have been instructions provided on the Job, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

Note: It is expected that re-sequencing of jobs is not allowed by the driver. If a job is attempted to be started out of sequence, the user will be told this at this point.

When a Job is successfully started, this will take the Job to 'In Progress' status.

Jobs can be cancelled by the driver at this time by clicking the Cancel Job button. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

Warning: It is a future requirement to support multiple delivery windows within Aurora and the CALIDUS suite of products.

SCR-314432-3:

Multiple Time Windows

If enabled, the multiple time windows will be visible on the device in this screen.

The screen allows the user to navigate to the customer's address (available only after choosing to start the job). The device will use any navigation application installed on the device for this navigation. It is expected that this will be through the TomTom navigation application.

Once the user arrives as the destination, they can indicate this and start processing the Job by clicking the Arrive Job button. Note: If navigation and arrival is being controlled through TomTom WEBFLEET, this option to mark jobs as arrived can be disabled on CALIDUS ePOD - The Start Job button will simply start the job.

When confirmed complete, the device will move on to the Delivery or Collection process, depending on the job type.

Delivery Process

It is expected that delivery will be by exception, detailing products for the delivery only - see the following section for details of an alternative configuration.

The following are the standard tabs that are expected to be displayed:

Job Details Tab
Products Tab

Note: There is an optional User Notes tab that can be displayed, allowing the user to enter any notes against the Job before completion.

Note: If Returns of any type are configured for the delivery jobs, tabs for entry of the collected items will be shown here - see section Collection Process for details of this.

The Job Details tab has multiple sections:

Contact information
Address information - if supplied, both current address and origin address are shown.
Job Instructions

The Products tab will display a list of all the products to be delivered, showing:

The Product Code
The Sequence
The full Description
Any Customer Reference associated to this product
The Planned Quantity
The Item Type
The Unit Type

It is expected that, as part of the styling process, the layout of this table will be modified (i.e. elements removed, or resized). The data displayed is dependent on the information passed to CALIDUS ePOD from Aurora. It is expected to be:

The Product Code
The full Description
The Product Type (categorisation, being the Order No + sub-reference, e.g. 3188620 / 00)
The Planned Quantity

If this is a consolidated job, the list will show all products required to be delivered on all jobs, including an indication of which order this product is for. Note: If the same product is present on two jobs consolidated together, the product will appear twice, to allow accurate recording of quantity delivered.

Each product on the list can be confirmed as delivered by either:

long-clicking on the item in the list and choosing Deliver X from the pop-up menu. Note: This option can be removed by configuration if not required.
entering the product code manually and clicking Deliver X
scanning the product code and clicking Deliver X

When marked as delivered, the item will be removed from the list.

The driver can change the quantity by choosing Change Quantity from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed. This will allow entry of quantity, and will display the unit type, for clarification. The product description will also be displayed here.

If a product can't be found on the vehicle, it can be removed from the list with the pop-up option Cancel. Again, the exception screen will be shown where the driver can enter the reason why.

Note: During this exception process (either quantity change or product cancellation), the driver will have the option to take a photo against the product changed. This is optional at the driver's discretion.

When all products have been confirmed as delivered or cancelled, the Delivery process will automatically close and the user will be directed to the Job Completion process.

It is a requirement of this process to allow delivery by exception, which requires a change to the CALIDUS ePOD system.

SCR-314432-4:

Deliver All Functionality

This process involves the driver only indicating where a product quantity is changed or cancelling products. Once the driver has completed the exceptions, the driver may move to the Job Details tab and press the Deliver All button. The device will request confirmation as to whether the driver has completed all exceptions. If confirmed, the Delivery process will close and the user will be directed to the Job Completion process.

Note: If completed inadvertently, it is possible for the driver to back out of the Job Completion process, to make further amendments/exceptions, or to mark cancelled goods as delivered.

Categorised (Container) Delivery

As an option, the jobs may have their products categorised by Product Type from Aurora. This involves using the Order No and sub-reference (e.g. 6188620 / 00) to categorise all of the items by type.

If jobs are received in this way from Aurora, the delivery of these jobs will be through a Containers tab. Note that the label for this tab may be changed as part of the look and feel modifications to the device.

Containers Tab
Products within Containers

From the Containers tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

The Container list may show the following items per line:

Container ID
Type
Status
Total Products
Code 1 (a multi-purpose code)

It is expected that, as part of the styling process, the layout of this table will be modified (i.e. elements removed, or resized). The data displayed is dependent on the information passed to CALIDUS ePOD from Aurora. At this time, it is expected that at least the following will be displayed:

Container ID, being the Order Number and sub-reference
Type - The Product Type e.g. Wine, Spirit, Cask, etc.
Status
Total Products

If there are also loose products to deliver (i.e. uncategorised), a Loose Products container will be displayed in the same way.

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

The products in each category can be delivered by:

pressing on the category in the list
entering the container ID manually
scanning the container ID

The products that are part of this category will then be displayed on the Products tab.

This Products tab acts in the same way as the loose products shown in the section above.

Once all products within a category are marked as delivered or cancelled, the Container list will be displayed again - the category will all products completed will be removed from the Containers list.

Note: It is not necessary to complete all items within a category at the same time - the driver may deliver or cancel any number of products in a category at a time.

An entire category can be removed in one step, by long-pressing against the category an selecting Cancel from the pop-up options. Again, the exception screen will be shown where the driver can enter the reason why.

Note: During this exception process, the user will have the facility to take a photo against the cancelled container, but this is optional.

All other functions described in the previous section are available to the driver, including the Deliver All functionality - in this case, all categories that have not yet been completed will be marked as complete, as well as all products not yet cancelled or delivered.

Note: If completed inadvertently, it is possible for the driver to back out of the Job Completion process, to make further amendments/exceptions, or to mark cancelled goods as delivered.

Collection Process

Warning: Preadvised Product Collections

It is possible that product returns jobs will be advised to CALIDUS ePOD from Aurora. In this case, the collections for these products will appear on the job list as separate collection jobs, and are expected to be after any deliveries for the customer.

Warning: Are products being advised for the returns?

If the product return job has products advised against them, the driver will be able to confirm the returned product from the list, although no additional information will be allowed to be entered against the product, such as:

Ullage Number
Size
BBD
Reason Code
Qty
Auth

If this information is required with preadvised products, a further change to CALIDUS ePOD would be required.

Standard Product Collections

Standard Products collections will display the same level of information as a product delivery, namely:

The Product Code
The Sequence
The full Description
Any Customer Reference associated to this product
The Planned Quantity
The Item Type
The Unit Type

Collection of these goods works similarly to the delivery of products, in that the product may:

be marked as fully collected
have the quantity collected changed
be cancelled.

Note that, if a zero quantity is advised to be collected, the driver can be forced to enter a returned quantity, or can confirm that nothing was collected.

Warning: For the purposes of this solution design, it is assumed that product collections will be through ad hoc entry of returns, as described following this.

It is expected that Returned Products and Returned Packaging will be entered ad hoc on the device. To achieve this, a change will be required.

SCR-314432-5:

Configurable Ad Hoc Returns

Warning: Ad Hoc Product Collections

If configured for Ad Hoc Product Collections, a new Tab will be added to the Collection or Delivery screens, depending on configuration. This is expected to be labelled as 'Prod Return'

Product Returns Tab
Add a Product Return

This tab will show a list of all returns (starting as empty). If the Add button is clicked, the device will display a pop-up window, allowing the driver to enter:

Ullage Number
Size
BBD
Reason Code
Qty
Auth

Note: The detail prompted for in this pop-up will be fully configurable.

Once entered and confirmed, the returned product will be displayed on the list.

Pressing or long-pressing a returned product on the list will allow the user to edit or remove this product from the list.

Warning: Ad Hoc Packaging Collections If configured for Ad Hoc Product Collections, a new Tab will be added to the Collection or Delivery screens, depending on configuration. This is expected to be labelled as 'Pack Return'

Package Returns Tab
Add a Package Return

This tab will show a list of all returns (starting as empty). If the Add button is clicked, the device will display a pop-up window, allowing the driver to enter:

Code/Description, from a drop-down list of packaging
Empties Collected
Empties Remaining

Note: The detail prompted for in this pop-up will be fully configurable in terms of what is entered, what is on the packaging drop-down list, the validation and whether this is required.

Once entered and confirmed, the returned packaging will be displayed on the list.

Pressing or long-pressing returned packaging on the list will allow the user to edit or remove this packaging from the list.

Note: Due to the ad-hoc nature of this functionality, no additional process is driven from the entry of these returned products or packaging, for example, the driver will not be prompted to unload all collected products or packaging at the end of the load.

Job Completion

All jobs will be sent to the CALIDUS ePOD system with a configuration element known as Job Group - this will define the process to be followed against each job, configuring the following items:

The Terms and Conditions displayed
Customer Signature required
Driver Signature required
Completion document format

All of these processes are controlled during Job Completion.

Note: At this time, the expectation is that the configuration will require the Customer and driver to sign for collection and delivery of goods.

The device will prompt for Customer Signature.

Signature and T&Cs
Containers
Products

The signatory will default to the customer contact sent through on the job, but this can be changed. If one is not sent through, the driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:

Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
Pallets and Totes collected/delivered.
The products and quantities collected/delivered.
If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

When the customer signature is entered and confirmed, the device will prompt for Driver Signature. The signature screen is extremely similar to the Customer Signature, but the Driver name is fixed, and the tabbed area is left blank.

Driver Signature

As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

The user will be returned to the Job List screen and the completed Job will be removed from the list.

Next Job

If a planned return job (product or packaging) has been advised from Aurora, the device will immediately start the collection job for this customer.

If packaging is to be returned, it may be identified as part of any planned return job. However, if there is no planned return job, the driver may generate an unplanned ad hoc collection on the device.

Create an unplanned collection
Unplanned collection details

The device will prompt the driver after all planned deliveries and collections for a customer are complete, asking whether an unplanned collection is required at this location. If the driver confirms this, the device will generate an unplanned collection and this can be used to add returned packaging, as described above. Note that the last location visited can be used to create an unplanned collection at any time, from the Job List menu.

Post-Load

Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.

At this time, if configured to do so, the device will prompt the user to enter Load End Metrics.

This is fully configurable and the requests could be:

ODO - Numeric entry
Fuel Cost - Numeric entry
Litres Bought - Numeric Entry
Parking Ticket Number - optional text entry

It is not expected that metrics are required for Green King.

Once complete, the device will attempt to download a new load for the user and/or vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.

POC/POD Documents

Note: The POD document format has been provided as a sample, and has been prototyped as below:

Prototype POD Format

This format includes details of any product/packaging collections linked to it.

At this time, the following elements are on the POD format, and can be supported by the CALIDUS ePOD system, except where indicated.

Header

Greene King Distribution Centre Address/contact.
Logo

Deliver To:

Customer or Job Address information

Delivery Instructions: Any special instructions received against the delivery job.

General Information:

Order/Del. No
Order Ref
Order Date
Deliv. Date
Customer No
Page
Route No - Warning: If required, requires a further change - can this be removed?
Load No
'EA' - Warning: Confirmation of what this is and whether it can/should be removed

Delivery Information - produced per product being delivered:

Code
Description
Qty
Comments

Returned Packaging Materials - produced from packaging returns jobs from this customer on this load:

Description
Code
Empties Collected
Empties Remaining

Returned Product - produced from product returns jobs from this customer on this load:

Description
Ullage Number
Size
BBD
Reason Code
Qty
Auth

Footer:

Contact Numbers - taken from the Greene King Distribution Centre (Site) address information.
Customer Signature
Customer Print Name
Drayman Signature
Drayman Print Name
Delivery Time
"GOODS RECEIVED AND EMPTIES CORRECT"
"Received goods & returned empties as detailed"
"Delivered goods & collected empties as detailed"

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job. Collected Packaging and Products will be present only on the first page and care should be taken to ensure that these sections fit on this page.

No images will be shown on the POD note, whether they are taken on the device or not.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into and will be confirmed after discussion with Aurora and at functional specification stage.

SCR-314432-6:

POD Note Format

Data Export

Warning: All files (inbound to and outbound from CALIDUS ePOD) will be transferred using an FTP method.

When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems. This is also true of cancelled jobs. All completed and cancelled Jobs may be transferred to Aurora through the standard interface. This is a pushed update, sent at a configurable interval, usually every 5 minutes.

There are no expected changes to the existing export format or methodology. The information regarding this interface and the format of the data contained within will be forwarded to the Aurora consultants.

For jobs that have been completed, POD documents may be automatically be sent to the customer. In this case, the jobs that require this would have the email address populated when the job is sent to . As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

Note: This feature requires access to a mail server for the use of the customer. If this is hosted by OBS Logistics Ltd, this would be expected to be through the OBS Logistics mail server.

Automatic emails may also be sent to a central email address if required. This may be configured at any time.

The CALIDUS ePOD system may send POD notes via FTP or other file transfer to an external document handling system. The files may be images or PDF format, and the name may be configured in several different ways.

Further Reporting and Queries

The CALIDUS ePOD Admin system allows admin users (i.e. non-PD users) the ability to access loads, jobs and product details, as mentioned previously.

When jobs are being processed, the status of the jobs and loads changes to show progress:

Pending - not yet assigned to a driver.
Assigned - Assigned to a driver, but not yet started. This is highlighted grey.
In Progress - Started by the driver. This is highlighted yellow.
Complete - Complete by the driver - This is highlighted green.
Cancelled - Job cancelled by the driver. This is highlighted red.
Complete (With Amendments) - job completed, but not exactly as planned. This is also highlighted green.

POD/POC reports and full product details can be accessed from this screen.

User activity may also be accessed, to show auditing of messages from the user, for example:

Log on
Vehicle defect checks complete
Load picked up
Job started
Job arrived
Job completed
Load completed
Log off

GPS co-ordinates will be shown here, if accurate and available on the device at the time the messages are sent.

Track and Trace

CALIDUS Portal TTM (Track and Trace) 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

It is expected that ETAs will be shown on the Portal - this functionality requires the purchase of a Nokia Maps account. If the system is hosted through OBS Logistics, this cost may be part of a hosting agreement.

The following is a brief description of functionality available within CALIDUS Portal TTM Module - full user guides are referenced in Appendix B.

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

Note: A requirement of the customer (Non-compliance Report) is to be able to export details of all 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 Trip Stops, and the order can be clicked to drill-down into specific details of the order. This table data can also be exported to XML format in multiple ways:

Manifest - Trip/Stop information
Manifest/Order - Trip/Stop/Order information
Order - Order Header information
Order Detail - Order Header / Order Detail information
Order Events - Order Header / Event information

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. This table data can also be exported to XML format in multiple ways:

Manifest - Trip/Stop information
Manifest/Order - Trip/Stop/Order information
Order - Order Header information
Order Detail - Order Header / Order Detail information

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

Order Detail

Order Details

Details can be found of the following:

Events - the messages received by the LOTS system via WMS, TMS and other systems.
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.
SO Details - the Stock details received from the TMS or WMS.
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.

Airport Screens

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.

Sample results pages:

Arrive/Depart screen

Order Status Screen

Both screens allow the user to drill-down or expand on data to get more details, through pop-ups or further details screens.

If present and the CALIDUS systems are configured for their use, the multiple time windows will be used to display the RAG colouration in the Airport screen.

If delivered within the delivery window for the order, the order will be shown green
If delivered outside the delivery window, but within any of the customer time windows, the order will be shown amber
If delivered outside of all the windows, or the order has been cancelled or otherwise has a variance on quantity of products, the order will be shown red.

Vehicle/Driver GPS Tracking

CALIDUS Portal and CALIDUS ePOD provide GPS tracking of vehicles and drivers.

GPS Tracking Parameters

GPS Tracking Results

GPS Tracking Map

Tracking Emails

CALIDUS Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

Portal Events Maintenance

If enabled, each event has a button which will take the user into the Event Email maintenance page.

Portal Events Maintenance

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:

Contact Name
Owner
Order Number
Booking Reference
TMS Reference
PO Reference
Customer Name
Planned Arrival Date/Time
Delivered Date/Time
Signed By
Tracking Link (only Body)

Customer Tracking Gateway

On clicking the tracking link from an external system or email, 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. Note: This functionality requires the use of HERE maps for calculation of the ETA.

If provided to CALIDUS Portal, this screen can also display the Signatory and Signature on this gateway screen, when the order being checked is marked as Delivered.

Gateway - Consignment Signature

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	Aurora	Integration	ePOD-Aurora Integration meetings and specification.	0.00
2	ePOD	Look and Feel	Create customer-specific style on device.	0.00
3	ePOD/Portal	Tracking	Multiple Time Windows	0.00
4	ePOD	Delivery	Deliver All Products	0.00
5	ePOD	Returns	Configurable Ad Hoc Returns	0.00
6	ePOD	Reporting	POD Note Format.	0.00

Notes:

Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1	UG 291094 EPOD Admin User Guide	3.0	16/10/2014
2	UG 291097 EPOD Client User Guide	4.0	16/10/2014
3	FS 291096 Interface with CALIDUS ePOD	1.0	05/02/2015
4	Portal User Guide - TTM	6.8	12/11/2015

B.2 Glossary

Term	Definition
EPOD	Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD.
CALIDUS eSERV	The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system.
PDA	The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android.
DAL	Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it.
GPS	Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device.
GPRS, 3G, HSDPA, Data Service	All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet.

B.3 Authorised By

Warning: Customer Contact	Greene King	_____________________________
Matt Turner	OBS Logistics Product Manager	_____________________________

Anonymous

Search

REQ 314432 Greene King ePOD Requirements