Latest revision as of 12:04, 29 November 2019

Elliott Baxter and Co

EBB Paper Solution Design

CALIDUS ePOD

1st August 2017 - 2.0
Reference: REQ 343463

Introduction

This document is the EBB Paper Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Elliott Baxter and Co, on 08/06/2017 at the EBB Paper office in Farnborough, and amended with further details from emails of additional details and clarifications from the customer.

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

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. TMS and ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.
The original solution from the sales process was to include CALIDUS TMS and WMS products. At this time, the customer is not ready to replace TMS. However, the customer believes that immediate benefits can be derived from C-ePOD, C-VEhub and TTM without C-TMS or C-WMS. The solution outlined in this document covers this, without implementing C-TMS or C-WMS.
This solution originally included completion of Trunking movements through EPOD. It has now been established that the information required to determine how to create these Trunking loads from the manifests provided does not exist. Therefore execution of trunk movements has been agreed to be removed from the scope of this solution.
Trailer swapping is performed by EBB, predominantly for trunking movements. More detail on this process is required, but at this time it is expected that this will not be part of the C-ePOD execution and will be handled manually.
Lot control was discussed and parked - it is out of scope of this solution design. However, it is noted that the expected requirements for this process would be:
- Obtain the Lot number(s) from a different view from GP
- Store against the product as a reference
- Display on the driver's device when delivering product.

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

Elliott Baxter is the leading family owned Independent Paper Supplier in the UK. Formed in 1922, the company is now into its fourth generation of Elliott ownership and management.

Sales for last year were £138 million delivering a total of 177,000 tonnes. For comparison purposes, in 1980 sales were £4 million with 4800 tonnes of paper delivered.

EBB Paper express delivery service is supported by a fleet of 90 delivery vehicles, which travel an average of 30,000 miles a year. The Company makes over 1,500 deliveries per day, many of which are delivered same-day.

EBB Paper stocks over 21,000 tonnes of paper. At current prices, the stock value is approximately £17 million.

Main Office Address:

Farnborough Sales Office
Elliott Baxter and Co. Ltd.
Nexus Park
Lysons Avenue
Farnborough
Hampshire GU12 5QE
Tel: 01252 379900
Fax: 01252 379911

There are 9 distribution sites/sales offices:

Birmingham
Bristol
Farnborough
Glasgow
Hemel Hempstead
Manchester
Newcastle
Sheffield
Thurrock

Contacts:

Paul Griffiths - IT Director - [email protected]
Rebecca Elliott - Project Sponsor - [email protected]
Terry Dixon

OBS Logistics Contacts:

Matt Tipping - 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 externally-provided ERP (GP) and TMS (MSA), with OBS Logistics' systems as follows:

CALIDUS ePOD - execution.
CALIDUS VEhub - vehicle checks.
CALIDUS Portal TTM - tracking.
TomTom - navigation.

Note: The original solution from the sales process was to include CALIDUS TMS and WMS products. At this time, the customer is not ready to replace TMS. However, the customer believes that immediate benefits can be derived from C-ePOD, C-VEhub and TTM without C-TMS or C-WMS.

The operational processes will be:

Orders are entered into the ERP.
ERP interfaces the orders to TMS.
When orders are manifested, this creates an XML file with basic order and trip details.
A bespoke interface in CALIDUS ePOD will pick up the XML file and process this, retrieving additional details of the product lines and the addresses from the ERP.
CALIDUS ePOD executes jobs and captures the actual delivery quantities, additional information and signatures.
TomTom Nav is used for navigation to the destination.
CALIDUS ePOD updates CALIDUS Portal's Track and Trace module (TTM) with information for order tracking.

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 applications. The TomTom devices are expected to be ordered from Fleet Trak after the completion of the requirements session.

The customer is providing the SIM cards, with Fleet Trak used to commission and install the devices.

All application software will be downloaded through the TomTom MDM (Mobile Device Management) platform.

Note: It is recommended that the steps to commission the devices are as follows:

Order the SIM cards.
Order the devices.
Fleet Trak to install the SIM cards in the devices and pre-load the applications.

The software will be rolled out as follows:

CALIDUS VEhub - All depots
CALIDUS ePOD - Farnborough
CALIDUS ePOD - Other depots
CALIDUS TTM

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

The operation will expect to execute the following movement types:

Radial Delivery
Desk Collect

Note: Trunk movements of products will not at this time be executed through C-ePOD.

Android tablets will be used to complete the customer (desk) collections through C-ePOD. These will be defined as a separate job group for configuration purposes. These will be performed through C-ePOD running on basic android devices, probably tablet, possibly Wi-Fi only.

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". Note: The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.

There are also supplier direct to customer deliveries. As these are not executed through the EBB network, they will not be interfaced to C-ePOD.

A list of branches and their details has been provided by the customer.

Roughly 30 new delivery addresses are created each day.

A list of email addresses for the branches is required.

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

Depots
Drivers, including passwords/PINs
Vehicles, including Registration, Make and Model
Trailers

Lot-controlled items are delivered in this operation. This is not a go-live requirements for the implementation. However, it is noted that the expected requirements for this process would be:

Obtain the Lot number(s) from a different view from GP
Store against the product as a reference
Display on the driver's device when delivering product.

Data Import

OBS Logistics have been requested to write the interface in order to speed up the delivery of the project.

SCR-343463-1:

Bespoke Import Interface

