JB Global

Oak Furniture Land Solution Design

CALIDUS ePOD

24th July 2017 - 1.0
Reference: REQ 344060

Introduction

This document is the Oak Furniture Land Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from JB Global, at the following meetings:

Initial meeting in Swindon - Demo provided with website data.
Second meeting at Customer reference site (Brett Martin).
Third meeting - Pre-Sales Workshop with detailed demo
The document has been amended with feedback from the customer, culminating in a review meeting on 05/07/2017.

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

The changes will be made in the latest version of the CALIDUS ePOD system, operating the Android version of the C-ePOD Client application.
Changes relating to information passed through to CALIDUS ePOD from external systems (i.e. WMS/ERP) 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.
Modifications are required to the customer systems (WMS/ERP) to achieve the functionality described in this document.
This document specifies changes for Lot Capture. It must be noted that this is not functionality for Lot Traceability, just the capture of the Lot numbers, to be passed back to the customer's WMS/ERP on Radial Deliveries only. None of the OBS systems included in this implementation will display or search for the captured Lot numbers.
This document specifies Loading and Unloading being performed by warehouse staff, not the drivers. It must be noted that CALIDUS ePOD is not a replacement for an RF-enabled Warehouse Management/Control system. Existing functionality and creative load building within the customer's systems is being used so that C-ePOD may be used for this purpose, but this is not the primary purpose of the application.
For Lot traceability, it would normally be expected that this be captured by the WMS/ERP and a unique item label produced for that order, identifying the Lot and Product implicitly. An item label has now been provided as part of the process, but this is not linked to the Lot number by the customer's systems.

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

Main Office Address:

JB Global Ltd
DC2
Viscount Way
South Marston Industrial Estate
Swindon
SN3 4TN

There are 4 main distribution depots:

Brentwood
Manchester
Glasgow
Swindon

Contacts:

Louis Merrett - Project Manager - [email protected]
Nav Mohammed - Lead Developer working on interface - [email protected]

OBS Logistics Contacts:

Barry Preece - Project Manager - [email protected]
Matt Turner - Sales/Account Manager - [email protected]
Warren Wright - Sales/CALIDUS VEhub - [email protected]
Tony Walker - Solution Design - [email protected]

The core systems for the business are an internally-maintained WMS/ERP, utilising PTV DPS for route creation/optimisation, with OBS Logistics' systems as follows:

CALIDUS ePOD - execution.
CALIDUS VEhub - vehicle checks, accident reports, asset tagging at locations.
CALIDUS Portal TTM - transport/order tracking.

The operational processes will be:

Orders are entered into the WMS/ERP.
WMS/ERP interfaces the orders to DPS for routing/optimisation.
When complete, the trips created will be interfaced to C-ePOD.
CALIDUS VEhub captures vehicle checks.
CALIDUS ePOD executes jobs and captures the actual delivery quantities and signatures.
Navigation to locations using CoPilot.
CALIDUS VEhub used to capture accident reports and/or asset tagging at locations.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.
CALIDUS ePOD updates WMS/ERP with actual quantities and times when jobs are complete or cancelled.

200 M3 SM10 rugged hand-held Android devices with 1D scanners have been ordered for the operation, along with various accessories. 70 devices are to be held at branches for seasonal peaks. Extra drivers are employed for peak periods.

The device supplier will be pre-loading the devices with the mobile applications for C-VEhub, C-ePOD, and CoPilot. JB Global will be ordering the SIM cards for these devices themselves and will install after delivery. Devices will not be delivered with Mobile Device Management software - if this is required, this is expected to be installed by the customer. The C-ePOD application will require configuration to connect to the final Test or Production systems and configure for the site (depot or warehouse) for the device - QR barcodes for Test and Production systems for each Site will be provided to speed this configuration.

The software will be rolled out as follows:

CALIDUS VEhub - Swindon first, then to all depots.
CALIDUS ePOD - Swindon first, then to all depots.
CALIDUS TTM - configured after C-ePOD go-live at Swindon.

The project has a 6-8 week lead time to software delivery, from the point of contract confirmation, which was 26/06/2017.

A project plan will be sent to the customer when available, detailing the time-lines of all phases of the project, including the implementation and development phases.

The operation will expect to execute the following movement types:

Trunk - unloading only by warehouse staff
Radial Delivery/Collection
Loading for Radial Delivery/Collection by warehouse staff

Excluded from C-ePOD execution:

Supplier drop-shipments into depots
Collections from suppliers into depots.

However, this is controlled by the loads and jobs sent to C-ePOD from the customer's WMS/ERP, so if these transport types are to be controlled through C-ePOD, they can be added through the interface. This solution does not cover these processes, however.

The customer plans to scan off (unload) consolidated products on trunk deliveries into the depots using C-ePOD. Trunks between depots will not be executed on C-ePOD by the drivers, but will instead by unloaded by warehouse staff in the destination depot. These will be sent on a separate load, under a different Site code (for the warehouse), for execution by the warehouse staff. A unique load will be sent for the day, with a job containing all of the products to be unloaded for that day.

The single job will contain multiple trunk trailers' deliveries consolidated into one product list. On average this job could be 300 to 500 product lines, involving 1000 to 1500 scans over a night period. The single job will be kept open until all product has been received/or the change quantity process has been employed for not present or damaged items.

It should be noted that this volume of products on a single job will take some time to download initially and may affect the efficiency of the process. It has been advised that these should be split into individual jobs per unloading vehicle, but the operation has declared that it is sometimes not entirely accurate as to what is on the vehicles. It is noted that Wifi would be the preferred connection to download this load and this has been assumed to be the case in the depots.

This load will have no user or vehicle assigned to it - the depot will assign it manually to a warehouse operative user utilising the C-ePOD Admin system.

Note: Trunks will not be loaded by warehouse staff with C-ePOD devices.

The customer plans to load the delivery items into delivery vehicles at the depot, by means of scanning each job with delivery items (loading) onto the defined vehicle in reverse order. The WMS/ERP will send the load for the vehicle through in reverse order to the delivery route, with no jobs consolidated. Loading for radial (delivery/collection) trips will not be executed on C-ePOD by the drivers, but will instead be loaded by warehouse staff in the delivery depot. These will be sent on a separate load, under a different Site code, for execution by the warehouse staff. A unique load will be sent per vehicle per trip and the all the jobs will be present in reverse loading sequence.

All warehouse-executed trips (i.e. loading and unloading) will be performed through C-ePOD by warehouse staff on a specific site code for the warehouses associated to the depots. The warehouse staff will have usernames and passwords.

The customer will user C-ePOD for radial delivery/collection routes, executed by the drivers. The radial (collection/delivery) trip will consist solely of the delivery/collection jobs, and the delivery items required for each job.

Product is delivered into depots 'drop-shipped' by suppliers directly. These will not be unloaded through C-ePOD.

Data Import

The integration is being performed by in-house I.T to OBS Logistics' standard XML schema. The interface will use Webservices. The customer has already begun to prototype this import interface.

This (and the export interface) requires a mapping exercise with the customer's I.T. team to ensure that the data is being sent as expected and conforming to both the requirements of the implementation and the C-ePOD product.

SCR-344060-1:

Interface Mapping

