Latest revision as of 16:04, 27 April 2016

Zenith Hygiene

CALIDUS ePOD/TTM Solution Design

CALIDUS ePOD

27th April 2016 - 2.00
Reference: REQ 330814

Introduction

This document is the CALIDUS ePOD/TTM Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Zenith Hygiene, on 14/10/2015 at the Zenith Hygiene office.

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

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

Warning: The following changes are out of scope for this project:

SCR-330814-8: Multiple Time Windows
SCR-330814-5: Timer to prevent Vehicle Check Completion
SCR-330814-7: Postpone Job with Reason Code
SCR-330814-13: Re-key Email/Contact/Tel at signature
SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. CALIDUS ePOD has been tested and sized based on the following standard loads:

Load 1 (600 products, 50 totes or loose, 40 jobs):
- 20 jobs with no totes, 5 loose products
- 10 jobs with 1 tote of 30 products, no loose products
- 10 jobs with 2 totes of 10 products, no loose products
Load 2 (500 products, 30 totes or loose, 11 jobs):
- 1 (opening) job with 20 totes of 20 products, no loose products
- 5 jobs with no totes, 10 loose products
- 5 jobs with 1 tote of 10 products, no loose products

The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

Note: There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:

Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.

Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

Note: Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

CALIDUS VEhub (for defect checks and other functionality) is not included in this solution design.

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

Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:

The Primary tracking reference for Zenith is the delivery note number.
There are potentially 500 items on one order.
UAT scheduled for January.
The implementation roll-out will be depot by depot.
Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
Orders are generally 2 types:
- Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
- Standard deliveries to a premises, predominantly in totes, with some loose product.
The maximum number of drops per day per driver run can be 50-60.
There will be a maximum of 500-600 products on a driver's run.
There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices

Android operating system.
There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
Devices to be decided in November. Warning: Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

General System Overview

The core systems are Sage and DPS, with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal).

Orders come into Sage.
Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
Orders are picked in several ways according to the routes created, and the type of deliveries:
- Into totes - this is the most normal delivery mechanism, usually for smaller products
- As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
- Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
- Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
- Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
Sage interfaces routes and orders to CALIDUS ePOD (trigger to be defined).
CALIDUS ePOD sends driving instructions to TomTom on demand.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.

Data Import