The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.

Note: The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This quite frequently on radial deliveries.

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.

Note: The C-ePOD system will be hosted by OBS, whilst the ERP is hosted by the customer. This interface will need to connect to this ERP to access the view to get the job details. There is a technical requirement to have the two servers connected, which will require action by OBS technical services and the customer in collaboration.

A scheduled import process will be created on the system, running at a timed interval.

There will be multiple manifests sent for the same vehicle on the same day. These must be combined into a single manifest on C-ePOD. Note: In order for the interface to successfully combine manifests, it is assumed that there will be one load required per vehicle per depot (Site) per day.

Note: Manifests (that create Loads in C-ePOD) will be allocated to a vehicle and/or driver. This allows the loads to be created and allocated to a driver for completion. Note however that, once created, the CALIDUS ePOD Admin system (Load or User screens) may be used to change allocation of vehicles and drivers on a load.

The interface will create loads, one per vehicle per depot (Site) per day.

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.

When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

For example:

"DAVID EASTMAN" will become "DEAST001"
"SMITH JOHN" will become "SJOHN001"
"DEREK MAY" will become "DMAY001"
"TRUNKER M25". TRUNKER M25 will become "TM25001"

Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:

"DIANE EASTMAN" will become "DEAST002"
"SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

It is noted that EBB will tidy up the list of drivers before the implementation

Sites will be created for each depot, following the encoding within the customer systems:

GP Site ID	GP ADI Site ID	Fleet name
03 CHARLTO	903 ADI	Thurrock
04 FARNBOR	904 ADI	Farnborough
05 WATFORD	905 ADI	Watford
09 YEOVIL	909 ADI	BRISTOL
10 BIRMING	910 ADI	Birmingham
11 MANCHES	911 ADI	Manchester
12 SHEFFIE	912 ADI	Sheffield
13 NEWCAST	913 ADI	Newcastle
14 GLASGOW	914 ADI	Glasgow
31 FELIXST	931 ADI	Felixstowe
32 MAREXPO	932 ADI	Marexport

Note: The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).

The owner is considered the Sales Territory (column SALSTERR in the MSA view)
The executing depot is the depot property on the manifest tag in the XML file.

It is noted that the following will be Owners only and will not be operators:

08 PRINTMT
20 EBBOFFI
30 GLOSSOP

The following columns are also noted from the MSA view:

DefaultSiteID - the final delivery depot
Originating Depot - the depot from which the product is sourced. Note: The Depot attribute of the order tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).

The manifest on which a job is received will be stored against the job in C-ePOD, as well as any of the other customer references. This will be used by the interface to determine if the manifest has been received before. If this is the case, and the manifest has been modified (i.e. orders or products removed or added), this will be used by the system to determine whether jobs are to be added to the created load for this vehicle and day, or whether the jobs will be removed (deleted). Products not on the jobs updated will be removed, and new products added.

The jobs will be placed on the Load in the order in which they are received in the manifest file. If a further manifest is received for this vehicle, the jobs will be added to the end of the manifest. A hard sequence will be generated for the jobs on the manifest.

In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.

The interface will consolidate jobs together if:

The manifest on which the job is received is determined to be on the same Load as other jobs.
The job has the same customer and delivery address as another job on the load.
The other jobs are not completed or cancelled.
They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.

Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:

INV - Delivery order
CAL - Call-off. Considered to be the same as an INV order.
RTN - Collection from customer.

Note: Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.

Note: Any manifests marked as TRUNK (in the trailer attribute of the TMS XML file) will also not be processed.

Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.

When receiving jobs through the interface, the invoice (customer) address will be updated, if this has changed. EBB Paper have confirmed that the Invoice address changing is as expected. It has been confirmed that any previous jobs with this invoice (customer) address will from that point show the new invoice address, and this is acceptable to EBB Paper.

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:

A non-timed delivery will have a cut off of 14:00
Timed Delivery

Note: Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.

The start and end planned dates and times will be populated from the values in the following MSA view columns:

Start Planned Date - ReqShipDate
Start Planned Time - StartTime if populated, else 0600
End Planned Date - ReqShipDate
End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.

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 need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:

Radial Collection/Delivery
- Customer Signature
- Unmanned Location Signature enabled
- Deliver All functionality enabled
Desk Collect
- Customer Signature
- Unmanned Location Signature will not be enabled
- Deliver All functionality enabled

For all jobs groups, it is expected that the following will also be configured:

No Job Photo
EBB Paper POD format
Terms and Conditions is expected to be set to:
- Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:

Product Code
Product Description - stored as a truncated value
FSC number (optional) - stored with the full product description in the long description field.
Pack Size
UOM
Weight
Quantity

The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).

The following is a list of the UOFMs known at this time and the proposals to handle them:

1 - always 1 - accepted as such, but rounded up if decimal.
1000 - quantity will be multiplied by 1000.
BOTTLE - always integer value - accepted as such, but rounded up if decimal.
BOX - always integer value - accepted as such, but rounded up if decimal.
CHARGE - Excluded - this is a delivery charge. No line will be created.
EACH - always integer value - accepted as such, but rounded up if decimal.
ENVS - Envelopes. Quantity will be multiplied by 1000.
MISC - always integer value - accepted as such, but rounded up if decimal.
ROLL - always integer value - accepted as such, but rounded up if decimal.
SETS -Multi-part paper. Quantity will be multiplied by 1000.
SHEETS - quantity will be multiplied by 1000
TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
METRES SQUARED - quantity will be multiplied by 1000.
LINEAR METRES - quantity will be multiplied by 1000.