Import and Export Mapping documents will be created and shared with the customer to aid in the creation of the interface. An Import mapping spreadsheet has been completed by OBS indicating the essential data, as derived from this document. It is expected that this mapping exercise will be conducted w/c 24/07/17, awaiting confirmation from the customer.

In addition, the WMS/ERP will also be sending tracking emails (and SMS messages) to the customer using their pre-existing functionality. The link to the CALIDUS Portal customer tracking gateway will be included in this email. The URL will be built including the reference to the order number, but not the postcode, as in the following example:

   http://[ website ]/Gateway?mod=POR&src=LOTS&sub=tracking&act=find&ref=GS295098

It should be noted that CALIDUS Portal also includes functionality to achieve this, and may be configured for this at any time.

The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. A C-ePOD user, on a device or in the Admin screen, can only see data for one site at a time.

There will be two Sites per depot in the network:

One will be for the warehouse operations (i.e. Loading/Unloading trips).
One will be for the transport operations (i.e. Radial Collection/Delivery trips).

The sites contain some configuration that controls how the mobile device operates when completing jobs under these sites.

The Warehouse sites will be configured as follows:

Forced Container and Product Entry disabled.
Job Arrival disabled.
Complete jobs out of sequence set to "N - Disabled".

The Transport sites will be configured as follows:

Forced Container and Product Entry disabled.
Job Arrival enabled.
Complete jobs out of sequence set to "N - Disabled".

Loads will be sent to C-ePOD as part of this interface, identifying each unique trip for that vehicle and all the jobs to be completed as part of the load.

Trunk unloading jobs will be interfaced on a single load per depot per day, with a single job. The products on this job will be the consolidated values of all the product being trunked. The load will contain at least the following information:

Site - the destination depot's warehouse
Load - a unique load reference for the site
Planned Start and End times.
Vehicle - the vehicle delivering the load.

Radial Collection/Delivery Loading jobs will be interfaced on a single load per vehicle per depot, with all jobs for delivery in reverse delivery sequence. The load will contain at least the following information:

Site - the loading depot's warehouse
Load - a unique load reference for the site
Planned Start and End times.
Vehicle - the vehicle delivering the load.

Radial Collection/Delivery jobs will be interfaced on a single load per vehicle per depot, with all jobs for delivery in delivery sequence. The load will contain at least the following information:

Site - the delivering/collecting (executing) depot
Load - a unique load reference for the site
Planned Start and End times.
Vehicle - the vehicle delivering the load.

Note: The driver executing the load may also be interfaced - this may be applicable for Radial Collection/Delivery loads, but unlikely to be for the warehouse-executed loads (i.e. Loading and Unloading).

Jobs will be interfaced as part of the loads, indicating the details of the jobs to be complete as part of the loads, and also the sequence on the load. The details for each job are expected to contain:

Planned Start (arrival) and End (completion) Date and Time. This is expected to be the recipient's provided delivery window
Type (Delivery or Collection)
Order Number (in Job Code)
Customer Name, Address and Contact information (including email if required)
Delivery Instructions

Note: Loading and Unloading jobs should be interfaced with a loading indicator, for visibility purposes, as follows:

Loading - Job Type Delivery, Loading Indicator "L".
Unloading - Job Type Collection, Loading Indicator "U".

Note: Sequence must be provided for each job on a load. This is a straight numerical sequence. The values depend on the purpose for the load, as follows:

Unloading - Set to 1, as there will be only one jobs on the load.
Loading - set in reverse delivery sequence.
Radial Delivery/Collection - set in delivery sequence. It is noted that Collection jobs at an address will be sequenced before the Delivery jobs at that address, for the purpose of emptying out the customer property first.

Note: Collections will be interfaced to C-ePOD on the radial trips as separate jobs to any delivery jobs for the same customer. It is noted that the current example POD shows a collection item against a delivery job - this is not expected to be the normal process and must be excluded in the future. Note that these collection jobs will be processed independently, and will require separate processing and signature capture on the mobile device.

Note: There is a facility to provide an invoice (customer) and delivery (job) address separately in the interface. This is not expected to be required, as it is expected that the customer address will always be the delivery address.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:

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

These will be agreed as part of the interface meetings. It is expected that there will be job groups as follows:

Trunk Jobs e.g. "TRUNK" or "UNLOAD"
Loading Jobs e.g. "LOAD"
Delivery Jobs e.g. "DEL"
Collection Jobs e.g. "COL"

The Job Group for Radial Deliveries is expected to be configured as follows:

Customer to sign for goods
NO Deliver All process
NO driver signature
Job Photos (required)
Scan at Vehicle (to allow checking, Failed delivery user-defined form entry and final confirmation)
Pre-Job (Arrival) Terms and Conditions and Signature (optional)

The Job Group for Radial Collections is expected to be configured identically to the Radial Delivery jobs. However, this can be changed if desired.

The Job Groups for trunk unloading and loading are expected to be configured as follows:

NO Customer signature
NO Deliver All process
NO driver signature
NO Job Photos
NO Scan at Vehicle
NO Pre-Job (Arrival) Signature

The details of jobs will be interfaced differently depending on the Job Type:

Trunk Unloading - products will be sent
Radial Loading and Radial Collection and Delivery - delivery items with unique delivery item IDs (barcoded of delivery labels) will be sent as containers.

The products, when sent for Trunk Unloading jobs, will be created on each job created with the details taken from the WMS/ERP. The details expected to be received are:

Product Code - set from the barcode Product ID.
Description - a truncated version of the description.
Long Description - the ERP product code (e.g. "OAKMAG001") plus the full description, delimited by a dash.
The total planned and ordered quantities.
The Unit volume in Cubic Metres, interfaced in the Item Type (i.e. not total volume).
The Unit Weight (i.e. not total weight).

