Marshalls (Premier Mortars)

Marshalls Premier Mortars Solution Design

CALIDUS ePOD

25th May 2017 - 1.3
Reference: REQ 339867

Introduction

This document is the Marshalls Premier Mortars Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Marshalls (Premier Mortars), on 18/11/2016 at the Marshalls Premier Mortars office in Ramsbottom, and amended with further details from emails, before a final sign-off session in Marshalls Mono Hall Ings office on 24/05/2017.

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

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. AX and REACH) 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.
The solution in this document is predominantly for the Premier Mortars and Screed business group. It is known that there are business requirements for the other (Landscape) business units, but these have not been discussed in detail. Where known, these are included in this solution design, but may not be completed in the first phase. Subsequent design meetings may be required to gather more information of the other business units.
Modifications are required to the customer systems (AX and REACH) to achieve the functionality described in this document.
A test system must be made available as soon as possible so that the team can test the REACH interface.
It is expected that, as part of this project, a 'crib sheet' will be required, indicating the expected driver process using the CALIDUS ePOD mobile device application. It is expected that this solution design will highlight the steps required by the driver in all circumstances, and that this may then be used as the basis of this training document.
Process flows have been created for each process for the operation, indicating the system, driver and mobile application actions to be taken in each case. OBSL have provided some generic process flows that have been created for C-ePOD to aid in the creation of these flows. These flows have been used to validate this solution design.
There is an extant issue at this time with the TomTom PRO device updates - when updated, the C-ePOD and C-VEhub application are not installed on the devices. It is expected that these applications need to be added to the TomTom MDM platform by Fleet Trak. This must be raised with Fleet Trak.

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

Marshalls is the UK's leading hard landscaping manufacturer and has been supplying superior natural stone and innovative concrete products to the construction, home improvement and landscape markets since the 1890s.

The Marshalls family of companies extents to several business units:

Marshalls
Stonemarket
Marshalls Tile and Stone Interiors
Stoneshippers
Natural Stone Paving
Premier Mortars and Screed

When fully implemented across Landscape and Premier Mortars business units, there will be around 240 drivers using the application.

The first implementation of the software solution will be for Premier Mortars and Screed. The meetings with the customer have focussed mainly on this business, with some focus being on the Landscape side of the business (the other business units listed above).

Addresses:

Landscape House,
Premier Way,
Lowfields Business Park,
Elland,
West Yorkshire,
HX5 9HT

Fletcher Bank Quarries,
Fletcher Bank,
Ramsbottom,
Bury,
BL0 0DD

Marshalls,
Hall Ings,
West Ln,
Southowram
HX3 9TW

Contacts:

Simon Martin ([email protected])
Stacey Helton-Michel ([email protected])
Tracy Carney
Alison Balmforth
Deborah Rogers ([email protected])
Dave Hornsey ([email protected])
Gary Shaw ([email protected])
Debbie Linley ([email protected])

OBS Logistics Contacts:

Matt Turner - Sales/Account Manager
Warren Wright - Sales/CALIDUS VEhub
Tony Walker - CALIDUS ePOD Designer

Existing System Processes

The core systems for all parts of the business are Microsoft AX (ERP), with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal TTM).

Additionally, the Landscape business uses REACH (TMS).

The Premier system processes will be:

Orders are entered into the ERP.
ERP interfaces the orders to CALIDUS ePOD.
TomTom WEBFLEET is used for navigation to the order destination.
CALIDUS ePOD executes jobs and captures the actual delivery quantities, additional information and signatures.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.

The Landscape system processes will be:

Orders are entered into the ERP.
ERP interfaces the orders to the TMS, for Routing purposes, triggered at Order Despatch.
TMS interfaces loads and orders to TomTom WEBFLEET and CALIDUS ePOD, initially at midnight before the delivery.
TomTom WEBFLEET is used for navigation to the order destination.
CALIDUS ePOD executes jobs and captures the actual delivery quantities, additional information and signatures.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.

Note: These indicated processes above are subject to modifications of the AX and REACH products, in progress now.

Note: Orders are sent from REACH to WEBFLEET as follows:

Loading and Return to Depot jobs are interfaced as Service jobs.
Delivery jobs are sent as Delivery orders.

Return to Depot jobs are normally sent as the last job of the day.

The vehicles will be using the TomTom PRO 8xxx devices to run CALIDUS VEhub, the CALIDUS ePOD client application and the built-in TomTom navigation and WEBFLEET applications.

The operations typically plan day 1 for day 2 delivery.

A list of deliveries is created, along with a list of collections (empty tub collections and normal collections from site). Each delivery and collection has its own order in the system (Microsoft AX).

Deliveries may be AM or PM, or specifically timed. The window for AM non-timed deliveries are 0600-1200. For PM non-timed deliveries these are 1200-1800.

For Landscape, typically there is only one job per load. When a job is arrived on TomTom WEBFLEET, the next order is released. This will also trigger sending of another (different) load to C-EPOD with this job on it. The typical load is as follows

Go to Depot
Go to customer delivery point.
Go back to Depot.

Landscape trips may be staged deliveries:

Trip 1: Depot 1 to Depot 2.
Trip 2: Depot 2 to delivery drop.

