JB Global

Oak Furniture Land Solution Design

CALIDUS ePOD

26th June 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

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) 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) 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 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 and a unique item label produced for that order, identifying the Lot and Product implicitly. However, there is no delivery item label on the products being delivered - this is not part of the process now and is deemed too much change for the operation.

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

Established in December 2008, JB Direct is JB Global's in-house delivery company which facilities 95% of deliveries for all of the group's furniture retailers (including Oak Furniture Land).

The delivery fleet is made up of 40 7.5 tonne and Luton vans, as well containing 10 articulated lorries which collectively fulfil over 2500 orders every week. With over 95 members of staff, JB Direct covers almost the whole of the UK spanning from Plymouth to Inverness.

Deliveries are booked in advance directly with the customer by JB Direct's telephone advisers who will confirm a specific date and a 3 - 4 hour time window for the delivery to take place to ensure maximum convenience for the customer. Delivery is made using a two-man delivery service on all orders using fully trained professional delivery staff, who will contact the customer when they are approximately thirty minutes away to keep the customer fully informed. Additionally, during delivery the drivers will take every item on the order into the property and directly to the requested room of choice by the customer so that all of the heavy lifting is taken care of.

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:

Jason Bannister - Owner - Warning: Email
Warning:

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]

Existing System Processes

The core systems for the business are an internally-maintained WMS, 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.
WMS interfaces the orders to DPS for routing/optimisation.
When complete, the trips created will be interfaced to C-ePOD.
CALIDUS VEhub captured vehicle checks.
CALIDUS ePOD executes jobs and captures the actual delivery quantities and signatures.
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 with actual quantities and times when jobs are complete or cancelled.

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

Warning: The software will be rolled out as follows:

CALIDUS VEhub - All depots
CALIDUS ePOD - All depots (big bang)
CALIDUS TTM

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 timelines 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
Warning: 3rd-party transport
Collections from suppliers into depots.

However, this is controlled by the loads and jobs sent to C-ePOD from the customer's WMS, 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 trunk deliveries into depot 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 per vehicle per trip. Trunks will not be loaded by warehouse staff with EPOD devices.

The customer plans to load the products into delivery vehicles at depot, by means of scanning each job with products (loading) onto the defined vehicle in reverse order. The WMS 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 stops.

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

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.

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

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.

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

The Transport sites will be configured as follows:

Forced Container and Product Entry enabled.
Job Arrival enabled.
Complete jobs out of sequence 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 vehicle per depot, 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 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.

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

It is expected that there will be job groups for:

Trunk Jobs
Loading Jobs
Delivery Jobs
Collection Jobs

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
Arrival Signature (optional)
Job Photos (optional)
Scan at Vehicle (to allow checking, Failed delivery user-defined form entry and final confirmation)
Pre-Job Terms and Conditions and Signature

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 Arrival Signature
NO Job Photos
NO Pre-Job Signature

The products will be created on each job created with the details taken from the WMS. 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.

Loads and jobs may be resent 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.

Note: Changes to quantity during the processing of executing Radial Loading will be reflected back into the WMS from C-ePOD. Note that this should trigger a change of quantity onto C-ePOD from the WMS for the jobs on the radial delivery load.

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

Warning: The system will be configured to create standing data from the received import information, such as:

Drivers
Customers (Invoice Addresses)
Vehicles

As noted above, it is expected that this data will be created at implementation.

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 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 is used to:

Capture Vehicle Checks
Asset Tagging at locations
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.

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.

Warning: It is expected that the 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 their vehicle.

Warning: C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot.

Warning: It is noted that the insurance cover note will be provided to the drivers through a cloud-enabled repository, such as DropBox.

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.
Product list including Product Barcode ID, Product Code, full description, volume and quantity.
Blank customer signatory at the Customer signature stage.

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

The Job List will display collections and delivery jobs separately. These jobs will be processed independently, and will require separate processing and signature capture.

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

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, Service)
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.

Cancelling a Job

The driver can cancel jobs by clicking the Cancel Job button on the job detail screen.

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.

If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

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.

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 product through incremental scanning of product 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.

Difficult 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 products.

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

Data must be captured against a job if any products 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 Checklist 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 and Card Numbers 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. This is optional at this stage.

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
Comments
Cancel
Info

Products Long-press Pop-up
REQ 344060 PDA Delivery6a.png

Product Info Pop-up
REQ 344060 PDA Delivery6b.png

Product Info Pop-up (More)

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

When all products 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 products delivered and change this if required. The list will display a border and status to indicate whether the products 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 products have had short delivery). 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 Checklist 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-3:

Job UDF Required dependent on Job Amended

If all the products 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 a Product

The standard mechanism of confirmation of the quantity of a product delivered will be modified for this customer. This will be configurable, and will be expected to be configured for radial deliveries and collections.

The delivery of product will be configured so that the driver 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 delivered will be increased by 1.

As each item's barcode is scanned, the quantity will be incremented, until the actually delivered quantity equals the planned amount, at which point the product will be considered to be fully delivered 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 driver can scan items from multiple products mixed together, and each line will be incremented by 1 each time they scan the barcode.

SCR-344060-4:

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 driver will use the Quantity Change process to confirm the shortage and enter a reason code.

