F H Brundle

F H Brundle C-ePOD Solution Design

CALIDUS ePOD

20th July 2016 - 1.0
Reference: REQ 336500

Introduction

This document is the F H Brundle C-ePOD Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from F H Brundle, on 05/07/2016 at the FH Brundle office in Ilkeston.

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

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

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

F H Brundle is the UK’s largest stockist of wrought iron components, welded wire mesh and expanded and perforated metal available from stock for immediate delivery. Other product ranges include stainless steel handrail components, tube clamps and galvanised tube, industrial steel flooring and GRP and tactile flooring. In addition to gate hardware and CAME gate automation equipment F H Brundle is also one of the largest steel sections stockholders in the UK.

F H Brundle trade from 7 nationwide distribution centres throughout the UK with over 200,000 square feet of warehousing.

F H Brundle operate a fleet of 50 lorries and vans integrated with an external parcel carrier.

Address:

F H Brundle,
Condor Road,
Quarry Hill Industrial Estate,
ILKESTON,
Derbyshire,
DE7 4RE

Contacts:

David West (IT).
Rob Eldridge (Ops)
Carl Taylor (Ops)
Kevin Hunter (Director)

OBS Logistics Contacts:

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

The core systems are ReportHub (ERP) and DPS, with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal).

Orders come into ERP.
ERP interfaces the orders to DPS, for Routing purposes, then back to ERP.
ERP interfaces routes and orders to CALIDUS ePOD (trigger at Despatch).
CALIDUS ePOD executes jobs and utilises TomTom Navigation on demand.
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.

Project Implementation Stages:

Test of CSV interface
Pilot - CSV upload only, no further update of ERP on completion
Phase 2 - Full OBSL XML Interface

Data Import

It is intended that the first phase of implementation of the software will include a flat-file transfer of a CSV file in OBS CSV format. This has been provided to the customer. There are some limitations of this format (i.e. it does not include all the fields that the full XML format provides), which will limit some of the functionality provided by the system. However, it is intended that a later phase of development to the ERP will result in the full XML interface format being used for imports.

Note: At this time, it is not expected that the ERP will be informed of updates of completed jobs. This is expected to be implemented at a later stage, and will be through the OBS XML Export format, either through Webservices or flat-file transfer pushed from CALIDUS ePOD.

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

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

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

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

General Deliveries, Priced POD.
General Deliveries, Unpriced POD.
'Problem' customers, Priced POD with Cash on Delivery.

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

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

Customer Signature
Consolidation
Optional Job Photo
Priced and Unpriced POD format will be assigned to appropriate job groups.
Cash On Delivery Terms and Conditions will be applied to 'Problem' job groups.

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

Details for each job type include:

Load ID - a unique ID for each load i.e. not a repeating Route Code.
Driver and/or Vehicle - for allocation of loads for execution.
Customer Code
Order (invoice) address information , linked from the Customer Code
Delivery Job Address
Order Number - the ERP internal unique order reference
Customer's Order Reference
Sales Person - Note: This cannot be sent using the CSV format and will not be received until the full interface is implemented.
Job Instructions, including the Total Weight of the order and any other instructions. Note: This will be simply concatenated in the CSV interface. When the XML interface is used in a later phase, this may be split into multiple additional fields.
Product Codes
Product Quantity Ordered.

Note: For a later phase, CALIDUS ePOD supports an XML format and webservices. OBS Logistics have created standard Interfacing documentation and passed this on. At this time, no mapping exercise has started. There are no expected modifications of the interface within CALIDUS ePOD, but it falls to OBS Logistics to specify and control the modifications to external systems.

SCR-336500-1:

ePOD-ERP Integration meetings and specification.

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

Drivers
Customers (Invoice or Order Addresses)
Vehicles
Job Groups

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

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

Each of these items can be agreed in advanced or administered within CALIDUS ePOD, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in CALIDUS ePOD, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created. As part of the interface mapping exercise, this standing data will be agreed, regardless of whether the interfaces above are implemented within the ERP.

Note: Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. This must be achieved by the ERP or DPS.

If this cannot be done, then the CALIDUS ePOD Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Administration

