View source for REQ 324746 Cooper Callas ePOD Requirements

<div class="noprint">
{{#vardefine:Client|COO}}
{{#vardefine:ClientName|Cooper Callas}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Cooper Callas ePOD Requirements}}
{{#vardefine:Version|3.0}}
{{#vardefine:Date|7th August 2015}}
{{#vardefine:Reference|324746}}
{{#vardefine:Year|2015}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

<!-- TOC --> 
<div class="noprint">
= Introduction  =
<!-- The introduction will detail the initial requirements supplied by the client -->
This document is the {{#var:Doc_Title}}.

== Objective  ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 29/01/2015 at the Cooper Callas office in Bicester.

<!-- List all amendments to the requirements here, and reference in final section, e.g. The document also encompasses the follow-up meeting held at X, with Y and Z attending, where the requirements were modified. See the minutes of the meeting referenced as item X in appendix B --> 

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

<!-- 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.
* 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 }}
<!-- NEW PAGE --> 

= Client Requirements =
Listed below are the proposed processes that will be followed by the operatives using {{#var:System}}. Also shown are the SCRs required for this to be achieved. 

<!-- Any standard processes should be referenced here and in the references section -->

== 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 ({{#var:System}}) 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 {{#var:System}} (trigger to be defined)
*	{{#var:System}} sends driving instructions to TomTom on demand.
*	{{#var:System}} 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 {{#var:System}} client application and the built-in TomTom navigation. There will also be some use of TomTom.WEBFLEET for vehicle tracking purposes, although {{#var:System}} 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 {{#var:System}} 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 {{#var:System}}. 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, {{#var:System}} 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 {{#var:System}} 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 {{#var:System}} 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 {{#var:System}}, but it falls to OBS Logistics to specify and control the modifications to external systems.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=ePOD-Sage Integration meetings and specification.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


There are additional interfaces to {{#var:System}} 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 {{#var:System}}, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in {{#var:System}}, 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 {{#var:System}} 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, {{#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: Table of SCRs and Ballpark Estimates|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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Create customer-specific style on device.
|Link=Appendix A: Table of SCRs and Ballpark Estimates 
}}

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 {{#var:System}}.


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 {{#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''
</gallery><br />

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 {{#var:System}} 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 {{#var:System}}. No change to this is expected as part of this project. 
*	CSV Export of Vehicle checks is obtained through the {{#var:System}} 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.

<gallery widths=310px heights=400px perrow=3>
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:
* 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. 

<gallery widths=310px heights=400px perrow=3>
File:REQ_312105_3.PNG|''Job Details''
</gallery><br />

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:
<gallery widths=310px heights=400px perrow=3>
File:REQ_312105_4.PNG|''Job Details 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.


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 {{#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 


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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Consolidation on device to consolidate products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}


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 {{#var:System}}, where driver signatures can be enabled or disabled for collections or deliveries. 


All jobs will be sent to the {{#var:System}} 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. 
<gallery widths=310px heights=400px perrow=3>
File:REQ_312105_8.PNG|''Customer Signature form''
</gallery><br />

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|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Clausing of products at Signature
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

[[file:REQ_324746_POD.PNG|border|600px]]
<br />''Sample POD Format''<br />

[[file:REQ_324746_POC.PNG|border|600px]]
<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). 

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 and Ballpark Estimates
}}


== Data Export ==
When jobs have been completed all the job is updated in the {{#var:System}} 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 {{#var:System}} 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 {{#var:system}}. 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|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 and Ballpark Estimates 
}}

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 {{#var:System}} 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 ====

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


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.

[[file:REQ_324746_TTM_Gateway_Signature.PNG|border|600px]]
<br />''Gateway - Consignment Signature''<br />




<!-- MEDIA LANDSCAPE YES --> 

= Appendix A: Table of SCRs and Ballpark Estimates  =
<!-- If there’s only one system being discussed here, the system column can be removed.
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
The description should be the description from the text in the main sections. 
The Notes column can be used for many things: grouping optional changes, showing whether the client or OBS originated the gap, etc. -->

{{ #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=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=1|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 (10d)
}} {{REQ_SCR_Line
|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=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=POD and POC formats|Estimate=7|Notes=
}} {{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=3|Notes=
}} {{REQ_SCR_Footer}}


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.

<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD
|Ref1=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=3.0
|RefDate1=16/10/2014
|Ref2=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=4.0
|RefDate2=16/10/2014
|Ref3=[http://172.198.45.54/calidus-assist/EPOD/index.php/FS_291096_Interface_with_CALIDUS_ePOD FS 291096 Interface with CALIDUS ePOD]
|RefV3=1.0
|RefDate3=05/02/2015
|Ref4=Portal User Guide - LOTS
|RefV4=6.4w
|RefDate4=19/09/2014
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Philip Carr
|Rev1Title=Cooper Callas
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div> 
[[Category:{{#var:Client}} REQ]]