All files (inbound to and outbound from CALIDUS ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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/Customer Signature.
POC/POD document format.
POC/POD business address and logo.
Terms and Conditions displayed.

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

It is expected that there will need to be at least three Job Group configurations:

Normal Deliveries with Pricing
Normal Deliveries without Pricing
Opening Deliveries with Pricing
Opening Deliveries without Pricing
Collections

Note: Collections may not require a different Job Group, depending on the functionality required.

Note: Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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

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

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

Details for each Delivery job include:

Route 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.
Driver and Vehicle resource information.
Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
TM (Territory Manager) - sent as the Sales Contact
Customer Details:
- Account Number
- The addresses shown on the POC and POD Notes can be a single customer address (expected to be the account depot address) and a job address (expected to be the final delivery or collection address).
- 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 Route received by ePOD from Sage.
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.
Container (Pallet and Tote) information to include:
- Container (Pallet or Tote) ID - unique for the job
- An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
Product Information to include:
- Product Code - the Sage product code
- Product Description - These are 40 characters within CALIDUS ePOD - this is consistent with the length supported by Sage.
- Product quantities regarding Ordered and Planned Delivered quantities are required.
- VAT Code
- Unit Price - May be zero for items that require no pricing on the POD note.
- Weight
- Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

Note: Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

Note: OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within CALIDUS ePOD, will fall to OBS Logistics to specify and control the modifications to external systems.

SCR-330814-1:

ePOD-Sage Integration meetings and specification.

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

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

Each of these items can be agreed in advanced or administered within CALIDUS ePOD, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in CALIDUS ePOD, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created. As part of the interface mapping exercise, this standing data will be agreed, regardless of whether the interfaces above are implemented within Sage.

Note: It is expected that the standing data will not be transferred through from Sage to CALIDUS ePOD. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to CALIDUS ePOD. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

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 Sage or any routing systems attached to it, then the CALIDUS ePOD Admin system (Load or User screens) may be used to manually allocate drivers to loads.

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

A requirement is to send an email to the customer on receipt of the original order information, CALIDUS Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section Track and Trace later in this document.

SCR-330814-2:

Customer Tracking Email.

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 system supports three job types at this point which encompass the functionality to complete many more tasks with them. At this point the system can be used to complete and record; Deliveries, Collections and Services.

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 print or email a POD.

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

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

Assigning a User to Loads

Assigning Loads to a user

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

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

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

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.

A new VAT Rates maintenance screen.
The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.

SCR-330814-3:

Pricing.

PDA Login

The application will have a customised style created for Zenith Hygiene, which will include:

A blue colour scheme
The logo on the login page.
A larger quantity and appropriate level of information on the Product list

SCR-330814-4:

Create customer-specific style on device.

Login

Additionally, the layout of certain tables 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 logs on to a device entering their provided user name and 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.

Vehicle Checks

When log-in is complete, the device will prompt the driver for the vehicle checks required. The content and frequency of these checks is configurable, from the CALIDUS ePOD Admin system.

Vehicle Checks Sample
Sample 2
Sample 3

Vehicle checks will be based on the information already provided and will include:

Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
First Aid Kit
Tyres
Lights
Oil
Water
Windows
Mirrors
COSHH Manual
Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

Note: Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.

Note: Completed vehicle checks can be viewed through the CALIDUS ePOD Admin screen, which also allows some selection criteria (by vehicle, user and date). These completed vehicle checks can also be exported, either by request through a web service request, or automatically exported. Both methods export the completed vehicle checks in a standard XML format.

No signature is prompted for by the device during vehicle checks - the user name and password will have already ensured that the user is tagged as the checker at this time.

Note: The Vehicle checks prompted for are the same for all vehicle types. If some questions are not applicable to some vehicle types, the question may be configured to be optional and/or have a "N/A" answer attached to them that the driver may select. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

Obtain Workload/Job List

When vehicle checks are complete, 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section Job Swap later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:

ODO - Required numeric entry
Load Secure Visual Check
Sack Barrow on Vehicle

All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

Load Metrics

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 Sage
- Cust Ref - as mapped from Sage
- SO Ref - as mapped from Sage
- Ext Ref - as mapped from Sage
Job Type - Collection/Delivery
Customer Name - Bold
Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.

SCR-330814-5:

Display Total Weight/Unique Products.

This information will be sent to the device from the server - it will not be calculated on the device.

Note: Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 (following).

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

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 give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

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.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to CALIDUS ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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

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

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

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

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

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

Additionally, jobs may already be consolidated together when the load was created - this is expected to be the case for the appropriate jobs received from Sage. 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 completing 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 Swap

Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, CALIDUS ePOD provides Job Swap functionality in several different ways.

Note: Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

Job Swap - No Load
Job Swap - Enter Swap Load

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

Job Swap menu from Job List

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

Job Swap List

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click Swap Jobs. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

Job List showing new jobs
Job confirming swap

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on CALIDUS ePOD. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

Job Details

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

Job Details - Address and Contact
Instructions

The screen has several Tabs, showing:

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

Clicking on the tabs will display the information.

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

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. Note: This is classified as part of the changes specified to the Job List above.

Total Weight/Unique Products display

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to CALIDUS ePOD, this check will be configured to be disabled on the device.

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.

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.

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

Standard Delivery Process

Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

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

Job Details Tab
Containers Tab
Products Tab

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

The Job Details tab has multiple sections:

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

From the Containers tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The Containers tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:

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

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

Container ID
Type
Status

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.

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

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

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

Note: The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the Products tab, which will display a list of the loose products (i.e. not on a pallet or tote) 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 Sage. It is expected to be:

The Product Code
The full Description
Any Customer Reference associated to this product
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.

Note: There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the CALIDUS ePOD will be required to handle this.

SCR-330814-6:

Amendments to handle large numbers of Products.

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 from the pop-up menu.
scanning the product code and clicking Deliver X from the pop-up menu.

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

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. CALIDUS ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

SCR-330814-7:

Allow Scanning of alternate Product Barcodes.

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

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

Note: During this exception process (either quantity change or product cancellation), the user will have the facility to take a photo against the product changed, but this is optional. Note that this is optional at the driver's discretion, rather than depending on the reason code selected by the driver.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

SCR-330814-8:

Identify Pallets that require Product Scanning.

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

Opening Delivery Process

Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

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

Note: The Containers tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

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

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:

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

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:

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 from the pop-up menu.
scanning the product code and clicking Deliver X from the pop-up menu.

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

The driver can change the quantity by choosing Change Quantity from the pop-up menu in the same way as a normal delivery.

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 user will have the facility to take a photo against the product changed, but this is optional. Note that this is optional at the driver's discretion, rather than depending on the reason code selected by the driver.

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

Collection Process

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

Note: Full details have not been received on the collection process other than:

Collections jobs are created solely for the return of product from a customer
They feature Loose Product collection only.

This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:

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

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

The driver can change the quantity by choosing Change Quantity from the pop-up menu in the same way as a normal delivery.

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 user will have the facility to take a photo against the product changed, but this is optional. Note that this is optional at the driver's discretion, rather than depending on the reason code selected by the driver.

When all containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.

Amending Jobs

Some customers check the products within the tote, and others do not. Zenith cannot advise CALIDUS ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:

All products in a tote
All or some loose products
All or some of an individual loose product
All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:

For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

Note: It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

SCR-330814-9:

Allow amendment of products in containers after delivery.

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the Job Details tab and pressing the Complete button available there.

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 collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.

Signature and T&Cs
Containers
Products

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

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

Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
Pallets and Totes collected/delivered.
The quantity of loose products only being 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.

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.

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.

Load End Metrics
Load End Metrics

The metrics required are expected to be:

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

All checks will be required, except Parking Ticket Number.

Note: The following checks may also be added if this is required:

Delivery Notes Signed/Printed
Full Uniform Worn
Failures phoned in
Checked back at depot
Sack Barrow Returned

All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. Note: The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 is being changed for the purposes of this project. The current format has been provided as a sample, as below:

Sample POD Format

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

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

Header

Header with Logo - Fixed
Zenith Address/contact information
Driver Name
TM (Territory Manager) Name
"DELIVERY NOTE" - Fixed Text (based on job type)
Date
Account Number
Purchase Order Number
Delivery Number

Addresses:

INVOICE TO
DELIVERY TO

Product List:

Product Code
Product Description
Qty Ord
Qty Del
Unit Price Note: Not displayed if the job is configured to not have pricing information
Total Price Note: Not displayed if the job is configured to not have pricing information
Weight

Footer:

"HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
Print Name
Signature
Date
NETT Note: Not displayed if the job is configured to not have pricing information
VAT Note: Not displayed if the job is configured to not have pricing information
TOTAL Note: Not displayed if the job is configured to not have pricing information
NOTES
Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

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

Note: Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

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

SCR-330814-10:

POD Note Format.

Data Export

All files (inbound to and outbound from CALIDUS ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 Sage through the standard interface. This is a pushed update, sent at a configurable interval, usually every 5 minutes.

All shortages at delivery (i.e. when CALIDUS ePOD cancels or changes the delivered quantity of an item) may go on back order - this depends on the reason for the quantity change.
All cancelled collections/deliveries (i.e. the driver cancels the job) should be manually re-booked within Sage - the interface back to Sage must be confirmed, and this must be handled by the Sage interface.

There are no expected changes to the existing export format or methodology. The information regarding this has been forwarded to the Sage consultants.

For jobs that have been completed, POD documents will 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 , or entered an the POD device at confirmation of the delivery. 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

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

The CALIDUS ePOD system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

Further Reporting and Queries

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

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

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

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

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

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

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 a Nokia Maps account which is included in the contract

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

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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

Events Tab showing the Postponement event - prototype

Reasons Tab showing the Postponement reason code - prototype

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.

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)

Document Management

It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

SCR-330814-11:

Upload additional documents.

A new Documents tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from CALIDUS ePOD) will not appear on this page, but are accessible through the existing POD button.