There is also a requirement to capture the Lot number portion of the barcode scan and pass this back to the WMS. The device will capture this seamlessly as part of the Product Quantity Countdown barcode scanning process above and store each Lot number found against the product. When the job is updated back into the C-ePOD database, the scanned lot numbers will be sent back on each product, in a delimited list (for example, if there were 3 of 1 product, 2 of lot 12345 and 1 of lot 98765, the delimited list would be ""12345|12345|98765"". Each lot scanned will be captured and returned. This information will be exported with the job when the details are returned to the WMS after job completion.

SCR-344060-5:

Lot Capture

Note:

This Lot capture is part of the process of scanning each barcode.
If the user cancels a product completely, any scanned Lot numbers against that line will be blanked.
If the user manually changes the quantity delivered (with a reason code), the lot number scanned up to that point will be kept, for reference, and returned with the product line to the WMS.
If the user manually keys in the product ID alone (e.g. 1408), the application will not recognise this as a valid scan - the whole barcode must be entered, minus the brackets, for example:
- 9114081016274
In this way, the application ensures that the information is captured regardless of whether the barcode cannot be scanned.

Changing a Product Quantity

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.

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 driver 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 delivered 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.

Cancelling a Product

Where delivery of a product is refused, the driver process will be to cancel the product delivery with the pop-up option Cancel. This is necessary, as the process will be to get the customer to sign for the non-delivery of the product.

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

The user 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.

Note: As part of the Lot Capture process, if the user cancels a product completely, any scanned Lot numbers against that line will be blanked.

Commenting a Product

This option will call the exception screen to allow the user to enter any comments against this product and optionally take a photo.

Exception - Commenting on a product

Note: Reason codes are the operation's to maintain and will be maintained only within C-ePOD, as they are never to be updated back to the WMS.

Note: As part of the Product Quantity Countdown change above, the quantity will be defaulted to the amount currently scanned.

Collection (Returns) Process

It is expected that, where planned returns of products are created, these collections will be interfaced to as separate Collection jobs.

The collection process will be almost identical to that 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 barcode scanning process (Product Quantity Countdown).

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

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 Products

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

If the customer is not in, but the items can still be delivered, the delivery will be completed as normal and the driver will sign PP on behalf of the customer.

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

After signature completion, the mobile device is expected 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 optional, but can be removed or made required.

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.

Trunk Unloading Process

The trunk unloading 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 unloaded.

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

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

It is assumed that the standard product quantity confirmation process (i.e. select a line or scan or enter the product ID, the select the amount loaded/unloaded) is more appropriate for loading and unloading, rather than the Product Quantity Countdown process, although this can be used for loading/unloading if required.

Each product on the list can be confirmed as unloaded by either:

long-clicking on the item in the list and choosing Unload X from the pop-up menu.
entering the product code manually and clicking Unload X from the pop-up menu.
scanning the product code and clicking Unload X from the pop-up menu.

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

The user 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.

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 driver 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 unlaoded and will be removed from the product list.

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 unloaded. 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 workload will also be complete. There will be no more work for this vehicle. The warehouse user can then re-login from the prompt, selecting the next vehicle to unload.

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 user 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 user will not be allowed to load the jobs out of sequence.

It is assumed that the standard product quantity confirmation process (i.e. select a line or scan or enter the product ID, the select the amount loaded/unloaded) is more appropriate for loading and unloading, rather than the Product Quantity Countdown process, although this can be used for loading/unloading if required.

Each product on the list can be confirmed as loaded by either:

long-clicking on the item in the list and choosing Load X from the pop-up menu.
entering the product code manually and clicking Load X from the pop-up menu.
scanning the product code and clicking Load X from the pop-up menu.

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

The user 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.

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 driver 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 loaded and will be removed from the product list.

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 user will continue loading all jobs in the same manner.

Note: Changes to quantity at loading will be reflected back into the WMS 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 user 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 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-6:

Oak Furniture Land POD/POC Format

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 removed from this table. A total line will be displayed, summing the Weight column.

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. 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 and DOOR COLOR will be removed, as it is expected that this will be made redundant through the process of Job Photos if required.

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. 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 also be configured to 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
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 - 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-7:

Custom Oak Furniture Land Portal Styling

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

SCR-344060-8:

Customer Tracking Gateway design change

Warning: Remove Following

If provided to CALIDUS Portal, this screen can also display the ETA at the location of the order being checked. Note: This functionality uses HERE maps for calculation of the ETA.

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

Gateway - Consignment Signature

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.00	²
3	EPOD	Device	Job UDF Dependent on Job Amended	2.50	²
4	EPOD	Device	Product Quantity Countdown	6.00	²
5	EPOD	Device	Lot Capture	7.50	²
6	EPOD	Reports	Oak Furniture Land POD/POC Format	4.00	²
7	PORTAL	TTM	Custom Oak Furniture Land Portal Styling	2.00	²
8	PORTAL	Gateway	Customer Tracking Gateway design changes	0.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.
These changes will be developed as part of the product improvement program internally at OBS Logistics and will be made available when complete.

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

Warning: Jason Bannister	Oak Furniture Land Representative	_____________________________
Matt Turner	OBS Logistics Representative	_____________________________

Anonymous

Search

REQ 344060 Oak Furniture Land Solution Design

Introduction

Objective

Scope and Limitations

Client Requirements

Operational Overview

Existing System Processes

Data Import

Administration

CALIDUS VEhub

C-ePOD Mobile Device Application

C-ePOD Mobile Device Login

Obtain Workload/Job List

Job Details

Cancelling a Job

Navigation and Arriving

Radial Delivery Process

Delivering a Product

Changing a Product Quantity

Cancelling a Product

Commenting a Product

Collection (Returns) Process

Job Completion

Post-Load

Trunk Unloading Process

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