The CALIDUS ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface (Admin console) and a mobile device application for use in completing tasks.

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

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

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

To create and maintain users of the ePOD devices.
To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
To create Jobs of all types and group them together onto Loads.
To assign Loads to Users and Vehicles.
To view the Jobs and Loads created.
To track progress against the Loads, Jobs, Vehicles and Users.
To print or email a POD/POC.

It is expected that Loads will be assigned to Drivers and Vehicles through the ERP import interface. However, if not, or if they require amending, CALIDUS ePOD provides a facility to manually assign Loads to drivers, through the following mechanisms:

Through the Load, assigning a user directly
Through the User, selecting from any Pending Load.

Assigning a User to Loads

Assigning Loads to a user

If not assigned in advance, vehicles will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

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

PDA Login

As an optional change, the application may have a customised style created for FH Brundle, which will include:

An appropriate colour scheme, expected to be blue.
The logo on the login page.
A defined Job List style.
A defined Product List style

SCR-336500-2:

Create customer-specific style on device.

Note: It is intended that the application will support containerised (i.e. palllets, totes, cages, etc) delivery as and when a WMS solution is implemented to/instead of the ERP system in use. At that time, it may be necessary to update the application to format the container table and text labels with something more appropriate to the customer's requirements. This is not included in this phase or this solution design document, and will be costed if required at such time as it is required.

Note: At this time it is expected that the default OBS format will be used.

Log In

The drivers will be provided a user-name and password, and the loads will be allocated to specific drivers, 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.

A driver will log on to a device using the provided user name, password and vehicle. The device will remember the last used User name and Vehicle, but will always require that the password is entered.

Note: Vehicle checks will be completed through the CALIDUS VEhub application and are not integrated into CALIDUS ePOD. This is not within the scope of this document.

Obtain Workload/Job List