Note: OBS Logistics' systems internal product description is 40 in length, whereas the customer's product description appears to be 50 (e.g. "Posture pocket plus supportive 1000 pocket spring". As such, the interface will truncate the description for the standard description field, and include the product code and full description in the long description field.

Containers for C-ePOD represent unique delivery items for this operation. The containers, when sent, will be created on each job created with the details taken from the WMS/ERP. The details expected to be received are:

Container (Item) ID - The delivery label ID
Package Description - The Product Code (e.g. MAT-PLUS1000MED-SINGLE)
The Unit volume in Cubic Metres (stored in a CODE_1 field).
The Unit Weight.
Description - The full description of the product.

Containers (Items) will require Lot capture at Radial Loading and/or Radial Delivery and Collection. The system will be configured for these job types (through the job group) to request the scan of the Lot number after the item is scanned. Note that this Lot capture is configurable per job type and therefore can be changed if required (for example, removed from collections).

Loads and jobs may be re-sent multiple times - no difference is required in the way that the XML is created. C-ePOD will update the load and the jobs on the load with the new details, provided the load and jobs have not already been completed. Any jobs not on the re-interfaced load will be deleted. Any products not on the jobs will be deleted.

Any exceptional late additions to Trunk Unloading loads will be as a separate job on the same load.

Note: Changes to the items loaded during the processing of executing Radial Loading (i.e. items not loaded) will be reflected back into the WMS/ERP from C-ePOD. Note that this should trigger a re-send of the Radial Delivery load at that time to C-ePOD from the WMS/ERP, so that the driver is not prompted to deliver items that were never loaded.

Loads may be deleted through the interface if no longer desired.

Certain data is required for configuration of all OBS systems being installed, such as:

Depots
Users, including passwords/PINs. In this case this includes:
- Drivers
- Warehouse Operatives (Loaders/Unloaders)
Vehicles, including Registration, Make and Model
Trailers (if used)

This information must either be provided in advance or (in the case of C-ePOD) sent to or created as part of the interface to C-ePOD with the Loads and Jobs. The system will be configured to create this standing data from the received import information with basic information. This may then need to be modified (for example, if a new driver is received, it will be created in C-ePOD, but with a default password that should be changed). This will be agreed as part of the interface discussions.

Users are maintained in C-ePOD at Site level. Therefore there will be different users for the warehousing sites (i.e. loaders/unloaders) as compared to the transport depots (i.e. drivers). Each depot and warehouse will have their own users and passwords.

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 (Admin console) and a mobile device application for use in completing jobs, consisting of pick-ups (collections and loading) and drop-offs (deliveries and unloading).

The CALIDUS ePOD Administration console is a web-based application that handles all of the administrative side of the C-ePOD devices.

Note: Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the Oak Furniture Land network for all users that require it.

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 and Vehicles.
To view the Jobs and Loads created.
To track progress against the Loads, Jobs, Vehicles and Users.
To print or email a POD/POC.

It is assumed that all Loads will be assigned to Vehicles through the WMS/ERP import interface.

A facility to manually assign Loads to drivers and vehicles is provided for problem-solving purposes.

The resource allocation may be managed 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

If loads are created without a driver assigned (vehicle will always be assigned through the interface), the driver will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

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

CALIDUS VEhub

The CALIDUS VEhub system will be used in this implementation to:

Capture Vehicle Checks
Capture Accident Reports

Note: CALIDUS VEhub is already configured for Oak Furniture Land use and is ready to be used. It is likely that this will be rolled out to all depots as soon as possible, with a handover session booked for 05/07/2017. However, note that C-VEhub is not part of this solution design document, and will configured as part of the implementation of this project.

Accident reports will be configured after Vehicle Checks have been implemented.

As part of this project, C-VEhub will be created for each depot to access their vehicles and the data entered through the mobile application. C-VEhub Admin access will be provided for every branch.

Note: Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the Oak Furniture Land network for all users that require it.

The drivers will be provided a user-name and password. The users and their passwords must be configured within C-VEhub. It is recommended that these user-names and passwords match between C-ePOD and C-VEhub.

It is expected that the C-VEhub application will be installed for the delivery drivers only - warehouse staff will not require access to this application. However, if this is a task that is performed by the warehouse loaders, this can be provided. This is not recommended as a reasonable process, however, as the driver is responsible for the safety of the vehicle they will be driving, not the warehouse operatives.

C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot, certainly for user-acceptance testing. This may also be configured when the product moves live.

C-ePOD Mobile Device Application

The mobile device application will be used to execute the following types of loads executed by the depot drivers, namely:

Radial Deliveries and Customer Collections

Additionally, this will be used by the warehouse staff to execute the following processes:

Trunk unloading
Radial Loading

The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other types.

Note that full details of the use of each process on the mobile device are not included in this solution design, but can be obtained from the user guide, referenced in this document's appendices.

C-ePOD Mobile Device Login

The application will have a customised style created for Oak Furniture Land, which will include:

Oak Furniture Land logo at login stage.
Job List as standard (showing the Job reference, type (collection/delivery), customer name, planned date and time and post code)
Removal of the Has this Delivery been checked check box on the Job Details screen.
Container (Delivery Item) list including Delivery Item ID, Product Code, full description, volume and weight.
Any reference to "Container" changed to "Item" (i.e. on all labels, pop-up messages and alerts).
Product list including Product Barcode ID, Product Code, full description, volume and quantity.
Blank customer signatory at the Customer signature stage.
Removal of the SMS button on Job Details screen.
Cancelling of items will labelled as "Item Exception".
Clausing of items will be labelled as "Delivered Exception".
All reference to "Pre-Job Signature" will be changed to "Pre Delivery Disclaimer" (i.e. on all labels, pop-up messages and alerts).

SCR-344060-2:

Custom Oak Furniture Mobile Device Styling

The details of the specific styling will be shown in each section following.

Log In

The drivers will be provided a user-name and password, and the loads will be allocated to specific vehicles, ensuring that they can complete only the loads required. The users and their passwords must be configured within CALIDUS ePOD. Note: User IDs that are created automatically as part of the Standing Data creation at Load Import will be available for use, but will have a default password created. This password should be modified before use as a security precaution. It is expected that the user-name and password will be the same for the drivers across CALIDUS VEhub and CALIDUS ePOD.

A driver will log on to a device using the 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.

Note: Vehicle checks will be completed through the CALIDUS VEhub application and are not integrated into CALIDUS ePOD. CALIDUS VEhub is not within the scope of this document. There will be no vehicle checks implemented within CALIDUS ePOD for Oak Furniture Land processes.

Obtain Workload/Job List

When log on is 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 (and/or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Job List

The layout of the job list as demonstrated is acceptable to the customer, with one modification. The time will not be displayed on the Job List, through configuration of the style on the device. The defined elements are:

The order number (Job Code)
The job type (Collection, Delivery, Loading, Unloading)
The location (address name)
The planned start date and time
The post code from the location

The screen will display the status of the jobs on the load through a coloured outline or background, 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 by the driver. It is expected that this will be strongly sequenced by the data imported into C-ePOD, and that the following will be the case:

For Radial Collection/Delivery loads, the jobs will be sequenced in the order they should be completed. Collections will be displayed separately from the delivery jobs, and expected to be before the delivery job on the Job List. These collection jobs will be processed independently, and will require separate processing and signature capture.
For Loading loads, the jobs will be sequenced in reverse delivery sequence. All jobs will be Loading jobs.
For Unloading loads, there will only be one job for all the product to be unloaded.

The jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.

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

Refresh Load - Refresh the Load/Worklist from the server, to pick up any updates
Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
Log Out
Change Vehicle
Cancel Jobs

There are also some bug-reporting options available on this pop-up menu, which may be asked to be used from time to time by the OBSL or client support staff.

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

No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed (see the following for details on cancellation for the business units).
Confirm re-sequencing allowed - this requests the user to confirm first.
Always allowed - no confirmation.

It is expected that re-sequencing of jobs will not be allowed.

If any jobs have been added to a Load while the load is in progress, the Refresh option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs if, for example, if quantities have been amended, products added, etc.

Long-pressing against the line will display some options from a pop-up menu:

Details - show the Job Details screen (following).
Cancel - the selected job or jobs will be cancelled. The application will display an Exception screen and prompt for entry of a reason code indicating why this job was cancelled.

Cancelling a Job

It is expected that the Cancel Job will be used when a customer is not in and the driver is unable to deliver or collect the goods.

The driver can cancel jobs by clicking the Cancel Job button on the job detail screen. This will operate as described against the Job List above.

This will call the cancellation screen where the user will be prompted to enter a reason why this job is being cancelled. The cancellation screen also allows the user to take a picture.

Note: Whether or not a picture is required for a job cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Job Only' then a picture must be taken to cancel a job, otherwise the picture is optional. If Job Cancellation is enabled, it is expected that the application will not be configured to require a photo, although one can still be taken if required.

The customer requires a change to this process to allow the user to enter some additional details when cancelling a job when the customer is not in.

Reason for failure (in addition to the cancellation reason code, values for this are still to be confirmed)
Return #
Card #

The application will be amended to allow for a User-defined Form (UDF) to be configured against Job Cancellations. This will also allow configuration against a specific reason code rather than for all jobs for this site or job group.

SCR-344060-3:

UDF for Cancelled Jobs

Once the driver has selected the reason code (and taken any photos), they will click the provided OK button. If UDF has been configured, a screen will pop-up to allow the entry of the additional information. All fields will be required. If they are not entered, the driver will not be allowed to confirm the cancellation.

If a job is confirmed cancelled and all additional details are entered (or none are required), the device will show the Job List again with the cancelled job removed from the list.

Job Details

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

Address & Contact
Instructions

The screen has several sections and tabs, showing:

The Job Type (Collection, Delivery, Loading, Unloading)
The customer details (Customer Code, Name, Address and Postcode)
The contact information (Contact name and number)
The planned collection/delivery window for the job, including the start and end times.
The Instructions for the job

Clicking on the tabs will display the information.

The Instructions tab will show instructions for the job, as well as any additional information passed through for the job.

Note: The screen allows the driver to contact the customer (through either text or phone) - the application will display appropriate icons to allow the drivers to accomplish this. It is noted that, as part of the styling changes, the SMS button will be removed, as drivers are not allowed to text the customers in this operation.

Cancelling a Job

The driver can cancel jobs by clicking the Cancel Job button on the job detail screen. This will operate as described against the Job List above.

Navigation and Arriving

The driver will select Start Job from the Job Details screen.

Note: If there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

Note: It is expected that re-sequencing of jobs will not be allowed for Oak Furniture Land. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and will not be allowed to continue.

Once started, the device will display a navigation button. Clicking this will start navigation through the installed navigation app. The application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.

For this implementation, ALK CoPilot navigation is expected to be installed on the mobile devices and will be used for navigation. Note that the functionality regarding navigation is controlled entirely by this application, separate to the CALIDUS ePOD application - please consult the CoPilot documentation for details as to how this operates and how it may be configured.

Once arrived at the destination, the driver will switch back to the CALIDUS ePOD mobile application. For standard Android devices, the app switcher can be used to switch back to the C-ePOD mobile application.

The driver will then indicate arrival and start processing the Job by clicking the Arrive Job button.

When clicking the button to start, arrive at or deliver the job, the application performs a check whether the job has been changed since it was loaded on the device, to ensure that the latest data is on the device for the job. If there are changes, the driver will be informed and the screen will refresh.

The device will move on to the Delivery or Collection process, depending on the job type.

Radial Delivery Process

The driver process at a delivery point is:

Arrive at site (recording time of arrival).
Pre-Job (i.e. post-arrival) Terms and Conditions and Signature (Difficult Delivery Disclaimer) if required.
Positively confirm delivery of delivery items through scanning of item barcodes.
Capturing of lot numbers.
Complete delivery (recording time off site) and capture signature and signatory.

When the driver has confirmed arrival, the device will display a pre-job signature and disclaimer.

Confirm Pre-job Signature required
Difficult Delivery Disclaimer

As part of the mobile device styling changes, all instances of "Pre-job Signature" will be changed to "Pre-Delivery Disclaimer".

This will configured to be optional, so the driver can skip this if not required.

The device will then move on to the delivery of the delivery items.

Radial Deliveries will consist of multiple containers (delivery items).

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

Job Details Tab
Job Details Tab - Addresses
Containers Tab
Notes Tab

The Job Details tab has multiple sections:

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

As part of the styling changes, the check-box "Has this delivery been checked?" will be removed from the screen, and "Containers" will be changed to "Items" wherever it is used in the application. Additionally, any reference to "Container" in the app will be changed to "Item" (i.e. on all labels, pop-up messages and alerts).

Data must be captured against a job if any items have been cancelled, namely:

Have the delivery team tried to get the item to the room of their choice?
Is it likely that the item will fit unpacked?
Is there another solution that we can identify?
Is the customer aware of the reason this cannot be delivered?
Reason for Failure
Return #
Card #

The 4 Y/N questions on the Failed Delivery Check List will be drop-down lists of "Y" and "N", with default values. The Reason for Failure will be a drop-down list of user-defined codes without a default value, that must be selected. The Return Number will be required entry.

This required data will be configured against as a User-Defined Form (UDF) against the Job Groups that require it (i.e. Collection and Delivery jobs). This will be present on this Job Details tab for the user to enter.

From the Items tab, the device will show a list of the items to be delivered, which will be styled to show only the following elements:

Delivery Item (Container) ID.
Product Code
Full description.
Volume
Weight

Actions against the items can be activated by long-pressing against the row, and have the following actions:

Deliver
Deliver Claused, changed to Delivered Exception as part of the mobile device styling changes.
Cancel, changed to Item Exception as part of the mobile device styling changes.
Info
Product Barcode

Container Long-press Pop-up
Container Info Pop-up

For information on the actions above, see the appropriate following sections.

When all items have been confirmed as delivered or cancelled, the Delivery process will return to the Job Details tab, where a Complete button will be displayed, to complete the job. It is then possible to review the list of items delivered and change this if required. The list will display a border and status to indicate whether the items have been delivered:

Red - Cancelled
Amber - Delivered with an amendment (changed quantity)
Green - Delivered in full.

The status and the Planned and Actual quantity will be displayed for confirmation.

The system will be modified so that the information is only enforced to be captured if the job is marked as amended (i.e. some items have not been delivered). In this case, once all items are confirmed as delivered, the Delivery process will return to the Job Details tab, where a Complete button will be present to confirm all as delivered. The Failed Delivery Check List items will be seen on this screen.

If Complete is pressed, and the job is amended, the driver will be instructed that the information must be entered. If the job is not amended, the driver will be allowed to skip entry of this information.

SCR-344060-4:

Job UDF Required dependent on Job Amended

Note: Clausing an item does not mark the job as Amended, and therefore the Failed Delivery Check-list will not be required to be entered.

Note: The Failed delivery check-list will not include photos - if a delivery has any cancelled items, it may still be delivered and a signature captured. This process will then allow the driver to take Job Photos, which can be used to capture any images associated to the failed delivery items.

Failed Delivery Check List and Complete

If all the items were fully delivered, or the Failed Delivery information has been fully entered, when the driver clicks the Complete button, this screen will close and the user will be directed to the Job Completion process.

Delivering an Item

Each deliverable item will be labelled with an Item Label with a barcode in CODE-128 format of a unique numeric item ID.

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

selecting the item from the list and selecting Deliver
entering the Item ID manually and clicking the Deliver button.
scanning the Item ID, using the application Scan button and camera scanning feature, or using a connected or integral hardware scanner.

If items are entered that are not part of this delivery, the application will issue an error and will not deliver the item.

If any user-defined fields are required to be entered against the delivered items, the application will prompt for this information at this stage. If required, the information must be entered before the item is marked as delivered.

There is a requirement to capture the Lot number portion of the barcode scan and pass this back to the WMS/ERP.

Additionally, in the instance of a failed scan (container or Lot), the customer would like a facility to take a photo.

Both of these requirements will be achieved through configuration of a Container user-defined form (UDF) against the items. This will allow the user, after scanning the Item ID, to enter the Lot number and potentially a photo.

Lot Number Entry

This will be prompted as "Product Barcode" on the form. The driver will scan the Product Barcode in this field. The form will store the lot extracted from the barcode scanned (with validation).

The product barcode is in GS1 format, and contains:

91 - Agreed between suppliers - in this case this is confirmed to be the numeric Product ID, representative of the product code. This is up to 30 characters, but will predominantly be 4 numeric characters.
10 - Batch or Lot Number. This is up to 20 characters, but will predominantly be 5 numeric characters.

The photo will be present, labelled as "Missing Barcode" and allow as many photos as the driver requires.

Both of these items will be optional entry by the driver, and may be skipped.

The application will require changes to this UDF functionality for the following purposes:

Recognise GS1 (UCC/EAN-128) barcodes
Extract the correct AI (Application Identifier) for the Lot number from the barcode scanned

SCR-344060-5:

Container UDF Barcode Extraction Changes

The driver can select to start this UDF page at any time against any Item by pressing the item in the list and selecting Product Barcode'

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

Cancelling an Item

If an item cannot be delivered, it can be removed from the list with the pop-up option Item Exception. The exception screen will be shown where the driver can enter the reason for the cancellation.

Container Cancellation

For clarification, details about the item being cancelled are displayed here.

A reason code must be entered by the user for an item to be cancelled.

The application will be not configured so that the driver is required to take a picture associated with this cancellation, but one may be taken if desired, using the provided photo button.

Clausing an Item

If an item is delivered but customer or user notes are to be captured against the Delivery, it can be delivered from the list with the pop-up option Delivered Exception. Again, the exception screen will be shown where the driver can enter the reason or notes for the claused Delivery.

Container Clausing

For clarification, details about the item being cancelled are displayed here.

The application can be configured to require:

Clause reason codes
Clause comments

The application will be not configured so that the driver is required to take a picture associated with this clausing, but one may be taken if desired, using the provided photo button.

Note: Clausing an item does not mark the job as Amended, and therefore the Failed Delivery Check-list will not be required to be entered.

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.

The device will prompt for Customer Signature for Radial Collections and Deliveries, and for Desk Collections.

Customer Signature and T&Cs
Customer Signature and Containers

The signatory will by configuration be set to be blank and always required entry. 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.
The quantity of containers being collected/delivered.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under or to the right of the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time and is expected to be finalised during implementation. These are currently expected to be:

SIGN TO ACKNOWLEDGE RECEIPT OF GOODS AND NO DAMAGE TO PROPERTY

In the instance where a customer is not in, it is expected that the job will be cancelled (through the Job Cancellation functionality described above). It should be noted that, if the customer is not in, but the items can still be delivered, the delivery can be completed as normal and the driver can sign PP on behalf of the customer.

The list of items delivered will be displayed, allowing the driver to click on each for more information and to allow clause notes and reason codes to be entered, if required.

Item Information and Clausing

Note: The application can be configured to require driver signature, although this is not expected in this implementation.

After signature completion, the mobile device will be configured to prompt for photos. This is to capture any images associated with completed or failed deliveries. This photo capture process is expected to be initially configured to be required for Radial Collections and Deliveries only, but can be removed or made optional if desired.

The driver will be able to take as many photos as required, view the captured image or re-take the photos.

Job Photo

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, etc) updated. The updates are sent whenever the driver has a viable data 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. Any completed jobs can be optionally viewed again, by pressing the Menu button and choosing Show All Jobs. The list can be made to show only outstanding jobs again by pressing the Menu button and choosing Show Outstanding Jobs.

Post-Load

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

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, re-login or log off the system.

Radial Collection (Returns) Process

It is expected that, where planned returns of products are created, these collections will be interfaced to as separate Collection jobs and present on the Radial Delivery/Collection loads.

The collection process will be almost identical to the Radial Delivery process described above, substituting Collection instead of Delivery. So:

The collection will be on the Job List with the radial deliveries, as a separate job, requiring separate confirmation and signature.

The driver will start and arrive the job as above.

The driver will be prompted to obtain pre-job signatures if required.

The collection will follow the same Item barcode scanning process.

The driver will have been provided a number of unique collection Item labels at the start of the trip by the warehouse. As the driver collects the products, the driver will apply a collection label and scan it.

The application will then prompt for the lot number and potentially photos, in identical fashion to the Delivery process. Again, both of these are optional and may be skipped.

The driver can cancel (Item Exception) or clause collect (Collected Exception) in the same way as described in the Radial Delivery process.

When all items have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process, which will configured as:

Customer to sign for the collection. The screen will display the items collected.
Job Photo will be prompted for, and will require a photo to be taken.

Trunk Unloading Process

The trunk unloading loads will be sent to a different (warehouse) site, and assigned to a vehicle and warehouse operative through the C-ePOD Admin screens.

The warehouse operative will sign on to the device, and enter their user and password. There will be only a single load for the day, assigned to a default warehouse vehicle for simplicity of process.

Note: As there will be only one load, only one operative will be able to log into the application to access the unloading load - it is not possible to have 2 operatives processing the same load.

The load will be displayed, but in this case there will be only one job, as all product is consolidated onto one load.

The warehouse operative will select the job and will immediately start it - there is no prompt for arrival. Any instructions will be forced to be viewed.

Trunk Unloading jobs will consist of multiple loose products.

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

Job Details Tab
Job Details Tab - Addresses
Products Tab

The Job Details tab will display as before, but without the failed delivery check-list.

From the Products tab, the device will show a list of the products to be delivered, which will be styled to show only the following elements:

Product Barcode ID.
Product Code and full description.
Volume (stored in the Item Type)
The planned quantity.

Actions against the products can be activated by long-pressing against the row, and have the following actions:

Deliver X
Change Quantity
Cancel
Info

Products Long-press Pop-up
Product Info Pop-up

Note: The system will be configured so that the user may not confirm a line without scanning it. The functions above are for error-correction and should not be used in place of scanning barcodes for the product.

For information on the actions above, see the appropriate following sections.

All of the products received throughout the day will be unloaded and counted off against this single load and job.

As each product is fully scanned and unloaded, the product will be removed from the list.

Once all product is unloaded, any remaining product on the list will be confirmed as short using the Quantity Change process. Any product not received may be confirmed as actual quantity 0 or cancelled using the appropriate processes below.

Once all products are confirmed as unloaded, short or cancelled, the job will be complete - the mobile device will immediately complete the job, as the configuration is not expected to require signatures or job photos. At this point, the warehouse operative may select any other jobs on the list, although it is expected that there will only be one. When all jobs on the load are complete, the load will be closed.

Unloading a Product

The standard mechanism of confirmation of the quantity of a product received will be modified for this customer. This will be configurable, and will be expected to be configured for Trunk Unloading only.

The unloading of product will be configured so that the warehouse operative cannot confirm the quantity by just pressing on the row on the screen - the product code must be scanned or manually entered. This is through existing configuration in the system.

A physical hardware scanner (part of the device) or the built-in application scanner (using the camera) may be used to scan the product barcode.

The product barcode is in GS1 format, and contains:

91 - Agreed between suppliers - in this case this is confirmed to be the numeric Product ID, representative of the product code. This is up to 30 characters, but will predominantly be 4 numeric characters.
10 - Batch or Lot Number. This is up to 20 characters, but will predominantly be 5 numeric characters.

The application will be modified to be configured to recognise and extract the GS1 data elements from the barcode scan.

The Product ID will be used to identify the product line on the product list. The quantity unloaded will be increased by 1.

As each item's barcode is scanned, the quantity will be incremented, until the actually unloaded quantity equals the planned amount, at which point the product will be considered to be fully unloaded and the product will be removed from the product list.

It is not required that each product is fully scanned before moving to the next, although this is recommended - the warehouse operative can scan items from multiple products mixed together, and each line will be incremented by 1 each time they scan the barcode.

SCR-344060-6:

Product Quantity Countdown

When all quantity of product that can be found for the job have been scanned, there may be a shortage on some lines. In this case, the warehouse operative will use the Change Quantity process (below) to confirm the shortage and enter a reason code.

Changing a Product Quantity

The warehouse operative can change the quantity by choosing Change Quantity from the pop-up menu, accessed by long-pressing on the product line - 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.

Exception - Change Product Quantity

For clarification, the product code and description and the job and customer are also displayed here.

The application will be not configured so that the warehouse operative is required to take a picture associated with this change of quantity.

If zero is entered as the new quantity, the application will cancel the product and remove it from the product list. If the quantity is changed (and is not set to zero), the product will be marked as having the quantity entered unloaded and will be removed from the product list.

Note: As part of the Product Quantity Countdown change above, the quantity will be defaulted to the amount currently scanned, and will not be allowed to be increased, although it may be decreased.

Cancelling a Product

Where a product is not on the vehicle, the warehouse operative process will be to cancel the product with the pop-up option Cancel, accessed by long-pressing on the product line.

As with quantity change, the exception screen will be shown where the warehouse operative can enter the reason for the cancellation.

The warehouse operative will also be able to optionally take a picture associated with this cancellation.

Note: Whether or not a picture is required for a product cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Detail Only' then a picture must be taken to cancel a product, otherwise the picture is optional.

The application will not be configured so that the driver is required to take a picture associated with cancellation of products.

Radial Loading Process

The radial loading loads will be sent to a different (warehouse) site, and assigned to a vehicle.

The warehouse operative will sign on to the device, and enter their user and password, identifying the vehicle to be loaded.

The load will be displayed. There will be multiple jobs on this list, displayed in reverse delivery sequence.

The warehouse operative will select the first job and will immediately start it - there is no prompt for arrival. Any instructions will be forced to be viewed.

Note: The warehouse operative will not be allowed to load the jobs out of sequence.

The Radial Loading process will be by Delivery Item (Container) ID, and is functionally identical to the Radial Delivery process, with the only difference being that the device will display "Collection" or "Loading" instead of "Delivery" (and similar words).

When the job is complete, the mobile device will not prompt for any signatures or photos. Instead, the process will return to the job list after confirmation that all product is loaded. Note that this configuration can be changed at any time, but is expected to be this way for initial implementation.

When the job is complete, the warehouse operative will continue loading all jobs in the same manner.

Note: Changes to quantity at loading will be reflected back into the WMS/ERP from C-ePOD. Note that this should trigger a change of quantity onto C-ePOD for the radial delivery load.

When all jobs are complete, the entire workload will also be complete. There will be no more work for this vehicle. The warehouse operative can then re-login from the prompt, selecting the next vehicle to load.

POC/POD Documents

Once jobs are completed, then will be confirmed with the C-ePOD server. After this confirmation, a POD/POC report may be produced.

All photos taken by the driver during the execution of the job (i.e. at cancellation of product, change quantity of product, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view, but will not be included in the PDF version of the document (generally the version emailed to customers).

The format attached to the job group is the format that will be produced from the Admin console and displayed for customers when requested through CALIDUS Portal.

Oak Furniture Land POD/POC

The different job types will require different completion reports, although they will look very similar:

Radial Deliveries - summing the delivery items into product lines, on a POD report.
Radial Collections - using the POD report above, but displaying Collection instead of Delivery.
Radial Loading - using the POD report above.
Trunk Unloading - displaying the product lines themselves, on a POC report.

The format of the POD note has been prototyped to show capability. The format has been provided and the prototype is shown below:

Prototype Oak Furniture Land POD Format

SCR-344060-7:

Oak Furniture Land POD/POC Formats

Note: The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into .

Page Header, expected to be displayed on every page:

Company Logo - It is expected that this will be the logo taken from the site.
"JB DIRECT DELIVERY NOTE" - fixed text, displaying "Collection Note" if the job is a collection.
"0800 440 2254" - taken from the telephone of the site's address.

DATE - The planned start date, in YYYY-MM-DD format.
TIME - The planned start and end times, delimited by a dash, in HH:MM format.
TYPE - The Job Type
ORDER NUM # - The Job Code
CUSTOMER/ADDRESS/POSTCODE/TEL1/2/3 - from the job address if present, otherwise the customer address.
"DELIVERY INSTRUCTIONS" - Fixed text, displaying "COLLECTION INSTRUCTIONS" if the job is a collection. The job instructions are displayed beneath this.
Failed Delivery checks (1) - taken from user-defined fields against the job.
DATE - The actual end date, when the signature was obtained.
TIME - The actual end time, when the signature was obtained.
PRINT NAME - The signatory, captured by the driver on the device when the customer signs.
SIGNATURE - the customer's signature.

Product Details, expected to be shown on every page, expected to show up to 15 products per page. Note: This may need to be reduced to account for the digital nature of the signatures on the POD/POC report):

QTY - The actual quantity of the product delivered, as confirmed by the driver.
PRODUCT - the product code and full description, as held in the Long Description field in C-ePOD.
Kg - the unit weight of the product, multiplied by the delivered quantity.

Note: PCS and CBM columns have been agreed to be present but not populated from this table. A total line will be displayed, summing the Weight column. Note: The POD report will require a modification to this format to group the delivery items by the product code and sum the values.

Footer, expected to be shown on all pages:

"SIGN TO ACKNOWLEDGE..." - T&Cs from the completed job, expected to be "SIGN TO ACKNOWLEDGE RECEIPT OF GOODS AND NO DAMAGE TO PROPERTY".
DATE - The actual end date, when the signature was obtained.
TIME - The actual end time, when the signature was obtained.
PRINT NAME - The signatory, captured by the driver on the device when the customer signs.
SIGNATURE - the customer's signature.

DIFFICULT DELIVERY DISCLAIMER and all text and signature - Taken from the post-job signature and T&Cs. Note: If they are not present (i.e. they were not captured by the driver) then this section will not be present.

Failed Delivery checks (2) - taken from user-defined fields against the job. Consisting of:
- REASON FOR FAILURE
- RETURN #
- CARD #

Note: The TIME DOOR COLOR will be removed, as it is expected that this will be made redundant through the process of Job Photos if required.

It has been agreed to keep this format as close as possible to the existing format used by the operation. However, due to the size of digital signatures, some restructuring of the report has taken place in the prototype to accommodate this. These changes must be reviewed and agreed.

Data Export

When jobs are completed (cancelled or confirmed as delivered, with or without shortages), C-ePOD will be configured to push the updates in OBS XML format to a webservice hosted by the WMS/ERP. This will require development by the in-house I.T. staff.

This will contains all of the information from the job provided to C-ePOD, and all the captured information from the execution of the job, including (but not limited to):

Actual dates and times
Failed Delivery information
Captured Lot numbers
Delivered product quantities
Signatory and Signatures
Terms & Conditions agreed to

C-ePOD will not be configured to automatically email the completed POD or POC to the customer's email address, if provided on the job.

However, these automatic emails or exports may be configured or changed at any time.

Further Reporting and Queries

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

Loads
Jobs
Containers/Products

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

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
Load picked up
Job started
Job arrived
Job completed
Load completed
Log off

User Tracking - Activities
User Tracking - Location

Track and Trace

CALIDUS Portal 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, tracking their delivery
Customer Service Queries
Transport Office

CALIDUS Portal is kept updated at all times by CALIDUS ePOD of all states of the loads and jobs, for example:

The Trip itself.
The Order itself.
The sequence of the Order on the Trip
When an order is in transit.
When an order is collected and/or delivered.
When an order is cancelled.

The messages identify any changes to quantities and reasons for these changes at all stages.

It is expected that ETAs will be shown on the Portal (except for the Customer Tracking Gateway) - this functionality requires the purchase of a Nokia Maps account. As the system is hosted through OBS, this cost may be part of the hosting agreement.

The Portal system will be styled for Oak Furniture Land, specifically the Customer Tracking Gateway screen.

SCR-344060-8:

Custom Oak Furniture Land Portal Styling

The core C-Portal TTM module and screens will be used - labels and layout will be configured standard configuration tools through an implementation session immediately following the first site C-ePOD go-live.

The following is a brief description of functionality available within CALIDUS Portal that has potential to be used by Oak Furniture Land and their customers if required. This is by no means a full list of all functionality available within CALIDUS Portal - the user guide (referenced in the Appendices of this document) contains the full details of the available functionality.

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

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

Order Details

Details can be found of the following:

Events - the Messages received by the LOTS system from external systems e.g. C-ePOD, 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 external systems.
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.
'Documents - Allows the upload/view of documents held in the Portal against the order.

Order Event Details

Order Info Details

Arrivals/Departures (Order Status) Screen

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. The recommended screen is the Order Status screen.

Order Status Screen

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

The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.

Order Status Parameters

Customer (Order) Visibility Screen

This screen represents a combination of all the screens above in one place, to simplify access.

Order Visibility Parameters and results

Similar selection criteria to the Trip/Order Enquiries and Order Status screens can be accessed from the left-hand panel. Results will be shown on the right.

When an order is selected, the Order Details page is displayed.

Order Visibility Details

Clicking on each of the icons on the top of the page displays similar information to the other enquiry results screens. This screen also allows the user to maintain CRM-related notes and events.

Order Visibility CRM Details

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. As part of the implementation, this ETA will be removed from the screen, as requested.

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

Gateway - Consignment Signature

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	EPOD	Integration	Interface Mapping	2.00	²
2	EPOD	Device	Custom Oak Furniture Mobile Device Styling	1.75	²
3	EPOD	Device	UDF for Cancelled Jobs	5.00	²
4	EPOD	Device	Job UDF Dependent on Job Amended	3.00	²
5	EPOD	Device	Container UDF Barcode Extraction Changes	6.00	²
6	EPOD	Device	Product Quantity Countdown	6.50	²
7	EPOD	Reports	Oak Furniture Land POD/POC Format	6.00	²
8	PORTAL	TTM	Custom Oak Furniture Land Portal Styling	2.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.
These changes will be delivered as part of the contracted delivery at no additional cost.

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1	UG 291094 EPOD Admin User Guide	4.0	21/07/2016
2	UG 291097 EPOD Client User Guide	5.0	23/12/2016
3	FS 291096 Interface with CALIDUS ePOD	1.1	11/01/2017
4	Portal User Guide - TTM	6.9.20	14/12/2016

B.2 Glossary

Term or Acronym	Meaning
General Definitions
EPOD	Electronic Proof of Delivery. The OBSL EPOD system is CALIDUS ePOD. This also comprises the basis of the Service Completion system CALIDUS eServ.
Server	The portion of the CALIDUS ePOD/eServ systems that controls all the data and sends information to and receives updates from the mobile device.
Mobile Device; PDA	The device used by the driver to perform the jobs. Typically an Android mobile device or tablet.
Site	The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. An EPOD user, on a device or in the Admin screen, can only see data for one site at a time.
Load	A single journey for the driver with a set of work attached. A load is identified by a unique load ID. This may also be referred to as a worklist or workload.
Job	Also Consignment. A single task for the driver as a specific location. This could be the collection of goods or the delivery of goods. Jobs may also be Services (for example, servicing, installing or de-installing a boiler). A job is identified by a unique job ID but can also have other references held against the job (e.g. job code, SO number, customer reference and external reference).
Job Group	Jobs must be tagged with a Job Group. All jobs tagged with a single job group are processed in the same way. The job group has configuration associated to it to control such items as: POD/POC Report settings; Pre-Job actions (such as signing at a gatehouse); Post-Job actions (such as who signs for the item, are photos required); configurable fields required for entry for the jobs; Terms and Conditions displayed and; driver/user process (such as photos required for cancellation, comments/notes allowed). The job group can be used for any or all Sites, and the configuration against the job group can be different in each site. Job Groups can also be restricted from Admin and Remote users, so that certain users only see jobs for certain groups.
Container	A generic term for any object that contains the items being collected or delivered. Examples of containers are: Pallet; Package; Carton; Item; Cage. A special container "Loose Products" - see Product below. A container is identified by a container ID which is unique to this physical container.
Product	A product is any goods that are being collected or delivered where the product has a 'Product Code' which identifies what the product is but which does not uniquely identify each individual item. A product will also have a quantity associated with it to indicate how many items of this 'Product Code' are being collected or delivered. Products can either be processed within a 'Container' or as 'Loose Products' without a 'Container'.
Owner	The owner of the order that created the job. Typically this is the sales team that took the order and will be responsible for dealing with queries from the customer regarding the status.
Operator; Executor	The Site (depot or carrier) that is executing the load or loads that are involved in the delivery of the items.
Item Related Definitions
Job Code	A reference associated with a job or job(s). This reference is common to connected jobs, for example this would be the same on both the collection of goods and the associated delivery of the same goods. Typically this would be the transport unique reference.
SO Number	A reference associated with a job which indicates the "Sales Order Number" this job is associated with.
Customer Reference	A reference associated with a job which has been provided by and will be recognised by the customer.
External Reference	A reference associated with a job which does not match any of the existing references, usually because it has been provided by an external system.
Pallet	An alternative for 'Container'. The term pallet is used when the operation only uses portable platforms as the container for goods.
Package	An alternative for 'Container'. The term package is used when the operation only uses boxes or wrapping as containers for goods.
Package Code	A code representing the type of 'Container'.
Package Desc	A description of the type of 'Container'.
Product Code	A code which identifies what a product is.
Item	A generic term for any individual item that can be collected or delivered. An item can represent a 'Container' or a 'Product'. This can also be used as an alternative for 'Container' when the operation only treats the goods as individual items, i.e. not as identifiable products.
Service Item	An item which will be serviced by a service job. See action 'Service'.
Issue Life	The time after which an item is no longer fit for purpose.
Pack Size; Case Quantity	A product may consist of a full quantity of items, inside a pack. The Pack Size (or Case Quantity) defines the amount of this product contained in a single pack. For example, if there are 85 items to deliver, with a pack size of 24, the number of full packs is determined to be 3 (24 * 3, or 72), with the remaining (13) being 'loose' quantity. This is displayed as "3/13" on the mobile application.
UOM; Item Type	Unit of Measure; The major (case) UOM. This can optionally be displayed on the mobile device when changing product quantities.
Product Type	A classification of the product being delivered. For example, a company may deliver 7 different mortar products and 80 different concrete slab products. The Product Types may be set to "MORTAR" and "SLABS". This may be used to attach additional configuration, changing the data required when collecting or delivering these product types.
Status Definitions
Status	An indicator of how far through the processing a 'Job', 'Container' or 'Product' has progressed.
Pending	A status indicating that the processing has not yet started, but is required to be completed.
In Progress	A status indicating that processing has started but not yet finished.
Complete	A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered.
Complete (Amended)	A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered but that some changes or amendments have been made. This means that not everything that was planned to be collected or delivered was collected or delivered, some items may have been cancelled or some products may only have had some of the planned quantities collected or delivered.
Complete (Claused)	A status indicating that the processing has been finished but that a 'Clause' condition has been recorded for this item.
Claused	See 'Complete (Claused)' and action 'Clause'.
Cancelled	A status indicating that the processing of this item or job is no longer required.
Cancelled at Collection	A status indicating that the delivery of a container or product is no longer required because the associated collection of this container or product was cancelled.
Submitted	An optional status that applies only to a 'Job' and which occurs after the 'Job' has been completed. This indicates that any time and expenses information recorded for the 'Job' has been submitted back to the server and can no longer be altered.
Action Definitions
Start	An action associated with a 'Job' meaning the driver is about to start the processing of this job or jobs. This action will mark the job(s) with a status of 'In Progress'.
Arrive	A conditional action associated with a 'Job' meaning the driver has arrived at the location the goods should be collected from or delivered to.
Continue	An action associated with a 'Job' meaning the driver has previously performed the 'Start' and/or 'Arrive' action and has exited the processing screen but is now going to continue the processing.
Collect	An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Collect Claused	An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product' but with a condition under which the collection was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Deliver	An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Deliver Claused	An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product' but with a condition under which the delivery was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Clause	An action associated with a specific 'Container' or a 'Product' that has already been collected or delivered meaning the collection or delivery has been accepted with a condition. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Cancel	An action associated with a 'Job', 'Container' or 'Product' meaning the collection or delivery will not be performed for this 'Job', 'Container' or 'Product'.
Submit	An optional action which can conditionally be carried out after a 'Job' has been collection or delivered meaning that any/all required expense or time recording for this 'Job' has been completed and can be submitted back to the server.
Service	A service of a service item or items. Typically, Installation, Deinstallation or Service. The process of a service usually encompasses Pre- and Port-work checks, information gathering and diagnosis and resolution notes. Additional references (MC Refs) may also be captured.
Actioned	A general term describing completing a job. So, 'Actioned' may be used instead of 'Collected', 'Serviced', 'Delivered'.
Consolidate	The action of taking several jobs and linking them together, so they are actioned at the same time with one start, arrive and signature.
Deconsolidate	The action of taking a consolidation of jobs and breaking them down into the component jobs again.
Job Swap	The action of selecting an existing load not assigned to the user, and picking jobs to transfer onto the user's load.
Signature Capture	Usually the final action of a job, where the customer's name and signature are entered.
Other Definitions
Reason Code	A code which represents the reason that a job was cancelled or an item was cancelled or claused.
Vehicle	The vehicle used for transporting the goods.
Vehicle Checks	Also Defect Checks. A series of questions representing the results of checks intended to ensure the vehicle is in an acceptable condition.
Metrics Entry	A series of questions to capture information either at the start or end of a 'Load'.
Driver	The person performing the collections or deliveries; the user of the device/application.
Engineer	The person performing the services; the user of the device/application.
Customer	The person/company the goods are being collected from or delivered to.
Signatory	The name of the person providing a signature.
T&Cs	Terms and Conditions. The T&Cs are shown when signatures are prompted for. The text of the T&Cs are defined in the system itself.
Transfer Load	A load select from which to swap jobs to the user's load.
Base	E.g. 'Return to Base'. Typically the depot from which the driver departed.
Unplanned Ad Hoc Collection	A collection job that is created by the driver, usually after delivering to a customer.
Ad Hoc Container Entry/Scanning	The process of adding containers (items) to a job that have not been pre-advised on the job.
Completion Report	POD, POC, Service/Work Report.
Load Assignment	The action of assigning a vehicle and/or a driver to a load.
Job Assignment	The action of putting jobs onto a load.
Collection/Delivery Windows; Access Windows	Periods of time between which it is acceptable to deliver or collect from that customer. This has limited use in the system, mostly for reporting purposes.
Location/Map Terms
Lat-Longs; GPS Co-ordinates, GPS Position	Latitude and Longitude co-ordinates, specified together as a single entity, identifying the exact position of a location. There are multiple formats - CALIDUS ePOD uses decimal notation, for example "53.3490818,-2.8521498" identifies the OBS Logistics office building in Liverpool.
GPS	Global Positioning System; the satellite system used to obtain a GPS position, for use with navigation and location positioning.
Geocode; Reverse Geocode	Geocoding is the process of obtaining lat-longs from an address. Reverse Geocoding is the process obtaining an address from lat-longs.
Geofence; Geofence Break	A Geofence is a perimeter around a location. A Geofence Break occurs when a device passes through this perimeter on entry or exit from the location.

B.3 Authorised By

Louis Merrett	Oak Furniture Land Representative	_____________________________
Matt Turner	OBS Logistics Representative	_____________________________

Anonymous

Search

REQ 354567 JB Global POD Note Changes

Introduction

Objective

Scope and Limitations

Client Requirements

Operational Overview

Data Import

Administration

CALIDUS VEhub

C-ePOD Mobile Device Application

C-ePOD Mobile Device Login

Obtain Workload/Job List

Cancelling a Job

Job Details

Cancelling a Job

Navigation and Arriving

Radial Delivery Process

Delivering an Item

Cancelling an Item

Clausing an Item

Job Completion

Post-Load

Radial Collection (Returns) Process

Trunk Unloading Process

Unloading a Product

Changing a Product Quantity

Cancelling a Product

Radial Loading Process

POC/POD Documents

Oak Furniture Land POD/POC

Data Export

Further Reporting and Queries

Track and Trace

Trip/Order Enquiry

Order Enquiry

Trip Enquiry

Order Details

Arrivals/Departures (Order Status) Screen

Customer (Order) Visibility Screen

Customer Tracking Gateway

Appendix A: Table of SCRs and Ballpark Estimates

Appendix B: Document References

Navigation

Wiki tools

Page tools

Categories