Latest revision as of 14:36, 7 August 2015

Cooper Callas

Cooper Callas ePOD Requirements

CALIDUS ePOD

7th August 2015 - 3.0
Reference: REQ 324746

Introduction

This document is the Cooper Callas ePOD Requirements.

Objective

The primary purpose of this document is to document the requirements gathered from Cooper Callas, on 29/01/2015 at the Cooper Callas office in Bicester.

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

The changes will be made in the latest version of the CALIDUS ePOD system, operating the Android version of the ePOD Client application.
Changes relating to information passed through to CALIDUS ePOD from external systems (i.e. Sage) 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

The operation deals with Bathroom deliveries and returns, with stock picked directly from the Bicester warehouse and delivered all over the country.

The business is £30m turnover
Change of management late 2014.
Recently installed new racking
All new vehicles in the fleet
All new uniforms
41 TomTom devices in vehicles now.
There are 800-900 order per day (not including returns)
Both the project and the business are owned by Philip Carr

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

Orders come into Sage.
Sage interfaces the orders to DPS, for Routing purposes, then back to Sage
These systems co-ordinate the picking of the stock for the orders, as well as stock levels.
Sage interfaces routes and orders to CALIDUS ePOD (trigger to be defined)
CALIDUS ePOD sends driving instructions to TomTom 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 the CALIDUS ePOD client application and the built-in TomTom navigation. There will also be some use of TomTom.WEBFLEET for vehicle tracking purposes, although CALIDUS ePOD will not directly communicate with this system - all tracking information will be taken by TomTom directly from it's installed devices.

Project Implementation:

Sage is expecting to implement beginning of March, whereas the customer is expecting to implement the middle of February latest.
DPS implementation is awaiting finalisation of Sage interface before implementation dates are confirmed.
Philip Carr is the project leader and should be mainly contacted by email.

External System Processing

Orders are received via Telephone, Fax and Email and keyed into Sage.

The Order cut-off is 1730, which is when the orders are released to DPS for routing.

DPS routes these orders, giving a delivery window.

Typically orders are received Day 1 for Day 2 delivery.

Note: Some customers do not have agreed deliveries every day - so for example, if they accept delivery Tuesday or Thursday, orders may be day 1 for day 3 - in this case, orders are only released to CALIDUS ePOD on the days that they are required.

Once orders are entered, an order acknowledgement is sent back to the customer, with:

Expected Time
Price
Confirmation of Qty of Products

DPS routes the orders, and a pick and pack manifest is provided for the warehouse staff.

Orders are split into Part Pick and Bulk Pick orders.

Orders that have finished picking are updated within Sage.

Regarding Pick Shortages:

All efforts are made to ensure that any shortages at pick are resolved before the order is sent to ePOD, within DPS/Sage.
All shortages that can't be resolved at picking should go on back order, within Sage.

Product Returns (Collection jobs) will be created within Sage based on customer calls and an order created in the same way as deliveries.

Note: There is some question regarding the exact processing flow within Sage, regarding a two-stage despatch confirmation within Sage. Regardless, at one of these stages (when all picks are complete and loaded), Sage will initiate the sending of Load and Order information to CALIDUS ePOD. The exact trigger point must be confirmed, but is part of the Sage functionality and does not affect OBS Logistics' systems processing.

Note: Sage/DPS provides a load manifest, used to manually load the goods onto the device in reverse order. it is noted that, in a potential future phase, CALIDUS ePOD may be used to load the vehicles. This is of interest to the customer, but not at this time and is out of scope of this project.

Data Import

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.

There will need to be at least two Job Group configurations:

Deliveries
Returns

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.

The exact confirmation of the Job Group configuration will be decided at implementation stage.

Some deliveries require a single photo taken of the delivery anyway - this will be achieved through Job Photo functionality (which requires a photograph after signature). Some deliveries will require this enforced:
- Deliveries direct to customers
- Repeat Return Offenders
Return orders will be configured differently to deliveries, in that a cancelled or changed quantity against a product will force an image to be taken.

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 (deliveries/returns) include:

Job Instructions - the customer wants this, but it depends on what information can be extracted from Sage. Specifically, the customer referred to 'D' codes (D or DI), which would be used as delivery instructions, which must be mapped.
Product Codes consist of <Manufacturer> <Product Type> <Range> <additional Information>. This needs to be mapped into Description and Long Description fields from Sage. Also, the lengths of the individual fields will need dealing with (Code 40, Description 40, Long Description 255).
Product quantities regarding Ordered and Planned Delivered quantities are required.
Customer Details:
- The addresses shown on the POC and POD Notes 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). Sage has a complication in that all depot addresses are part of a single account address and this may not be accessible for the job - this must be confirmed by Sage.
- Email addresses are required for the customers requesting returns, so that POC notes may be immediately emailed to them upon confirmation of collection.
- Contact Number - Initially, it is expected that Sage map no contact number on the jobs sent to ePOD. Regardless, the customer does not want drivers directly contacting customers through the devices, by phone or SMS. It was noted that a central phone number may be provided on the jobs from Sage, so that the driver may easily contact base.
Consolidation - When delivering orders, there could be up to 10 deliveries per address (for deliveries to depots rather than end customers). Consolidation of orders at delivery/collection is required. This may be controlled manually by the driver, but is more commonly controlled by the jobs being linked together on the Route received by ePOD from Sage.
An Owner must be specified against each job. It is expected that this will be the same for all jobs and will be agreed during the mapping exercise.

Note: OBS Logistics have created standard Interfacing documentation and passed this to Sage. 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-324746-1:

ePOD-Sage Integration meetings and specification.

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

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 Sage 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 and a client application for use 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 ePOD administration software is a web-based application that handles all of the administrative side of the 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.
To view the Jobs and Loads created.
To print or email a POD.

Note: If loads are not assigned to Drivers or Vehicles through the Sage interface, 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

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

The application will haver a customised style created for Cooper Callas, which will include:

An appropriate colour scheme
The logo on the login page.
All Text entry fields forcing upper-case text.

SCR-324746-2:

Create customer-specific style on device.

Additionally, the layout of certain on the tables and test labels may be modified if required, and confirmed before development begins on the project work.

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 logs on to a device using their 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.

Vehicle Checks

When log-in is complete, the device will prompt the driver for the vehicle checks required. The content and frequency of these checks is user-configurable, from the CALIDUS ePOD Admin system. This will be changed to allow configuration of the Vehicle Checks to be completed at the end of the Load as well as at the start.

Vehicle Checks Sample

Vehicle checks would normally be configured to be run daily. An example of some vehicle defect check questions follows:

Oil Level (wear gloves)
Water Level
Lights
Indicators
Wipers/Washers
Windscreen
Tyres
Wheel Nuts
Air/Fluid Leaks (wear gloves)
Wings/Body Parts
Steering
Tachograph
Mirrors
Warning Lights/Buzzers
Brakes
Horn
Road Tax/O License
Load Security and Safety
Internal Straps
External Straps
Rope
Accident Damage

All questions are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Alternatively, these checks could be optional text entry for each check above, to capture any defects, or a combination of the above.

Note: Vehicle checks must be completed before the user is allowed to continue - there will not be an option to postpone Vehicle Checks.

Note: Completed vehicle checks can be viewed through the CALIDUS ePOD Admin screen, which also allows some selection criteria (by vehicle, user and date). These completed vehicle checks can also be exported, either by request through a web service request, or automatically exported. Both methods export the completed vehicle checks in a standard XML format.

No signature is prompted for by the device during vehicle checks - the user name and password will have already ensured that the user is tagged as the checker at this time.

Note: The Vehicle checks prompted for are the same for all vehicle types. If some questions are not applicable to some vehicle types, the question may be configured to be optional and/or have a "N/A" answer attached to them that the driver may select.

Some notes on the process for Cooper Callas:

The customer is interested in completing these.
The customer requested photographs of damage against a vehicle pertaining to certain questions. It is confirmed that this is not possible within CALIDUS ePOD. No change to this is expected as part of this project.
CSV Export of Vehicle checks is obtained through the CALIDUS ePOD Vehicle Checks Responses Admin screen.

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 Sage
- Cust Ref - as mapped from Sage
- SO Ref - as mapped from Sage
- Ext Ref - as mapped from Sage
Job Type - Collection/Delivery
Customer Name
Postcode
Planned Date/Time
Product Count (subtotalled quantity of all items on the job)

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 re-sequencing is 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, for example, if DU quantities have been entered or amended.

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.