There are then essentially 4 rules:

RULE	UOMS
Multiply by 1000	1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
Round up to nearest integer value	1, BOTTLE, BOX, EACH, MISC, ROLL
Exclude	CHARGE
Multiply by 1000 and change to KGS	TONNE

Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

Note that the above method has been confirmed by the customer.

This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. Note: This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).

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 drop-offs (deliveries).

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

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.

Additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. The C-ePOD Admin Job screen may be used to add a job to a load, or to create a new job, then assign it to a load.

It is recommended that, in this particular example, product lines of code "PALLETS" are added to the collection job, with a zero quantity. The C-ePOD device can then be used to prompt the driver to enter how many pallets have been picked up. This will then be reflected on CALIDUS Portal TTM showing as Planned 0, collected 4. Note: If the product lines not entered, this will not affect C-PORTAL or C-ePOD functionality - C-ePOD will still execute the job and C-PORTAL will still show the job being completed, just without products and quantities.

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 EBB Paper use and is ready to be used. It is likely that this will be rolled out to all depots as soon as possible. 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 EBB Paper network for all users that require it.

The drivers will be provided a user-name and password (expected to be a PIN number). The users and their passwords must be configured within C-VEhub. It is expected that the user name and password will be configured to be the TomTom WEBFLEET user name and PIN.

It is noted that VEhub is likely to be used by Agency drivers as well. In this case, the system may be configured with multiple generic agency drivers (e.g. "AGENCY 1", "AGENCY 2", etc) and these used by the drivers themselves.

In this case, it is recommended that the defect check template used by the Agency drivers request the entry of the agency driver's name as part of the additional defect checks, to ensure that the name of the driver completing the checks is always captured.

Note: It is not possible to allow multiple drivers (agency or not) to access the VEhub system with the same ID. This will invalidate the session for the driver initially logged on to the VEhub mobile device application.

C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot. It is noted that the customer's email system is powered by a Microsoft Exchange server, not Office 365.

It is noted the Vehicle Checks table (and all other tables in this system) will be modified for improved searching.

SCR-343463-2:

Improved searching on tables

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 trips executed by the depots:

Radial Deliveries and customer collections
Desk Collections

The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other trip 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 EBB Paper, which will include:

The logo on the login page.
Numeric password entry at Login
A defined Job List style.
A defined Product List style.
Removal of the Has this Delivery been checked check box on the Job Details screen.

SCR-343463-3:

General Mobile Device Styling

Log In

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

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: There will be agency drivers who use the C-ePOD software. There will be multiple agency drivers, but the actual driver who completes the task may not be known until they turn up (due to late replacements). Therefore, there will be multiple general Agency drivers configured in the customer's TMS e.g.

Agency 1
Agency 2
etc.

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 EBB Paper 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

Note: The Load must be downloaded to the device through a data (3G or Wifi) connection. After this, the device can work off-line. However, if there are updates to the drivers load whilst out in the field, the updates will not been seen by the driver until a data connection is made.

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 (no time)
The post code from the location

If the jobs have been consolidated together for one location (for example, all Loading jobs at the depot may be consolidated together for loading as one job), these will appear as 1 row on this job list, showing that there are multiple consignments that require completing together. The details of the individual jobs can be seen in the Job Details screen, following.

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.

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
Consolidate Jobs
Deconsolidate 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 be allowed, but with a warning displayed to the drivers.

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.

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.
Group Jobs Together - if configured for Consolidation, this option allows the selected job to be quickly grouped with another.
Break Group - if configured and the selected row is a consolidated group of jobs, this option will break the group back into individual jobs and refresh the job list.

Job Details

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

Address & Contact
Instructions

The screen has several sections and tabs, showing:

The Job Type (Collection, Delivery, 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 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 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 EBB Papers, 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

For EBB Paper, 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. These instructions will be concatenated 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 be allowed for EBB Paper, but with a warning. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and must confirm to continue.

Once started, the device will display a navigation button. Clicking this will start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp. For non-TomTom devices, 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 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 for the TomTom devices. 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).
Confirm delivery of product.
Complete delivery (recording time off site)

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

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:

The Product Code
The Product Description
The Unit Type
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
Product Info Pop-up
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.

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

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.
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.
Clicking Deliver All on the Job Details tab.

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

The system will be configured with "Deliver All" functionality. This can be used to mark all pending products as delivered. This is most likely to be used as follows:

Check all products and quantities from the information on the Product list.
Cancelling or changing the quantity of any items with discrepancies, using the following processes.
Clicking Deliver All for the remaining products on the list.

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

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.

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 returns of products are created, these collections will be interfaced to as Collection jobs.

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.

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:

Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

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. This Unmanned Location Process will be configured for this implementation. Note: This is dependent on a development in progress at this time and is a dependency of this implementation.

If a customer is not available, the driver can click the Unmanned Location button. The device will prompt for confirmation from the user that no customer is available to sign for the job.

If confirmed, the device will prompt for the Driver signature, then prompt for a Job Photo, where at least one photo must be taken by the driver. This will be done regardless of any other configuration set against the jobs or site.

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

The standard collection T&Cs will not be shown. Special Driver T&Cs can be configured if required.
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.

