Latest revision as of 12:47, 10 February 2022

Greene King

CALIDUS ePOD/TTM Solution Design

Solution Design

1st March 2016 - 0.6
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

The operation deals in distribution of the Green King products between the depots (for primary movements) and to the pubs (secondary movements).

Movements are:

Primary - bulk movements between depots
Secondary - radial deliveries to customers (pubs).
3rd-party haulage (for example, for Carlsberg)

The operation has its own fleet, which completes the majority of the movements, primary and secondary.

An overflow of movements are also completed by a range of 3rd-party Carriers and Couriers, predominantly DHL (for primary movements) and TradeTeam (for secondary).

Carlsberg also complete some secondary movements for Greene King, as Greene King complete some movements for Carlsberg. It is noted that there are some products on movements completed for Carlsberg that are not maintained within Aurora, and the process for dealing with these is to be confirmed by Greene King.

Other 3rd-party couriers are used to complete the remaining small percentage of movements.

Primary and Secondary movements will be planned together onto the same vehicles if possible and being completed by the same carrier.

There are several depots throughout the UK in the distribution network:

Bury St Edmonds
Eastwood
Abingdon
2 in Scotland

The operation primarily requires its own fleet outfitted with a mechanism for electronic delivery. It is required that this be achieved for secondary movements completed by the home fleet.

The secondary project objectives are:

Primary movements through ePOD.
Trusted 3rd-party carriers/couriers utilising ePOD (for example, TradeTeam, DHL, other 3rd-party couriers).
Electronic signature capture of customer collection of goods by office staff at the depots.
Electronic signature capture of staff sales.

The total number of drivers and vehicles using the application is variable, depending on the usage by 3rd parties.

Information to be confirmed:

Number of devices/drivers
Number of loads
Number of jobs per load
Average products per job
Average products per category

Project information:

The mobile devices used by the home fleet will be a device with an integrated scanner. To be confirmed.

The project is being sponsored within Greene King by Nick Atkinson, supported during the project by a number of additional staff:

Nick Atkinson
Philip Pearce
Isabel Aves - 3PC Management
Roger Smith (DiPS)
John Murray - Secondary Distribution
Ian Dorrington (Aurora)
Rob Carter (Hen Hall Operations)

General System Overview

The core systems are Aurora (ERP), a WMS system (undefined) and DiPS (Route Planning), with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal TTM). TomTom WEBFLEET provides Vehicle Tracking, device routing and reporting, and CALIDUS VEhub provides Vehicle Defect Checks, Accident Reporting and additional tracking and reporting functionality.

Orders are entered into, received or generated by Aurora.
Orders are routed in a variety of mechanisms:
- Secondary movements by Own Fleet are planned in DiPS
- Primary movements are routed by Aurora, assisted by other routing tools. It is possible that these may be route planned by DiPS in the future.
- Secondary movements by 3rd-party couriers are never planned through DiPS. They may have their own ePOD systems and therefore will not be sent to CALIDUS ePOD at all, or they may require the use of CALIDUS ePOD to complete these jobs, and therefore will plan these jobs onto loads themselves through the CALIDUS ePOD Admin system, to which they will be given access as required.
- Some orders are entered and planned in DiPS alone, not in Aurora. As such, these orders will be planned onto Loads and have order header information (such as address and contact) but will have no product details, only the summary entered into DiPS.
- Primary and Secondary movements will be planned together onto the same vehicles if possible and being completed by the same carrier.
- Staff Sales and Customer Collect orders will not be route planned in Aurora or DiPS, but will instead be sent with enough information for CALIDUS ePOD to create a single load per depot per day.
DiPS will interface load and job header information to CALIDUS ePOD.
Aurora will interface orders and order details to CALIDUS ePOD (after Pick Confirm and Despatch Print).
CALIDUS ePOD sends driving instructions to TomTom WEBFLEET on demand, when the load is In Progress, for those loads that are to be executed by vehicles with TomTom WEBFLEET units (as configured in the CALIDUS ePOD Admin system).
TomTom WEBFLEET is used for navigation to destinations on those vehicles with access to TomTom WEBFLEET. CALIDUS ePOD and any Android navigation tool will be used by those carriers using CALIDUS ePOD without TomTom WEBFLEET.
CALIDUS ePOD executes the deliveries and returns.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking. This information will be taken from CALIDUS ePOD and/or TomTom WEBFLEET if available.