As a change to this process, the customer required that an image must be taken when cancelling a job. When delivering direct to a customer's home, if the delivery is cancelled (because they are unable to get a response from the customer at the address), the drivers require the ability to take a photo of the front door. The system will not be changed to enforce this - the photo is optional at the driver's discretion.

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.

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.

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.

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.

The screen allows the user to contact the customer (through text or phone).

Note: The existing configuration of the TomTom 8xxx devices does not allow telephony. It is noted that the cradles may have a microphone built in, and therefore this may be allowed in the future. It is further noted that the SMS/Phone buttons within the device are not shown if there is no contact phone number provided.

Initially, it is expected that Sage map no contact number on the jobs sent to ePOD.

Regardless, the customer does not want drivers directly contacting customers through the devices, by phone or SMS. A central phone number may be provided on the jobs from Sage, to allow the driver to easily contact base.

Note: It was queried whether SMS be forwarded as an email to a central account - this is not a function of the devices, ePOD Server or the application on the device, this is a function provided by an SMS service provider at a cost, and should be investigated as a separate project if required, with another vendor.

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

If there have been instructions provided on the Job, 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 not allowed by the driver. If a job is attempted to be started out of sequence, the user will be told this at this point.

When a Job is successfully started, this will take the Job to 'In Progress' status.

Jobs can be cancelled by the driver at this time by clicking the Cancel Job button. 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: Changes to Job Cancellation imaging (i.e. whether an image is required at job cancellation) apply here.

The screen allows the user to navigate to the customer's address (available only after choosing to start the job).

The device will use any navigation application installed on the device for this navigation. It is expected that this will be through the TomTom navigation application.

Once the user arrives as the destination, they can indicate this and start processing the Job by clicking the Arrive Job button.

When confirmed complete, the device will move on the the Delivery or Collection process, depending on the job type.

Delivery Process

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

Job Details Tab
Products Tab

Note: There is an optional User Notes tab that can be displayed, allowing the user to enter any notes against the Job before completion.

The Job Details tab has multiple sections:

Contact information
Address information - if supplied, both current address and origin address are shown.
Job Instructions

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

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

It is expected that, as part of the styling process, the layout of this table will be modified (i.e. elements removed, or resized). The data displayed is dependent on the information passed to CALIDUS ePOD from Sage. 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.

SCR-324746-3:

Consolidation on device to consolidate products.

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

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

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

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. This will allow entry of quantity, and will display the unit type, for clarification. The product description will also be displayed here.

If a product can't be found on the vehicle, 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 why.

Note: During this exception process (either quantity change or product cancellation), the user will have the facility to take a photo against the product changed, but this is optional. Note that this is optional at the driver's discretion, rather than depending on the reason code selected by the driver.

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

Note: During discussions, the customer felt that the cancellation or changing of quantities was too easy for the driver to complete. The driver must take care to obtain all items and ensure that the quantities are correct before confirming delivery. No change of the system will be undertaken to enforce this.

Collection (Returns) Process

The collection process will be almost identical, except in this case, only the products require to be collected will be displayed on the Product tab.

If not all of a product can be collected, or more is to be returned, the Change Quantity option may be used to identify the amount actually collected.

If a product cannot be collected, the Cancel option may be used to remove the item.

Differently to Deliveries, an image must be taken with these changes - the jobs will be configured to require an image be taken.

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

Note: At this time, the expectation is that the configuration will require the Driver and 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.

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

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

All of these processes are controlled during Job Completion.

The device will first prompt for Customer Signature.

Customer Signature form

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 check boxes the user is required to confirm. These are configurable.
The products and quantities 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 the signature). Unlimited T&Cs text can be configured, along with 3 potential check-boxes. This may be configured at any time.

Note: Customer signature is required for all job types.

When the customer signature is entered and confirmed, the device will prompt for Driver Signature. The signature screen is extremely similar to the Customer Signature, but the Driver name is fixed, and the tabbed area is left blank.

Note: Driver signature is required for collections only.