Only for Unmanned Locations, the device will prompt for photos after completion of the driver signature. Note that this can be configured for every process if required, but is expected only to be prompted for for unmanned locations.

The driver will be able to 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 or log off the system.

Desk Collect Process

The above process of working through jobs from a Job List, selecting them and following the delivery process will be as per the above process.

The Load for the depot operatives will be created one per depot per day, so all collections from the depot will be visible on that load.

The device will show all jobs as delivery jobs with the destination address and contact information provided. The desk operative will request the information from the customer (reference, post code, etc) and select the job (or consolidated jobs, if there are many to be collected) from the job list.

The depot operative will then Start the job and immediately click Arrive - no navigation is required.

The depot operative will then check the goods and 'deliver' as the driver would. Deliver All functionality will be available.

The device will prompt for the customer signature - no unmanned location process will be available.

When the desk collection is complete, the job will be removed from the list, as normal.

All collections for the day will remain on this load unless they are moved to another day by the interface. If any jobs remain on this load at the end of the day, the load should be cancelled or deassigned from the "WAREHOUSE" user using the Admin system.

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.

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.

EBB Papers 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 EBB Papers POD Format

SCR-343463-4:

EBB Paper 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:

EBB Logo - It is expected that this will be the logo taken from the site.
"ELLIOTT BAXTER & ..." - fixed text.
"Delivery Note" - fixed text, displaying "Collection Note" if the job is a collection.
Mr EBB Logo - Fixed image in the format
Invoice to - The address of the job's customer.
"Delivery to" - fixed text, displaying "Collection from" if the job is a collection.
Delivery to - the job address if present, otherwise the customer address.
"Delivery Instructions" - any job instructions provided.
DATE - Warning: the planned start date
BRANCH - the owner of the job
DEL DATE - Warning: the actual start date
DELIVERY TIME - Warning: the planned start time
S TIME - the arrival time
E TIME - the actual end time
DEL NOTE NO - the INV number (Job Code)

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

ORDER NO - the order number against the product
QTY - The actual quantity of the product delivered, as confirmed by the driver.
UNITS - the unit type against the product
QUALITY & DESCRIPTION - The description of the product, and the FSC number (if provided) from the Long Description.
PACKS - the pack size, from the case quantity.
KGS - the weight of the product

Footer, expected to be shown on all pages:

Please be sure to check every..." - T&Cs from the job.
Total Wgt - the sum of the weights of the delivered products.
"Signature" - the customer signature if present.
Print Name - the customer signatory, if present.
Date - the actual end date.
"Signed on behalf of" - based on the Unmanned Location process. If the driver signature is present, it will be displayed here.
Print Name - the driver's name.
Date - the actual end date.
"NUMBER 1 FOR SERVICE" - fixed logo.
"Only products identified ..." - fixed text.

Warning: Definition of the exact fields used for this report will be confirmed at functional specification stage, dependant on the interface mapping, specifically:

The Dates and Times displayed
The Branch
The quantities displayed is dependent upon how C-ePOD will store these values.

Data Export

At this time, there is no planned outbound interface of jobs completed in C-ePOD back to the ERP or TMS.

At this time, there is no plan to automatically email the POD document to a customer email address, or export the POD in PDF form to a document management system.

However, these automatic emails or exports may be configured at any time. It is noted that the customer's email system is powered by a Microsoft Exchange server, not Office 365.

A recent development (re: FS 343561 SCR-339867-09 Do not Automatically Email Orders) has been completed that allows C-ePOD to send POD or POC reports if the job has not been completed cleanly (i.e. there has been a shortage of product, an item or product was not delivered or the job was cancelled completely). EBB Paper will make use of this development, sending POD/POC reports to the defined Site (i.e. transport/carrier) email address.

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
Contracts/Owners
Customer Service Queries
Transport Office

The C-Portal TTM module will primarily be used as an internal tracking tool.

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 noted that failed delivery of orders on a day may result in the order being re-planned for the following day. In this case, the order will be interfaced on another vehicle and manifest file for the next day. C-ePOD must take this into account when sending data to TTM, to show that the order is being redelivered. This will be through a suffix "_Rx" to the transport reference, showing that this is a redelivery, attempt "x".

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.

It is noted that the ETAs are currently calculated within CALIDUS Portal using a fixed dwell time at each location. The Portal will be updated (as part of the product improvement program) to calculate these times with the defined dwell time between stops taken into account. This will be made available to EBB Paper when developed.

SCR-343463-5:

Use defined Dwell time for ETA.

The following is a brief description of functionality available within CALIDUS Portal that has potential to be used by EBB paper 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

It is noted that the Map screen could display the ETA and Planned times.

SCR-343463-6:

Display ETA and Planned Time on Map screen

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

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	EPOD	Integration	Bespoke Import Interface	27.00	³
2	VEhub	Admin	Improved searching on tables	6.00	²
3	EPOD	Device	General Mobile Device Styling	1.00	³
4	EPOD	Reports	EBB Paper POD/POC Format	4.00	³
5	PORTAL	ETAs	Use defined Dwell time for ETAs	4.00	²
6	PORTAL	Map	Display ETA and Planned time on map	1.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 developed as part of the product improvement program internally at OBS Logistics and will be made available when complete.
These changes will be delivered as part of the contracted delivery at no additional cost.

Appendix B: Document References

B.1 References

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

B.2 Glossary

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