System Overview

Data Import

All integration is subject to meetings with the appropriate resources within DiPS and Aurora. At this time, several conferences and meetings have taken place, which has clarified the general interfacing protocols.

Note: OBS Logistics have created standard Interfacing documentation and this will be passed to the Aurora and DiPS development teams. At this time, no mapping exercise has started. It falls to OBS Logistics to specify and control the modifications to external systems.

SCR-314432-1:

ePOD-Aurora/DiPS Integration meetings and specification.

It is expected that there will be a split inbound interface from the source systems:

From DiPS, Load, Planned Times and sequencing information.
From Aurora, containing the detailed job information.

The DiPS interface is expected to be a bespoke interface.

Note: It is expected that this interface will be completed as part of the Planned vs Actuals project. However, it is a requirement and dependency of this project - if not completed as part of that project, it must be completed as part of this.

The Aurora interface is confirmed to use the existing CALIDUS ePOD XML interface format, with some modification driven by the software changes in this document, and to cooperate with the bespoke DiPS interface above. The files will be received through FTP. This interface will be for the orders only (no load information) and will contain:

Header, Timings, Address, Contacts
Line-level information (products, quantities)

SCR-314432-2:

Aurora-ePOD Interface for Order and Product Details.

The expected changes are:

Autogenerate a load if load not provided and a user is (product change).
Add some additional fields?
Deal with not deleting jobs if they have not been provided on the load
Deal with not deleting containers/products.
Working in conjunction with the DiPS interface, no matter which record arrives first.

Note: If a load is not provided, but a user ID is, the interface will find the first open (i.e. not complete or cancelled) load assigned to that user and add the jobs onto that load. If a load is not available, one will be generated for them.

Note: There is some discussion as to whether all of the information currently received from DiPS will be sent to and stored in Aurora, and therefore only one interface will be required. This has not been confirmed and is dependent on cost from Aurora. This document assumes the solution above and may be changed at a later date to use a single interface from Aurora instead of a split interface.

The expected trigger point for Aurora to send orders and details to CALIDUS ePOD differs depending on the job type:

For Primary and Secondary jobs, this will be at the point of Release Load in Aurora.
For Customer Collect and Staff Sales, this will be immediately upon receiving the order in Aurora.

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 there will be the following Sites within CALIDUS ePOD:

A single site per depot, for all primary and secondary movements.
A single (different) site per depot, for customer collect and staff sales.
A single site per 3rd-party Carrier or Courier expecting to use the CALIDUS ePOD system.

All Sites must be pre-created by the OBS Logistics implementation team. Loads and Jobs received for Sites that are not pre-created will be rejected by the interface.

The Site indicates which depot has responsibility for executing the orders, regardless of where the orders might originate.

For example:

Order 1 for a Movement from Depots A to B.
Order 2 for a Movement from Depots B to A.

If a load is planned and resourced from Depot A for both orders (round-trip, load order 1 at A, travel A to B, delivery 1, collect 2, travel back to A), Depot A retains responsibility for the orders and therefore all orders and load will be marked for site A.

If it was planned and resourced by Depot B, all orders and loads should be marked for site B.

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 on the device.
Job Image capture after completion.

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 and Empty Packaging Returns
Product Returns/Ullages
Breaks
Loading/Unloading
Customer Collect/Staff Sales

Note: Large retail customers (e.g. Tesco, Morrisons, etc) may still require sign on paper for their own systems. In this case, a different job group for these jobs may be configured, requiring Document Photo capture in lieu of or in addition to signature.

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 - this may then require further manual configuration of the job group.

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:

Load ID will be sent through as the DiPS Callover Sequence Number, if planned through DiPS. This is available to Aurora and DiPS and is unique for every load created for a depot. If not planned through DiPS, this is expected to be a unique ID generated from the Route Code (for Primary movements).
If orders are not route planned at all, they may be sent with no Load ID - these may be planned manually in the CALIDUS ePOD Admin system.
If orders are not route planned but have been allocated a user (i.e. Customer Collect and Staff Sales jobs), Loads will be automatically generated for that user, or the jobs will be automatically added to the first open load assigned to that user. It is expected that these jobs will be given a unique site (as indicated above) and will have a default user (e.g. 'COLLECT') specific to the customer collection and staff sales process. Aurora will be able to identify these orders through flags against those orders or customers.
It is expected that Carriers in Aurora will be configured as to whether they are using CALIDUS ePOD. Carriers that are not configured for CALIDUS ePOD use will not have jobs transferred to CALIDUS ePOD.
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.
- It is expected that the jobs sent to CALIDUS ePOD from Aurora will not contain a contact name.
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. It has been decided that this information
An Owner must be specified against each job. This indicates which depot (or CALIDUS Portal TTM user) may track an order. Where movements originate from a depot, this owner should contain this site. Orders that are executed by the same site should have their site ID in this field. 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.
A new field will be sent into the system to specify an amount of time before the planned end time on the job to alert the driver.
Special instructions for the driver will be received from Aurora on the job. There are 6 lines of 50 characters in Aurora, whereas CALIDUS ePOD accepts only up to 255 characters. This can either be trimmed when sent by Aurora, or a software change could be made to CALIDUS ePOD to store 300 characters in the Job Instructions.

SCR-314432-3:

Increase special instructions to 300 characters

Product Returns and Ullages will be specified as collection jobs in the interface to CALIDUS ePOD. These will be entered into Aurora and planned as any normal delivery job.

Note: Currently, DiPS does not receive enough information from Aurora to accurately identify jobs as collections or delivery jobs. As such, all jobs are marked as Delivery jobs by this bespoke interface. When the Aurora interface is implemented, Aurora will identify jobs as collection or delivery jobs. At this time, either the interface to DiPS from Aurora should be changed to mark jobs as collections, and the DiPS interface to CALIDUS ePOD changed to set the job type from this data, or the generic OBS XML process must be changed to recognise jobs on a load may not be the correct job type. In either case, this is development that will require bespoke modification to overcome, and therefore a change is required.

SCR-314432-4:

Correctly identify Collection jobs from DiPS.

Note: It is necessary for the POD format to identify products that are not part of the delivery, but instead identify the number of returnable items (i.e. empties, packaging, etc) on the job. This will be sent through the Aurora interface. CALIDUS ePOD must be modified to handle these additional non-deliverable products, to ensure that the drivers are never instructed to deliver these items. Further, modifications to the Admin system must be made to ensure that these products are identified properly.

SCR-314432-5:

Handle Non-deliverable Products.

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 Reason Code standing data will be transferred through from Aurora to CALIDUS ePOD or maintained manually. Drivers and Vehicle will be generated from the DiPS interface automatically.

Note: Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. Orders may be allocated loads in the following ways:

Automatically through the DiPS interface from planning in DiPS
Automatically through the Aurora interface from planning in Aurora.
Automatically generated for customer returns and staff sales.
Manually through the CALIDUS ePOD Admin system.

Once Order and Trip information is received (or entered) 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 Loads.
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.
To run Reports

Note: This Administration system is expected to be used primarily for running the Planned Vs Actuals report, developed as part of that project. It will also be used by 3rd-party Carriers using CALIDUS ePOD. It is expected that these carriers will be provided a user and password for their use, and the system will prevent this carrier from seeing the work assigned to any other site (own depot or other carrier). The carrier will also be able to maintain their own drivers and vehicles through this Admin system. Note also that users of this system with full access will also be able to maintain system settings, such as Import/Export rules and Reason Codes. If these are changed by the operators, these may have adverse affects on the running of the system, the integration to and from Aurora and DiPS and how jobs are executed on the mobile devices by that carrier. It is the responsibility of all the users using the system with full access to ensure that the core system parameters are not changed in this way, unless explicitly agreed by Greene King.

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

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

Assigning a User to Loads

Assigning Loads to a user

This mechanism will be expected to be used by and 3rd-party Carriers using CALIDUS ePOD. It is expected that these carriers will be provided a user and password for their use, and the system will prevent this carrier from seeing the work assigned to any other site (own depot or other carrier). The carrier will also be able to maintain their own drivers and vehicles through this Admin system.

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

Vehicles and Drivers are expected to be created as part of the interface from the host system. 3rd-party carriers, if using CALIDUS ePOD, will be expected to maintain their resource data manually through the Admin system.

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.

Additionally, if a vehicle is to be used with WEBFLEET, the vehicles must be configured with the WEBFLEET external object ID (external ref) - this must be maintained manually for any vehicles created.

Adding the WEBFLEET external object ID to a vehicle

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

