REQ 330814 Zenith ePOD Requirements

From Calidus HUB





Aptean Logo.png







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 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 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 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 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 Note: Collections may not require a different Job Group, depending on the functionality required.

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

EPOD Users2.PNG EPOD LoadAssign1.PNG
Assigning a User to Loads

EPOD Load2.PNG EPOD Load3.PNG
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 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 SCR-330814-4: Create customer-specific style on device.
  • Login

    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

    Vehicle Checks Sample

  • Sample 2

    Sample 2

  • Sample 3

    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 Note: Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.

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

    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

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

  • Job Swap - Enter Swap 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

    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

    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 List showing new jobs

  • Job confirming swap

    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

    Job Details - Address and Contact

  • Instructions

    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 Note: This is classified as part of the changes specified to the Job List above.

  • Total Weight/Unique Products display

    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

    Job Details Tab

  • Containers Tab

    Containers Tab

  • Products Tab

    Products Tab


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

    Signature and T&Cs

  • Containers

    Containers

  • Products

    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

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

REQ 330814 POD.PNG
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 Note: Not displayed if the job is configured to not have pricing information
  • Total Price Note 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 Note: Not displayed if the job is configured to not have pricing information
  • VAT Note Note: Not displayed if the job is configured to not have pricing information
  • TOTAL Note 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 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 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 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

REQ 324746 TTM OrdEnqParms.PNG
Order Enquiry Parameters


The enquiry responds with a results table summarising the matched orders:

REQ 324746 TTM OrdEnqResults.PNG
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

REQ 324746 TTM TripEnqParms.PNG
Trip Enquiry Parameters

REQ 324746 TTM TripEnqResults.PNG
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

REQ 324746 TTM OrderDetail.PNG
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:

REQ 330814 TTM OrderDetail Events.PNG
Events Tab showing the Postponement event - prototype

REQ 330814 TTM OrderDetail Reasons.PNG
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:

REQ 324746 TTM ArrDep.PNG
Arrive/Depart screen

REQ 324746 TTM OrderStatus.PNG
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:

REQ 330814 TTM Events.PNG
Portal Events Maintenance

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

REQ 330814 TTM Events Email.PNG
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 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.

REQ 324746 TTM OrderDetail.PNG
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.

REQ 330814 Portal Upload.PNG
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 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 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 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.

REQ 324746 TTM Gateway Login.PNG
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:

REQ 324746 TTM Gateway Tracking.PNG
Consignment Tracking


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

REQ 324746 TTM Gateway Signature.PNG
Gateway - Consignment Signature


Out Of Scope SCR List

SCR#SystemAreaDescriptionEstimate (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  2
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#SystemAreaDescriptionEstimate (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:

  1. 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 NoDocument Title & IDVersionDate
1UG 291094 EPOD Admin User Guide3.016/10/2014
2UG 291097 EPOD Client User Guide4.016/10/2014
3FS 291096 Interface with CALIDUS ePOD1.005/02/2015
4Portal User Guide - TTM6.812/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		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=REQ_330814_Zenith_ePOD_Requirements&oldid=3087’