Premier Mortar and Screed trips may be single- or multi-drop:

Go to Delivery drop 1
Go to Delivery drop 2
Go to Delivery drop 3
Go to Delivery drop 4
Go to Delivery drop 5

In-between the drops, the vehicle may come back to the depot. In this case, they will use the TomTom unit to manually navigate, using the Favourites menu.

Note: Premier Mortars typically require the first job of the day to be completed first, then all subsequent jobs can be completed in any sequence. With the current process, morning and afternoon deliveries are planned onto separate loads. In the future, it is possible that these may be planned onto the same load. In this case, Morning orders should be enforced to be completed before afternoon orders.

Within AX, orders will typically travel through the following statuses:

Ordered
Despatched (passed QC at Loading)

However, there are instances where problems with QC mean that the order will pass through the following statuses:

Ordered
Despatched (passed QC at Loading)
Held - Quality issues when driver checks (e.g. solidified overnight)

At this stage, the order may be move to the following statuses:

Cancelled - cancelled for this day, to be delivered at a later day under a different order, on agreement with the customer.
Despatched - new product is loaded for the customer, so that the order may be redelivered on that day. This may require agreement with the customer, if the delivery window is going to be broken.

Note: There will be no system-based link between the cancelled and replacement orders.

It is noted that, although this cancellation of orders that are no longer required for that day is part of the process, this process was not being followed immediately - instead these held orders are being cancelled on the morning of the following day or days. The interface requirements (i.e. to cancel the orders within C-ePOD for non-Landscape orders) may define a change to this process to ensure that the orders are cancelled in a timely fashion.

Loading is completed by the depots, not the drivers.

At loading for Premier, the hopper and cone readings are entered.

Hopper indicates the Hopper into which the product has been loaded on the vehicle.
The Depot Cone Reading is a test to determine whether the mortar is set.

AX will be modified to allow the loaders at the plant to enter the Hopper and Cone reading per product on the order and send through the information to C-ePOD on each product on the delivery job. The entry of the data into AX will be developed as part of this implementation.

In the current process, orders are set to Despatched status before loading. In the new process, this will be set after loading, and after the new information is entered into AX.

The new process will be:

All orders will be picked and loaded the prior day.
Physically load the product at the plant, by the loaders at the plant.
Quality check the product (cone test).
Enter Hopper and Cone Test data into AX.
Despatch in AX.
Send messages to C-ePOD (and WEBFLEET if part of the process), including the loading information, interfaced as part of the load at midnight.
Amendments to Load and Jobs will be sent through as required, when jobs are held.
For Landscape, Navigation will be completed through the orders on the WEBFLEET order workflow, and C-ePOD will be used to deliver after navigation is complete.
For Premier Mortars, C-ePOD will be used to select the orders, with the TomTom NavApp used to navigate to the addresses, then the C-ePOD delivery process used to deliver afterwards.

Note: For Landscape certainly and possibly also for Premier Mortars, the driver will take pre-printed POD sheets in case of emergency (i.e. if the TomTom PRO device should stop working).

It is determined that a change of process may be required for the operations, to ensure that Held orders are either swiftly dealt with, or they would not be able to be delivered that day. It is very exceptional that an order will be held for a long period, and still be attempted delivered on that day. Realistically, this is the standard process. Therefore, there is no necessity to try to deal with any exceptional circumstances where an order is released to be delivered on a load that has already been completed on that day.

It is agreed that the implemented interface from AX and Reach will remove orders that are at held status from the loads, and re-send the entire load.

Data Import

The transport system that currently sends messages to TomTom WEBFLEET and will in the future send messages to CALIDUS ePOD is called Reach. This system is currently used for Landscape only, and is being developed so that it can also be used directly from AX for all other business units.

The business is confident that this Reach process can be modified to ensure that jobs are sent through for all the orders under the load for the next day, all at the same time, rather than one by one, which is the standard C-ePOD processing model.

The jobs will be transferred to C-ePOD through a webservices transmission in OBS XML format. This has been provided to the customer.

Note: It is not expected that the ERP will be informed of updates of completed jobs - this is not required now or in the future.

A discussion at a technical level has taken place between AX/Reach consultants and OBS representatives to discuss the details of the interface of jobs and loads into C-ePOD. The information here reflects that, and the detailed mapping of the fields is taking place outside of this document.

The different business units operate independently. Separate Sites are required for all the different business groups, initially for Premier Mortars. As each business unit comes into the software, new sites will be added.

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, such as:

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

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

It is expected that there will need to be the following Job Group configurations:

General Deliveries, Unpriced POD.

If Job Groups are sent to CALIDUS ePOD that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration, which can then be configured to customer-specific need through the CALIDUS ePOD Admin console.

The exact confirmation of the Job Group configuration will be decided at implementation stage, but is expected to consist of:

Customer Signature
Optional Job Photo
POD format
Terms and Conditions

It is advised that the Site and the Job Group may be set from the AX Data Area ID.

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

Details for each job include:

Load ID - a unique ID for each load i.e. not a repeating Route Code.
Driver and/or Vehicle - for allocation of loads for execution.
Planned times - planned times are required for each job and for the loads. Non-timed deliveries should be passed through with 0600 - 1200 as the start and end date and time for AM deliveries, whereas PM deliveries should have 1200 - 1800 passed through as the start and end date and time. Timed deliveries should have the start planned time set to the planned arrival time.
Note: Service Level may be used to indicate "AM" or "PM" deliveries if required on the note. This is not displayed on the mobile device and can be used for reference on the POD notes if required.
Customer Code
Order (invoice) address information , linked from the Customer Code
Delivery Job Address
Customer Contact Information - including email address for final delivery jobs (not trunk jobs).
Order Number - the ERP internal unique order reference
Customer's Order Reference
Sales Person
Job Instructions - Timed deliveries are indicated through the special instructions on the orders. This will also be interfaced as the Planned Start and End time.
Sequence - All jobs will be sequenced. Timed jobs will be sequenced as first in the list, whereas non-timed jobs will all be given the same but later sequence in the list. This will then support the required functionality on the device (where the first timed jobs are all required to be completed first, whereas the non-timed jobs may then be completed later in any order.
Product Codes
Product Quantity Despatched and Unit Type.
Item Type and Mortar number if required

Note: Lat/Longs may be provided with each job that is sent to CALIDUS ePOD from the ERP. In this case, this is used to navigate to the destination address. Alternatively, the TomTom GeoCoder can be used by CALIDUS ePOD to generate these Lat/Longs when not present. It is expected that they will be provided for all Landscape jobs, and may be provided for Premier Mortars jobs.

Note: Premier Mortars typically require the first job of the day to be completed first, then all subsequent jobs can be completed in any sequence. With the current process, morning and afternoon deliveries are planned onto separate loads. In the future, it is possible that these may be planned onto the same load. In this case, Morning orders should be enforced to be completed before afternoon orders. All of this can be achieved by the sequencing of the orders on the load.

Additional information is required to be sent to C-ePOD on the delivery job (in the job detail):

Date/Time loaded.
Loading point (plant).
The loader (name).
Sales Contact Telephone.

For Premier only, additional information is required to be sent to C-ePOD on the delivery product:

Hopper.
Depot Cone Test.

This will require modification of the data stored on the Jobs in C-ePOD.

SCR-339867-1:

Additional loading data imported for the job.

Additional information is required to be sent to C-ePOD on the delivery job for Landscape jobs:

Haulier.
Transport Group.
Case Quantity for the product (i.e. quantity of units to a case).
Product References (e.g. "CEFL5656000 LSMUF560 EN1339:2003 EN1338-2003") in place of Mortar Numbers

This will require modification of the data stored on the Jobs in C-ePOD. Note that these are required for the POD format report. It is noted that these references are the same as Mortar Numbers.

SCR-339867-2:

Additional non-Premier job and product information required on Import

Note: Should any amendments be required for the jobs, or the jobs on the load, the entire load will be re-interfaced.

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

Drivers
Customers (Invoice or Order Addresses)
Vehicles
Job Groups

It should be noted however that there are additional interfaces to CALIDUS ePOD in order to keep standing data in line within the system, for example:

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

Each of these items can be agreed in advanced or administered within CALIDUS ePOD, negating the need for a developed interface. Furthermore, if drivers or vehicles are assigned to a Load on a message and are not in CALIDUS ePOD, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created for users, and the vehicle ID as the registration for vehicles.

As part of the interface mapping exercise, this standing data will be agreed, regardless of whether the interfaces above are implemented within the ERP.

Note: Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. This must be achieved by the ERP or DPS. It is confirmed that the loads will be allocated to a vehicle. It is further noted that this may require addition of REACH code to Premier.

If this cannot be done, then the CALIDUS ePOD Admin system (Load or User screens) may be used to manually allocate drivers to loads. However, it is explicitly noted that all load maintenance will be done via the ERP. This will be managed by a physical process.

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

The system supports three job types at this point which encompass the functionality to complete many more tasks with them. At this point the system can be used to complete and record: Deliveries, Collections and Services.

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

The purpose of the application can be broken down into the following sections:

To create and maintain users of the ePOD devices.
To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
To create Jobs of all types and group them together onto Loads.
To assign Loads to Users 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 confirmed that all Loads will be assigned to Vehicles through the ERP import interface.

A facility to manually assign Loads to drivers and vehicles for problem-solving purposes - this may not be disabled in the Admin application, and will be managed by process.

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

As loads will be assigned by vehicle and not driver, 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.

PDA Login

The application will have 2 customised styles created for Marshalls (or for Landscape, one for Premier Mortars), which will include:

The logo on the login page.
A defined Job List style.
Addition of a WEBFLEET toggle button to the Load Information panel.
A defined Product List style.
A change to the text of the Start Job button (for Landscape style).
Removal of the Cancel Job button on the Job Details screen (for Landscape style).
Enforced entry of Customer Signatory.

SCR-339867-3:

General Mobile Device Styling

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 this will be configured to be the TomTom WEBFLEET username and password.

Warning: Driver details are held for Landscape, and may not be for Premier - this must be checked as this is required for WEBFLEET integration.

Note: For a future phase, it is requested that the driver details are pulled from the Tacho card. This change is not part of the scope of this solution design.

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

It was noted regarding the function of the application without mobile signal, that this initial download of a load to a device is necessary for the functioning of the application. It may be that the drivers may need instructions to stop and pick up the jobs when in a coverage area.

Job List

The Job list on the mobile device is expected to be styled so that only the following items are displayed:

The Delivery Time (not the delivery date)
The Ticket number (the job code)
The location (address name)

The Load information (on the right of the screen when the device is oriented in landscape mode, and available through an Information button press when in portrait orientation) will be modified as part of the style changes to add a WEBFLEET toggle button, if WEBFLEET is enabled for the site and this is a TomTom PRO device. This will allow the user to switch to WEBFLEET, by activating the WEBFLEET NavApp only - no extra information will be sent. The purpose of this is to ease the transition between C-ePOD and WEBFLEET for the drivers.

The screen will display the status of the jobs on the load through a coloured outline, as follows:

Red - Cancelled
Green - Completed
Blue - Completed (with amendments)
Yellow - In Progress
None - Pending/Incomplete

Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed.

All Timed jobs will be shown in sequence at the top of the list.
All non-timed jobs will then be shown afterwards, sorted in Planned Time sequence.

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

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

Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
Refresh - Refresh the Load/Worklist
Settings - Show the Settings screen

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 at any time. Jobs with the same sequence (i.e. non-timed jobs) may be completed in any order, although not before any timed jobs i.e. jobs that are lower in sequence.

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. It is noted that this should not occur.

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.

Job Details
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 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 does not allow the user to contact the customer (through either text or phone) when using TomTom PRO or BRIDGE devices, as they do not allow telephony. Other devices will allow this and, in this case, the application will display appropriate icons to allow the drivers to accomplish this.

Cancelling a Job

For Premier Mortars, 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.

For Landscape, this is not the normal process - it is expected that the C-ePOD application will be set up so that the Cancel Job functionality is disabled, through removal of the Cancel Job button (as part of the styling changes on the device) and having no Job-level reason codes configured within the system. In this case, it is expected that the jobs will be cancelled through AX and then passed through to C-ePOD, and removed from the mobile device when the update is received.

Navigation and Arriving

The driver process states that the driver is to check the quality of the product before the vehicle departs. This is typically completed, but the readings are not recorded. It is noted that this can at that point indicate a problem with the product, which then would need to be dealt with before despatch. This process is covered later.

The screen will show a Navigation icon, which can be clicked to start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp, which can be linked to WEBFLEET.

Landscape Process

For Landscape, which will have the orders sent to WEBFLEET, the driver will use the TomTom WEBFLEET list of orders to navigate to the job. In most instances, only one order will be ion the device at one time.

It is expected that the TomTom WEBFLEET order workflow will consist of:

Started
Arrived
Finished.

It is possible that the Finished step may be removed. It may however be required for reporting purposes. This does not affect the C-ePOD process specified in this document.

The WEBFLEET Order Workflow functions within the WEBFLEET NavApp will be used to complete this.

Once arrived at the destination, the driver will switch to the CALIDUS ePOD mobile application. This can be through the 'All apps' icon on the home screen or (expected to be) through a configured short-cut on the task bar. The driver will then indicate arrival and start processing the Job by clicking the Deliver Job button (a style change for the Start Job button for Landscape).

Note: Delivery instructions are provided from several sources (specific instructions against the job and/or standing instructions for the customer e.g. advising ETA or customer details). These instructions should be concatenated in the ERP and sent in the Instructions shown above. 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 delivering.

Note: It is known that the navigation through the Post Code is not accurate enough in some cases, and the TomTom WEBFLEET location has Lat/Longs updated to the correct location. This is indicated through a template in the WEBFLEET app on the device, (Incorrect Address).

Note: If the WEBFLEET orders are not present, the C-ePOD app has a facility to send the address directly to the TomTom NavApp instead, to navigate directly to the provided address.

Premier Mortars Process

For Premier, which will not have the orders sent to WEBFLEET, the TomTom NavApp will be sent the address by the C-ePOD app, and will commence immediate navigation to the address.

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

Note: Delivery instructions are provided from several sources (specific instructions against the job and/or standing instructions for the customer e.g. advising ETA or customer details). These instructions should be concatenated in the ERP and sent in the Instructions shown above. 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 Landscape or Premier Mortars jobs. 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 (through configuration. Note that the application can if desired be configured to only issue a warning in this case, rather than prevent it outright. It is expected that doing jobs out of sequence will not be allowed for Landscape or Premier Mortars jobs.

It is to be noted that, if jobs are passed through to the CALIDUS ePOD from the ERP that do not have sequences at all, these will appear at the bottom of the list, but may be completed before or after any jobs, including timed jobs. It is expected, however, that all timed jobs will have a unique sequence, whereas all non-timed jobs will have the same sequence, but higher in value. This will ensure that the non-timed jobs can be completed in any order, but not before the timed jobs.

Once started, the device will display a navigation button. Clicking this will commence immediate navigation to the address - the TomTom NavApp will be shown, which will immediately calculate a route to the destination address.

The Lat/Longs on the job (if present) will be used for navigation, otherwise the address will be evaluated at that time and used for navigation.

Once arrived at the destination, the driver will switch to the CALIDUS ePOD mobile application. This can be through the 'All apps' icon on the home screen or (expected to be) through a configured short-cut on the task bar.

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

Common Process

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.

Delivery Process

The driver process at a delivery point is:

Arrive at site (recording time of arrival).
For Premier only, take cone readings from the hopper for each delivered product (recorded).
Confirm delivery of product.
Complete delivery (recording time off site)

Deliveries will initially 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

From the Products tab, the device will show a list of the products to be delivered, which can show:

The Product Code
The Sequence
The full Description
Any Customer Reference associated to this product
The Planned Quantity
The Item Type
The Unit Type

As an optional change, the layout of this table may be modified (i.e. elements removed, or resized), as part of the Customer Styling change shown above. The data displayed is dependent on the information passed to CALIDUS ePOD from ERP. It is expected to be:

The Product Code
The full Description
Any Customer Reference associated to this product
The Planned Quantity

Note: The quantity on the device must take into account the pack size. This change is specified in more detail when changing quantity against a product.

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
Product Info Pop-up

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

When all containers and 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.

If this is a Landscape job, it is required that the number of pallets unloaded is entered here. To accommodate this process, the delivery processing screen on the C-ePOD mobile device application will be configured to request the required entry of a quantity, labelled as "Pallets Unloaded". This process configuration will only be created for non-Premier Mortars jobs.

Job Details Tab with Pallets Unloaded configured

This Pallets Unloaded field will require the entry of quantity before the job can be completed and signatures obtained. The driver will be forced to enter a quantity, even if that quantity is zero.

There is a scenario where the drivers arrive at site and there are no tubs ordered for the material. It is expected that this will be noted by the driver using the Notes tab, as an indication to the order management team that some additional cost may need to be added to the invoice for the order, or as a reason as to why the order could not be delivered (in full). This information can be easily reported from the existing extract from the C-ePOD Admin Jobs screen, the process of which is shown later in this document.

When the driver has confirmed that everything is complete and clicked the Complete button, this screen will close and the user will be directed to the Job Completion process.

Delivering a Product

The driver process for delivering product is:

Take cone readings from the hopper for mortar product.
Confirm delivery of the product, recording the cone test result.

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

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

Mortar items will be configured to require a cone test entry by the driver at this time.

Site Cone Test Results Entry

A physical Cone test is a metal cone dropped into the mortar from several feet. The distance into the mortar that the cone penetrates is then measured in cm by being read from markings on the side of the cone.

It is also possible to enter this information manually by long-clicking on the item in the list. This may be used to capture the cone test result before cancelling the product delivery.

The Cone test result will be selected from a drop-down list. The result must be selected in order to successfully deliver the product. The acceptable values (provided on the device through a drop-down list) are:

12 or below
13
14
15
16
17
18 or above

Note: Site cone test results are only entered and required entry against Mortar products, not others. For example, Screed, Tubs and Liners do not require entry of these fields. This will require change to the configuration to ensure that these are only entered/produced against certain product lines (i.e. Mortar lines only). It is noted that the mobile device can at this time only be configured for entry of cone test on all products or none. In order to achieve the above, the Product configuration must be changed to allow configuration at product type.

SCR-339867-4:

Product UDF by Product Type

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

Changing a Product Quantity

Image (Photo) capture may be required by the operation at multiple stages, for example, when the driver gets to the site, not enough tubs have been left for the driver to deliver the quantity of mortar. At an unmanned site, this means that the delivery may be short. Photo capture against the product being delivered would be required on change of quantity in this case.

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.

Regardless, any configured cone test readings must be entered for Mortar products.

Note: The quantity on the device must take into account the pack size. Therefore:

If the system is configured to do so, and the pack size is to a value greater than 1, then the quantity will be displayed and entered as 2 quantities: Pack and Unit. The Pack value will be populated by the quantity integer divided by the pack size. The units will be the remainder of this calculation.

SCR-339867-5:

Product Quantity to use Pack Size

This change affects the display of the Product List and all changes made to Product Quantity.

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.

Regardless, any configured cone test readings must be entered for Mortar products.

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

Collection (Returns) Process

It is expected that, where planned collections of tubs are created, these collections will be interfaced to as Collection jobs. The tubs to be collected may be interfaced as products to be collected, or the mechanism above or requiring the driver to enter the number of tubs collected from the site will be used.

In either case, it should be noted that the collection process will be almost identical to that described above, substituting Collection instead of Delivery.

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.

Note: At this time, the expectation is that the configuration will require only the Customer to sign for collection and delivery of goods. It is an optional configuration for CALIDUS ePOD, where driver signatures can be enabled or disabled for collections or deliveries, and whether the device will prompt for Job Photos after signature.

The device will prompt for Customer Signature.

Customer Signature and T&Cs
Customer Signature and Products
Driver Signature

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. These are configurable.
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:

"In accordance with Marshalls Terms & Conditions, available upon request or via our website www.marshalls.co.uk/tandc"

Note: The Marshalls team are reviewing the T&C requirements at this time, and these may change.

Unmanned locations or delivery out of hours may require that the driver sign PP for the customer, then taking photos to indicate the successful delivery. In the current system without change, this is expected that the driver would sign on behalf of the customer in the customer signature, then have an optional job photo process prompted after this.

Note: For Landscape, it is expected that the Job Photo will always be required for every job.

It is requested that the mobile application is changed to account for this unmanned location process. It is expected that some kind of prompt or button press will be requested of the driver at Customer Signature stage (or before) to indicate whether a customer signature can be obtained. If a customer signature cannot be obtained, the device will be expected to require entry of driver signature and then enforce taking of at least one job photo to prove delivery.

SCR-339867-6:

Unmanned Location Signature Process

If driver signature is required, this displays very similarly to the customer signature above, with some differences:

Only T&Cs if configured will be shown on the tabs.
The driver name will be pre-set from the logged-on driver and cannot be changed.

If driver signature is prompted for, it must be entered and cannot be skipped.

The process will prompt for photos after completion of the signatures for Deliveries.

For Landscape, Job Photos will not be compulsory, but instead set as optional, unless a customer signature could not be taken (as per the Unmanned Location process above).

For Premier Mortars, the Job Photos will always be compulsory.

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

Job Photo (showing optional 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 an internet connection, and may be delayed until that time.

The user will be returned to the Job List screen and the completed Job will be removed from the list. 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 or log off the system.

For Landscape, if another job has been assigned to the vehicle, this will have been created as another load. If one is available, it will be downloaded at that point.

For Premier Mortars, if there are jobs for afternoon delivery, these may be planned onto another load for that vehicle, and will be picked up at this point.

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. Note: It is confirmed that photos taken with a job will not be added to the POD at any time (i.e. not for viewing, emailing or sending the report to OnBase).

These completion documents should show despatched and delivered quantity and should show all product lines on the order, whether they are cancelled or not.

Note: There are two POD/POC formats:

One for Premier Mortars.
One for all other business units.

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.

Note:

The original format contains a barcode for manual uploading of PODs into OnBase, when the documents are scanned. As the documents will no longer be scanned but electronically uploaded by C-ePOD, it is not expected that this is required. However, for manual backup (in the case where the interface between C-ePOD and OnBase is not working) it may be the case that this barcode stays. It has subsequently been agreed that this barcode will be removed.
The original Premier Mortars format allowed for Comments to be seen from the driver. It has been agreed that this will be modified to remove the 'Comments' label and driver comments from the format - it is not required on an electronic POD format.

Premier Mortars 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 Premier Mortars POD Format

SCR-339867-7:

MPMS POD/POC Format

Note: This format is being changed and is subject to definition by Marshalls.

Note: There will certainly be less than 10 products to a job, most commonly a maximum of 6, ensuring that there will only be a single page for this report.

Note: The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into . As part of Import changes specified above, additional data will be received against the jobs so that it can be placed on the POD note.

Page Header, expected to be displayed on every page:

CE Logo - fixed
"DELIVERY NOTE" - fixed text, displaying "COLLECTION NOTE" if the job is a collection.
Logo - It is expected that this will be the logo taken from the Job Group. If not present, this will default to the logo from the site.
Depot Address - Taken from a customer record linked to the site.
"Customer Name" - the customer name.
"Account Number" - the customer code.
"Deliver To" - the job address if present, otherwise the customer address. Including the contact name and telephone.
"Sales Order" - the Marshalls order number, in Job Code.
"Trip" - the Load ID
"Loading Point" - from the new import data.
"Vehicle Reg" - the vehicle that completed the trip.
"Date" - the actual end date
"Sales Contact" - the contact that took the order.
"Telephone" - the phone number of the sales contact.
"Cust Ref" - the customer's reference.
"Special Instructions" - any special instructions provided.
"Mortar: EN998-2..." - fixed text.

Product Details, expected to be shown on every page, expected to show up to 12 products per page:

"Item" - The product code.
"Description" - The product description.
"Qty Despatched" - The planned quantity of the product being delivered.
"Qty Delivered" - The actual quantity of the product delivered, as confirmed by the driver.
(Blank Column) - the unit type
"Hopper" - the hopper for the product, entered in AX and sent to C-ePOD in a new field.
"Depot" - the depot cone test for the product, entered in AX and sent to C-ePOD in a new field.
"Site" - the site cone test for the product, entered by the driver.

Footer, expected to be shown on all pages:

"Driver Signature for Out of Hours" - based on the new Unmanned Location process. If the driver signature is present, it will be displayed here.
"Customer Name" - the entered customer signatory
"Signature" - the customer signature if present.
"Date Loaded:" - from the new data received on the job
"Time Loaded:" - from the new data received on the job
"Delivery Date:" - the actual planned date
"Delivery Time:" - Either the planned time or "AM"/"PM", if sent in the service level.
"Time on Site:" - the start time of the job in C-ePOD
"Time Off Site:" - the end time of the job in C-ePOD
"Waiting Time:" - the start time minus the end time in minutes.
All other footer text - fixed text

Warning: Notes:

The bottom right-hand corner contains come kind of reference, which is illegible on the photocopy presented. Is this required on the electronic POD and, if so, what is this value? It has been noted that this is part of the pre-printed stationary. This will be confirmed. It is unlikely that this will cause an issue to the report format.
It is expected that the POC format would be similar to the POD format (usually replacing "Deliver" with "Collect" and other similar words). Is this acceptable or are there other changes that would be required?
Re: Tubs Collected: This should be added to the POD note.
The CE Mark is present on the header - should this be moved to the footer, similar to the Marshalls format? To be confirmed.
It has been confirmed that the actual CE reference for "Mortar: EN998-2..." is a fixed text value, and not part of the data received for the items or the job. As such, the prototype will be changed to reflect this. This has been reflected above.
If there is a reason code assigned to the product, the reason for the change or cancellation will be provided as a second line under the product description.
The Quantity Despatched and Delivered will be added to the product details.

Marshalls 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 Marshalls Generic POD Format

SCR-339867-8:

Marshalls Generic 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 . As part of Import changes specified above, additional data will be received against the jobs so that it can be placed on the POD note.

Page Header, expected to be displayed on every page:

Logo - It is expected that this will be the logo taken from the Job Group. If not present, this will default to the logo from the site.
"Sales Order No:" - the Marshalls order number, in Job Code.
"Journey No / Drop No:" - the Load ID and Sequence
"DELIVERY NOTE" - fixed text, displaying "COLLECTION NOTE" if the job is a collection.
"RECEIPT NOTE TO BE RETURNED TO" - Taken from a customer record linked to the site.
"CUSTOMER" - the customer (invoice) address. Including the telephone.
"DELIVERY ADDRESS" - the job address if present, otherwise the customer address. Including the telephone.
"Journey No / Drop:" - the Load ID and Sequence
"Order Number" - the Marshalls order number, in Job Code.
"Del Date" - the actual end date
"Del Time" - the actual end time
"Customer Req" - the customer's reference.
"Customer Account" - the customer code.
"Haulier" - from the new data received on the job
"Registration" - the vehicle that completed the trip.
"Transport Group" - from the new data received on the job
"Driver's Helpline" - fixed text

Initial header, displayed on the first page only:

Any special instructions provided.

Product Details, expected to be shown on every page, expected to show up to 16 products per page:

"Pick Code" - the product code
"Quantity" - the actual delivered quantity
(Blank Column) - the unit type
"Pack Size" - the case quantity
"Item" - the item description, plus the long description
"Total Packs" - the delivered quantity integer divided by the case quantity
"Loose Items" - the remainder of the delivered quantity from the above calculation (the delivered quantity mod by the case quantity)
"Tonnes" - the delivered quantity multiplied by the unit weight.

A total line will be produced, showing the totals of:

"Total Packs"
"Loose Items"
"Tonnes"

Footer, expected to be shown on the last page only:

"I have received the materials listed" - either fixed text or T&C text.
"Print Name" - customer signatory as entered by the driver.
"Vehicle Reg" - the vehicle that completed the load.
"Number of Pallets Unloaded" - as entered by the driver.
"Signature" - the customer signature.
"Delivery Date:" - the actual delivery date
CE Logo - fixed
All other footer text - fixed text

Data Export

When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems. This is also true of cancelled jobs. All completed and cancelled Jobs may be transferred to the ERP through the standard interface. This is a pushed update, sent at a configurable interval, usually every 5 minutes.

At this time, there is no plan to take any of the updates from C-ePOD into AX - it is determined that the Portal and C-ePOD Admin consoles will provide enough information for the order management team to determine whether there were amendments that needed to be dealt with on a particular day. There is some intention to update orders to indicate if there has been an issue (driver comments or some cancelled or changed quantity on products). It is the intention that this may change the status to Held, although this must be considered in line with the functionality to take the orders to held status to indicate an issue before delivery, as opposed to the order being held after delivery. In the future there may be the need to take more updates into AX, but this is not part of this solution at this time.

Completed jobs with an email specified on the address will be picked up by a timed process and the POD will be automatically sent to that email address. The POD will be in PDF format. The email address will be provided to C-ePOD only on final delivery jobs from the customer record.

POD documents will not be emailed to customers if the delivery was cancelled, only if the delivery is marked as complete. Even if a delivery is marked as complete with all products not delivered, the POD note would be sent.

Note: This feature requires access to a mail server for the use of the customer.

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

Email subject and content may be configured:

Customer Name
A/C Number
Order Reference, one of:
- Job ID - ePOD internal unique job reference
- Job Code - as mapped from ERP
- Cust Ref - as mapped from ERP
- SO Ref - as mapped from ERP
- Ext Ref - as mapped from ERP
Date
Job Type (Delivery or Collection)

It has been agreed with customer to add a facility to choose by configuration not to auto-email a POD to a customer if there are any discrepancies on the order, including user notes.

SCR-339867-9:

Do not automatically email amended orders

The system will be modified to:

Allow configuration to state whether jobs with User Notes are seen as amended jobs, and whether amended jobs should be emailed.
Export only those jobs seen as complete without amendments.

Note: The jobs with amendments will then never be automatically emailed and the POD email will then need to be sent manually from the CALIDUS ePOD Admin console by finding the amended jobs, running the report, entering the email and emailing from this report.

It is also possible to configure the system to send a copy of the POD/POC note at completion of the jobs, for the purposes of updating a Document Management System (DMS). The POD/POC can be sent in image or PDF format, to multiple destinations, by flat file transfer. The POD/POC file can be named with several items to aid identification of which order/job the POD/POC belongs.

The system will be configured to send the POD in PDF format to the OnBase Document Management System (DMS). This will be through an FTP send to a designated server, with a designated user and password to be provided for this. No other information will be sent to OnBase. It is requested that this file is named with at least the Marshalls Order Reference in it (the job code). This is possible with the existing configuration without modifications.

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.

There is a scenario where the drivers arrive at site and there are no tubs ordered for the material. It is expected that this will be noted by the driver using the Notes tab, as an indication to the order management team that some additional cost may need to be added to the invoice for the order, or as a reason as to why the order could not be delivered (in full). This information can be easily reported from the existing extract from the C-ePOD Admin Jobs screen, as well as reporting on any job that has an amendment.

In the system as-is, to find jobs with user notes:

Select all jobs for a particular day
Click Create Excel Spreadsheet.
Open the file produced and filter on the EPL_USER_NOTES column.

To find all jobs with amendments:

Select all jobs for a particular day with status "Complete with Amendments".
Click Find or Create Excel Spreadsheet

As part of the change to only email POD jobs without amendments, the system will have marked the jobs as Amended if there are any user notes. Therefore the second process of finding all jobs with amendments will also find those with user notes.

Additionally, this information may be taken from the CALIDUS Portal system, as seen in the Track and Trace section below.

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
Contracts/Owners
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.

Due to the nature of the orders on the trips being predominantly un-sequenced, this then requires a change to the interface to CALIDUS Portal from CALIDUS ePOD. This change will generate an expected drop sequence of the orders on the trip, to maintain consistency of data in Portal.

SCR-339867-10:

Ensure that Drop numbers are created and stored on the jobs, for use by TTM.

Delivery windows are important to all aspects of the Marshalls business - early delivery is seen to be equally non-compliant as a late delivery. It is noted that the product development of Delivery Windows will be added to C-ePOD and C-Portal at a later date and, when complete, will be made available to Marshalls through an update to the products. As such, this change is a dependency of this project.

SCR-339867-11:

Add Delivery Windows and use these if provided when displaying Success or Failure within CALIDUS Portal TTM screens.

The functionality of CALIDUS Portal was not explicitly discussed in the requirements meeting. However, there is at this time no expectation that this would have to change in any way.

It is expected that ETAs will be shown on the Portal - this functionality requires the purchase of a Nokia Maps account. If the system is hosted through OBS, this cost may be part of a hosting agreement.

It may be that Marshalls would want to provide a service to their customers to allow them to see the progress or ETA of their delivery through the Marshalls website (currently being built). In this case, Portal may provide a link to a simplified page with details of the delivery, if postcode and delivery reference are provided. If this is required, details may be provided at that time. This is not expected to be part of this project, however.

The following is a brief description of functionality available within CALIDUS Portal.

Trip/Order Enquiry

This screen allows CALIDUS Portal users to track the status and events held against trips and orders, selecting them through a large variety of parameters.

Order Enquiry

Order Enquiry Parameters

Note: A requirement of the customer is to be able to identify the jobs (collection and delivery) that have exceptions (i.e. were not collected/delivered in full). This selection screen allows the user to define the orders to be reported, entering date/time from/to, and selecting delivery exceptions only.

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.

Delivery windows are important to all aspects of the Marshalls business - early delivery is seen to be equally non-compliant as a late delivery. It is noted that the product development of Delivery Windows will be added to C-ePOD and C-Portal at a later date and, when complete, will be made available to Marshalls through an update to the products. As such, this change is a dependency of this project.

Until that time, 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

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	EPOD	Integration	Additional loading data imported for the job.	5.00	¹
2	EPOD	Integration	Additional non-Premier job and product information required on Import	6.00	²
3	EPOD	Device	General Mobile Device Styling	2.00	¹
4	EPOD	Device	Product UDF by Product Type	6.00	^1,3
5	EPOD	Device	Product Quantity to use Pack Size	5.00	¹
6	EPOD	Device	Unmanned Location Signature Process	7.00	¹
7	EPOD	Reports	MPMS POD/POC Format	4.00	¹
8	EPOD	Reports	Marshalls Generic POD/POC Format	4.00	²
9	EPOD	Integration	Do not automatically email amended orders	5.00	¹
10	EPOD	Integration	Ensure that Drop numbers are created and stored on the jobs, for use by TTM.	7.00	^1,3
11	PORTAL	Track & Trace	Add Delivery Windows and use these if provided when displaying Success or Failure within CALIDUS Portal TTM screens.	20.00	⁴

Notes:

Phase 1 delivery
Phase 2 delivery
Product change
Being developed under another project and will be made available when complete.
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.
All changes apart from 5, 10 and 11 above will be charged at additional cost, minus the 15 days' development included in the contract

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	4.0	16/10/2014
3	FS 291096 Interface with CALIDUS ePOD	1.0	05/02/2015
4	Portal User Guide - TTM	6.9.20	26/09/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

Simon Martin	Marshalls Representative	_____________________________
Matt Turner	OBS Logistics Representative	_____________________________

Anonymous

Search

REQ 339867 Marshalls Premier Mortars Solution Design