Note: Software Changes specified in this document will result in changes to the Site and Job Group configuration screens, and to the Job and Products screens. The changes will be detailed as part of the functional specification stage.

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

The following sections details the standard processing expected by the drivers for secondary delivery and collection jobs.

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-6:

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 and vehicles, ensuring that they can complete only the loads required. The users and their passwords must be configured within CALIDUS ePOD.

A driver will log on to a device using their provided user name, password and selecting the vehicle from a drop-down list. The device will remember the last used User name and Vehicle, but will always require that the password is entered.

Note:

The TomTom devices are linked to a specific vehicle - this is not ePOD functionality, but the way that TomTom WEBFLEET devices work.
The TomTom devices can be linked to another vehicle through an administrative change on the device, taking up to 5 minutes. It does not automatically link to the nearest device, as this is inappropriate when there are several vehicles within a 10m radius.
The ePOD application will remember the vehicle on which it is being used, so the driver will not be required to change the vehicle.
If the device is to be linked to another vehicle, the driver can use the drop-down list within ePOD to select the correct vehicle.
If the driver logs on with the wrong vehicle, they will not be given any work, as the work is assigned to a specific driver/vehicle combination.

A change was mooted regarding changing this CALIDUS ePOD log-on process to not specify the vehicle, but to log on and then assign the vehicle through the load that is assigned to the driver. It was decided that this was not required, but if this is required, this will require further changes to the ePOD system and generate additional cost.

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 as the main Order Reference
- 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 allowed with a warning to the driver.

SCR-314432-7:

Alert Pop-up for Customer Contact

The process will be as follows:

If there are any planned jobs where the planned time is within the alert window for the job (specified in the Aurora interface), the Info button on the Job List screen will show a red background. Additionally, any job with an alert time that is in its alert window will show the date and time on the job list in red rather than the usual black. The driver can just as easily click on these jobs here instead.
Any jobs that move within the alert window while the driver is in the Job List or Job Details screens will return the driver to the Job List and generate an alert, accompanied by a vibration and sound. Note: If the driver is processing a job, they will not be interrupted - only in the Job Detail and Job list screen will this interrupt the driver.
Clicking Yes on this alert, or clicking the Info button will show the load information drop-down, which will also show the jobs that are being alerted.
Clicking on a job in the Load Info list will show the Job Details of the job, allowing the driver to see the instructions, and to text or phone the customer. Note: Contacting the customer will not clear the alert display from the load information or the red text from the job list.
Any jobs at confirmed or cancelled status will not trigger the alert, and will not trigger the display of alerted jobs in the job list.

Alerted jobs highlighted
The pop-up alert
The Load Information, showing the alerted jobs

If any jobs (product returns or additional deliveries) have been added to a Load, or product quantities have been changed 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. It is expected initially that the driver will not have any reason codes created for the cancellation of jobs, but that the cancellation will be through the driver phoning the office and requesting the cancellation or re-planning of the job for a later date. However, it may be the case that a single Job Level reason code may created ('Authorised by Office') may be created, that the driver may use after they have contacted the office for confirmation. In either case, this configuration may be changed by the operation at any time by creating or deleting the Job Reason Code in the CALIDUS ePOD Admin system.

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.

Note: An optional software change may be entered into for enforced image capture by the Reason Code selected - this is detailed later in the document.

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

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). Note: It is expected that the contact name will not be sent.
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). This requires that the contact numbers be interfaced from Aurora.

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. This will also trigger an event to CALIDUS Portal TTM, to show that the driver in in transit to the job, and to calculate ETAs. This may then trigger a tracking email to the customer, although this is expected not to be configured for this initially, relying instead on email notifications sent from DiPS.

Jobs can be cancelled by the driver at this time by clicking the Cancel Job button, which functions identically to the Cancel Job option available on the Job List screen.

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

SCR-314432-8:

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 also a User Notes tab that will be displayed, allowing the user to enter any notes against the Job before completion. This will primarily be used to capture any product delivered to the customer not preadvised by Aurora on the job.

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
Using the Deliver All button (defined later in this section)

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

Note:

Products may be confirmed through scanning a barcode against the product. This must be the product code sent to CALIDUS ePOD from Aurora, including any preamble in the barcode itself. The mobile application will then confirm the quantity delivered. The Scan button on the device (using the camera), an integrated scanner or a linked BlueTooth scanner may be used to scan the item.
Products may be confirmed by selecting them from the list, and then confirming the quantity delivered. This may be disabled on the system, enforcing scanning.
Selecting from the list equalled their current process and would not take significantly more time than the paper process.
The Scanning process would allow better definition of which product and batch was delivered, although may not be suitable for all products.
The Deliver All functionality could be abused by the drivers.
The application may be configured for all the above if required, and this may be evaluated at a later date.

The scanning of individual products may be required (unlikely) or that a tally mechanism system (where product is counted down for each quantity delivered) may be required. In either case, this will require an additional change to the software at additional cost, although it is expected that neither of these will be required. There is concern that the more that was required of the driver (i.e scanning) would add too much time to the processing and that this should be minimised if possible, driving further change into a possible phase 2 after go-live.

It is expected that the initial configuration of the application will be:

Scroll through the list and select the products to confirm as exceptions
Scanning may only be used to identify products for exception, rather than scrolling through the list.
A copy of the load sheet may be used by customers for tallying, if required. This Load sheet will be produced from Aurora and emailed direct to the customer as an ASN, rather than being printed. This is expected to be in the same format as the current despatch note.
All remaining product will be confirmed as fully delivered using the Deliver All functionality.

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 up or down, 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.

Note: The CALIDUS ePOD application must be checked and made capable of increasing product quantities in this exception process.

SCR-314432-9:

Allow Over-Delivery/Collection of Product.

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.

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.

An optional software change may be entered into for enforced image capture by the Reason Code selected

SCR-314432-10:

Enforce Image Capture by Reason Code.

This change does not include modifications to allow Reason Codes to be configured as requiring images through the standing data interface from external systems - Reason Codes must be configured within the CALIDUS ePOD Admin system to require image capture. By default, reason codes will not require images to be captured. If the Reason Codes are configured this way, this will over-ride any other Site or Job Group setting.

It is expected that Returned Empty Packaging will be entered during the delivery process. To achieve this, a change will be required.

SCR-314432-11:

Configurable Empty Returns

A new Tab will be added to the Collection or Delivery screens, depending on configuration. This is expected to be labelled as 'Empties'

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 an empty already entered on the list will allow the user to edit or remove this empty 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.

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

SCR-314432-12:

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: This Deliver All functionality completes the job. This should be done after all exceptions to delivered products are made, and after all empties are entered. If completed inadvertently, it is possible for the driver to back out of the Job Completion process, to make further amendments/exceptions, to mark cancelled goods as delivered, or to enter additional empties.

Product Returns/Ullages Collection Process

Product returns jobs will be advised to CALIDUS ePOD from Aurora as Collections. 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.

Product Returns Collection screen

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

Ullages are required to be captured. At this time, the process for capturing these has not been defined, although the process is expected to be defined to OBSL as an action from the meeting at Eastwood on 26/02/2016. This may generate additional development within CALIDUS ePOD, but this will be evaluated when the information is received.

It is expected that Ullages will be preadvised as products on product returns, and that they will require:

An Ullage Number
Lot Numbers
BBD

It has not yet been confirmed whether any or all of this information (for Product Returns or Ullages) is required on the device. If this information is required with preadvised products, a further change to CALIDUS ePOD would be required.

SCR-314432-13:

Additional Fields for Product Returns

At this time, it is expected that the Long Description will be used to add any additional fields that are required for the driver to see.

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 up or down
be cancelled.

Note that, if a zero quantity is advised to be collected (for example, if Aurora has informed CALIDUS ePOD of a product to be collected, but has not confirmed how much), the driver can be forced to enter a returned quantity, or can confirm that nothing was collected.

Warning: Ullages are required to be captured. At this time, the process for capturing these has not been defined. This may generate additional development within CALIDUS ePOD, but this will be evaluated when the information is received. Note: It is expected that the change here for Empty Returns may also be used to enter Ullages, either during the delivery process or with product returns.

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 only to sign for product return 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. It is expected that the jobs sent to CALIDUS ePOD from Aurora will not contain a contact name.

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.

The Products tab shows all the quantity of all products being delivered. A change is requested here to show only a summary at product type.

SCR-314432-14:

Summary of Product Quantity by Type