Order Enquiry Results to have Documents tab added to the right

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

Gateway - Consignment Signature

Zenith will be able to upload documents in bulk to CALIDUS Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the CALIDUS Portal screens).

Note: This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from CALIDUS Portal when older than 90 days.

Appendix A: Out of Scope Requirements

The following changes are out of scope and can be reinstated at a later date at additional cost

SCR-5-330814: Timer to prevent vehicle check completion

Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the Confirm button. When this timer reaches zero, the button will change to Confirm and will be enabled. If the driver exits the app and restarts, the timer will also restart.

SCR-330814-7 Postpone Job with Reason Code

It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to Postpone Job will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

Note: Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the CALIDUS suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

SCR-330814-12:

Multiple Time Windows.

SCR-330814-13: Re-key Email/Contact/Tel at Signature

A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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.

SCR-330814-14 Allow Admin to set a load in progress

Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to CALIDUS ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:

Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:

Completing the order in WEBFLEET will not complete the order or load in CALIDUS ePOD.
If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

SCR-330814-2: Customer Tracking Gateway

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

Enter Consignment

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

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

Consignment Tracking

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

The screen displays:

The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
- Ordered.
- 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 customers 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 uses 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

Out Of Scope SCR List

SCR#	System	Area	Description	Estimate (Days)	Notes
2	Portal	Email	Customer Tracking Email.	2.75	^{OBS Cost}
5	ePOD	Vehicle Checks	Timer to prevent Vehicle Check Completion.	2.50
7	ePOD/Portal	Exception	Postpone Job with Reason Code.	13.50	²
8	ePOD/Portal	Tracking	Multiple Time Windows.	0.00
13	ePOD	Signature	Re-key Email/Contact/Tel at Signature.	4.50
14	ePOD	Loads Admin	Allow Admin to set a load in progress.	2.00