When vehicle checks are complete, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the Driver (or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Job List

The device will show a list of the jobs on this load, showing:

Job Reference - configured to be one of the following:
- Job ID - ePOD internal unique job reference
- Job Code - as mapped from ERP
- Cust Ref - as mapped from ERP. This is expected to be configured as the default display of Job Reference on the device.
- SO Ref - as mapped from ERP
- Ext Ref - as mapped from ERP
Job Type - Collection/Delivery
Customer Name
Postcode
Planned Date/Time
Product Count (subtotalled quantity of all items on the job)

Note: The format of this table may be configured for the customer's use, through the optional Customer Styling change specified above. It is expected that this will be in one of two general configurations (i.e. showing the customer name or not). If required, this must be decided before specification is complete.

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

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

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

The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job you want to complete - the device will display the Job Details page.

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

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

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.
Confirm re-sequencing allowed - this requests the user to confirm first.
Always allowed - no confirmation.

This configuration will be decided at the point of implementation, but is expected that initially re-sequencing will be allowed with a warning.

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

Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing Cancel from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

Note: The system may be configured for Image Capture in the following ways:

Force Image Capture at all times when cancelling or changing quantity (i.e. at Job and Detail level)
Optional Image Capture at all times.

Separate to the above configuration, Image Capture at the end of a job (if enabled) may be configured to be optional or required. It is expected that Photo at exception and at Job completion will initially be optional.

The driver may choose to consolidate jobs together, to process them together for speed. This is available through several options on the device, allowing:

Manual consolidation, by selecting all jobs to be consolidated individually, accessible through the Consolidate menu option.
To group single jobs with other consolidations, through the Create Group option accessed when long-pressing against a job or consolidated group.

Additionally, jobs may already be consolidated together when the load was created. Note: This feature is not available through the CSV Upload or through modification through the Admin console. When the full XML import is used, it will be possible for the ERP to identify jobs that are required to be consolidated together.

When consolidated jobs are present, a single line is shown summarising the information from all the jobs (i.e. total number of consignments, total products, etc). These can be seen in more details when completing the job (see later in this document).

The driver also has access to several functions to deconsolidate consolidated groups of jobs:

Singly, by selecting the job to split out, through the Deconsolidate menu option.
Breaking the entire group back to single jobs, through the Break Group option accessed when long-pressing against a consolidated group.

Note: This functionality can be disabled if not required.

Job Details

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

Job Details

The screen has several Tabs, showing:

The Job Type (Collection, Delivery, Service)
The customer details (Customer Code, Name, Address and Postcode)
The contact information (Contact name and number)
The Instructions for the job

Clicking on the tabs will display the information.

If the jobs are consolidated, the < and > buttons can be used to move between the all the consolidated jobs, to see any specific details. The Instructions tab will show all instructions for all the jobs, as well as any additional information passed through for the job.

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 disp[lay appropriate icons to allow the drivers to accomplish this.

Cancelling a Job

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

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

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

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

Note: This job cancellation screen can also be called from the job list.

Starting/Navigating/Arriving

When the user has selected their Job, they can choose the Job with the Start Job button.

Delivery instructions are provided from several sources (specific instructions against the job and/or standing instructions for the customer e.g. "Ring 1hr before arrival"). These instructions should be concatenated in the ERP and sent in the Instructions shown above. If there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

Note: It is expected that re-sequencing of jobs is initially to be allowed with a warning. If a job is attempted to be started out of sequence, the user will be told this at this point and allowed to confirm.

When clicking this button to start or arrive at 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.

When a Job is successfully started, this will take the Job to 'In Progress' status, at this point the 'Start Job' button will change to an 'Arrive Job' button and the navigation icon is shown. When the navigation icon is clicked on the device will use a navigation application installed on the device to navigate to the destination. This will be through the TomTom navigation application for the TomTom devices used in this implementation - other devices may use any other installed navigation application. The destination address will be entered in the device and will allow immediate navigation to the address.

Once arrived at the destination, the driver will switch back to the CALIDUS ePOD mobile application. This can be through the 'All apps' icon on the home screen or through a configured short-cut on the task bar. The driver will then indicate arrival and start processing the Job by clicking the Arrive Job button. When the job is confirmed as Arrived, the device will move on to the Delivery or Collection process, depending on the job type.

Delivery Process

Deliveries will initially consist of multiple loose products. It should be noted that in later phases (i.e. after the WMS solution is installed), it is expected that products will be containerised (i.e. in totes, cages or pallets) with distinct container IDs associated with them. The CALIDUS ePOD system completely supports containerised delivery, both with and without scanning of contained products. For the purposes of this document, the focus will remain on product scanning.

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

Note: A Deliver All button will be available on this first tab. This is used for Delivery by Exception. Clicking this button will mark all products as delivered and moving to Job Completion stage, skipping all scanning of products. It is expected that this will be enabled for all job groups EXCEPT that assigned to 'problem' or COD customers.

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

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

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

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

If this is a consolidated job, the list will show all products required to be delivered on all jobs, including an indication of which order this product is for. Note: If the same product is present on two jobs consolidated together, the product will appear twice, to allow accurate recording of quantity delivered.

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

Deliver X
Change Quantity
Comments
Cancel
Info

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

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

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

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

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

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. Note: This option can be removed by configuration if not required.
entering the product code manually and clicking Deliver X from the pop-up menu.
scanning the product code and clicking Deliver X from the pop-up menu.
clicking the Deliver All button.

When marked as delivered, the item will be removed from 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 is also displayed here.

The driver is also able to optionally 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

If a product can't be delivered, it can be removed from the list with the pop-up option Cancel. Again, the exception screen will be shown where the driver can enter the reason 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.

Commenting a Product

The enabling of the product comments will mean the product options will also include a Comments option.

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

Note: Reason codes are the operation's to maintain and can be complex. They should be normalised between the ERP and CALIDUS ePOD, in preparation for updating the ERP data in a later phase. Reason codes can help in reporting and categorising exceptions in the ERP. Narrative responses such as this Product Comment are virtually impossible to group by narrative reasons e.g. "Late arrival" vs "Arrived Late" vs "ARRIVED LATE". Regardless, the system will be configured to allow this.

Collection (Returns) Process

There is no stated requirement for collections at this time. However, it should be noted that the collection process will be almost identical to that described above, substituting Collection instead of Delivery.

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

Job Completion

All jobs will be sent to the CALIDUS ePOD system with a configuration element known as Job Group - this will define the process to be followed against each job, configuring the following items:

The Terms and Conditions displayed
Customer Signature required
Driver Signature required
Completion document format

All of these processes are controlled during Job Completion.

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

The device will prompt for Customer Signature.

Signature and T&Cs
Products

The signatory will default to the customer contact sent through on the job, but this can be changed. If one is not sent through, the driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:

Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
The quantity of products being collected/delivered.
If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under 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.

Note: The system is expected to be configured so that, for Cash On Delivery notes, that the cash provided will be confirmed through the T&Cs, prompting for the value received at this time. This will be through the configuration of T&Cs for the jobs through the User-Defined Forms (UDF) screen. This will be configured at implementation, and will display the normal T&Cs, plus a label "Cash Collected" and a value. This value MUST be entered before the customer signature can be confirmed.

The process will prompt for photos after completion of the signatures for Deliveries - the application will ensure that at least one photo is taken.

The PDA will be configured for certain jobs for Job Photo Capture. When configured for this, the PDA will start the Photo Capture dialogue after all signatures have been captured - the driver will not be allowed to skip this however. The driver will be able to view the captured image or re-take the photos. The application will ensure that at least one photo is taken.

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

The user will be returned to the Job List screen and the completed Job will be removed from the list. Any completed jobs can be optionally viewed again, by pressing the Menu button and choosing Show All Jobs. The list can be made to show only outstanding jobs again by pressing the Menu button and choosing Show Outstanding Jobs.

Post-Load

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

The device will attempt to download a new load for the user and/or vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.

POC/POD Documents

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

The images should be shown on a second page, per item cancelled or quantity changed. Given that an image may be taken for non-delivery of items, this page may be shown if there are any product or job images. The second page would then display the job image first, then any product images, plus the reason codes and descriptions. Note: These Image pages will not be produced when emailing the report.

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

Sample POD Format

SCR-336500-3:

POD and POC Formats

Note: There will be two versions of the POD/POC note, one with pricing information against the line and one without. 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. The Unit Price and VAT information cannot be provided through the CSV interface and, as such, each job group should be initially configured to the non-priced POD/POC format. The total price will be provided in the CSV interface through the Instructions and displayed in the appropriate section. The full XML interface may be used at a later stage to provide this information, and the Job Group configuration should be changed for those customers that require a priced POD/POC note. For the initial phase, only an unpriced format will be produced. Should a priced format be required at a later stage, this will require a new change being raised at additional cost. This cost is not included in this document.

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:

Logo - It is expected that this will be the FH Brundle logo initially. However, there is a potential future requirements that certain of FH Brundle's customers may want a specific format, and that implementing their logo onto this documentation may suffice. Therefore, the logo must come from the Job Group associated to the job, unless this is not provided, when the Site logo should be displayed instead.
"1H1/1" - Warning: Unknown. At this time, this is assumed to be the Load ID and Sequence, or a unique reference for the job (e.g. Job ID). To be confirmed by the customer.
"DELIVERY NOTE" - fixed text, displaying "COLLECTION NOTE" if the job is a collection.
"Tel No"/"Fax No"/"Email" - from the Site address.

Header, expected to be displayed only on the first page:

"Deliver To" - the job address if present, otherwise the customer address.
"Ordered By" - the customer address.
"Customer Code" - the customer code.
"Order No" - the primary reference (i.e. Job Code).
"Your Order No" - the customer reference.
"Despatched" - the Actual Start Date of the load.
"Sales Person" - the sales contact for the job. Note: This data cannot be provided by the ERP through the CSV interface, and is mapped here to show capability for when the full interface is used. Without this information, the Sales Contact will be blank.

Note: The addresses shown on the POC and POD can be a single customer address (expected to be the account depot address) and a job address (expected to be the final delivery or collection address).

Product Details, expected to be shown on every page, expected to show up to 15 lines of information per page:

"Qty Ordered" - The planned quantity of the product being delivered.
"Qty Delivered" - The actual quantity of the product delivered, as confirmed by the driver.
"Description" - The description and product code.
"Line Value" - Note: Only displayed on Priced POD/POC notes. The Unit Price + Unit VAT, multiplied by the delivered quantity. On the Unpriced format, both the title and row values should be blank.

Information, expected to be shown once after the product details:

"Packing Information" - populated from the office instructions. Note: Using the CSV interface, this information cannot be provided. When switching to the full XML interface at a later stage, this information can be provided and will be populated on the POD/POC note.
"Other Information" - populated from the Job Instructions. Note: When using the CSV interface initially, this will be populated with the Weight and Order Instructions. For Priced items, this will also contain the total price of the order. When using the fill XML interface at a later stage, this information will be re-mapped.

Note: For the initial phase using the CSV interface, the Packing Instructions on the POD/POC note will be empty and all information will be displayed in the Other Information section.

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

"We Hereby..." - The text from the T&Cs against the job.
"Print Name" - the signatory name, confirmed or entered by the driver at customer signature.
"Signature" - the customer signature, captured by the driver.
"Date" - the actual end date of the job.
"Registered Office..." - from the Site address.

Note: The system is expected to be configured so that, for Cash On Delivery notes, that the cash provided will be confirmed through the T&Cs, prompting for the value received at the point of delivery. This will NOT be displayed on the POD/POC format.

Note: As noted above, there is a possible additional change for 3rd-party formats. If required, it is expected that this will be raised as an additional chargeable software change request at a later date, and is not part of the deliverable of the project at this time.

Data Export

For the pilot and first phase, it is not expected that the ERP or any non-OBSL system will be updated with any information for completed jobs. It should be noted that this export in XML format may be configured at any time without further software changes. The following section shows the capability of the system.

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

There are no expected changes to the existing export format or methodology. The information regarding this has been forwarded to the ERP consultants.

For jobs that have been completed, POD documents may be sent to the customer. In this case, the jobs that require this would have the email address populated when the job is sent to . As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD or POC report.

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

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

Email subject and content may be configured:

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

Note: It is expected that this functionality will not be enabled and that the Portal Track and Trace module will be used to generate an email with a link to the Customer Tracking Gateway for the customer to view or download the POD themselves if required. See the following sections for details.

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

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

POD/POC reports and full product details can be accessed from this screen.

User activity may also be accessed, to show auditing of messages from the user, for example:

Log on
Vehicle defect checks complete
Load picked up
Job started
Job arrived
Job completed
Load completed
Log off

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 functionality of CALIDUS Portal was not explicitly discussed in the requirements meeting. However, there is at this time no expectation that this would have to change in any way.

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

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

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

Trip/Order Enquiry

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

Order Enquiry

Order Enquiry Parameters

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

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 Detail

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.

Airport (Arrive/Depart) Screens

CALIDUS Portal supports several Airport-style screens:

Arrive/Depart screen
Order Status screen

Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries

Sample results pages:

Arrive/Depart screen

Order Status Screen

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

Note: A requirement of the customer is to be able to identify the jobs (collection and delivery) that have exceptions (i.e. were not collected/delivered in full). The filter menu on this screen allows the user to define the orders to be reported, entering date/time from/to, and selecting delivery exceptions only, allowing all other exceptions (e.g. late deliveries) to be removed from the screen.

Vehicle/Driver GPS Tracking

Although primary vehicle tracking for the FH Brundle implementation will be through TomTom.WEBFLEET, CALIDUS Portal and CALIDUS ePOD provide GPS tracking of vehicles and drivers.

GPS Tracking Parameters

GPS Tracking Results

GPS Tracking Map

Customer Tracking Gateway

On clicking the tracking link from the external system, the customer is asked to enter the consignment reference (the customer reference) they have been provided and the post code for the delivery location of the order being checked. Note that the consignment number can be sent through from the calling system, to help the customer obtain their details but post code must always be entered by the customer as a security measure.

Enter Consignment

The gateway then checks the order on the system, matching the customer reference and post code to the information on the system. The search for the order to be checked is not case-sensitive - the gateway will match the entry if entered in upper or lower case, and the postcode entered can be in any format, with or without spacing. If an order is not found that matches the information entered, the screen will display that no information can be found in a popup message.

If a unique order is found, the gateway displays a summary of the information on the order being checked, similar to the following:

Consignment Tracking

Note: Only information from the order being checked is displayed on this screen, as well as some information relating to times and execution of the Trip on which this order is being delivered. At no time is any information from any other order (on this trip or otherwise) displayed on this screen.

The screen displays:

The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
- Ordered.
- Loaded.
- Out for Delivery.
- Delivered.
- Cancelled
Last Delivery Sequence - The number of the last stop serviced on the trip that is delivering the order being checked. Note: This is only the stop number, not the full address of the last stop serviced.
Your Delivery Sequence - The stop on which the order being checked will be delivered. Note: This is only the stop number, not the full order address - this is displayed below.
Order Reference - The customer's order reference of the order being checked.
Full Address - The full delivery address of the order being checked.
Courier - If known, the courier completing the delivery of the order being checked.
Driver - The full name of the driver completing the trip on which the order being checked is being delivered.

The screen also displays a time-line bar, showing all the statuses the order being checked has passed though. Successfully-completed statuses are coloured green, and the date/time the status was changed (if provided) is displayed under the status on the bar.

If the order being checked is out for delivery, the screen displays a map showing:

The last known location of the vehicle making the delivery.
The customer’s delivery location

Note: The last known location of the vehicle making the delivery could be the address of another customer receiving a delivery on that trip. However, no address information or labels are shown against the locations displayed in the map and no information is divulged regarding the reason the vehicle is currently at that location.

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

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

Gateway - Consignment Signature

Tracking Emails

CALIDUS Portal can be configured for automatically triggered emails at certain system or operational events. It is expected that this implementation will be configured to send automatic emails upon delivery of items (the DEL event) to the delivery customer's email address.

Events are configured in the Event Maintenance page:

Portal Events Maintenance

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

Portal Events Maintenance

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:

Contact Name
Owner
Order Number
Booking Reference
TMS Reference
PO Reference
Customer Name
Planned Arrival Date/Time
Delivered Date/Time
Signed By
Tracking Link (only Body)

Note: This functionality is used for informing customers, and can only be configured against an event , in this case, successful delivery (DEL). There is also a potential requirement to email the customer service team when an order has been cancelled or delivered incomplete. This requires a change to the CALIDUS Portal system to create Email events:

Identify the customer service email address for the emails
Identify the status of the order on the event (in this case, on the DEL event, specifying that this is only for orders that have not been fully delivered).

This is an optional change - the same information may be found from the various screens within CALIDUS Portal (for example, the Arrive/Depart and Order Enquiry screens above). If this is required, this would be at additional cost.

SCR-336500-4:

Customer Service Alerts

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	ERP	Integration	ePOD-ERP Integration meetings and specification.	2.75	^{For a later phase}
2	ePOD	Look and Feel	Customer Styling of the PDA device application.	1.25	^Optional
3	ePOD	Reporting	POD and POC formats (UNPRICED ONLY)	4.75
4	Portal	Alerts	Customer Service Alerts	9.25	^Optional

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.
Unless specified as Optional, these changes are included in the contract for delivery of these items. Optional items are at additional cost and will require confirmation. Unless confirmed, these optional items will not be delivered with the other changes specified here.

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1	UG 291094 EPOD Admin User Guide	3.0	16/10/2014
2	UG 291097 EPOD Client User Guide	4.0	16/10/2014
3	FS 291096 Interface with CALIDUS ePOD	1.0	05/02/2015
4	Portal User Guide - TTM	6.8	02/06/2016

B.2 Glossary

Term	Definition
EPOD	Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD.
CALIDUS eSERV	The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system.
PDA	The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android.
DAL	Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it.
GPS	Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device.
GPRS, 3G, HSDPA, Data Service	All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet.

B.3 Authorised By

Rob Eldridge	FH Brundle	_____________________________
Matt Turner	OBS Logistics	_____________________________

Anonymous

Search

REQ 336500 FH Brundle C-ePOD Solution Design