Warning: The Product Type used to summarise this is not yet defined and may require an additional field in the interface from Aurora - this is assumed at this time. If instead the existing Order No + sub-reference (e.g. 3188620 / 00) is used, the development necessary for this change will decrease.

Large retail customers (e.g. Tesco, Morrisons, etc) may still require sign on paper rather than sign on glass and were unlikely to change, as this would mean change to their own internal systems. In this case, the driver will sign in lieu of these customers, entering the delivery reference from the customers' system into the Signatory field.

Images at Job Completion may be configured, specifically for the purposes of capturing an image of the customers' document. This is possible within CALIDUS ePOD without further change, requiring only the configuration of the job received into CALIDUS ePOD from Aurora to be a different job group.

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.

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

Breaks Process

Planned Breaks will be interfaced to CALIDUS ePOD from the DiPS interface. They will be generated as a normal job with customer 'BREAK'. They will be given a job address based on the BREAK customer, but with a Lat/Long set as the last job processed on the load. The instructions will be the break length. The Order Number (Job Code) for these jobs will be generated from a code "BRK", plus the Load ID and a sequence.

The Break jobs are expected to be created with a different Job Group, which will allow control of how the break jobs process, to an extent. For example, it is expected that the break jobs will be configured to not require any signatures

The break jobs will be sequenced on the load in the same way that delivery and collection jobs are sequenced. They may be completed out of sequence in the same way that jobs may be.

As these are essentially delivery jobs with no product information, they will be processed in exactly the same way as delivery jobs:

The job will be selected from the Job List and the device will show the details of the job, including the break length.
The job be completed using TomTom WEBFLEET to arrive at the break job, to capture the distance and time travelled to the break.
The job will be started with the Start button in CALIDUS ePOD. Note: The Arrive Job button may also be required depending on the Site configuration. The Delivery screen will be shown.
The job will be completed with the Complete button.
It is expected that the break jobs will be configured to not require any signatures, through the Job Group that was interfaced with the job.

If any different functionality is required to control the Break jobs in the CALIDUS ePOD system, additional work will be required for this.

SCR-314432-15:

Add Break Jobs as a different type.

The expected work could be as follows:

To identify Break jobs as Breaks through the Job Type
To display Break jobs differently in the Admin system, and to not allow any Product or Container details to be shown.
To display the breaks differently on the mobile device job list.
To control the completion of Break jobs differently, without requiring the Delivery process to be completed first, and showing a break length.

As this is open to discussion, the change estimated in the document is a ballpark only and may change if additional changes to the above are required.

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

Customer Collections

Orders to be collected from the depots will be marked as such within Aurora.

Customer collection orders will be sent to CALIDUS ePOD with a site ID specific to customer collections for that depot. They will be assigned to a specific user for that depot (e.g. "COLLECT"). The address will be the depot. They can be collection or delivery jobs. These jobs are expected to have a specific configuration (Job Group) defined against them.

CALIDUS ePOD will create these orders and automatically generate a load for that user, or assign the orders to the currently open load for that user.

When the customer comes to collect the goods, they will approach the reception user who will log on to an ePOD device with the user "COLLECT" and a default vehicle (e.g. "COLLECT" again).

The device will show the load generated for the COLLECT user.

The user will use the Job List to find the order, from the customer's documentation. The configuration for this depot will ensure that the user can select any of the pending collections on the job list.

The items will be scanned or entered as a normal delivery.

Once complete, the customer will sign for the goods as normal.

Staff Sales

Staff Sales Orders to be collected from the depots will be marked as such within Aurora.

These orders will be sent to CALIDUS ePOD with a site ID specific to customer collections for that depot. They will be assigned to a specific user for that depot (e.g. "COLLECT" or "STAFF" if this needs to be segregated from Customer Collections, although this is not recommended). The address will be the depot. They can be collection or delivery jobs. These jobs are expected to have a specific configuration (Job Group) defined against them.

Staff sales will be processed identically to customer collections above.

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.

Warning: The POD document is changing, and a POC format (for Product Returns) is also being created. This has not been received at this time. For the purposes of this document and estimates, it is assumed that the above format contains all the details required on the new documents, although the formatting will change to reflect the new styling. Note also that, if the new POC and POD formats are significantly different from each other, the development work will increase.

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
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/POC produced will expect to be paginated to accommodate the quantity of products on a single job. Collected Packaging will be present only on the first page of the POD and care should be taken to ensure that these sections fit on this page.