Appendix B: Table of SCRs and Ballpark Estimates

Essential

SCR#	System	Area	Description	Estimate (Days)	Notes
1	Sage	Integration	ePOD-Sage Integration meetings and specification.	1.00
2	Portal	Email	Customer Tracking Email.	2.75	^{OBS Cost}
3	ePOD	Reporting	Pricing.	10.00
4	ePOD	Look and Feel	Create customer-specific style on device.	1.00
6	ePOD	Delivery	Display Total Weight/Unique Products.	7.25
9	ePOD	Delivery	Amendments to handle large numbers of Products.	4.50	^{OBS Cost}
10	ePOD	Reporting	Allow Scanning of alternate Product Barcodes.	5.50
11	ePOD	Delivery	Identify Pallets that require Product Scanning.	4.50
12	ePOD	Delivery	Allow amendment of products in containers after delivery.	0.00	^{OBS Cost}
15	ePOD	Reporting	POD Note Format.	1.50	^{1.5 days additional to 3 days included in contract}
16	Portal	Loads Admin	Upload additional documents.	3.00

Notes:

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

Appendix C: Document References

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

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

C.3 Authorised By

John Hitchmough	Zenith Hygiene	_____________________________
Matt Turner	OBS Logistics	_____________________________

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' ePOD}}
 {{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
-{{#vardefine:Version|0.8}}
+{{#vardefine:Version|2.00}}
-{{#vardefine:Date|16th December 2015}}
+{{#vardefine:Date|27th April 2016}}
 {{#vardefine:Reference|330814}}
-{{#vardefine:Year|2015}}
+{{#vardefine:Year|2016}}
 </div>
 {{Doc_Title
@@ Line 17: / Line 17: @@
 |Date={{#var:Date}}
 |Year={{#var:Year}}
 }}
 <!-- TOC -->
@@ Line 39: / Line 39: @@
 * Changes relating to information passed through to {{#var:System}} from external systems (i.e. Sage) 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.
-{{Warning}} The following changes may be out of scope of or not essential to this project, as follows:
+{{Warning}} The following changes are out of scope for this project:
-* Multiple Time Windows
+* SCR-330814-8: Multiple Time Windows
-These may be reinstated at a later date at additional cost.
+* SCR-330814-5: Timer to prevent Vehicle Check Completion
+* SCR-330814-7: Postpone Job with Reason Code
+* SCR-330814-13: Re-key Email/Contact/Tel at signature
+* SCR-330814-14: Allow Admin to set a load in progress
+Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.
@@ Line 53: / Line 58: @@
 ** 5 jobs with no totes, 10 loose products
 ** 5 jobs with 1 tote of 10 products, no loose products
 The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.
+{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.
 Results of processing these loads are as follows:
@@ Line 100: / Line 107: @@
 *	There will be a maximum of 500-600 products on a driver's run.
 *	There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
-*	Accurate figures regarding certain run types have been provided.
+*	Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.
@@ Line 114: / Line 121: @@
 The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
 *	Orders come into Sage.
+*	Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
 *	Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
-*	Orders are picked in several ways according to the routes created:
+*	Orders are picked in several ways according to the routes created, and the type of deliveries:
-** Into totes - this is the most normal delivery mechanism
+** Into totes - this is the most normal delivery mechanism, usually for smaller products
-** As loose products, placed on the vehicle in the loose products bin.
+** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
 ** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
+** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
+** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
 *	Sage interfaces routes and orders to {{#var:System}} (trigger to be defined).
 *	{{#var:System}} sends driving instructions to TomTom on demand.
@@ Line 154: / Line 164: @@
 Details for each Delivery job include:
 * Route 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.
+* Driver and Vehicle resource information.
 * Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
-* TM (Territory Manager - sent as the Sales Contact
+* TM (Territory Manager) - sent as the Sales Contact
 * Customer Details:
 ** Account Number
@@ Line 163: / Line 174: @@
 * 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.
 * Container (Pallet and Tote) information to include:
-** Container/Tote ID - unique for the delivery
+** Container (Pallet or Tote) ID - unique for the job
+** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
 * Product Information to include:
-** Product Code
+** Product Code - the Sage product code
 ** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
 ** Product quantities regarding Ordered and Planned Delivered quantities are required.
+** VAT Code
 ** Unit Price - May be zero for items that require no pricing on the POD note.
 ** Weight
+** Alternate Barcode Identifiers - within the Long Description field
 There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.
 {{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.
-For Collection jobs, different information may need to be required, for example:
-* Special Instructions - Job Instructions will be used to indicate to the driver whether the job is a collection or delivery.
-* Job Group
 <!--
@@ Line 212: / Line 221: @@
 Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.
-It is a requirement to send an email to the customer with a link to ''CALIDUS'' Portal TTM for tracking purposes. On receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.
+A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.
+Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
@@ Line 218: / Line 229: @@
 |Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
-Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.
-When this information configured on the Order or Trip Creation event, this will trigger the email.
-Sample email:
- From: [email protected]
- Subject: Your Zenith Order X123 is in progress
- Body:
- Jack Jones,
- Please track your order through the following link:
- <nowiki>http://.../</nowiki>
- If you have any issues, please contact the Zenith team on …
- Yours,
- The Zenith Delivery Team
- Note: This is an unmonitored email account - please do not reply to this email.
 == Administration ==
@@ Line 270: / Line 262: @@
-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. {{Note}} If enabled, Postponement reason codes may be maintained through the Reason Codes maintenance screen an uploaded through templates.
+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
-If required and enabled, Postponement Reason Codes will be shown in the Jobs maintenance screen detail pop-up. {{Note}} This is optional and may not be required.
@@ Line 307: / Line 296: @@
-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 logs on to a device entering their provided user name and 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.
@@ Line 342: / Line 331: @@
 {{Note}} The Vehicle checks prompted for are the same for all vehicle types. If some questions are not applicable to some vehicle types, the question may be configured to be optional and/or have a "N/A" answer attached to them that the driver may select. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.
-Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.
-The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Timer to prevent Vehicle Check Completion.
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-{{Note}} This is a non-essential change.
@@ Line 415: / Line 392: @@
-The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:
+The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery. Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.
+This configuration will be decided at the point of implementation, but is expected that re-sequencing will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.
+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.
-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.
+It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.
 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.
-If enabled, the cancellation option will also show Postponement reason codes, clearly labelled as such in the drop-down list of reasons. In the case that a postponement reason code is selected rather than a cancellation reason code, the driver will be allowed to optionally enter a comment, and the option to take an image will be removed. If confirmed, the postponed job will not be removed from the list, but will instead be marked as Postponed - see later for more information on Postpone Jobs.
-Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.
 The system may be configured for Image Capture in the following ways:
@@ Line 449: / Line 424: @@
 {{Note}} This functionality can be disabled if not required.
-It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Postpone Job with Reason Code.
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.
-As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Multiple Time Windows.
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
@@ Line 558: / Line 516: @@
 When a Job is successfully started, this will take the Job to 'In Progress' status.
+When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.
-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. If enabled, the cancellation option will also show Postponement reason codes, clearly labelled as such in the drop-down list of reasons. As before, in the case that a postponement reason code is selected rather than a cancellation reason code, the driver will be allowed to optionally enter a comment, and the option to take an image will be removed. If confirmed, the postponed job will not be removed from the list, but will instead be marked as Postponed - see later for more information on Postpone Jobs.
-Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.
+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.
@@ Line 641: / Line 600: @@
-{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list, and to ensure that the device will receive only container information (pallet or tote), without contained products, to reduce the size of the jobs on the device. A change to the {{#var:System}} will be required to handle this.
+{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
@@ Line 654: / Line 613: @@
 * scanning the product code and clicking ''Deliver X'' from the pop-up menu.
 When marked as delivered, the item will be removed from the list.
+For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Allow Scanning of alternate Product Barcodes.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
@@ Line 833: / Line 801: @@
 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.
-It is expected that this process will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Re-key Email/Contact/Tel at Signature.
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.
 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.
@@ Line 879: / Line 837: @@
 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.
-== Unplanned Ad-Hoc Orders ==
-Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.
-In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.
-In order to then transfer this to WEBFLEET, there are several options:
-* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
-* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Allow Admin to set a load in progress.
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-Notes:
-* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
-* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
-* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
-* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.
-It is recommended that the operation choose to complete these jobs through the standard mobile device application.
@@ Line 910: / Line 845: @@
 <br />''Sample POD Format''<br />
-It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within {{#var:System)) has not at this time been completed. This will be done at functional specification stage.
+It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.
 At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.
@@ Line 957: / Line 892: @@
-The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into {{#var:system}} and will be confirmed after discussion with Sage and at functional specification stage.
+The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
@@ Line 978: / Line 913: @@
 For jobs that have been completed, POD documents will 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}}, or entered an the POD device at confirmation of the delivery. 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.
+{{Note}} This feature requires access to a mail server for the use of the customer
 Automatic emails may also be sent to a central email address if required. This may be configured at any time.
@@ Line 1,018: / Line 953: @@
 * 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.
+It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract
@@ Line 1,138: / Line 1,073: @@
-=== Customer Tracking Gateway ===
+=== Document Management ===
+It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Upload additional documents.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.
+[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
+<br />''Order Enquiry Results to have Documents tab added to the right''<br />
+Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.
+This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.
+[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
+<br />''Gateway - Consignment Signature''<br />
+Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).
+{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.
+If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.
+Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.
+<!-- MEDIA LANDSCAPE NO -->
+= Appendix A: Out of Scope Requirements =
+<!-- If there’s only one system being discussed here, the system column can be removed.
+Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
+The description should be the description from the text in the main sections.
+The Notes column can be used for many things: grouping optional changes, showing whether the client or OBS originated the gap, etc. -->
+The following changes are out of scope and can be reinstated at a later date at additional cost
+==''' SCR-5-330814: Timer to prevent vehicle check completion''' ==
+Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.
+The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.
+== '''SCR-330814-7 Postpone Job with Reason Code''' ==
+It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.
+If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.
+{{Note}} Two none development options have been provided for job postponement
+) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time
+) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list
+As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Multiple Time Windows.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+==''' SCR-330814-13: Re-key Email/Contact/Tel at Signature''' ==
+A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.
+The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.
+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.
+==SCR-330814-14 Allow Admin to set a load in progress ==
+Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.
+In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.
+In order to then transfer this to WEBFLEET, there are several options:
+* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
+* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.
+Notes:
+* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
+* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
+* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
+* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.
+It is recommended that the operation choose to complete these jobs through the standard mobile device application.
+== '''SCR-330814-2: 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.
@@ Line 1,159: / Line 1,190: @@
 *	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.
@@ Line 1,175: / Line 1,205: @@
 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
+*	The customers 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 ETA at the location of the order being checked. {{Note}} This functionality uses HERE maps for calculation of the ETA.
@@ Line 1,188: / Line 1,218: @@
-=== Document Management ===
+== '''Out Of Scope SCR List''' ==
-It is a Zenith optional requirement to upload further documents pertaining to orders (for example, an invoice document and backing sheet) into the system, to be displayed on the Portal in the same way as the POD. There must also be functionality to download the documents.
+{{REQ_SCR_Header}}{{REQ_SCR_Line
+|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+}} {{REQ_SCR_Line
-|Definition=Upload additional documents.
+|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}} {{REQ_SCR_Line
-}}
+|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
+}} {{REQ_SCR_Line
-A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.
+|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
+}} {{REQ_SCR_Line
-[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
+|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
-<br />''Order Enquiry Results to have Documents tab added to the right''<br />
+}} {{REQ_SCR_Line
+|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
-Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.
+}} {{REQ_SCR_Footer}}
-This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.
-[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
-<br />''Gateway - Consignment Signature''<br />
-Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).
-{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.
-If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.
-Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.
 <!-- MEDIA LANDSCAPE YES -->
-= Appendix A: Table of SCRs and Ballpark Estimates  =
+= Appendix B: Table of SCRs and Ballpark Estimates  =
 <!-- If there’s only one system being discussed here, the system column can be removed.
 Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
@@ Line 1,238: / Line 1,253: @@
 |SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
 }} {{REQ_SCR_Line
-|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=8.0|Notes=OBS Cost
+|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
 }} {{REQ_SCR_Line
-|SCR=10|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
+|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
 }} {{REQ_SCR_Line
-|SCR=11|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
+|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
 }} {{REQ_SCR_Line
-|SCR=14|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=4.5|Notes=
+|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
-}} {{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.
-<!-- NEW PAGE -->
-== '''Non-Essential''' ==
-{{REQ_SCR_Header}}{{REQ_SCR_Line
-|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
 }} {{REQ_SCR_Line
-|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
+|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
 }} {{REQ_SCR_Line
-|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
+|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
-}} {{REQ_SCR_Line
-|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
-}} {{REQ_SCR_Line
-|SCR=12|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
-}} {{REQ_SCR_Line
-|SCR=13|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
 }} {{REQ_SCR_Line
-|SCR=15|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|Notes=
+|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|Notes=
 }} {{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.
-#Cost shown is for a full tracking solution within EPOD and Portal. If Portal tracking only is required, the cost in 9d. If Sage is to cancel and reissue a new job, 0d.
 <!-- MEDIA LANDSCAPE NO -->
 {{Doc_Appendix
-|Appendix=B
+|Appendix=C
 |Estimate=N
 |Glossary=EPOD
@@ Line 1,301: / Line 1,300: @@
 |Year=
 |FSEST=Y
-|Rev1=Michael Rayner
+|Rev1=John Hitchmough
 |Rev1Title=Zenith Hygiene
 |Rev2=Matt Turner

Anonymous

Search

REQ 330814 Zenith ePOD Requirements: Difference between revisions

Latest revision as of 16:04, 27 April 2016

Introduction

Objective

Scope and Limitations

Client Requirements

Operational Overview

General System Overview

Data Import

Administration

PDA Login

Vehicle Checks

Obtain Workload/Job List

Job Swap

Job Details

Standard Delivery Process

Opening Delivery Process

Collection Process

Amending Jobs

Job Completion

Post-Load

POC/POD Documents

Data Export

Further Reporting and Queries

Track and Trace

Trip/Order Enquiry

Order Enquiry

Trip Enquiry

Order Detail

Airport Screens

Tracking Emails

Document Management

Appendix A: Out of Scope Requirements

SCR-5-330814: Timer to prevent vehicle check completion

SCR-330814-7 Postpone Job with Reason Code

SCR-330814-13: Re-key Email/Contact/Tel at Signature

SCR-330814-14 Allow Admin to set a load in progress

SCR-330814-2: Customer Tracking Gateway

Out Of Scope SCR List

Appendix B: Table of SCRs and Ballpark Estimates

Essential

Appendix C: Document References

Navigation

Wiki tools

Page tools

Categories