B.3 Authorised By

Rebecca Elliott	EBB Paper Representative	_____________________________
Matt Turner	OBS Logistics Representative	_____________________________

@@ Line 3: / Line 3: @@
 {{#vardefine:ClientName|Elliott Baxter and Co}}
 {{#vardefine:System|''CALIDUS'' ePOD}}
+{{#vardefine:SystemCode|EPOD}}
 {{#vardefine:Doc_Title|EBB Paper Solution Design}}
-{{#vardefine:Version|0.3}}
+{{#vardefine:Version|2.0}}
-{{#vardefine:Date|22nd June 2017}}
+{{#vardefine:Date|1st August 2017}}
 {{#vardefine:Reference|343463}}
 {{#vardefine:Year|2017}}
@@ Line 41: / Line 42: @@
 * Changes relating to information passed through to {{#var:System}} from external systems (i.e. TMS and ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
 * Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.
+* The original solution from the sales process was to include ''CALIDUS'' TMS and WMS products. At this time, the customer is not ready to replace TMS. However, the customer believes that immediate benefits can be derived from C-ePOD, C-VEhub and TTM without C-TMS or C-WMS. The solution outlined in this document covers this, without implementing C-TMS or C-WMS.
+* This solution originally included completion of Trunking movements through EPOD. It has now been established that the information required to determine how to create these Trunking loads from the manifests provided does not exist. Therefore execution of trunk movements has been agreed to be removed from the scope of this solution.
+* Trailer swapping is performed by EBB, predominantly for trunking movements. More detail on this process is required, but at this time it is expected that this will not be part of the C-ePOD execution and will be handled manually.
+* Lot control was discussed and parked - it is out of scope of this solution design. However, it is noted that the expected requirements for this process would be:
+**         Obtain the Lot number(s) from a different view from GP
+**         Store against the product as a reference
+**         Display on the driver's device when delivering product.
 <!-- ANY other systems? e.g. does this link to TTM, WMS, 414, 770, etc? -->
@@ Line 136: / Line 145: @@
 * ''CALIDUS'' TTM
-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.
+An updated project plan will be sent to the customer when available, detailing the time-lines of all phases of the project, including the implementation and development phases.
 The operation will expect to execute the following movement types:
-* Trunk
 * Radial Delivery
 * Desk Collect
+{{Note}} Trunk movements of products will not at this time be executed through C-ePOD.
 Android tablets will be used to complete the customer (desk) collections through C-ePOD. These will be defined as a separate job group for configuration purposes. These will be performed through C-ePOD running on basic android devices, probably tablet, possibly Wi-Fi only.
-Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a vehicle of "WAREHOUSE".
+Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.
 There are also supplier direct to customer deliveries. As these are not executed through the EBB network, they will not be interfaced to C-ePOD.
 A list of branches and their details has been provided by the customer.
@@ Line 154: / Line 165: @@
 Roughly 30 new delivery addresses are created each day.
-A list of email addresses for the branches is required
+A list of email addresses for the branches is required.
 Certain data is required for configuration of all OBS systems being installed, such as:
@@ Line 163: / Line 174: @@
-Lot-controlled items are delivered in this operation. Details are to be provided by the customer, including examples. It is believed that, at this time, this is not a go-live requirements for the implementation.
+Lot-controlled items are delivered in this operation. This is not a go-live requirements for the implementation. However, it is noted that the expected requirements for this process would be:
+*         Obtain the Lot number(s) from a different view from GP
+*         Store against the product as a reference
-Further example files have been provided for trunks. These need to be assessed and detailed in the functional specification stage.
+*         Display on the driver's device when delivering product.
@@ Line 179: / Line 190: @@
 The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.
-{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This quite frequently on radial deliveries, and is expected to happen every day on trunk loads.
+{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This quite frequently on radial deliveries.
-This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file.
+This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.
-The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.
 The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.
@@ Line 205: / Line 214: @@
 * Vehicles
 As noted above, it is expected that this data will be created at implementation.
+When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.
+For example:
+*         "DAVID EASTMAN" will become "DEAST001"
+*         "SMITH JOHN" will become "SJOHN001"
+*         "DEREK MAY" will become "DMAY001"
+*         "TRUNKER M25". TRUNKER M25 will become "TM25001"
+Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
+*         "DIANE EASTMAN" will become "DEAST002"
+*         "SANDERSON JOHN" will become "SJOHN002"
+The password will be defaulted to the user name.
+It is noted that EBB will tidy up the list of drivers before the implementation
@@ Line 214: / Line 238: @@
 |03 CHARLTO	||903 ADI	||Thurrock
 |-
-|04 FARNBO	||904 ADI	||Farnborough
+|04 FARNBOR	||904 ADI	||Farnborough
 |-
 |05 WATFORD	||905 ADI	||Watford
@@ Line 236: / Line 260: @@
 {{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.
-{{Warning}} The interface must identify the Site (the executing depot) and the Owner (the originator). Confirmation is required as to what data from the interface files contain this information. This may be confirmed at functional specification stage for this interface change.
+The interface must identify the Site (the executing depot) and the Owner (the originator).
+* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
+* The executing depot is the depot property on the manifest tag in the XML file.
+It is noted that the following will be Owners only and will not be operators:
+* 08 PRINTMT
+* 20 EBBOFFI
+* 30 GLOSSOP
+The following columns are also noted from the MSA view:
+*         DefaultSiteID - the final delivery depot
+*         Originating Depot - the depot from which the product is sourced. {{Note}} The Depot attribute of the order tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).
@@ Line 244: / Line 280: @@
 In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.
+The interface will consolidate jobs together if:
+*         The manifest on which the job is received is determined to be on the same Load as other jobs.
+*         The job has the same customer and delivery address as another job on the load.
+*         The other jobs are not completed or cancelled.
+*         They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
+Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.
+Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.
@@ Line 249: / Line 295: @@
 * INV - Delivery order
 * CAL - Call-off. Considered to be the same as an INV order.
-* ISTIN - transfer of stock between depots (inter-warehouse transfer or IWT)
 * RTN - Collection from customer.
+{{Note}} Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.
+{{Note}} Any manifests marked as TRUNK (in the trailer attribute of the TMS XML file) will also not be processed.
 Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.
@@ Line 264: / Line 314: @@
 {{Note}} Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.
-The start and end planned time (in columns "S Time" and "E Time") will be used for the start and end planned time for the jobs. If these are not present, the DelTime column will be used. If this is not present, the planned start and end times will be defaulted to 0600 and 1400 respectively.
+The start and end planned dates and times will be populated from the values in the following MSA view columns:
+*	Start Planned Date - ReqShipDate
+*	Start Planned Time - StartTime if populated, else 0600
+*	End Planned Date - ReqShipDate
+*	End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.
 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:
@@ Line 273: / Line 328: @@
 It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
-* Trunk
-** No Driver or Customer Signature
-** Deliver All functionality enabled
 * Radial Collection/Delivery
 ** Customer Signature
@@ Line 293: / Line 345: @@
 The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
 * Product Code
-* Product Description
+* Product Description - stored as a truncated value
-* FSC number (optional)
+* FSC number (optional) - stored with the full product description in the long description field.
 * Pack Size
 * UOM
 * Weight
 * Quantity
-The description of the product is longer than the description within C-ePOD. The full description is required on the POD note. Therefore the description will be increased in length to accommodate this.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Product Description increased in length
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
 The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.
-UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (i.e. 1.3 Tonnes). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).
+UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).
-{{Warning}} UOFMs known at this time, proposals to handle them and exceptions noted:
+The following is a list of the UOFMs known at this time and the proposals to handle them:
-* 1 - quantity will always be 1. There are examples of 0.1 and 0.5. I propose to always set value as 1.
+*	1 - always 1 - accepted as such, but rounded up if decimal.
-* 1000 - quantity will be multiplied by 1000. No exceptions that I can see.
+*	1000 - quantity will be multiplied by 1000.
-* BOTTLE - always integer value - accepted as such, but rounded up if decimal. I only have 1 example of these, which is 1.
+*	BOTTLE - always integer value - accepted as such, but rounded up if decimal.
-* BOX - always integer value - accepted as such, but rounded up if decimal. One exception in the samples, of value 0.03. In this example, I would round up the quantity to 1
+*	BOX - always integer value - accepted as such, but rounded up if decimal.
-* CHARGE - Excluded - this is a delivery charge. No line will be created.
+*	CHARGE - Excluded - this is a delivery charge. No line will be created.
-* EACH - always integer value - accepted as such, but rounded up if decimal. One exception in the samples, of value 5.5. In this example, I would round up the quantity to 6.
+*	EACH - always integer value - accepted as such, but rounded up if decimal.
-* ENVS - Envelopes. Quantity will be multiplied by 1000. No exceptions that I can see.
+*	ENVS - Envelopes. Quantity will be multiplied by 1000.
-* MISC - always integer value - accepted as such, but rounded up if decimal. I only have 2 examples of these, which are 1.
+*	MISC - always integer value - accepted as such, but rounded up if decimal.
-* ROLL - always integer value - accepted as such, but rounded up if decimal. I only have 2 examples of these, which are integer values.
+*	ROLL - always integer value - accepted as such, but rounded up if decimal.
-* SETS -Multi-part paper. Quantity will be multiplied by 1000. No exceptions that I can see.
+*	SETS -Multi-part paper. Quantity will be multiplied by 1000.
-* SHEETS - quantity will be multiplied by 1000
+*	SHEETS - quantity will be multiplied by 1000
-* TONNE - quantity will be multiplied by 1000. UOM will be changed to KILOS.
+*	TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
-It is proposed that any not on this list will be converted to an integer value, rounding up.
+*	METRES SQUARED - quantity will be multiplied by 1000.
+*	LINEAR METRES - quantity will be multiplied by 1000.
-Further analysis is required on this and confirmation from the customer has been requested. If not appropriate, development work must be undertaken to change C-ePOD and C-PORTAL to handle decimal values.
+There are then essentially 4 rules:
+{| class="wikitable" border="1"
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|- bgcolor="silver"
-|Definition=Support decimal values in quantities
+!RULE	!!UOMS
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
+|-
-}}
+|Multiply by 1000 	||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
+|-
+|Round up to nearest integer value	||1, BOTTLE, BOX, EACH, MISC, ROLL
+|-
+|Exclude	||CHARGE
+|-
+|Multiply by 1000 and change to KGS	||TONNE
+|}
+Any not on the list would follow the first rule (i.e. multiply quantity by 1000).
+Note that the above method has been confirmed by the customer.
-Trunk movements are defined as movements between two depots (sites) defined in the list above.
-Trunk orders created will include the products - there could up 100 or more products on the trunk moves.
+This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. {{Note}} This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).
-{{Note}} If the trunk of an order is cancelled, the radial delivery of the job will not be planned or manifested and therefore C-ePOD will not receive it, so it will never be executed. This is as expected - no further functionality within C-ePOD is required to attempt to cancel onward deliveries of the same order if the prior delivery is cancelled.
-For deliveries that are trunked and then refused by the customer, stock is either held at the delivering depot (if it stocks this product) or a separate IWT order is generated to transfer the stock back to the originating depot. This will generate an order for C-ePOD, which will be treated as any other trunk or IWT order.
@@ Line 379: / Line 429: @@
 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.
+Additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. The C-ePOD Admin Job screen may be used to add a job to a load, or to create a new job, then assign it to a load.
+It is recommended that, in this particular example, product lines of code "PALLETS" are added to the collection job, with a zero quantity. The C-ePOD device can then be used to  prompt the driver to enter how many pallets have been picked up. This will then be reflected on ''CALIDUS'' Portal TTM showing as Planned 0, collected 4. {{Note}} If the product lines not entered, this will not affect C-PORTAL or C-ePOD functionality - C-ePOD will still execute the job and C-PORTAL will still show the job being completed, just without products and quantities.
@@ Line 396: / Line 451: @@
 {{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 EBB Paper network for all users that require it.
-The drivers will be provided a user-name and password (expected to be a PIN number). The users and their passwords must be configured within C-VEhub. It is expected that the username and password will be configured to be the TomTom WEBFLEET username and PIN.
+The drivers will be provided a user-name and password (expected to be a PIN number). The users and their passwords must be configured within C-VEhub. It is expected that the user name and password will be configured to be the TomTom WEBFLEET user name and PIN.
+It is noted that VEhub is likely to be used by Agency drivers as well. In this case, the system may be configured with multiple generic agency drivers (e.g. "AGENCY 1", "AGENCY 2", etc) and these used by the drivers themselves.
+In this case, it is recommended that the defect check template used by the Agency drivers request the entry of the agency driver's name as part of the additional defect checks, to ensure that the name of the driver completing the checks is always captured.
+{{Note}} It is not possible to allow multiple drivers (agency or not) to access the VEhub system with the same ID. This will invalidate the session for the driver initially logged on to the VEhub mobile device application.
-C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot.
+C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot. It is noted that the customer's email system is powered by a Microsoft Exchange server, not Office 365.
 It is noted the Vehicle Checks table (and all other tables in this system) will be modified for improved searching.
@@ Line 412: / Line 475: @@
 == C-ePOD Mobile Device Application ==
-The mobile device application will be used to execute all types of trips executed by the depots, namely:
+The mobile device application will be used to execute the following types of trips executed by the depots:
 * Radial Deliveries and customer collections
-* Trunk trips
 * Desk Collections
 The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other trip types.
@@ Line 440: / Line 502: @@
 </gallery><br />
-The drivers will be provided a user-name and password (expected to be a PIN number), 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 {{#var:System}}. {{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 configured to be the TomTom WEBFLEET username and PIN.
+The drivers will be provided a user-name and password (expected to be a PIN number), 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 {{#var:System}}. {{Note}} User IDs that are created automatically as part of the Standing Data creation at Load Import will be available for use, but will have a default password created. This password should be modified before use as a security precaution. It is expected that the user name and password will be configured to be the TomTom WEBFLEET user name and PIN.
 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}} There will be agency drivers who use the C-ePOD software. There will be multiple agency drivers, but the actual driver who completes the task may not be known until they turn up (due to late replacements). Therefore, there will be multiple general Agency drivers configured in the customer's TMS e.g.
+*         Agency 1
+*         Agency 2
+*         etc.
 {{Note}} Vehicle checks will be completed through the ''CALIDUS'' VEhub application and are not integrated into {{#var:System}}. ''CALIDUS'' VEhub is not within the scope of this document. There will be no vehicle checks implemented within ''CALIDUS'' ePOD for EBB Paper processes.
@@ Line 455: / Line 525: @@
 File:REQ_343463_PDA_JobList1.png|''Job List''
 </gallery><br />
+{{Note}} The Load ''must'' be downloaded to the device through a data (3G or Wifi) connection. After this, the device can work off-line. However, if there are updates to the drivers load whilst out in the field, the updates will not been seen by the driver until a data connection is made.
@@ Line 582: / Line 655: @@
 * Job Instructions
-As part of the styling changes, the checkbox "Has this delivery been checked?" will be removed from the style.
+As part of the styling changes, the check-box "Has this delivery been checked?" will be removed from the style.
 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:
 *    The Product Code
-*    The full Description
+*    The Product Description
 *    The Unit Type
 *    The Item Type
 *    The Planned Quantity
-<!--{{Warning}} 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:
@@ Line 606: / Line 676: @@
 File:REQ_343463_PDA_Delivery6b.png|''Product Info Pop-up (More)''
 </gallery><br />
 For information on the actions above, see the appropriate following sections.
@@ Line 630: / Line 701: @@
 The system will be configured with "Deliver All" functionality. This can be used to mark all pending products as delivered.
-This is most likely to be used by:
+This is most likely to be used as follows:
 * Check all products and quantities from the information on the Product list.
 * Cancelling or changing the quantity of any items with discrepancies, using the following processes.
 * Clicking '''Deliver All''' for the remaining products on the list.
-This process is likely to be used extensively for Trunk deliveries.
 === 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.
 <gallery widths=300px heights=210px perrow=2>
 File:REQ_343463_PDA_Delivery7.png|''Exception - Change Product Quantity''
@@ Line 645: / Line 716: @@
 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.
+The application will ''not'' be 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.
-<!--{{Warning}} 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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Product Quantity to use Pack Size
-|Link=Appendix A: Table of SCRs and Ballpark Estimates
-}}
-This change affects the display of the Product List and all changes made to Product Quantity.
--->
 === Cancelling a Product ===
@@ Line 746: / Line 807: @@
 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.
-== Trunk Process ==
-The above process of working through jobs from a Job List, selecting them and following the delivery process will be as per the above process.
-The Load for the Trunk drivers will be heavily consolidated, and will likely only contain 1 or 2 stops on the job list, with all jobs consolidated together at the depots.
-As mentioned, this delivery process is likely to make substantial use of the Deliver All process, to identify that all products are delivered to the depot successfully.
-When the driver delivers to the depot, the device will not prompt for any signatures, customer or driver. Instead, the process will return to the job list after confirmation that all product is delivered.
-{{Warning}} Trailer swapping is performed by EBB. More detail on this process is required, but at this time it is expected that this will not be part of the C-ePOD execution and will be handled manually.
@@ Line 846: / Line 895: @@
 * The Dates and Times displayed
 * The Branch
-* The quantities displayed is dependent upon how C-ePOD will store these values, dependent on the decimal quantity change specified in this document.
+* The quantities displayed is dependent upon how C-ePOD will store these values.
@@ Line 852: / Line 901: @@
 At this time, there is no planned outbound interface of jobs completed in C-ePOD back to the ERP or TMS.
-At this time, there is no plan to automatically email the POD document to a customer or depot email address, or export the POD in PDF form to a document management system.
+At this time, there is no plan to automatically email the POD document to a customer email address, or export the POD in PDF form to a document management system.
+However, these automatic emails or exports may be configured at any time. It is noted that the customer's email system is powered by a Microsoft Exchange server, not Office 365.
-However, these automatic emails or exports may be configured at any time.
+A recent development (re: FS 343561 SCR-339867-09 Do not Automatically Email Orders) has been completed that allows C-ePOD to send POD or POC reports if the job has not been completed cleanly (i.e. there has been a shortage of product, an item or product was not delivered or the job was cancelled completely). EBB Paper will make use of this development, sending POD/POC reports to the defined Site (i.e. transport/carrier) email address.
@@ Line 911: / Line 963: @@
 * When an order is cancelled.
 The messages identify any changes to quantities and reasons for these changes at all stages.
-The interface from C-ePOD to C-PORTAL TTM must account for trunks of orders to determine the from and to locations for the orders in TTM. The jobs will be linked through the Job Code to determine this.
 It is noted that failed delivery of orders on a day may result in the order being re-planned for the following day. In this case, the order will be interfaced on another vehicle and manifest file for the next day. C-ePOD must take this into account when sending data to TTM, to show that the order is being redelivered. This will be through a suffix "_Rx" to the transport reference, showing that this is a redelivery, attempt "x".
@@ Line 1,037: / Line 1,087: @@
-<!-- MEDIA EBB Paper YES -->
+<!-- MEDIA LANDCSAPE YES -->
 = Appendix A: Table of SCRs and Ballpark Estimates  =
 <!-- If there's only one system being discussed here, the system column can be removed.
@@ Line 1,047: / Line 1,097: @@
 {{REQ_SCR_Header}}{{REQ_SCR_Line
 |SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Integration|Description=Bespoke Import Interface |Estimate=27|Notes=3
-}} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Database|Description=Product Description increased in length |Estimate=3|Notes=3
-}} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Database|Description=Support decimal values in quantities|Estimate=20|Notes=1
 }} {{REQ_SCR_Line
 |SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=VEhub|Area=Admin|Description=Improved searching on tables|Estimate=6|Notes=2
@@ Line 1,056: / Line 1,102: @@
 |SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=General Mobile Device Styling |Estimate=1|Notes=3
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Reports|Description=EBB Paper POD/POC Format |Estimate=2|Notes=3
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Reports|Description=EBB Paper POD/POC Format |Estimate=4|Notes=3
 }} {{REQ_SCR_Line
 |SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=ETAs|Description=Use defined Dwell time for ETAs |Estimate=4|Notes=2
@@ Line 1,065: / Line 1,111: @@
 Notes:
-#	This change is required only if the OBS systems are required to store decimal quantities. Note also that this change covers C-ePOD and C-PORTAL only. Should C-TMS be used as part of this solution, this must be evaluated for change separately.
+#	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 developed as part of the product improvement program internally at OBS Logistics and will be made available when complete.
 # These changes will be delivered as part of the contracted delivery at no additional cost.
-<!-- MEDIA EBB Paper NO -->
+<!-- MEDIA LANDSCAPE NO -->
 {{Doc_Appendix
 |Appendix=B
@@ Line 1,103: / Line 1,149: @@
 }}</div>
 [[Category:{{#var:Client}} REQ]]
+[[Category:{{#var:SystemCode}}]]

Anonymous

Search

REQ 343463 EBB Paper Solution Design: Difference between revisions