Pilgrim Foods

Pilgrim Foods C-ePOD Solution Design

CALIDUS ePOD

25th July 2016 - 1.0
Reference: REQ 336832

Introduction

This document is the Pilgrim Foods C-ePOD Solution Design.

Objective

The primary purpose of this document is to document the requirements gathered from Pilgrim Foods, from various sales meetings.

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

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.
Changes requiring subsequent discussion are marked with a Warning: annotation. It is expected these will be clarified during the phase 2 workshop.

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

Website: http://www.pilgrimfoods.co.uk/

Established in 1980, Pilgrim Foodservice remains a family owned supplier of high quality products to the foodservice industry. They offer a range of over 4,000 products; these include all aspects of frozen, chilled and ambient foods together with soft drinks, cleaning and disposables products. They are a member of Caterforce Buying and Marketing Group and an active member of the British Frozen Food Federation. They have over 40 purpose-built, multi-temperature vehicles. Pilgrim Foodservice cover the East Midlands, East Anglia and South Yorkshire regions.

Pilgrim have a team of over thirty sales and customer support staff

Address:
Pilgrim Foodservice Ltd,
Marsh Lane,
Boston,
Lincolnshire,
PE21 7SJ
Telephone: 01205 312700

Contacts:

Operational:
- Charles Bateman ([email protected]) - MD.
I.T.:
- Phil Marshall ([email protected]) - I.T and Integration.
- Ben Richards ([email protected]) - Server/Hosting.

OBS Logistics Contacts:

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

Products to be delivered:

CALIDUS VEhub
CALIDUS ePOD
CALIDUS Portal TTM

Pilgrim will host the applications themselves on their own dedicated servers.

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.

It is expected that the core systems for order management and route planning (hereby referred to as ERP) will continue to be used, with OBS Logistics' systems providing execution (CALIDUS ePOD) and order tracking (CALIDUS Portal).

Orders come into ERP.
ERP route-plans orders.
ERP interfaces routes (loads) and orders (jobs) to CALIDUS ePOD (trigger to be defined).
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 project will be implemented in multiple stages:

C-VEhub - already configured and due for go-live on 1st August 2016.
C-ePOD phase 1 - FTP CSV upload only, no POD reports, C-Portal TTM for tracking of arrival and ETA, no electronic POD to customers, no further update of ERP on completion.
C-ePOD phase 2 - Full OBSL XML Interface and update of ERP, POD note formatting and electronic POD. This will be subject to a further phase 2 workshop.

Data Import

It is intended that the first phase of implementation of the software will include a flat-file FTP 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: For phase 1, 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, potentially configured with COD entry.
Collections.

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 the following in phase 1:

No Customer Signature
Driver Consolidation
Optional Job Photo
Generic POD format
Cash/Cheque On Delivery - This may be applied at customer or driver signature, or against the job details.
Allowed re-sequencing of jobs

For phase 2, the customer signature will be required, Deliver All functionality will be enabled and product delivery will be used.

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. It is expected that this will be by the Vehicle ID only. There was some discussion over using the vehicle ID as the user ID. This may be done if required, but is not necessary for CALIDUS ePOD to operate and allocate loads to vehicles.
Customer Code
Customer's Invoice Address, either maintained in the Admin system (phase 1) or interfaced with the jobs (phase 2)
Delivery Job Address
Order Number - the ERP internal unique order reference
Customer's Order Reference
Planned Start (and optionally End) date and time. Note: It is recognised that the ERP and planning solutions may specify only a window for the deliveries. For lateness and ETA functionality in CALIDUS TTM to function correctly (which measures against the planned arrival time), the Start Planned Date and Time should be set as the end of the window.
Job Instructions, potentially including the COD requirements. Note: Optional developments to CALIDUS ePOD for other customers may include the facility to alert the driver to ring a customer a certain number of minutes before delivery from the Job List screen. If this functionality is not available, it is expected that this requirement to contact the customer will be identified through the Job Instructions.
Product information - Codes, Descriptions, Pack Size, quantity (in cases and singles), unit price, VAT Code and unit VAT cost. Note: In phase 1, Product Information will not be provided.