Note: The below SCR (#4 Clausing of products at Signature) has been cancelled and is not in scope of this project as the customer advises this is not required. The details remain in the document just for reference

If products are accepted but the customer wishes to note that the delivery may be queried later, they can enter clause text against specific products.This functionality will be modified to work with products rather than single delivery items.

SCR-324746-4:

Clausing of products at Signature

The driver or user may click the product in the grid, and a pop-up will be displayed, allowing the user to enter clause information. When saved, the Product tab will be redisplayed, showing as the status that the product is claused, and colouring the text.

The PDA will be configured for certain jobs for Job Photo Capture. Some jobs will require this enforced:

Deliveries direct to customers
Repeat Return Offenders

When configured for this, the PDA will start the Photo Capture dialogue after all signatures have been captured. If prompted for this, this is expected to be a required process (the driver will not be allowed to skip this). The driver will be able to view the captured image or re-take the photo.

Note: It is possible to configure the device so that this Job Image is prompted for (but not required) for other jobs types.

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.

Post-Load

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

At this time, if configured to do so, the device will be changed to prompt the user to enter vehicle checks again.

SCR-324746-5:

Vehicle checks at end of load in addition to start of load.

The vehicle checks prompted for will be the same checks as were prompted at the start of the load. The system will always prompt for the load end vehicle checks, regardless of how frequently the vehicle checks have been completed. The driver will be forced to enter the vehicle checks before continuing.

Once complete, 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 final formats have been provided and are shown below.

Sample POD Format

Sample POC Format

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

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

The quantity remaining column will be calculated from the Ordered Quantity minus the Actally Delivered Quantity.

SCR-324746-6:

POD and POC Formats

Data Export

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

All shortages at delivery (i.e. when CALIDUS ePOD cancels or changes the delivered quantity of an item) may go on back order - this depends on the reason for the quantity change.
All cancelled collections/deliveries (i.e. the driver cancels the job) should be manually rebooked within Sage - the interface back to Sage must be confirmed, and this must be handled by the Sage interface.

There are no expected changes to the existing export format or methodology. The information regarding this has been forwarded to the Sage 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.

These emails are sent with a fixed email subject and body. As an additional change, the customer asked for this to be configurable.

SCR-324746-7:

Auto-email subject and body text to be configurable

The expected data in these should be made up from:

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

Once this development is complete, it will be configured for the customer during implementation. This has been confirmed to be:

"Cooper Callas - <Delivery> to <Customer Name> - <Order Reference> on <Date>"

At this time, the emails sent have the following text applied to them:

Subject (for the customer): "Cooper Callas: POD for Order: (Job ID) on HHMM YYYYMMDD"
Subject (for the central email): "Collection/Delivery: (Job ID): (Job Code)"
Body Text (for PDF Attachments): "Please find attached your delivery documentation, Thank You."

Further Reporting and Queries

The CALIDUS ePOD Admin system allows admin users (i.e. non-PD users) the ability to access loads, jobs and product details, as mentioned previously.

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

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 Cooper Callas 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 (Non-compliance Report) is to be able to export details of all 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 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.

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

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	Sage	Integration	ePOD-Sage Integration meetings and specification.	4.00
2	ePOD	Look and Feel	Customer Styling of the PDA device application.	1.00
3	ePOD	Consolidation	Consolidation on device to consolidate products.	0.00	^{OBS cost (10d)}
4	ePOD	Signature	Clausing of products at Signature - CANCELLED	0.00	^{OBS cost (2d)}
5	ePOD	Reporting	Vehicle checks at end of load in addition to start of load.	4.00
6	ePOD	Reporting	POD and POC formats	7.00
7	ePOD	Reporting	Auto-email subject and body text to be configurable	3.00

Notes:

Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.

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 - LOTS	6.4w	19/09/2014

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

Philip Carr	Cooper Callas	_____________________________
Matt Turner	OBS Logistics	_____________________________

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' ePOD}}
 {{#vardefine:Doc_Title|Cooper Callas ePOD Requirements}}
-{{#vardefine:Version|0.1}}
+{{#vardefine:Version|3.0}}
-{{#vardefine:Date|27th February 2015}}
+{{#vardefine:Date|7th August 2015}}
 {{#vardefine:Reference|324746}}
 {{#vardefine:Year|2015}}
@@ Line 36: / Line 36: @@
 <!-- ANY scope or limitations, bulleted. -->
-*The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the ePOD Client application.
+* The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the ePOD Client application.
+* Changes relating to information passed through to {{#var:System}} from external systems (i.e. Sage) 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.
 <!-- ANY other systems? e.g. does this link to TTM, WMS, 414, 770, etc? -->
 {{ #vardefine: SCR | 0 }}
@@ Line 125: / Line 126: @@
 If Job Groups are sent to {{#var:System}} that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration.
-{{Warning}} The exact confirmation of the Job Group configuration will be added to this document at a later stage.
+The exact confirmation of the Job Group configuration will be decided at implementation stage.
 * Some deliveries require a single photo taken of the delivery anyway - this will be achieved through Job Photo functionality (which requires a photograph after signature). Some deliveries will require this enforced:
 **	Deliveries direct to customers
@@ Line 134: / Line 135: @@
 The Jobs and Loads themselves will be interfaced with the data required to complete the jobs. This will be mapped outside of this document.
-{{Warning}} Details for each job type (deliveries/returns) to be included here. Including:
+Details for each job type (deliveries/returns) include:
 * Job Instructions - the customer wants this, but it depends on what information can be extracted from Sage. Specifically, the customer referred to 'D' codes (D or DI), which would be used as delivery instructions, which must be mapped.
 * Product Codes consist of <Manufacturer> <Product Type> <Range> <additional Information>. This needs to be mapped into Description and Long Description fields from Sage. Also, the lengths of the individual fields will need dealing with (Code 40, Description 40, Long Description 255).
@@ Line 150: / Line 151: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=ePOD-Sage Integration meetings and specification.
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 180: / Line 181: @@
 * To view the Jobs and Loads created.
 * To print or email a POD.
 {{Note}} If loads are not assigned to Drivers or Vehicles through the Sage interface, {{#var:System}} 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.
+[[file:EPOD_Users2.PNG|border|600px]]
+[[file:EPOD_LoadAssign1.PNG|border|600px]]
+<br />''Assigning a User to Loads''<br />
+[[file:EPOD_Load2.PNG|border|600px]]
+[[file:EPOD_Load3.PNG|border|600px]]
+<br />''Assigning Loads to a user''<br />
 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:_Quote_.26_Document_References|Appendix A]].
+A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].
@@ Line 198: / Line 209: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=Create customer-specific style on device.
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 211: / Line 222: @@
 == Vehicle Checks ==
-When log-in is complete, the device will prompt the driver for the vehicle checks required. The content and frequency of these checks is user-configurable, from the {{#var:System}} Admin system.
+When log-in is complete, the device will prompt the driver for the vehicle checks required. The content and frequency of these checks is user-configurable, from the {{#var:System}} Admin system. This will be changed to allow configuration of the Vehicle Checks to be completed at the end of the Load as well as at the start.
 <gallery widths=310px heights=400px perrow=3>
-File:REQ_312105_1.PNG|Vehicle Checks Sample
+File:REQ_312105_1.PNG|''Vehicle Checks Sample''
 </gallery><br />
@@ Line 247: / Line 258: @@
 No signature is prompted for by the device during vehicle checks - the user name and password will have already ensured that the user is tagged as the checker at this time.
+{{Note}} The Vehicle checks prompted for are the same for all vehicle types. If some questions are not applicable to some vehicle types, the question may be configured to be optional and/or have a "N/A" answer attached to them that the driver may select.
@@ Line 259: / Line 272: @@
 <gallery widths=310px heights=400px perrow=3>
-File:REQ_312105_2.PNG|Job List
+File:REQ_312105_2.PNG|''Job List''
 </gallery><br />
+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 Sage
+**         Cust Ref - as mapped from Sage
+**         SO Ref - as mapped from Sage
+**         Ext Ref - as mapped from Sage
+*  Job Type - Collection/Delivery
+*  Customer Name
+*  Postcode
+*  Planned Date/Time
+*  Product Count (subtotalled quantity of all items on the job)
 The screen will display the status of the jobs on the load through a coloured outline, as follows:
@@ Line 291: / Line 319: @@
 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.
-As a change to this process, the customer required that an image must be taken when cancelling a job. When delivering direct to a customer's home, if the delivery is cancelled (because they are unable to get a response from the customer at the address), the drivers require the ability to take a photo of the front door - enforced only on Job Cancellations.
+As a change to this process, the customer required that an image must be taken when cancelling a job. When delivering direct to a customer's home, if the delivery is cancelled (because they are unable to get a response from the customer at the address), the drivers require the ability to take a photo of the front door. The system will not be changed to enforce this - the photo is optional at the driver's discretion.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+{{Note}} The system may be configured for Image Capture in the following ways:
-|Definition=Enforced Image Capture on job only.
+* Force Image Capture at all times when cancelling or changing quantity (i.e. at Job and Detail level)
-|Link=Appendix A: Table of SCRs
+* 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.
@@ Line 315: / Line 343: @@
 <gallery widths=310px heights=400px perrow=3>
-File:REQ_312105_3.PNG|Job Details
+File:REQ_312105_3.PNG|''Job Details''
 </gallery><br />
@@ Line 369: / Line 397: @@
 The following are the standard tabs that are expected to be displayed:
 <gallery widths=310px heights=400px perrow=3>
-File:REQ_312105_4.PNG|Job Details Tab
+File:REQ_312105_4.PNG|''Job Details Tab''
-File:REQ_312105_5.PNG|Products Tab
+File:REQ_312105_5.PNG|''Products Tab''
 </gallery><br />
 {{Note}} There is an optional ''User Notes'' tab that can be displayed, allowing the user to enter any notes against the Job before completion.
@@ Line 389: / Line 417: @@
 *    The Item Type
 *    The Unit Type
-It is expected that, as part of the styling process, the layout of this table will be modified (i.e. elements removed, or resized).
+It is expected that, as part of the styling process, the layout of this table will be modified (i.e. elements removed, or resized). The data displayed is dependent on the information passed to {{#var:System}} from Sage. It is expected to be:
+*    The Product Code
+*    The full Description
+*    Any Customer Reference associated to this product
+*    The Planned Quantity
@@ Line 396: / Line 428: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=Consolidation on device to consolidate products.
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 418: / Line 450: @@
-{{Note}} During discussions, the customer felt that the cancellation or changing of quantities was too easy for the driver to complete. To achieve this, a modification may be made to existing functionality (Two-Stage Delivery) to allow it to work with Product quantities.
+{{Note}} During discussions, the customer felt that the cancellation or changing of quantities was too easy for the driver to complete. The driver must take care to obtain all items and ensure that the quantities are correct before confirming delivery. No change of the system  will be undertaken to enforce this.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Two-stage delivery to work with products
-|Link=Appendix A: Table of SCRs
-}}
-Essentially, this allows the driver to come back to this product confirmation process after completion, to amend quantities or uncancel items, if desired. In this case, all products are displayed, showing the status of the product, allowing modifications through pressing the line.
@@ Line 455: / Line 480: @@
 The device will first prompt for Customer Signature.
 <gallery widths=310px heights=400px perrow=3>
-File:REQ_312105_8.PNG|Customer Signature form
+File:REQ_312105_8.PNG|''Customer Signature form''
 </gallery><br />
@@ Line 467: / Line 492: @@
 The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with 3 potential check-boxes. This may be configured at any time.
+{{Note}} Customer signature is required for all job types.
 When the customer signature is entered and confirmed, the device will prompt for Driver Signature. The signature screen is extremely similar to the Customer Signature, but the Driver name is fixed, and the tabbed area is left blank.
+{{Note}} Driver signature is required for collections only.
-Once the Job Completion process has finished, the job will then be sent back to the {{#var:System}} server for completion, where all entered data, signatures and images will be stored and the job marked as complete. The user will be returned to the Job List screen and the Job will be removed from the list.
+{{Note}} The below SCR (#4 Clausing of products at Signature) has been cancelled and is not in scope of this project as the customer advises this is not required. The details remain in the document just for reference
 If products are accepted but the customer wishes to note that the delivery may be queried later, they can enter clause text against specific products.This functionality will be modified to work with products rather than single delivery items.
@@ Line 479: / Line 507: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=Clausing of products at Signature
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 490: / Line 518: @@
 *	Repeat Return Offenders
 When configured for this, the PDA will start the Photo Capture dialogue after all signatures have been captured. If prompted for this, this is expected to be a required process (the driver will not be allowed to skip this). The driver will be able to view the captured image or re-take the photo.
+{{Note}} It is possible to configure the device so that this Job Image is prompted for (but not required) for other jobs types.
 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.
 == 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.
+Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.
+At this time, if configured to do so, the device will be changed to prompt the user to enter vehicle checks again.
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+|Definition=Vehicle checks at end of load in addition to start of load.
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
+}}
+The vehicle checks prompted for will be the same checks as were prompted at the start of the load. The system will always prompt for the load end vehicle checks, regardless of how frequently the vehicle checks have been completed. The driver will be forced to enter the vehicle checks before continuing.
+Once complete, 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 despatched (possibly ordered) vs delivered and should show all product lines on the order, whether they are cancelled or not.
+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.
-For the POC format - 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.
+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. However, the final format has not yet been defined. Additionally, the POC format may be significantly different.
+The format of the POD note has been prototyped to show capability. The final formats have been provided and are shown below.
+[[file:REQ_324746_POD.PNG|border|600px]]
+<br />''Sample POD Format''<br />
-[[file:REQ_324746_POD.PNG|border|600px]]
+[[file:REQ_324746_POC.PNG|border|600px]]
-<br />Sample Format<br />
+<br />''Sample POC Format''<br />
 The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into {{#var:system}}.
-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). Sage has a complication in that all depot addresses are part of a single account address and this may not be accessible for the job - this must be confirmed with Sage.
+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).
+The quantity remaining column will be calculated from the Ordered Quantity minus the Actally Delivered Quantity.
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=POD and POC Formats
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 526: / Line 575: @@
 *	All cancelled collections/deliveries (i.e. the driver cancels the job) should be manually rebooked within Sage - the interface back to Sage must be confirmed, and this must be handled by the Sage interface.
 There are no expected changes to the existing export format or methodology. The information regarding this has been forwarded to the Sage consultants.
-At this time, however, it is expected that there will be no interface back to Sage, as the orders are already completed within Sage before they are interfaced to {{#var:System}}.
@@ Line 541: / Line 587: @@
 {{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |Definition=Auto-email subject and body text to be configurable
-|Link=Appendix A: Table of SCRs
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
 }}
@@ Line 547: / Line 593: @@
 *	Customer Name
 *	A/C Number
-*	Order Reference
+*	Order Reference, one of:
+**	Job ID - ePOD internal unique job reference
+**	Job Code - as mapped from Sage
+**	Cust Ref - as mapped from Sage
+**	SO Ref - as mapped from Sage
+**	Ext Ref - as mapped from Sage
 *	Date
-Once this development is complete, it will be configured for the customer during implementation.
+*	Job Type (Delivery or Collection)
+Once this development is complete, it will be configured for the customer during implementation. This has been confirmed to be:
+* "Cooper Callas - <Delivery> to <Customer Name> - <Order Reference> on <Date>"
+At this time, the emails sent have the following text applied to them:
+* Subject (for the customer): "Cooper Callas: POD for Order: (Job ID) on HHMM YYYYMMDD"
+* Subject (for the central email): "Collection/Delivery: (Job ID): (Job Code)"
+* Body Text (for PDF Attachments): "Please find attached your delivery documentation, Thank You."
@@ Line 577: / Line 635: @@
-As additional changes to the system, the user asked for Excel or CSV reports. If complete, these reports will be accessible through a Reports menu item in Admin.
+== 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.
-===Driver Activity Report===
+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.
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Driver Activity Report
-|Link=Appendix A: Table of SCRs
+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 Cooper Callas 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 ====
+[[file:REQ_324746_TTM_OrdEnqParms.PNG|border|600px]]
+<br />''Order Enquiry Parameters''<br />
+{{Note}} A requirement of the customer (Non-compliance Report) is to be able to export details of all 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:
+[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
+<br />''Order Enquiry Results''<br />
+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 ====
+[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
+<br />''Trip Enquiry Parameters''<br />
+[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
+<br />Trip Enquiry Results<br />
+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 ====
+[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
+<br />''Order Details''<br />
+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 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:
+[[file:REQ_324746_TTM_ArrDep.PNG|border|600px]]
+<br />''Arrive/Depart screen''<br />
+[[file:REQ_324746_TTM_OrderStatus.PNG|border|600px]]
+<br />''Order Status Screen''<br />
+Both screens allow the user to drill-down or expand on data to get more details, through pop-ups or further details screens.
+<!--
+=== Vehicle/Driver GPS Tracking ===
+Although primary tracking for the Cooper Callas implementation will be through TomTom.WEBFLEET, ''CALIDUS'' Portal and ''CALIDUS'' ePOD provide GPS tracking of vehicles and drivers.
+[[file:REQ_324746_TTM_GPSTrack.PNG|border|600px]]
+<br />''GPS Tracking Parameters''<br />
+[[file:REQ_324746_TTM_GPSTrackResults.PNG|border|600px]]
+<br />''GPS Tracking Results''<br />
+[[file:REQ_324746_TTM_GPSTrackMap.PNG|border|600px]]
+<br />''GPS Tracking Map''<br />
+-->
+=== 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.
+[[file:REQ_324746_TTM_Gateway_Login.PNG|border|600px]]
+<br />''Enter Consignment''<br />
+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:
+[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
+<br />''Consignment Tracking''<br />
+{{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.
-Simple CSV/XLS export showing:
-*	Logon - time
-*	Vehicle Defect Checks - time completed
-*	Load Request
-*	Job Start/Arrive/Complete
-*	Logoff - time
-{{Note}} this report cannot compare any times above with Shift Times (i.e. late starting shift, comparison of logon versus shift start times) as {{#var:System}} is not a resource management tool, and ''CALIDUS'' Portal provides order tracking - neither provide this resource management function.
-Further details of selection criteria must be provided before specification.
+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.
-===Non-compliance Report===
-{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Non-compliance Report
-|Link=Appendix A: Table of SCRs
-}}
-Simple CSV/XLS export showing every load and job that has occurred throughout the day, showing any differences, shortages, and any attached information.
+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.
-{{Note}} It has since been decided that this report is not required.
+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.
-== 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 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.
+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.
-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.
+[[file:REQ_324746_TTM_Gateway_Signature.PNG|border|600px]]
+<br />''Gateway - Consignment Signature''<br />
-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 Cooper Callas 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.
@@ Line 628: / Line 793: @@
 {{ #vardefine: SCR | 0 }}
 {{REQ_SCR_Header}}{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=3750|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=4|Notes=
-}} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Look and Feel|Description=Customer Styling of the PDA device application.|Estimate=1000|Notes=
-}} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Image Capture|Description=Enforced Image Capture on job only.|Estimate=3750|Notes=
-}} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Consolidation|Description=Consolidation on device to consolidate products.|Estimate=0|Notes=OBS cost (£9,500.00)
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Delivery|Description=Two-stage delivery to work with Products.|Estimate=10000|Notes=Optional
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Look and Feel|Description=Customer Styling of the PDA device application.|Estimate=1|Notes=
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Signature|Description=Clausing of products at Signature|Cost=0|Notes=OBS cost (£2,000.00)
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Consolidation|Description=Consolidation on device to consolidate products.|Estimate=0|Notes=OBS cost (10d)
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=POD and POC formats|Estimate=6750|Notes=
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Signature|Description=Clausing of products at Signature - CANCELLED|Cost=0|Notes=OBS cost (2d)
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=Auto-email subject and body text to be configurable|Estimate=4750|Notes=Optional
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=Vehicle checks at end of load in addition to start of load.|Estimate=4|Notes=
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=Driver Activity Report.|Estimate=3750|Notes=Optional
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=POD and POC formats|Estimate=7|Notes=
 }} {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=Non-compliance Report|Estimate=0|Notes=Not required
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=ePOD|Area=Reporting|Description=Auto-email subject and body text to be configurable|Estimate=3|Notes=
 }} {{REQ_SCR_Footer}}
@@ Line 667: / Line 826: @@
 |RefV3=1.0
 |RefDate3=05/02/2015
+|Ref4=Portal User Guide - LOTS
+|RefV4=6.4w
+|RefDate4=19/09/2014
 |REQ=0
 |EST=0

Anonymous

Search

REQ 324746 Cooper Callas ePOD Requirements: Difference between revisions