No images will be shown on the POD/POC notes, 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-16:

POD and POC Note Formats

Data Export

Note: All files (inbound to and outbound from CALIDUS ePOD) will be transferred using an FTP method - this will be confirmed after discussions with Aurora. Jobs will be exported in the OBS XML format.

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, although some of the changes that were made to the import functionality may also be copied to the export. Regardless, the information regarding this interface and the format of the data contained within will be forwarded to the Aurora consultants.

Aurora will update the product quantities, enter all the reason codes, mark fully complete lines as complete, and store any notes sent back by from CALIDUS ePOD. Aurora does not have a place to store signatory/signature and will not store this information.

Any clean orders (i.e. without reason codes, quantity discrepancies or user notes) will be immediately updated to POD Confirmed status. Any dirty orders will be left NOT POD confirmed. A new screen is required in Aurora, extremely similar to the POD Confirm screen, to show any dirty orders with the information obtained from CALIDUS ePOD. The operation requires enforced checking of these orders. The screen should also allow amendment of the details from ePOD (e.g. Reason Code), then POD confirm from this screen.

Aurora may also produce a WMS Returns sheet from this information provided by CALIDUS ePOD, so that returns may be processed more effectively. There may also be processes to reflect non-delivered items in Aurora and the WMS (i.e. marked as In Transit, Held, QC, SinBin) until examined and brought back into stock or discarded. This information can be easily gathered from the information passed back from CALIDUS ePOD:

Any non-delivered product where the quantity is less that that planned.
Any product with a non-zero quantity on a Product Return Collection job.
Any Empty Packaging detailed on the Delivery job.

It is confirmed that the WMS will obtain this information directly from the Aurora POD confirmation process and as such requires no changes to function as planned.

For jobs that have been completed, POD documents will 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, which requires a comma delimiter for multiple email addresses.

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

Aurora does not have a place to store signatory/signature. 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. This is confirmed as a requirement. However, the Document Management system in use may require an XML file as well as the PDF. Warning: More information is required on this file, or whether it is required at all. This requires additional development within CALIDUS ePOD. This has been listed as an optional development.

SCR-314432-17:

New Interface to send PDF to DMS - create XML file.

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

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

Core Changes

This section shows the core changes required for the system to function without any optional changes or additional processes, and fulfil the primary goal of operating Home Fleet Secondary movements.

SCR#	System	Area	Description	Estimate (Days)	Notes
1	Aurora	Integration	ePOD-Aurora/DiPS Integration meetings and specification.	3.00
2	ePOD/Aurora	Integration	Aurora-ePOD Interface for Order and Product Details.	2.25
5	ePOD	All	Handle Non-deliverable Products.	3.25
6	ePOD	Look and Feel	Create customer-specific style on device.	0.50
8	ePOD/Portal	Tracking	Multiple Time Windows.	18.75	^{2: Product Change}
9	ePOD	Exception	Allow Over-Delivery/Collection of Product.	0.00	^{2: Product Change}
11	ePOD	Returns	Configurable Empty Returns.	15.25
12	ePOD	Delivery	Deliver All Products.	4.50	^{2: Product Change}
14	ePOD	Signature	Summary of product qty by type.	7.75	^{3: More info required}
16	ePOD	Reporting	POD and POC Note Format.	4.50	^{3: More info required}

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.
This change is OBS funded as part of product development.
These changes are dependent on the requirements that have not yet been received by OBSL.

Additional Changes

This section shows the changes that are not required to fulfil the primary goal of operating Home Fleet Secondary movements, or that are required because the external systems will/can not be changed to achieve necessary functionality.

SCR#	System	Area	Description	Estimate (Days)	Notes
3	ePOD	Integration	Increase special instructions to 300 characters.	2.25	^{1: Not Required}
4	ePOD	Integration	Correctly identify Collection jobs from DiPS.	4.50
7	ePOD	Job List	Alert pop-up for customer contact.	11.75
10	ePOD	Exception	Enforce Image Capture by Reason Code.	4.75	^{2: Optional}
13	ePOD	Integration	Additional Fields for Product Returns.	4.50	^{1: Not Required}
15	ePOD	Breaks	Add Break Jobs as a different type.	9.25	^{2: Optional}
17	ePOD/DMS	Integration	New interface to send PDF to DMS - create XML file.	4.50	^{3: More info required}