Note: The CSV import has no facility to identify the vehicle, nor to sequence the jobs is any order other than by start planned date and time. The upload will be modified to allow the vehicle to be specified, and to (configurably) sequence the jobs in the order in which they are received in the file.

SCR-336832-1:

CSV Upload to specify vehicle and sequence.

Note: For phase 2, CALIDUS ePOD supports an XML format import and/or 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-336832-2:

ePOD-ERP Integration meetings and specification.

When phase 2 is implemented, it will be possible to also capture the following information:

Product information - Codes, Descriptions, Pack Size, quantity (in cases and singles), unit price, VAT Code and unit VAT cost.
Server-side consolidations of jobs

Note: Optional developments to the product suite (i.e. CALIDUS ePOD and Portal) for other customers may include the facility to identify multiple delivery windows against a job. If this development is completed, and the ERP is capable of interfacing this information and strongly planning the deliveries, the CALIDUS Portal screens will allow configuration as to whether this information is used to identify late or exception deliveries. This will be available through the XML upload only, not the CSV upload, and will therefore only be available (if completed) after phase 2.

There is a requirement to upload additional information regarding the monies required to be collected in cash or cheque, also identifying the invoice number from which this cost is generated. For example, "Inv 201 £405, Inv 301 £321, Total £235 to collect". It is recommended that this be placed in the Job Instructions so that it can appear on the device, if there is room to store this within the field (maximum length 255 characters). If specific fields are required to enter and store this information, this will require additional cost, which will be quoted as required.

Warning: It is not possible to identify the VAT Code against the products. If this is required, an additional change will be required to allow this to be specified, and to identify the code and rate in the system, for displaying on the POD note. This requirement will be clarified in the phase 2 workshop.

SCR-336832-3:

Support VAT codes within the system and on the POD/POC.

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. It is expected that this will be through the vehicle ID.

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 Vehicles through the 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. Alternatively, the driver will be assigned to the load selected based on the vehicle the driver selected when logging on.

In phase 1 (and potentially onward), transport staff will on rare occasions manage the manual entry of collections onto loads through the Admin console. This will be through the CSV Upload.

Note: If the sequence of the collection is not important on the load, then this may also be added through the Admin Loads screen.

View Load and Job

The load will be found on the Loads screen. The user will then view the jobs on the Load and add a new collection job.

Create Collection Job

There is no facility to change the sequence of jobs through the Admin Loads and Jobs. If this is required, as change will be required to the Loads and Jobs screens, to allow the entered jobs to be sequenced, and the jobs will be displayed in Sequence order, if present.

SCR-336832-4:

Admin Loads and Jobs screen to allow sequencing.

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 Pilgrim, 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-336832-5:

Create customer-specific style on device.

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.

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 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 (sub-totalled 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.

Note: Optional developments to CALIDUS ePOD for other customers may include the facility to alert the driver to ring a customer a certain number of minutes before delivery. If this development is completed, and the ERP is capable of interfacing this information and strongly planning the deliveries, the mobile device application Job List screen will show indicators against the jobs and against the load in general as to whether there are alerts that must be dealt with, showing them as a list. On devices with telephony enabled (i.e. not TomTom PRO or BRIDGE devices), the application will allow the driver to phone the contact directly from this alert.

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.

Note: It is expected that initially re-sequencing will be allowed.

If any jobs have been added to a Load while the load is in progress, the Refresh option (which also is timed to happen on a regular 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 and will not be used in phase 1. In phase 2, when the full XML import is used, it will be possible for the ERP to identify jobs that are required to be consolidated together - the device will then automatically show them as consolidated without driver intervention.

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.

Note: Optional developments to CALIDUS ePOD for other customers may include the facility to alert the driver to ring a customer a certain number of minutes before delivery from the Job List screen. If this functionality is not available, it is expected that this requirement to contact the customer will be identified through the Job Instructions.

There is a requirement to upload additional information regarding the monies required to be collected in cash or cheque, also identifying the invoice number from which this cost is generated. For example, "Inv 201 £405, Inv 301 £321, Total £235 to collect". This may also be present in the Job Instructions.

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

Cancelling a Job

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

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

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

If 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 completing jobs out of sequence will be allowed - as such, no warning will be given. If the system is configured to warn or not allow re-sequencing of jobs, the user will be told this at this point.

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 in phase 1 consist solely of a job to deliver goods, but with no indication of the products and quantities. It should be noted that in phase 2 (i.e. after the full XML interface is implemented), it is expected that multiple loose products will be present with quantities and pricing information. For the purposes of this document, the details of product scanning will be shown, indicating where in phase 1 this will not be present.

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

Job Details Tab
Job Details Tab - Addresses
Products Tab - not present in phase 1
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
Job Details UDF Information, which may include fields to enter the Cash and Cheque amounts collected.

Note: The system may be configured so that, for Cash On Delivery notes, that the cash provided will be confirmed through Job Details, prompting for the values received (Cheque and Cash) at this time. This will be through the configuration of Job Details UDF for the jobs through the User-Defined Forms (UDF) screen. This will be configured at implementation, and will display a label and a value for each. These values MUST be entered before the job can be completed.

In phase 1, a Complete button will be present on this first screen, to confirm the delivery as completed and move the driver straight to Job Completion stage.

Note: All further description in this section after this point refers to phase 2.

In phase 2, 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 the scanning of products that have not already been scanned or have had quantity changed.

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

Warning: The current Pilgrim POD/POC format requires both cases and units to be entered and calculated against jobs. It is assumed that this will also be a requirement on the device in phase 2, as this is not available in the CSV upload. Confirmation as to how this will work is required.

For example, the system could support this through a calculation from a pack size (i.e. total quantity 142, pack size 12, therefore total 11 cases 10 units)

Alternatively, the system could calculate this from a total number of whole cases (i.e. total quantity 142, case qty 10, therefore 22 units).

SCR-336832-6:

Support Cases/Units on the Device and Admin.

This change would affect all areas on the device where quantity is displayed, displaying it as Cases/Units e.g. 10/22. Areas affected would be:

Products List.
Products Actions ("Deliver X", Cancellation, Change Quantity).
Signature - products summary.

The Admin Products screen would also be affected.

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 Process

Collections will be created through the Admin console in the rare occasions that they are required.

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, or the collection is marked as complete by clicking the Complete button, 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: For phase 1, it is expected that the job completion configuration will request that a Photo be taken. No signatures (driver or customer) will be required, and the taking of a photo is entirely optional. It is intended that the driver may use this photo to capture an image when the delivery is made to an untended location.

However, it may be decided that Cash/Cheque collection is better collected at job end, before the Complete button is pressed. If this is the case, then the fields to enter these values can be added to a Customer Signature screen as terms and conditions. If so, customer signature must be enabled, and the driver will sign in lieu.

Note: For phase 2, customer signatures will be enabled, as will optional Job Photo.

If required, 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.

Warning: It may be a requirement to display a summary of cost and VAT on the device. If this is required, an additional change will be required to allow this to be specified in addition to the change to identify the VAT code against the product codes. This requirement will be clarified in the phase 2 workshop.

SCR-336832-7:

Display Price Summary inc. VAT on Device.

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 may be configured so that, for Cash On Delivery notes, that the cash provided will be confirmed through the T&Cs, prompting for the values received (Cheque and Cash) 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 and a value for each. These values MUST be entered before the customer signature can be confirmed.

The mobile device application will be configured for Job Photo Capture. When configured for this, the application will start the Photo Capture dialogue after all signatures have been captured (or after the job is complete, if no signature capture is configured) - the driver will be allowed to skip this however. 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 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

Note: In phase 1, no POD/POC reports will be used. In phase 2, these completion reports will be required in a custom format, showing products and quantities, pricing and cash collected information and images taken.

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

Sample POD Format

SCR-336832-8:

POD and POC Formats

Note: The POC format is expected to be similar to the above, replacing only the word "DELIVERY" with "COLLECTION" (and all derivatives). This change has been costed as such. If a significantly different format is required, additional cost will be generated.

Warning: It is as yet unknown whether this will be the final format of the report - this will be clarified in the phase 2 workshops.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into . The following data is required.

Page Header, expected to be displayed on every page:

Logo - The Pilgrim logo taken from the Site.
"Pilgrim Foodservice Ltd Company Reg..." - a mixture of fixed text and from the site address.
Warning: 2 unknown blank text boxes - to be confirmed.
BFFFC logo - fixed image.
Pilgrim address/contact information - from the site address.
"DELIVER TO" - the job address. Note: It is assumed that the grey box to the right of the "DELIVER TO" is related to the job address and can be sourced from there.
"INVOICE TO" - the customer account address.
"Special Instructions" - from the Job Instructions.
"Customer Tel No" - Contact telephone number from the job address.
"INVOICE AND SUPPLY DATE" - the Actual Start Date of the load.
"DELIVERY ACCOUNT" - the customer code.
"SALESMAN" - 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.
"OUR ORDER NO" - the primary reference (i.e. Job Code).
"ROUTE" - the unique load ID.
"DROP" - the sequence.
"CUSTOMER ORDER NUMBER" - the customer reference.

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

"PRODUCT CODE" - the product code
"BIN LOCATION" - Warning: Not supported in the system and expected to be removed.
"PRODUCT DESCRIPTION" - The product description.
"CASE SIZE" - the pack size. Note: This data cannot be provided by the ERP through the CSV interface.
"CASES" - product cases. Note: This data cannot be provided by the ERP through the CSV interface.
"SINGLES" - calculated from the quantity and the case quantity. Note: This data cannot be provided by the ERP through the CSV interface. Only a total quantity can be specified.
"UNIT PRICE" - the unit nett price. Note: This data cannot be provided by the ERP through the CSV interface.
Warning: Blank column - requires confirmation. Assuming Unit VAT cost. Note: This data cannot be provided by the ERP through the CSV interface.
"TOTAL" - calculated as unit price and VAT price multiplied by the total quantity. Note: This data cannot be provided by the ERP through the CSV interface.
"VAT CODE" - not present in CALIDUS ePOD - required change.

Footer, expected to be shown on all pages:

"PLEASE CHECK..." - The text from the T&Cs against the job.
"ORIGIN" - Warning: not supported by CALIDUS ePOD and expected to be removed in the final format.
"PICKER" - Warning: not supported by CALIDUS ePOD and expected to be removed in the final format.
"CHECKER" - Warning: supported by CALIDUS ePOD and expected to be removed in the final format.
"No OF CONTAINERS" - Warning: supported by CALIDUS ePOD and expected to be removed in the final format.
"DRIVER SIGNATURE" - the driver signature, captured by the driver. Note: This section will be larger in the final format, to allow for the electronic signature to be fully displayed. If not captured, will be replaced with a "NO SIGNATURE" placeholder.
"TIME OF DELIVERY" - the actual end time of the delivery.
"GOODS RECEIVED IN FULL AND GOOD CONDITION" - either fixed text for a delivery job or part of the T&Cs.
"Customer Signature" - the customer signature, captured by the driver. Note: This section will be larger in the final format, to allow for the electronic signature to be fully displayed. If not captured, will be replaced with a "NO SIGNATURE" placeholder.
"Customer Printed Name" - the signatory name, confirmed or entered by the driver at customer signature. Note: If not captured, this will be blank.
"Date" - the actual end date of the job.
"VAT ANALYSIS" - a summary of all the tax codes, rates, taxable status and total tax for items on the order. Note: This data cannot be provided by the ERP through the CSV interface.
Warning: Blank box under VAT ANALYSIS - requires confirmation.
VISA logo, "A/C", "SORT"- fixed text.
"TOTAL GOODS" - Total of calculated total unit nett costs for products. Note: This data cannot be provided by the ERP through the CSV interface.
"VAT" - Total of calculated VAT costs for products. Note: This data cannot be provided by the ERP through the CSV interface.
"TOTAL DUE" - The calculated total gross costs for products. Note: This data cannot be provided by the ERP through the CSV interface.
"RECEIPT" - "CASH" and "CHEQUE" - From Job Details UDF or T&Cs.
"TERMS AND CONDITIONS OF TRADING" - Fixed text or part of the T&Cs.

Note: The system is expected to be configured so that, for Cash/Cheque On Delivery, that the cash/cheque provided will be confirmed through the T&Cs or through Job Details UDF, prompting for the value received at the point of delivery.

Warning: It is not possible to identify the VAT Code against the products. If this is required, an additional change will be required to allow this to be specified, and to identify the code and rate in the system, for displaying on the POD note. This requirement will be clarified in the phase 2 workshop.

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. It is expected that in phase 2, outbound integration to the ERP will be performed using this standard OBSL XML export, expected to be through FTP rather than Webservices - this will be confirmed during the phase 2 workshop.

The following section shows the capability of the CALIDUS ePOD 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.

Completion Report (i.e. POD, POC, Service Report) emails may be sent from the CALIDUS ePOD server once a job is marked as complete. Emails can be sent to job- or customer-specific email addresses or to central site email addresses. The reports can either be embedded in the email or attached as a PDF through configuration.

To send emails to job-specific email addresses, the email address must be present on the job or the customer for that job. If the system is configured to send emails, and the job or customer is configured with an email address, an email will be sent for both collections and deliveries.

In either case, multiple email addresses may be specified Note: When configuring multiple emails, they may be separated with the email server's separation character, which is usually a comma or a semi-colon. This is dependent on the email server that CALIDUS ePOD is configured to use.

Note: This feature requires access to a mail server.

Customer Email subject and body may be configured - the main areas are:

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)

Site email will always have the subject and body as follows:

Subject: "{Job Type}:{Job ID}:{Job Code}"
Body (if PDF): "Please find attached your delivery documentation, Thank You"

Note: It is expected that this functionality will not be enabled in phase 1. It is expected that some emailing of PODs will be required in phase 2. Automatic Email functionality

Note also that the CALIDUS Portal Track and Trace module may be used to generate customer emails 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

Further to this, Pilgrim have requested to use QuickView reporting tools against the CALIDUS ePOD database, utilising this for read only with limited permissions and visibility. As the system will be hosted by Pilgrim, there are no technical restrictions on accessing the data, as long as it is reasonable, restricted and as recommended. If guidelines are not followed, reporting access such as this may affect the smooth running of CALIDUS ePOD and any other system running on the machine with the database, or using the database.

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

It is expected that the system will be used in customer services and transport, to answer customer tracking enquiries.

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 for phase 1.

It is expected that ETAs will be shown on the Portal - this functionality requires the purchase of a Nokia Maps account. This is an additional cost which should be accounted for.

The CALIDUS Portal system allows configuration of the layout, information displayed and selection criteria prompted for. This will be decided in further meetings and configured at implementation stage.

Note: Optional developments to the product suite (i.e. CALIDUS ePOD and Portal) for other customers may include the facility to identify multiple delivery windows against a job. If this development is completed, and the ERP is capable of interfacing this information and strongly planning the deliveries, the CALIDUS Portal screens will allow configuration as to whether this information is used to identify late or exception deliveries.

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

The primary search/filter will be through the customer and date to find the deliveries, although many more criteria may be entered.

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.

The RAG colouration is based on the planned start date and time (i.e. not the planned end or departure date and time, and not a window).

Note: It is recognised that the ERP and planning solutions may specify only a window for the deliveries. For lateness and ETA functionality in CALIDUS TTM to function correctly (which measures against the planned arrival time), the CALIDUS ePOD Start Planned Date and Time should be set as the end of the window when jobs are sent to the system.

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: This screen will be used to monitor those jobs (collection and delivery) that have exceptions (i.e. were not collected/delivered in full or late). The filter menu on this screen allows the user to define the orders to be reported, entering date/time from/to, and selecting the types of exceptions to be shown, therefore removing all normally completed jobs from the screen.

Vehicle/Driver GPS Tracking

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 pop-up message.

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

Consignment Tracking

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

The screen displays:

The Order Status of the order being checked, which may be one of several items, based on how the systems are being used:
- Ordered.
- 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.