Revision as of 15:41, 24 December 2015

Greene King

CALIDUS ePOD/TTM Solution Design

CALIDUS ePOD

24th December 2015 - 0.3
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), 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 come into Aurora.
Aurora interfaces the orders to DIPS, for Routing purposes, then back to Aurora.
Aurora interfaces loads and orders 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.
TomTom WEBFLEET is 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, with the possible exception of route information from DIPS.

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.

SCR-314432-2:

DIPS-ePOD Interface for Load and Order Sequencing.

Note: It is expected that this interface will be completed as part of the Planned vs Actuals project. However, it is listed here as 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 likely 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. 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-3:

Aurora-ePOD Interface for Order and Product Details.

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.

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

Large retail customers (e.g. Tesco, Morrissons, 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: 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.
- 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. 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.
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 CLAIDUS ePOD to store 300 characters in the Job Instructions.

SCR-314432-4:

Increase special instructions to 300 characters

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

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. This is expected to be through the interface from DIPS. 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 (if not automatically assigned) will be assigned 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.

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.

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

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

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

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 may be emailed direct to the customer as a kind of ASN, rather than being printed.
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-8:

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

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

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.

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.

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

SCR-314432-11:

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

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

SCR-314432-12:

Additional Fields for Product Returns

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

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

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.

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.

Note: 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 formattting will change to reflect the new styling.

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/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-14:

POD and POC Note Formats

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, 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 ro 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 quantitiy 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.

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 requires an XML file as well as the PDF. This requires additional development within CALIDUS ePOD.

SCR-314432-15:

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 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/DIPS Integration meetings and specification.	5.00	²
2	ePOD/DIPS	Integration	DIPS-ePOD Interface for Load and Order Sequencing.	8.75	³
3	ePOD/Aurora	Integration	Aurora-ePOD Interface for Order and Product Details.	2.25
4	ePOD	Integration	Increase special instructions to 300 characters.	2.25	⁴
5	ePOD	Look and Feel	Create customer-specific style on device.	0.50
6	ePOD	Job List	Alert pop-up for customer contact.	11.50
7	ePOD/Portal	Tracking	Multiple Time Windows.	20.00
8	ePOD	Exception	Allow Over-Delivery/Collection of Product.	0.00	⁵
9	ePOD	Exception	Enforce Image Capture by Reason Code.	5.00	⁶
10	ePOD	Returns	Configurable Empty Returns.	14.50
11	ePOD	Delivery	Deliver All Products.	4.50	⁵
12	ePOD	Integration	Additional Fields for Product Returns.	4.50	⁴
13	ePOD	Signature	Summary of product qty by type.	7.75	⁷
14	ePOD	Reporting	POD and POC Note Format.	4.50	⁸
15	ePOD	Integration	New interface to send PDF to DMS - create XML file.	5.50	⁸

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 expected to be partially fulfilled by the Planned Vs Actual Project.
This change is expected to be fulfilled as part of the Planned Vs Actuals project. It is listed here as a dependency and a requirement.
This change is assumed as not required.
This change is OBS funded as part of product development.
This is an optional change.
If no new field is required, the development for this change is 5.0 days.
These changes are dependent on the requirements that have not yet been received by OBSL.

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

Nick Atkinson	Greene King	_____________________________
Matt Turner	OBS Logistics Product Manager	_____________________________

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' ePOD}}
 {{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
-{{#vardefine:Version|0.2}}
+{{#vardefine:Version|0.3}}
-{{#vardefine:Date|27th November 2015}}
+{{#vardefine:Date|24th December 2015}}
 {{#vardefine:Reference|314432}}
 {{#vardefine:Year|2015}}
@@ Line 71: / Line 71: @@
 == General System Overview ==
-The core systems are Aurora (ERP) and DIPS (Route Planning), with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal TTM).
+The core systems are Aurora (ERP), a WMS system (undefined) and DIPS (Route Planning), with OBS Logistics' systems providing execution ({{#var:System}}) 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 come into Aurora.
 *	Aurora interfaces the orders to DIPS, for Routing purposes, then back to Aurora.
-*	Aurora interfaces loads and orders to {{#var:System}} (trigger to be defined).
+*	Aurora interfaces loads and orders to {{#var:System}} (after Pick Confirm and Despatch Print).
-*	{{#var:System}} sends driving instructions to TomTom WEBFLEET on demand.
+*	{{#var:System}} sends driving instructions to TomTom WEBFLEET on demand, when the load is In Progress.
-*	TomTom WEBFLEET used for navigation to destinations.
+*	TomTom WEBFLEET is used for navigation to destinations.
 *	{{#var:System}} executes the deliveries and returns.
 *	{{#var:System}} updates ''CALIDUS'' Portal's Track and Trace module (TTM) with information for order tracking.
@@ Line 86: / Line 86: @@
 == Data Import ==
-All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method in OBS XML format.
+All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method in OBS XML format, with the possible exception of route information from DIPS.
+{{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.
-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.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=ePOD-Aurora/DIPS Integration meetings and specification.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+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.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=DIPS-ePOD Interface for Load and Order Sequencing.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+{{Note}} It is expected that this interface will be completed as part of the Planned vs Actuals project. However, it is listed here as 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 likely 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. This interface will be for the orders only (no load information) and will contain:
+* Header, Timings, Address, Contacts
+* Line-level information (products, quantities)
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Aurora-ePOD Interface for Order and Product Details.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+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.
@@ Line 96: / Line 126: @@
 * POC/POD document format.
 * POC/POD business address and logo.
-* Terms and Conditions displayed.
+* 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
+* Deliveries and Empty Packaging Returns
-* Returns (Product and/or Packaging)
+* Product Returns
-{{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.
+Large retail customers (e.g. Tesco, Morrissons, 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 {{#var:System}} that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration.
+If Job Groups are sent to {{#var:System}} 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.
@@ Line 120: / Line 152: @@
 ** 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.
+** 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. 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.
+* 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 ''CLAIDUS'' ePOD to store 300 characters in the Job Instructions.
-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 {{#var:System}}, but it falls to OBS Logistics to specify and control the modifications to external systems.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=ePOD-Aurora Integration meetings and specification.
+|Definition=Increase special instructions to 300 characters
 |Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
+Product Returns 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.
@@ Line 145: / Line 175: @@
 Each of these items can be agreed in advanced or administered within {{#var:System}}, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in {{#var:System}}, 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 {{#var:System}}. 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 {{#var:System}}.
+{{Note}} It is expected that the Reason Code standing data will be transferred through from Aurora to {{#var:System}} 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. If this cannot be achieved by Aurora or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.
+{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. This is expected to be through the interface from DIPS. The {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.
@@ Line 184: / Line 214: @@
-Vehicles will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.
+Vehicles (if not automatically assigned) will be assigned as the driver logs on to the device application and confirms which vehicle they are using.
@@ Line 190: / Line 220: @@
-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.
+{{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.
@@ Line 214: / Line 247: @@
-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 {{#var:System}}.
+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 {{#var:System}}.
-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.
+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.
 <!-- == Vehicle Checks ==
@@ Line 296: / Line 338: @@
 * 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.
+This configuration will be decided at the point of implementation, but is expected that re-sequencing is allowed with a warning to the driver.
-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.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Alert Pop-up for Customer Contact
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+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.
+<gallery widths=310px heights=400px perrow=3>
+File:REQ_314432_PDA_Alert1.png|''Alerted jobs highlighted''
+File:REQ_314432_PDA_Alert2.png|''The pop-up alert''
+File:REQ_314432_PDA_Alert3.png|''The Load Information, showing the alerted jobs''
+</gallery><br />
+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.
-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.
+{{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.
@@ Line 335: / Line 399: @@
 *    The Job Type (Collection, Delivery, Service)
 *    The customer details (Customer Code, Name, Address and Postcode)
-*    The contact information (Contact name and number)
+*    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.
@@ Line 343: / Line 407: @@
-The screen allows the user to contact the customer (through text or phone).
+The screen allows the user to contact the customer (through text or phone). This requires that the contact numbers be interfaced from Aurora.
-{{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.
@@ Line 357: / Line 417: @@
-When a Job is successfully started, this will take the Job to 'In Progress' status.
+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. 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.
+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.
@@ Line 390: / Line 450: @@
 File:REQ_314432_PDA_Delivery2.png|''Products Tab''
 </gallery><br />
-{{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}} 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.
-{{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|Collection Process]]'' for details of this.
@@ Line 423: / Line 481: @@
 * 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 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.
+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.
-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.
+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 may be emailed direct to the customer as a kind of ASN, rather than being printed.
+* All remaining product will be confirmed as fully delivered using the Deliver All functionality.
-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.
+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.
-It is a requirement of this process to allow delivery by exception, which requires a change to the ''CALIDUS'' ePOD system.
+{{Note}} The ''CALIDUS'' ePOD application must be checked and made capable of increasing product quantities in this exception process.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Deliver All Functionality
+|Definition=Allow Over-Delivery/Collection of Product.
 |Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
-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.
+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}} 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.
+{{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
-=== Categorised (Container) Delivery ===
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-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.
+|Definition=Enforce Image Capture by Reason Code.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
-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.
+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.
-<gallery widths=310px heights=400px perrow=3>
+It is expected that Returned Empty Packaging will be entered during the delivery process. To achieve this, a change will be required.
-File:REQ_314432_PDA_Delivery3.png|''Containers Tab''
-File:REQ_314432_PDA_Delivery4.png|''Products within Containers''
-</gallery><br />
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Configurable Empty Returns
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
-From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.
+A new Tab will be added to the Collection or Delivery screens, depending on configuration. This is expected to be labelled as 'Empties'
-The Container list may show the following items per line:
+<gallery widths=310px heights=400px perrow=3>
-* Container ID
+File:REQ_314432_PDA_ReturnPack1.png|''Package Returns Tab''
-* Type
+File:REQ_314432_PDA_ReturnPack2.png|''Add a Package Return''
-* Status
+File:REQ_314432_PDA_ReturnPack3.png
-* Total Products
+</gallery><br />
-* 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 {{#var:System}} 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
+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.
-If there are also loose products to deliver (i.e. uncategorised), a Loose Products container will be displayed in the same way.
+Once entered and confirmed, the returned packaging will be displayed on the list.
-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.
+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.
-The products in each category can be delivered by:
+{{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.
-* 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.
+{{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.
-{{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.
+It is a requirement of this process to allow delivery by exception, which requires a change to the ''CALIDUS'' ePOD system.
-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.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Deliver All Functionality
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
-{{Note}} During this exception process, the user will have the facility to take a photo against the cancelled container, but this is optional.
+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.
-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}} 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.
-{{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.
+==Product Returns 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.
-==Collection Process==
+<gallery widths=310px heights=400px perrow=3>
-{{Warning}} Preadvised Product Collections
+File:REQ_314432_PDA_Collection1.png|''Product Returns Collection screen''
+</gallery><br />
-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:
+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
@@ Line 517: / Line 589: @@
 * Qty
 * Auth
-If this information is required with preadvised products, a further change to ''CALIDUS'' ePOD would be required.
+It has not yet been confirmed whether any or all of this information is required on the device. If this information is required with preadvised products, a further change to ''CALIDUS'' ePOD would be required.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Additional Fields for Product Returns
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
-<gallery widths=310px heights=400px perrow=3>
-File:REQ_314432_PDA_Collection1.png|''Standard Product Collections''
-</gallery><br />
 Standard Products collections will display the same level of information as a product delivery, namely:
@@ Line 534: / Line 608: @@
 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
+* have the quantity collected changed up or down
 * 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.
+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}} 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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Configurable Ad Hoc Returns
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-{{Warning}} Ad Hoc Product Collections
+{{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.
-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'
-<gallery widths=310px heights=400px perrow=3>
-File:REQ_314432_PDA_ReturnProd1.png|''Product Returns Tab''
-File:REQ_314432_PDA_ReturnProd2.png|''Add a Product Return''
-</gallery><br />
-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'
-<gallery widths=310px heights=400px perrow=3>
-File:REQ_314432_PDA_ReturnPack1.png|''Package Returns Tab''
-File:REQ_314432_PDA_ReturnPack2.png|''Add a Package Return''
-File:REQ_314432_PDA_ReturnPack3.png
-</gallery><br />
-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.
@@ Line 604: / Line 625: @@
 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.
+{{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.
@@ Line 614: / Line 635: @@
 </gallery><br />
-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 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:
@@ Line 625: / Line 646: @@
 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.
-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.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Summary of Product Quantity by Type
-<gallery widths=310px heights=400px perrow=3>
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
-File:REQ_314432_PDA_Signature4.png|''Driver Signature''
+}}
-</gallery><br />
+{{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.
-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.
+Large retail customers (e.g. Tesco, Morrissons, 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.
-== 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.
+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.
-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.
+The user will be returned to the Job List screen and the completed Job will be removed from the list.
-<gallery widths=310px heights=400px perrow=3>
-File:REQ_314432_PDA_UnplannedAHC1.png|''Create an unplanned collection''
-File:REQ_314432_PDA_UnplannedAHC2.png|''Unplanned collection details''
-</gallery><br />
+If a planned product return job has been advised from Aurora, the device will immediately start the collection job for this customer.
-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.
@@ Line 663: / Line 678: @@
 * Litres Bought - Numeric Entry
 * Parking Ticket Number - optional text entry
-It is not expected that metrics are required for Green King.
+It is not expected that metrics are required for Greene King.
 <!-- {{Note}} Vehicle Checks may also be configured for the end of the load.
@@ Line 679: / Line 694: @@
 This format includes details of any product/packaging collections linked to it.
+{{Note}} 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 formattting will change to reflect the new styling.
 At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.
@@ Line 742: / Line 760: @@
-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.
+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 note, whether they are taken on the device or not.
+No images will be shown on the POD/POC notes, whether they are taken on the device or not.
@@ Line 751: / Line 769: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=POD Note Format
+|Definition=POD and POC Note Formats
 |Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 762: / Line 780: @@
 When jobs have been completed all the job is updated in the {{#var:System}} 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.
+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.
-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 {{#var:system}}. 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).
+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.
-{{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.
+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 ro 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 quantitiy 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.
+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 {{#var:system}}. 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.
-The {{#var:System}} 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.
+Aurora does not have a place to store signatory/signature. The {{#var:System}} 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 requires an XML file as well as the PDF. This requires additional development within ''CALIDUS'' ePOD.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=New Interface to send PDF to DMS - create XML file.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
@@ Line 990: / Line 1,023: @@
 {{ #vardefine: SCR | 0 }}
 {{REQ_SCR_Header}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=Aurora|Area=Integration|Description=ePOD-Aurora Integration meetings and specification.|Estimate=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=Aurora|Area=Integration|Description=ePOD-Aurora/DIPS Integration meetings and specification.|Estimate=5.0|Notes=2
-}} {{REQ_SCR_Line
+}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Cost=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD/DIPS|Area=Integration|Description=DIPS-ePOD Interface for Load and Order Sequencing.|Estimate=8.75|Notes=3
-}} {{REQ_SCR_Line
+}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows|Estimate=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD/Aurora|Area=Integration|Description=Aurora-ePOD Interface for Order and Product Details.|Estimate=2.25|Notes=
-}} {{REQ_SCR_Line
+}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Delivery|Description=Deliver All Products|Estimate=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Integration|Description=Increase special instructions to 300 characters.|Estimate=2.25|Notes=4
-}} {{REQ_SCR_Line
+}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Returns|Description=Configurable Ad Hoc Returns|Estimate=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device. |Estimate=0.5|Notes=
-}} {{REQ_SCR_Line
+}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=0|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Job List|Description=Alert pop-up for customer contact.|Estimate=11.5|Notes=
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=20.0|Notes=
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Exception|Description=Allow Over-Delivery/Collection of Product.|Estimate=0|Notes=5
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Exception|Description=Enforce Image Capture by Reason Code.|Estimate=5.0|Notes=6
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Returns|Description=Configurable Empty Returns.|Estimate=14.5|Notes=
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Delivery|Description=Deliver All Products.|Estimate=4.5|Notes=5
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Integration|Description=Additional Fields for Product Returns.|Estimate=4.5|Notes=4
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Signature|Description=Summary of product qty by type.|Estimate=7.75|Notes=7
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=POD and POC Note Format.|Estimate=4.5|Notes=8
+}}{{REQ_SCR_Line
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Integration|Description=New interface to send PDF to DMS - create XML file.|Estimate=5.5|Notes=8
 }} {{REQ_SCR_Footer}}
 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.
+# 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 expected to be partially fulfilled by the Planned Vs Actual Project.
+# This change is expected to be fulfilled as part of the Planned Vs Actuals project. It is listed here as a dependency and a requirement.
+# This change is assumed as not required.
+# This change is OBS funded as part of product development.
+# This is an optional change.
+# If no new field is required, the development for this change is 5.0 days.
+# These changes are dependent on the requirements that have not yet been received by OBSL.
 <!-- MEDIA LANDSCAPE NO -->
@@ Line 1,034: / Line 1,091: @@
 |Year=
 |FSEST=Y
-|Rev1={{Warning}} Customer Contact
+|Rev1=Nick Atkinson
 |Rev1Title=Greene King
 |Rev2=Matt Turner

Anonymous

Search

REQ 314432 Greene King ePOD Requirements: Difference between revisions