Calidus HUB - User contributions [en-gb]

SDD 366558 EBB Paper CTL Solution Design

2020-01-31T14:30:44Z

Tippingm: /* Appendix A: Table of SCRs and Ballpark Estimates */

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' Total Logistics}}
{{#vardefine:SystemCode|CTLTMS}}
{{#vardefine:Doc_Title|EBB Paper CTL Solution Design}}
{{#vardefine:Version|0.7}}
{{#vardefine:Date|27th January 2020}}
{{#vardefine:Reference|366558}}
{{#vardefine:Year|2020}}
{{ #vardefine: Figure | 0 }}{{ #vardefine: Example | 0 }}

</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 19/12/2019 at the EBB Paper office in Farnborough.



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 well as information gleaned from site visits and workshops with {{#var:ClientName}}.


* The changes will be made in the latest version of the {{#var:System}} system.
* Changes relating to information passed through to {{#var:System}} from external systems (i.e. ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
* Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.

{{ #vardefine: SCR | 0 }}

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

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

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

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

EBB Paper stocks over 30,000 tonnes (50,000+ pallets) of paper. At current prices our stock value is approximately £24 million.

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

There are 9 distribution sites/sales offices:
* Birmingham.
* Bristol.
* Farnborough.
* Glasgow.
* Hemel Hempstead.
* Manchester.
* Newcastle.
* Sheffield.
* Thurrock.

EBB Paper contacts:
* Paul Griffiths (p.griffiths@ebbpaper.co.uk) - IT.
* Rebecca Elliott (R.Elliott@ebbpaper.co.uk) - Manager.
* Shantal Liebenberg (S.Liebenberg@ebbpaper.co.uk) - Logistics
* Mark Ford - Operations.
* Terry Dixon (T.Dixon@ebbpaper.co.uk)

OBS Logistics contacts:
* Matt Tipping - Project Manager - Matthew.Tipping@obs-logistics.com
* Matt Turner - Sales/Account Manager - Matthew.Turner@obs-logistics.com
* Warren Wright - Sales/''CALIDUS'' VEhub - Warren.Wright@obs-logistics.com
* Tony Walker - Solution Design - Tony.Walker@obs-logistics.com
* Craig Hopcroft - Implementation - Craig.Hopcroft@obs-logistics.com

== Current Operational Processing ==
EBB paper currently use the following core systems:
* Great Plains ERP (GP) - order creation.
* MSA (TMS) - planning.
* ''CALIDUS'' ePOD - execution.
* ''CALIDUS'' VEhub - vehicle checks.
* ''CALIDUS'' Portal TTM - tracking.
* TomTom - navigation.

Sales Contact and sales territories are captured as part of the order entry process in GP.

Sales enter the orders (a note).

Sales could (and may) order stock from any depot but use sense i.e. attempting to order from local depots first, if the stock is unavailable, order from any other depot, checking closest first.

Opening times against delivery locations are maintained in the ERP.

Sales can void a note (for order cancellation, or if the product quantity being ordered is reduced). If additional product is ordered after a note is created, typically the user adds an additional order for the additional product.

The team do not amend orders - they either add new orders or they void the order and create a new one.

Voiding the order is always discussed by the sales operative and the warehouse and transport teams before it is voided, to prevent any issues. Typically, if the order has been loaded at any point, the order is not voided as transport has begun.

Voided orders are not exported to the planning system and are not present in the MSA view used by this planning system.

Other order types are also entered into GP. The type is indicated by the first few characters of the order number. The types are:
* RTN - Customer returns.
* INV - Customer orders.
* CAL - Call-off.
* ISTIN - Stock transfer between depots.
* XINV - supplier-delivered orders - not part of the transport operation and therefore are to be ignored.
* COMP - Customer complaint return.

Customer return order are always entered for movement back to the nearest depot. Once they are returned, the operation evaluates the product on the order:
* If it is stored at this location, it may stay there, regardless of where it originally came from.
* If not, a product transfer order is created to move the product through the trunk network to a depot that does store that product.

Orders in GP are indicated as to whether they are customer collect (i.e. a desk job at a depot).

The orders are then planned in the existing planning system.

The usual cut-off for orders is 1800 for radial deliveries.

The current process uses zonal delivery routes. So, deliveries from each depot are routed through the trunk network through a series of 'cross-dock paths' i.e. If this order starts at depot A and is to be delivered in zone Z, it must be trunked through depots B and C first.

EBB Paper have provided the trunk network plan, as follows:
<gallery widths=300px heights=450px perrow=2>
Image:REQ_366558_Trunk1.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Southern trunk routes}}
Image:REQ_366558_Trunk2.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Northern trunk routes}}
</gallery>

{{Note}} Subsequent to this, confirmation has been received from the customer confirming all of the cut-off and departure/arrival times of all routes. Additionally, the Sheffield trunk routes have changed times.

When at the final depot, that depot's catchment area is broken down further into delivery zones, which are typically used to create a single driver run.
Each of these delivery zones should be broken down into smaller areas, to ensure that the locations are serviced in a reasonably efficient manner.

The operation then uses the existing system to manually change the sequence of all of the orders so that they are efficient. They also use customer (location) windows to ensure that they are delivering within the correct window.

The operation subs certain trips to 3rd-party carriers. Typically this is based on whether it is financially viable for EBB paper to run the trip themselves or for another carrier to run the trip, based on the order revenue and the carrier cost. This is a manual comparative process.

{{Note}} The current planning process does not distinguish between order types. It is noted that customer orders should be serviced first, then any product movements are then added to the trips if there is capacity to do so.

Any low-volume routes will then be checked for cost and revenue to determine the viability and trips will be manually modified and/or merged to create a reasonable delivery run.

Customer Return orders (RTN) are also be planned onto the final radial trips.

When planned in MSA, the manifests are exported to C-ePOD, which creates loads for the manifests. Currently this is limited to:
* Final radial trips.
* Customer returns.
* Customer collections from depot (desk collections).
Trunk trips are currently excluded, as there is not enough information on the MSA interface to determine which trunk trips should be created.

OBS have requested EBB Paper to provide extracts of the configuration data currently used by the planning system with respect to:
* cross-dock paths for the trunk network.
* zonal breakdown.
The intention is to potentially use this data to upload directly into CTL for system testing (as a start point).

OBS have analysed the trunk routing information provided and transposed that into data.
OBS have provided a breakdown of the current routing to EBB Paper for validation, and to confirm the normal defaults i.e. trailer type, cut-off, times, etc.

{{Note}} Subsequent to this, confirmation has been received from the customer confirming all of the cut-off and departure/arrival times of all routes. Additionally, the Sheffield trunk routes have changed times.

When the order is in GP, the operation produces pick sheets to pick the stock, and driver manifests to load the vehicles.

This leads to a process whereby any orders added to a plan after initial loading being placed on a separate manifest for the same vehicle, so that they can get a distinct sheet showing the new products to be loaded. Experience has shown that, if they do not do this, the operations may load product twice (unaware that it has been loaded already), which then leads to additional picking of product for the subsequent orders (whose picked product has been inadvertently loaded for the first order).

The existing Driver Manifests are as follows:
* A manifest summary sheet, showing all stops, orders and quantity of products.
* A signature line, so that they can use this sheet to capture signatures in the event of a failure.
* A delivery note per order on the manifest, showing the order information, deliverable stock and quantities.
This is printed onto pro-forma stock.

EBB Paper have provided electronic copies of this documentation:
<gallery widths=300px heights=450px perrow=2>
Image:REQ_366558_ProForma.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Pro-forma stock}}
Image:REQ_366558_ExistingManifest.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Existing manifest}}
Image:REQ_366558_ExistingDeliveryNote.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Existing Delivery Note}}
</gallery>

The operation trunks the picked product to the correct out-base for final delivery through the trunk network of vehicles. As previously mentioned, this is not executed by C-ePOD.

C-ePOD is used to perform the final radial deliveries and collection of returns.

TomTom navigation is used to navigate to the destination of the job, and then the product quantities delivered or collected are captured on the C-ePOD application, as well as the customer's signature.

{{Note}} The paper delivery notes and driver manifests are used in the event of any system failure. The customers sign the manifest in the provided signature line.

The current process in use to electronically capture these manual PODs is to use the C-ePOD system when back on line, complete the job as per the sheet and then use the unmanned location process to take an image of the signature on the manifest/delivery note. This then uploads as normal to TTM. Several alternative options were discussed in the start-up meeting, but this process seems most consistent and easiest for the operation to follow.

C-ePOD is also used at the depot to complete customer collections, utilising a WAREHOUSE user.

EBB identified that there is an existing issue with customer collections.

It is noted that this is an understood limitation of the system, and is caused by customers not collecting on the day advised.
The users then must move the job onto a load on the following day and close the original load to continue.

The operation makes use of Portal TTM to:
* track completion of trips and orders.
* run extracts of orders.

Currently, the operation utilises some extract from the Portal TTM system to provide information on the completed orders. The operation has recently raised concerns that these reports do not include enough information (i.e. the reason codes and descriptions of any cancelled or amended product, or a cancelled order).

== Overview of Solution ==
The core systems for the business are an externally-provided ERP (GP), with OBS Logistics' systems as follows:
* Great Plains ERP (GP) - order entry.
* ''CALIDUS'' Total Logistics TMS (CTL) - planning.
* ''CALIDUS'' ePOD (C-ePOD) - execution.
* ''CALIDUS'' VEhub (C-VEhub) - vehicle checks.
* ''CALIDUS'' Portal TTM (TTM) - tracking.
* TomTom - navigation.

{{Note}} With the exception of CTL, all other systems have already been installed and are in use by the operation.

[[File:REQ_366558_Solution_Schematic.png|border|600px]]
{{Xref
|Type=Figure
|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}
|Text=Solution Schematic}}

The operational processes will be:
* Orders are entered into the ERP.
* CTL will pick up the orders from the ERP at regular intervals. A bespoke interface in CTL will poll for new orders.
* CTL will automatically plan orders onto trips through fixed route templates, planning them onto timed trunk network trips and final radial trips. The orders will be broadly sequenced by zones within regional operating areas.
* CTL users will have the facility to amend the planned trips, and to manually plan any orders that do not plan onto the trips.
* CTL users will resource the trips, applying a carrier identifying the depot fleet. When a carrier is selected, they will assign vehicle and trailer to the trips. For 3rd-party carriers, the existing process will continue of assigning a warehouse driver and vehicle (e.g. WAREHOB03).
* CTL users will send the trips through to the existing implementation of ''CALIDUS'' ePOD.
* C-ePOD executes jobs and captures the actual delivery quantities, additional information and signatures.
* This information will automatically debrief the orders and trips in CTL.
* TomTom Nav is used for navigation to the destination.
* C-ePOD will update ''CALIDUS'' Portal's Track and Trace module (TTM) with information for order tracking, as it currently does.

{{Note}} The ERP will not be updated with the actually delivered/collected quantities - this information will be held within the ''CALIDUS'' systems and can be viewed in CTL, C-ePOD and C-PORTAL.

The vehicles use the TomTom PRO 8xxx devices to run ''CALIDUS'' VEhub, the C-ePOD client application and the built-in TomTom navigation applications.

== Static and Configuration Data ==
A list of branches and their details has been provided by the customer.

Roughly 30 new delivery addresses are created each day.

Only one organisation is required within the system (EBB) - the system does not need to be broken down to division.

Certain data is required for configuration of CTL, such as:
* Customers (in this case, contractual agreements between EBB and a customer, rather than a delivery address).
* Locations.
* Location Zones.
* Cross-dock routes.
* Rates.
* UOMs.
* Transport units.
* Product Types.
* Depots.
* Sales territories.
* Drivers.
* Shift patterns.
* Driver shifts.
* Vehicles.
* Vehicle Types.
* Trailer Types.
* Trailer IDs.
This information has been requested from EBB Paper.

EBB Paper will investigate extracting static data from the existing systems (both planning and ERP) to aid in evaluation and implementation.

OBS will then attempt to use this to drive upload of this existing data into CTL pre-implementation of the test system. Extensive implementation time will be required to upload this information from the existing systems and create a scripted process that can be repeated during implementation to test and for go-live.

{{Note}} Once EBB's test CTL system is initially loaded, it will be EBB's responsibility to maintain any static data in the system. Before the system goes live, a data import of static data will be made into the production system from the test system, to ensure that the system is configured exactly as test before go-live.

=== Customers ===
{{Note}} Customers in CTL determine the rate and account information, and therefore the trip cost. Each order created must belong to a customer in CTL.

The customer code will be extracted from the view from the ERP and created within CTL if this does not already exist. It is expected that this will include basic rate information to generate product costs.

Customers can be then maintained within CTL in the customers maintenance screen.

[[File:REQ_366558_Customers.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Customers maintenance}}

This will allow the operation to maintain the following information:
* Address.
* Accounting information.
* Contacts.

Each customer can and should be assigned to a customer group. Only a single customer group is required - EBB.

=== Sales Territory ===
After discussion with EBB, the sales territory will be set up through the order groups and this will be used against each order. This will allow users to filter and report on orders for particular sales territories as well as delivery depots.

Order groups can be maintained within CTL in the order groups maintenance screen.

[[File:REQ_366558_Order_Groups.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Order groups maintenance}}

=== Locations ===
Locations in CTL are used for multiple purposes, determined by the location type. It is expected that the following types will be available:
* CUSTOMER - Delivery/collection locations.
* RDC - Depot (RDC) locations.

Locations types are configurable in CTL using the location types maintenance screen.

[[File:REQ_366558_Location_Types.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Location types maintenance}}

However, location types are expected to be static and will be set up as part of the implementation.

Locations are maintained in the locations maintenance screen. All locations of all types above will be created within the CTL system with unique codes.

[[File:REQ_366558_Locations.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Locations maintenance}}

This will allow the operation to maintain the following information:
* Address.
* Contact information.
* Loading/Unloading rates.
* Opening and Closing times - EBB Paper will provide a list of time windows for the locations, which will be created as part of the implementation of the system.
* Resource restrictions - EBB Paper will provide a list of resource (i.e. vehicle type) restrictions, which will be created as part of the implementation.

It is expected that locations will be maintained within the ERP and will be created and/or amended as part of the orders interface from the ERP.

Further, it is expected that all existing locations that have been used by the C-ePOD system up until this point will be loaded into the system as part of the implementation of the system. OBSL will map the loosely-formatted EPOD Customer data to the strongly-formatted data in CTL (i.e. town, county).

In terms of location contacts, there is very little contact data currently passed to C-ePOD and available for extract, so this will not be imported. It will also not be necessary to import this on the orders.

=== Location Zones ===
Location zones are used by the system to group locations for routing through the fixed route templates.

Location zones are created and maintained within CTL in the location zones maintenance screen.

[[File:REQ_366558_Location_Zones.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Location Zones Maintenance}}

The zones are expected to be set up to replicate the existing zones and areas used within the existing planning solution. These are not expected to be modified extensively after implementation of the system.

EBB will provide a data extract of these postal ranges for evaluation.

=== Cross-dock routes ===
Cross-dock routes (i.e. the trunking network) will be maintained in the system through the use of fixed route templates.

[[File:REQ_366558_Routes1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Fixed route template maintenance}}

Fixed route templates will be created for the following routes:
* All trunk routes.
* All radial collection/delivery routes.

The fixed route templates can include restrictions such as:
* Operational days.
* Owning depot.
* Carrier or Vehicle type.
* Max trips per day.
* Cut-off times.
* Fixed times.

Trunk routes will be created to route between the depots, cross-docking the delivery orders' product through the depots until the final regional delivery depot is reached. These route templates will be identified as a trunk route template. Trips will be created for each day as orders are planned onto the routes. These trips will be stamped as trunk routes.

The radial routes will be used to create trip for the final delivery of delivery orders and the collection of collection orders. Sub-zones will be used to partially sequence the orders on the trips.

=== Loading/Unloading Rates ===
Loading and unloading rates are used per location to determine how long it will take to load or unload at that location. This includes the amount of time to handle individual transport units.

[[File:REQ_366558_Load_Rates.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Load rate maintenance}}

So, a basic amount of time can be set for the general arrival/departure at a location, as well as an amount of time to handle each TU.

For example, one location may include a lengthy approach which takes 3 minutes to navigate, whereas another may be right outside the delivery point. In that case, the first location may have a basic rate of 6 minutes, whereas the second may only allow for a minute.

The amount of time taken to handle each TU at the locations would be the same i.e. x minutes per TU.

It is expected that TU types will be defined as part of the interface from the ERP, and that standard loading/unloading rates will be used against RDCs and customer delivery locations.

There are also certain known exceptions to waiting times, for example Desktop locations, where the driver delivers the product to many individual locations on a single delivery. These are known locations. EBB will create specific loading/unloading rates for these locations and apply them as required.

Once the waiting times are determined at each site through live running of the system, EBB can then start to input more accurate load/unload times to improve planning.

The rates are expected to be configured initially as follows:
* Depots will have their own loading/unloading rates of 30 minutes.
* Customer locations will have a standard 5 minute delivery time.
* Desktop locations will have a 30 min rate and will be assigned to specific locations, known to EBB.

=== UOMs ===
Each order will contain products that have specific product types, expected to be one of:
* 1.
* 100.
* 1000.
* 1000sqm.
* 5000.
* BOTTLE.
* BOX.
* BOXES.
* CHARGE.
* EACH.
* ENV.
* ENVS.
* M2.
* METRES.
* Misc.
* Pack.
* PAN.
* REEL.
* ROLL.
* SETS.
* Sheet.
* SHEETS.
* TIN.
* TONNE.
* TONNES.

There is no concept of UOM within CTL to hold this information.

These instead will be held as transport units within CTL.

Transport units (TUs) are used to determine the loading/unloading rates and to estimate the vehicle fill, based on the quantity of product.

Transport units may be maintained through the transport units maintenance screen.

[[File:REQ_366558_Transport_Units.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Transport units maintenance}}

Each transport unit will be configured with dims, weight and BUE (base unit equivalent) - CTL will use this, combined with the quantity against an order line, to determine the area, footprint and weight of the product being stored and therefore the capacity of the vehicle.

It is expected that TU types will be defined as part of the interface from the ERP, and that standard loading/unloading rates will be used against RDCs and customer delivery locations.

{{Note}}
* EBB Paper are reviewing the definitions of the transport units in use in the operation as part of this project, to more accurately represent size of products.
* Transport units are being reviewed by and will be maintained by the customer.
* This review may result in changed UOMs, for example SHEETS may become SHEETS_SML, SHEETS_STD, SHEETS_LGE, SHEETS_XL. This will reflect in the data sent to the C-ePOD system, and therefore the UOMs on the POD note from C-ePOD. This change in UOM is not expected to present a problem to EBB Paper or to their customers.

=== Products ===
Products will be held as product types within CTL.

EBB have confirmed the following information:
* Product type description should never change.
* A single product is always ordered in the same UOM.
The exception is FOC products, where the description will change with every order. There are multiple FOC products, for each UOM, for example FOC_SHEETS, FOC_ENVS, etc.

OBSL conducted analysis of the existing data within C-ePOD and the following was found:
* There are many examples of the same product code with a different description, for example: 002.12005: "... CUT to A2", 02.16001: "... HAS BEEN CUT TO". It has been confirmed that the sales team should not be doing this.
* There are examples where the same UOM (SHEETS) are used on many different product sizes. e.g. from 210*297 up to 720*1020. As this is the transport unit in CTL, this directly affects the area and therefore capacity of the vehicle. EBB agreed to maintain these UOMs in CTL.
* There are 18 examples of multiple UOMs used on the same product e.g. LF1C75-320-75: 1/PACK, ZZZ100204: TONNE/TONNES, ZZZ101153: 1000/SHEETS, 130.075: BOX/SHEETS.
* There are many examples of products without a UOM as well. When CTL creates a new product type, the TU will default to "SHEETS" if it has not been provided.

OBSL will send through examples of duplicated product types and examples of product types using multiple UOMs in C-ePOD, for EBB to analyse and provide instruction to the sales team as to the proper usage when CTL is implemented.

Product types may be maintained in the product types maintenance screen.

[[File:REQ_366558_Product_Types.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Product types maintenance}}

Each product type in the system is then used to determine the TU type that the product is stored on, and therefore the BUE and vehicle fill that this quantity of product would use on a vehicle. This can also store the default description, dims and weight of the product. These will be created when orders are created, then not updated from that point.

This process of determining the product type and TU type will need to be modified (as part of the orders interface from the ERP) to calculate the total quantity of product (multiplying quantities for example) and will require additional fields against the product type. This is accounted for in the orders interface change listed in following sections. This will be a bespoke interface for EBB.

Note that any additional UOMs that have not yet been used in CTL will be created with default values as part of this interface.

=== Salesperson ===
Sales territory and salesperson are required to be stored against each order created from the ERP. This information is required to be passed through to the C-ePOD system for reproduction onto the POD paperwork.

Sales territory will be stored as the group of the order.

There is no concept of salesperson within CTL. However, it is possible to store additional information against orders within the system, utilising order parameters.

Order parameters are user-definable and can be maintained in the order parameters maintenance screen.

[[File:REQ_366558_Order_Parameters.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Order parameters maintenance}}

These can then be applied to orders created in the system.

It is expected that a new order parameters will be created to hold this information and that this information will be automatically populated when creating orders through the orders interface.

{{Note}} If orders are created manually within CTL (which is not expected to be part of the process in this implementation), the user must manually add this information to the orders created - the system will not require the entry of these parameters.

This parameter process will be used to store any other non-essential order information that CTL is required to store for the EBB operation (typically to pass on to C-ePOD). This may include (but not limited to) the following:
* Loading location.
* Order creation date.

=== Order Types ===
Order type is not a concept in CTL.

However, CTL does contain the concept of service levels, which are user-maintainable through the service levels screen.

[[File:REQ_366558_Service_Levels.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Service levels maintenance}}

The service levels will be configured to represent the order types within the system, as follows:
* RTN - Customer return.
* INV - Customer orders.
* CAL - Call-off.
* ISTIN - Stock transfer.
* COMP - Customer complaint return.
* COLL - Customer collection.

Orders will be allocated a service level through the interface.

The screen will be modified to indicate whether service levels (order types) are excluded from automatic planning. This will be done as part of the scheduling engine, specified later in this document.

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this range.

The operation does not normally make a specific delivery run to collect a customer return (type COMP/RTN): the, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

All exceptions will be handled and planned manually by EBB.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

=== Reason Codes ===
Reason codes are used for many purposes in CTL-TMS, mainly:
* Delivery exceptions.
* Resource availability.

Reason codes are categorised by the type, which can be maintained.

[[File:REQ_366558_Reason_Types.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Reason types maintenance}}

Delivery reason codes can be maintained in the Delivery Reason Codes maintenance screen.

[[File:REQ_366558_Delivery_Reasons.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Delivery reason codes maintenance}}

These are used when debriefing orders and product quantities, in exception circumstances. These match the reason codes used in C-ePOD when executing the jobs.

Resource reason codes can be maintained in the Resource Reason Codes maintenance screen.

[[File:REQ_366558_Resource_Reasons.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Resource reason codes maintenance}}

These are used in the resource diary to mark resources (drivers, vehicles, trailers) as unavailable on certain dates and times.

Reason codes will be extracted out of C-ePOD and entered into CTL data as part of the implementation of the system.

=== Resources ===
==== Carriers ====
Carriers are assigned to trips for execution. The carrier is the top-level resource assigned to a trip, which then determines which drivers, vehicles and trailers are available to be assigned to the trip.

Carriers are maintained in the carriers screen.

[[File:REQ_366558_Carriers.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Carriers maintenance}}

Here, the following can be maintained against the carrier:
* Details - the carrier type and whether the carrier must start and end at a hub location.
* Payments - accounting and rate/tariff information, for generation of trip costs.
* Vehicle Type - vehicle types used by the carrier.
* Contacts - contacts for the carrier
* Addresses - identifying Billing Address; Collection Address; Delivery Address; Headquarters if required.
* Restrictions for the carrier, such as:
** Maximum weight and volume carried.
** Product Type.
** Location Zone.
** Service Level.
** Transport Unit.
** Operating Locations.

Carriers are defined by types that indicate whether they are home fleet or 3rd-party. Carriers will be set up for each depot within the EBB network. Drivers, vehicles and trailers will then be allocated to the carriers.

A single carrier will be created per depot, with the same name as the depot.

3rd party carriers are required. currently that is known to be (not limited to):
* PALLETLINE.
* UK Mail.
* ACL.

No 3rd-party carriers will be set up in the system - instead these will be identified by ware WAREHOB driver for the depot's carrier.

Trips assigned to 3PC will still be sent to C-ePOD, will be sent to the normal C-ePOD site, but will be sent as user WAREHOBxxx.

{{Warning}}
* This configuration will NOT allow for different rates per carrier.
* Changing to add a 3rd-party carrier as a full carrier (rather than just a warehouse user) may require additional development at a later stage, not included in this project or the costs.

==== Drivers ====
Drivers must be applied to trips during the resourcing process.

Drivers and their availability are maintained in the drivers maintenance screen.

[[File:REQ_366558_Drivers.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Drivers maintenance}}

Here, drivers can be:
* created with full reference details, amended or deleted.
* assigned to carriers.
* excluded from working for customers or at locations.
* have a shift pattern assigned.
* have their availability modified for non-working time or holidays, for example.

Shift patterns can be created or modified in the shift pattern maintenance screen.

[[File:REQ_366558_Shift_Patterns.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Shift Patterns maintenance}}

All drivers for all depots will be created and maintained by the EBB operational staff. This includes the warehouse staff e.g. WAREHOB03.

Currently resource availability is managed through a combination of a spreadsheet and/or calendar.

CTL contains a number of facilities to manage resource availability. However, EBB must note that CTL is not a resource management system.

Resources can be limited by:
* Availability calendar, showing when this resource is unavailable and why.
* Driver shifts.
* Vehicle Off-road.

[[File:REQ_366558_Resource_Availability1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Driver availability calendar}}

[[File:REQ_366558_Resource_Availability2.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Full-screen calendar}}

EBB described that they would ideally like a total view of all resources on a single calendar, showing who/what is unavailable on certain dates, so that they can use this to manage resource requirements, driver holiday requests, etc.

Note that CTL allows the user to identify a driver resource, then click the calendar section and add in unavailability information. Users can also use this to set the driver's shift. The same calendar can be accessed from individual vehicles (to make them unavailable at certain times/dates). Vehicles can also be indicated as being off-road or on-road, by checking or un-checking the VOR flag.

The single driver or vehicle calendar can be shown full-screen, but that there is not a single calendar view that shows all of a particular resource type, to give the customer a full view. This can be developed at additional cost.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Full resource calendar.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} The resource availability information could be extracted from the system through the data extracts to that the operation can get a full view from that extract, rather than funding the development of a full resource calendar.

==== Vehicle and Trailer Types ====
Categories are created that define whether vehicle types of this category have transport movement capability and/or storage capability.

[[File:REQ_366558_Vehicle_Categories.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Vehicle Categories maintenance}}

For example:
* a trailer has storage capability but no transport movement capability.
* a tractor unit has transport movement capability but no storage capability.
* a van has both.

Types are then created for each tractor, trailer and/or van in the operation.

[[File:REQ_366558_Vehicle_Types.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Vehicle Types maintenance}}

These define the general outline of vehicles of this type, such as the maximum weight, dims, max BUE and any additional equipment.

{{Warning}} All vehicles are 15T. All are capable of pulling a trailer. A trailer can be added to the trip. This should increase the volume accessible to the trip.

==== Vehicles and Trailers ====
Vehicles in CTL define all available transport types, including tractor, trailer and van, through the category and type.

Vehicles can be created in the vehicles maintenance screen.

[[File:REQ_366558_Vehicles.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Vehicles maintenance}}

Here, the individual vehicles are entered, identifying the vehicle type. The specific characteristics of a that vehicle may be maintained, such as:
* Vehicle code (typically the registration plate or trailer ID).
* Make/Model/Livery.
* VIN number.
* Fleet number.
* Fuel type.
* Fuel efficiency.
* ODO reading.
* Registration date.

{{Note}} Vehicles and trailers are carrier resources and must be assigned to a carrier.

{{Note}} Vehicles, like drivers (above) can be made available or unavailable through the resource calendar. The vehicle may also be marked as off-road.

== Orders ==
Orders will continue to be created in exactly the same way as they are now, within the ERP.

=== ERP-CTL Orders Interface ===
The operation will expect to execute the following movement types:
* Radial delivery.
* Customer collection.
* Customer returns.
* Trunk movements.

Customer collections will be interfaced to CTL on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl).

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke import interface.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} A version of this interface has already been written as part of the C-ePOD integration. This is not suitable for implementation into CTL (mainly because it is primarily driven from a file sent from the MSA TMS already in place). This, however, may be used as a template as to how orders are created.

The team do not amend orders - they either add new orders or they void the order and create a new one. However, the interface will be written in such a way as to update orders if they already exist, so that re-processing a failed order will not prevent this interface from working as expected.

{{Note}} The import of orders will be designed to utilise the static data created in CTL. Certain areas, such as DU/TU (Despatch/Delivery unit or transport unit) are used to determine the vehicle fill through a percentage BUE (base unit equivalent). The process will apply the product and UOM to the product type and TU type, which will represent a proportionate vehicle fill.

A scheduled import process will be created on the system, running at a timed interval. During implementation, the existing interface in C-ePOD will be disabled, as C-ePOD will now be receiving all orders and trips from CTL through the standard C-ePOD web-service interface.

The current C-ePOD order import is triggered by the transport plan. The process then retrieves the details of only the orders on that transport plan.
As CTL will be responsible for creating the transport plan, this will require a change in how this is triggered.

Extracting data for orders will be direct from the MSD data, taken from the existing view of data.

The view currently shown 14 days of orders.

It will not be efficient to retrieve all orders from the view and check whether they have changed. As this will be happening very regularly (the import is expected to look for orders every few minutes), the process must be efficient.

In order to make in the new order import work efficiently, the MSA view must change to show:
* Voided orders.
* Creation Date/Time.

This will be prototyped by EBB paper as a new view within the existing database for the purpose of evaluation of the new CTL interface. Note that voided orders may instead be through a different view.

Voided orders in the interface will be handled as follows:
* The order will be moved to CANCELLED status.
* The order will be automatically unplanned from all trips, as long as none of the trips have not yet started (i.e. not status EN-ROUTE or COMPLETED).

Any order that is cancelled after it has begun being transported by the operation (i.e. the order is on any trip that is EN-ROUTE or COMPLETED status) must be manually handled. In this case, this means manually un-planning the cancelled order from any trips that are no longer required and moving the product back to the depot that will store the order's product. The raising of this stock transfer movement will be at the discretion of the operation.

{{Warning}} Voided orders removed from trips will change the product that is delivered and also loaded/unloaded by the operation on the trunk trips. It is likely that the operational documents affected by this will require reproduction by the operation. This should be achieved when the order is taken off trips by the operation.

Opening times against delivery locations are maintained in the ERP. These delivery times must be maintained against the orders in CTL.

These delivery windows will be transposed directly against the customer orders. These will be visible against the orders and may then be used when planning.

The interface will search for all orders created since the last time that the interface ran. For each order found, the interface will create all details of the order, including:
* References - the order references, expected to be the CTL order number, the external order number and the customer's reference.
* Service level - the service level will be determined from the first few characters of the order reference. If the order is specified as customer collect, this will be identified as a different service level. The service level will identify whether the order may be automatically planned (through the scheduling engine, described in following sections).
* Instructions - any order-specific instructions.
* Locations - the origin and destination (from and to) locations. Any locations that do not already exist will be created by this interface.
** If AddrCode is "0000", then CUSTNMBR is the location AND the customer.
** If AddrCode is NOT "0000", the CUSTNMBR is the Customer and AddrCode is the Location.
* Scheduling - the collection and delivery windows for the order.
* Contacts - any contacts for the order. As already mentioned, it is unlikely that there will be any contact information available to import.
* Requirements/Charges - any ad-hoc charges associated with the order. This will be used to generate the revenue of the order and will be taken directly from the ERP gross profit (XTNDPRCE – EXTDCOST).
* Transport Units/Products being delivered. This process will also create TU types and product types where required. Unit weights and dims will be stored on product types and UOMs. These will be created when orders are created, then not updated from that point.
* Customer - the customer and basic rate information will be defaulted in order to generate costs for trip. The customer will be identified through the CUSTNMBR and AddrCode fields in the view and will be automatically created if they do not already exist:
** If AddrCode is "0000", then CUSTNMBR is the location AND the customer.
** If AddrCode is NOT "0000", the CUSTNMBR is the Customer and AddrCode is the Location.
* The sales territory (order group).
* Parameters - consisting of:
** Salesperson.
** Loading location.
** Order creation date.
** Any other non-critical cross-reference data required for the order.

{{Note}} The operation has requested that lot numbers for certain order types be captured within the system for execution and reports. This is covered in more detail in the following [[#Lot Numbers|Lot Numbers]] section.

The collection and delivery windows will be set based on the order type (service level).

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this region.

Returns (COMP/RTN): the operation does not normally make a specific delivery run to collect a return, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

All exceptions will be handled and planned manually.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

The process will audit the success or failure of these order interfaces through the EDI Log screen, with a line for each order imported, a status (success or failure) and a showing the reason for any failure in detail.

{{Note}} Voided orders will be audited through the EDI log, in that the description of the process will clearly state that this order has been voided.

Given that the interface is based on the creation date of the orders, if an order should fail, there will be no facility to get the order again. Therefore this auditing process must check the interface type that generated the message (in this case, then bespoke EBB orders interface) and allow for re-processing of the message. The interface should check for any messages marked to be reprocessed in the audit log and get the details of this order again in the next pass. The original audit record will be updated as reprocessed and a new audit record created for the new import.

{{Note}} Failed orders will ''not'' automatically re-import - it is up to the CTL administrators to look for failures and mark them to be reprocessed, as this may require modifications to be made to the order in the ERP or the static data in CTL to allow the order to be successfully processed.

=== Orders Maintenance ===
All orders created in the system can be viewed and edited through the orders maintenance screen.

[[File:REQ_366558_Orders1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Orders maintenance - list of orders}}

Each order created will have the following information:
* References - the order references, expected to be the CTL order number, the external order number and the customer's reference. This also includes the order type (service level).
* Instructions - any order-specific instructions.
* Locations - the origin and destination (from and to) locations.
* Scheduling - the collection and delivery windows for the order.
* Contacts - any contacts for the order.
* Transport Units/Products being delivered.
* Customer.
* The sales territory (order group).
* Parameters - consisting of:
** Salesperson.
** Loading location.
** Order creation date.
** Any other non-critical cross-reference data required for the order.
{{Note}} The revenue of orders created through the interface will be fixed and cannot be changed in this screen.

[[File:REQ_366558_Orders2.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Orders - status, references, type, instructions}}

[[File:REQ_366558_Orders3.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Orders - locations}}

[[File:REQ_366558_Orders4.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Orders - scheduling, requirements, transport units}}

[[File:REQ_366558_Orders5.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Orders - parameters, audit}}

A full audit trail is maintained of the creation and each change made to orders, either through the orders interface or manually by users in this screen.

=== Lot Numbers ===
Lot numbering is a requirement of the operation.

Call-off orders are typically large orders, pulled by pallet, where specific lots are identified.

Typically these are full reels of a single product, with a unique lot number and weight within the ERP.

The reels are palletised, one reel per pallet.

The weight of each reel is roughly the same, but never identical.

So, if an order calls off 11 tonnes, and the weight of each reel is roughly 1 tonne, the order will identify 11 pallets (lot numbers) with a weight as close to 11 tonnes as possible.

The lots are identified on the order and on the pick note.

The specific lot numbers are then picked and loaded for the order.

Typically (but not always) this constitutes a full load.

Because this information is not specifically displayed on the C-ePOD device, the driver could technically unload the incorrect lots.

So the operation require that this information is displayed on the C-ePOD device and also potentially onto the POD document produced from C-ePOD.

CTL and C-ePOD will be modified to support this process.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Lot number processing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} A view will be required within the ERP accessible by the CTL interface to retrieve the lot numbers, regardless of whether or how CTL intend to store or process the data. This will be a separate view (not amending the main order view) to that this can be implemented separately if required.

This view will contain:
* ORDER
* PRODUCT
* LOT

When importing orders, the process will check for any lot numbers associated with the product. If any are found, these will be stored as separate items under the product (the order line).

This information will be sent to C-ePOD as part of the interface.

The interface will either:
# Concatenate these lot numbers into a single field against the order or;
# Send these through as individual items to be found and delivered.

This will affect the delivery process for the drivers in different ways:
# If concatenated, the information will be displayed against the product being delivered. So, if the product was 247.01 and the lots called off were LOT1, LOT2 and LOT3, there would be 1 product line for 247.01 with an additional text field of "LOT1, LOT2, LOT3" displayed against it.
# If sent through as individual pallets, these will be listed as individual containers on the list, showing the lot number, product code and weight. Each item will need to be confirmed separately. So, if the product was 247.01 and the lots called off were LOT1, LOT2 and LOT3, there would be no product lines but there would be 3 containers: 247.01-LOT1, 247.01-LOT3 and 247.01-LOT3, each showing the actual weight of the lots for that product.

Each process would require some development, specifically:
* Both:
** Order interface to retrieve and store lot numbers.
** POD format change.
** EPOD Products List layout change.
* Concatenation:
** Identify a field on EPOD to store concatenated lot numbers
* Lot as separate items:
** Modify the length of the product + lot number, to ensure it can be stored.

Each process has pros and cons:
* Concatenation:
** The driver process would not change in EPOD - they would still be prompted only for a single concatenated line.
** The drivers would manually check the lot numbers - the device cannot enforce this.
** The summary of products delivered (at customer signature) would not display the lot number without further development.
* Lot as separate items:
** Lots are immediately visible in CTL and EPOD without looking for the additional field.
** Specific lots can be marked as delivered or not.
** Driver will have to identify multiple items to unload - one for each lot.

EBB will confirm the process they want to follow as part of the review and sign-off of this solution design.

== Planning ==
=== Automatic Route Scheduling ===
As shown in the [[#Cross-dock routes|Cross-dock routes]] section above, CTL will replicate the existing fixed route configuration with respect to:
* The trunk network.
* Delivery zones and areas.
The intention is that CTL will use these created templates and zones to automatically plan each new order onto trips for that day through a scheduling engine process running at a timed interval.

Fixed routes related to the trunk network will be identified with a Trunk flag.

Any orders that do not match or are outside the normal schedule, break vehicle capacities, etc) will remain unscheduled and can then be investigated.
This should allow the operation to work much more pro-actively, with the system doing all of the original planning to the template, and then the users investigating just the exceptions, finessing the delivery plans, etc.

The automated scheduling process will check the attributes of the order being scheduled against the fixed route template, checking:
* volume capacity, estimated through the quantity of each TU type and the base unit equivalent (BUE) value.
* trailer weight capacity.
* cut-off time.
* from location (the depot from which the product is picked).
* end location compared to the zones on the fixed route template.
* delivery window, in that the order must be delivered within the end window of the order.

The collection and delivery windows will be set in the interface based on the order type (service level).

Most orders are day 1 for day 2 (i.e. customer deliveries INV and CAL).

Some orders specify a delivery date and time outside of this region.

If a trip is not found that matches the criteria of the fixed route template, one will be created. If the route templates indicates that this is a trunk trip, the trip created will be stamped with a flag indicating this. All trips created from fixed route templates will be automatically named from the fixed route template description. In this way, trips created from routes and trunk trips can be quickly identified in the system.

If one is found, the order will be added to that trip and the order will be considered to be planned up to the destination of the template.

This process will repeat, finding and scheduling the order onto trips generated by fixed routes until the order has reached its destination.

If at any stage the order cannot be planned in full from the origin location to the destination within the delivery window, the order will be completely unplanned. This allows the users to manually plan the order, choosing whether to employ a third party from the origin point or whether to push the order to the closest depot before manually planning. {{Warning}} The process could instead retain all planning up to the last point, and then allow the users to manually plan (potentially through a 3rd party) from the last depot it reached, if that is preferable.

The trailer type used will be configured to take into account the tare weight of the trailer itself, to ensure that the load does not exceed weight capacity.

It is requested that the process used to plan the orders within CTL plans only certain order types (service levels). Essentially, only customer-related delivery orders will be planned onto trips. Returns and stock transfers will then be manually planned. In terms of order types, that is:
* INV
* CAL

The process will check the service levels (order types) to determine whether the order should be excluded from automatic planning.

Returns (COMP/RTN): the operation does not normally make a specific delivery run to collect a return, but instead plans them for when they are next visiting that location. This is usually within 3 days. The operation will manually plan these orders.

Stock Transfers (ISTIN) will be excluded from automatic scheduling and will be planned manually by the operation.

Customer (desk) collections will be excluded from automatic scheduling and will be planned manually by the operation.

All exceptions will be handled and planned manually as shown below.

=== Manual Planning ===
All trips automatically or manually planned can be viewed and amended through the CTL planning screen.

When creating manual trips, the screen shows a view of all orders in the order well. This list can be restricted to the orders that are being planned (i.e. unscheduled orders) and filtered.

The screen allows:
* Creating new trips.
* Filtering trips by status, trunks, carriers, depots, dates, schedules, trunk trip, etc.
* Filtering orders by status, schedule, ownership (by region), customer, etc.
* Amending trips.
* Resourcing - discussed in more detail in the following [[#Resource Assignment|Resource Assignment]] section.
* Viewing on a map - discussed in more detail in the following [[#Optimisation|Optimisation]] section.
* Optimisation - discussed in more detail in the following [[#Optimisation|Optimisation]] section.

The carrier you are planning for is shown in the header, and all trips shown will be restricted to that carrier. The trips can also be further filtered.

Multiple orders can be selected and new trips can be created, either to the destination or through a cross-dock location, using the buttons provided.

[[File:REQ_366558_Planning1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Planning Order Well}}

Existing trips can have orders manually added to them by selecting the orders and dragging them to the trip in the trip panel.

[[File:REQ_366558_Planning2.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Planning onto existing trips}}

Each trip can be viewed in more detail through the full-screen view. Each stop can be expanded to show the orders on that stop, along with more stop and order information.

Each trip and stop shows warnings regarding potential planning issues.

[[File:REQ_366558_Planning3.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Full-screen with expanded details and warnings}}

The current planning process uses the gross profit to determine the viability of any single trip, so planning must show order revenue and trip cost. This is applicable only to final radial trips.

The order revenue calculated in GP will be picked up as part of the order interface. This will then generate the order revenue - it need not be calculated in CTL.

The screen will be modified to include trip cost and total order revenue on the trip summary.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Planning screen to display trip cost and revenue in summary.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The screen will also indicate whether this is a trunk trip on the full screen view.

Desk collections can order product from one depot e.g. (Thurrock) to be collected at another (e.g. Farnborough).

The order must be trunked to that location.

Typically collection is at the depot closest to the customer, but could be at any location.

EBB will manually trunk and create collection trips for customer collections.

In order to facilitate that, the users will filter orders by service level on the planning screen.

=== Optimisation ===
Trunk trips will naturally be optimised as they are very proscriptive with limited stops and fixed times.

Regarding radial trips, although the fixed route templates will get all of the orders on the trunk and final radial trips as required, the sequence of the orders on the trip will not be fully optimised.

The planning screen will allow the user to see all of the orders on a trip on a map, so that they can see inefficiencies and change them manually. MT confirmed that this cannot be changed on the map - this map is used for information, which the user then replicates on the trip by changing the stop sequence.

[[File:REQ_366558_PlanningMap.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Planning map view}}

There is trip optimisation option built into the planning screen, utilising HERE maps optimisation.

This has been agreed that this is part of the solution that will be built for EBB and that the costs of the HERE maps optimisation are included.

The user can use the icons under a trip to automatically optimise the sequence of orders on this trip.

[[File:REQ_366558_PlanningOptimise.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Optimisation}}

The HERE maps optimisation supports:
* Fixed start times.
* Fixed start and end locations.
* A single location time window.
* Fixed sequencing (i.e. order B before order A).

{{Note}} Optimisation will use these order/customer windows to automatically determine the most efficient run sequence.

== Resource Assignment ==
Once trips are created and optimised, the users will assign resource to the trips.

The current implementation of C-ePOD is enabled for trailer identification, but that it appears not be used at this time. The operation requires that this is used after the implementation of CTL.

Trips are created with carriers assigned to them. The carrier defines the available resources (driver, vehicle, trailer).

The planning screen allows the users to assign resource to trips.

[[File:REQ_366558_ResourcingDrivers.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Resourcing Drivers}}

<gallery widths=150px heights=250px perrow=2>
Image:REQ_366558_ResourcingVehicles.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Resourcing Vehicles}}
Image:REQ_366558_ResourcingTrailers.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Resourcing Trailers}}
</gallery>

Users can select the resource type and then drag and drop the selected resource onto the trips. Depending on the trip being resourced, the resources will be displayed with annotations to indicate any limitations with this resource on this trip.

EBB noted that certain locations have restrictions as to what trailer/vehicle type may visit that location (for final radial runs of deliveries and collections).
OBS noted that CTL contains the facility to restrict vehicle types or specific vehicles from visiting the location.

Furthermore, drivers themselves can be excluded from delivering for certain customers or locations.

This users enter this information as part of the configuration of the resources (driver, vehicle and trailer).

This information is used when resourcing created trips, by providing decision assistance to the user, indicating why the specific resource (vehicle or driver in this case) may or may not be suitable for this trip, in the form of warnings or information icons and pop-ups against the resource or trip. This will show:
* Driver exclusions.
* Driver availability (diary).
* Driver working hours/shift.
* Vehicle/trailer exclusions.
* Vehicle/trailer availability (diary or VOR).
* Resource already allocated.

{{Warning}} Trailer swaps - how to plan them.

== Execution ==
Once a trip has been successfully resourced, the users may then export the trip to C-ePOD for execution using the provided button on the trip. The trip will be automatically set to ACCEPTED status.

[[File:REQ_366558_SendToEPOD.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Send trips to EPOD.}}

{{Note}} The users may still modify trips after this point, and the trip can be sent to C-ePOD again after modification are complete.

{{Note}} This process could equally be completed after loading is completed.

The interface to C-ePOD will require some change from the standard model to support the requirements of the existing EBB Paper implementation of C-ePOD. The following changes are required:
* Map new/changed elements (i.e. Sales territory, Salesperson, loading location, order creation date, etc). Ensure that this is configurable.
* The configuration of job group will be required to be set by stop activity (SU, PK, DL, CL).
* Job consolidation is required at a loading and unloading stop level at a depot only.
* Depot loading and unloading will be identified as loading or unloading jobs in the interface (as opposed to normal collections and deliveries).
* Trailer identification.
* Importing of any bespoke functionality into the standard C-ePOD webservice interface, such as (but not limited to):
** Creating UOMs.
** Creating drivers.
** Creating trailers.
** Multiplying product quantities.
{{Note}} If lot number functionality is to be developed, this interface must also include the specific lot numbers. This is included as part of the lot number change raised earlier.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=CTL-EPOD Interface changes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} The use of location has changed slightly, as identified in the order import process:
** EPOD currently does not use the AddrNo field at all.
** Location will now be the AddrNo in the case where it is a non-0000 value.
** This drives a change to what is sent to EPOD, in that the location may differ.

This will be reflected in the interface and in the set-up of the C-ePOD system. This is not expected to drive any meaningful change into the process, but more properly defines the data.

The operation will then need to load the product and print out driver manifests and delivery notes for the trips. The system will include the following operational reports:
* Loading sheet.
* Driver Manifest.
* Delivery Notes.

{{Warning}} It is to be confirmed whether OBSL should develop this format within CTL or whether EBB will conform to the generic CTL format. If required, this will be an additional development, described below.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=EBB operational reports.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}



=== Loading ===
The operation will load the vehicles based on the trips created. CTL will produce a loading sheet to control the loading and unloading of the vehicles.

This will display the stops on the trip, and display a list of the orders and product (lines) and quantity to be loaded. {{Note}} If lot number functionality is to be developed, this report must also include the specific lot numbers to be loaded. This is included as part of the lot number change raised earlier.

To aid in the issues in the current system where late orders sometimes result in duplicate picking or loading twice, the loading report will be modified to help control this.

A mechanism will be introduced in this report whereby a unique ID will be stamped against the reported orders showing when they were added to the Loading report. This then will immediately identify to the users that these orders are additional to any previously-produced sheet and are awaiting loading, whereas any that have the previous ID were produced on an earlier report and therefore may already be loaded.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Operational report (loading sheet or driver manifest) to include run sequence.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Warning}} Voided orders may have been removed from trips or may still be assigned to the trips. When producing the documentation (driver manifest, delivery notes and/or loading/unloading sheets), the documents will clearly indicate any cancelled orders. When the orders are removed from the trips by the operation, the orders will no longer show on the operational documents for those trips and therefore the operation will need to take great care in ensuring that cancelled orders that have been removed from trips have their operational documents reproduced.

{{Note}} It is noted that voiding orders is subject to operational checks between the salesperson and the operation (warehouse and depot) before orders are voided. If this check is performed, it is highly unlikely that the operation will have issues with voided orders. This manual check must remain, however.

{{Warning}} MT queried the need for an unloading sheet in the operation, as other operations just use the driver manifests and delivery notes to achieve this. To be confirmed with EBB whether they use the driver manifest for loading/unloading trunks and loading final deliveries.

QUESTION: What about the orders that are added to the trip after the trip departs the first depot? So, all orders planned, picked and loaded at Thurrock. Truck departs Thurrock to go to Hemel. Orders are still being picked and readied for loading onto this trip up until around 2000. The driver's manifest will not include any of these orders.

{{Note}} This decision will affect which reports are run by the operation (loading/unloading or driver manifest), but the work to amend either report to include a run sequence will remain the same.

=== Vehicle Departure ===
Once the loading of a trip is complete (and the trip is resourced and sent to C-ePOD), the trips can be executed through C-ePOD.

When a trip is started on the C-ePOD device, the trip will be set to EN-ROUTE status within CTL automatically.

{{Note}} EN-ROUTE trips will still be accessible through the CTL planning screen and may still be amended. The planning screen does not, however, display any actual stop times or order quantities that may have been derived through execution through C-ePOD - this information can be seen through the debrief screen discussed in the [[#Trip and Order Debrief|Trip and Order Debrief]] section below.

The operation already uses C-ePOD to execute trips for delivery, return collection and customer collection (desk) jobs.

As already mentioned, trunk trips were currently not operated through EPOD.

The following types of trip will now be executed through C-ePOD:
* Trunk trips.
* Final radial delivery/return trips.
* Customer collections at the depot (warehouse/desk jobs).

=== Delivery/Collection ===
The operation already uses C-ePOD to execute delivery/collections loads.

The process is as described in the C-ePOD requirements document, referenced in [[#Appendix B: Document References|Appendix B]] below.

This is summarised in this section.

==== Retrieving the load ====
The driver will log on to the device with a user name, password and vehicle.

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

==== Starting jobs ====
The driver will select '''Start Job''' from the ''Job Details'' screen.

Delivery instructions are displayed.

The driver may do the jobs in any sequence - the device will warn the user if the jobs are attempted out of sequence.

Once started, the device displays a navigation button. Clicking this will start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp. For non-TomTom devices, the application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.

Once arrived at the destination, the driver switches to the ''CALIDUS'' ePOD mobile application.

The driver indicates arrival and starts processing the job by clicking the '''Arrive Job''' button.

The device moves on to the Delivery or Collection process, depending on the job type.

==== Delivery process ====
The driver confirms delivery of the product and quantities for the order.

The driver can confirm each product on the list as delivered, change the quantity delivered or cancel the delivery of that product.

The driver has the option of clicking '''Deliver All''' on the ''Job Details'' tab to confirm all product on that job as delivered.

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.

{{Warning}} Potential modifications to process to support Lot Numbers.

==== Returns (collection) process ====
The collection process is almost identical to that described above, substituting Collection instead of Delivery.

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

==== Job completion process ====
The device displays:
* The Terms and Conditions.
* The Products delivered/collected.

The driver is expected to obtain:
* the customer name.
* the customer Signature.

The driver has an option of ''Unmanned location'' for unmanned locations or delivery out of hours. This process will instead require:
* the driver signature (PP customer).
* photos to confirm delivery.

When the delivery or collection job is complete, the job is removed from the list. The driver continues the same process for all jobs on the load.

=== Customer Collection from Depot (Desk Collection) ===
The operation already uses C-ePOD to execute desk collections loads.

The process is as described in the C-ePOD requirements document, referenced in [[#Appendix B: Document References|Appendix B]] below.

This is summarised in this section.

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

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

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

The depot operative starts the job and immediately clicks ''Arrive'' - no navigation is required.

The depot operative checks the goods and 'delivers' the goods as the driver would. '''Deliver All''' functionality is available.

The device prompts for the customer signature - no unmanned location process is available.

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

All collections for the day remain on this load unless they are moved to another day. If any jobs remain on this load at the end of the day, the load is cancelled or deassigned from the "WAREHOUSE" user.

EBB identified that there is an existing issue with customer collections.

It is noted that this is an understood limitation of the system, and is caused by customers not collecting on the day advised.

The users then must move the job onto a load on the following day and close the original load to continue.

CTL will build trips in the same way as EPOD currently does so, without additional work, this problem will persist.

As part of the solution design, OBS will investigate the possibility of CTL applying customer collection jobs to a specific trip that remains open for a long time (for example a month or a year, rather than a day). C-ePOD then must be modified to leave the trip open rather than close it when all orders are collected.

This is likely to be substantial additional work.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Keep desk loads open for longer periods.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Trunk Trips ===
EBB Paper desire to start using EPOD for trunk trip execution.

Based on the current known requirements, there are no modification required to the systems to help process trunk movements through CTL and C-ePOD.

It is expected that the trunk trips will be operated through C-ePOD in a similar way as radial deliveries. This is as described in the C-ePOD requirements document, referenced in [[#Appendix B: Document References|Appendix B]] below and summarised above.

The device will be configured with 'Deliver All' functionality, so that the driver would not have to scan each product on or off the vehicle.

{{Note}} During the start-up meeting, it was mentioned that entering the product quantities could be desirable at certain depots, due to inaccuracies when unloading. It should be noted that it is the driver that would be responsible for the unloading and product quantity entry and therefore this may not be suitable.

{{Note}} The system could be configured to run these jobs and that the configuration could be made specific to these jobs. EBB are to decide upon the exact configuration required for the trunk job execution.

The process within C-ePOD for trunk loads will be as follows:

The driver will log on to the device with a user name, password and vehicle.

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

The list will contain only a single entry per loading or unloading at the depots, no matter how many jobs there are on the load. So, if this were the Sheffield - Birmingham trunker:
* 1 loading entry at Sheffield planned for 1800.
* 1 unloading entry at Birmingham planned for 2030.
* 1 loading entry at Birmingham planned for 2130.
* 1 unloading entry at Sheffield planned for 2330.

<gallery widths=200px heights=320px perrow=3>
Image:REQ_366558_Job_List_Trunk.png|{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Job List showing consolidated trunk jobs}}
</gallery>

The driver will start, navigate and arrive the jobs in the same way as normal collections and deliveries. The driver will also be able to view the order level details of all orders to be loaded at that location, using buttons on the header to view each order. All instructions for all orders at that location will be displayed to the driver.

At this point, the device will display all products for all orders. The driver will have a single button to confirm that the jobs are loaded, through a '''Collect All''' button. Note that the unloading or loading of products for a trip/vehicle is expected to be handled through the operational documents either carried by the driver or produced at the depot.

When the user has confirmed all products are collected (loaded) for that location, the device will then require a signature as normal.

When the loading job is complete, the job is removed from the list. The driver continues the same process unloading at the next depot, and any other jobs on the load in sequence. In the case of unloading jobs, the driver will have a '''Deliver All'''' button rather than a '''Collect All''' button.

== Trip and Order Debrief ==
Debrief consists of several elements:
* Trip debrief, confirming trip, driver and resource information captured.
* Stop-level debrief, typically confirming the actual arrival and departure times
* Order-level debrief, typically confirming the quantities of products collected, despatched and delivered.

CTL allows all of these elements to be debriefed, largely automatically from use of C-ePOD execution.

[[File:REQ_366558_Debrief1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Debrief Trip level}}

[[File:REQ_366558_Debrief1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Debrief Stop and Order level}}

[[File:REQ_366558_Debrief1.png|border|600px]]
{{Xref|Type=Figure|Num={{ #vardefineecho: Figure| {{ #expr: {{ #var: Figure}} + 1 }} }}|Text=Debrief Order Line level}}

C-ePOD provides GPS tracking and an interface of actual arrival and departure dates and times into CTL-TMS to enable planned versus actual schedule adherence to be measured. This data is captured automatically, near real time.

The C-ePOD system is responsible for the trip/stop-level debrief information (i.e. the On Time aspect of OTIF, the arrival and departure times against stops on a trip). This information is stored within CTL-TMS for reporting purposes.

This update for trunk trips will update the arrival and departure times against each stop on a trip.

For final mile delivery trips executed using the C-ePOD application by the driver, this will update order quantities in CTL-TMS and therefore will set the delivered quantities against the orders and complete the order and the trip, changing the statuses accordingly.

Any modifications to delivered quantity or the product delivered are captured with a clause code in C-ePOD. This information is included in the debrief and reflected in CTL-TMS as part of the reason codes against each line. Note that this is also true of individual items (which may be used for lot number processing).

Most orders will be executed through C-ePOD as described above. In this case, the CTL-TMS debrief screen will provide a view of the information captured from the C-ePOD system.

However, in some instances, the operation may wish to manually debrief orders, for example orders through 3rd party carriers.

CTL-TMS provides a debrief screen that can be used to review the automatic debrief updates from the mobile execution systems and to update and finalise the driver, trip and order debrief (i.e. the In Full aspect of OTIF).

The order debrief allows the quantity of despatched and delivered units to be confirmed for each order line.

The trip stop times enables actual times to be reviewed and input against planned times. This is expected to be automatically populated by C-ePOD.

Any discrepancy of actual quantity input for an order will prompt the user to enter a reason code from a list and narrative can be added.

The screen also allows each individual tracked item to be debriefed for despatch and delivered quantity. This may be used for Lot traceability.

Start and End ODO readings are entered against a trip at debrief. These may be viewed and entered in the manual debrief screen.
These ODO readings will be stored in KM as a base unit.

Fuel drawn by the engine may also entered against a trip at debrief. This may be viewed or entered in the manual debrief screen.

Once the debrief entry is done, the status of the trip can be updated and promoted to COMPLETED using the provided button.

== Track and Trace ==
The operation already utilises ''CALIDUS'' Portal TTM for track and trace of trips and orders.

The process will not be affected by the addition of CTL as a transport management system, as C-ePOD will continue to be the source of all TTM-related information.

The system is described in the C-ePOD requirements document, referenced in [[#Appendix B: Document References|Appendix B]] below.

== Reporting ==
Currently, C-ePOD generates the POD/POC documentation for each job completed. This will continue.

As part of the optional Lot Number change, this report format may require modification.

Regardless, there are changes required to the C-ePOD report to reflect new configuration in C-ePOD user-defined fields - this has been agreed to be completed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Modify POD/POC report to include new UDF fields.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Currently, the operation utilises some extract from the Portal TTM system to provide information on the completed orders. The operation has recently raised concerns that these reports do not provide all of the information that is required, namely the reason codes for product quantity amendment or cancellation.

These reports will be superseded by data extracts within CTL. It is not required that the existing TTM reports be modified to provide this additional functionality before the implementation of CTL.

Further to that, the TRIP_ORDER and ORDER extracts be extended to report data to a reason code level.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Extracts to report reason codes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The levels will be amended to:
* TRIP_ORDER extract: TRIP/ORDER/LINE/ITEM/ITEM_REASONS
* ORDER extract: ORDER/LINE/ITEM/ITEM_REASONS

It is acceptable to the operation to have these extracts run by repeating lines dependent on the number of child records.

So for example, with a trip with 5 orders, each with 5 products to deliver:
* Reporting at TRIP level will show the 1 line with the trip-related fields.
* Reporting at ORDER level will show 5 lines with the trip-related fields repeated and the order-related fields.
* Reporting at LINE level will show 5 lines with the trip-related fields repeated and the order- and order line-related fields (assuming only one order line). This level is not expected to be something that EBB will use.
* Reporting at ITEM level will show 25 lines with the trip-, order- and order line-related fields repeated and the item-related fields.
* Reporting at ITEM_REASONS level will show 25 lines with the trip-, order- and order line-related fields repeated and the item- and reason-related fields (reason populated if present).

When extracted, the data in this form will be easy to pivot in Excel.


= Appendix A: Table of SCRs and Ballpark Estimates =


{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Resource Planning
|Description=Full resource calendar.
|Estimate=8
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Integration
|Description=Bespoke import interface.
|Estimate=32
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL/EPOD
|Area=Various
|Description=Lot number processing.
|Estimate=32
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Interface
|Description=CTL-EPOD Interface changes.
|Estimate=16
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Reports
|Description=EBB operational reports.
|Estimate=8
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Reports
|Description=Operational report (loading sheet or driver manifest) to include run sequence.
|Estimate=3.5
|Notes=
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL/EPOD
|Area=Interface
|Description=Keep desk loads open for longer periods.
|Estimate=11.5
|Notes=2
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=EPOD
|Area=Reports
|Description=Modify POD/POC report to include new UDF fields.
|Estimate=1.5
|Notes=4
}}
{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=CTL
|Area=Extracts
|Description=Extracts to report reason codes.
|Estimate=3.5
|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.
#Optional additional development.
#Estimates are total number of days, and include specification and unit testing. They do not include project management, system testing, release or implementation costs.
#Free of charge - listed here for completeness.


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=CTLTMS
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Paul Griffiths
|Rev1Title=EBB Paper Representative
|Rev2=Matt Tipping
|Rev2Title=OBS Logistics Representative
}}</div>
[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:SystemCode}}]]

FS 344274 SCR-343463-04 EBB Paper POD POC Format

2017-08-10T11:18:01Z

Tippingm: v1.0 - Review and Issue

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|EBB Paper POD/POC Format}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344274 SCR-343463-04}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-04: EBB Paper POD/POC Format

Once jobs are completed, then will be confirmed with the C-ePOD server. After this confirmation, a POD/POC report may be produced.

All photos taken by the driver during the execution of the job (i.e. at cancellation of product, change quantity of product, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view.

The format attached to the job group is the format that will be produced from the Admin console and displayed for customers when requested through ''CALIDUS'' Portal.

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

[[file:REQ_343463_POD1.png|border|600px]]
 ''Prototype EBB Papers POD Format'' 

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

Product Details, expected to be shown on every page, expected to show up to 10 products per page:
* ORDER NO - the order number against the product
* QTY - The actual quantity of the product delivered, as confirmed by the driver.
* UNITS - the unit type against the product
* QUALITY & DESCRIPTION - The description of the product, and the FSC number (if provided) from the Long Description.
* PACKS - the pack size, from the case quantity.
* KGS - the weight of the product

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

== Scope ==
This change will be applied to system version 4.X.

The definition of the exact fields used for this report are to be confirmed as part of this functional specification. These are dependent on the interface mapping. Specifically the data affected is:
* The Dates and Times displayed
* The Branch


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
Each Job Group will be configured with the POD/POC format.

[[file:FS_344273_Admin_JobGroups1.png|border|600px]]
 ''Job Groups Maintenance'' 


= Functional Description =
== Format "EBB Paper" ==
The report will be produced through the Configurable POD Report format (ConfigPOD.aspx).

A data report (on EPOD_CONFIG_REPORT) will be created matching the prototype format created.

The format created will have the name "EBB Paper" (in ECR_NAME) and will added to the list of POD/POC formats that can be selected from the Site and Job Group screens (being added to EPOD_LIST_ITEMS for the drop-down lists on these screens).

Settings for the configurable report are stored on EPOD_CONFIG_REPORT and are as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
! Data Field !! Value !! Description
|-
| ECR_NAME || "EBB Paper" || The name of the report.
|-
| ECR_ROWS_FIRST_PAGE || 10 || The number of detail rows on the first page of a multi-page report, including the title line.
|-
| ECR_MAX_ROWS_SINGLE_PAGE || 10 || The number of detail rows on a single page report, including the title line.
|-
| ECR_ROWS_CONTENT_PAGE || 10 || The number of detail rows on a (non-first or last) page of a multi-page report.
|-
| ECR_ROWS_LAST_PAGE || 10 || The number of detail rows on the last page of a multi-page report
|-
| ECR_ALT_ROWS_IND || 0 || Whether odd and even detail rows are formatted differently (1) or not (0).
|-
| ECR_INC_CANCELLED_IND || 0 || Whether to include cancelled details lines (containers or products) on the report (1) or not (0).
|-
| ECR_INC_IMAGES_IND || 1 || Whether to include images on the viewed report (1) or not (0).
|-
| ECR_EMAIL_IMAGES_IND || 0 || Whether to include images on the PDF report generated for emails (1) or not (0).
|-
| ECR_INC_PRODUCTS_IND || 1 || Whether Products are included on the report (1) or not (0).
|-
| ECR_PDF_ORIENT || P || The orientation of the report: (P)ortrait or (L)andscape.
|-
| ECR_CONTENT_SORT || NULL || The fields on which to sort detail (product or container) records, delimited by commas.
|-
| ECR_CONTENT_GROUP || NULL || The fields on which to group detail (product or container) records, delimited by commas.
|}

The format is populated as follows:

The Page Header will be defined in ECR_PAGE_HEADER and will be displayed on every page. The data will be populated as follows:

{| class="wikitable" border="1"
|- bgcolor="silver"
! Report Item !! Data Fields !! Description
|-
| Company Logo || EPOD_JOB_GROUPS.EPL_LOGO || The logo taken from the job group, if a logo exists, otherwise taken from the site.
|-
| "ELLIOTT BAXTER & COMPANY LIMITED" Delivery Note || EPOD_JOB.EPL_JOB_TYPE ||Fixed text, displaying Delivery or Collection depending on the Job Type.
|-
| Mr EBB Image ||  || Base64-encoded image embedded in the header.
|-
| Invoice To || EPOD_CUSTOMER || Taken from the customer address. Including Name, Address Lines and Postcode.
|-
| "Deliver To" || EPOD_JOB.EPL_JOB_TYPE || Fixed text, displaying Deliver or Collect depending on the Job Type.
|-
| Deliver To || EPOD_JOB_ADDRESS || Taken from the job address. Including Name, Address Lines and Postcode.
|-
| "Delivery Instructions" || EPOD_JOB.EPL_JOB_TYPE || Fixed text, displaying Delivery or Collection depending on the Job Type.
|-
| Delivery Instructions || EPOD_JOB.EPL_JOB_INSTRUCTION || The job instructions.
|-
| DATE || EPOD_JOB.EPL_START_PLANNED_DATE || The planned start date, in dd/mm/yyyy format.
|-
| BRANCH || EPOD_JOB.EPL_OWNER_NAME || The sales territory.
|-
| DEL DATE || EPOD_JOB.EPL_START_PLANNED_DATE || The planned start date, in dd/mm/yyyy format.
|-
| DELIVERY TIME || EPOD_JOB.EPL_START_PLANNED_TIME || The planned start time, in hh:mm format.
|-
| S TIME || EPOD_JOB.EPL_START_ACTUAL_TIME || The actual start time, in hh:mm format.
|-
| E TIME || EPOD_JOB.EPL_END_ACTUAL_TIME || The actual end time, in hh:mm format.
|-
| DEL NOTE NO || EPOD_JOB.EPL_JOB_CODE || The SO number.
|}

Product details will be shown on every page, showing up to 10 products per page, as defined by the report settings above.
The reported elements will be taken from EPOD_PRODUCT. Cancelled products (i.e. those with a status of "X" and a quantity of 0) will not be shown in this section.
The detail table header will be defined in ECR_CONTENT_TITLE as shown below.
Each page will fill the detail table to the maximum amount per page, defined by entering an empty row definition in ECR_CONTENT_EMPTY.

Each row will be defined in ECR_CONTENT_ROW as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
! Report Item !! Data Fields !! Description
|-
| ORDER NO || EPOD_PRODUCT.EPL_CUST_REF || The customer's order number.
|-
| QTY || EPOD_PRODUCT.EPL_PRODUCT_QTY_ACTUAL || The actual quantity of the product delivered, as confirmed by the driver.
|-
| UNITS || EPL_UNIT_TYPE || The UOFM, as stored from the interface
|-
| QUALITY & DESCRIPTION || EPOD_PRODUCT.EPL_DESCRIPTION_LONG || The full description and FSC text, as held in the Long Description field in C-ePOD. These will be displayed on two lines, substituting the CR/LF characters with an HTML Line Break tag.
|-
| PACKS || EPL_PRODUCT_QTY_ACTUAL / EPL_PRODUCT_QTY_CASE || The number of packs. This is a calculated value (denoted by "CALC:") of the delivered quantity divided by the pack size, displayed with no decimal places.
|-
| KGS || EPOD_PRODUCT.EPL_PRODUCT_WEIGHT || The total weight of the delivered product. The weight will be sub-totalled.
|}

The Page Footer will be defined in ECR_PAGE_FOOTER and will be displayed on every page. The data will be populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
! Report Item !! Data Fields !! Description
|-
| "Please be sure to check..." || EPOD_JOB.EPL_TNCS || T&Cs as signed for by the customer at the point of signing for the job. These are configured against the Job Group and are expected to be "Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which
is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk". Note that each job group may have different configured T&Cs.
|-
| Total Wgt || TOT0 || The KGS subtotal, formatted with no decimal places.
|-
| Signature || EPOD_JOB.EPL_JOB_SIGNATURE || The customer's signature. If not present, this should be a blank image rather than the standard "Image Not Available" text.
|-
| Print Name || EPOD_JOB.EPL_CUST_SIGNATORY || The signatory, captured by the driver on the device when the customer signs.
|-
| Date || EPOD_JOB.EPL_END_ACTUAL_DATE || The actual end date, when the signature was obtained, in dd/mm/yyyy format.
|-
| Signed on behalf of: || EPOD_JOB.EPL_JOB_SIGNATURE || The driver's signature, for unmanned locations. If not present, this should be a blank image rather than the standard "Image Not Available" text.
|-
| Print Name || EPOD_USER.EPL_USER_NAME || The driver's name, for unmanned locations
|-
| Date || EPOD_JOB.EPL_END_ACTUAL_DATE || The actual end date, when the signature was obtained, in dd/mm/yyyy format.
|-
| No 1 for Service Image ||   || Base64-encoded image embedded in the footer.
|-
| "Only products identified ..." ||   || Fixed text.
|}


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new POD report format
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that the report format works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Job Groups and Site screens that the new EBB Paper report format can be set.
|Result=The new EBB Paper report format can be set.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=POD/POC Report
|Notes=Ensure there is a completed job with Products, configured to the "EBB Paper" POD/POC format.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report on the completed job.
|Result=The report layout is as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=0.75
|ETS=0
|EDEV=2.5
|ESTT=0.25
|EIMP=0.25
|EPM=0.25
|REQ=0
|EST=0
|FS=0.75
|TS=0
|DEV=2.5
|ST=0.25
|IMP=0.25
|PM=0.25
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=Customer Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344275 SCR-343463-03 EBB Paper Mobile Device Styling

2017-08-10T11:16:34Z

Tippingm: v1.0 - Review and Issue

<div class="noprint">
{{#vardefine:Client|JBG}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Custom Mobile Device Styling}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344275 SCR-343463-03}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-3: General Mobile Device Styling

== Solution Overview ==
The application will have a customised style created for EBB Paper, which will include:
* The logo on the login page.
* Numeric password entry at Login
* A defined Job List style.
* A defined Product List style.
* Removal of the "Has this Delivery been checked" check box on the Job Details screen.

== Scope ==
This change will be applied to system version 4.X.

The information displayed on these mobile device screens is subject to the data mapping for the EBB Paper project.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
Each depot will have a site created for it.

A new PDA Style will be created:
* "EBB", labelled as "EBB Paper".

The C-ePOD site will be linked to the appropriate PDA Style through the Admin Sites Maintenance screen.

[[File:FS_344275_Admin_Site1.png|border|600px]]
 ''Admin Site Maintenance Screen'' 

Each C-ePOD site will have the appropriate EBB Paper logo uploaded to it, and will be configured to show the Job Code on the device.


= Functional Description =
== EBB Paper Style Changes ==
A style will be created using the style creator, called "EBB" with description "EBB Paper".

The basic layout and colour scheme will be taken from the existing "OBS2" style.

The Login screen will display as follows:
* The logo will be displayed from the Site logo uploaded within the ''CALIDUS'' ePOD Admin system.

The Job List will display only the following data per job:
* Job ID, configured to be the Customer's Reference
* Type (Collection or Delivery)
* Customer Name
* Planned Date only, in standard format
* Post Code

The Collection/Delivery Address screen will display as follows
* The "Collection/Delivery Checked" box will be removed

The Product List will show only the following data per item:
* Product Barcode ID (EPL_PRODUCT_CODE)
* Product Description (EPL_DESCRIPTION)
* Pack Size (EPL_PRODUCT_QTY_CASE)
* UOM (EPL_UNIT_TYPE)
* Quantity (EPL_PRODUCT_QTY_PLANNED)

The Signature screen will display as follows:
* The signatory will be blank at all times.

All other items on all screens will display as per the default system style.

{{Note}} The style has been prototyped and can be seen in the development system.

Screen-shot samples:

<gallery widths=300px heights=220px perrow=2>
File:FS_344275_Login1.png|''Login''
File:FS_344275_Login2.png|''Numeric password''
File:FS_344275_JobList1.png|''Job List''
File:FS_344275_ColDel1.png|''Collection/Delivery Details''
File:FS_344275_Products1.png|''Products List''
File:FS_344275_Products2.png|''Products Info''
File:FS_344275_Signature1.png|''Signature''
</gallery> 


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB Paper mobile device style
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test the new EBB Paper style.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Mobile Device
|Notes=Ensure there are "EBB Paper"-type jobs available for execution on the device.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure to the "EBB Paper" style. Load the mobile device app on a device and complete a job.
|Result=The login screen should show the correct logo. The Job list should be configured as expected. The "Deliver Checked" check box should not be present. The Products list should be as expected. No Signatory should be present on customer signature.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=0.25
|ETS=0
|EDEV=0.25
|ESTT=0.25
|EIMP=0.25
|EPM=0.0
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=0.0
|ST=0.0
|IMP=0.0
|PM=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Eliott
|Rev2Title=Customer Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2017-08-10T09:51:06Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

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

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

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

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

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

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

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

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

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

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

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

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

For example:
* "DAVID EASTMAN" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

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

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

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

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

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

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

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

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

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

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

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

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

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

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

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

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

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 0600
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

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

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

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

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

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

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

== Scope ==
This change will be applied to system version 3.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery> 

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery> 

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery> 

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery> 

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

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

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery> 


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery> 

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery> 

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag contains the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

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

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - "P" if the '''driver''' attribute is explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C" or "X"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip
|}

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip
|}

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 0600
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 1400.
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || 1
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=2.5
|ETS=0
|EDEV=15.5
|ESTT=3.50
|EIMP=1.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2017-08-10T09:49:33Z

Tippingm: v1.0 - Review and Issue

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

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

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

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

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

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

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

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

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

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

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

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

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

For example:
* "DAVID EASTMAN" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

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

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

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

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

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

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

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

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

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

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

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

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

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

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

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

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

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 0600
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

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

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

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

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

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

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

== Scope ==
This change will be applied to system version 3.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery> 

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery> 

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery> 

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery> 

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

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

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery> 


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery> 

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery> 

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag contains the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

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

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - "P" if the '''driver''' attribute is explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C" or "X"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip
|}

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip
|}

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 0600
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 1400.
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || 1
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=4.0
|ETS=0
|EDEV=18.5
|ESTT=2.75
|EIMP=0.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

REQ 343463 EBB Paper Solution Design

2017-06-23T13:32:45Z

Tippingm: Review

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|Elliott Baxter and Co}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|EBB Paper Solution Design}}
{{#vardefine:Version|0.5}}
{{#vardefine:Date|23rd June 2017}}
{{#vardefine:Reference|343463}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 08/06/2017 at the EBB Paper office in Farnborough, and amended with further details from emails of additional details and clarifications from the customer.



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


* The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the C-ePOD Client application.
* Changes relating to information passed through to {{#var:System}} from external systems (i.e. TMS and ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
* Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.


{{ #vardefine: SCR | 0 }}


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



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

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

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

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

Main Office Address:

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

There are 9 distribution sites/sales offices:
* Birmingham
* Bristol
* Farnborough
* Glasgow
* Hemel Hempstead
* Manchester
* Newcastle
* Sheffield
* Thurrock

Contacts:
* Paul Griffiths - IT Director - p.griffiths@ebbpaper.co.uk
* Rebecca Elliott - Project Sponsor - R.Elliott@ebbpaper.co.uk
* Terry Dixon

OBS Logistics Contacts:
* Matt Tipping - Project Manager - Matthew.Tipping@obs-logistics.com
* Matt Turner - Sales/Account Manager - Matthew.Turner@obs-logistics.com
* Warren Wright - Sales/''CALIDUS'' VEhub - Warren.Wright@obs-logistics.com
* Tony Walker - Solution Design - Tony.Walker@obs-logistics.com

== Existing System Processes ==
The core systems for the business are an externally-provided ERP (GP) and TMS (MSA), with OBS Logistics' systems as follows:
* ''CALIDUS'' ePOD - execution.
* ''CALIDUS'' VEhub - vehicle checks.
* ''CALIDUS'' Portal TTM - tracking.
* TomTom - navigation.

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

The operational processes will be:
* Orders are entered into the ERP.
* ERP interfaces the orders to TMS.
* When orders are manifested, this creates an XML file with basic order and trip details.
* A bespoke interface in ''CALIDUS'' ePOD will pick up the XML file and process this, retrieving additional details of the product lines and the addresses from the ERP.
* {{#var:System}} executes jobs and captures the actual delivery quantities, additional information and signatures.
* TomTom Nav is used for navigation to the destination.
* {{#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 ''CALIDUS'' VEhub, the {{#var:System}} client application and the built-in TomTom navigation applications. The TomTom devices are expected to be ordered from Fleet Trak after the completion of the requirements session.

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

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

{{Note}} It is recommended that the steps to commission the devices are as follows:
* Order the SIM cards.
* Order the devices.
* Fleet Trak to install the SIM cards in the devices and pre-load the applications.

The software will be rolled out as follows:
* ''CALIDUS'' VEhub - All depots
* ''CALIDUS'' ePOD - Farnborough
* ''CALIDUS'' ePOD - Other depots
* ''CALIDUS'' TTM

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

The operation will expect to execute the following movement types:
* Trunk
* Radial Delivery
* Desk Collect

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

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a vehicle of "WAREHOUSE".

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

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

Roughly 30 new delivery addresses are created each day.

A list of email addresses for the branches is required

Certain data is required for configuration of all OBS systems being installed, such as:
* Depots
* Drivers, including passwords/PINs
* Vehicles, including Registration, Make and Model
* Trailers

Lot-controlled items are delivered in this operation. Details are to be provided by the customer, including examples. It is believed that, at this time, this is not a go-live requirements for the implementation.

Further example files have been provided for trunks. These need to be assessed and detailed in the functional specification stage.

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke Import Interface
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

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

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file.

The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

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

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

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

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

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

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

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBO ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

{{Warning}} The interface must identify the Site (the executing depot) and the Owner (the originator). Confirmation is required as to what data from the interface files contain this information. This may be confirmed at functional specification stage for this interface change.

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

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

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

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* ISTIN - transfer of stock between depots (inter-warehouse transfer or IWT)
* RTN - Collection from customer.

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

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

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

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

The start and end planned time (in columns "S Time" and "E Time") will be used for the start and end planned time for the jobs. If these are not present, the DelTime column will be used. If this is not present, the planned start and end times will be defaulted to 0600 and 1400 respectively.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Trunk
** No Driver or Customer Signature
** Deliver All functionality enabled
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

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

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). For these products, the import process will set the quantity to 1 and store the actual quantity in another field, which will be displayed on the mobile device.

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS -Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be set to 1. Quantity in file will be put in Item Type field.
* METRES SQUARED - quantity will be set to 1. Quantity in file will be put in Item Type field.
* LINEAR METRES - quantity will be set to 1. Quantity in file will be put in Item Type field.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Set to 1 and put in Item Type field ||TONNE, METRES SQUARED, LINEAR METRES
|}
Any not on the list would follow the last rule (i.e. set quantity to 1 and put the quantity in the item type)

Further analysis is required on this and confirmation from the customer has been requested. If not appropriate, development work must be undertaken to change C-ePOD and C-PORTAL to handle decimal values.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Support decimal values in quantities
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Trunk movements are defined as movements between two depots (sites) defined in the list above.

Trunk orders created will include the products - there could up 100 or more products on the trunk moves.

{{Note}} If the trunk of an order is cancelled, the radial delivery of the job will not be planned or manifested and therefore C-ePOD will not receive it, so it will never be executed. This is as expected - no further functionality within C-ePOD is required to attempt to cancel onward deliveries of the same order if the prior delivery is cancelled.

For deliveries that are trunked and then refused by the customer, stock is either held at the delivering depot (if it stocks this product) or a separate IWT order is generated to transfer the stock back to the originating depot. This will generate an order for C-ePOD, which will be treated as any other trunk or IWT order.

== Administration ==
The ''CALIDUS'' ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface (Admin console) and a mobile device application for use in completing jobs, consisting of pick-ups (collections) and drop-offs (deliveries).

The {{#var:System}} Administration console is a web-based application that handles all of the administrative side of the C-ePOD devices.

{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the EBB Paper network for all users that require it.

The purpose of the application can be broken down into the following sections:
* To create and maintain users of the ePOD devices.
* To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
* To create Jobs of all types and group them together onto Loads.
* To assign Loads to Users and Vehicles.
* To view the Jobs and Loads created.
* To track progress against the Loads, Jobs, Vehicles and Users.
* To print or email a POD/POC.

It is confirmed that ''all'' Loads will be assigned to Vehicles through the ERP import interface.

A facility to manually assign Loads to drivers and vehicles for problem-solving purposes.

The resource allocation may be managed through the following mechanisms:
* Through the Load, assigning a user directly
* Through the User, selecting from any Pending Load.

[[file:REQ_336500_Admin_Users3.png|border|600px]]
[[file:REQ_336500_Admin_Users1.png|border|600px]]
 ''Assigning a User to Loads'' 

[[file:REQ_336500_Admin_Load3.png|border|600px]]
[[file:REQ_336500_Admin_Load2.png|border|600px]]
 ''Assigning Loads to a user'' 

If loads are created without a driver assigned (vehicle will always be assigned through the interface), the driver will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

== ''CALIDUS'' VEhub ==
The ''CALIDUS'' VEhub system is used to:
* Capture Vehicle Checks
* Asset Tagging at locations
* Capture Accident Reports

{{Note}} ''CALIDUS'' VEhub is already configured for EBB Paper use and is ready to be used. It is likely that this will be rolled out to all depots as soon as possible. However, note that C-VEhub is not part of this solution design document, and will configured as part of the implementation of this project.

As part of this project, C-VEhub will be created for each depot to access their vehicles and the data entered through the mobile application. C-VEhub Admin access will be provided for every branch.

{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the EBB Paper network for all users that require it.

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

C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot.

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Improved searching on tables
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

It is noted that the insurance cover note will be provided to the drivers through a cloud-enabled repository, such as DropBox.

== C-ePOD Mobile Device Application ==
The mobile device application will be used to execute all types of trips executed by the depots, namely:
* Radial Deliveries and customer collections
* Trunk trips
* Desk Collections
The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other trip types.

Note that full details of the use of each process on the mobile device are not included in this solution design, but can be obtained from the user guide, referenced in this document's appendices.

== C-ePOD Mobile Device Login ==
The application will have a customised style created for EBB Paper, which will include:
* The logo on the login page.
* Numeric password entry at Login
* A defined Job List style.
* A defined Product List style.
* Removal of the ''Has this Delivery been checked'' check box on the Job Details screen.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=General Mobile Device Styling
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Login1.png|''Log In''
</gallery> 

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

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

{{Note}} Vehicle checks will be completed through the ''CALIDUS'' VEhub application and are not integrated into {{#var:System}}. ''CALIDUS'' VEhub is not within the scope of this document. There will be no vehicle checks implemented within ''CALIDUS'' ePOD for EBB Paper processes.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_JobList1.png|''Job List''
</gallery> 

The layout of the job list as demonstrated is acceptable to the customer, with one modification. The time will not be displayed on the Job List, through configuration of the style on the device. The defined elements are:
* The order number (Job Code)
* The job type
* The location (address name)
* The planned start date (no time)
* The post code from the location

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

The screen will display the status of the jobs on the load through a coloured outline or background, as follows:
* Red - Cancelled
* Green - Completed
* Blue - Completed (with amendments)
* Yellow - In Progress
* None - Pending/Incomplete
Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed.

The jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.

The '''Menu''' button can be used here to allow the following options:
* Refresh Load - Refresh the Load/Worklist from the server, to pick up any updates
* Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
* Log Out
* Change Vehicle
* Cancel Jobs
* Consolidate Jobs
* Deconsolidate Jobs
There are also some bug-reporting options available on this pop-up menu, which may be asked to be used from time to time by the OBSL or client support staff.

The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:
* No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed (see the following for details on cancellation for the business units).
* Confirm re-sequencing allowed - this requests the user to confirm first.
* Always allowed - no confirmation.
It is expected that re-sequencing of timed jobs will be allowed, but with a warning displayed to the drivers.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs if, for example, if quantities have been amended, products added, etc. It is noted that this should not occur.

Long-pressing against the line will display some options from a pop-up menu:
* ''Details'' - show the Job Details screen (following).
* ''Cancel'' - the selected job or jobs will be cancelled. The application will display an Exception screen and prompt for entry of a reason code indicating why this job was cancelled.
* ''Group Jobs Together'' - if configured for Consolidation, this option allows the selected job to be quickly grouped with another.
* ''Break Group'' - if configured and the selected row is a consolidated group of jobs, this option will break the group back into individual jobs and refresh the job list.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_JobDetail1.png|''Address & Contact''
File:REQ_343463_PDA_JobDetail2.png|''Instructions''
</gallery> 

The screen has several sections and tabs, showing:
* The Job Type (Collection, Delivery, Service)
* The customer details (Customer Code, Name, Address and Postcode)
* The contact information (Contact name and number)
* The planned collection/delivery window for the job, including the times.
* The Instructions for the job
Clicking on the tabs will display the information.

The ''Instructions'' tab will show instructions for the job, as well as any additional information passed through for the job.

{{Note}} The screen does not allow the user to contact the customer (through either text or phone) when using TomTom PRO or BRIDGE devices, as they do not allow telephony. Other devices will allow this and, in this case, the application will display appropriate icons to allow the drivers to accomplish this.

=== Cancelling a Job ===
For EBB Papers, the driver can cancel jobs by clicking the '''Cancel Job''' button on the job detail screen.

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

{{Note}} Whether or not a picture is required for a job cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Job Only' then a picture must be taken to cancel a job, otherwise the picture is optional. If Job Cancellation is enabled, it is expected that the application will ''not'' be configured to require a photo, although one can still be taken if required.

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

== Navigation and Arriving ==
For EBB Paper, which will not have the orders sent to WEBFLEET, the TomTom NavApp will be sent the address by the C-ePOD app, and will commence immediate navigation to the address.

The driver will select '''Start Job''' from the Job Details screen.

{{Note}} Delivery instructions are provided from several sources. These instructions will be concatenated in the Instructions shown above. If there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

{{Note}} It is expected that re-sequencing of jobs will be allowed for EBB Paper, but with a warning. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and must confirm to continue.

Once started, the device will display a navigation button. Clicking this will start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp. For non-TomTom devices, the application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.

Once arrived at the destination, the driver will switch to the {{#var:System}} mobile application. This can be through the 'All apps' icon on the home screen or (expected to be) through a configured short-cut on the task bar for the TomTom devices. For standard Android devices, the app switcher can be used to switch back to the C-ePOD mobile application.

The driver will then indicate arrival and start processing the Job by clicking the '''Arrive Job''' button.

When clicking the button to start, arrive at or deliver the job, the application performs a check whether the job has been changed since it was loaded on the device, to ensure that the latest data is on the device for the job. If there are changes, the driver will be informed and the screen will refresh.

The device will move on to the Delivery or Collection process, depending on the job type.

== Radial Delivery Process ==
The driver process at a delivery point is:
* Arrive at site (recording time of arrival).
* Confirm delivery of product.
* Complete delivery (recording time off site)

Deliveries will consist of multiple loose products.

The following are the standard tabs that are expected to be displayed:
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery1.png|''Job Details Tab''
File:REQ_343463_PDA_Delivery2.png|''Job Details Tab - Addresses''
File:REQ_343463_PDA_Delivery3.png|''Products Tab''
File:REQ_343463_PDA_Delivery4.png|''Notes Tab''
</gallery> 

The ''Job Details'' tab has multiple sections:
* Contact information
* Address information - if supplied, both current address and origin address are shown.
* Job Instructions

As part of the styling changes, the checkbox "Has this delivery been checked?" will be removed from the style.

From the ''Products'' tab, the device will show a list of the products to be delivered, which will be styled to show only the following elements:
* The Product Code
* The Product Description
* The Unit Type
* The Item Type
* The Planned Quantity

{{Note}} If confirmed, this list will also include a "UOM Qty" field, containing the decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc. In this case, the quantity of the item will always be 1.



Actions against the products can be activated by long-pressing against the row, and have the following actions:
* ''Deliver X''
* ''Change Quantity''
* ''Comments''
* ''Cancel''
* ''Info''
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery5.png|''Products Long-press Pop-up''
File:REQ_343463_PDA_Delivery6a.png|''Product Info Pop-up''
File:REQ_343463_PDA_Delivery6b.png|''Product Info Pop-up (More)''
</gallery> 

{{Note}} If confirmed, this Product Info pop-up will also include a "UOM Qty" field, containing the decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc.

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

When all products have been confirmed as delivered or cancelled, the Delivery process will return to the Job Details tab, where a '''Complete''' button will be displayed, to complete the job. It is then possible to review the list of products delivered and change this if required. The list will display a border and status to indicate whether the products have been delivered:
* Red - Cancelled
* Amber - Delivered with an amendment (changed quantity)
* Green - Delivered in full.
The status and the Planned and Actual quantity will be displayed for confirmation.

When the driver has confirmed that everything is complete and clicked the '''Complete''' button, this screen will close and the user will be directed to the Job Completion process.

=== Delivering a Product ===
Each product on the list can be confirmed as delivered by either:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
* Clicking '''Deliver All''' on the ''Job Details'' tab.

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

The system will be configured with "Deliver All" functionality. This can be used to mark all pending products as delivered.
This is most likely to be used by:
* Check all products and quantities from the information on the Product list.
* Cancelling or changing the quantity of any items with discrepancies, using the following processes.
* Clicking '''Deliver All''' for the remaining products on the list.
This process is likely to be used extensively for Trunk deliveries.

{{Note}} If confirmed, products with a decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc will have a quantity set as 1.

=== Changing a Product Quantity ===
The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed.
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery7.png|''Exception - Change Product Quantity''
</gallery> 

For clarification, the product code and description and the job and customer are also displayed here.

The application will be ''not'' configured so that the driver is required to take a picture associated with this change of quantity.

If zero is entered as the new quantity, the application will cancel the product and remove it from the product list. If the quantity is changed (and is not set to zero), the product will be marked as having the quantity entered delivered and will be removed from the product list.



{{Note}} If confirmed, products with a decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc will have a quantity set as 1 and the quantity may only be changed to 0 (i.e. cancelled). Comments may be added, however.

=== Cancelling a Product ===
Where delivery of a product is refused, the driver process will be to cancel the product delivery with the pop-up option ''Cancel''. This is necessary, as the process will be to get the customer to sign for the non-delivery of the product.

As with quantity change, the exception screen will be shown where the driver can enter the reason for the cancellation.

The user will also be able to optionally take a picture associated with this cancellation.

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

The application will ''not'' be configured so that the driver is required to take a picture associated with cancellation of products.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery8.png|''Exception - Commenting on a product''
</gallery> 

{{Note}} Reason codes are the operation's to maintain and will be maintained only within C-ePOD, as they are never to be updated back to the ERP.

==Collection (Returns) Process==
It is expected that, where planned returns of products are created, these collections will be interfaced to {{#var:system}} as Collection jobs.

The collection process will be almost identical to that described above, substituting Collection instead of Delivery.

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

== Job Completion ==
All jobs will be sent to the {{#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 prompt for Customer Signature for Radial Collections and Deliveries, and for Desk Collections.
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Signature1.png|''Customer Signature and T&Cs''
File:REQ_343463_PDA_Signature2.png|''Customer Signature and Products''
</gallery> 

The signatory will by configuration be set to be blank and always required entry. The driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm.
* The quantity of products being collected/delivered.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under or to the right of the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time and is expected to be finalised during implementation. These are currently expected to be:
* Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

Unmanned locations or delivery out of hours may require that the driver sign PP for the customer, then taking photos to indicate the successful delivery. This Unmanned Location Process will be configured for this implementation. {{Note}} This is dependent on a development in progress at this time and is a dependency of this implementation.

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

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

If driver signature is required, this displays very similarly to the customer signature above, with some differences:
* The standard collection T&Cs will not be shown. Special Driver T&Cs can be configured if required.
* The driver name will be pre-set from the logged-on driver and cannot be changed.
If driver signature is prompted for, it must be entered and cannot be skipped.

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

The driver will be able to view the captured image or re-take the photos.

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Signature3.png|''Job Photo''
</gallery> 

As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, etc) updated. The updates are sent whenever the driver has a viable data connection, and may be delayed until that time.

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

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

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

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

The Load for the Trunk drivers will be heavily consolidated, and will likely only contain 1 or 2 stops on the job list, with all jobs consolidated together at the depots.

As mentioned, this delivery process is likely to make substantial use of the Deliver All process, to identify that all products are delivered to the depot successfully.

When the driver delivers to the depot, the device will not prompt for any signatures, customer or driver. Instead, the process will return to the job list after confirmation that all product is delivered.

{{Warning}} Trailer swapping is performed by EBB. More detail on this process is required, but at this time it is expected that this will not be part of the C-ePOD execution and will be handled manually.

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

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

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

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

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

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

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

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

== POC/POD Documents ==
Once jobs are completed, then will be confirmed with the C-ePOD server. After this confirmation, a POD/POC report may be produced.

All photos taken by the driver during the execution of the job (i.e. at cancellation of product, change quantity of product, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view.

The format attached to the job group is the format that will be produced from the Admin console and displayed for customers when requested through ''CALIDUS'' Portal.

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

[[file:REQ_343463_POD1.png|border|600px]]
 ''Prototype EBB Papers POD Format'' 

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=EBB Paper POD/POC Format
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into {{#var:system}}.

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

Product Details, expected to be shown on every page, expected to show up to 10 products per page:
* ORDER NO - the order number against the product
* QTY - The actual quantity of the product delivered, as confirmed by the driver.
* UNITS - the unit type against the product
* QUALITY & DESCRIPTION - The description of the product, and the FSC number (if provided) from the Long Description.
* PACKS - the pack size, from the case quantity.
* KGS - the weight of the product

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

{{Warning}} Definition of the exact fields used for this report will be confirmed at functional specification stage, dependant on the interface mapping, specifically:
* The Dates and Times displayed
* The Branch
* The quantities displayed is dependent upon how C-ePOD will store these values, dependent on the decimal quantity change specified in this document.

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

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

However, these automatic emails or exports may be configured at any time.

== Further Reporting and Queries ==
The {{#var:System}} Admin system allows admin users (i.e. non-PDA users) the ability to access loads, jobs and product details, as mentioned previously.

<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_Load2.png|''Loads''
File:REQ_336500_Admin_Job1.png|''Jobs''
File:REQ_336500_Admin_Containers1.png|''Products''
</gallery> 

When jobs are being processed, the status of the jobs and loads changes to show progress:
* Pending - not yet assigned to a driver.
* Assigned - Assigned to a driver, but not yet started. This is highlighted grey.
* In Progress - Started by the driver. This is highlighted yellow.
* Complete - Complete by the driver - This is highlighted green.
* Cancelled - Job cancelled by the driver. This is highlighted red.
* Complete (With Amendments) - job completed, but not exactly as planned. This is also highlighted blue.

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

User activity may also be accessed, to show auditing of messages from the user, for example:
* Log on
* Load picked up
* Job started
* Job arrived
* Job completed
* Load completed
* Log off

<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_UserTracking1.png|''User Tracking - Activities''
File:REQ_336500_Admin_UserTracking2.png|''User Tracking - Location''
</gallery> 

== Track and Trace ==
''CALIDUS'' Portal provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

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

''CALIDUS'' Portal is kept updated at all times by {{#var:System}} of all states of the loads and jobs, for example:
* The Trip itself.
* The Order itself.
* The sequence of the Order on the Trip
* When an order is in transit.
* When an order is collected and/or delivered.
* When an order is cancelled.
The messages identify any changes to quantities and reasons for these changes at all stages.

The interface from C-ePOD to C-PORTAL TTM must account for trunks of orders to determine the from and to locations for the orders in TTM. The jobs will be linked through the Job Code to determine this.

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

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

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Use defined Dwell time for ETA.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The following is a brief description of functionality available within ''CALIDUS'' Portal that has potential to be used by EBB paper and their customers if required. This is by no means a full list of all functionality available within ''CALIDUS'' Portal - the user guide (referenced in the Appendices of this document) contains the full details of the available functionality.

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

==== Order Enquiry ====

[[file:REQ_339867_TTM_OrdEnqParms.png|border|600px]]
 ''Order Enquiry Parameters'' 

[[file:REQ_339867_TTM_GenEnqParms.png|border]]
 ''General Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_339867_TTM_OrdEnqResults1.png|border|600px]]
 ''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 ====
[[file:REQ_339867_TTM_TripEnqParms.png|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_339867_TTM_TripEnqResults.png|border|600px]]
 ''Trip Enquiry Results'' 
These results can be expanded for further details of the Orders, and the order can be clicked to drill-down into specific details of the order.

This table data can also be exported to XML format in multiple ways:
* '''Manifest''' - Trip/Stop information
* '''Manifest/Order''' - Trip/Stop/Order information
* '''Order''' - Order Header information
* '''Order Detail''' - Order Header / Order Detail information

The screen supports configurable RAG colouration, to highlight trips that are late or incomplete, and ETAs.

==== Order Details ====
[[file:REQ_339867_TTM_OrderDetail1.png|border|600px]]
 ''Order Details'' 

Details can be found of the following:
* Events – the Messages received by the LOTS system via WMS, TMS and other systems.
* Info – Details of all of the header information stored on the system
* Route – Details of the trips/stops that the order is currently assigned to.
* SO Details – the Stock details received from the TMS or WMS.
* Reasons – Details of the Order level reasons placed against the order.
* Map – A map of the current location of the order (if co-ordinates have been supplied by an external system). The Mapping page will only be available to groups where the 'Mapping' parameter against the User Group is set to 'Available' and where licensing is available.
* Notes – Allows the entry of user notes against the order. These are only kept on the Portal system.
* Documents - Allows the upload/view of documents held in the Portal against the order.

[[file:REQ_339867_TTM_OrderDetail2.png|border|600px]]
 ''Order Event Details'' 
[[file:REQ_339867_TTM_OrderDetail3.png|border|600px]]
 ''Order Info Details'' 

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display ETA and Planned Time on Map screen
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Arrivals/Departures (Order Status) Screen ===
''CALIDUS'' Portal supports several Airport-style screens:
* Arrive/Depart screen
* Order Status screen
Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries. The recommended screen is the Order Status screen.

[[file:REQ_339867_TTM_OrderStatus1.png|border|600px]]
 ''Order Status Screen'' 

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

The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.

[[file:REQ_339867_TTM_OrderStatus2.png|border]]
 ''Order Status Parameters'' 

=== Customer (Order) Visibility Screen ===
This screen represents a combination of all the screens above in one place, to simplify access.

[[file:REQ_339867_TTM_OrderVis1.png|border|600px]]
 ''Order Visibility Parameters and results'' 

Similar selection criteria to the Trip/Order Enquiries and Order Status screens can be accessed from the left-hand panel. Results will be shown on the right.

When an order is selected, the Order Details page is displayed.

[[file:REQ_339867_TTM_OrderVis2.png|border|600px]]
 ''Order Visibility Details'' 

Clicking on each of the icons on the top of the page displays similar information to the other enquiry results screens. This screen also allows the user to maintain CRM-related notes and events.

[[file:REQ_339867_TTM_OrderVis3.png|border|600px]]
 ''Order Visibility CRM Details'' 


= Appendix A: Table of SCRs and Ballpark Estimates =


{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Integration|Description=Bespoke Import Interface |Estimate=27|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Database|Description=Support decimal values in quantities|Estimate=20|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=VEhub|Area=Admin|Description=Improved searching on tables|Estimate=6|Notes=3
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=General Mobile Device Styling |Estimate=1|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Reports|Description=EBB Paper POD/POC Format |Estimate=4|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=ETAs|Description=Use defined Dwell time for ETAs |Estimate=4|Notes=3
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=Map|Description=Display ETA and Planned time on map |Estimate=1|Notes=3
}} {{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.
# This change is required only if the OBS systems are required to store decimal quantities. Note also that this change covers C-ePOD and C-PORTAL only. Should C-TMS be used as part of this solution, this must be evaluated for change separately.
# These changes will be developed as part of the product improvement program internally at OBS Logistics and will be made available when complete.
# These changes will be delivered as part of the contracted delivery at no additional cost.


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD2
|Ref1=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=4.0
|RefDate1=21/07/2016
|Ref2=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=5.0
|RefDate2=23/12/2016
|Ref3=[[FS 291096 Interface with CALIDUS ePOD]]
|RefV3=1.1
|RefDate3=11/01/2017
|Ref4=Portal User Guide - TTM
|RefV4=6.9.20
|RefDate4=14/12/2016
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Rebecca Elliott
|Rev1Title=EBB Paper Representative
|Rev2=Matt Turner
|Rev2Title=OBS Logistics Representative
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 343463 EBB Paper Solution Design

2017-06-23T13:28:57Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|Elliott Baxter and Co}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|EBB Paper Solution Design}}
{{#vardefine:Version|0.5}}
{{#vardefine:Date|23rd June 2017}}
{{#vardefine:Reference|343463}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 08/06/2017 at the EBB Paper office in Farnborough, and amended with further details from emails of additional details and clarifications from the customer.



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


* The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the C-ePOD Client application.
* Changes relating to information passed through to {{#var:System}} from external systems (i.e. TMS and ERP) are subject to analysis and design, which may affect the other changes in this document or generate other work if the process described within this document cannot be followed by the external system.
* Modifications are required to the customer systems (ERP) to achieve the functionality described in this document.


{{ #vardefine: SCR | 0 }}


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



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

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

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

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

Main Office Address:

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

There are 9 distribution sites/sales offices:
* Birmingham
* Bristol
* Farnborough
* Glasgow
* Hemel Hempstead
* Manchester
* Newcastle
* Sheffield
* Thurrock

Contacts:
* Paul Griffiths - IT Director - p.griffiths@ebbpaper.co.uk
* Rebecca Elliott - Project Sponsor - R.Elliott@ebbpaper.co.uk
* Terry Dixon

OBS Logistics Contacts:
* Matt Tipping - Project Manager - Matthew.Tipping@obs-logistics.com
* Matt Turner - Sales/Account Manager - Matthew.Turner@obs-logistics.com
* Warren Wright - Sales/''CALIDUS'' VEhub - Warren.Wright@obs-logistics.com
* Tony Walker - Solution Design - Tony.Walker@obs-logistics.com

== Existing System Processes ==
The core systems for the business are an externally-provided ERP (GP) and TMS (MSA), with OBS Logistics' systems as follows:
* ''CALIDUS'' ePOD - execution.
* ''CALIDUS'' VEhub - vehicle checks.
* ''CALIDUS'' Portal TTM - tracking.
* TomTom - navigation.

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

The operational processes will be:
* Orders are entered into the ERP.
* ERP interfaces the orders to TMS.
* When orders are manifested, this creates an XML file with basic order and trip details.
* A bespoke interface in ''CALIDUS'' ePOD will pick up the XML file and process this, retrieving additional details of the product lines and the addresses from the ERP.
* {{#var:System}} executes jobs and captures the actual delivery quantities, additional information and signatures.
* TomTom Nav is used for navigation to the destination.
* {{#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 ''CALIDUS'' VEhub, the {{#var:System}} client application and the built-in TomTom navigation applications. The TomTom devices are expected to be ordered from Fleet Trak after the completion of the requirements session.

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

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

{{Note}} It is recommended that the steps to commission the devices are as follows:
* Order the SIM cards.
* Order the devices.
* Fleet Trak to install the SIM cards in the devices and pre-load the applications.

The software will be rolled out as follows:
* ''CALIDUS'' VEhub - All depots
* ''CALIDUS'' ePOD - Farnborough
* ''CALIDUS'' ePOD - Other depots
* ''CALIDUS'' TTM

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

The operation will expect to execute the following movement types:
* Trunk
* Radial Delivery
* Desk Collect

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

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a vehicle of "WAREHOUSE".

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

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

Roughly 30 new delivery addresses are created each day.

A list of email addresses for the branches is required

Certain data is required for configuration of all OBS systems being installed, such as:
* Depots
* Drivers, including passwords/PINs
* Vehicles, including Registration, Make and Model
* Trailers

Lot-controlled items are delivered in this operation. Details are to be provided by the customer, including examples. It is believed that, at this time, this is not a go-live requirements for the implementation.

Further example files have been provided for trunks. These need to be assessed and detailed in the functional specification stage.

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Bespoke Import Interface
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

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

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file.

The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

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

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

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

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

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

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

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBO ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

{{Warning}} The interface must identify the Site (the executing depot) and the Owner (the originator). Confirmation is required as to what data from the interface files contain this information. This may be confirmed at functional specification stage for this interface change.

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

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

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

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* ISTIN - transfer of stock between depots (inter-warehouse transfer or IWT)
* RTN - Collection from customer.

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

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

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

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

The start and end planned time (in columns "S Time" and "E Time") will be used for the start and end planned time for the jobs. If these are not present, the DelTime column will be used. If this is not present, the planned start and end times will be defaulted to 0600 and 1400 respectively.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Trunk
** No Driver or Customer Signature
** Deliver All functionality enabled
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

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

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). For these products, the import process will set the quantity to 1 and store the actual quantity in another field, which will be displayed on the mobile device.

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS -Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be set to 1. Quantity in file will be put in Item Type field.
* METRES SQUARED - quantity will be set to 1. Quantity in file will be put in Item Type field.
* LINEAR METRES - quantity will be set to 1. Quantity in file will be put in Item Type field.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Set to 1 and put in Item Type field ||TONNE, METRES SQUARED, LINEAR METRES
|}
Any not on the list would follow the last rule (i.e. set quantity to 1 and put the quantity in the item type)

Further analysis is required on this and confirmation from the customer has been requested. If not appropriate, development work must be undertaken to change C-ePOD and C-PORTAL to handle decimal values.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Support decimal values in quantities
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Trunk movements are defined as movements between two depots (sites) defined in the list above.

Trunk orders created will include the products - there could up 100 or more products on the trunk moves.

{{Note}} If the trunk of an order is cancelled, the radial delivery of the job will not be planned or manifested and therefore C-ePOD will not receive it, so it will never be executed. This is as expected - no further functionality within C-ePOD is required to attempt to cancel onward deliveries of the same order if the prior delivery is cancelled.

For deliveries that are trunked and then refused by the customer, stock is either held at the delivering depot (if it stocks this product) or a separate IWT order is generated to transfer the stock back to the originating depot. This will generate an order for C-ePOD, which will be treated as any other trunk or IWT order.

== Administration ==
The ''CALIDUS'' ePOD system provides functionality to handle the process of Proof of Delivery electronically. The system aids this process by providing both a management interface (Admin console) and a mobile device application for use in completing jobs, consisting of pick-ups (collections) and drop-offs (deliveries).

The {{#var:System}} Administration console is a web-based application that handles all of the administrative side of the C-ePOD devices.

{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the EBB Paper network for all users that require it.

The purpose of the application can be broken down into the following sections:
* To create and maintain users of the ePOD devices.
* To create and maintain reference data for the system (e.g. Reason Codes, Vehicles, Customers).
* To create Jobs of all types and group them together onto Loads.
* To assign Loads to Users and Vehicles.
* To view the Jobs and Loads created.
* To track progress against the Loads, Jobs, Vehicles and Users.
* To print or email a POD/POC.

It is confirmed that ''all'' Loads will be assigned to Vehicles through the ERP import interface.

A facility to manually assign Loads to drivers and vehicles for problem-solving purposes.

The resource allocation may be managed through the following mechanisms:
* Through the Load, assigning a user directly
* Through the User, selecting from any Pending Load.

[[file:REQ_336500_Admin_Users3.png|border|600px]]
[[file:REQ_336500_Admin_Users1.png|border|600px]]
 ''Assigning a User to Loads'' 

[[file:REQ_336500_Admin_Load3.png|border|600px]]
[[file:REQ_336500_Admin_Load2.png|border|600px]]
 ''Assigning Loads to a user'' 

If loads are created without a driver assigned (vehicle will always be assigned through the interface), the driver will be assigned automatically as the driver logs on to the device application and confirms which vehicle they are using.

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

== ''CALIDUS'' VEhub ==
The ''CALIDUS'' VEhub system is used to:
* Capture Vehicle Checks
* Asset Tagging at locations
* Capture Accident Reports

{{Note}} ''CALIDUS'' VEhub is already configured for EBB Paper use and is ready to be used. It is likely that this will be rolled out to all depots as soon as possible. However, note that C-VEhub is not part of this solution design document, and will configured as part of the implementation of this project.

As part of this project, C-VEhub will be created for each depot to access their vehicles and the data entered through the mobile application. C-VEhub Admin access will be provided for every branch.

{{Note}} Access to this Admin system is through a web browser, connecting to a provided URL for the system. Access to this URL must be allowed from the EBB Paper network for all users that require it.

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

C-VEhub will be configured to send email alerts of every defective vehicle check completed to the defined email addresses for each depot.

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Improved searching on tables
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

It is noted that the insurance cover note will be provided to the drivers through a cloud-enabled repository, such as DropBox.

== C-ePOD Mobile Device Application ==
The mobile device application will be used to execute all types of trips executed by the depots, namely:
* Radial Deliveries and customer collections
* Trunk trips
* Desk Collections
The below sections detail the flow of the radial deliveries predominantly, then indicate how these processes will be used to execute other trip types.

Note that full details of the use of each process on the mobile device are not included in this solution design, but can be obtained from the user guide, referenced in this document's appendices.

== C-ePOD Mobile Device Login ==
The application will have a customised style created for EBB Paper, which will include:
* The logo on the login page.
* Numeric password entry at Login
* A defined Job List style.
* A defined Product List style.
* Removal of the ''Has this Delivery been checked'' check box on the Job Details screen.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=General Mobile Device Styling
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Login1.png|''Log In''
</gallery> 

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

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

{{Note}} Vehicle checks will be completed through the ''CALIDUS'' VEhub application and are not integrated into {{#var:System}}. ''CALIDUS'' VEhub is not within the scope of this document. There will be no vehicle checks implemented within ''CALIDUS'' ePOD for EBB Paper processes.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_JobList1.png|''Job List''
</gallery> 

The layout of the job list as demonstrated is acceptable to the customer, with one modification. The time will not be displayed on the Job List, through configuration of the style on the device. The defined elements are:
* The order number (Job Code)
* The job type
* The location (address name)
* The planned start date (no time)
* The post code from the location

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

The screen will display the status of the jobs on the load through a coloured outline or background, as follows:
* Red - Cancelled
* Green - Completed
* Blue - Completed (with amendments)
* Yellow - In Progress
* None - Pending/Incomplete
Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed.

The jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.

The '''Menu''' button can be used here to allow the following options:
* Refresh Load - Refresh the Load/Worklist from the server, to pick up any updates
* Show All / Outstanding Jobs - Toggle between showing all or only incomplete jobs.
* Log Out
* Change Vehicle
* Cancel Jobs
* Consolidate Jobs
* Deconsolidate Jobs
There are also some bug-reporting options available on this pop-up menu, which may be asked to be used from time to time by the OBSL or client support staff.

The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:
* No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed (see the following for details on cancellation for the business units).
* Confirm re-sequencing allowed - this requests the user to confirm first.
* Always allowed - no confirmation.
It is expected that re-sequencing of timed jobs will be allowed, but with a warning displayed to the drivers.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs if, for example, if quantities have been amended, products added, etc. It is noted that this should not occur.

Long-pressing against the line will display some options from a pop-up menu:
* ''Details'' - show the Job Details screen (following).
* ''Cancel'' - the selected job or jobs will be cancelled. The application will display an Exception screen and prompt for entry of a reason code indicating why this job was cancelled.
* ''Group Jobs Together'' - if configured for Consolidation, this option allows the selected job to be quickly grouped with another.
* ''Break Group'' - if configured and the selected row is a consolidated group of jobs, this option will break the group back into individual jobs and refresh the job list.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_JobDetail1.png|''Address & Contact''
File:REQ_343463_PDA_JobDetail2.png|''Instructions''
</gallery> 

The screen has several sections and tabs, showing:
* The Job Type (Collection, Delivery, Service)
* The customer details (Customer Code, Name, Address and Postcode)
* The contact information (Contact name and number)
* The planned collection/delivery window for the job, including the times.
* The Instructions for the job
Clicking on the tabs will display the information.

The ''Instructions'' tab will show instructions for the job, as well as any additional information passed through for the job.

{{Note}} The screen does not allow the user to contact the customer (through either text or phone) when using TomTom PRO or BRIDGE devices, as they do not allow telephony. Other devices will allow this and, in this case, the application will display appropriate icons to allow the drivers to accomplish this.

=== Cancelling a Job ===
For EBB Papers, the driver can cancel jobs by clicking the '''Cancel Job''' button on the job detail screen.

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

{{Note}} Whether or not a picture is required for a job cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Job Only' then a picture must be taken to cancel a job, otherwise the picture is optional. If Job Cancellation is enabled, it is expected that the application will ''not'' be configured to require a photo, although one can still be taken if required.

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

== Navigation and Arriving ==
For EBB Paper, which will not have the orders sent to WEBFLEET, the TomTom NavApp will be sent the address by the C-ePOD app, and will commence immediate navigation to the address.

The driver will select '''Start Job''' from the Job Details screen.

{{Note}} Delivery instructions are provided from several sources. These instructions will be concatenated in the Instructions shown above. If there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

{{Note}} It is expected that re-sequencing of jobs will be allowed for EBB Paper, but with a warning. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and must confirm to continue.

Once started, the device will display a navigation button. Clicking this will start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp. For non-TomTom devices, the application will show whatever app is installed on the device to handle navigation, or the Google Maps website if there is none. The app will immediately calculate a route to the destination address.

Once arrived at the destination, the driver will switch to the {{#var:System}} mobile application. This can be through the 'All apps' icon on the home screen or (expected to be) through a configured short-cut on the task bar for the TomTom devices. For standard Android devices, the app switcher can be used to switch back to the C-ePOD mobile application.

The driver will then indicate arrival and start processing the Job by clicking the '''Arrive Job''' button.

When clicking the button to start, arrive at or deliver the job, the application performs a check whether the job has been changed since it was loaded on the device, to ensure that the latest data is on the device for the job. If there are changes, the driver will be informed and the screen will refresh.

The device will move on to the Delivery or Collection process, depending on the job type.

== Radial Delivery Process ==
The driver process at a delivery point is:
* Arrive at site (recording time of arrival).
* Confirm delivery of product.
* Complete delivery (recording time off site)

Deliveries will consist of multiple loose products.

The following are the standard tabs that are expected to be displayed:
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery1.png|''Job Details Tab''
File:REQ_343463_PDA_Delivery2.png|''Job Details Tab - Addresses''
File:REQ_343463_PDA_Delivery3.png|''Products Tab''
File:REQ_343463_PDA_Delivery4.png|''Notes Tab''
</gallery> 

The ''Job Details'' tab has multiple sections:
* Contact information
* Address information - if supplied, both current address and origin address are shown.
* Job Instructions

As part of the styling changes, the checkbox "Has this delivery been checked?" will be removed from the style.

From the ''Products'' tab, the device will show a list of the products to be delivered, which will be styled to show only the following elements:
* The Product Code
* The Product Description
* The Unit Type
* The Item Type
* The Planned Quantity

{{Note}} If confirmed, this list will also include a "UOM Qty" field, containing the decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc. In this case, the quantity of the item will always be 1.



Actions against the products can be activated by long-pressing against the row, and have the following actions:
* ''Deliver X''
* ''Change Quantity''
* ''Comments''
* ''Cancel''
* ''Info''
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery5.png|''Products Long-press Pop-up''
File:REQ_343463_PDA_Delivery6a.png|''Product Info Pop-up''
File:REQ_343463_PDA_Delivery6b.png|''Product Info Pop-up (More)''
</gallery> 

{{Note}} If confirmed, this Product Info pop-up will also include a "UOM Qty" field, containing the decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc.

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

When all products have been confirmed as delivered or cancelled, the Delivery process will return to the Job Details tab, where a '''Complete''' button will be displayed, to complete the job. It is then possible to review the list of products delivered and change this if required. The list will display a border and status to indicate whether the products have been delivered:
* Red - Cancelled
* Amber - Delivered with an amendment (changed quantity)
* Green - Delivered in full.
The status and the Planned and Actual quantity will be displayed for confirmation.

When the driver has confirmed that everything is complete and clicked the '''Complete''' button, this screen will close and the user will be directed to the Job Completion process.

=== Delivering a Product ===
Each product on the list can be confirmed as delivered by either:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
* Clicking '''Deliver All''' on the ''Job Details'' tab.

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

The system will be configured with "Deliver All" functionality. This can be used to mark all pending products as delivered.
This is most likely to be used by:
* Check all products and quantities from the information on the Product list.
* Cancelling or changing the quantity of any items with discrepancies, using the following processes.
* Clicking '''Deliver All''' for the remaining products on the list.
This process is likely to be used extensively for Trunk deliveries.

{{Note}} If confirmed, products with a decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc will have a quantity set as 1.

=== Changing a Product Quantity ===
The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed.
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery7.png|''Exception - Change Product Quantity''
</gallery> 

For clarification, the product code and description and the job and customer are also displayed here.

The application will be ''not'' configured so that the driver is required to take a picture associated with this change of quantity.

If zero is entered as the new quantity, the application will cancel the product and remove it from the product list. If the quantity is changed (and is not set to zero), the product will be marked as having the quantity entered delivered and will be removed from the product list.



{{Note}} If confirmed, products with a decimal value for UOFMs such as TONNES, LINEAR METRES, METRES SQUARED, etc will have a quantity set as 1 and the quantity may only be changed to 0 (i.e. cancelled). Comments may be added, however.

=== Cancelling a Product ===
Where delivery of a product is refused, the driver process will be to cancel the product delivery with the pop-up option ''Cancel''. This is necessary, as the process will be to get the customer to sign for the non-delivery of the product.

As with quantity change, the exception screen will be shown where the driver can enter the reason for the cancellation.

The user will also be able to optionally take a picture associated with this cancellation.

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

The application will ''not'' be configured so that the driver is required to take a picture associated with cancellation of products.

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

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Delivery8.png|''Exception - Commenting on a product''
</gallery> 

{{Note}} Reason codes are the operation's to maintain and will be maintained only within C-ePOD, as they are never to be updated back to the ERP.

==Collection (Returns) Process==
It is expected that, where planned returns of products are created, these collections will be interfaced to {{#var:system}} as Collection jobs.

The collection process will be almost identical to that described above, substituting Collection instead of Delivery.

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

== Job Completion ==
All jobs will be sent to the {{#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 prompt for Customer Signature for Radial Collections and Deliveries, and for Desk Collections.
<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Signature1.png|''Customer Signature and T&Cs''
File:REQ_343463_PDA_Signature2.png|''Customer Signature and Products''
</gallery> 

The signatory will by configuration be set to be blank and always required entry. The driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm.
* The quantity of products being collected/delivered.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under or to the right of the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time and is expected to be finalised during implementation. These are currently expected to be:
* Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

Unmanned locations or delivery out of hours may require that the driver sign PP for the customer, then taking photos to indicate the successful delivery. This Unmanned Location Process will be configured for this implementation. {{Note}} This is dependent on a development in progress at this time and is a dependency of this implementation.

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

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

If driver signature is required, this displays very similarly to the customer signature above, with some differences:
* The standard collection T&Cs will not be shown. Special Driver T&Cs can be configured if required.
* The driver name will be pre-set from the logged-on driver and cannot be changed.
If driver signature is prompted for, it must be entered and cannot be skipped.

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

The driver will be able to view the captured image or re-take the photos.

<gallery widths=300px heights=210px perrow=2>
File:REQ_343463_PDA_Signature3.png|''Job Photo''
</gallery> 

As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, etc) updated. The updates are sent whenever the driver has a viable data connection, and may be delayed until that time.

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

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

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

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

The Load for the Trunk drivers will be heavily consolidated, and will likely only contain 1 or 2 stops on the job list, with all jobs consolidated together at the depots.

As mentioned, this delivery process is likely to make substantial use of the Deliver All process, to identify that all products are delivered to the depot successfully.

When the driver delivers to the depot, the device will not prompt for any signatures, customer or driver. Instead, the process will return to the job list after confirmation that all product is delivered.

{{Warning}} Trailer swapping is performed by EBB. More detail on this process is required, but at this time it is expected that this will not be part of the C-ePOD execution and will be handled manually.

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

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

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

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

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

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

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

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

== POC/POD Documents ==
Once jobs are completed, then will be confirmed with the C-ePOD server. After this confirmation, a POD/POC report may be produced.

All photos taken by the driver during the execution of the job (i.e. at cancellation of product, change quantity of product, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view.

The format attached to the job group is the format that will be produced from the Admin console and displayed for customers when requested through ''CALIDUS'' Portal.

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

[[file:REQ_343463_POD1.png|border|600px]]
 ''Prototype EBB Papers POD Format'' 

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=EBB Paper POD/POC Format
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

{{Note}} The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into {{#var:system}}.

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

Product Details, expected to be shown on every page, expected to show up to 10 products per page:
* ORDER NO - the order number against the product
* QTY - The actual quantity of the product delivered, as confirmed by the driver.
* UNITS - the unit type against the product
* QUALITY & DESCRIPTION - The description of the product, and the FSC number (if provided) from the Long Description.
* PACKS - the pack size, from the case quantity.
* KGS - the weight of the product

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

{{Warning}} Definition of the exact fields used for this report will be confirmed at functional specification stage, dependant on the interface mapping, specifically:
* The Dates and Times displayed
* The Branch
* The quantities displayed is dependent upon how C-ePOD will store these values, dependent on the decimal quantity change specified in this document.

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

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

However, these automatic emails or exports may be configured at any time.

== Further Reporting and Queries ==
The {{#var:System}} Admin system allows admin users (i.e. non-PDA users) the ability to access loads, jobs and product details, as mentioned previously.

<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_Load2.png|''Loads''
File:REQ_336500_Admin_Job1.png|''Jobs''
File:REQ_336500_Admin_Containers1.png|''Products''
</gallery> 

When jobs are being processed, the status of the jobs and loads changes to show progress:
* Pending - not yet assigned to a driver.
* Assigned - Assigned to a driver, but not yet started. This is highlighted grey.
* In Progress - Started by the driver. This is highlighted yellow.
* Complete - Complete by the driver - This is highlighted green.
* Cancelled - Job cancelled by the driver. This is highlighted red.
* Complete (With Amendments) - job completed, but not exactly as planned. This is also highlighted blue.

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

User activity may also be accessed, to show auditing of messages from the user, for example:
* Log on
* Load picked up
* Job started
* Job arrived
* Job completed
* Load completed
* Log off

<gallery widths=600px heights=300px perrow=1>
File:REQ_336500_Admin_UserTracking1.png|''User Tracking - Activities''
File:REQ_336500_Admin_UserTracking2.png|''User Tracking - Location''
</gallery> 

== Track and Trace ==
''CALIDUS'' Portal provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

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

''CALIDUS'' Portal is kept updated at all times by {{#var:System}} of all states of the loads and jobs, for example:
* The Trip itself.
* The Order itself.
* The sequence of the Order on the Trip
* When an order is in transit.
* When an order is collected and/or delivered.
* When an order is cancelled.
The messages identify any changes to quantities and reasons for these changes at all stages.

The interface from C-ePOD to C-PORTAL TTM must account for trunks of orders to determine the from and to locations for the orders in TTM. The jobs will be linked through the Job Code to determine this.

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

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

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Use defined Dwell time for ETA.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The following is a brief description of functionality available within ''CALIDUS'' Portal that has potential to be used by EBB paper and their customers if required. This is by no means a full list of all functionality available within ''CALIDUS'' Portal - the user guide (referenced in the Appendices of this document) contains the full details of the available functionality.

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

==== Order Enquiry ====

[[file:REQ_339867_TTM_OrdEnqParms.png|border|600px]]
 ''Order Enquiry Parameters'' 

[[file:REQ_339867_TTM_GenEnqParms.png|border]]
 ''General Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_339867_TTM_OrdEnqResults1.png|border|600px]]
 ''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 ====
[[file:REQ_339867_TTM_TripEnqParms.png|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_339867_TTM_TripEnqResults.png|border|600px]]
 ''Trip Enquiry Results'' 
These results can be expanded for further details of the Orders, and the order can be clicked to drill-down into specific details of the order.

This table data can also be exported to XML format in multiple ways:
* '''Manifest''' - Trip/Stop information
* '''Manifest/Order''' - Trip/Stop/Order information
* '''Order''' - Order Header information
* '''Order Detail''' - Order Header / Order Detail information

The screen supports configurable RAG colouration, to highlight trips that are late or incomplete, and ETAs.

==== Order Details ====
[[file:REQ_339867_TTM_OrderDetail1.png|border|600px]]
 ''Order Details'' 

Details can be found of the following:
* Events – the Messages received by the LOTS system via WMS, TMS and other systems.
* Info – Details of all of the header information stored on the system
* Route – Details of the trips/stops that the order is currently assigned to.
* SO Details – the Stock details received from the TMS or WMS.
* Reasons – Details of the Order level reasons placed against the order.
* Map – A map of the current location of the order (if co-ordinates have been supplied by an external system). The Mapping page will only be available to groups where the 'Mapping' parameter against the User Group is set to 'Available' and where licensing is available.
* Notes – Allows the entry of user notes against the order. These are only kept on the Portal system.
* Documents - Allows the upload/view of documents held in the Portal against the order.

[[file:REQ_339867_TTM_OrderDetail2.png|border|600px]]
 ''Order Event Details'' 
[[file:REQ_339867_TTM_OrderDetail3.png|border|600px]]
 ''Order Info Details'' 

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

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display ETA and Planned Time on Map screen
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Arrivals/Departures (Order Status) Screen ===
''CALIDUS'' Portal supports several Airport-style screens:
* Arrive/Depart screen
* Order Status screen
Both screens allow for customised parameter entry, and refreshing data at intervals, making them ideal for overhead displays or continuous transport queries. The recommended screen is the Order Status screen.

[[file:REQ_339867_TTM_OrderStatus1.png|border|600px]]
 ''Order Status Screen'' 

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

The C-Portal TTM module's Order Status screen can be configured to determine the window for delivery in a +/- number of minutes before the delivery end time. This is accessible from the burger menu on the screen.

[[file:REQ_339867_TTM_OrderStatus2.png|border]]
 ''Order Status Parameters'' 

=== Customer (Order) Visibility Screen ===
This screen represents a combination of all the screens above in one place, to simplify access.

[[file:REQ_339867_TTM_OrderVis1.png|border|600px]]
 ''Order Visibility Parameters and results'' 

Similar selection criteria to the Trip/Order Enquiries and Order Status screens can be accessed from the left-hand panel. Results will be shown on the right.

When an order is selected, the Order Details page is displayed.

[[file:REQ_339867_TTM_OrderVis2.png|border|600px]]
 ''Order Visibility Details'' 

Clicking on each of the icons on the top of the page displays similar information to the other enquiry results screens. This screen also allows the user to maintain CRM-related notes and events.

[[file:REQ_339867_TTM_OrderVis3.png|border|600px]]
 ''Order Visibility CRM Details'' 


= Appendix A: Table of SCRs and Ballpark Estimates =


{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Integration|Description=Bespoke Import Interface |Estimate=27|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Database|Description=Support decimal values in quantities|Estimate=20|Notes=2
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=VEhub|Area=Admin|Description=Improved searching on tables|Estimate=6|Notes=3
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Device|Description=General Mobile Device Styling |Estimate=1|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=EPOD|Area=Reports|Description=EBB Paper POD/POC Format |Estimate=2|Notes=4
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=ETAs|Description=Use defined Dwell time for ETAs |Estimate=4|Notes=3
}} {{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}|System=PORTAL|Area=Map|Description=Display ETA and Planned time on map |Estimate=1|Notes=3
}} {{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.
# This change is required only if the OBS systems are required to store decimal quantities. Note also that this change covers C-ePOD and C-PORTAL only. Should C-TMS be used as part of this solution, this must be evaluated for change separately.
# These changes will be developed as part of the product improvement program internally at OBS Logistics and will be made available when complete.
# These changes will be delivered as part of the contracted delivery at no additional cost.


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD2
|Ref1=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=4.0
|RefDate1=21/07/2016
|Ref2=[http://172.198.45.54/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=5.0
|RefDate2=23/12/2016
|Ref3=[[FS 291096 Interface with CALIDUS ePOD]]
|RefV3=1.1
|RefDate3=11/01/2017
|Ref4=Portal User Guide - TTM
|RefV4=6.9.20
|RefDate4=14/12/2016
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Rebecca Elliott
|Rev1Title=EBB Paper Representative
|Rev2=Matt Turner
|Rev2Title=OBS Logistics Representative
}}</div>
[[Category:{{#var:Client}} REQ]]

EST 339969 LFS Control POD Email Send

2017-03-23T09:34:17Z

Tippingm:

{{#vardefine:Year|2017}}{{#vardefine:Client|LFS}}{{Estimate_Head
|Client={{#var:Client}}
|Project=AUS
|Site=AUS-MEL
|ClientRef=NO REF
|OBSRef=339969
|Version=1.0
|Author=AN Walker
|PONum= 
|Priority=3
|Date=23/03/17
|Customer= 
|SysVer=1.4
|ClientRequest=The auto-email POD at Customer level is sending through POD's for both the scan onto the van and for delivery to the final delivery legs. However, the scan onto the van time is not something that the customer should know.
Would like to suggest that the proposed solution looks at the emailing of triggers in a complete and comprehensive way to allow for flexibility as all of our customers have varied expectations and requirements and this is only increasing with new customers.
|Solution=A customer-level, location-level and location type-level configuration will be added to C-TMS, used when sending jobs to C-ePOD.

For customers, the settings mean:
* POD Only - any orders owned by that customer will send a POD to the customer's contact email address at completion of the job at the final destination location only.
* POC Only - any orders owned by that customer will send a POC to the customer's contact email address at completion of the job at the origin location only.
* Both - any orders owned by that customer will send a POC to the customer's contact email address at completion of the job at the origin location, and will send a POD to the customer's contact email address at completion of the job at the origin location.
* Neither - no POD or POC emails will be sent to the customer's contact email address at all.
The configuration will be added to the ''EPOD'' tab on the ''Customers'' maintenance screen.

For locations, the settings mean:
* POD Only - any order with a To Loc of this location will send a POD to the location's contact email address at completion of the job at the final destination location only.
* POC Only - any order with a From Loc of this location will send a POC to the location's contact email address at completion of the job at the origin location only.
* Both - any order with a From Loc of this location will send a POC to the location's contact email address at completion of the job at the origin location, and any order with a To Loc of this location will send a POD to the location's contact email address at completion of the job at the final destination location.
* Neither - no POD or POC emails will be sent to the location's contact email address at all.
* Default - the location type will be checked instead.
The configuration will be added to the ''EPOD'' tab on the ''Locations'' maintenance screen.

For location types, the settings are:
* POD Only - any order with a To Loc of locations of this type will send a POD to the location's contact email address at completion of the job at the final destination location only.
* POC Only - any order with a From Loc of locations of this type will send a POC to the location's contact email address at completion of the job at the origin location only.
* Both - any order with a From Loc of locations of this type will send a POC to the location's contact email address at completion of the job at the origin location, and any order with a To Loc of locations of this type will send a POD to the location's contact email address at completion of the job at the final destination location.
* Neither - no POD or POC emails will be sent to locations of this type's contact email address at all.
The configuration will be added to the ''EPOD'' tab on the ''Business Data/Location Types'' maintenance screen.

All email addresses sent through on the jobs would then be set against the origin job and/or final delivery job based on these settings.

Email addresses are configured against contacts linked to locations or orders.

For Customer emails:
* Link a location to a customer
* Add a contact against this location with an email address.

For Location emails:
* Add a contact against this location with an email address.

For Order emails:
* Add a contact against the from and/or to locations with an email address.

For example:
* if the supplier is configured to receive both, to be sent to cust@lfs.com.au
* the collection address is configured for both, to be sent to origin@cust.com.au
* the destination address is set to both, to be sent to final@gmail.com
* the order has a From Location email address set to order_to@gmail.com
* the order has a To Location email address set to order_from@gmail.com

In this example, the jobs sent through (in normal configuration) would be as follows:
* Customer to LFS depot. - cust@cust.com.au; origin@cust.com.au; order_from@gmail.com
* LFS Depot to Airport - (None)
* Airport to Airport - (None)
* Airport to LFS Depot - (None)
* LFS Depot to final destination - cust@lfs.com.au; final@gmail.com; order_to@gmail.com

So the rules are:
* Never populate email if the job being sent is not an origin or final destination location.
* Only add customer email to origin if configuration is Both or POC.
* Only add customer email to final destination if configuration is Both or POD.
* Only add address email to origin if location configuration is Both or POC or Default and location type configuration is Both or POC.
* Only add address email to final destination if configuration is Both or POD or Default and location type configuration is Both or POD.
* Add order From Loc email to origin if present.
* Add order To Loc email to final destination if present.

The email lists will be curated when created to ensure that only one entry per email is generated.

For Job Swaps, the systems will be configured to remove the emails from the job at the swap point, and will be copied to the new jobs, ensuring that the emails will only be sent at final destination.

This mechanism will be used in preference to the Job Group mechanism is C-ePOD. The C-ePOD Site email address (for LFS contact information) will still be used to send emails to LFS contacts.

{{Note}} If addresses are free-typed on orders through the Portal screens rather than a location found for that location that already exists, a new location will be created. The contact information will not be stored against the location, only against the order. The configuration for this new location will be set to ''Default''.

{{Note}} If a location is configured to ''Both'', this means that the location email address is used when the order is delivered or collected from that location. This does not mean that the email address will be used for the POC or POD at the other location.

For example:
When delivering an order from RDCMEL direct to customer MYCUST, if location MYCUST has a contact email address and the configuration is ''Both'', the email address will be used on the POD to MYCUST - the email will not be used for the POC from RDCMEL.

The reverse is also true: When delivering an order from MYCUST to RDCMEL, the email address will be used on the POC from MYCUST - the email will not be used for the POD to RDCMEL.
}}{{EstimateCostDetails{{#var:Year}}
|REQ=0.0
|EST=1.0
|FS=1.75
|TS=0
|DEV=8.5
|ST=1.5
|IMP=0.5
|PM=1.0
|Client=LFS
|Year={{#var:Year}}
|FOC=N
|NOFOOTER=Y
}}

<table width="100%">
<tr><td align="center">
Copyright © OBS Logistics {{#var:Year}}. 
This estimate has an expiry date of 30 days from the specified Estimate Date. 
The information contained herein is supplied without liability for errors or omissions.
</td></tr></table>
[[Category:{{#var:Client}} EST]]

EST 339969 LFS Control POD Email Send

2017-03-23T09:33:20Z

Tippingm: v1.0 Review and Issue to LFS

{{#vardefine:Year|2017}}{{#vardefine:Client|LFS}}{{Estimate_Head
|Client={{#var:Client}}
|Project=AUS
|Site=AUS-MEL
|ClientRef=NO REF
|OBSRef=339969
|Version=1.0
|Author=AN Walker
|PONum= 
|Priority=3
|Date=23/03/17
|Customer= 
|SysVer=1.4
|ClientRequest=The auto-email POD at Customer level is sending through POD's for both the scan onto the van and for delivery to the final delivery legs. However, the scan onto the van time is not something that the customer should know.
Would like to suggest that the proposed solution looks at the emailing of triggers in a complete and comprehensive way to allow for flexibility as all of our customers have varied expectations and requirements and this is only increasing with new customers.
|Solution=A customer-level, location-level and location type-level configuration will be added to C-TMS, used when sending jobs to C-ePOD.

For customers, the settings mean:
* POD Only - any orders owned by that customer will send a POD to the customer's contact email address at completion of the job at the final destination location only.
* POC Only - any orders owned by that customer will send a POC to the customer's contact email address at completion of the job at the origin location only.
* Both - any orders owned by that customer will send a POC to the customer's contact email address at completion of the job at the origin location, and will send a POD to the customer's contact email address at completion of the job at the origin location.
* Neither - no POD or POC emails will be sent to the customer's contact email address at all.
The configuration will be added to the ''EPOD'' tab on the ''Customers'' maintenance screen.

For locations, the settings mean:
* POD Only - any order with a To Loc of this location will send a POD to the location's contact email address at completion of the job at the final destination location only.
* POC Only - any order with a From Loc of this location will send a POC to the location's contact email address at completion of the job at the origin location only.
* Both - any order with a From Loc of this location will send a POC to the location's contact email address at completion of the job at the origin location, and any order with a To Loc of this location will send a POD to the location's contact email address at completion of the job at the final destination location.
* Neither - no POD or POC emails will be sent to the location's contact email address at all.
* Default - the location type will be checked instead.
The configuration will be added to the ''EPOD'' tab on the ''Locations'' maintenance screen.

For location types, the settings are:
* POD Only - any order with a To Loc of locations of this type will send a POD to the location's contact email address at completion of the job at the final destination location only.
* POC Only - any order with a From Loc of locations of this type will send a POC to the location's contact email address at completion of the job at the origin location only.
* Both - any order with a From Loc of locations of this type will send a POC to the location's contact email address at completion of the job at the origin location, and any order with a To Loc of locations of this type will send a POD to the location's contact email address at completion of the job at the final destination location.
* Neither - no POD or POC emails will be sent to locations of this type's contact email address at all.
The configuration will be added to the ''EPOD'' tab on the ''Business Data/Location Types'' maintenance screen.

All email addresses sent through on the jobs would then be set against the origin job and/or final delivery job based on these settings.

Email addresses are configured against contacts linked to locations or orders.

For Customer emails:
* Link a location to a customer
* Add a contact against this location with an email address.

For Location emails:
* Add a contact against this location with an email address.

For Order emails:
* Add a contact against the from and/or to locations with an email address.

For example:
* if the supplier is configured to receive both, to be sent to cust@lfs.com.au
* the collection address is configured for both, to be sent to origin@cust.com.au
* the destination address is set to both, to be sent to final@gmail.com
* the order has a From Location email address set to order_to@gmail.com
* the order has a To Location email address set to order_from@gmail.com

In this example, the jobs sent through (in normal configuration) would be as follows:
* Customer to LFS depot. - cust@cust.com.au; origin@cust.com.au; order_from@gmail.com
* LFS Depot to Airport - (None)
* Airport to Airport - (None)
* Airport to LFS Depot - (None)
* LFS Depot to final destination - cust@lfs.com.au; final@gmail.com; order_to@gmail.com

So the rules are:
* Never populate email if the job being sent is not an origin or final destination location.
* Only add customer email to origin if configuration is Both or POC.
* Only add customer email to final destination if configuration is Both or POD.
* Only add address email to origin if location configuration is Both or POC or Default and location type configuration is Both or POC.
* Only add address email to final destination if configuration is Both or POD or Default and location type configuration is Both or POD.
* Add order From Loc email to origin if present.
* Add order To Loc email to final destination if present.

The email lists will be curated when created to ensure that only one entry per email is generated.

For Job Swaps, the systems will be configured to remove the emails from the job at the swap point, and will be copied to the new jobs, ensuring that the emails will only be sent at final destination.

This mechanism will be used in preference to the Job Group mechanism is C-ePOD. The C-ePOD Site email address (for LFS contact information) will still be used to send emails to LFS contacts.

{{Note}} If addresses are free-typed on orders through the Portal screens rather than a location found for that location that already exists, a new location will be created. The contact information will not be stored against the location, only against the order. The configuration for this new location will be set to ''Default''.

{{Note}} If a location is configured to ''Both'', this means that the location email address is used when the order is delivered or collected from that location. This does not mean that the email address will be used for the POC or POD at the other location.

For example:
When delivering an order from RDCMEL direct to customer MYCUST, if location MYCUST has a contact email address and the configuration is ''Both'', the email address will be used on the POD to MYCUST - the email will not be used for the POC from RDCMEL.

The reverse is also true: When delivering an order from MYCUST to RDCMEL, the email address will be used on the POC from MYCUST - the email will not be used for the POD to RDCMEL.
}}{{EstimateCostDetails{{#var:Year}}
|REQ=0.0
|EST=1.0
|FS=1.75
|TS=0
|DEV=7.5
|ST=1.5
|IMP=0.5
|PM=1.0
|Client=LFS
|Year={{#var:Year}}
|FOC=N
|NOFOOTER=Y
}}

<table width="100%">
<tr><td align="center">
Copyright © OBS Logistics {{#var:Year}}. 
This estimate has an expiry date of 30 days from the specified Estimate Date. 
The information contained herein is supplied without liability for errors or omissions.
</td></tr></table>
[[Category:{{#var:Client}} EST]]

FS 336019 332569-9 GK Planned Vs Actual Report

2016-08-23T12:17:24Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title| Planned Vs Actual Report}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336019 332569-9}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
A series of Planned vs Actuals reports, comparing planned data from DiPS and actual data from TomTom WEBFLEET.

== Solution Overview ==
== Planned Vs Actual Reporting ==
A facility will exist within ''CALIDUS'' ePOD to allow reporting of Planned Vs Actuals. This will be available from the Reports menu in the ''CALIDUS'' ePOD Admin system.

[[file:REQ_332571_Admin_Reports.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped TomTom Planned Vs Actual Report'' 

The report is expected to be run daily.

The report will allow the following parameters to be entered:
* Depot - This will default to the current Site. The drop-down list will allow the selection of other depots configured specifically for the report, or all depots for that customer.
* Driver - an optional parameter, to select only loads completed by a particular driver. The parameter will allow selection of one specific driver from the depots selected, or all drivers from the depots selected (the default value).
* Vehicle Reg - an optional parameter, to select only loads completed on a particular vehicle. The parameter will allow selection of one specific vehicle from the depots selected, or all vehicles from the depots selected (the default value).
* Date range - a required parameter. This will select jobs with a Planned End date within this range. This will default to the current date for both parameters. A range of more than one month will not be allowed, although it will be allowed to select a range earlier.
* Customer Account number - an optional parameter, to select jobs for a specific customer only. The parameter will allow selection of one specific customer from the depots selected, or all customers from the depots selected (the default value).

[[file:REQ_332571_Admin_PvA_Parms.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped report parameters'' 

Once selected, the user will run the report, and the system will generate a Microsoft Excel file with the results.

Notes:
* Only completed or cancelled jobs will be selected.
* The report will be named based on the parameters selected:
** PVA_{Depot}_{Driver}_{Vehicle}_{Customer}_{Date}.xls
** If a parameter is left as All Values, this will not appear in the name, with the exception of Depot and Date Range.

Depending on browser settings, this may either offer to save the report immediately, or open immediately in the browser. If opened in the browser, the report may be saved locally.

An example report has been provided and is referenced in [[#Appendix B: Document References|Appendix B]].

The report will have multiple tabs as defined in the sample report provided. An additional Parameters tab will be created as the first tab, showing the parameters entered.

=== Report Parameters ===
[[file:REQ_332571_PvA_Parameters.PNG|border|600px]]
 ''Sample Plan vs Actual Parameters Tab'' 

The Parameters screen will show the report title and the selected parameters. Where a parameter is selected, the code and the description will be shown.

The page will be oriented in landscape.

General Tab Notes:
* All pages will include the title bar, consisting of the tab title alone.
* The TomTom Logo in the top left and the GK Logo in the top right will '''not''' be produced on the report. If this is required, and additional change will be required at additional cost.
* All tables will be outlined with single borders
* All titles and summary lines will be bold.
* All titles will be fixed - no additional fields can be added and the text may not be changed through configuration of the report, although they may be changed after the report is produced.
* Work time is defined as the time in between arriving at a location and departing a location. The working time consists of loading/unloading and paperwork
* Travel time is defined as the time in between the start and arrive times stored against a job, either travelling on Collections/Deliveries or travel to/from the depot.
* Route displayed on the reports will be the new Route field added to the load, if this is not blank, otherwise this will be the default Load ID.
* Date displayed on the report will be the Planned End Date, when the delivery should be completed.
* Data on the report will be primarily sorted by Planned End Date, Vehicle Reg and Route, then any additional data specific to that tab.

=== Plan vs Actual Summary ===
[[file:REQ_332571_PvA_Summary.PNG|border|600px]]
 ''Sample Plan vs Actual Summary Tab'' 

The report will show the variance between the planned distances, work time and travel time, per load (Route) and Vehicle.

Each of the monitored values will be calculated as follows:
* Plan - the sum of the planned values against the jobs on the load.
* Actual - the sum of the actual values against the jobs on the load.
* Var - the planned summed value minus the actual summed value.
* % Var - the summed variance divided by the summed planned value, expressed as a percentage with 1 decimal place.

A total line will be shown, totalling all the calculated monitored values and the total number of lines (routes).

The page will be oriented in landscape.

=== Plan vs Actual Detail ===
[[file:REQ_332571_PvA_Detail.PNG|border|600px]]
 ''Sample Plan vs Actual Detail Tab'' 

The report will show the variance between the planned distances, work time and travel time, per job (account) on a load (route).

Each of the monitored values will be calculated as follows:
* Plan - the planned values against the job.
* Actual - the actual values against the job.
* Var - the planned value minus the actual value.
* % Var - the variance divided by the planned value, expressed as a percentage with 1 decimal place.

Breaks and Depot (Loading/Unloading) jobs will not include account number and postcode.

Loading jobs will not include Distance or Travel Time variances.

The page will be oriented in landscape.

=== Time Window Summary ===
[[file:REQ_332571_Window_Summary.PNG|border|600px]]
 ''Sample Time Window Summary Tab'' 

The report will show a summary of the drops planned on a load, the number achieved within the window, and the variance.

The report will summarise at Load (route) and will display:
* No. Planned - a sum of the number of collection or delivery jobs on the load.
* No. Achieved - a sum of the number of collection or delivery jobs on the load where the actual arrival time is within the window.
* Var - No. Planned minus No. Achieved.
* % Var - No. Achieved divided by No. Planned, expressed as a percentage, rounded up. {{Note}} This is not the percentage variance, this is the percentage compliance. The column title will be labelled as '% Comp' rather than '% Var' to reflect this.

A total line will be shown, totalling all the calculated monitored values.

The page will be oriented in portrait.

=== Time Detail ===
[[file:REQ_332571_Time_Detail.PNG|border|600px]]
 ''Sample Time Detail Tab'' 

The report will show the variance between the planned time windows and planned and actual time, per job (account) on a load (route).

The report will display:
* Time Window - the time window received for the job.
* Planned Arrival Time - Planned Start Time.
* Actual Arrival Time - Arrival Time.
* Var - Actual Arrival minus planned arrival, in minutes. This should be green background if the arrival time is within 30 minutes (plus or minus) or the planned arrival time, otherwise red background.
* Achieved Time Window - Yes or, depending if the arrival time is within the time window. This should be green background if Yes, other red background.

The page will be oriented in landscape.

=== Time Window Exception ===
[[file:REQ_332571_Window_Exception.PNG|border|600px]]
 ''Sample Time Window Exception Tab'' 

The report will show any jobs where the actual arrival time is not within the planned time window, per job (account) on a load (route).

The report will display:
* Time Window - the time window received for the job.
* Arrival Time - the actual Arrival Time.

The page will be oriented in portrait.

=== Arrival Time Exception ===
[[file:REQ_332571_Arrival_Exception.PNG|border|600px]]
 ''Sample Arrival Time Exception Tab'' 

The report will show any jobs where the actual arrival time is not within 30 minutes of the planned time, per job (account) on a load (route).

The report will display:
* Planned Arrival Time - Planned Start Time.
* Actual Arrival Time - Arrival Time.
* Var - Actual Arrival minus planned arrival, in minutes.

The page will be oriented in portrait.

== Scope ==



= Set-up =
== Pre-requisites ==
The jobs must be received from DiPS for the planned values.

The jobs must be sent to TomTom WEBFLEET and updated from there to achieve the actual values.
The set-up of these interfaces are covered in the relevant specification referenced in [[#Appendix B: Quote & Document References|Appendix B]].

== Menu Structure ==
''Reports''

== Data ==
The data used by these reports is derived directly from the DiPS interface (for planned information) and WEBFLEET Update interface (for actuals information), defined in the relevant specifications referenced in [[#Appendix B: Quote & Document References|Appendix B]].


= Functional Description =

== Admin Parameters Screen ==
A facility will exist within ''CALIDUS'' ePOD to allow reporting of Planned Vs Actuals. This will be available from the Reports menu in the ''CALIDUS'' ePOD Admin system.

[[file:REQ_332571_Admin_Reports.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped TomTom Planned Vs Actual Report'' 

If the system type is "PvA" (EPL_SYSTEM_TYPE of EPOD_LOAD), the drop-down list of reports should have the value "TomTom Planned Vs Actuals Report" pre-selected and the parameters already shown. If the system type is any other value, the report screen should operate as now, in that the reports drop-down list should be showing "Please select a Report", with no parameters shown.

The report will allow the following parameters to be entered:
* Depot - This will default to the current Site. The drop-down list will allow the selection of other depots configured specifically for the report, or all depots (option "All Depots"). The list of depots accessible for the report will be set against the system in pre-configured List Items for Greene King (EPOD_LISTS and EPOD_LIST_ITEMS). {{Note}} If the Depot selected is changed, any select value in Driver, Vehicle and Customer Account Number will be reset.
* Driver - an optional parameter, to select only loads completed by a particular driver. The parameter will allow selection of one specific driver from the depots selected, or all drivers from the depots selected (the default option "All Drivers"). This list of drivers will be built after the selection of Depot. The drivers will be listed showing Site and Name and sorted this way e.g. "EAS-A Driver", This is built from EPL_SITE_ID and EPL_USER_NAME from EPOD_USER.
* Vehicle Reg - an optional parameter, to select only loads completed on a particular vehicle. The parameter will allow selection of one specific vehicle from the depots selected, or all vehicles from the depots selected (the default option "All Vehicles"). This list of vehicles will be built after the selection of Depot. The vehicles will be listed showing Site and Reg and sorted this way e.g. "EAS-AB12 CDE", This is built from EPL_SITE_ID and EPL_VEHICLE_REG from EPOD_VEHICLE.
* Date range - a required parameter. This will select jobs with a Planned End date within this range. This will default to the current date for both parameters. A range of more than one month will not be allowed, although it will be allowed to select a range earlier. If the From date selected is after the To date, the To date will default to the From date. If the To date selected is before the From date, the From date will default to the To date. The user will be provided a Calendar pop-up to select dates.
* Customer Account number - an optional parameter, to select jobs for a specific customer only. The parameter will allow selection of one specific customer from the depots selected, or all customers from the depots selected (the default option "All Customers"). This list of Customers will be built after the selection of Depot. The customers will be listed showing Site and Name and sorted this way e.g. "EAS-Ashby Mill Road Club [Scunthorpe]", This is built from EPL_SITE_ID and EPL_CUSTOMER_NAME from EPOD_CUSTOMER.

[[file:REQ_332571_Admin_PvA_Parms.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped report parameters'' 

{{Note}} Parameters selected as "All ..." will have the parameter value as blank.

Once selected, the user will run the report by clicking '''Create Excel Spreadsheet''' and the system will generate a Microsoft Excel file with the results.

{{Note}}:
* Only completed or cancelled jobs and loads will be selected.
* The report will be named based on the parameters selected:
** PVA_{Depot}_{Driver}_{Vehicle}_{Customer}_{Date}.xls
** Depot: The selected Depot ID (EPL_SITE_ID) or "ALL", plus an underscore (_).
** Driver: The selected Driver ID (EPL_USER_ID) plus an underscore (_), or omitted if All selected.
** Vehicle: The selected Vehicle ID (EPL_VEHICLE_ID) plus an underscore (_), or omitted if All selected.
** Customer: The selected Customer Code (EPL_CUSTOMER_CODE) with all spaces replaced as underscores, plus an underscore (_), or omitted if All selected.
** Date: The Date From and To, in YYYYMMDD format, concatenated with an underscore (_).

Examples:
* Where all parameters are left at the default:
** PVA_ALL_20160629_20160629.xls
* Where a specific depot (Eastwood) is selected:
** PVA_EAS_20160629_20160629.xls
* Where a specific driver (A Driver) is selected:
** PVA_EAS_adriver_20160629_20160629.xls
* Where a specific vehicle (AB12 BCD) is selected:
** PVA_EAS_adriver_AB12BCD_20160629_20160629.xls
* Where a specific Customer (268349 001 - Ashby Mill Road Club [Scunthorpe]) is selected:
** PVA_EAS_adriver_AB12BCD_268349__001_20160629_20160629.xls
* Where a 3-day range is selected (from 27/06 to 29/06):
** PVA_EAS_adriver_AB12BCD_268349__001_20160627_20160629.xls

=== Report Parameters ===
The report will have multiple tabs as defined in the sample report provided. An additional Parameters tab will be created as the first tab, showing the parameters entered.

[[file:REQ_332571_PvA_Parameters.PNG|border|600px]]
 ''Sample Plan vs Actual Parameters Tab'' 

The Parameters screen will show the report title and the selected parameters. Where a parameter is selected, the code and the description will be shown.

The selected parameters should be displayed as follows:
* All parameters will be labelled and have values and descriptions displayed as below:
** Label "Depot": The selected Depot ID (value) and Name (description) (EPL_SITE_ID and EPL_DESCRIPTION) or "All" if the parameter value is blank.
** Label "Driver": The selected Driver ID (value) and Name (description) (EPL_USER_ID and EPL_USER_NAME) or "All" if the parameter value is blank.
** Label "Vehicle": The selected Vehicle ID (value) and Reg (description) (EPL_VEHICLE_ID and EPL_VEHICLE_REG) or "All" if the parameter value is blank.
** Label "Date Range": The Date From and To, in YYYYMMDD format.
** Label "Customer": The selected Customer Code (value) and Name (description) (EPL_CUSTOMER_CODE and EPL_CUSTOMER_NAME) or "All" if the parameter value is blank.
* The columns used will be as follows:
** C - The parameter Label.
** E - The parameter value. For Date Range, the From date.
** F - " to ", only for the Date Range parameter, blank for all others.
** G - The parameter Name if the parameter value is not blank. For Date Range, the To date.

The page will be oriented in landscape.

General Tab Notes:
* All pages will include the title bar, consisting of the tab title alone. This is specified as the title of each page section following.
* The TomTom Logo in the top left and the GK Logo in the top right will '''not''' be produced on the report. If this is required, an additional change will be required at additional cost.
* All tables will be outlined with single borders.
* All page titles, column titles and total lines will be bold.
* All titles will be fixed - no additional fields can be added and the text may not be changed through configuration of the report, although they may be changed after the report is produced by manually modifying the report after production.
* Page headers, Tables, Titles and Totals (where required) will always be displayed, even if there are no other rows on the table. In this case, for a page that displays a totals row, the total row will show zero values in the summarised columns.

=== Plan vs Actual Summary ===
[[file:REQ_332571_PvA_Summary.PNG|border|600px]]
 ''Sample Plan vs Actual Summary Tab'' 

The report will show the variance between the planned distances, work time and travel time, per load (Route) and Vehicle.

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Distance (KMs)
** Plan: The sum of the planned travel distance on all the jobs on the load (summed from EPL_DISTANCE_PLANNED).
** Actual: The sum of the actual travel distance on all the jobs on the load (summed from EPL_DISTANCE_ACTUAL).
** Var: the planned summed travel distance minus the actual summed travel distance.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.
* Work Time (Mins)
** Plan: The sum of the planned work time on all the jobs on the load (summed from EPL_WORK_PLANNED).
** Actual: The sum of the actual work time on all the jobs on the load (summed from EPL_WORK_ACTUAL).
** Var: the planned summed work time minus the actual summed work time.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.
* Travel Time (Mins)
** Plan: The sum on the planned travel time on all the jobs on the load (summed from EPL_TRAVEL_PLANNED).
** Actual: The sum of the actual travel time on all the jobs on the load (summed from EPL_DRIVING_TIME).
** Var: the planned summed travel time minus the actual summed travel time.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.

{{Note}} The values should be calculated with a SQL statement specific to this report, summing, grouping and ordering in the mechanism specified above. The following is an example of how this might be achieved for distance:
SELECT
, el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_CODE
, el.EPL_LOAD_ID
, SUM(ej.EPL_DISTANCE_PLANNED) DistancePlan
, SUM(ej.EPL_DISTANCE_ACTUAL) DistanceActual
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
''-- Other Criteria Here''
GROUP BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID
ORDER BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID

Variance and Percentage values will be calculated from the returned Plan and Actual values.

A total line will be shown, totalling all the calculated monitored values and the total number of lines (routes). This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* Route - A count of the lines.
* Distance
** Plan - A sum of all the row values.
** Actual - A sum of all the row values.
** Var - A sum of all the row values.
** % Var - The summed Var value divided by the summed Plan value.
* Work Time - All columns totalled as above.
* Travel Time - All columns totalled as above.

The page will be oriented in landscape.

=== Plan vs Actual Detail ===
[[file:REQ_332571_PvA_Detail.PNG|border|600px]]
 ''Sample Plan vs Actual Detail Tab'' 

The report will show the variance between the planned distances, work time and travel time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE). This cell should be blank and have a grey background if the job is a depot loading or unloading job (EPL_LOADING_TYPE is not blank) or the job is a Break (EPL_CUSTOMER_CODE is "BREAK").
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below). This cell should be blank and have a grey background if the job is a depot loading or unloading job (EPL_LOADING_TYPE is not blank) or the job is a Break (EPL_CUSTOMER_CODE is "BREAK").
* Distance (KMs)
** Plan: The planned travel distance of the job on the load (EPL_DISTANCE_PLANNED). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Actual: The actual travel distance of the job on the load (EPL_DISTANCE_ACTUAL). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Var: the planned travel distance minus the actual travel distance. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
* Work Time (Mins)
** Plan: The planned work time of the job on the load (EPL_WORK_PLANNED).
** Actual: The actual work time of the job on the load (EPL_WORK_ACTUAL).
** Var: the planned work time minus the actual work time.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place.
* Travel Time (Mins)
** Plan: The planned travel time of the job on the load (EPL_TRAVEL_PLANNED). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Actual: The actual travel time of the job on the load (EPL_DRIVING_TIME). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Var: the planned travel time minus the actual travel time. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} Driver-generated Break Jobs will have the same sequence as the following or in-progress job when generated. To ensure that they are displayed after they job that they interrupt, the result will also be sorted in Actual Start Date and Time sequence as well as Job Sequence.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved for distance:
SELECT
el.EPL_SITE_ID
, el.EPL_LOAD_ID
, el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, ej.EPL_CUSTOMER_CODE
, ec.EPL_CUSTOMER_NAME
, ec.EPL_POSTCODE
, eja.EPL_NAME
, eja.EPL_POSTCODE
, ej.EPL_JOB_TYPE
, ej.EPL_LOADING_TYPE
, ej.EPL_DISTANCE_PLANNED
, ej.EPL_DISTANCE_ACTUAL
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
JOIN EPOD_CUSTOMER ec
ON ec.EPL_SITE_ID = ej.EPL_SITE_ID
AND ec.EPL_CUSTOMER_CODE= ej.EPL_CUSTOMER_CODE
LEFT JOIN EPOD_JOB_ADDRESS eja
ON eja.EPL_SITE_ID = ej.EPL_SITE_ID
AND eja.EPL_JOB_TYPE = ej.EPL_JOB_TYPE
AND eja.EPL_JOB_ID = ej.EPL_JOB_ID
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
''-- Other Criteria Here''
ORDER BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, ej.EPL_START_ACTUAL_DATE, ej.EPL_START_ACTUAL_TIME

Variance and Percentage values will be calculated from the returned Plan and Actual values.

A total line will be shown, totalling all the calculated monitored values. This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* Distance
** Plan - A sum of all the row values.
** Actual - A sum of all the row values.
** Var - A sum of all the row values.
** % Var - The summed Var value divided by the summed Plan value.
* Work Time - All columns totalled as above.
* Travel Time - All columns totalled as above.

The page will be oriented in landscape.

=== Time Window Summary ===
[[file:REQ_332571_Window_Summary.PNG|border|600px]]
 ''Sample Time Window Summary Tab'' 

The report will show a summary of the drops planned on a load, the number achieved within the window, and the variance against the delivery/collection windows provided.

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* No. Planned: The number of jobs on the load with a unique sequence (EPL_SEQUENCE, excluding Loading/Unloading (EPL_LOADING_TYPE is not blank) or Break (EPL_CUSTOMER_CODE is "BREAK") jobs.
* No. Achieved: Of the jobs selected, those with a delivery time (EPL_END_ACTUAL_TIME) within the Job or Customer Delivery Windows - see below.
* Var: Calculated Planned above minus calculated achieved above
* % Comp: {{Note}} This is a percentage Compliance column, not a percentage variance column. Calculated Achieved above divided by calculated Planned above, with no decimal places.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved:
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_LOAD_END_PLANNED_DATE
, ej.EPL_VEHICLE_REG
, COUNT(ej.EPL_SEQUENCE) NoPlanned
, SUM(Achieved) Achieved
FROM (
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, MAX(el.EPL_LOAD_END_PLANNED_DATE) EPL_LOAD_END_PLANNED_DATE
, MAX(ev.EPL_VEHICLE_REG) EPL_VEHICLE_REG
, MAX(ej.EPL_CUSTOMER_CODE) EPL_CUSTOMER_CODE
, MAX(CASE WHEN
ej.EPL_END_ACTUAL_TIME >= COALESCE(etwj.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwj.ETW_TIME_END, 23599999)
AND ej.EPL_END_ACTUAL_TIME >= COALESCE(etwc.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwc.ETW_TIME_END, 23599999)
THEN 1 ELSE 0 END) Achieved
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwj
ON etwj.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwj.ETW_TYPE = 'J'
AND etwj.ETW_FK_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwc
ON etwc.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwc.ETW_TYPE = 'C'
AND etwc.ETW_FK_ID = ej.EPL_CUSTOMER_CODE
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
AND ej.EPL_LOADING_TYPE = ''
''-- Other Criteria Here''
GROUP BY ej.[EPL_SITE_ID]
,ej.[EPL_LOAD_ID]
,ej.[EPL_SEQUENCE]
) as ej
GROUP BY ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_LOAD_END_PLANNED_DATE
, ej.EPL_VEHICLE_REG
{{Note}} The SQL shown here consolidated the Customer and Job windows. The report will display only the achievement status and window against a single Job window. With the data expected in this implementation, this process will work. If customer windows are added or multiple windows are required, the achievement status will show correctly, however changes will be required to display the window correctly. These changes should be included as part of the work to implement multiple windows.

A total line will be shown, totalling all the calculated monitored values. This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* No. Planned - A sum of all the row values.
* No. Achieved - A sum of all the row values.
* Var - A sum of all the row values.
* % Comp - The summed variance plus the summed No. Planned, divided by the summed No. Planned, expressed as a percentage with no decimal places.

The page will be oriented in portrait.

=== Time Detail ===
[[file:REQ_332571_Time_Detail.PNG|border|600px]]
 ''Sample Time Detail Tab'' 

The report will show the variance between the planned time windows and planned and actual time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route Number: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Time Window: Concatenated from the job time window (ETW_TIME_START and ETW_TIME_END, if either is a non-zero value)
* Planned Time: The Planned Start Time (EPL_START_PLANNED_TIME).
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME). Referred to as the Arrival Time here on in.
* Var: The Arrival Time above minus the planned time above, in minutes. This should be green background if the arrival time is within 30 minutes (plus or minus) of the planned arrival time, otherwise red background.
* Time Window Achieved Yes/No: Whether the arrival time was within the Job Time Window. This should be green background if Yes, other red background.

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved:
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, MAX(el.EPL_LOAD_END_PLANNED_DATE) EPL_LOAD_END_PLANNED_DATE
, MAX(ev.EPL_VEHICLE_REG) EPL_VEHICLE_REG
, MAX(ej.EPL_CUSTOMER_CODE) EPL_CUSTOMER_CODE
, MAX(ec.EPL_CUSTOMER_NAME) EPL_CUSTOMER_NAME
, MAX(ec.EPL_POSTCODE) EPL_CUSTOMER_POSTCODE
, MAX(eja.EPL_NAME) EPL_NAME
, MAX(eja.EPL_POSTCODE) EPL_POSTCODE
, MAX(ej.EPL_JOB_TYPE) EPL_JOB_TYPE
, MAX(ej.EPL_LOADING_TYPE) EPL_LOADING_TYPE
, MAX(ej.EPL_START_PLANNED_TIME) EPL_START_PLANNED_TIME
, MAX(CASE WHEN ej.EPL_ARRIVAL_TIME > 0 THEN ej.EPL_ARRIVAL_TIME ELSE ej.EPL_END_ACTUAL_TIME END) EPL_ARRIVAL_TIME
, MAX(etwj.ETW_TIME_START) ETW_TIME_START
, MAX(etwj.ETW_TIME_END) ETW_TIME_END
, MAX(CASE WHEN
ej.EPL_END_ACTUAL_TIME >= COALESCE(etwj.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwj.ETW_TIME_END, 23599999)
AND ej.EPL_END_ACTUAL_TIME >= COALESCE(etwc.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwc.ETW_TIME_END, 23599999)
THEN 1 ELSE 0 END) Achieved
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
JOIN EPOD_CUSTOMER ec
ON ec.EPL_SITE_ID = ej.EPL_SITE_ID
AND ec.EPL_CUSTOMER_CODE= ej.EPL_CUSTOMER_CODE
LEFT JOIN EPOD_JOB_ADDRESS eja
ON eja.EPL_SITE_ID = ej.EPL_SITE_ID
AND eja.EPL_JOB_TYPE = ej.EPL_JOB_TYPE
AND eja.EPL_JOB_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwj
ON etwj.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwj.ETW_TYPE = 'J'
AND etwj.ETW_FK_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwc
ON etwc.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwc.ETW_TYPE = 'C'
AND etwc.ETW_FK_ID = ej.EPL_CUSTOMER_CODE
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
AND ej.EPL_LOADING_TYPE = ''
''-- Other Criteria Here''
GROUP BY ej.[EPL_SITE_ID]
,ej.[EPL_LOAD_ID]
,ej.[EPL_SEQUENCE]
{{Note}} The SQL shown here consolidated the Customer and Job windows. The report will display only the achievement status and window against a single Job window. With the data expected in this implementation, this process will work. If customer windows are added or multiple windows are required, the achievement status will show correctly, however changes will be required to display the window correctly. These changes should be included as part of the work to implement multiple windows.

The page will be oriented in landscape.

=== Time Window Exception ===
[[file:REQ_332571_Window_Exception.PNG|border|600px]]
 ''Sample Time Window Exception Tab'' 

The report will show any jobs where the actual arrival time is not within the planned time window, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Time Window: Concatenated from the job time window (ETW_TIME_START and ETW_TIME_END, if either is a non-zero value)
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME).

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} The same query used to create the Time Detail report may be used again here. The query should not be executed again - the same result recordset may be used again. In this case, however, only records that have a window that is not achieved should be displayed here.

The page will be oriented in portrait.

=== Arrival Time Exception ===
[[file:REQ_332571_Arrival_Exception.PNG|border|600px]]
 ''Sample Arrival Time Exception Tab'' 

The report will show any jobs where the actual arrival time is not within 30 minutes of the planned time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route Number: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Planned Time: The Planned Start Time (EPL_START_PLANNED_TIME).
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME). Referred to as the Arrival Time here on in.
* Var: The Arrival Time above minus the planned time above, in minutes.

{{Note}} The same query used to create the Time Detail report may be used again here. The query should not be executed again - the same result recordset may be used again. In this case, however, only records that have a calculated Var value of +/- 30 minutes should be displayed here.

The page will be oriented in portrait.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test the new Planned Vs Actual report content and production.
|MenuAccess=Reports
|Prerequisites=Data will be set up as per the test load in the DiPS sample file (Load 46004, Route E2010). The data should be completed as follows:
* GREENE KING - Completed in time in window.
* White Swan [Scotter] - Completed in time in window.
* Queensway [Scunthorpe] - Completed out of time (+35 minutes) in window.
* Ashby Mill Road Club [Scunthorpe] - Completed out of window (1031).
* Break 1 - Completed.
* Priory [Scunthorpe] - Completed in time in window.
* Honest Lawyer [Scunthorpe] - Completed out of window (1201).
* Bay Horse [Winteringham] - Completed in time with driver-generated break whilst driving.
* Break 2 - Cancelled.
* GREENE KING (Unloading) - Completed out of time (-31 minutes).
{{Note}} The job window for Honest Lawyer [Scunthorpe] should be set to 1000-1200 for this to work as described above.

Ensure that there is at least one other load on another depot, day, driver and vehicle. Ensure that there are other pending loads.

Ensure that the system type is configured as not PvA.

Ensure the available Depot list for the report is configured for the two depots.
|Objective=To test that: the report parameters screen acts as required; the report is produced as required; the report is formatted and contains the data as required.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Parameter Screen/Basic Report Production.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the Reports menu item.
|Result=The Reports screen should show, requesting the user to "Please select a Report". No parameters should be shown. The Drop-down list should contain the "TomTom Planned Vs Actuals Report" item.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the "TomTom Planned Vs Actuals Report" item.
|Result=The parameters required for this report are shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set the Site System Type to "PvA". Select the Reports menu item.
|Result=The Reports screen should show, automatically showing the "TomTom Planned Vs Actuals Report" item. The parameters required for this report are shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for the default parameters.
|Result=The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - ALL for all parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Depot.
|Result=The Drop-down list for Depot should show all configured depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Depot ID and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Driver.
|Result=The Drop-down list for Driver should show all drivers for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Driver ID and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Vehicle.
|Result=The Drop-down list for Vehicle should show all vehicles for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Vehicle ID and Reg selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Customer.
|Result=The Drop-down list for Customer should show all customers for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Customer Code and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select all Depots. Select a Customer, Driver and Vehicle. Change the Date. Select a single Depot.
|Result=The Drop-down lists for Driver, Vehicle and Customer should change to have only values associated to the selected depot. These parameters should reset to the default "All ..." values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a selection of parameters that produces no results on any page. Check the report.
|Result=All pages (tabs) should be produced. The parameter page should be produced as expected. All other pages should have headers, tables, titles and, where applicable, footers with zero totals.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test that the combination of selected parameters produces the correct selected results.
|Result=A combination of selected parameters builds the file name correctly. The Report is produced with a correct parameter page. The selected data on each report page is correct.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Report Details
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select parameters to show all loads for the all depots, customers, drivers and a date range that covers both completed loads and some incomplete loads.
|Result=The report is created.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Plan vs Actual Detail Tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected. The Plan, Actual, Variance and Percentage Variance columns for Distance, Work Time and Travel Time are all populated correctly for each job. For Loading, Unloading and Break jobs, the Account Number and Postcode are greyed out with no values. For Loading jobs, the Distance and Travel Time sections are greyed out with no values. The total values are correct for each of the summarised columns. The Driver-generated beak is visible. The travel and work time and distance on the driver-generated break is taken off the job during which it was completed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Plan vs Actual Summary Tab.
|Result=Only the 2 completed loads are selected. The Plan, Actual, Variance and Percentage Variance columns for Distance, Work Time and Travel Time are all populated correctly for each load, summarising the values from the Details tab above. The total values are correct for each of the summarised columns.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Detail tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. The Job Time window is displayed if present. The planned and arrival times are displayed. The time variance is displayed correctly. Variances or +/- 30 minutes are displayed with a red background, within the tolerance as a green background. The Time Window is correctly shown as being achieved (with a green background) or not achieved (with a red background).
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Window Summary tab.
|Result=Only the 2 completed loads are selected. The No. Planned and Achieved against each load correctly total for the drops only (ignoring multiple jobs at the same stop), summarising the values from the Time Detail tab above. The Variance is calculated correctly. The % Compliance is calculated and labelled correctly. The total values are correct for each of the summarised columns.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Window Exception tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. Only the drops with an arrival time outside the time window are displayed. The Job Time window and Arrival Time are displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Arrival Time Exception tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. Only the drops with an arrival time differing from the planned time by more than 30 minutes window are displayed. The Planned and Arrival Time are displayed. The Variance is calculated and displayed correctly.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|Ref2=336015/332569-6 WEBFLEET-ePOD Job Update Interface
|RefV2=1.0
|RefDate2=23/08/2016
|REQ=0
|EST=0
|FS=1.5
|TS=1.5
|DEV=6.75
|ST=1.25
|IMP=0
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336019 332569-9 GK Planned Vs Actual Report

2016-08-23T12:16:30Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title| Planned Vs Actual Report}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336019 332569-9}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
A series of Planned vs Actuals reports, comparing planned data from DiPS and actual data from TomTom WEBFLEET.

== Solution Overview ==
== Planned Vs Actual Reporting ==
A facility will exist within ''CALIDUS'' ePOD to allow reporting of Planned Vs Actuals. This will be available from the Reports menu in the ''CALIDUS'' ePOD Admin system.

[[file:REQ_332571_Admin_Reports.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped TomTom Planned Vs Actual Report'' 

The report is expected to be run daily.

The report will allow the following parameters to be entered:
* Depot - This will default to the current Site. The drop-down list will allow the selection of other depots configured specifically for the report, or all depots for that customer.
* Driver - an optional parameter, to select only loads completed by a particular driver. The parameter will allow selection of one specific driver from the depots selected, or all drivers from the depots selected (the default value).
* Vehicle Reg - an optional parameter, to select only loads completed on a particular vehicle. The parameter will allow selection of one specific vehicle from the depots selected, or all vehicles from the depots selected (the default value).
* Date range - a required parameter. This will select jobs with a Planned End date within this range. This will default to the current date for both parameters. A range of more than one month will not be allowed, although it will be allowed to select a range earlier.
* Customer Account number - an optional parameter, to select jobs for a specific customer only. The parameter will allow selection of one specific customer from the depots selected, or all customers from the depots selected (the default value).

[[file:REQ_332571_Admin_PvA_Parms.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped report parameters'' 

Once selected, the user will run the report, and the system will generate a Microsoft Excel file with the results.

Notes:
* Only completed or cancelled jobs will be selected.
* The report will be named based on the parameters selected:
** PVA_{Depot}_{Driver}_{Vehicle}_{Customer}_{Date}.xls
** If a parameter is left as All Values, this will not appear in the name, with the exception of Depot and Date Range.

Depending on browser settings, this may either offer to save the report immediately, or open immediately in the browser. If opened in the browser, the report may be saved locally.

An example report has been provided and is referenced in [[#Appendix B: Document References|Appendix B]].

The report will have multiple tabs as defined in the sample report provided. An additional Parameters tab will be created as the first tab, showing the parameters entered.

=== Report Parameters ===
[[file:REQ_332571_PvA_Parameters.PNG|border|600px]]
 ''Sample Plan vs Actual Parameters Tab'' 

The Parameters screen will show the report title and the selected parameters. Where a parameter is selected, the code and the description will be shown.

The page will be oriented in landscape.

General Tab Notes:
* All pages will include the title bar, consisting of the tab title alone.
* The TomTom Logo in the top left and the GK Logo in the top right will '''not''' be produced on the report. If this is required, and additional change will be required at additional cost.
* All tables will be outlined with single borders
* All titles and summary lines will be bold.
* All titles will be fixed - no additional fields can be added and the text may not be changed through configuration of the report, although they may be changed after the report is produced.
* Work time is defined as the time in between arriving at a location and departing a location. The working time consists of loading/unloading and paperwork
* Travel time is defined as the time in between the start and arrive times stored against a job, either travelling on Collections/Deliveries or travel to/from the depot.
* Route displayed on the reports will be the new Route field added to the load, if this is not blank, otherwise this will be the default Load ID.
* Date displayed on the report will be the Planned End Date, when the delivery should be completed.
* Data on the report will be primarily sorted by Planned End Date, Vehicle Reg and Route, then any additional data specific to that tab.

=== Plan vs Actual Summary ===
[[file:REQ_332571_PvA_Summary.PNG|border|600px]]
 ''Sample Plan vs Actual Summary Tab'' 

The report will show the variance between the planned distances, work time and travel time, per load (Route) and Vehicle.

Each of the monitored values will be calculated as follows:
* Plan - the sum of the planned values against the jobs on the load.
* Actual - the sum of the actual values against the jobs on the load.
* Var - the planned summed value minus the actual summed value.
* % Var - the summed variance divided by the summed planned value, expressed as a percentage with 1 decimal place.

A total line will be shown, totalling all the calculated monitored values and the total number of lines (routes).

The page will be oriented in landscape.

=== Plan vs Actual Detail ===
[[file:REQ_332571_PvA_Detail.PNG|border|600px]]
 ''Sample Plan vs Actual Detail Tab'' 

The report will show the variance between the planned distances, work time and travel time, per job (account) on a load (route).

Each of the monitored values will be calculated as follows:
* Plan - the planned values against the job.
* Actual - the actual values against the job.
* Var - the planned value minus the actual value.
* % Var - the variance divided by the planned value, expressed as a percentage with 1 decimal place.

Breaks and Depot (Loading/Unloading) jobs will not include account number and postcode.

Loading jobs will not include Distance or Travel Time variances.

The page will be oriented in landscape.

=== Time Window Summary ===
[[file:REQ_332571_Window_Summary.PNG|border|600px]]
 ''Sample Time Window Summary Tab'' 

The report will show a summary of the drops planned on a load, the number achieved within the window, and the variance.

The report will summarise at Load (route) and will display:
* No. Planned - a sum of the number of collection or delivery jobs on the load.
* No. Achieved - a sum of the number of collection or delivery jobs on the load where the actual arrival time is within the window.
* Var - No. Planned minus No. Achieved.
* % Var - No. Achieved divided by No. Planned, expressed as a percentage, rounded up. {{Note}} This is not the percentage variance, this is the percentage compliance. The column title will be labelled as '% Comp' rather than '% Var' to reflect this.

A total line will be shown, totalling all the calculated monitored values.

The page will be oriented in portrait.

=== Time Detail ===
[[file:REQ_332571_Time_Detail.PNG|border|600px]]
 ''Sample Time Detail Tab'' 

The report will show the variance between the planned time windows and planned and actual time, per job (account) on a load (route).

The report will display:
* Time Window - the time window received for the job.
* Planned Arrival Time - Planned Start Time.
* Actual Arrival Time - Arrival Time.
* Var - Actual Arrival minus planned arrival, in minutes. This should be green background if the arrival time is within 30 minutes (plus or minus) or the planned arrival time, otherwise red background.
* Achieved Time Window - Yes or, depending if the arrival time is within the time window. This should be green background if Yes, other red background.

The page will be oriented in landscape.

=== Time Window Exception ===
[[file:REQ_332571_Window_Exception.PNG|border|600px]]
 ''Sample Time Window Exception Tab'' 

The report will show any jobs where the actual arrival time is not within the planned time window, per job (account) on a load (route).

The report will display:
* Time Window - the time window received for the job.
* Arrival Time - the actual Arrival Time.

The page will be oriented in portrait.

=== Arrival Time Exception ===
[[file:REQ_332571_Arrival_Exception.PNG|border|600px]]
 ''Sample Arrival Time Exception Tab'' 

The report will show any jobs where the actual arrival time is not within 30 minutes of the planned time, per job (account) on a load (route).

The report will display:
* Planned Arrival Time - Planned Start Time.
* Actual Arrival Time - Arrival Time.
* Var - Actual Arrival minus planned arrival, in minutes.

The page will be oriented in portrait.

== Scope ==



= Set-up =
== Pre-requisites ==
The jobs must be received from DiPS for the planned values.

The jobs must be sent to TomTom WEBFLEET and updated from there to achieve the actual values.
The set-up of these interfaces are covered in the relevant specification referenced in [[#Appendix B: Quote & Document References|Appendix B]].

== Menu Structure ==
''Reports''

== Data ==
The data used by these reports is derived directly from the DiPS interface (for planned information) and WEBFLEET Update interface (for actuals information), defined in the relevant specifications referenced in [[#Appendix B: Quote & Document References|Appendix B]].


= Functional Description =

== Admin Parameters Screen ==
A facility will exist within ''CALIDUS'' ePOD to allow reporting of Planned Vs Actuals. This will be available from the Reports menu in the ''CALIDUS'' ePOD Admin system.

[[file:REQ_332571_Admin_Reports.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped TomTom Planned Vs Actual Report'' 

If the system type is "PvA" (EPL_SYSTEM_TYPE of EPOD_LOAD), the drop-down list of reports should have the value "TomTom Planned Vs Actuals Report" pre-selected and the parameters already shown. If the system type is any other value, the report screen should operate as now, in that the reports drop-down list should be showing "Please select a Report", with no parameters shown.

The report will allow the following parameters to be entered:
* Depot - This will default to the current Site. The drop-down list will allow the selection of other depots configured specifically for the report, or all depots (option "All Depots"). The list of depots accessible for the report will be set against the system in pre-configured List Items for Greene King (EPOD_LISTS and EPOD_LIST_ITEMS). {{Note}} If the Depot selected is changed, any select value in Driver, Vehicle and Customer Account Number will be reset.
* Driver - an optional parameter, to select only loads completed by a particular driver. The parameter will allow selection of one specific driver from the depots selected, or all drivers from the depots selected (the default option "All Drivers"). This list of drivers will be built after the selection of Depot. The drivers will be listed showing Site and Name and sorted this way e.g. "EAS-A Driver", This is built from EPL_SITE_ID and EPL_USER_NAME from EPOD_USER.
* Vehicle Reg - an optional parameter, to select only loads completed on a particular vehicle. The parameter will allow selection of one specific vehicle from the depots selected, or all vehicles from the depots selected (the default option "All Vehicles"). This list of vehicles will be built after the selection of Depot. The vehicles will be listed showing Site and Reg and sorted this way e.g. "EAS-AB12 CDE", This is built from EPL_SITE_ID and EPL_VEHICLE_REG from EPOD_VEHICLE.
* Date range - a required parameter. This will select jobs with a Planned End date within this range. This will default to the current date for both parameters. A range of more than one month will not be allowed, although it will be allowed to select a range earlier. If the From date selected is after the To date, the To date will default to the From date. If the To date selected is before the From date, the From date will default to the To date. The user will be provided a Calendar pop-up to select dates.
* Customer Account number - an optional parameter, to select jobs for a specific customer only. The parameter will allow selection of one specific customer from the depots selected, or all customers from the depots selected (the default option "All Customers"). This list of Customers will be built after the selection of Depot. The customers will be listed showing Site and Name and sorted this way e.g. "EAS-Ashby Mill Road Club [Scunthorpe]", This is built from EPL_SITE_ID and EPL_CUSTOMER_NAME from EPOD_CUSTOMER.

[[file:REQ_332571_Admin_PvA_Parms.PNG|border|600px]]
 ''Admin Reports Screen, showing prototyped report parameters'' 

{{Note}} Parameters selected as "All ..." will have the parameter value as blank.

Once selected, the user will run the report by clicking '''Create Excel Spreadsheet''' and the system will generate a Microsoft Excel file with the results.

{{Note}}:
* Only completed or cancelled jobs and loads will be selected.
* The report will be named based on the parameters selected:
** PVA_{Depot}_{Driver}_{Vehicle}_{Customer}_{Date}.xls
** Depot: The selected Depot ID (EPL_SITE_ID) or "ALL", plus an underscore (_).
** Driver: The selected Driver ID (EPL_USER_ID) plus an underscore (_), or omitted if All selected.
** Vehicle: The selected Vehicle ID (EPL_VEHICLE_ID) plus an underscore (_), or omitted if All selected.
** Customer: The selected Customer Code (EPL_CUSTOMER_CODE) with all spaces replaced as underscores, plus an underscore (_), or omitted if All selected.
** Date: The Date From and To, in YYYYMMDD format, concatenated with an underscore (_).

Examples:
* Where all parameters are left at the default:
** PVA_ALL_20160629_20160629.xls
* Where a specific depot (Eastwood) is selected:
** PVA_EAS_20160629_20160629.xls
* Where a specific driver (A Driver) is selected:
** PVA_EAS_adriver_20160629_20160629.xls
* Where a specific vehicle (AB12 BCD) is selected:
** PVA_EAS_adriver_AB12BCD_20160629_20160629.xls
* Where a specific Customer (268349 001 - Ashby Mill Road Club [Scunthorpe]) is selected:
** PVA_EAS_adriver_AB12BCD_268349__001_20160629_20160629.xls
* Where a 3-day range is selected (from 27/06 to 29/06):
** PVA_EAS_adriver_AB12BCD_268349__001_20160627_20160629.xls

=== Report Parameters ===
The report will have multiple tabs as defined in the sample report provided. An additional Parameters tab will be created as the first tab, showing the parameters entered.

[[file:REQ_332571_PvA_Parameters.PNG|border|600px]]
 ''Sample Plan vs Actual Parameters Tab'' 

The Parameters screen will show the report title and the selected parameters. Where a parameter is selected, the code and the description will be shown.

The selected parameters should be displayed as follows:
* All parameters will be labelled and have values and descriptions displayed as below:
** Label "Depot": The selected Depot ID (value) and Name (description) (EPL_SITE_ID and EPL_DESCRIPTION) or "All" if the parameter value is blank.
** Label "Driver": The selected Driver ID (value) and Name (description) (EPL_USER_ID and EPL_USER_NAME) or "All" if the parameter value is blank.
** Label "Vehicle": The selected Vehicle ID (value) and Reg (description) (EPL_VEHICLE_ID and EPL_VEHICLE_REG) or "All" if the parameter value is blank.
** Label "Date Range": The Date From and To, in YYYYMMDD format.
** Label "Customer": The selected Customer Code (value) and Name (description) (EPL_CUSTOMER_CODE and EPL_CUSTOMER_NAME) or "All" if the parameter value is blank.
* The columns used will be as follows:
** C - The parameter Label.
** E - The parameter value. For Date Range, the From date.
** F - " to ", only for the Date Range parameter, blank for all others.
** G - The parameter Name if the parameter value is not blank. For Date Range, the To date.

The page will be oriented in landscape.

General Tab Notes:
* All pages will include the title bar, consisting of the tab title alone. This is specified as the title of each page section following.
* The TomTom Logo in the top left and the GK Logo in the top right will '''not''' be produced on the report. If this is required, an additional change will be required at additional cost.
* All tables will be outlined with single borders.
* All page titles, column titles and total lines will be bold.
* All titles will be fixed - no additional fields can be added and the text may not be changed through configuration of the report, although they may be changed after the report is produced by manually modifying the report after production.
* Page headers, Tables, Titles and Totals (where required) will always be displayed, even if there are no other rows on the table. In this case, for a page that displays a totals row, the total row will show zero values in the summarised columns.

=== Plan vs Actual Summary ===
[[file:REQ_332571_PvA_Summary.PNG|border|600px]]
 ''Sample Plan vs Actual Summary Tab'' 

The report will show the variance between the planned distances, work time and travel time, per load (Route) and Vehicle.

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Distance (KMs)
** Plan: The sum of the planned travel distance on all the jobs on the load (summed from EPL_DISTANCE_PLANNED).
** Actual: The sum of the actual travel distance on all the jobs on the load (summed from EPL_DISTANCE_ACTUAL).
** Var: the planned summed travel distance minus the actual summed travel distance.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.
* Work Time (Mins)
** Plan: The sum of the planned work time on all the jobs on the load (summed from EPL_WORK_PLANNED).
** Actual: The sum of the actual work time on all the jobs on the load (summed from EPL_WORK_ACTUAL).
** Var: the planned summed work time minus the actual summed work time.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.
* Travel Time (Mins)
** Plan: The sum on the planned travel time on all the jobs on the load (summed from EPL_TRAVEL_PLANNED).
** Actual: The sum of the actual travel time on all the jobs on the load (summed from EPL_DRIVING_TIME).
** Var: the planned summed travel time minus the actual summed travel time.
** % Var: the summed variance (calculated above) divided by the summed planned value calculated above, expressed as a percentage with 1 decimal place.

{{Note}} The values should be calculated with a SQL statement specific to this report, summing, grouping and ordering in the mechanism specified above. The following is an example of how this might be achieved for distance:
SELECT
, el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_CODE
, el.EPL_LOAD_ID
, SUM(ej.EPL_DISTANCE_PLANNED) DistancePlan
, SUM(ej.EPL_DISTANCE_ACTUAL) DistanceActual
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
''-- Other Criteria Here''
GROUP BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID
ORDER BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID

Variance and Percentage values will be calculated from the returned Plan and Actual values.

A total line will be shown, totalling all the calculated monitored values and the total number of lines (routes). This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* Route - A count of the lines.
* Distance
** Plan - A sum of all the row values.
** Actual - A sum of all the row values.
** Var - A sum of all the row values.
** % Var - The summed Var value divided by the summed Plan value.
* Work Time - All columns totalled as above.
* Travel Time - All columns totalled as above.

The page will be oriented in landscape.

=== Plan vs Actual Detail ===
[[file:REQ_332571_PvA_Detail.PNG|border|600px]]
 ''Sample Plan vs Actual Detail Tab'' 

The report will show the variance between the planned distances, work time and travel time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE). This cell should be blank and have a grey background if the job is a depot loading or unloading job (EPL_LOADING_TYPE is not blank) or the job is a Break (EPL_CUSTOMER_CODE is "BREAK").
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below). This cell should be blank and have a grey background if the job is a depot loading or unloading job (EPL_LOADING_TYPE is not blank) or the job is a Break (EPL_CUSTOMER_CODE is "BREAK").
* Distance (KMs)
** Plan: The planned travel distance of the job on the load (EPL_DISTANCE_PLANNED). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Actual: The actual travel distance of the job on the load (EPL_DISTANCE_ACTUAL). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Var: the planned travel distance minus the actual travel distance. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
* Work Time (Mins)
** Plan: The planned work time of the job on the load (EPL_WORK_PLANNED).
** Actual: The actual work time of the job on the load (EPL_WORK_ACTUAL).
** Var: the planned work time minus the actual work time.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place.
* Travel Time (Mins)
** Plan: The planned travel time of the job on the load (EPL_TRAVEL_PLANNED). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Actual: The actual travel time of the job on the load (EPL_DRIVING_TIME). This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** Var: the planned travel time minus the actual travel time. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.
** % Var: the variance (calculated above) divided by the planned value above, expressed as a percentage with 1 decimal place. This cell should be blank and have a grey background if the job is a depot loading job (EPL_LOADING_TYPE is "L") and the planned and actual distance travelled is 0.

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} Driver-generated Break Jobs will have the same sequence as the following or in-progress job when generated. To ensure that they are displayed after they job that they interrupt, the result will also be sorted in Actual Start Date and Time sequence as well as Job Sequence.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved for distance:
SELECT
el.EPL_SITE_ID
, el.EPL_LOAD_ID
, el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, ej.EPL_CUSTOMER_CODE
, ec.EPL_CUSTOMER_NAME
, ec.EPL_POSTCODE
, eja.EPL_NAME
, eja.EPL_POSTCODE
, ej.EPL_JOB_TYPE
, ej.EPL_LOADING_TYPE
, ej.EPL_DISTANCE_PLANNED
, ej.EPL_DISTANCE_ACTUAL
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
JOIN EPOD_CUSTOMER ec
ON ec.EPL_SITE_ID = ej.EPL_SITE_ID
AND ec.EPL_CUSTOMER_CODE= ej.EPL_CUSTOMER_CODE
LEFT JOIN EPOD_JOB_ADDRESS eja
ON eja.EPL_SITE_ID = ej.EPL_SITE_ID
AND eja.EPL_JOB_TYPE = ej.EPL_JOB_TYPE
AND eja.EPL_JOB_ID = ej.EPL_JOB_ID
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
''-- Other Criteria Here''
ORDER BY
el.EPL_LOAD_END_PLANNED_DATE
, ev.EPL_VEHICLE_REG
, el.EPL_ROUTE_ID
, el.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, ej.EPL_START_ACTUAL_DATE, ej.EPL_START_ACTUAL_TIME

Variance and Percentage values will be calculated from the returned Plan and Actual values.

A total line will be shown, totalling all the calculated monitored values. This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* Distance
** Plan - A sum of all the row values.
** Actual - A sum of all the row values.
** Var - A sum of all the row values.
** % Var - The summed Var value divided by the summed Plan value.
* Work Time - All columns totalled as above.
* Travel Time - All columns totalled as above.

The page will be oriented in landscape.

=== Time Window Summary ===
[[file:REQ_332571_Window_Summary.PNG|border|600px]]
 ''Sample Time Window Summary Tab'' 

The report will show a summary of the drops planned on a load, the number achieved within the window, and the variance against the delivery/collection windows provided.

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* No. Planned: The number of jobs on the load with a unique sequence (EPL_SEQUENCE, excluding Loading/Unloading (EPL_LOADING_TYPE is not blank) or Break (EPL_CUSTOMER_CODE is "BREAK") jobs.
* No. Achieved: Of the jobs selected, those with a delivery time (EPL_END_ACTUAL_TIME) within the Job or Customer Delivery Windows - see below.
* Var: Calculated Planned above minus calculated achieved above
* % Comp: {{Note}} This is a percentage Compliance column, not a percentage variance column. Calculated Achieved above divided by calculated Planned above, with no decimal places.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved:
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_LOAD_END_PLANNED_DATE
, ej.EPL_VEHICLE_REG
, COUNT(ej.EPL_SEQUENCE) NoPlanned
, SUM(Achieved) Achieved
FROM (
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, MAX(el.EPL_LOAD_END_PLANNED_DATE) EPL_LOAD_END_PLANNED_DATE
, MAX(ev.EPL_VEHICLE_REG) EPL_VEHICLE_REG
, MAX(ej.EPL_CUSTOMER_CODE) EPL_CUSTOMER_CODE
, MAX(CASE WHEN
ej.EPL_END_ACTUAL_TIME >= COALESCE(etwj.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwj.ETW_TIME_END, 23599999)
AND ej.EPL_END_ACTUAL_TIME >= COALESCE(etwc.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwc.ETW_TIME_END, 23599999)
THEN 1 ELSE 0 END) Achieved
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwj
ON etwj.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwj.ETW_TYPE = 'J'
AND etwj.ETW_FK_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwc
ON etwc.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwc.ETW_TYPE = 'C'
AND etwc.ETW_FK_ID = ej.EPL_CUSTOMER_CODE
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
AND ej.EPL_LOADING_TYPE = ''
''-- Other Criteria Here''
GROUP BY ej.[EPL_SITE_ID]
,ej.[EPL_LOAD_ID]
,ej.[EPL_SEQUENCE]
) as ej
GROUP BY ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_LOAD_END_PLANNED_DATE
, ej.EPL_VEHICLE_REG
{{Note}} The SQL shown here consolidated the Customer and Job windows. The report will display only the achievement status and window against a single Job window. With the data expected in this implementation, this process will work. If customer windows are added or multiple windows are required, the achievement status will show correctly, however changes will be required to display the window correctly. These changes should be included as part of the work to implement multiple windows.

A total line will be shown, totalling all the calculated monitored values. This will be calculated by the process. The total line will have all columns in bold.

The columns totalled in detail are:
* No. Planned - A sum of all the row values.
* No. Achieved - A sum of all the row values.
* Var - A sum of all the row values.
* % Comp - The summed variance plus the summed No. Planned, divided by the summed No. Planned, expressed as a percentage with no decimal places.

The page will be oriented in portrait.

=== Time Detail ===
[[file:REQ_332571_Time_Detail.PNG|border|600px]]
 ''Sample Time Detail Tab'' 

The report will show the variance between the planned time windows and planned and actual time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route Number: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Time Window: Concatenated from the job time window (ETW_TIME_START and ETW_TIME_END, if either is a non-zero value)
* Planned Time: The Planned Start Time (EPL_START_PLANNED_TIME).
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME). Referred to as the Arrival Time here on in.
* Var: The Arrival Time above minus the planned time above, in minutes. This should be green background if the arrival time is within 30 minutes (plus or minus) of the planned arrival time, otherwise red background.
* Time Window Achieved Yes/No: Whether the arrival time was within the Job Time Window. This should be green background if Yes, other red background.

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} The values should be returned with a SQL statement specific to this report, ordering in the mechanism specified above. The following is an example of how this might be achieved:
SELECT
ej.EPL_SITE_ID
, ej.EPL_LOAD_ID
, ej.EPL_SEQUENCE
, MAX(el.EPL_LOAD_END_PLANNED_DATE) EPL_LOAD_END_PLANNED_DATE
, MAX(ev.EPL_VEHICLE_REG) EPL_VEHICLE_REG
, MAX(ej.EPL_CUSTOMER_CODE) EPL_CUSTOMER_CODE
, MAX(ec.EPL_CUSTOMER_NAME) EPL_CUSTOMER_NAME
, MAX(ec.EPL_POSTCODE) EPL_CUSTOMER_POSTCODE
, MAX(eja.EPL_NAME) EPL_NAME
, MAX(eja.EPL_POSTCODE) EPL_POSTCODE
, MAX(ej.EPL_JOB_TYPE) EPL_JOB_TYPE
, MAX(ej.EPL_LOADING_TYPE) EPL_LOADING_TYPE
, MAX(ej.EPL_START_PLANNED_TIME) EPL_START_PLANNED_TIME
, MAX(CASE WHEN ej.EPL_ARRIVAL_TIME > 0 THEN ej.EPL_ARRIVAL_TIME ELSE ej.EPL_END_ACTUAL_TIME END) EPL_ARRIVAL_TIME
, MAX(etwj.ETW_TIME_START) ETW_TIME_START
, MAX(etwj.ETW_TIME_END) ETW_TIME_END
, MAX(CASE WHEN
ej.EPL_END_ACTUAL_TIME >= COALESCE(etwj.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwj.ETW_TIME_END, 23599999)
AND ej.EPL_END_ACTUAL_TIME >= COALESCE(etwc.ETW_TIME_START, 0)
AND ej.EPL_END_ACTUAL_TIME <= COALESCE(etwc.ETW_TIME_END, 23599999)
THEN 1 ELSE 0 END) Achieved
FROM EPOD_LOAD el
JOIN EPOD_JOB ej
ON ej.EPL_SITE_ID = el.EPL_SITE_ID
AND ej.EPL_LOAD_ID = el.EPL_LOAD_ID
JOIN EPOD_VEHICLE ev
ON ev.EPL_SITE_ID = el.EPL_SITE_ID
AND ev.EPL_VEHICLE_ID = el.EPL_VEHICLE_ID
JOIN EPOD_CUSTOMER ec
ON ec.EPL_SITE_ID = ej.EPL_SITE_ID
AND ec.EPL_CUSTOMER_CODE= ej.EPL_CUSTOMER_CODE
LEFT JOIN EPOD_JOB_ADDRESS eja
ON eja.EPL_SITE_ID = ej.EPL_SITE_ID
AND eja.EPL_JOB_TYPE = ej.EPL_JOB_TYPE
AND eja.EPL_JOB_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwj
ON etwj.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwj.ETW_TYPE = 'J'
AND etwj.ETW_FK_ID = ej.EPL_JOB_ID
LEFT JOIN [EPODV3_DEV].[dbo].EPOD_TIME_WINDOW etwc
ON etwc.ETW_SITE_ID = ej.EPL_SITE_ID
AND etwc.ETW_TYPE = 'C'
AND etwc.ETW_FK_ID = ej.EPL_CUSTOMER_CODE
WHERE ej.EPL_STATUS IN ('C', 'X')
AND el.EPL_STATUS IN ('C', 'X')
AND ej.EPL_LOADING_TYPE = ''
''-- Other Criteria Here''
GROUP BY ej.[EPL_SITE_ID]
,ej.[EPL_LOAD_ID]
,ej.[EPL_SEQUENCE]
{{Note}} The SQL shown here consolidated the Customer and Job windows. The report will display only the achievement status and window against a single Job window. With the data expected in this implementation, this process will work. If customer windows are added or multiple windows are required, the achievement status will show correctly, however changes will be required to display the window correctly. These changes should be included as part of the work to implement multiple windows.

The page will be oriented in landscape.

=== Time Window Exception ===
[[file:REQ_332571_Window_Exception.PNG|border|600px]]
 ''Sample Time Window Exception Tab'' 

The report will show any jobs where the actual arrival time is not within the planned time window, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Time Window: Concatenated from the job time window (ETW_TIME_START and ETW_TIME_END, if either is a non-zero value)
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME).

{{Note}} Customer Names and Post Codes should be obtained from the Job Address if this exists for the job type (EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB_ADDRESS linked from EPL_JOB_TYPE and EPL_JOB_ID of EPOD_JOB respectively). If this record exists, use EPL_NAME and EPL_POSTCODE respectively, if the values are not blank. If this record does not exist or the values are blank, use EPL_CUSTOMER_NAME and EPL_POSTCODE respectively from EPOD_CUSTOMER, linked from EPL_CUSTOMER_CODE of EPOD_JOB.

{{Note}} The same query used to create the Time Detail report may be used again here. The query should not be executed again - the same result recordset may be used again. In this case, however, only records that have a window that is not achieved should be displayed here.

The page will be oriented in portrait.

=== Arrival Time Exception ===
[[file:REQ_332571_Arrival_Exception.PNG|border|600px]]
 ''Sample Arrival Time Exception Tab'' 

The report will show any jobs where the actual arrival time is not within 30 minutes of the planned time, per job (account) on a load (route).

The columns displayed on the report are:
* Date: Load Planned End Date (EPL_LOAD_PLANNED_START_DATE).
* Vehicle Reg: The registration of the vehicle that completed the load (EPL_VEHICLE_REG of EPOD_VEHICLE linked from EPL_VEHICLE_ID of EPOD_LOAD).
* Route Number: The Route Code of the load (EPL_ROUTE_CODE). If this is blank, report the Load ID instead (EPL_LOAD_ID).
* Account Name: The name of the Customer on the job (see below).
* Account Number: The Customer Code from the job (EPL_CUSTOMER_CODE).
* Postcode: The Post Code from the job address or customer address (EPL_POSTCODE - see below).
* Planned Time: The Planned Start Time (EPL_START_PLANNED_TIME).
* Arrival Time: The Arrival Time (EPL_ARRIVAL_TIME) if present, else the Actual End Time (EPL_END_ACTUAL_TIME). Referred to as the Arrival Time here on in.
* Var: The Arrival Time above minus the planned time above, in minutes.

{{Note}} The same query used to create the Time Detail report may be used again here. The query should not be executed again - the same result recordset may be used again. In this case, however, only records that have a calculated Var value of +/- 30 minutes should be displayed here.

The page will be oriented in portrait.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test the new Planned Vs Actual report content and production.
|MenuAccess=Reports
|Prerequisites=Data will be set up as per the test load in the DiPS sample file (Load 46004, Route E2010). The data should be completed as follows:
* GREENE KING - Completed in time in window.
* White Swan [Scotter] - Completed in time in window.
* Queensway [Scunthorpe] - Completed out of time (+35 minutes) in window.
* Ashby Mill Road Club [Scunthorpe] - Completed out of window (1031).
* Break 1 - Completed.
* Priory [Scunthorpe] - Completed in time in window.
* Honest Lawyer [Scunthorpe] - Completed out of window (1201).
* Bay Horse [Winteringham] - Completed in time with driver-generated break whilst driving.
* Break 2 - Cancelled.
* GREENE KING (Unloading) - Completed out of time (-31 minutes).
{{Note}} The job window for Honest Lawyer [Scunthorpe] should be set to 1000-1200 for this to work as described above.

Ensure that there is at least one other load on another depot, day, driver and vehicle. Ensure that there are other pending loads.

Ensure that the system type is configured as not PvA.

Ensure the available Depot list for the report is configured for the two depots.
|Objective=To test that: the report parameters screen acts as required; the report is produced as required; the report is formatted and contains the data as required.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Parameter Screen/Basic Report Production.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the Reports menu item.
|Result=The Reports screen should show, requesting the user to "Please select a Report". No parameters should be shown. The Drop-down list should contain the "TomTom Planned Vs Actuals Report" item.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the "TomTom Planned Vs Actuals Report" item.
|Result=The parameters required for this report are shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set the Site System Type to "PvA". Select the Reports menu item.
|Result=The Reports screen should show, automatically showing the "TomTom Planned Vs Actuals Report" item. The parameters required for this report are shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for the default parameters.
|Result=The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - ALL for all parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Depot.
|Result=The Drop-down list for Depot should show all configured depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Depot ID and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Driver.
|Result=The Drop-down list for Driver should show all drivers for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Driver ID and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Vehicle.
|Result=The Drop-down list for Vehicle should show all vehicles for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Vehicle ID and Reg selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a single Customer.
|Result=The Drop-down list for Customer should show all customers for all depots. The report should run and offer to download the result with the correct naming convention. When downloaded, the Report Parameter page should show the selected parameters correctly - The Customer Code and Name selected, ALL for all other parameters, except Date Range, which should show today's date in the From and To values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select all Depots. Select a Customer, Driver and Vehicle. Change the Date. Select a single Depot.
|Result=The Drop-down lists for Driver, Vehicle and Customer should change to have only values associated to the selected depot. These parameters should reset to the default "All ..." values.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Run the report for a selection of parameters that produces no results on any page. Check the report.
|Result=All pages (tabs) should be produced. The parameter page should be produced as expected. All other pages should have headers, tables, titles and, where applicable, footers with zero totals.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test that the combination of selected parameters produces the correct selected results.
|Result=A combination of selected parameters builds the file name correctly. The Report is produced with a correct parameter page. The selected data on each report page is correct.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Report Details
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select parameters to show all loads for the all depots, customers, drivers and a date range that covers both completed loads and some incomplete loads.
|Result=The report is created.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Plan vs Actual Detail Tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected. The Plan, Actual, Variance and Percentage Variance columns for Distance, Work Time and Travel Time are all populated correctly for each job. For Loading, Unloading and Break jobs, the Account Number and Postcode are greyed out with no values. For Loading jobs, the Distance and Travel Time sections are greyed out with no values. The total values are correct for each of the summarised columns. The Driver-generated beak is visible. The travel and work time and distance on the driver-generated break is taken off the job during which it was completed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Plan vs Actual Summary Tab.
|Result=Only the 2 completed loads are selected. The Plan, Actual, Variance and Percentage Variance columns for Distance, Work Time and Travel Time are all populated correctly for each load, summarising the values from the Details tab above. The total values are correct for each of the summarised columns.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Detail tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. The Job Time window is displayed if present. The planned and arrival times are displayed. The time variance is displayed correctly. Variances or +/- 30 minutes are displayed with a red background, within the tolerance as a green background. The Time Window is correctly shown as being achieved (with a green background) or not achieved (with a red background).
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Window Summary tab.
|Result=Only the 2 completed loads are selected. The No. Planned and Achieved against each load correctly total for the drops only (ignoring multiple jobs at the same stop), summarising the values from the Time Detail tab above. The Variance is calculated correctly. The % Compliance is calculated and labelled correctly. The total values are correct for each of the summarised columns.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Time Window Exception tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. Only the drops with an arrival time outside the time window are displayed. The Job Time window and Arrival Time are displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the Arrival Time Exception tab.
|Result=Only the 2 completed loads and completed or cancelled jobs on those loads are selected, excluding all breaks and loading/unloading jobs. Only the drops are displayed, ignoring multiple jobs at the same stop. Only the drops with an arrival time differing from the planned time by more than 30 minutes window are displayed. The Planned and Arrival Time are displayed. The Variance is calculated and displayed correctly.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|Ref2=336015/332569-6 WEBFLEET-ePOD Job Update Interface
|RefV2=1.0
|RefDate2=23/08/2016
|REQ=0
|EST=0
|FS=1.5
|TS=1.5
|DEV=6.75
|ST=1.25
|IMP=0
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=OBSL Project Manager
|Rev2=Matt Tipping
|Rev2Title=Greene King Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336015 SCR-332569-6 GK PvA WEBFLEET-ePOD Interface

2016-08-23T12:13:44Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|- WEBFLEET-ePOD Job Update Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336015 - SCR-332569-6, SCR-332569-7, SCR332569-8}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
As each job is actioned by the drivers, information on those actions is stored within TomTom WEBFLEET. This information will be pulled back into {{#var:System}} and will update the jobs. A new process will be required to complete this. This will be a timed process, running at regular intervals.

== Solution Overview ==
{{SCR|Reference=332569|SCRNo=6
|Definition=WEBFLEET-ePOD Job Update Interface.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will create a queue to poll for:
* Order Completion messages
* Order Cancellation messages
* Order Started messages
* Order Arrived messages
All these messages should include Odometer and Lat/Long co-ordinates.

Each message will be processed and then acknowledged from the queue. The success or failure of processing of the message files received from TomTom will be audited.

It is intended that processing these messages will provide the following information:
* Job Status (Completed/Cancelled)
* Reason for cancellation if required
* Start/Arrival/End Times
* Start/Arrival/End Odometer readings
This information will then be used to update the jobs on {{#var:System}}.

{{Note}} Jobs that are cancelled on TomTom WEBFLEET devices provide a different interface back into {{#var:System}} - this requires prototyping at functional specification stage and may result in increased cost. Reasons entered against a cancelled job are also required. It is expected, however, that the costs in this document will be sufficient to achieve the full interface.

TomTom WEBFLEET non-working time (unplanned breaks) is required to be supported by this project and therefore this interface - if the driver logs non-working time as part of the execution of an order, this will generate a break job in the database, with no planned times or distances. Additionally, this time will be taken away from any travel or working time on any jobs that have actual start, arrival or end times around that unplanned break.
{{SCR|Reference=332569|SCRNo=7
|Definition=Update non-working time as a new break
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

When all jobs on a load are updated to cancelled or completed through this interface, the load will be marked as complete.

An optional change has also been requested to indicate the position at which the driver clicks the Arrive button, so that Greene King can check the location.
{{SCR|Reference=332569|SCRNo=8
|Definition=Display location of TomTom Order Arrival.
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

In order to achieve this, this process will write User Audit records for each message processed from the TomTom files received, for the following information:
* Order Started
* Order Arrived
* Order Completed

This information would then be accessible through the existing {{#var:System}} User Audit Admin screen.

[[file:FS_336015_User_Tracking.PNG|border|600px]]
 ''Admin User Tracking Screen, showing prototyped TomTom messages'' 

== Scope ==
This document covers 3 changes from the solution design:
* 336015 SCR-332569-6 WEBFLEET-ePOD Job Update Interface
* 336016 SCR-332569-8 Display location of TomTom Order Arrival
* 336017 SCR-332569-7 Update non-working time as a new break
The estimates in [[#Appendix B: Quote & Document References|Appendix B]] are the combined values from these 3 changes.

{{Note}} This interface will be written to capture the events related to Orders and start/stop working time only - Geofence breaks will not be captured or created as part of this interface and will NOT debrief the loads and jobs in {{#var:System}}.

{{Note}} This interface identifies the Site for WEBFLEET updates by extracting it from the Order Number sent to WEBFLEET. This requires a fixed Job ID length of 10 characters, which is the default when sending orders to WEBFLEET. If the interface is used as described in the solution design, this interface will function automatically with no issues and no manual intervention. If any other mechanism is used to generate the orders in WEBFLEET, or the Job IDs are created at a different length, this update process will not work as described.

{{Note}} This interface identifies driver-generated Breaks through the external (WEBFLEET) vehicle ID in order to find the load that is in progress. Where the same vehicle is in use on multiple sites, this can compromise the interface for generation of breaks.

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. Under the full {{#var:System}} solution, driver-generated breaks on the device will not be processed through this TomTom WEBFLEET interface. The system will then restrict the messages read from WEBFLEET to Order-only messages, rather than all messages. Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

{{Note}} When jobs are consolidated and will be actioned together on the device ((i.e. the linked ID is set to be the same value on multiple jobs), the actual values for work, travel and distance will still be updated on the job. This must be taken into account when producing the Planned Vs Actuals report, so that the values are reported on only one of the consolidated jobs on the load.


= Set-up =
== Pre-requisites ==
The Sites must be pre-configured by the OBSL implementation team to point to the correct WEBFLEET fleet. This is a requirement of the Breaks solution. This is not configurable by the users. If this is not configured, driver-generated breaks from WEBFLEET will not be processed and added.

== Menu Structure ==
N/A.

== Data ==
For full functionality to be enabled, the {{#var:System}} system must be configured for PvA only, through the Site maintenance screen (on the ''Administration'' menu), ''Details'' tab, System Type setting.

[[file:FS_336015_Admin_Site.PNG|border|600px]]
 ''Admin Site Screen, showing prototyped System Type'' 

TomTom WEBFLEET-specific reason codes should be created for the Sites in advance:
* "TWCD" - description "TomTom WEBFLEET - Cancelled by Driver".
* "TWRD" - description "TomTom WEBFLEET - Rejected by Driver".
These reason codes should be created at Job and Detail level.

[[File:FS_336015_Admin_Codes.PNG|border|600px]]
 ''Codes Maintenance Screen'' 

Set up the sites for WEBFLEET inbound interface.

New EPOD_XF_CONFIG configurations will be required:
* EPL_XF_CONFIG_ID - A new configuration name to be applied to sites that do not have an Export Configuration yet, or the Export Configuration ID of the existing configuration.
* EPL_XF_ID - "TO" - TomTom Update
* EPL_SOAP_ACTION - ""
* EPL_SOAP_NS - "ser"
* EPL_SOAP_NS_PREFIX - <nowiki>"http://connect.webfleet.tomtomwork.com/services"</nowiki>
* EPL_WEB_USER - "admin"
* EPL_WEB_PASSWORD - "Matt3221"
* EPL_XF_RECIPIENT - Account - "logistics-obs"
* EPL_XF_DESTINATION - <nowiki>"https://soap.business.tomtom.com/v1.28/messagesService"</nowiki>
* EPL_XF_MSG_TYPE - API Key - "000fcb2a-6631-477a-b00e-de0505e7c7e3"
* EPL_XF_DIRECTION - "I"
* EPL_XF_TYPE - "SOAP"

[[File:FS_336015_Admin_AutoExport.PNG|border|600px]]
 ''Import/Export Config Screen'' 

This configuration must be added to all of the sites that requires TomTom interfaces for that WEBFLEET fleet. If a site already has a configuration attached to it, a configuration should be added to the same configuration name. {{Note}} This configuration of the interface will bring back all updates from the fleet, regardless of site. However, the interface configuration is required against all sites, so that the parameters may be used to identify to which site the vehicle belongs.

Vehicles must be set up for WEBFLEET, with an external reference matching the object ID in WEBFLEET:

[[File:FS_336015_Admin_Vehicles.PNG|border|600px]]
 ''Vehicles Maintenance Screen'' 

[[File:FS_336015_WEBFLEET_Vehicles.PNG|border|600px]]
 ''WEBFLEET Vehicles Screen'' 



= Functional Description =
== Database/DAL ==
New fields will be added to the EPOD_JOB table:
* EPL_WORK_ACTUAL - number - to hold the value of the Actual Work Time from WEBFLEET in whole numbers of minutes.
* EPL_ODO_START - float - to hold the Start Odometer reading from WEBFLEET.
* EPL_ODO_END - float - to hold the End Odometer reading from WEBFLEET.
All database packages and the DAL object will be changed to update and retrieve these new fields.
{{Note}} It is not necessary to add these fields as search-able items.

{{Note}} The following existing fields will be used to store Actual times and distances in addition to the new field above:
* EPL_DISTANCE_ACTUAL - Actual distance travelled. {{Note}} This must be changed to a float type (i.e. capable of storing decimal values).
* EPL_DRIVING_TIME - Actual driving time in whole numbers of minutes.

The existing EPOD_LOAD fields EPL_LOAD_DISTANCE_PLANNED and EPL_LOAD_DISTANCE_ACTUAL should be changed to be a float type (i.e. capable of storing decimal values).

{{Note}} As standard, these fields will be added to the standard XML Webservice Import and Export flows. These changes (and all others for the project) have been documented and referenced in [[#Appendix B: Quote & Document References|Appendix B]]. The standard XSD files describing the XML in detail will also be updated as part of this project. Note specifically that all fields changed to float type will need to have the type changed to "xsd:float".

A new field will be added to the EPOD_SITE table:
* EPL_EXT_FLEET - nvarchar(40) - to hold the value of the WEBFLEET fleet ID.
All database packages and the DAL object will be changed to update and retrieve this new field.
{{Note}} It is not necessary to add this field as search-able items.

{{Note}} Indexes are required for the following tables, to improve efficiency of finding applicable vehicles to create breaks:
* EPOD_VEHICLE - Index EPV_EXT_IDX as EPL_EXT_REF, EPL_SITE_ID, EPL_VEHICLE_ID.
* EPOD_SITE - Index EPS_EXT_IDX as EPL_EXT_FLEET, EPL_SITE_ID.
* EPOD_LOAD - Index EPL_VEHICLE_STATUS_IDX as EPL_SITE_ID, EPL_VEHICLE_ID, EPL_STATUS, EPL_LOAD_ID

== Auto Import Process ==
Retrieving messages from WEBFLEET is through the use of message queues, created and accessed through the TomTom WEBFLEET API, referenced in [[#Appendix B: Quote & Document References|Appendix B]].

A request to the created message queue will be made through the webservice method popQueueMessagesExtern.

Before using popQueueMessagesExtern to retrieve outstanding messages, a queue must be created using the createQueueExtern method, using the same message class
parameter that is being provided with calls to popQueueMessagesExtern. In this case, the message class is 2 (all messages except tracking messages).

{{Note}} The resulting data set is delivered in the language chosen in the WEBFLEET account and not on the language indicated in the lang parameter.

The structure of the popQueueMessagesExtern method is as follows:

<ser:popQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:popQueueMessagesExtern>

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. In this case, the message queue created and used for WEBFLEET messages will require to be filtered for all messages except tracking messages (filter attribute "ALL_EXCEPT_POSITION_MESSAGES"). This attribute is used on all WEBFLEET webservice calls to create, pop and acknowledge messages from that queue. This is only the case when the Site's System Type (EPL_SYSTEM_TYPE) is "PvA". This is only required when creating breaks through WEBFLEET. When the full {{#var:System}} system is in use, this will not be the case, and therefore the WEBFLEET messages can be more strictly filtered to only Order-based messages (filter attribute "ORDER_RELATED"). The mcgClass filter attribute on ''all'' WEBFLEET message queue methods in this document should be set to "ORDER_RELATED" if the Site's System Type (EPL_SYSTEM_TYPE) is anything except "PvA".

Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

The response to a popQueueMessagesExtern message is as follows:
<ns3:popQueueMessagesExternResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns3="http://connect.webfleet.tomtomwork.com/services">
<return>
<statusCode>9195</statusCode>
<statusMessage>...Details of the status...</statusMessage>
<errors>
<errorInfo objectName="QueueServiceParameter" fieldName="filter">
<msg>A value is required</msg>
</errorInfo>
</errors>
<resultSize>0</resultSize>
<results xsi:nil="true"/>
</return>
</ns3:popQueueMessagesExternResponse>

The above response object also shows the result should an error occur. TomTom Responses have been handled before when processing sending orders to WEBFLEET in the Auto Export process (in method EPOD_SYS_EXPORT.TomTomOrdersProcessData). A similar process should be implemented here:
* If the status code returned is 0, the message was successful.
* If the status code returned is 8011, request limits were reached - in this case treat this as a failure.
* If the status code returned is 9303, the message queue request failed - see the following section.
* Any other status code returned should be treated as a failure.

If the message queue request failed, it may not be set up yet. This is indicated by the errorInfo/msg tag starting with "WFCQ_E0022". If any other error message is received, write an XF Audit record, indicating "Unable to read from queue" plus the description from the msg tag.

If the queue has not been set up yet, the process should create it at this time. This is through a call to the createQueueExtern webservice method, populated as follows:

<ser:createQueueExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:createQueueExtern>

To call this, simply replace the outer tags of the previous request and resend the SOAP request.

The response object for this call is identical to the response to all other calls, except that the outer tag is createQueueExternResponse. Anything other than "0" (Success) in the status code means a failure to create the queue. In the case of failure, write an XF Audit record, indicating "Creation of queue failed" plus the description from the msg tag.

{{Note}} If the queue is created here, there is no need to continue with the process, as there will be no messages in the queue yet - the process can finish here.

The results tag will contain the results in sub-tags called resultItem. Example files exist for this data returned. The following are example result items for each item that the process will be dealing with:

'''Starting an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949248423"/>
<msgTime>2016-06-20T15:05:06.008Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order TW0000000001: started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349133</latitude>
<longitude>-2852108</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:05:04Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''In progress to an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949319260"/>
<msgTime>2016-06-20T15:06:19.388Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000761</msgType>
<msgText>Order TW0000000001: est. arrival 16:24, 11 mi to destination</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852109</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:06:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<eta>2016-06-20T15:24:56Z</eta>
<distance>17249</distance>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''On and Off a Break:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851082"/>
<msgTime>2016-06-20T15:15:48.686Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Pause started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<pndconn>0</pndconn>
<tripMode>1</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:05Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>PAUSE</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:05Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851641"/>
<msgTime>2016-06-20T15:15:49.258Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Work started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<tripMode>2</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:25Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>WORKING</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:25Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Cancellation:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950259474"/>
<msgTime>2016-06-20T15:23:18.805Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100734</msgType>
<msgText>Order TW0000000001: cancelled "unexpected cow"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852117</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:23:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>301</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>unexpected cow</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Rejection:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950499987"/>
<msgTime>2016-06-20T15:27:50.947Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100731</msgType>
<msgText>Order TW0000000002: rejected "rejected by duck"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349067</latitude>
<longitude>-2852166</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:27:48Z</posTime>
<speed>0</speed>
<course>282</course>
<direction>7</direction>
<status>A</status>
<orderNo orderNo="TW0000000002"/>
<orderState>302</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>rejected by duck</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Arrived at Delivery Location:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856914199"/>
<msgTime>2016-06-17T14:06:20.409Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: arrived at delivery location</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349010</latitude>
<longitude>-2851930</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:19Z</posTime>
<speed>2</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>242</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Order Finished:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856918353"/>
<msgTime>2016-06-17T14:06:24.714Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: finished</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349020</latitude>
<longitude>-2851940</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:23Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>401</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

All result items should be processed in sequence, by looping through them.

The tags in this resultItem that are required are as follows:
* msgClass - for filtering messages.
* msgType - for filtering messages.
* objectNo - the vehicle's external (TomTom WEBFLEET) reference.
* odometer - the Odometer reading in KM. This may not be present, depending on hardware and configuration.
* pos/latitude - the latitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* pos/longitude - the longitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* posTime - the date and time the message was created. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* orderNo@orderNo - the unique order number passed to WEBFLEET when the order was created. For {{#var:System}} this will the value from External System ID, usually the Site ID and Job ID combined. This differs for consolidated jobs and should be confirmed as to the actual value.
* orderState - for filtering messages.
* eta - the estimated time of arrival at the location for the order. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* pndWorkingStateMessageData/workstate - determines break status.
* userText - the text entered when cancelling or rejecting an order on the device.

{{Note}}
* A slash (/) in the tag name (e.g. pndWorkingStateMessageData/workstate) indicates that this is a sub-tag of another tag.
* An At symbol (@) in the tag name (orderNo@orderNo) indicates that this is an attribute of the named tag.
* Tags (and sub-tags) may not exist for each message, so each tag must be extracted and checked individually, or the errors handled when extracting values from tags.
* Longitudes and Latitudes are stored in micro-degrees and must be divided by 1,000,000 for storing in {{#var:System}}.
* Times are in xsd:dateTime format and must be converted. Furthermore, they are in UTC, and must be converted to the local server timezone when storing.

'''General Processing'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag values "DATA" and "ORDER" only.
* Convert the date/time from the posTime tag in the result.
* Convert the ETA date/time from the eta tag in the result, if present.
* Convert and validate the ODO reading from the odometer tag in the result, if present.
* Convert and validate the GPS location from the pos tag, sub-tags latitude and longitude in the result.

'''Processing of result records with an order state value:'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag value "ORDER" and for the following orderState tag values:
** 221 - Pickup order started
** 222 - Arrived at Pickup location
** 241 - Delivery order started
** 242 - Arrived at Delivery location
** 301 - Cancelled
** 302 - Rejected
** 401 - Finished
* Get the Job or Jobs (EPOD_JOB) using the extracted Site (EPL_SITE_ID) and External System Reference (EPL_EXTERNAL_SYSTEM_ID) from the orderNo tag attribute value. {{Note}} There can be multiple jobs for the External System Reference.
* Stop processing this result record if this job is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Load (EPOD_LOAD) from the Job's Load ID (EPL_LOAD_ID). Store the Load ID in a list of loads processed from this response.
* Stop processing this result record if this load is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Vehicle (EPOD_VEHICLE) from the Load's Vehicle ID (EPL_VEHICLE_ID).
* Set the Vehicle's last position, date and time as follows:
** Set the Last Position (EPL_LAST_POSITION) from the converted values of the result tags latitude and longitude values, concatenated with a comma.
** Set the Last Position Date and time (EPL_LAST_POSITION_DATE and EPL_LAST_POSITION_TIME) from the extracted date and time from the tag posTime value, translated into OBS format.

* For order states 221 and 241 (order started):
** Set the Actual Start date and time if not already populated (EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "I" - In Progress if not already in progress.
** If the job was not already in progress, find any other in-progress jobs against the load and set to status pending (EPL_STATUS set to "P"). If they already have a value in start odometer (EPL_ODO_START), set the distance travelled (EPL_DISTANCE_ACTUAL) to tag odometer value minus the value in the jobs' start odometer and zero the jobs' start odometer value.
** Set the ETA date and time against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME) from the tag eta value, if present, translated into OBS format.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the Start Odometer reading on the Job or Jobs (EPL_ODO_START) to the tag odometer value, if not already populated.
** If present in the incoming result, set the ODO start against the Load (EPL_MILEAGE_START) from the tag odometer value, if not already populated.
** Write a User Tracking record for each of the jobs - see below for details.

* For order states 222 and 242 (arrived at location):
** Update Arrival date and time against the job or jobs if not already populated (EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME) from the tag posTime value, translated into OBS format.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Write a User Tracking record for each of the jobs - see below for details.

* For order state 401 (Finished):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "C" - Complete if not already complete.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the End Odometer reading on the Job to the tag odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If the status of the job (EPL_STATUS) is not "I" (In Progress), set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", complete all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "C" - Complete.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled) or order status 302 (Rejected):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set Job or Jobs status (EPL_STATUS) to "X" - Cancelled.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set the Reason Code against the Job or Jobs (EPL_REASON_CODE) to "TWCD" (for order status 301) or "TWRD" (for order status 302).
** Set the User Notes (EPL_USER_NOTES) against the Job or Jobs to be the tag userText value.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the incoming odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", cancel all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "X" - Cancelled.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled), 302 (Rejected) and 401 (Complete):
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.

* Ignore any other messages than the ones above, if the System Type (EPL_SYSTEM_TYPE) is ''not'' "PvA" - breaks will not be processed through this TomTom WEBFLEET interface when the full {{#var:System}} system is being run.

'''Processing of result records without an order state value:'''
These messages are used predominantly to generate breaks indicated by the driver.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for tag msgClass value "DATA" and the following message types (extracted from the last 3 digits of the value in the msgType tag):
** 711 - Log-off driver (including tachograph driver card removed) - treat as end of break.
** 712 - Begin of work, driver indicated - treat as end of break.
** 713 - End of work, driver indicated - treat as end of break.
** 714 - Begin of break, driver indicated - treat as start of break.
** 715 - End of break, driver indicated - treat as end of break.
** 716 - Work status change, indicating driver role, old and new work status (applies to all PRO 71xx, 91xx devices when used with identified driver and Remote LINK Working Time). If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.
** 717 - Work started (driver role and driver name indicated) - treat as end of break.
** 718 - Work ended (driver role and driver name indicated) - treat as end of break.
** 719 - Work time event, indicating driver. If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.

* If treating the message as Start of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a break (either generated by the system or generated by DiPS) that is status In Progress (EPL_STATUS is "I"). If there is one, ignore this message, as a break is already started.
** Find the first job on that load that is not complete i.e. the status (EPL_STATUS) is "P" - Pending - or "I" - In Progress, ordering by the status In Progress (i.e. those jobs should be the first jobs found).

** Create a new break job as follows:
*** EPL_SITE_ID - From the found Load's Site ID
*** EPL_LOAD_ID - From the found Load ID
*** EPL_JOB_ID - Generated
*** EPL_JOB_CODE - "BRK_<EPL_LOAD_ID>_<EPL_SEQUENCE_NO>". The tagged values should be substituted with the found Load ID, and the DIPS column value LINK SEQ NO respectively.
*** EPL_JOB_TYPE - "D"
*** EPL_JOB_GROUP - "OTHER"
*** EPL_JOB_INSTRUCTION - "Driver Break"
*** EPL_START_PLANNED_DATE - from the tag posTime value.
*** EPL_START_PLANNED_TIME - from the tag posTime value.
*** EPL_START_ACTUAL_DATE - from the tag posTime value.
*** EPL_START_ACTUAL_TIME - from the tag posTime value.
*** EPL_ARRIVAL_DATE - from the tag posTime value.
*** EPL_ARRIVAL_TIME - from the tag posTime value.
*** EPL_END_PLANNED_DATE - from the tag posTime value.
*** EPL_END_PLANNED_TIME - from the tag posTime value.
*** EPL_DISTANCE_PLANNED - 0
*** EPL_CUSTOMER_CODE - "BREAK"
*** EPL_CUSTOMER_NAME - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_ADDRESS_1 - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_POSTCODE - The postcode from the found job.
*** EPL_SEQUENCE - The sequence from the found job
*** EPL_LOADING_TYPE - Blank
*** EPL_TRAVEL_PLANNED - 0
*** EPL_WORK_PLANNED - 0
*** EPL_LAT - from the tag pos, sub-tag latitude value, converted to degrees.
*** EPL_LONG - from tag pos, sub-tag longitude value, converted to degrees.
*** EPL_LAST_CHANGED_DATE - Now
*** EPL_LAST_CHANGED_TIME - Now
*** EPL_ODO_START - from the tag odometer value, if present.
*** EPL_GENERATED - "Y" - Generated by the driver.
*** EPL_STATUS - "I" - In Progress
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - Start of Break" - see below for details.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

* If treating the message as End of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a driver-generated break that is status In Progress (EPL_STATUS is "I"). If there is not one one, ignore this message.
** If there is one, update it as follows:
*** Set the Actual End date and time (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
*** Set the break job's ODO End (EPL_ODO_END) from the tag odometer value if present.
*** Set the break job's status to Complete (EPL_STATUS = "C".
*** Set the Last Changed date and time (EPL_LAST_CHANGED_DATE and EPL_LAST_CHANGED_TIME) to the current server time, in OBS format.
*** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
*** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
*** Set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value on the job (EPL_ODO_START), plus any value already in this distance travelled job field.
** If the break job found is a driver-generated break job, find any non-break jobs in progress (EPL_STATUS = "I") on the load. If found, set the distance (EPL_DISTANCE_ACTUAL) and travel time (EPL_DRIVING_TIME) on all the jobs to be the current values minus the values on the break job just updated, plus any value already in these fields. This will then remove the distance and travel that was added to the Break job from the job in progress, for the Planned vs Actual reporting later.
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - End of Break" - see below for details.
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

{{Note}} Any messages in the result that do not match the filtered messages above can be ignored - no audit is required.

{{Note}} When writing order tracking records to EPOD_USER_AUDIT, all of the normal details should be entered. This should be sourced from the Job record being updated unless specified otherwise:
* Site ID
* User ID - From the Load
* Vehicle ID - From the Load
* Load ID - From the Load
* Job ID
* Message Type - dependent on the tag orderState of the result being processed:
** 221 or 241 - "WEBFLEET - Order Started"
** 222 or 242- "WEBFLEET - Order Arrived"
** 301 - "WEBFLEET - Order Cancelled"
** 302 - "WEBFLEET - Order Rejected"
** 401 - "WEBFLEET - Order Complete"
** If this is Blank and the process is treating this as a Start of Break - "WEBFLEET - Start of Break"
** If this is Blank and the process is treating this as an End of Break - "WEBFLEET - End of Break"
* GPS Coordinates - from the converted values of the input tag pos, sub-tags latitude and longitude values, concatenated with a comma.
* Audit Date - The server date as of the time the record is processed.
* Audit Time - The server time as of the time the record is processed.
* Job Type
* Device Date - extracted date from the tag posTime value, translated into OBS format.
* Device Time - extracted time from the tag posTime value, translated into OBS format.

{{Note}} Once messages taken from the queue in this message response are successfully processed, the process must use the webservice method ackQueueMessagesExtern to acknowledge completion of the message transfer to the application. Otherwise, the messages will be kept and returned again during the next call to popQueueMessagesExtern.

{{Note}} In order to prevent this system from being flooded with over-sized responses, the number of messages that will be returned on a single response is limited to 500. This limit can be adjusted per account on request.

The structure of the ackQueueMessagesExtern method is identical to the above Pop message, except for the name, as follows:
<ser:ackQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:ackQueueMessagesExtern>

Again, the response to this message will be the same as the other WEBFLEET messages, except that the outer tag is ackQueueMessagesExternResponse. Regardless of status, the

Should the value of the tag resultSize be 500, this whole process of retrieving, processing and acknowledging messages should be repeated. This should continue until the result size is less than 500 (i.e. there are no more messages on the queue).

Should there be a problem processing the messages from the queue, an audit record of the row detail and the error code should be created in EPOD_XF_AUDIT_HEADER. Failing a single message does not result in the message failing - these should always be acknowledged. Failures encountered server-side (failures within {{#var:System}} should result in not acknowledging the message, so that they may be reprocessed later by re-reading them from the queue.

When writing Audit records for failures and successes, the records should be populated as follows. If not specified, the values should be derived from the job:
* Site.
* Job Group, if this is an audit related to a job.
* Header ID - Generated.
* Request Data - If Failure, the resultItem tag and contents.
* Request Date - The server date as of the time the record is processed.
* Request Time - The server time as of the time the record is processed.
* Status - "S" for Success, "F" for Fail, as indicated above when writing the audit record.
* Status Description - If Success, "Jobs Updated", else the reason for the failure (e.g. "Load already completed", "Job already cancelled", etc) as indicated above.
* Key Value 1 - The Job Code, if this is an audit related to a job.
* Key Value 2 - The Job ID, if this is an audit related to a job.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing all aspects of the WEBFLEET - {{#var:System}} Update Interface.
|MenuAccess=N/A
|Prerequisites=Create 2 loads with jobs configured as per the example Load in the supplied CSV extraction from DiPS.
|Objective=To test that: jobs are updated with all actual information; Loads are updated correctly; jobs done out of sequence are updated taking into account any intermediate distance and time; driver-generated breaks are created correctly; jobs completed with breaks whilst in progress are updated taking into account any intermediate distance and time.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 1 - Normal Processing.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept and Start Loading job.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Arrive Loading Job.
|Result=Job updated in C-ePOD - Arrival Date/Time and End ODO updated, Travel Time and Distance updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD - Job Complete, Actual End Date/Time updated, Work Time updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept, Start and Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Reject Delivery Job 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Delivery Job 3.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Delivery 1.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Consolidated Delivery 2.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 2 before the next job (out of sequence).
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 4.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated. Next Load automatically set to In Progress (not part of this test).
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 2 - Out of sequence.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start and Drive to Delivery Job 1. Do not Arrive at Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job In Progress, Actual Start Date/Time, Job Start ODO updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start, Arrive and Complete Delivery Job 2 before completing Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance Travel times take into account the distance and time travelled on the job 2 in between.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 3 - Driver-generated Breaks.
|Notes=Continuing from Cycle 2.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause Work.
|Result=Creates new break job as specified.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Work.
|Result=Updates new break job - Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised break job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Consolidated jobs 1.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause and Start Work.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the Break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Continue Consolidated jobs. Pause and Start Work again.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the next Break added to the previous break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Jobs 1.
|Result=Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs. Distance, Work and Travel times take into account the distance, work and time travelled on the 2 break jobs in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete consolidated jobs 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the next job. Pause and Start work, complete job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance, Work and Travel times take into account the distance, work and time travelled on the break job in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised Break.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|Ref2=EPOD Import Mapping
|RefV2=5.1.2
|RefDate2=17/06/2016
|Ref3=EPOD Export Mapping
|RefV3=5.1.2
|RefDate3=17/06/2016
|Ref4=WEBFLEET.connect Reference
|RefV4=1.28.0
|RefDate4=31/03/2016
|Ref4=obs-eas-DIPS2AXS for PvA.xls
|RefV4=N/A
|RefDate4=24/06/2016
|REQ=0
|EST=0
|FS=1.75
|TS=1.75
|DEV=7.25
|ST=1.50
|IMP=0
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336015 SCR-332569-6 GK PvA WEBFLEET-ePOD Interface

2016-08-23T12:13:17Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|WEBFLEET-ePOD Job Update Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336015 - SCR-332569-6, SCR-332569-7, SCR332569-8}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
As each job is actioned by the drivers, information on those actions is stored within TomTom WEBFLEET. This information will be pulled back into {{#var:System}} and will update the jobs. A new process will be required to complete this. This will be a timed process, running at regular intervals.

== Solution Overview ==
{{SCR|Reference=332569|SCRNo=6
|Definition=WEBFLEET-ePOD Job Update Interface.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will create a queue to poll for:
* Order Completion messages
* Order Cancellation messages
* Order Started messages
* Order Arrived messages
All these messages should include Odometer and Lat/Long co-ordinates.

Each message will be processed and then acknowledged from the queue. The success or failure of processing of the message files received from TomTom will be audited.

It is intended that processing these messages will provide the following information:
* Job Status (Completed/Cancelled)
* Reason for cancellation if required
* Start/Arrival/End Times
* Start/Arrival/End Odometer readings
This information will then be used to update the jobs on {{#var:System}}.

{{Note}} Jobs that are cancelled on TomTom WEBFLEET devices provide a different interface back into {{#var:System}} - this requires prototyping at functional specification stage and may result in increased cost. Reasons entered against a cancelled job are also required. It is expected, however, that the costs in this document will be sufficient to achieve the full interface.

TomTom WEBFLEET non-working time (unplanned breaks) is required to be supported by this project and therefore this interface - if the driver logs non-working time as part of the execution of an order, this will generate a break job in the database, with no planned times or distances. Additionally, this time will be taken away from any travel or working time on any jobs that have actual start, arrival or end times around that unplanned break.
{{SCR|Reference=332569|SCRNo=7
|Definition=Update non-working time as a new break
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

When all jobs on a load are updated to cancelled or completed through this interface, the load will be marked as complete.

An optional change has also been requested to indicate the position at which the driver clicks the Arrive button, so that Greene King can check the location.
{{SCR|Reference=332569|SCRNo=8
|Definition=Display location of TomTom Order Arrival.
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

In order to achieve this, this process will write User Audit records for each message processed from the TomTom files received, for the following information:
* Order Started
* Order Arrived
* Order Completed

This information would then be accessible through the existing {{#var:System}} User Audit Admin screen.

[[file:FS_336015_User_Tracking.PNG|border|600px]]
 ''Admin User Tracking Screen, showing prototyped TomTom messages'' 

== Scope ==
This document covers 3 changes from the solution design:
* 336015 SCR-332569-6 WEBFLEET-ePOD Job Update Interface
* 336016 SCR-332569-8 Display location of TomTom Order Arrival
* 336017 SCR-332569-7 Update non-working time as a new break
The estimates in [[#Appendix B: Quote & Document References|Appendix B]] are the combined values from these 3 changes.

{{Note}} This interface will be written to capture the events related to Orders and start/stop working time only - Geofence breaks will not be captured or created as part of this interface and will NOT debrief the loads and jobs in {{#var:System}}.

{{Note}} This interface identifies the Site for WEBFLEET updates by extracting it from the Order Number sent to WEBFLEET. This requires a fixed Job ID length of 10 characters, which is the default when sending orders to WEBFLEET. If the interface is used as described in the solution design, this interface will function automatically with no issues and no manual intervention. If any other mechanism is used to generate the orders in WEBFLEET, or the Job IDs are created at a different length, this update process will not work as described.

{{Note}} This interface identifies driver-generated Breaks through the external (WEBFLEET) vehicle ID in order to find the load that is in progress. Where the same vehicle is in use on multiple sites, this can compromise the interface for generation of breaks.

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. Under the full {{#var:System}} solution, driver-generated breaks on the device will not be processed through this TomTom WEBFLEET interface. The system will then restrict the messages read from WEBFLEET to Order-only messages, rather than all messages. Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

{{Note}} When jobs are consolidated and will be actioned together on the device ((i.e. the linked ID is set to be the same value on multiple jobs), the actual values for work, travel and distance will still be updated on the job. This must be taken into account when producing the Planned Vs Actuals report, so that the values are reported on only one of the consolidated jobs on the load.


= Set-up =
== Pre-requisites ==
The Sites must be pre-configured by the OBSL implementation team to point to the correct WEBFLEET fleet. This is a requirement of the Breaks solution. This is not configurable by the users. If this is not configured, driver-generated breaks from WEBFLEET will not be processed and added.

== Menu Structure ==
N/A.

== Data ==
For full functionality to be enabled, the {{#var:System}} system must be configured for PvA only, through the Site maintenance screen (on the ''Administration'' menu), ''Details'' tab, System Type setting.

[[file:FS_336015_Admin_Site.PNG|border|600px]]
 ''Admin Site Screen, showing prototyped System Type'' 

TomTom WEBFLEET-specific reason codes should be created for the Sites in advance:
* "TWCD" - description "TomTom WEBFLEET - Cancelled by Driver".
* "TWRD" - description "TomTom WEBFLEET - Rejected by Driver".
These reason codes should be created at Job and Detail level.

[[File:FS_336015_Admin_Codes.PNG|border|600px]]
 ''Codes Maintenance Screen'' 

Set up the sites for WEBFLEET inbound interface.

New EPOD_XF_CONFIG configurations will be required:
* EPL_XF_CONFIG_ID - A new configuration name to be applied to sites that do not have an Export Configuration yet, or the Export Configuration ID of the existing configuration.
* EPL_XF_ID - "TO" - TomTom Update
* EPL_SOAP_ACTION - ""
* EPL_SOAP_NS - "ser"
* EPL_SOAP_NS_PREFIX - <nowiki>"http://connect.webfleet.tomtomwork.com/services"</nowiki>
* EPL_WEB_USER - "admin"
* EPL_WEB_PASSWORD - "Matt3221"
* EPL_XF_RECIPIENT - Account - "logistics-obs"
* EPL_XF_DESTINATION - <nowiki>"https://soap.business.tomtom.com/v1.28/messagesService"</nowiki>
* EPL_XF_MSG_TYPE - API Key - "000fcb2a-6631-477a-b00e-de0505e7c7e3"
* EPL_XF_DIRECTION - "I"
* EPL_XF_TYPE - "SOAP"

[[File:FS_336015_Admin_AutoExport.PNG|border|600px]]
 ''Import/Export Config Screen'' 

This configuration must be added to all of the sites that requires TomTom interfaces for that WEBFLEET fleet. If a site already has a configuration attached to it, a configuration should be added to the same configuration name. {{Note}} This configuration of the interface will bring back all updates from the fleet, regardless of site. However, the interface configuration is required against all sites, so that the parameters may be used to identify to which site the vehicle belongs.

Vehicles must be set up for WEBFLEET, with an external reference matching the object ID in WEBFLEET:

[[File:FS_336015_Admin_Vehicles.PNG|border|600px]]
 ''Vehicles Maintenance Screen'' 

[[File:FS_336015_WEBFLEET_Vehicles.PNG|border|600px]]
 ''WEBFLEET Vehicles Screen'' 



= Functional Description =
== Database/DAL ==
New fields will be added to the EPOD_JOB table:
* EPL_WORK_ACTUAL - number - to hold the value of the Actual Work Time from WEBFLEET in whole numbers of minutes.
* EPL_ODO_START - float - to hold the Start Odometer reading from WEBFLEET.
* EPL_ODO_END - float - to hold the End Odometer reading from WEBFLEET.
All database packages and the DAL object will be changed to update and retrieve these new fields.
{{Note}} It is not necessary to add these fields as search-able items.

{{Note}} The following existing fields will be used to store Actual times and distances in addition to the new field above:
* EPL_DISTANCE_ACTUAL - Actual distance travelled. {{Note}} This must be changed to a float type (i.e. capable of storing decimal values).
* EPL_DRIVING_TIME - Actual driving time in whole numbers of minutes.

The existing EPOD_LOAD fields EPL_LOAD_DISTANCE_PLANNED and EPL_LOAD_DISTANCE_ACTUAL should be changed to be a float type (i.e. capable of storing decimal values).

{{Note}} As standard, these fields will be added to the standard XML Webservice Import and Export flows. These changes (and all others for the project) have been documented and referenced in [[#Appendix B: Quote & Document References|Appendix B]]. The standard XSD files describing the XML in detail will also be updated as part of this project. Note specifically that all fields changed to float type will need to have the type changed to "xsd:float".

A new field will be added to the EPOD_SITE table:
* EPL_EXT_FLEET - nvarchar(40) - to hold the value of the WEBFLEET fleet ID.
All database packages and the DAL object will be changed to update and retrieve this new field.
{{Note}} It is not necessary to add this field as search-able items.

{{Note}} Indexes are required for the following tables, to improve efficiency of finding applicable vehicles to create breaks:
* EPOD_VEHICLE - Index EPV_EXT_IDX as EPL_EXT_REF, EPL_SITE_ID, EPL_VEHICLE_ID.
* EPOD_SITE - Index EPS_EXT_IDX as EPL_EXT_FLEET, EPL_SITE_ID.
* EPOD_LOAD - Index EPL_VEHICLE_STATUS_IDX as EPL_SITE_ID, EPL_VEHICLE_ID, EPL_STATUS, EPL_LOAD_ID

== Auto Import Process ==
Retrieving messages from WEBFLEET is through the use of message queues, created and accessed through the TomTom WEBFLEET API, referenced in [[#Appendix B: Quote & Document References|Appendix B]].

A request to the created message queue will be made through the webservice method popQueueMessagesExtern.

Before using popQueueMessagesExtern to retrieve outstanding messages, a queue must be created using the createQueueExtern method, using the same message class
parameter that is being provided with calls to popQueueMessagesExtern. In this case, the message class is 2 (all messages except tracking messages).

{{Note}} The resulting data set is delivered in the language chosen in the WEBFLEET account and not on the language indicated in the lang parameter.

The structure of the popQueueMessagesExtern method is as follows:

<ser:popQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:popQueueMessagesExtern>

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. In this case, the message queue created and used for WEBFLEET messages will require to be filtered for all messages except tracking messages (filter attribute "ALL_EXCEPT_POSITION_MESSAGES"). This attribute is used on all WEBFLEET webservice calls to create, pop and acknowledge messages from that queue. This is only the case when the Site's System Type (EPL_SYSTEM_TYPE) is "PvA". This is only required when creating breaks through WEBFLEET. When the full {{#var:System}} system is in use, this will not be the case, and therefore the WEBFLEET messages can be more strictly filtered to only Order-based messages (filter attribute "ORDER_RELATED"). The mcgClass filter attribute on ''all'' WEBFLEET message queue methods in this document should be set to "ORDER_RELATED" if the Site's System Type (EPL_SYSTEM_TYPE) is anything except "PvA".

Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

The response to a popQueueMessagesExtern message is as follows:
<ns3:popQueueMessagesExternResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns3="http://connect.webfleet.tomtomwork.com/services">
<return>
<statusCode>9195</statusCode>
<statusMessage>...Details of the status...</statusMessage>
<errors>
<errorInfo objectName="QueueServiceParameter" fieldName="filter">
<msg>A value is required</msg>
</errorInfo>
</errors>
<resultSize>0</resultSize>
<results xsi:nil="true"/>
</return>
</ns3:popQueueMessagesExternResponse>

The above response object also shows the result should an error occur. TomTom Responses have been handled before when processing sending orders to WEBFLEET in the Auto Export process (in method EPOD_SYS_EXPORT.TomTomOrdersProcessData). A similar process should be implemented here:
* If the status code returned is 0, the message was successful.
* If the status code returned is 8011, request limits were reached - in this case treat this as a failure.
* If the status code returned is 9303, the message queue request failed - see the following section.
* Any other status code returned should be treated as a failure.

If the message queue request failed, it may not be set up yet. This is indicated by the errorInfo/msg tag starting with "WFCQ_E0022". If any other error message is received, write an XF Audit record, indicating "Unable to read from queue" plus the description from the msg tag.

If the queue has not been set up yet, the process should create it at this time. This is through a call to the createQueueExtern webservice method, populated as follows:

<ser:createQueueExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:createQueueExtern>

To call this, simply replace the outer tags of the previous request and resend the SOAP request.

The response object for this call is identical to the response to all other calls, except that the outer tag is createQueueExternResponse. Anything other than "0" (Success) in the status code means a failure to create the queue. In the case of failure, write an XF Audit record, indicating "Creation of queue failed" plus the description from the msg tag.

{{Note}} If the queue is created here, there is no need to continue with the process, as there will be no messages in the queue yet - the process can finish here.

The results tag will contain the results in sub-tags called resultItem. Example files exist for this data returned. The following are example result items for each item that the process will be dealing with:

'''Starting an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949248423"/>
<msgTime>2016-06-20T15:05:06.008Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order TW0000000001: started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349133</latitude>
<longitude>-2852108</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:05:04Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''In progress to an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949319260"/>
<msgTime>2016-06-20T15:06:19.388Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000761</msgType>
<msgText>Order TW0000000001: est. arrival 16:24, 11 mi to destination</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852109</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:06:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<eta>2016-06-20T15:24:56Z</eta>
<distance>17249</distance>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''On and Off a Break:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851082"/>
<msgTime>2016-06-20T15:15:48.686Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Pause started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<pndconn>0</pndconn>
<tripMode>1</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:05Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>PAUSE</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:05Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851641"/>
<msgTime>2016-06-20T15:15:49.258Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Work started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<tripMode>2</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:25Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>WORKING</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:25Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Cancellation:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950259474"/>
<msgTime>2016-06-20T15:23:18.805Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100734</msgType>
<msgText>Order TW0000000001: cancelled "unexpected cow"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852117</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:23:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>301</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>unexpected cow</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Rejection:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950499987"/>
<msgTime>2016-06-20T15:27:50.947Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100731</msgType>
<msgText>Order TW0000000002: rejected "rejected by duck"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349067</latitude>
<longitude>-2852166</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:27:48Z</posTime>
<speed>0</speed>
<course>282</course>
<direction>7</direction>
<status>A</status>
<orderNo orderNo="TW0000000002"/>
<orderState>302</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>rejected by duck</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Arrived at Delivery Location:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856914199"/>
<msgTime>2016-06-17T14:06:20.409Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: arrived at delivery location</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349010</latitude>
<longitude>-2851930</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:19Z</posTime>
<speed>2</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>242</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Order Finished:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856918353"/>
<msgTime>2016-06-17T14:06:24.714Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: finished</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349020</latitude>
<longitude>-2851940</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:23Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>401</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

All result items should be processed in sequence, by looping through them.

The tags in this resultItem that are required are as follows:
* msgClass - for filtering messages.
* msgType - for filtering messages.
* objectNo - the vehicle's external (TomTom WEBFLEET) reference.
* odometer - the Odometer reading in KM. This may not be present, depending on hardware and configuration.
* pos/latitude - the latitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* pos/longitude - the longitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* posTime - the date and time the message was created. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* orderNo@orderNo - the unique order number passed to WEBFLEET when the order was created. For {{#var:System}} this will the value from External System ID, usually the Site ID and Job ID combined. This differs for consolidated jobs and should be confirmed as to the actual value.
* orderState - for filtering messages.
* eta - the estimated time of arrival at the location for the order. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* pndWorkingStateMessageData/workstate - determines break status.
* userText - the text entered when cancelling or rejecting an order on the device.

{{Note}}
* A slash (/) in the tag name (e.g. pndWorkingStateMessageData/workstate) indicates that this is a sub-tag of another tag.
* An At symbol (@) in the tag name (orderNo@orderNo) indicates that this is an attribute of the named tag.
* Tags (and sub-tags) may not exist for each message, so each tag must be extracted and checked individually, or the errors handled when extracting values from tags.
* Longitudes and Latitudes are stored in micro-degrees and must be divided by 1,000,000 for storing in {{#var:System}}.
* Times are in xsd:dateTime format and must be converted. Furthermore, they are in UTC, and must be converted to the local server timezone when storing.

'''General Processing'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag values "DATA" and "ORDER" only.
* Convert the date/time from the posTime tag in the result.
* Convert the ETA date/time from the eta tag in the result, if present.
* Convert and validate the ODO reading from the odometer tag in the result, if present.
* Convert and validate the GPS location from the pos tag, sub-tags latitude and longitude in the result.

'''Processing of result records with an order state value:'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag value "ORDER" and for the following orderState tag values:
** 221 - Pickup order started
** 222 - Arrived at Pickup location
** 241 - Delivery order started
** 242 - Arrived at Delivery location
** 301 - Cancelled
** 302 - Rejected
** 401 - Finished
* Get the Job or Jobs (EPOD_JOB) using the extracted Site (EPL_SITE_ID) and External System Reference (EPL_EXTERNAL_SYSTEM_ID) from the orderNo tag attribute value. {{Note}} There can be multiple jobs for the External System Reference.
* Stop processing this result record if this job is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Load (EPOD_LOAD) from the Job's Load ID (EPL_LOAD_ID). Store the Load ID in a list of loads processed from this response.
* Stop processing this result record if this load is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Vehicle (EPOD_VEHICLE) from the Load's Vehicle ID (EPL_VEHICLE_ID).
* Set the Vehicle's last position, date and time as follows:
** Set the Last Position (EPL_LAST_POSITION) from the converted values of the result tags latitude and longitude values, concatenated with a comma.
** Set the Last Position Date and time (EPL_LAST_POSITION_DATE and EPL_LAST_POSITION_TIME) from the extracted date and time from the tag posTime value, translated into OBS format.

* For order states 221 and 241 (order started):
** Set the Actual Start date and time if not already populated (EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "I" - In Progress if not already in progress.
** If the job was not already in progress, find any other in-progress jobs against the load and set to status pending (EPL_STATUS set to "P"). If they already have a value in start odometer (EPL_ODO_START), set the distance travelled (EPL_DISTANCE_ACTUAL) to tag odometer value minus the value in the jobs' start odometer and zero the jobs' start odometer value.
** Set the ETA date and time against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME) from the tag eta value, if present, translated into OBS format.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the Start Odometer reading on the Job or Jobs (EPL_ODO_START) to the tag odometer value, if not already populated.
** If present in the incoming result, set the ODO start against the Load (EPL_MILEAGE_START) from the tag odometer value, if not already populated.
** Write a User Tracking record for each of the jobs - see below for details.

* For order states 222 and 242 (arrived at location):
** Update Arrival date and time against the job or jobs if not already populated (EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME) from the tag posTime value, translated into OBS format.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Write a User Tracking record for each of the jobs - see below for details.

* For order state 401 (Finished):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "C" - Complete if not already complete.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the End Odometer reading on the Job to the tag odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If the status of the job (EPL_STATUS) is not "I" (In Progress), set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", complete all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "C" - Complete.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled) or order status 302 (Rejected):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set Job or Jobs status (EPL_STATUS) to "X" - Cancelled.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set the Reason Code against the Job or Jobs (EPL_REASON_CODE) to "TWCD" (for order status 301) or "TWRD" (for order status 302).
** Set the User Notes (EPL_USER_NOTES) against the Job or Jobs to be the tag userText value.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the incoming odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", cancel all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "X" - Cancelled.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled), 302 (Rejected) and 401 (Complete):
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.

* Ignore any other messages than the ones above, if the System Type (EPL_SYSTEM_TYPE) is ''not'' "PvA" - breaks will not be processed through this TomTom WEBFLEET interface when the full {{#var:System}} system is being run.

'''Processing of result records without an order state value:'''
These messages are used predominantly to generate breaks indicated by the driver.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for tag msgClass value "DATA" and the following message types (extracted from the last 3 digits of the value in the msgType tag):
** 711 - Log-off driver (including tachograph driver card removed) - treat as end of break.
** 712 - Begin of work, driver indicated - treat as end of break.
** 713 - End of work, driver indicated - treat as end of break.
** 714 - Begin of break, driver indicated - treat as start of break.
** 715 - End of break, driver indicated - treat as end of break.
** 716 - Work status change, indicating driver role, old and new work status (applies to all PRO 71xx, 91xx devices when used with identified driver and Remote LINK Working Time). If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.
** 717 - Work started (driver role and driver name indicated) - treat as end of break.
** 718 - Work ended (driver role and driver name indicated) - treat as end of break.
** 719 - Work time event, indicating driver. If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.

* If treating the message as Start of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a break (either generated by the system or generated by DiPS) that is status In Progress (EPL_STATUS is "I"). If there is one, ignore this message, as a break is already started.
** Find the first job on that load that is not complete i.e. the status (EPL_STATUS) is "P" - Pending - or "I" - In Progress, ordering by the status In Progress (i.e. those jobs should be the first jobs found).

** Create a new break job as follows:
*** EPL_SITE_ID - From the found Load's Site ID
*** EPL_LOAD_ID - From the found Load ID
*** EPL_JOB_ID - Generated
*** EPL_JOB_CODE - "BRK_<EPL_LOAD_ID>_<EPL_SEQUENCE_NO>". The tagged values should be substituted with the found Load ID, and the DIPS column value LINK SEQ NO respectively.
*** EPL_JOB_TYPE - "D"
*** EPL_JOB_GROUP - "OTHER"
*** EPL_JOB_INSTRUCTION - "Driver Break"
*** EPL_START_PLANNED_DATE - from the tag posTime value.
*** EPL_START_PLANNED_TIME - from the tag posTime value.
*** EPL_START_ACTUAL_DATE - from the tag posTime value.
*** EPL_START_ACTUAL_TIME - from the tag posTime value.
*** EPL_ARRIVAL_DATE - from the tag posTime value.
*** EPL_ARRIVAL_TIME - from the tag posTime value.
*** EPL_END_PLANNED_DATE - from the tag posTime value.
*** EPL_END_PLANNED_TIME - from the tag posTime value.
*** EPL_DISTANCE_PLANNED - 0
*** EPL_CUSTOMER_CODE - "BREAK"
*** EPL_CUSTOMER_NAME - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_ADDRESS_1 - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_POSTCODE - The postcode from the found job.
*** EPL_SEQUENCE - The sequence from the found job
*** EPL_LOADING_TYPE - Blank
*** EPL_TRAVEL_PLANNED - 0
*** EPL_WORK_PLANNED - 0
*** EPL_LAT - from the tag pos, sub-tag latitude value, converted to degrees.
*** EPL_LONG - from tag pos, sub-tag longitude value, converted to degrees.
*** EPL_LAST_CHANGED_DATE - Now
*** EPL_LAST_CHANGED_TIME - Now
*** EPL_ODO_START - from the tag odometer value, if present.
*** EPL_GENERATED - "Y" - Generated by the driver.
*** EPL_STATUS - "I" - In Progress
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - Start of Break" - see below for details.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

* If treating the message as End of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a driver-generated break that is status In Progress (EPL_STATUS is "I"). If there is not one one, ignore this message.
** If there is one, update it as follows:
*** Set the Actual End date and time (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
*** Set the break job's ODO End (EPL_ODO_END) from the tag odometer value if present.
*** Set the break job's status to Complete (EPL_STATUS = "C".
*** Set the Last Changed date and time (EPL_LAST_CHANGED_DATE and EPL_LAST_CHANGED_TIME) to the current server time, in OBS format.
*** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
*** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
*** Set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value on the job (EPL_ODO_START), plus any value already in this distance travelled job field.
** If the break job found is a driver-generated break job, find any non-break jobs in progress (EPL_STATUS = "I") on the load. If found, set the distance (EPL_DISTANCE_ACTUAL) and travel time (EPL_DRIVING_TIME) on all the jobs to be the current values minus the values on the break job just updated, plus any value already in these fields. This will then remove the distance and travel that was added to the Break job from the job in progress, for the Planned vs Actual reporting later.
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - End of Break" - see below for details.
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

{{Note}} Any messages in the result that do not match the filtered messages above can be ignored - no audit is required.

{{Note}} When writing order tracking records to EPOD_USER_AUDIT, all of the normal details should be entered. This should be sourced from the Job record being updated unless specified otherwise:
* Site ID
* User ID - From the Load
* Vehicle ID - From the Load
* Load ID - From the Load
* Job ID
* Message Type - dependent on the tag orderState of the result being processed:
** 221 or 241 - "WEBFLEET - Order Started"
** 222 or 242- "WEBFLEET - Order Arrived"
** 301 - "WEBFLEET - Order Cancelled"
** 302 - "WEBFLEET - Order Rejected"
** 401 - "WEBFLEET - Order Complete"
** If this is Blank and the process is treating this as a Start of Break - "WEBFLEET - Start of Break"
** If this is Blank and the process is treating this as an End of Break - "WEBFLEET - End of Break"
* GPS Coordinates - from the converted values of the input tag pos, sub-tags latitude and longitude values, concatenated with a comma.
* Audit Date - The server date as of the time the record is processed.
* Audit Time - The server time as of the time the record is processed.
* Job Type
* Device Date - extracted date from the tag posTime value, translated into OBS format.
* Device Time - extracted time from the tag posTime value, translated into OBS format.

{{Note}} Once messages taken from the queue in this message response are successfully processed, the process must use the webservice method ackQueueMessagesExtern to acknowledge completion of the message transfer to the application. Otherwise, the messages will be kept and returned again during the next call to popQueueMessagesExtern.

{{Note}} In order to prevent this system from being flooded with over-sized responses, the number of messages that will be returned on a single response is limited to 500. This limit can be adjusted per account on request.

The structure of the ackQueueMessagesExtern method is identical to the above Pop message, except for the name, as follows:
<ser:ackQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:ackQueueMessagesExtern>

Again, the response to this message will be the same as the other WEBFLEET messages, except that the outer tag is ackQueueMessagesExternResponse. Regardless of status, the

Should the value of the tag resultSize be 500, this whole process of retrieving, processing and acknowledging messages should be repeated. This should continue until the result size is less than 500 (i.e. there are no more messages on the queue).

Should there be a problem processing the messages from the queue, an audit record of the row detail and the error code should be created in EPOD_XF_AUDIT_HEADER. Failing a single message does not result in the message failing - these should always be acknowledged. Failures encountered server-side (failures within {{#var:System}} should result in not acknowledging the message, so that they may be reprocessed later by re-reading them from the queue.

When writing Audit records for failures and successes, the records should be populated as follows. If not specified, the values should be derived from the job:
* Site.
* Job Group, if this is an audit related to a job.
* Header ID - Generated.
* Request Data - If Failure, the resultItem tag and contents.
* Request Date - The server date as of the time the record is processed.
* Request Time - The server time as of the time the record is processed.
* Status - "S" for Success, "F" for Fail, as indicated above when writing the audit record.
* Status Description - If Success, "Jobs Updated", else the reason for the failure (e.g. "Load already completed", "Job already cancelled", etc) as indicated above.
* Key Value 1 - The Job Code, if this is an audit related to a job.
* Key Value 2 - The Job ID, if this is an audit related to a job.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing all aspects of the WEBFLEET - {{#var:System}} Update Interface.
|MenuAccess=N/A
|Prerequisites=Create 2 loads with jobs configured as per the example Load in the supplied CSV extraction from DiPS.
|Objective=To test that: jobs are updated with all actual information; Loads are updated correctly; jobs done out of sequence are updated taking into account any intermediate distance and time; driver-generated breaks are created correctly; jobs completed with breaks whilst in progress are updated taking into account any intermediate distance and time.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 1 - Normal Processing.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept and Start Loading job.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Arrive Loading Job.
|Result=Job updated in C-ePOD - Arrival Date/Time and End ODO updated, Travel Time and Distance updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD - Job Complete, Actual End Date/Time updated, Work Time updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept, Start and Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Reject Delivery Job 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Delivery Job 3.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Delivery 1.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Consolidated Delivery 2.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 2 before the next job (out of sequence).
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 4.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated. Next Load automatically set to In Progress (not part of this test).
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 2 - Out of sequence.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start and Drive to Delivery Job 1. Do not Arrive at Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job In Progress, Actual Start Date/Time, Job Start ODO updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start, Arrive and Complete Delivery Job 2 before completing Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance Travel times take into account the distance and time travelled on the job 2 in between.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 3 - Driver-generated Breaks.
|Notes=Continuing from Cycle 2.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause Work.
|Result=Creates new break job as specified.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Work.
|Result=Updates new break job - Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised break job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Consolidated jobs 1.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause and Start Work.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the Break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Continue Consolidated jobs. Pause and Start Work again.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the next Break added to the previous break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Jobs 1.
|Result=Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs. Distance, Work and Travel times take into account the distance, work and time travelled on the 2 break jobs in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete consolidated jobs 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the next job. Pause and Start work, complete job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance, Work and Travel times take into account the distance, work and time travelled on the break job in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised Break.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|Ref2=EPOD Import Mapping
|RefV2=5.1.2
|RefDate2=17/06/2016
|Ref3=EPOD Export Mapping
|RefV3=5.1.2
|RefDate3=17/06/2016
|Ref4=WEBFLEET.connect Reference
|RefV4=1.28.0
|RefDate4=31/03/2016
|Ref4=obs-eas-DIPS2AXS for PvA.xls
|RefV4=N/A
|RefDate4=24/06/2016
|REQ=0
|EST=0
|FS=1.75
|TS=1.75
|DEV=7.25
|ST=1.50
|IMP=0
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336015 SCR-332569-6 GK PvA WEBFLEET-ePOD Interface

2016-08-23T12:10:52Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|WEBFLEET-ePOD Job Update Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336015 SCR-332569-6}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
As each job is actioned by the drivers, information on those actions is stored within TomTom WEBFLEET. This information will be pulled back into {{#var:System}} and will update the jobs. A new process will be required to complete this. This will be a timed process, running at regular intervals.

== Solution Overview ==
{{SCR|Reference=332569|SCRNo=6
|Definition=WEBFLEET-ePOD Job Update Interface.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will create a queue to poll for:
* Order Completion messages
* Order Cancellation messages
* Order Started messages
* Order Arrived messages
All these messages should include Odometer and Lat/Long co-ordinates.

Each message will be processed and then acknowledged from the queue. The success or failure of processing of the message files received from TomTom will be audited.

It is intended that processing these messages will provide the following information:
* Job Status (Completed/Cancelled)
* Reason for cancellation if required
* Start/Arrival/End Times
* Start/Arrival/End Odometer readings
This information will then be used to update the jobs on {{#var:System}}.

{{Note}} Jobs that are cancelled on TomTom WEBFLEET devices provide a different interface back into {{#var:System}} - this requires prototyping at functional specification stage and may result in increased cost. Reasons entered against a cancelled job are also required. It is expected, however, that the costs in this document will be sufficient to achieve the full interface.

TomTom WEBFLEET non-working time (unplanned breaks) is required to be supported by this project and therefore this interface - if the driver logs non-working time as part of the execution of an order, this will generate a break job in the database, with no planned times or distances. Additionally, this time will be taken away from any travel or working time on any jobs that have actual start, arrival or end times around that unplanned break.
{{SCR|Reference=332569|SCRNo=7
|Definition=Update non-working time as a new break
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

When all jobs on a load are updated to cancelled or completed through this interface, the load will be marked as complete.

An optional change has also been requested to indicate the position at which the driver clicks the Arrive button, so that Greene King can check the location.
{{SCR|Reference=332569|SCRNo=8
|Definition=Display location of TomTom Order Arrival.
|Link=REQ_314432_Greene_King_ePOD_Requirements#Appendix A: Table of SCRs and Ballpark Estimates
}}

In order to achieve this, this process will write User Audit records for each message processed from the TomTom files received, for the following information:
* Order Started
* Order Arrived
* Order Completed

This information would then be accessible through the existing {{#var:System}} User Audit Admin screen.

[[file:FS_336015_User_Tracking.PNG|border|600px]]
 ''Admin User Tracking Screen, showing prototyped TomTom messages'' 

== Scope ==
This document covers 3 changes from the solution design:
* 336015 SCR-332569-6 WEBFLEET-ePOD Job Update Interface
* 336016 SCR-332569-8 Display location of TomTom Order Arrival
* 336017 SCR-332569-7 Update non-working time as a new break
The estimates in [[#Appendix B: Quote & Document References|Appendix B]] are the combined values from these 3 changes.

{{Note}} This interface will be written to capture the events related to Orders and start/stop working time only - Geofence breaks will not be captured or created as part of this interface and will NOT debrief the loads and jobs in {{#var:System}}.

{{Note}} This interface identifies the Site for WEBFLEET updates by extracting it from the Order Number sent to WEBFLEET. This requires a fixed Job ID length of 10 characters, which is the default when sending orders to WEBFLEET. If the interface is used as described in the solution design, this interface will function automatically with no issues and no manual intervention. If any other mechanism is used to generate the orders in WEBFLEET, or the Job IDs are created at a different length, this update process will not work as described.

{{Note}} This interface identifies driver-generated Breaks through the external (WEBFLEET) vehicle ID in order to find the load that is in progress. Where the same vehicle is in use on multiple sites, this can compromise the interface for generation of breaks.

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. Under the full {{#var:System}} solution, driver-generated breaks on the device will not be processed through this TomTom WEBFLEET interface. The system will then restrict the messages read from WEBFLEET to Order-only messages, rather than all messages. Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

{{Note}} When jobs are consolidated and will be actioned together on the device ((i.e. the linked ID is set to be the same value on multiple jobs), the actual values for work, travel and distance will still be updated on the job. This must be taken into account when producing the Planned Vs Actuals report, so that the values are reported on only one of the consolidated jobs on the load.


= Set-up =
== Pre-requisites ==
The Sites must be pre-configured by the OBSL implementation team to point to the correct WEBFLEET fleet. This is a requirement of the Breaks solution. This is not configurable by the users. If this is not configured, driver-generated breaks from WEBFLEET will not be processed and added.

== Menu Structure ==
N/A.

== Data ==
For full functionality to be enabled, the {{#var:System}} system must be configured for PvA only, through the Site maintenance screen (on the ''Administration'' menu), ''Details'' tab, System Type setting.

[[file:FS_336015_Admin_Site.PNG|border|600px]]
 ''Admin Site Screen, showing prototyped System Type'' 

TomTom WEBFLEET-specific reason codes should be created for the Sites in advance:
* "TWCD" - description "TomTom WEBFLEET - Cancelled by Driver".
* "TWRD" - description "TomTom WEBFLEET - Rejected by Driver".
These reason codes should be created at Job and Detail level.

[[File:FS_336015_Admin_Codes.PNG|border|600px]]
 ''Codes Maintenance Screen'' 

Set up the sites for WEBFLEET inbound interface.

New EPOD_XF_CONFIG configurations will be required:
* EPL_XF_CONFIG_ID - A new configuration name to be applied to sites that do not have an Export Configuration yet, or the Export Configuration ID of the existing configuration.
* EPL_XF_ID - "TO" - TomTom Update
* EPL_SOAP_ACTION - ""
* EPL_SOAP_NS - "ser"
* EPL_SOAP_NS_PREFIX - <nowiki>"http://connect.webfleet.tomtomwork.com/services"</nowiki>
* EPL_WEB_USER - "admin"
* EPL_WEB_PASSWORD - "Matt3221"
* EPL_XF_RECIPIENT - Account - "logistics-obs"
* EPL_XF_DESTINATION - <nowiki>"https://soap.business.tomtom.com/v1.28/messagesService"</nowiki>
* EPL_XF_MSG_TYPE - API Key - "000fcb2a-6631-477a-b00e-de0505e7c7e3"
* EPL_XF_DIRECTION - "I"
* EPL_XF_TYPE - "SOAP"

[[File:FS_336015_Admin_AutoExport.PNG|border|600px]]
 ''Import/Export Config Screen'' 

This configuration must be added to all of the sites that requires TomTom interfaces for that WEBFLEET fleet. If a site already has a configuration attached to it, a configuration should be added to the same configuration name. {{Note}} This configuration of the interface will bring back all updates from the fleet, regardless of site. However, the interface configuration is required against all sites, so that the parameters may be used to identify to which site the vehicle belongs.

Vehicles must be set up for WEBFLEET, with an external reference matching the object ID in WEBFLEET:

[[File:FS_336015_Admin_Vehicles.PNG|border|600px]]
 ''Vehicles Maintenance Screen'' 

[[File:FS_336015_WEBFLEET_Vehicles.PNG|border|600px]]
 ''WEBFLEET Vehicles Screen'' 



= Functional Description =
== Database/DAL ==
New fields will be added to the EPOD_JOB table:
* EPL_WORK_ACTUAL - number - to hold the value of the Actual Work Time from WEBFLEET in whole numbers of minutes.
* EPL_ODO_START - float - to hold the Start Odometer reading from WEBFLEET.
* EPL_ODO_END - float - to hold the End Odometer reading from WEBFLEET.
All database packages and the DAL object will be changed to update and retrieve these new fields.
{{Note}} It is not necessary to add these fields as search-able items.

{{Note}} The following existing fields will be used to store Actual times and distances in addition to the new field above:
* EPL_DISTANCE_ACTUAL - Actual distance travelled. {{Note}} This must be changed to a float type (i.e. capable of storing decimal values).
* EPL_DRIVING_TIME - Actual driving time in whole numbers of minutes.

The existing EPOD_LOAD fields EPL_LOAD_DISTANCE_PLANNED and EPL_LOAD_DISTANCE_ACTUAL should be changed to be a float type (i.e. capable of storing decimal values).

{{Note}} As standard, these fields will be added to the standard XML Webservice Import and Export flows. These changes (and all others for the project) have been documented and referenced in [[#Appendix B: Quote & Document References|Appendix B]]. The standard XSD files describing the XML in detail will also be updated as part of this project. Note specifically that all fields changed to float type will need to have the type changed to "xsd:float".

A new field will be added to the EPOD_SITE table:
* EPL_EXT_FLEET - nvarchar(40) - to hold the value of the WEBFLEET fleet ID.
All database packages and the DAL object will be changed to update and retrieve this new field.
{{Note}} It is not necessary to add this field as search-able items.

{{Note}} Indexes are required for the following tables, to improve efficiency of finding applicable vehicles to create breaks:
* EPOD_VEHICLE - Index EPV_EXT_IDX as EPL_EXT_REF, EPL_SITE_ID, EPL_VEHICLE_ID.
* EPOD_SITE - Index EPS_EXT_IDX as EPL_EXT_FLEET, EPL_SITE_ID.
* EPOD_LOAD - Index EPL_VEHICLE_STATUS_IDX as EPL_SITE_ID, EPL_VEHICLE_ID, EPL_STATUS, EPL_LOAD_ID

== Auto Import Process ==
Retrieving messages from WEBFLEET is through the use of message queues, created and accessed through the TomTom WEBFLEET API, referenced in [[#Appendix B: Quote & Document References|Appendix B]].

A request to the created message queue will be made through the webservice method popQueueMessagesExtern.

Before using popQueueMessagesExtern to retrieve outstanding messages, a queue must be created using the createQueueExtern method, using the same message class
parameter that is being provided with calls to popQueueMessagesExtern. In this case, the message class is 2 (all messages except tracking messages).

{{Note}} The resulting data set is delivered in the language chosen in the WEBFLEET account and not on the language indicated in the lang parameter.

The structure of the popQueueMessagesExtern method is as follows:

<ser:popQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:popQueueMessagesExtern>

{{Note}} This document assumes that that the process will be used under conditions where only WEBFLEET is in use, '''not''' the full {{#var:System}} solution. In this case, the message queue created and used for WEBFLEET messages will require to be filtered for all messages except tracking messages (filter attribute "ALL_EXCEPT_POSITION_MESSAGES"). This attribute is used on all WEBFLEET webservice calls to create, pop and acknowledge messages from that queue. This is only the case when the Site's System Type (EPL_SYSTEM_TYPE) is "PvA". This is only required when creating breaks through WEBFLEET. When the full {{#var:System}} system is in use, this will not be the case, and therefore the WEBFLEET messages can be more strictly filtered to only Order-based messages (filter attribute "ORDER_RELATED"). The mcgClass filter attribute on ''all'' WEBFLEET message queue methods in this document should be set to "ORDER_RELATED" if the Site's System Type (EPL_SYSTEM_TYPE) is anything except "PvA".

Care must be taken if implementing the full {{#var:System}} solution, that the old message queue is deleted after all messages are processed, and that the new message queue for orders is implemented ''before'' work starts under the new system.

The response to a popQueueMessagesExtern message is as follows:
<ns3:popQueueMessagesExternResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns3="http://connect.webfleet.tomtomwork.com/services">
<return>
<statusCode>9195</statusCode>
<statusMessage>...Details of the status...</statusMessage>
<errors>
<errorInfo objectName="QueueServiceParameter" fieldName="filter">
<msg>A value is required</msg>
</errorInfo>
</errors>
<resultSize>0</resultSize>
<results xsi:nil="true"/>
</return>
</ns3:popQueueMessagesExternResponse>

The above response object also shows the result should an error occur. TomTom Responses have been handled before when processing sending orders to WEBFLEET in the Auto Export process (in method EPOD_SYS_EXPORT.TomTomOrdersProcessData). A similar process should be implemented here:
* If the status code returned is 0, the message was successful.
* If the status code returned is 8011, request limits were reached - in this case treat this as a failure.
* If the status code returned is 9303, the message queue request failed - see the following section.
* Any other status code returned should be treated as a failure.

If the message queue request failed, it may not be set up yet. This is indicated by the errorInfo/msg tag starting with "WFCQ_E0022". If any other error message is received, write an XF Audit record, indicating "Unable to read from queue" plus the description from the msg tag.

If the queue has not been set up yet, the process should create it at this time. This is through a call to the createQueueExtern webservice method, populated as follows:

<ser:createQueueExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:createQueueExtern>

To call this, simply replace the outer tags of the previous request and resend the SOAP request.

The response object for this call is identical to the response to all other calls, except that the outer tag is createQueueExternResponse. Anything other than "0" (Success) in the status code means a failure to create the queue. In the case of failure, write an XF Audit record, indicating "Creation of queue failed" plus the description from the msg tag.

{{Note}} If the queue is created here, there is no need to continue with the process, as there will be no messages in the queue yet - the process can finish here.

The results tag will contain the results in sub-tags called resultItem. Example files exist for this data returned. The following are example result items for each item that the process will be dealing with:

'''Starting an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949248423"/>
<msgTime>2016-06-20T15:05:06.008Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order TW0000000001: started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349133</latitude>
<longitude>-2852108</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:05:04Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''In progress to an Order:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949319260"/>
<msgTime>2016-06-20T15:06:19.388Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000761</msgType>
<msgText>Order TW0000000001: est. arrival 16:24, 11 mi to destination</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852109</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:06:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>241</orderState>
<orderType>3</orderType>
<eta>2016-06-20T15:24:56Z</eta>
<distance>17249</distance>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''On and Off a Break:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851082"/>
<msgTime>2016-06-20T15:15:48.686Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Pause started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<pndconn>0</pndconn>
<tripMode>1</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:05Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>PAUSE</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:05Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54949851641"/>
<msgTime>2016-06-20T15:15:49.258Z</msgTime>
<msgClass>DATA</msgClass>
<msgType>80000719</msgType>
<msgText>John Doe: Work started</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<driverNo driverNo="44" driverUid="1-44036-4637202118"/>
<odometer>874543</odometer>
<tripMode>2</tripMode>
<pos>
<latitude>53349131</latitude>
<longitude>-2852114</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:14:25Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<pndWorkingStateMessageData>
<workstate>WORKING</workstate>
<sourceDevice>PND</sourceDevice>
<eventTime>2016-06-20T15:14:25Z</eventTime>
</pndWorkingStateMessageData>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Cancellation:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950259474"/>
<msgTime>2016-06-20T15:23:18.805Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100734</msgType>
<msgText>Order TW0000000001: cancelled "unexpected cow"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349131</latitude>
<longitude>-2852117</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:23:16Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="TW0000000001"/>
<orderState>301</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>unexpected cow</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Rejection:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54950499987"/>
<msgTime>2016-06-20T15:27:50.947Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>111100731</msgType>
<msgText>Order TW0000000002: rejected "rejected by duck"</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349067</latitude>
<longitude>-2852166</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-20T15:27:48Z</posTime>
<speed>0</speed>
<course>282</course>
<direction>7</direction>
<status>A</status>
<orderNo orderNo="TW0000000002"/>
<orderState>302</orderState>
<orderType>3</orderType>
<orderAddrNo>10151</orderAddrNo>
<userText>rejected by duck</userText>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Arrived at Delivery Location:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856914199"/>
<msgTime>2016-06-17T14:06:20.409Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: arrived at delivery location</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349010</latitude>
<longitude>-2851930</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:19Z</posTime>
<speed>2</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>242</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

'''Order Finished:'''
<resultItem xsi:type="ns4:QueueServiceData"
xmlns:ns4="http://connect.webfleet.tomtomwork.com/transfer/messages">
<msgid messageId="54856918353"/>
<msgTime>2016-06-17T14:06:24.714Z</msgTime>
<msgClass>ORDER</msgClass>
<msgType>110000760</msgType>
<msgText>Order 405511: finished</msgText>
<objectNo objectNo="#T009" objectUid="1-44036-9593E0A06"/>
<odometer>874543</odometer>
<pos>
<latitude>53349020</latitude>
<longitude>-2851940</longitude>
<mapcode xsi:nil="true"/>
</pos>
<posText>Liverpool</posText>
<posParams>town1_name=Liverpool;location_type=67;</posParams>
<posTime>2016-06-17T14:06:23Z</posTime>
<speed>0</speed>
<course>0</course>
<direction>1</direction>
<status>A</status>
<orderNo orderNo="405511"/>
<orderState>401</orderState>
<orderType>3</orderType>
<dtMessageData xsi:nil="true"/>
<rllMessageData xsi:nil="true"/>
<driverKeyDeviceMessageData xsi:nil="true"/>
</resultItem>

All result items should be processed in sequence, by looping through them.

The tags in this resultItem that are required are as follows:
* msgClass - for filtering messages.
* msgType - for filtering messages.
* objectNo - the vehicle's external (TomTom WEBFLEET) reference.
* odometer - the Odometer reading in KM. This may not be present, depending on hardware and configuration.
* pos/latitude - the latitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* pos/longitude - the longitude taken at the point of the message being generated, in micro degrees. This may not be present if there is not an adequate GPS signal at the time the message was created.
* posTime - the date and time the message was created. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* orderNo@orderNo - the unique order number passed to WEBFLEET when the order was created. For {{#var:System}} this will the value from External System ID, usually the Site ID and Job ID combined. This differs for consolidated jobs and should be confirmed as to the actual value.
* orderState - for filtering messages.
* eta - the estimated time of arrival at the location for the order. ISO 8601-formatted date and time in the UTC timezone, combined representation in the extended format. Example: 2007-12-24T16:00:00Z.
* pndWorkingStateMessageData/workstate - determines break status.
* userText - the text entered when cancelling or rejecting an order on the device.

{{Note}}
* A slash (/) in the tag name (e.g. pndWorkingStateMessageData/workstate) indicates that this is a sub-tag of another tag.
* An At symbol (@) in the tag name (orderNo@orderNo) indicates that this is an attribute of the named tag.
* Tags (and sub-tags) may not exist for each message, so each tag must be extracted and checked individually, or the errors handled when extracting values from tags.
* Longitudes and Latitudes are stored in micro-degrees and must be divided by 1,000,000 for storing in {{#var:System}}.
* Times are in xsd:dateTime format and must be converted. Furthermore, they are in UTC, and must be converted to the local server timezone when storing.

'''General Processing'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag values "DATA" and "ORDER" only.
* Convert the date/time from the posTime tag in the result.
* Convert the ETA date/time from the eta tag in the result, if present.
* Convert and validate the ODO reading from the odometer tag in the result, if present.
* Convert and validate the GPS location from the pos tag, sub-tags latitude and longitude in the result.

'''Processing of result records with an order state value:'''
* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for the result msgClass tag value "ORDER" and for the following orderState tag values:
** 221 - Pickup order started
** 222 - Arrived at Pickup location
** 241 - Delivery order started
** 242 - Arrived at Delivery location
** 301 - Cancelled
** 302 - Rejected
** 401 - Finished
* Get the Job or Jobs (EPOD_JOB) using the extracted Site (EPL_SITE_ID) and External System Reference (EPL_EXTERNAL_SYSTEM_ID) from the orderNo tag attribute value. {{Note}} There can be multiple jobs for the External System Reference.
* Stop processing this result record if this job is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Load (EPOD_LOAD) from the Job's Load ID (EPL_LOAD_ID). Store the Load ID in a list of loads processed from this response.
* Stop processing this result record if this load is completed or cancelled (EPL_STATUS = "C" or "X"). Write an Audit record for the job, status "F" - see later for details.
* Get the Vehicle (EPOD_VEHICLE) from the Load's Vehicle ID (EPL_VEHICLE_ID).
* Set the Vehicle's last position, date and time as follows:
** Set the Last Position (EPL_LAST_POSITION) from the converted values of the result tags latitude and longitude values, concatenated with a comma.
** Set the Last Position Date and time (EPL_LAST_POSITION_DATE and EPL_LAST_POSITION_TIME) from the extracted date and time from the tag posTime value, translated into OBS format.

* For order states 221 and 241 (order started):
** Set the Actual Start date and time if not already populated (EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "I" - In Progress if not already in progress.
** If the job was not already in progress, find any other in-progress jobs against the load and set to status pending (EPL_STATUS set to "P"). If they already have a value in start odometer (EPL_ODO_START), set the distance travelled (EPL_DISTANCE_ACTUAL) to tag odometer value minus the value in the jobs' start odometer and zero the jobs' start odometer value.
** Set the ETA date and time against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME) from the tag eta value, if present, translated into OBS format.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the Start Odometer reading on the Job or Jobs (EPL_ODO_START) to the tag odometer value, if not already populated.
** If present in the incoming result, set the ODO start against the Load (EPL_MILEAGE_START) from the tag odometer value, if not already populated.
** Write a User Tracking record for each of the jobs - see below for details.

* For order states 222 and 242 (arrived at location):
** Update Arrival date and time against the job or jobs if not already populated (EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME) from the tag posTime value, translated into OBS format.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Write a User Tracking record for each of the jobs - see below for details.

* For order state 401 (Finished):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", set the Job or Jobs status (EPL_STATUS) to "C" - Complete if not already complete.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the tag odometer value.
** If present in the incoming result, set the End Odometer reading on the Job to the tag odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** If the status of the job (EPL_STATUS) is not "I" (In Progress), set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", complete all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "C" - Complete.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled) or order status 302 (Rejected):
** Set the Actual End date and time if not already populated (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set Job or Jobs status (EPL_STATUS) to "X" - Cancelled.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", Set the Reason Code against the Job or Jobs (EPL_REASON_CODE) to "TWCD" (for order status 301) or "TWRD" (for order status 302).
** Set the User Notes (EPL_USER_NOTES) against the Job or Jobs to be the tag userText value.
** Remove the ETA date and time if present against the Job or Jobs (EPL_ETA_DATE and EPL_ETA_TIME).
** If present in the incoming result, set the Odometer reading on the Vehicle (EPL_VEHICLE_MILEAGE) to the incoming odometer value.
** If not yet populated, set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value (EPL_ODO_START), plus any value already in the distance travelled.
** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
** If the System Type (EPL_SYSTEM_TYPE) is "PvA", cancel all child records for the job or jobs (i.e. Containers, Products, Service Items), by setting the status (EPL_STATUS) to "X" - Cancelled.
** Write a User Tracking record for each of the jobs - see below for details.

* For order status 301 (Cancelled), 302 (Rejected) and 401 (Complete):
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.

* Ignore any other messages than the ones above, if the System Type (EPL_SYSTEM_TYPE) is ''not'' "PvA" - breaks will not be processed through this TomTom WEBFLEET interface when the full {{#var:System}} system is being run.

'''Processing of result records without an order state value:'''
These messages are used predominantly to generate breaks indicated by the driver.

{{Note}} Drivers Pausing and Starting work will generate new breaks and update in progress jobs. Breaks will not be generated if the driver is already in-progress on a pre-existing break job. Pre-existing break jobs (for example, generated by DiPS) will not be updated or confirmed when the driver pauses or starts work on the WEBFLEET device.

* Filter (ignore) any messages that are not being processed by this interface. Initially, the list should be filtered for tag msgClass value "DATA" and the following message types (extracted from the last 3 digits of the value in the msgType tag):
** 711 - Log-off driver (including tachograph driver card removed) - treat as end of break.
** 712 - Begin of work, driver indicated - treat as end of break.
** 713 - End of work, driver indicated - treat as end of break.
** 714 - Begin of break, driver indicated - treat as start of break.
** 715 - End of break, driver indicated - treat as end of break.
** 716 - Work status change, indicating driver role, old and new work status (applies to all PRO 71xx, 91xx devices when used with identified driver and Remote LINK Working Time). If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.
** 717 - Work started (driver role and driver name indicated) - treat as end of break.
** 718 - Work ended (driver role and driver name indicated) - treat as end of break.
** 719 - Work time event, indicating driver. If the tag pndWorkingStateMessageData sub-tag workstate value is "PAUSE", treat as start of break. If the tag pndWorkingStateMessageData sub-tag workstate value is "WORKING", treat as end of break.

* If treating the message as Start of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a break (either generated by the system or generated by DiPS) that is status In Progress (EPL_STATUS is "I"). If there is one, ignore this message, as a break is already started.
** Find the first job on that load that is not complete i.e. the status (EPL_STATUS) is "P" - Pending - or "I" - In Progress, ordering by the status In Progress (i.e. those jobs should be the first jobs found).

** Create a new break job as follows:
*** EPL_SITE_ID - From the found Load's Site ID
*** EPL_LOAD_ID - From the found Load ID
*** EPL_JOB_ID - Generated
*** EPL_JOB_CODE - "BRK_<EPL_LOAD_ID>_<EPL_SEQUENCE_NO>". The tagged values should be substituted with the found Load ID, and the DIPS column value LINK SEQ NO respectively.
*** EPL_JOB_TYPE - "D"
*** EPL_JOB_GROUP - "OTHER"
*** EPL_JOB_INSTRUCTION - "Driver Break"
*** EPL_START_PLANNED_DATE - from the tag posTime value.
*** EPL_START_PLANNED_TIME - from the tag posTime value.
*** EPL_START_ACTUAL_DATE - from the tag posTime value.
*** EPL_START_ACTUAL_TIME - from the tag posTime value.
*** EPL_ARRIVAL_DATE - from the tag posTime value.
*** EPL_ARRIVAL_TIME - from the tag posTime value.
*** EPL_END_PLANNED_DATE - from the tag posTime value.
*** EPL_END_PLANNED_TIME - from the tag posTime value.
*** EPL_DISTANCE_PLANNED - 0
*** EPL_CUSTOMER_CODE - "BREAK"
*** EPL_CUSTOMER_NAME - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_ADDRESS_1 - "Driver Break " concatenated with the sequence (EPL_SEQUENCE) and the Load ID (EPL_LOAD_ID) from the found job.
*** EPL_POSTCODE - The postcode from the found job.
*** EPL_SEQUENCE - The sequence from the found job
*** EPL_LOADING_TYPE - Blank
*** EPL_TRAVEL_PLANNED - 0
*** EPL_WORK_PLANNED - 0
*** EPL_LAT - from the tag pos, sub-tag latitude value, converted to degrees.
*** EPL_LONG - from tag pos, sub-tag longitude value, converted to degrees.
*** EPL_LAST_CHANGED_DATE - Now
*** EPL_LAST_CHANGED_TIME - Now
*** EPL_ODO_START - from the tag odometer value, if present.
*** EPL_GENERATED - "Y" - Generated by the driver.
*** EPL_STATUS - "I" - In Progress
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - Start of Break" - see below for details.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

* If treating the message as End of Break:
** Find the Vehicle(s) (EPOD_VEHICLE) through the External System Reference (EPL_EXT_REF) from tag objectNo attribute value, for sites that match the fleet parameter from the extraction (EPL_XF_RECIPIENT from EPOD_XF_CONFIG).
** Find the load in progress on that Site (EPL_SITE_ID) and vehicle ID (EPL_VEHICLE_ID), for all matching vehicles. If one is not found, do not process this message.
** Find a job (EPOD_JOB) on the load that is a driver-generated break that is status In Progress (EPL_STATUS is "I"). If there is not one one, ignore this message.
** If there is one, update it as follows:
*** Set the Actual End date and time (EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME) from the tag posTime value, translated into OBS format.
*** Set the break job's ODO End (EPL_ODO_END) from the tag odometer value if present.
*** Set the break job's status to Complete (EPL_STATUS = "C".
*** Set the Last Changed date and time (EPL_LAST_CHANGED_DATE and EPL_LAST_CHANGED_TIME) to the current server time, in OBS format.
*** Set the driving time (EPL_DRIVING_TIME) from the Arrival time on the job (EPL_ARRIVAL_TIME) minus the Actual Start time on the job (EPL_START_ACTUAL_DATE), plus any value already in this Driving Time field.
*** Set the actual work time (EPL_WORK_ACTUAL) from the Actual End time on the job (EPL_END_ACTUAL_TIME) minus the Arrival time on the job (EPL_ARRIVAL_TIME), plus any value already in this actual work time field.
*** Set the distance travelled (EPL_DISTANCE_ACTUAL) to the tag odometer value minus the start odometer value on the job (EPL_ODO_START), plus any value already in this distance travelled job field.
** If the break job found is a driver-generated break job, find any non-break jobs in progress (EPL_STATUS = "I") on the load. If found, set the distance (EPL_DISTANCE_ACTUAL) and travel time (EPL_DRIVING_TIME) on all the jobs to be the current values minus the values on the break job just updated, plus any value already in these fields. This will then remove the distance and travel that was added to the Break job from the job in progress, for the Planned vs Actual reporting later.
** Write a User Tracking record for the Break job created or updated to In Progress, indicating "WEBFLEET - End of Break" - see below for details.
** Check all the jobs on the Load.
*** If the System Type (EPL_SYSTEM_TYPE) is "PvA", if all have been completed or cancelled, set the Load status (EPL_STATUS) to "C" - Complete.
*** If all have been completed or cancelled and if the tag odometer value is present, set the ODO end against the load if not set (EPL_MILEAGE_END) from this incoming value. Set the Actual Distance travelled against the load (EPL_LOAD_DISTANCE_ACTUAL) to be the ODO end (EPL_MILEAGE_END)) minus the ODO start (EPL_MILEAGE_START), if both values are non-zero.
{{Note}} When the first matching vehicle with an in progress load is found, stop processing any further records.

{{Note}} If no EPOD_XF_CONFOG exists for the site for the WEBFLEET job update for that fleet for that vehicle, ignore the updates.

{{Note}} Any messages in the result that do not match the filtered messages above can be ignored - no audit is required.

{{Note}} When writing order tracking records to EPOD_USER_AUDIT, all of the normal details should be entered. This should be sourced from the Job record being updated unless specified otherwise:
* Site ID
* User ID - From the Load
* Vehicle ID - From the Load
* Load ID - From the Load
* Job ID
* Message Type - dependent on the tag orderState of the result being processed:
** 221 or 241 - "WEBFLEET - Order Started"
** 222 or 242- "WEBFLEET - Order Arrived"
** 301 - "WEBFLEET - Order Cancelled"
** 302 - "WEBFLEET - Order Rejected"
** 401 - "WEBFLEET - Order Complete"
** If this is Blank and the process is treating this as a Start of Break - "WEBFLEET - Start of Break"
** If this is Blank and the process is treating this as an End of Break - "WEBFLEET - End of Break"
* GPS Coordinates - from the converted values of the input tag pos, sub-tags latitude and longitude values, concatenated with a comma.
* Audit Date - The server date as of the time the record is processed.
* Audit Time - The server time as of the time the record is processed.
* Job Type
* Device Date - extracted date from the tag posTime value, translated into OBS format.
* Device Time - extracted time from the tag posTime value, translated into OBS format.

{{Note}} Once messages taken from the queue in this message response are successfully processed, the process must use the webservice method ackQueueMessagesExtern to acknowledge completion of the message transfer to the application. Otherwise, the messages will be kept and returned again during the next call to popQueueMessagesExtern.

{{Note}} In order to prevent this system from being flooded with over-sized responses, the number of messages that will be returned on a single response is limited to 500. This limit can be adjusted per account on request.

The structure of the ackQueueMessagesExtern method is identical to the above Pop message, except for the name, as follows:
<ser:ackQueueMessagesExtern>
<aParm>
<accountName>EPL_XF_RECIPIENT</accountName>
<userName>EPL_WEB_USER</userName>
<password>EPL_WEB_PASSWORD</password>
<apiKey>EPL_XF_MSG_TYPE</apiKey>
</aParm>
<gParm>
<locale>UK</locale>
<timeZone>Europe_London</timeZone>
</gParm>
<msgClass filter="ALL_EXCEPT_POSITION_MESSAGES" />
</ser:ackQueueMessagesExtern>

Again, the response to this message will be the same as the other WEBFLEET messages, except that the outer tag is ackQueueMessagesExternResponse. Regardless of status, the

Should the value of the tag resultSize be 500, this whole process of retrieving, processing and acknowledging messages should be repeated. This should continue until the result size is less than 500 (i.e. there are no more messages on the queue).

Should there be a problem processing the messages from the queue, an audit record of the row detail and the error code should be created in EPOD_XF_AUDIT_HEADER. Failing a single message does not result in the message failing - these should always be acknowledged. Failures encountered server-side (failures within {{#var:System}} should result in not acknowledging the message, so that they may be reprocessed later by re-reading them from the queue.

When writing Audit records for failures and successes, the records should be populated as follows. If not specified, the values should be derived from the job:
* Site.
* Job Group, if this is an audit related to a job.
* Header ID - Generated.
* Request Data - If Failure, the resultItem tag and contents.
* Request Date - The server date as of the time the record is processed.
* Request Time - The server time as of the time the record is processed.
* Status - "S" for Success, "F" for Fail, as indicated above when writing the audit record.
* Status Description - If Success, "Jobs Updated", else the reason for the failure (e.g. "Load already completed", "Job already cancelled", etc) as indicated above.
* Key Value 1 - The Job Code, if this is an audit related to a job.
* Key Value 2 - The Job ID, if this is an audit related to a job.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing all aspects of the WEBFLEET - {{#var:System}} Update Interface.
|MenuAccess=N/A
|Prerequisites=Create 2 loads with jobs configured as per the example Load in the supplied CSV extraction from DiPS.
|Objective=To test that: jobs are updated with all actual information; Loads are updated correctly; jobs done out of sequence are updated taking into account any intermediate distance and time; driver-generated breaks are created correctly; jobs completed with breaks whilst in progress are updated taking into account any intermediate distance and time.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 1 - Normal Processing.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept and Start Loading job.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Arrive Loading Job.
|Result=Job updated in C-ePOD - Arrival Date/Time and End ODO updated, Travel Time and Distance updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD - Job Complete, Actual End Date/Time updated, Work Time updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Accept, Start and Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Reject Delivery Job 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Delivery Job 3.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Delivery 1.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel Consolidated Delivery 2.
|Result=All Jobs updated in C-ePOD as before in stages - final result: Jobs Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Break 2 before the next job (out of sequence).
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 4.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated. Next Load automatically set to In Progress (not part of this test).
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 2 - Out of sequence.
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Loading Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start and Drive to Delivery Job 1. Do not Arrive at Job.
|Result=Job updated in C-ePOD as before in stages - final result: Job In Progress, Actual Start Date/Time, Job Start ODO updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start, Arrive and Complete Delivery Job 2 before completing Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Delivery Job 1.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance Travel times take into account the distance and time travelled on the job 2 in between.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Cycle 3 - Driver-generated Breaks.
|Notes=Continuing from Cycle 2.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause Work.
|Result=Creates new break job as specified.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Work.
|Result=Updates new break job - Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised break job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start Consolidated jobs 1.
|Result=Job updated in C-ePOD - Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Pause and Start Work.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the Break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Continue Consolidated jobs. Pause and Start Work again.
|Result=Creates and updates new break job in stages as before: Job In Progress, Actual Start Date/Time updated on Load and Job, Load and Job Start ODO updated. Updates In-progress Consolidated Jobs 1 wrt Time and Distance taken away for the time and distance taken on the next Break added to the previous break.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Consolidated Jobs 1.
|Result=Jobs updated in C-ePOD as before in stages - final result: Jobs Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Jobs. Distance, Work and Travel times take into account the distance, work and time travelled on the 2 break jobs in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete consolidated jobs 2.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the next job. Pause and Start work, complete job.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Distance, Work and Travel times take into account the distance, work and time travelled on the break job in between.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel preadvised Break.
|Result=Job updated in C-ePOD as before in stages - final result: Job Cancelled, User Notes, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete Unloading.
|Result=Job updated in C-ePOD as before in stages - final result: Job Complete, Actual Start Date/Time, Job Start and End ODO, Arrival Date/Time, Travel Time, Distance, Actual End Date/Time and Work Time updated on Job. Load updated to Complete, End ODO updated.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|Ref2=EPOD Import Mapping
|RefV2=5.1.2
|RefDate2=17/06/2016
|Ref3=EPOD Export Mapping
|RefV3=5.1.2
|RefDate3=17/06/2016
|Ref4=WEBFLEET.connect Reference
|RefV4=1.28.0
|RefDate4=31/03/2016
|Ref4=obs-eas-DIPS2AXS for PvA.xls
|RefV4=N/A
|RefDate4=24/06/2016
|REQ=0
|EST=0
|FS=1.75
|TS=1.75
|DEV=7.25
|ST=1.50
|IMP=0
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336014 SCR-332569-5 GK PvA ePOD-WEBFLEET Mods

2016-08-23T11:33:02Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|ePOD-WEBFLEET Interface Modifications}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336014 SCR-332569-5}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
Some slight modifications to the way that data is sent to TomTom WEBFLEET for orders will be undertaken

== Solution Overview ==
* Job Instructions will include the order reference to be displayed.
* The Planned Date and Time will be amended to be the Expected Arrival Date and Time (Planned Start Date/Time within CALIDUS ePOD).

== Scope ==



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==



= Functional Description =

== Auto-Export ==
Some slight modifications to the way that data is sent to TomTom WEBFLEET for orders will be undertaken:
* Job Instructions will include the order reference to be displayed.
* The Planned Date and Time will be amended to be the Expected Arrival Date and Time (Planned Start Date/Time within CALIDUS ePOD).

Currently the Order Text sent to WEBFLEET is the Job Instructions only. This will be modified so that the Job Code is inserted before the Instructions, so that it can be visible on the device when completing the job. Where jobs are consolidated, the Job Code of all the jobs should be present, concatenated with a slash ("/") character. The Job Code is expected to be populated with the ORDER OR SHIPMENT IDENT from the DiPS interface (example "3031298"). The Job Instructions is expected to be populated with ORDER SPECIAL DELIVERY INST (example "pls call 30m b4 del 07970884489 Kul"), and the concatenated weight and quantity (example "179 KILOGRAM, 6 D-RB, 33 W+S").

The final instructions sent to WEBFLEET will then be as follows:
"3031298 pls call 30m b4 del 07970884489 Kul 179 KILOGRAM, 6 D-RB, 33 W+S"
"6030158/6029870 pls call 30m b4 del 07970884489 Kul 179 KILOGRAM, 6 D-RB, 33 W+S"

Currently the End Planned date and time are sent to WEBFLEET as the Scheduled Completion Date and Time. This will be modified to be the Start Planned Date and Time. This will be populated in the interface from DiPS as EAT AT CALL.

''Developer Notes:''

The data is populated in method EPODServer.EPOD_SYS_EXPORT.TomTomOrdersGetRequestXML.

strOrderText will now be populated with:
drData["EPL_JOB_CODE"].ToString()).Trim() concatenated with (drData["EPL_JOB_INSTRUCTION"].ToString()).Trim()

Dates will now be populated with:
iDate = (int)drData["EPL_END_PLANNED_DATE"];
iTime = (int)drData["EPL_END_PLANNED_TIME"];

Given the nature of the way that data is populated in the interface, there is no need to control this data population with flags in the system.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test modifications to the WEBFLEET interface.
|MenuAccess=N/A
|Prerequisites=An active WEBFLEET orders interface.
|Objective=To test that orders are created in WEBFLEET with the new details.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=WEBFLEET Export
|Notes=Ensure an active WEBFLEET interface is created.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a load with jobs - ensure the Start and End Planned Dates and Times are different, that the Job Codes are set and different, and that the Instructions are populated. Assign the load to a WEBFLEET-enabled vehicle.
|Result=In WEBFLEET, the orders should be created on that vehicle with Dates/Times as per the Planned End Date, and the Instructions are populated with the Job Code as well as the instructions.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a load with consolidated jobs - ensure the Start and End Planned Dates and Times are different, that the Job Codes are set and different, and that the Instructions are populated. Assign the load to a WEBFLEET-enabled vehicle.
|Result=As the prior test, but the consolidated jobs should have all of the Job Codes listed on the instructions.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|REQ=0
|EST=0
|FS=0.25
|TS=0
|DEV=0.50
|ST=0.25
|IMP=0
|PM=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336013 SCR-332569-4 GK PvA Automatically Set Loads In Progress

2016-08-23T11:04:52Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|Automatically Set Loads In Progress}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336013 SCR-332569-4}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
Once the DiPS import is complete, the drivers will require the ability to execute the jobs through TomTom WEBFLEET. In order to achieve that, CALIDUS ePOD must generate the orders on to TomTom WEBFLEET. A process already exists to complete that, when loads are set to In Progress. The setting of loads to this status is normally achieved through the CALIDUS ePOD devices requesting a load. As ''CALIDUS'' ePOD will not be in use at this time, a process will be required to automatically set the status of the earliest loads for a vehicle to In Progress.

== Solution Overview ==
The process will be capable of being configured by Site (Depot). Any loads at status In Progress or Pending will be checked and the earliest load for that vehicle will be marked in progress. This will then automatically trigger a requirement to send this load to TomTom WEBFLEET. If there was already a load in progress for the vehicle, this load will be changed back to Pending and TomTom WEBFLEET will be informed to remove any jobs associated to this load from the worklist.

Notes:
* Only vehicles configured with a TomTom External ID within CALIDUS ePOD will have orders sent to them.
* Only jobs that are not yet complete will be sent to TomTom WEBFLEET.
* Only Loads In Progress will be sent to TomTom WEBFLEET.

== Scope ==
{{Note}} Parts of the testing of this change will be completed with 336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==



= Functional Description =

== Database/DAL ==
A new EPOD_SITE flag will be added to control automatically setting loads in progress.
* EPL_AUTO_IN_PROGRESS_LOAD_IND - numeric flag, defaulting to 0.
This should be added to all database procedures and DAL objects. It is not necessary to add this as a searchable item.

== Admin ==
A new value to the existing Site-level flag System Type will be added to control PvA-specific functionality.

The new value will be "PVA", description "Planned vs Actual".

== System ==
Whenever a load has the status updated to Complete or Cancelled, or has the vehicle changed, or has the start planned date or time changed, the process will check the following:
* That the vehicle has an external ID (i.e. is enabled for WEBFLEET).
* That automatic status change to In Progress is required (through the new value of the system flag)
* That this is the earliest planned load for that vehicle.
If this is the case, the Load Status should be set to In Progress and then call the following two existing procedures:
// Update other loads for this user or vehicle but if only if the load has successfully been updated
EPOD_LOAD.LoadUserOrVehicleChanged();
// Create EPOD_XF_CONTROL record if the load has successfully been updated
EPOD_LOAD.CreateXFControlRecord();

These will have the following effect:
* Check the load for changes of vehicle/user
* Create the record to process the sending of the Load and all jobs to WEBFLEET if required.
* Change any prior Loads in progress to Pending.

This new check should be created as a new method of the EPOD_LOAD object.

The Load Status may be updated from the following procedures:
* The Load Assignment screen (load_assignment.aspx)
* The Load Header admin screen (load_header.aspx)
* When Loads are updated through the Upload process (Upload.aspx)
* When Flat File Uploads are processed automatically (EPOD_DATAPROCESS.cs)
* When External Webservices update loads (EPOD_DATASERVICE.cs and MessageProcess.cs)
* When a device updates loads (MessageProcess.cs)
{{Note}} This is not a complete list - ALL areas should be modified.

The new procedure for processing DiPS files (in EPOD_DATAPROCESS.cs, specified in 336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing) should also be changed for this purpose.



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test loads automatically set to in progress.
|MenuAccess=N/A
|Prerequisites=N/A
|Objective=To test that; the Site flag may be properly configured by the Admin system; any mechanism of changing the load status, date or vehicle results in the load being set to In Progress, any previous load being reset, and the new load being sent to WEBFLEET.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin Maintenance
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit the new flag so that this is set to the new value, and save the changes.
|Result=The flag may be edited and changed to the new value.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Auto Load In Progress
|Notes=Ensure the Site System flag is set to PvA initially.
Ensure that there are at least 2 vehicles, one with an external ID and one without.
Ensure that there is are at least 2 loads per vehicle.
Ensure WEBFLEET interfaces are enabled for this site.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Add a new load for a WEBFLEET-enabled vehicle through the Webservices. Ensure this is the earliest planned date.
|Result=The load should be set to In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Amend another load for the same Vehicle to be an earlier planned date/time in the Load screen.
|Result=The load should be set to In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load. The original In Progress load should be reset to Pending.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Update the original load to an earlier date using a Flat File format.
|Result=The load should be set to In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load. The original In Progress load should be reset to Pending.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Update the load to a later date using the Load screen.
|Result=The load should be set to status Pending. The earlier load should be set to status In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Deallocate the In Progress load from this vehicle.
|Result=The load should be set to status Pending. The earlier load should be set to status In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Allocate the load to a vehicle without WEBFLEET integration.
|Result=Nothing.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Allocate the load to a WEBFLEET vehicle. Complete all jobs on the Load (through ePOD or WEBFLEET).
|Result=The load should be completed. The next load for that vehicle should be set to status In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel the next load through the Admin screen.
|Result=The load should be cancelled. The next load for that vehicle should be set to status In Progress. A message for this load should be set on the XF Control. Messages should be sent to WEBFLEET for the jobs on this load.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set the System flag back to Generic. Add an earlier load for the WEBFLEET enabled vehicle through Webservices.
|Result=The load should be created but not automatically set in progress.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|EEST=0
|EFS=0.25
|ETS=0.25
|EDEV=1.75
|ESTT=0.25
|EIMP=0
|EPM=0.25
|REQ=0
|EST=0
|FS=0.25
|TS=0.25
|DEV=1.75
|ST=0.25
|IMP=0
|PM=0.25
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336012 SCR-332569-3 GK PvA Add Time Windows

2016-08-23T11:00:06Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|Add Time Windows}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336012/SCR-332569-3}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
In order to support the functionality required within the Planned Vs Actual report regarding time windows, the application will be modified to store the time windows information from the DiPS interface.

== Solution Overview ==
These will be added as new table, at Job level, to account for potential multiple time windows. The data is assumed to be taken from OPENING/CLOSING TIME 2 at this time. There is no way of identifying or specifying multiple delivery windows or customer delivery windows in the way that Aurora and DiPS plan jobs at this time. A customer is expected to always have a delivery window configured against it, and that it may change (by configuration) for each day of the week if required.

== Scope ==
Although this change will be made capable of storing multiple time windows against a job or against a customer, the interface here will only create job windows, and only one of them per job. Should Aurora and DiPS (or the interface between them) be modified to support multiple windows, or there is a product requirement to add multiple customer windows, this will generate additional cost. It is not expected that this will be required at this time.

The changes here are to support multiple time windows from the bespoke DiPS interface, and for use within the Planned Vs Actual report only - there is no mechanism of viewing or editing these through the ePOD Admin application. If this is required, this will generate additional cost. If the full ''CALIDUS'' ePOD solution is agreed, this time will be added part of the full solution defined in that project.

{{Note}} Testing of this change will be part of the 336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing.



= Set-up =

== Pre-requisites ==
This change is part of the 336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing. Set up for that change must be completed so that this may be tested.

== Menu Structure ==
None

== Data ==
None



= Functional Description =

== Database/DAL ==
These will be added as new table, at Job level, to account for potential multiple time windows. The data is assumed to be taken from OPENING/CLOSING TIME 1/2 at this time. There is no way of identifying or specifying multiple delivery windows or customer delivery windows in the way that Aurora and DiPS plan jobs at this time. A customer is expected to always have a delivery window configured against it, and that it may change (by configuration) for each day of the week if required.

The new table will be called EPOD_TIME_WINDOW and will be structured as follows:
* ETW_ID - an auto-generated number.
* ETW_SITE_ID - nvarchar(10)
* ETW_TYPE - nvarchar(1)
* ETW_FK_ID - nvarchar(30)
* ETW_TIME_START - number
* ETW_TIME_END - number
There will be primary key added as follows:
* ETW_ID - an auto-generated number.
An index will be added called ETW_TYPE as follows:
* ETW_SITE_ID - nvarchar(10)
* ETW_TYPE - nvarchar(1)
* ETW_FK_ID - nvarchar(30)

A new DAL object will be created to access this data. Database procedures will be created

The table must support being linked to a job or to a customer. This is through the new index.
* For jobs, this is expected to be populated with the job's Site ID, the Type as "J" and the Foreign Key ID as the Job ID (EPL_JOB_ID of EPOD_JOB).
* For customers, this is expected to be populated with the customer's Site ID, the Type as "C" and the Foreign Key ID as the customer ID (EPL_CUSTOMER_CODE of EPOD_CUSTOMER).

The Archiving routines must be updated to delete these new records when deleting Customers or when deleting Jobs.



= Appendix A: TEST PLAN =

{{Note}} Testing of this change will be part of the 336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing.


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=336010/SCR-332569-2 DiPS-ePOD Interface for Load and Order Sequencing
|RefV1=1.0
|RefDate1=23/08/2016
|REQ=0
|EST=0
|FS=0.5
|TS=0.5
|DEV=2.75
|ST=0.5
|IMP=0
|PM=0.25
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 336010 SCR-332569-2 GK PvA DiPS-ePOD Interface

2016-08-23T10:56:38Z

Tippingm: v1.0 - Issue to Greene King

<div class="noprint">
{{#vardefine:Client|GK}}
{{#vardefine:ClientName|Greene King}}
{{#vardefine:System|''CALIDUS'' EPOD}}
{{#vardefine:Doc_Title|DiPS-ePOD Interface for Load and Order Sequencing}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd August 2016}}
{{#vardefine:Reference|336010 SCR-332569-2}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
Orders will be exported from Aurora into DiPS for route planning. DiPS is a route optimisation tool which optimises the drops in to the optimum route. When planned within DiPS, the routed orders with load details will be exported back into Aurora, through an existing interface, consisting of only limited details. At this time, DiPS will also generate a new fully-populated CSV for import into {{#var:System}}.

The file will be generated from DiPS in mid-afternoon for the following day - they will then be finalised and sent through to TomTom.

The file will contain all fields that can be exported from DiPS, to minimise any additional work required for any future requirements.

The file will contain all routes for individual depot, or all routes for all depots. Routes must be assigned to a vehicle & driver. Routes must contain postcodes and/or valid Lat/Long co-ordinates.

An example full file export has been provided and is referenced in Appendix B.

This file will be generated to a local or network folder, accessible by {{#var:System}} - this can be through an FTP account or file sharing. It will be expected to be named uniquely, as a variant of DIPS2AXS.TXT. Note that the name must either be unique per export, or unique per depot, or created as a different name then renamed for {{#var:System}} to pick up, to prevent partial uploading of the file.

{{#var:System}} will be modified to automatically import the file through a process triggered to run every few minutes. This will be a bespoke process written specifically for this purpose.

Additional orders, cancellation of orders and changes to orders already received throughout the day will necessitate changes to the plan. Aurora and DiPS will follow the same process to send orders across to DiPS and route plan them. When exported from DiPS, the same import file will be created for all of the orders and loads.

When uploading files with orders and loads that have already been created, the process will update any existing Loads and Orders with the information from the new import file.

== Solution Overview ==
The process will process the file and create Loads and Jobs from the information provided.

The first depot job on a load will be marked as a loading job, and all subsequent depot jobs on a load will be marked as an unloading job. The Order Number (Job Code) for these jobs will be generated from a code "LOA" or "UNL" and the Load ID and a sequence.

Break jobs on a load will be generated as a normal job with customer 'BREAK'. They will be given a job address based on the BREAK customer, but with a Lat/Long set as the last job processed on the load. The instructions will be the break length. The Order Number (Job Code) for these jobs will be generated from a code "BRK", plus the Load ID and a sequence.

{{Note}} DiPS can provide a planned driver break on the inbound file, in between of the execution of orders, not during the execution of the orders. This solution expects that breaks will be created as delivery jobs with specific default information. These will then act identically to delivery jobs within TomTom WEBFLEET.

No functionality is included here to make Break jobs visible within ''CALIDUS'' ePOD specifically as Break job types or to handle them differently to collections or deliveries on the mobile device. If the full ''CALIDUS'' ePOD solution is put in place, a further change will be undertaken there to handle break jobs on the Android device and within the general administration screens. This will be added as a change in the Greene King ''CALIDUS'' ePOD solution design document.

The Jobs and Load created will be stored in the normal tables within ''CALIDUS'' ePOD, with additional fields created for the new planned data.

The process will generate the following standard ''CALIDUS'' ePOD tables:
* EPOD_LOAD - each unique load will be created, within the Site (Depot) owning the load.
* EPOD_JOB - a unique job will be created for the order on the load specified.
* EPOD_CUSTOMER - A customer record will be automatically created if one does not already exist, including the Lat/Long of the address.
* EPOD_JOB_ADDRESS - if the customer record exists, but the address or information on it differs to the information on the job, an Address will be created specifically for the job.
* EPOD_VEHICLE - A vehicle record will be automatically created for vehicle assigned to the load, based on the Vehicle Registration, if one does not already exist. {{Note}} Vehicles created automatically in this way will not have a TomTom ID (Object ID) assigned to them, meaning that loads for vehicles automatically generated in this way will NOT be automatically sent to TomTom until this is completed.
* EPOD_USER - a driver record will be automatically created based on the driver name received from DiPS. This driver ID will be generated from the driver name, and provided a generic password. {{Note}} Although not part of this project, these automatically created drivers may then be used on ''CALIDUS'' ePOD devices to complete the jobs. This will be disabled until ''CALIDUS'' ePOD is implemented.

The following assumptions are made regarding the data that ''CALIDUS'' ePOD will use:
* Load
** Site - the depot, from CALLS OWNING DEPOT
** Load ID - from CALLOVER SEQUENCE NO. {{Note}} This load ID '''must''' be unique for every load ever created for a depot.
** Load Planned Start/End times - from the individual jobs on the load.
** Vehicle ID - generated from VEHICLE IDENT
** User ID - generated from DRIVER'S NAME OR CARRIER
** New fields will be required to store:
*** Route Code - TRIP LABEL
* Job
** Job Code (the main reference) - ORDER OR SHIPMENT ID. {{Note}} This reference '''must''' be unique for for the order on the load (it can appear as a collection and a delivery if required).
** Job Type - These will be identified as Delivery jobs only, regardless of whether they are collections or deliveries within DiPS. If functionality is added between Aurora and DiPS to identify collections to DiPS, this may generate additional development. As this would only affect the full ''CALIDUS'' ePOD solution (if implemented), this will be added as change to that project.
** Job Group (the main configuration of the execution of the jobs) - based on the job type, hard-coded. For Loading, Unloading and Break jobs, a different job group will be used to Collections and Deliveries.
** Job Instructions - a concatenation of the weights/quantities, or ORDER SPECIAL DELIVERY INST
** Planned Start Date/Time (Planned Arrival) - OPENING TIME 1
** Planned End Date/Time - CLOSING TIME 1
** Planned Distance - TRAVEL DISTANCE TO NEXT CALL from previous job on this load
** Customer Code - IDENT OF CALL OR DEPOT
** Customer Details, from:
*** Name - ADDRESS LINE 1
*** Address - ADDRESS LINE 2/3/4/5/POSTCODE
*** Telephone - TELEPHONE NUMBER
** Sequence on Job List - LINK SEQ NO
** Loading Type - For Depot jobs.
** New fields will be required to store:
*** Planned Travel Time (Minutes) - TRAVEL TIME TO NEXT CALL from the previous job
*** Planned Work Time (Minutes) - WORK TIME
*** ETA Date and Time - For TomTom WEBFLEET integration

{{Note}} There is a requirement to display the Weight and Quantities on the TomTom WEBFLEET device, combining them into the instructions field. This can be achieved, depending on whether the length of the data required exceeds the length in ''CALIDUS'' ePOD. This will need to be agreed and the DiPS fields from which this data is taken agreed during the mapping session. If this exceeds the maximum length, additional cost may be incurred.

Time windows will be also be added to the jobs here if present in the file.

Additional orders, cancellation of orders and changes to orders already received throughout the day will necessitate changes to the plan. Aurora and DiPS will follow the same process to send orders across to DiPS and route plan them. When exported from DiPS, the same import file will be created for all of the orders and loads.

When uploading files with orders and loads that have already been created, the process will update any existing Loads and Orders with the information from the new import file.

When all imports are completed for a load, the process will check if any orders already on the load were not included in the new upload. If orders are found, these will be deleted.

When all load imports are completed, the process will check if any loads already in the system for that date were not included in the new upload file. If loads are found, these will be deleted.

== Scope ==
{{Note}} This process will be used to create loads and jobs for a particular date. It is expected that this import will always interface all loads and jobs for the date. This can then be used to determine loads or jobs which are no longer valid, which can be removed from the {{#var:System}} database.

{{Note}} This import is expected to be in Load and Job order. No additional orders for a load will be found in this file after the file has moved on to another load.

{{Note}} One file is expected to be imported per depot. These files should never be combined, and should retain either a unique naming convention or unique directory for the file to be found.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
The Site must be linked to the XF Config ID for the file to be imported. This is expected to be set during the implementation. This is achieved through the Site maintenance screen in the {{#var:System}} Admin console, from the Admin tab, XF Config drop-down list.

{{Note}} Users generated through this process will be consistent and reused. However, they will have a default password created for them by this process, which should be changed to a reasonable and secure password through the {{#var:System}} Admin User Maintenance screen before use. For usability, the users created are enabled immediately, so this should be dealt with by the administrative users quickly.



= Functional Description =

== Database/DAL ==
A new field will be added to the EPOD_LOAD table to hold the value of the Route Code from DiPS (TRIP LABEL):
* EPL_ROUTE_CODE - nvarchar(40).
All database packages and the DAL object will be updated to update this new field.
{{Note}} It is not necessary to add this field as a search-able item.

New fields will be added to the EPOD_JOB table to hold various new values, as follows:
* EPL_TRAVEL_PLANNED - Planned Travel Time, in whole numbers of minutes - number.
* EPL_WORK_PLANNED - Planned Work Time, in whole numbers of minutes - number.
* EPL_ETA_DATE - ETA date from TomTom WEBFLEET in YYYYMMDD format - number
* EPL_ETA_TIME - ETA time from TomTom WEBFLEET in HHMMSShh format - number
All database packages and the DAL object will be updated to update these new fields.
{{Note}} It is not necessary to add these fields as search-able items.

The existing field EPL_DISTANCE_PLANNED should be changed to be a float type (i.e. capable of storing decimal values).

{{Note}} As standard, these fields will be added to the standard XML Webservice Import and Export flows. These changes (and all others for the project) have been documented and referenced in [[#Appendix B: Quote & Document References|Appendix B]]. The standard XMLUpload.XSD file describing the XML in detail will also be updated as part of this project. Note also that the type of the distance planned object must change to "xsd:float".

{{Note}} The following fields must be added to the standard Webservice import when creating addresses (customer or job):
* EPL_LAT
* EPL_LONG

== Admin ==
=== XF Config Maintenance ===
The screen will allow the following to be created/edited:
* Config ID - The ID (e.g. GK).
* The Config Name - (e.g. DIPS Orders).
* Type - FILE or FTP only.
* ID - DIPS - DIPS Orders.
* Destination - the destination folder for the FTP Get or the FILE pick-up location.
* Direction - I - Inbound only.
* Filename - a filename pattern, for example "DIPS2EPOD_*.xls".

The screen will only allow these elements to be entered or edited, based on the ID (DIPS) selected.

== Auto-Import ==
The existing Auto Import process will be modified to identify the new DIPS import id. If a configuration is found for this new type, the new DIP Import process will be run, passing in this file.

{{Note}} This message type can be processed as FILE or FTP.

The standard processing for FILE and FTP types should be followed, in that the file to be imported should be found in the directory specified matching the pattern of the filename specified in the configuration. When found, the file should be copied and imported through the new DIPS orders import process.

{{Note}} One file is expected to be imported per depot. These files should never be combined, and should retain either a unique naming convention or unique directory for the file to be found.

=== DIPS Import Process ===
{{Note}} This process will be used to create loads and jobs for a particular date. It is expected that this import will always interface all loads and jobs for the date. This can then be used to determine loads or jobs which are no longer valid, which can be removed from the {{#var:System}} database.

{{Note}} This import is expected to be in Load and Job order. No additional orders for a load will be found in this file after the file has moved on to another load.

{{Note}} The extract file from DiPS contains over 150 columns. At this time, only a small section of these values will be used. However, it may be that this needs to expand for the customer in the future. To ensure that this process is easier to maintain moving forward, the extract file sent to {{#var:System}} will contain all the columns, with a header row labelling the contents. The process will be written in such a way as to extract the values by searching for the column required. This will make the function easier to maintain and more extensible in the future, should the format change or the required data in the file change.

The first row of the file being uploaded will be read, to determine the necessary columns to extract. This will be stored in a property of the import function.
A getRowVal method will be written to identify the column, by searching for the value in the header row. This will be passed the header row, and will search the header property for the passed-in column header, and will return the value from this column in the row. If the column is not found, NULL should be returned, to identify this, different to when a column is found, but the data value is zero-length.

So accessing the column data will be as in the following typical example:
With the header row (e.g. dsData.Tables[0].Rows[0]) being stored first,
getRowVal(Row, "ORDER SPECIAL DELIVERY INST")].ToString();

The process created here should be similar to the OBS Import process in structure, in that:
* Loads are found and created if required
* Jobs are found and created if required
* Standing Data (e.g. Vehicles, Users) should be found and created if necessary.
* Existing data not found on the export file will be removed after the update if they were not updated as part of this run.

The process will read through each row (storing the header row as identified previously) and process the inbound records.

The Site for the upload will be set from the Site to which the XF configuration is linked.

==== Create Standing Data ====
The process will generate a Vehicle ID. This will be through the value in VEHICLE IDENT. The vehicle record will be found using the Site and Vehicle ID, using the found Site ID and VEHICLE IDENT. If not found, this will be created with the following values:
* Site: the found Site ID
* Vehicle ID: VEHICLE IDENT with any spaces removed.
* Vehicle Reg/Description: VEHICLE IDENT
* Status: "Y", indicating Active.
* Last Updated Date and Time: Now

The process will generate a User ID. This will be from the value in DRIVER'S NAME OR CARRIER. This ID will be based on the first letter of the first name followed by the surname, lowercase converted. The user will be found. If the name stored matches DRIVER'S NAME OR CARRIER, this will be used. If the names do not match, a single digit (starting at 1) will appended to the name and be incremented by one, and the process repeated until the matching name is found, or no record is found.
If a record is not found, one will be created, as follows:
* Site: the found Site ID
* User ID: The generated user ID
* Password: "PASSWORD"
* User Name: DRIVER'S NAME OR CARRIER
* Admin: "N"
* Active: "Y"
* Last Updated Date and Time: Now

==== Creating Loads ====
The process will find the load through the Site and Load id, from the found Site ID and CALLOVER SEQUENCE NUMBER respectively.

If the load is already present and complete or cancelled, no update to this load will be made and no jobs will be imported on this load.
If the load is already present, the load will be updated with the following information:
* EPL_LOAD_START_PLANNED_DATE - DEPARTURE DATE (removing the last digit, as this is in format "YYYYMMDDW")
* EPL_VEHICLE_ID - from the found/created Vehicle ID
* EPL_USER_ID - From the found/created User ID
* EPL_TRAILER_ID - TRAILER_IDENT
* EPL_LOAD_INFORMATION - ROUTE_IDENT
* EPL_TIMEZONE - As normal, from the server
* EPL_STATUS "P", if not already created, else to be left at current status.
* EPL_ROUTE_CODE - TRIP_LABEL

The load should NOT be updated at this time, only when the load changes or no more records exist in the file to be imported.

==== Create Jobs ====
The process will then create Delivery and Break jobs from the data.

The process will find the job using the found Site ID, the found/created Load ID, the ORDER OR SHIPMENT ID from the file (the job code) and the Job Type, based on the column "ENTITY TYPE (C,D, K)".
For ENTITY TYPE (C,D, K):
* If this column is "B" or "C", the Job Type is "D".
* If this column is "D", and this is the first job processed on this load, the job type is "C", else "D".
* If this column is "D", the ORDER OR SHIPMENT ID will be blank. If so, the Job Code should be generated as "LOA_<EPL_LOAD_ID>_<LINK SEQ NO>", if this is the first job processed on the Load. If this is not the first job on the load, this should be generated as "UNL_<EPL_LOAD_ID>_<LINK SEQ NO>". The tagged values should be substituted with the found Load ID, and the DIPS column value LINK SEQ NO respectively.
* If this column is "B", the ORDER OR SHIPMENT ID will be blank. If so, the Job Code should be generated as "BRK_<EPL_LOAD_ID>_<LINK SEQ NO>", replacing the tags as above.

If the job is found, this job will be updated if the status is not "X" or "C" (complete or cancelled). If not found, this job will be created. The Job ID will be generated if the job is not found.

==== Create Delivery Jobs ====

For Delivery Job Types:
* EPL_SITE_ID - From the found Site ID
* EPL_LOAD_ID - From the found Load ID
* EPL_JOB_ID - Generated if not found
* EPL_JOB_CODE - As generated above
* EPL_JOB_TYPE - As generated above
* EPL_JOB_GROUP - "DEL".
* EPL_JOB_INSTRUCTION - see the section below this for details.
* EPL_START_PLANNED_DATE - DEPARTURE DATE (YYYYMMDDW) (removing the last digit)
* EPL_START_PLANNED_TIME - EAT AT CALL
* EPL_END_PLANNED_DATE - DEPARTURE DATE (YYYYMMDDW) (removing the last digit)
* EPL_END_PLANNED_TIME - EDT AT CALL
* EPL_DISTANCE_PLANNED - TRAVEL DISTANCE TO NEXT CALL From previous job
* EPL_CUSTOMER_CODE - IDENT OF CALL OR DEPOT
* EPL_CUSTOMER_NAME - ADDRESS LINE 1
* EPL_ADDRESS_1 - ADDRESS LINE 3
* EPL_ADDRESS_2 - ADDRESS LINE 4
* EPL_ADDRESS_3 - ADDRESS LINE 5
* EPL_ADDRESS_5 - COUNTRY CODE
* EPL_POSTCODE - POSTCODE
* EPL_CONTACT - ADDRESS LINE 2 if not "."
* EPL_TELEPHONE - TELEPHONE NUMBER
* EPL_ORDER_DATE - defaulted to Now()
* EPL_SEQUENCE - LINK SEQ NO
* EPL_LINKED_ID - Generated from CUSTOMER SEQ - see below
* EPL_LOADING_TYPE - Blank
* EPL_ORDER_TIME - defaulted to Now()
* EPL_TRAVEL_PLANNED - TRAVEL TIME TO NEXT CALL From previous job
* EPL_WORK_PLANNED - WORK TIME
* EPL_LAT - LATITUDE
* EPL_LONG - LONGITUDE
* EPL_LAST_CHANGED_DATE - Now
* EPL_LAST_CHANGED_TIME - Now

As per normal processing, a Customer should be created if one does not exist. A Job Address should be generated if the details of the address differ to that stored against the Customer Code, if one is found already stored.

'''Generating Time Windows'''

Time Windows should be generated for the job if there are non-zero values in the OPENING and CLOSING TIME fields in the incoming file. There are two sets of these values:
* OPENING TIME 1 and CLOSING TIME 1
* OPENING TIME 2 and CLOSING TIME 2
If non-zero values are found in these fields, an EPOD_TIME_WINDOW record should be created for each pair:

* ETW_SITE_ID - From the found Site ID
* ETW_TYPE - "J"
* ETW_FK_ID - EPL_JOB_ID from the found/created Job.
* ETW_TIME_START - OPENING TIME
* ETW_TIME_END - CLOSING TIME

{{Note}} This DAL object is created in ''SCR FS 336012 SCR-332569-3 GK PvA Add Time Windows''.

'''Generating Job Instructions'''

The Job Instructions is expected to be populated with ORDER SPECIAL DELIVERY INST (example "pls call 30m b4 del 07970884489 Kul"), and the concatenated weight and quantity (example "179 KILOGRAM, 6 D-RB, 33 W+S").

The weight and quantity will be taken from the following fields, if populated and having a non-zero value:
* DELIVERY PRODUCT 1 to DELIVERY_PRODUCT 12, using LABEL PRODUCT 1 to LABEL PRODUCT 12
The values will be concatenated with ", ".

For example:
{| border="1"
|- bgcolor="silver"
! No !! DELIVERY PRODUCT !! LABEL PRODUCT
|-
|1 ||179 ||KGS
|-
|2 ||2 ||TUBS
|-
|3 ||0 ||ETUB
|-
|4 ||0 ||D-RB
|-
|5 ||0 ||E-RB
|-
|6 ||6 ||CASE
|-
|7 ||0 ||S-LP
|-
|8 ||0 ||S-SP
|-
|9 ||0 ||C-LP
|-
|10 ||0 ||C-SP
|-
|11 ||0 ||W+S
|-
|12 ||2639 ||ITEM
|}

The weight and quantity string generated would be:
"179 KGS, 2 TUBS, 6 CASE, 2639 ITEM"

This will then be concatenated with the ORDER SPECIAL DELIVERY INST to for the job instructions. The final instructions stored in this example will be as follows:
"pls call 30m b4 del 07970884489 Kul 179 KGS, 2 TUBS, 6 CASE, 2639 ITEM"

'''Generating Linked IDs'''
Linked IDs are used to consolidate jobs at the same address together on the device. The DiPS interface provides enough information to achieve this.

For normal delivery jobs, the value should be generated as the value in CUSTOMER SEQ, multiplied by 10.

For Loading, Unloading or Break jobs, the value should be stored as the previous job's value in the Linked ID, plus 1.

==== Create Loading/Unloading Jobs ====

Loading and Unloading Job Types are populated almost identically to delivery jobs:
* EPL_SITE_ID - From the found Site ID
* EPL_LOAD_ID - From the found Load ID
* EPL_JOB_ID - Generated if not found
* EPL_JOB_CODE - As generated above
* EPL_JOB_TYPE - As generated above
* EPL_JOB_GROUP - "DEL".
* EPL_JOB_INSTRUCTION - Blank
* EPL_START_PLANNED_DATE - DEPARTURE DATE
* EPL_START_PLANNED_TIME - EAT AT CALL
* EPL_END_PLANNED_DATE - DEPARTURE DATE
* EPL_END_PLANNED_TIME - EDT AT CALL
* EPL_DISTANCE_PLANNED - TRAVEL DISTANCE TO NEXT CALL From previous job
* EPL_CUSTOMER_CODE - IDENT OF CALL OR DEPOT
* EPL_CUSTOMER_NAME - ADDRESS LINE 1
* EPL_ADDRESS_1 - ADDRESS LINE 2
* EPL_ADDRESS_5 - COUNTRY CODE
* EPL_POSTCODE - POSTCODE
* EPL_TELEPHONE - TELEPHONE NUMBER
* EPL_ORDER_DATE - defaulted to Now()
* EPL_SEQUENCE - LINK SEQ NO
* EPL_LINKED_ID - As generated above
* EPL_LOADING_TYPE - if first job, "L", else "U"
* EPL_ORDER_TIME - defaulted to Now()
* EPL_TRAVEL_PLANNED - TRAVEL TIME TO NEXT CALL From previous job
* EPL_WORK_PLANNED - WORK TIME
* EPL_LAT - LATITUDE
* EPL_LONG - LONGITUDE
* EPL_LAST_CHANGED_DATE - Now
* EPL_LAST_CHANGED_TIME - Now

==== Creating Break Jobs ====

For Break Jobs, the Job fields should be created as follows:
* EPL_SITE_ID - From the found Site ID
* EPL_LOAD_ID - From the found Load ID
* EPL_JOB_ID - Generated if not found
* EPL_JOB_CODE - As generated above
* EPL_JOB_TYPE - "D"
* EPL_JOB_GROUP - "OTHER"
* EPL_JOB_INSTRUCTION - ADDRESS LINE 1
* EPL_START_PLANNED_DATE - DEPARTURE DATE
* EPL_START_PLANNED_TIME - EAT AT CALL
* EPL_END_PLANNED_DATE - DEPARTURE DATE
* EPL_END_PLANNED_TIME - EDT AT CALL
* EPL_DISTANCE_PLANNED - TRAVEL DISTANCE TO NEXT CALL From previous job
* EPL_CUSTOMER_CODE - "BREAK"
* EPL_CUSTOMER_NAME - IDENT OF CALL OR DEPOT concatenated with CALLOVER SEQUENCE NUMBER
* EPL_ADDRESS_1 - IDENT OF CALL OR DEPOT concatenated with CALLOVER SEQUENCE NUMBER
* EPL_ADDRESS_5 - COUNTRY CODE
* EPL_POSTCODE - EPL_POSTCODE from previous job.
* EPL_ORDER_DATE - defaulted to Now()
* EPL_SEQUENCE - LINK SEQ NO
* EPL_LINKED_ID - As generated above
* EPL_LOADING_TYPE - Blank
* EPL_ORDER_TIME - defaulted to Now()
* EPL_TRAVEL_PLANNED - TRAVEL TIME TO NEXT CALL From previous job
* EPL_WORK_PLANNED - WORK TIME
* EPL_LAT - LATITUDE from previous job
* EPL_LONG - LONGITUDE from previous job
* EPL_LAST_CHANGED_DATE - Now
* EPL_LAST_CHANGED_TIME - Now

As per normal processing, a Customer should be created if one does not exist. A Job Address should be generated if the details of the address differ to that stored against the Customer Code, if one is found already stored.

As each break job will have a different address to the standard BREAK customer address, a specific Job Address should be created for each Break job, storing:
* EPL_CUSTOMER_CODE - "BREAK"
* EPL_NAME - IDENT OF CALL OR DEPOT concatenated with CALLOVER SEQUENCE NUMBER
* EPL_ADDRESS_1 - IDENT OF CALL OR DEPOT concatenated with CALLOVER SEQUENCE NUMBER
* EPL_POSTCODE - EPL_POSTCODE from previous job
* EPL_LAT - LATITUDE from previous job
* EPL_LONG - LONGITUDE from previous job

=== Post Job Processing ===

When a job is created, the following items should be stored for potential use on the next job created:
* EPL_LOAD_ID - From the found Load ID
* EPL_DISTANCE_PLANNED - TRAVEL DISTANCE TO NEXT CALL
* EPL_TRAVEL_PLANNED - TRAVEL TIME TO NEXT CALL
* EPL_LAT - LATITUDE
* EPL_LONG - LONGITUDE
* EPL_START_PLANNED_TIME - EAT AT CALL - if earlier than the stored value
* EPL_END_PLANNED_DATE - DEPARTURE DATE - if earlier than the stored value
* EPL_END_PLANNED_TIME - EDT AT CALL - if earlier than the stored value
* EPL_LINKED_ID - as generated from CUSTOMER SEQ above.
* EPL_POSTCODE - as set on this job.

A list of all Loads and Jobs processed in the file should be stored as each job is processed. This should store the Load IDs and Job IDs of the jobs created or updated.

A list of all start planned dates in the file should be stored as each load is processed.

=== Post Load Processing ===

When all jobs on a load have been processed, the process should loop through all jobs on that load that are not in the list of jobs processed. If any are found, these and all child records should be deleted. That is:
* EPOD_JOB
* EPOD_CONTAINER
* EPOD_PRODUCT
* EPOD_JOB_ADDRESS
* EPOD_TIME_WINDOW

The Load should only be updated at this time if the load being processed is different to the previous load processed in this run, or when no further records are pin the file being processed.
* EPL_LOAD_START_PLANNED_TIME - Earliest start planned time of jobs on this load
* EPL_LOAD_END_PLANNED_DATE TRUE - Latest start planned date of jobs on this load
* EPL_LOAD_END_PLANNED_TIME TRUE - Latest start planned time of jobs on this load
* EPL_LAST_CHANGED_DATE - Now
* EPL_LAST_CHANGED_TIME - Now

{{Note}} The new change ''FS 336013 SCR-332569-4 GK PvA Automatically Set Loads In Progress'' details changes required to automatically set loads in progress when they are the earliest load for that vehicle. These changes must be implemented at this stage.

All previously stored values should be reset when the Load changes.

=== Post File Processing ===
Once all loads in the file are processed, all loads for the processed start planned dates should be retrieved, where the loads are not in the list of loads processed by this run. If any are found, these and all child records should be deleted. That is:
* EPOD_LOAD
* EPOD_JOB
* EPOD_PRODUCT
* EPOD_CONTAINER
* EPOD_JOB_ADDRESS
* EPOD_TIME_WINDOW



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the DIPS-EPOD interface
|MenuAccess=N/A
|Prerequisites=N/A
|Objective=To test that: the interface can be created through Admin and; the interface creates and amends jobs correctly.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin tests
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new DIPS interface in the XF Config screen
|Result=All fields are enter-able as described here. The new interface is created.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface tests
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new DIPS interface file as follows:
* At least 2 Loads, for different unknown vehicles and drivers.
* Multiple Jobs for each load, including a Depot Load and Unload job at the start and end
* At least one break per load.
* Multiple Deliverable Items and labels
* Some with job windows.
Upload the file.
|Result=All Loads are created. All Delivery Jobs are created correctly. All Windows are created correctly. All Customers are created. All Breaks are created. All Vehicles are created. All Load/Unload jobs are created correctly. The jobs are marked as In Progress and WEBFLEET orders are created.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new DIPS interface file similar to the first, with the following differences:
* All loads except 1 from the previous file.
* All jobs for the other loads bar 1 from the previous file.
* 1 Load and 1 Job with all details slightly changed.
* 1 new load, with the same vehicle as the previous file, but at an earlier date/time. The user should be very similar to a previous user, in that 1st letter of the first name and the surname are identical e.g. John Jones and Jack Jones.
|Result=The new Load and all jobs are created as before. All existing loads and jobs from before are updated. The new user will be created with a single-digit '1' after the user id. Any loads or jobs not included in the file are deleted, including all children.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new DIPS interface file similar to the second, with the following differences:
* Add 1 extra break into 1 load, in the middle, changing the link number on all following jobs.
* Add an additional Unload at Depot in the middle of another load, changing the link number on all following jobs.
|Result=Additional jobs should be created for the new Unload and Break jobs created. Break and Unload Job IDs should change based on the sequence (link number) of the job in the load. Prior Loading/Unloading/Break jobs should be deleted.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=FS 336012 SCR-332569-3 GK PvA Add Time Windows
|RefV1=1.0
|RefDate1=16/06/2016
|Ref2=EPOD Import Mapping
|RefV2=5.1.2
|RefDate2=17/06/2016
|Ref3=EPOD Export Mapping
|RefV3=5.1.2
|RefDate3=17/06/2016
|Ref4=FS 336013 SCR-332569-4 GK PvA Automatically Set Loads In Progress
|RefV4=1.0
|RefDate4=16/06/2016
|REQ=0
|EST=0
|FS=1.5
|TS=1.5
|DEV=6.75
|ST=1.25
|IMP=0
|PM=0.5
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Rob Carter
|Rev1Title=Greene King Representative
|Rev2=Matt Tipping
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

EST 336598 Zenith Back Orders

2016-07-13T13:48:10Z

Tippingm: v1.0 - Review and Issue

{{Estimate_Head
|Client=ZEN
|Project=DEV
|Site=WHG
|ClientRef=N/A
|OBSRef=336598
|Version=1.0
|Author=A N Walker
|PONum= 
|Priority=3
|Date=13/07/2016
|Customer=N/A
|SysVer=3.X
|ClientRequest='''Requirement 1:'''

Back-order lines must be displayed on the POD note.

'''Requirement 2:'''

It is not always clear whether a product was not despatched or not delivered using the current POD format. This will be changed to display the Ordered, Despatched and Delivered quantities.

|Solution={{Note}} All changes to the POD will be made to both the Priced and Unpriced formats.

'''Requirement 1:'''

Sage currently handles this requirement by adding product lines to an order, containing the free text describing the back order status.

Sage will pass through additional product lines that have various levels of information
* Product Code - set if this is a back-order line for the product
* Description - the quantity back-ordered or the back-order reference, for example "Fully Back-Ordered for 1", "** Back-order to follow : XXXXXXX/1 **"
* Status - set to "C" - Complete.
* Sequence - This will be set as the same sequence as the line to which it pertains (for back ordered quantities) or 9000, plus 1 for each new back order reference line, e.g. 9001, 9002, etc.

The Inbound webservice will be changed to allow the user to set a line to completed status - this will ensure that these lines are never prompted for the driver to deliver. The change to the webservice format (XSD) will be passed through to the Sage team for modification after sign-off of this change.

All product lines on the POD will be ordered by Sequence, ensuring that the new lines will always appear at the end. The sequence should ensure that the line displaying the ordered, despatched and delivered quantity appears first, then the line for the back-ordered qty. Any back-order references should appear at the end after all product and back-order lines.

'''Requirement 2:'''

Sage will pass through the Ordered values for each product line.

A "QTY DESP" column will be added after the existing column "QTY ORD". This will be populated from the planned quantities.

The existing "QTY ORD" column will be changed so that this is populated from the Ordered quantities.

The changes for both requirements will result with c change to the product table on the POD form as per the following example:

<table border="1px">
<tr>
<td bgcolor="silver">'''PRODUCT CODE'''</td>
<td bgcolor="silver">'''PRODUCT DESCRIPTION'''</td>
<td bgcolor="silver">'''QTY ORD'''</td>
<td bgcolor="silver">'''QTY DESP'''</td>
<td bgcolor="silver">'''QTY DEL'''</td>
</tr><tr>
<td>WG 011000 </td><td> HARD WATER M/C DETERGENT </td><td> 1 </td><td> 1 </td><td> 1
</td></tr><tr>
<td>WG 100900 </td><td> ULTRA FLOOR CLEANER </td><td> 6 </td><td> 4 </td><td> 3
</td></tr><tr>
<td>WG 100900 </td><td> Fully Back-ordered for 2 </td><td> 0 </td><td> 0 </td><td> 0
</td></tr><tr>
<td>WG 020500 </td><td> PEBBLE SALT </td><td> 1 </td><td> 1 </td><td> 1
</td></tr><tr>
<td>WG 121700S </td><td> CLOTHS ALL PURPOSE BLUE </td><td> 1 </td><td> 1 </td><td> 1
</td></tr><tr>
<td>190700 </td><td> WINDOW SQUEEGEE 14" WITH HANDLE </td><td> 1 </td><td> 0 </td><td> 0
</td></tr><tr>
<td>190700 </td><td> Fully Back-ordered for 1 </td><td> 0 </td><td> 0 </td><td> 0
</td></tr><tr>
<td></td><td> ** Back-order to follow : XXXXXXX/1 ** </td><td> 0 </td><td> 0 </td><td> 0
</td></tr></table>

All other elements of the POD reports, including all other elements on the Product table, will remain unchanged.

}}

{{EstimateCostDetails
|REQ=0
|EST=0.0
|FS=0.5
|TS=0.75
|DEV=2.25
|ST=0.5
|IMP=0.25
|PM=0.25
|Client=ZEN
|Year=2016
|FOC=N
|NOFOOTER=Y
}}

<table width="100%">
<tr><td align="center">
Copyright © OBS Logistics 2016. 
This estimate has an expiry date of 30 days from the specified Estimate Date. 
The information contained herein is supplied without liability for errors or omissions.
</td></tr></table>
[[Category:ZEN EST]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T14:04:10Z

Tippingm: v2.0 - Issue to Zenith Hygiene

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|2.00}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

==''' SCR-5-330814: Timer to prevent vehicle check completion''' ==
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

== '''SCR-330814-7 Postpone Job with Reason Code''' ==
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

==''' SCR-330814-13: Re-key Email/Contact/Tel at Signature''' ==
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

== '''SCR-330814-2: Customer Tracking Gateway''' ==
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

== '''Out Of Scope SCR List''' ==
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T14:02:02Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

==''' SCR-5-330814: Timer to prevent vehicle check completion''' ==
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

== '''SCR-330814-7 Postpone Job with Reason Code''' ==
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

==''' SCR-330814-13: Re-key Email/Contact/Tel at Signature''' ==
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

== '''SCR-330814-2: Customer Tracking Gateway''' ==
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

== '''Out Of Scope SCR List''' ==
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:57:54Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

== '''Out Of Scope SCR List''' ==
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:55:51Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:54:06Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=
John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:48:41Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope Requirements =


The following changes are out of scope and can be reinstated at a later date at additional cost

===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:43:11Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=John Hitchmough
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:41:22Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


===SCR-5-330814: Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

===SCR-330814-7 Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===SCR-330814-13: Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

==SCR-330814-14 Allow Admin to set a load in progress ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

===SCR-330814-2: Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:24:19Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith requirement to upload paper POD documents from couriers into the system, these are to be displayed on the Portal in the same way as the ePOD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


=== Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Timer to prevent Vehicle Check Completion.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Postpone Job with Reason Code.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Re-key Email/Contact/Tel at Signature.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:13:06Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith optional requirement to upload further documents pertaining to orders (for example, an invoice document and backing sheet) into the system, to be displayed on the Portal in the same way as the POD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


=== Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Timer to prevent Vehicle Check Completion.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Postpone Job with Reason Code.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Re-key Email/Contact/Tel at Signature.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T13:06:29Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes are out of scope for this project:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

Further details of these requirements are in Appendix A. These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* Consolidate or Deconsolidate groups of jobs

The system can be configured to give the drivers the 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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. If enabled, the cancellation option will also show Postponement reason codes, clearly labelled as such in the drop-down list of reasons. As before, in the case that a postponement reason code is selected rather than a cancellation reason code, the driver will be allowed to optionally enter a comment, and the option to take an image will be removed. If confirmed, the postponed job will not be removed from the list, but will instead be marked as Postponed - see later for more information on Postpone Jobs.
Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith optional requirement to upload further documents pertaining to orders (for example, an invoice document and backing sheet) into the system, to be displayed on the Portal in the same way as the POD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


=== Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Timer to prevent Vehicle Check Completion.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Postpone Job with Reason Code.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Re-key Email/Contact/Tel at Signature.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T12:55:16Z

Tippingm:

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes may be out of scope of or not essential to this project, as follows:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

When this information configured on the Order or Trip Creation event, this will trigger the email.

Sample email:
From: Orders@Zenith.co.uk
Subject: Your Zenith Order X123 is in progress
Body:
Jack Jones,
Your order will arrive on 27/04/16
If you have any issues, please contact the Zenith team on …

Yours,
The Zenith Delivery Team

Note: This is an unmonitored email account - please do not reply to this email.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens. {{Note}} If enabled, Postponement reason codes may be maintained through the Reason Codes maintenance screen an uploaded through templates.

If required and enabled, Postponement Reason Codes will be shown in the Jobs maintenance screen detail pop-up. {{Note}} This is optional and may not be required.

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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. If enabled, the cancellation option will also show Postponement reason codes, clearly labelled as such in the drop-down list of reasons. As before, in the case that a postponement reason code is selected rather than a cancellation reason code, the driver will be allowed to optionally enter a comment, and the option to take an image will be removed. If confirmed, the postponed job will not be removed from the list, but will instead be marked as Postponed - see later for more information on Postpone Jobs.
Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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 ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith optional requirement to upload further documents pertaining to orders (for example, an invoice document and backing sheet) into the system, to be displayed on the Portal in the same way as the POD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


=== Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Timer to prevent Vehicle Check Completion.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Postpone Job with Reason Code.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Re-key Email/Contact/Tel at Signature.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 330814 Zenith ePOD Requirements

2016-04-27T12:53:39Z

Tippingm: v1.1 - Update following customer meeting

<div class="noprint">
{{#vardefine:Client|ZEN}}
{{#vardefine:ClientName|Zenith Hygiene}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|''CALIDUS'' ePOD/TTM Solution Design}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|27th April 2016}}
{{#vardefine:Reference|330814}}
{{#vardefine:Year|2016}}
</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}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, on 14/10/2015 at the Zenith Hygiene office.



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


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

{{Warning}} The following changes may be out of scope of or not essential to this project, as follows:
* SCR-330814-8: Multiple Time Windows
* SCR-330814-5: Timer to prevent Vehicle Check Completion
* SCR-330814-7: Postpone Job with Reason Code
* SCR-330814-13: Re-key Email/Contact/Tel at signature
* SCR-330814-14: Allow Admin to set a load in progress

These may be reinstated at a later date at additional cost.

There is some question as the number of products being advised on a jobs for this contract. ''CALIDUS'' ePOD has been tested and sized based on the following standard loads:
* Load 1 (600 products, 50 totes or loose, 40 jobs):
** 20 jobs with no totes, 5 loose products
** 10 jobs with 1 tote of 30 products, no loose products
** 10 jobs with 2 totes of 10 products, no loose products
* Load 2 (500 products, 30 totes or loose, 11 jobs):
** 1 (opening) job with 20 totes of 20 products, no loose products
** 5 jobs with no totes, 10 loose products
** 5 jobs with 1 tote of 10 products, no loose products
The jobs above represent the number of jobs and products that may be required for jobs, in line with the sizings provided by Zenith Hygiene on 9-16 Dec.

{{Note}} There are tramping deliveries over 2 and 3 days will be created for some depots, although it has been confirmed that the total volumes (of jobs, totes and products) will be similar to those sample details already provided.

Results of processing these loads are as follows:
* Load 1 request took 0:42, auto update with no changes 0:02, auto update with changes to everything took 0:40.
* Load 2 request took 0:31, auto update with no changes 0:01, auto update with changes to everything took 0:31.
Based on this sizing, and with modifications to the standard software (specified elsewhere in this document), the system is capable and reactive to the user with no reported issues.

Due to the high volume of data being sent to the device, the automatic load updater will be slow. While this is updating data (from the Job List and Details screens), the application will delay in responding to user touches. An indicator will show when this update is occurring to prevent non-responsiveness of the application.

If these speeds or recommendations are not acceptable, further modifications to the software may be required at additional cost.

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed. If this is not acceptable, further modifications to the software or design may be required at additional cost.

For crew members swapping jobs with a driver, the device will by standard request Load Start/End Metrics if configured to do so. There is no option to configure these drivers to be allowed to skip these metrics. If this is required, a further change may be required at additional cost.

For crew members swapping jobs with a driver, the device will request vehicle defect checks be completed if configured for the vehicle. It is recommended that a 'CREW' vehicle be used with checks configured with no questions, and the crew members encouraged to use this in lieu of the specific vehicle. The lead driver should still use the specific vehicle when logging on.

''CALIDUS'' VEhub (for defect checks and other functionality) is not included in this solution design.

{{ #vardefine: SCR | 0 }}


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



== Operational Overview ==
Zenith Hygiene are the UK's largest independent manufacturer and supplier of cleaning and hygiene chemicals and ancillary products.

General information gathered from sales meetings:
* The Primary tracking reference for Zenith is the delivery note number.
* There are potentially 500 items on one order.
* UAT scheduled for January.
* The implementation roll-out will be depot by depot.
* Zenith have their own internal IT team and will develop their interface to map to the EPOD format.
* Orders are generally 2 types:
** Opening Orders - full stocking of a premises, up to 500 products, predominantly in totes and pallets, with some loose product.
** Standard deliveries to a premises, predominantly in totes, with some loose product.
* The maximum number of drops per day per driver run can be 50-60.
* There will be a maximum of 500-600 products on a driver's run.
* There are an average of 25 totes per vehicle, plus a loose products bin and pallets to pick from (for high-volume products).
* Accurate figures regarding certain run types have been provided, as well as a week's data from Welham Green depot.

Devices
* Android operating system.
* There is a very high level of scans, so an integrated barcode scanner must be available on the hardware.
* OBSL are to ensure that the devices are provided with cradles and include this in the cost of the hardware. Cradles are required in the warehouse and vehicles.
* Devices to be decided in November. {{Warning}} Matt Turner to advise in SDD what hardware to buy and when it must be ordered by.
* There are currently internal questions from Zenith as to where the labels and barcodes will be generated.

== General System Overview ==
The core systems are Sage and DPS, with OBS Logistics' systems providing execution ({{#var:System}}) and order tracking (''CALIDUS'' Portal).
* Orders come into Sage.
* Orders are grouped by depot (Welham Green, Droitwich, etc) and type (P - Pallets, B - Bulk, W - Mixed) for picking purposes.
* Sage interfaces the orders to DPS, for Routing purposes, then back to Sage.
* Orders are picked in several ways according to the routes created, and the type of deliveries:
** Into totes - this is the most normal delivery mechanism, usually for smaller products
** As loose products, placed on the vehicle in the loose products bin. Also very common. Jobs (indeed an entire route) can be entirely bulk delivered, either as loose products or palletised.
** Line picked onto pallets, for large volume or size products, picked by the driver at the delivery point.
** Bulk pallets, for large bulk deliveries. These are treated as loose products delivery, where the product is scanned.
** Bulk pallets, for onward delivery to DHL. These would be treated as Tote delivery, where the container only is scanned.
* 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.

== Data Import ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

All jobs of any type 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/Customer Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.
The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics.

It is expected that there will need to be at least three Job Group configurations:
* Normal Deliveries with Pricing
* Normal Deliveries without Pricing
* Opening Deliveries with Pricing
* Opening Deliveries without Pricing
* Collections
{{Note}} Collections may not require a different Job Group, depending on the functionality required.

{{Note}} Jobs without Pricing may be sent with 0 cost per unit, which will then display as 0 on the POD note - if this is acceptable, this means that fewer job groups need to be created and maintained.

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.

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 Delivery job include:
* Route ID will be sent through as the driver and a batch number or Drivers name and Date to keep the Load ID within ''CALIDUS'' ePOD unique.
* Driver and Vehicle resource information.
* Job References, such as Delivery Number (which will be the unique job reference) and Purchase Order Number
* TM (Territory Manager) - sent as the Sales Contact
* Customer Details:
** Account Number
** 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).
** Email addresses are required for the customers requesting POD notes to be immediately emailed to them upon confirmation of collection or delivery.
* Consolidation - When delivering orders, there could be multiple deliveries per address. 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.
* Container (Pallet and Tote) information to include:
** Container (Pallet or Tote) ID - unique for the job
** An indication as to whether this container requires contained product scanning (in addition to container-only scanning)
* Product Information to include:
** Product Code - the Sage product code
** Product Description - These are 40 characters within {{#var:System}} - this is consistent with the length supported by Sage.
** Product quantities regarding Ordered and Planned Delivered quantities are required.
** VAT Code
** Unit Price - May be zero for items that require no pricing on the POD note.
** Weight
** Alternate Barcode Identifiers - within the Long Description field

There is a requirement to display the total weight and unique products on the Job List and Job Details screen (shown as a change in the Job List section below). Calculating the total weight and total unique products for a job is a task that will affect the performance of the display of the job list. Due to the high volume of data being sent through (in numbers of jobs, containers and products), this will lead to the performance of the display of the job list being hampered if calculated on the device, and must therefore be calculated in the server or received from Sage. The development required for either solution is the same, and the calculated values per job will be passed to the device for display.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.



{{Note}} OBS Logistics have created standard Interfacing documentation and this will be passed to the Sage development team. At this time, no mapping exercise has started. Any modifications of the interface within {{#var:System}}, will fall 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}} It is expected that the standing data will not be transferred through from Sage to {{#var:System}}. It will be a manual process to keep both systems in line. At a later data Zenith may perform development to send standing data to {{#var:System}}. There are internal questions within Zenith regarding the high turnover of drivers due to agency workers.

{{Note}} Routes (Loads) must be allocated to a driver and/or vehicle for them to be picked up by the devices. If this cannot be achieved by Sage or any routing systems attached to it, then the {{#var:System}} Admin system (Load or User screens) may be used to manually allocate drivers to loads.

Once Order and Trip information is received into {{#var:System}}, ''CALIDUS'' Portal TTM (the Track and Trace module) will be kept up to date with tracking events.

A requirement is to send an email to the customer on receipt of the original order information, ''CALIDUS'' Portal TTM will initiate this email to the email address associated to the job's address.

Details of the configuration of this are shown in section [[#Track and Trace|Track and Trace]] later in this document.

When this information configured on the Order or Trip Creation event, this will trigger the email.

Sample email:
From: Orders@Zenith.co.uk
Subject: Your Zenith Order X123 is in progress
Body:
Jack Jones,
Your order will arrive on 27/04/16
If you have any issues, please contact the Zenith team on …

Yours,
The Zenith Delivery Team

Note: This is an unmonitored email account - please do not reply to this email.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Customer Tracking Email.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== 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]]
 ''Assigning a User to Loads'' 

[[file:EPOD_Load2.PNG|border|600px]]
[[file:EPOD_Load3.PNG|border|600px]]
 ''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.

Standing Data (i.e. Vehicles, Reason Codes, Users) may be uploaded in mass through the appropriate maintenance screens - XLS templates may be downloaded from the screens. {{Note}} If enabled, Postponement reason codes may be maintained through the Reason Codes maintenance screen an uploaded through templates.

If required and enabled, Postponement Reason Codes will be shown in the Jobs maintenance screen detail pop-up. {{Note}} This is optional and may not be required.

A full guide to the use of the system can be found referenced in [[#Appendix A: Table of SCRs and Ballpark Estimates|Appendix A]].

The POD note format requires Pricing and VAT information for some customers. This will require some Admin changes to support this.
* A new VAT Rates maintenance screen.
* The Product/Container screen must be modified to allow entry of Unit Price and VAT Rate
* The Job Group Maintenance screen must be modified to allow maintenance of a flag to control whether pricing information is used for jobs in this group.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Pricing.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== PDA Login ==
The application will have a customised style created for Zenith Hygiene, which will include:
* A blue colour scheme
* The logo on the login page.
* A larger quantity and appropriate level of information on the Product list
{{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
}}

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Login1.png|''Login''
</gallery> 

Additionally, the layout of certain tables 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 and vehicles, 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 entering their provided user name and password and selecting the vehicle from a drop-down list. 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 configurable, from the {{#var:System}} Admin system.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_VehicleChecks3.png|''Vehicle Checks Sample''
File:REQ_330814_PDA_VehicleChecks4.png|''Sample 2''
File:REQ_330814_PDA_VehicleChecks5.png|''Sample 3''
</gallery> 
Vehicle checks will be based on the information already provided and will include:
* Fuel Tank Level - a drop-down list of options, requiring selection of 1/4, 1/3, 3/4 or Full
* First Aid Kit
* Tyres
* Lights
* Oil
* Water
* Windows
* Mirrors
* COSHH Manual
* Vehicle Defects - a text entry box

All questions (except Fuel Tank Level and Vehicle Defects) are expected to be required entry, check-box only, to allow the user to confirm that the checks have taken place. Fuel Tank level will be required entry of a drop-down list. Vehicle Defects will be an optional entry of free text.

{{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. It is also possible to have specific vehicle checks for specific vehicle types, and it is recommended that this is done for a 'CREW' vehicle, used for crew members when swapping jobs.

== 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. If the driver has no assigned load, but is sharing work from another driver, an option to Swap Jobs is available here - see section [[#Job Swap|Job Swap]] later for details.

Once a Load has been downloaded to the device, the device can optionally request entry of Metrics at this time. It is expected that this would contain the following checks:
* ODO - Required numeric entry
* Load Secure Visual Check
* Sack Barrow on Vehicle
All checks are expected to be required entry, and all except ODO will be check-box only. ODO will be a numeric entry. Load Metrics must be completed before the trip may be started.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadStart2.png|''Load Metrics''
</gallery> 

Once the metrics are complete (or if there are no metrics configured), the device will display the details of the load in a Job List.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobList1.png|''Job List''
</gallery> 

The list of the jobs on this load will show the following:
* 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 - Bold
* Planned Date/Time

This list will be modified to display the total weight of all the products, and the count of unique products on the job or jobs.
{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Display Total Weight/Unique Products.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

This information will be sent to the device from the server - it will not be calculated on the device.

{{Note}} Consolidated jobs will display the total unique products per consolidation as the sum of the total unique products on the consolidated jobs, which may lead to higher figures than should be displayed.

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 - the device will display the ''Job Details'' screen.

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/Work-list
* 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 will be allowed with a warning, as the drivers will be able to choose whether to start a job based on the weight and total unique products on that delivery.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if quantities have been amended or products have been added/removed. This can also be triggered by long-pressing against the label showing the load identifier on the screen.

It has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD. Further, if a customer calls to cancel or amend an order whilst the vehicle is en route to the delivery, the driver will be informed through call or text to their device, and will then cancel or amend the job through the application. Given that the load may be refreshed manually at any time, and that the reallocation of vehicles or drivers is mostly reactive and manual, the automatic refresh of the load whilst en route will be configured to be disabled on the device.

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.

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 - this is expected to be the case for the appropriate jobs received from Sage.
{{Note}} This functionality can be disabled if not required.

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

The driver also has access to several functions to deconsolidate consolidated groups of jobs:
* Singly, by selecting the job to split out, through the ''Deconsolidate'' menu option.
* Breaking the entire group back to single jobs, through the ''Break Group'' option accessed when long-pressing against a consolidated group.
{{Note}} This functionality can be disabled if not required.

== Job Swap ==
Drivers go out in pairs and spread the work between them. This cannot be planned by Sage. To achieve this, {{#var:System}} provides Job Swap functionality in several different ways.

{{Note}} Job Swap functionality requires a data connection - it cannot be completed off-line.

It is expected that the drivers and crew in the morning in the depot before departure - this is to ensure that there is no issue with data connectivity whilst out on the road.

A user who has not been provided a Load can swap jobs from another driver's load - in this case, a new load will be created for the driver.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap1.png|''Job Swap - No Load''
File:REQ_330814_PDA_JobSwap2.png|''Job Swap - Enter Swap Load''
</gallery> 

A user that has been provided a load can still swap jobs - this is available from the menu on the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap6.png|''Job Swap menu from Job List''
</gallery> 

The user will then be prompted to enter the Load from which the jobs are being swapped, as above.

The device will display a list of jobs from the indicated load.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap3.png|''Job Swap List''
</gallery> 

The user can select the jobs to be swapped, or can scan a container (Pallet or Tote) to select the job delivering that container.

Once all jobs have been selected for swapping, the user will click '''Swap Jobs'''. This will copy the jobs from one load to the other. For Delivery jobs, this will create a Collection jobs on the driver's load. These must be completed as normal collections to indicate that all the items have been swapped correctly.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobSwap4.png|''Job List showing new jobs''
File:REQ_330814_PDA_JobSwap5.png|''Job confirming swap''
</gallery> 

The two loads will be updated in the Admin system to show that the jobs have been swapped.

Swapped jobs (deliveries or collections) will be completed as normal jobs, as shown in the following sections.

When a new load is created for a crew member for the swapped jobs, the device will also create a Return to Depot job - this is created to keep the load open for more potential swaps later in the trip. This may be completed after all jobs on the load are complete.

When a new load is created for a crew member for the swapped jobs, the device will require entry of load start metrics, if configured for the operation. Additionally, when the swap load is complete, Load End metrics will be requested if configured. If this is required to be removed for Job Swap loads, this will require further development at additional cost. This has not been specified in this document.

When a crew member logs onto the application, if they choose a vehicle they will be prompted for vehicle checks. This can be disabled by creating a 'CREW' vehicle on {{#var:System}}. This will be configured to require no vehicle defect checks. The crew members should be encouraged to use this vehicle for job swapping.

== 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_330814_PDA_JobDetail1.png|''Job Details - Address and Contact''
File:REQ_330814_PDA_JobDetail2.png|''Instructions''
</gallery> 

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.

This Instructions tab will be modified to display the total weight of all the products, and the count of unique products on the job or jobs. {{Note}} This is classified as part of the changes specified to the Job List above.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_JobDetail3.png|''Total Weight/Unique Products display''
</gallery> 

If the jobs are consolidated, the total weight/unique products for each job will be displayed.

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

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.

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

When clicking this button to start or arrive at the job, the application normally performs a check whether the job has been changed since it was loaded on the device. As it has been confirmed that there will never be modifications of a load after it has been loaded and interfaced to ''CALIDUS'' ePOD, this check will be configured to be disabled on the device.

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. If enabled, the cancellation option will also show Postponement reason codes, clearly labelled as such in the drop-down list of reasons. As before, in the case that a postponement reason code is selected rather than a cancellation reason code, the driver will be allowed to optionally enter a comment, and the option to take an image will be removed. If confirmed, the postponed job will not be removed from the list, but will instead be marked as Postponed - see later for more information on Postpone Jobs.
Note that, if enabled, Postponed jobs will not prevent starting a job later in the sequence than the postponed job, nor will it prevent a postponed job being started at any time after postponement.

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 to the Delivery or Collection process, depending on the job type.

== Standard Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery can consist of a Tote with multiple products (with only the tote needing to be scanned), a bulk pallet of a product line, which will be scanned by product and confirmed line by line, and also loose products in a bin on the vehicle, which will also be scanned individually.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Delivery1.png|''Job Details Tab''
File:REQ_330814_PDA_Delivery2.png|''Containers Tab''
File:REQ_330814_PDA_Delivery3.png|''Products Tab''
</gallery> 
{{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 ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs, as well as a 'Loose Products' entry on this list, to access scanning of the loose products.

The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery. The 'Loose Products' container will only be displayed if there are loose products as part of the delivery.

The Container list may show the following items per line:
* Container ID
* Type
* Status
* Total Products
* Code 1 (a multi-purpose code)
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. At this time, it is expected that the following will be displayed:
* Container ID
* Type
* Status

If this is a consolidated job, the list will show all containers required to be delivered on all jobs - containers will only appear once, no matter how many jobs have products in that container. The list will also display the customer code and the number of consignments in this container.

Each container 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 container ID manually and clicking '''Deliver'''
* scanning the container ID
When marked as delivered, the item will be removed from the list.

{{Note}} The system will be configured so that, regardless of whether a pallet or tote contains products, the device will mark all as delivered when the container is confirmed delivered - the user will not be given the option to scan the products in a container.

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

For Loose Products, clicking on the item in the container list will immediately display the ''Products'' tab, which will display a list of the loose products (i.e. not on a pallet or tote) to be delivered, 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.

{{Note}} There is some concern that the quantity of products on a job (estimated as 500) will make the application unstable, due to the memory requirements of building a large Product list. A change to the {{#var:System}} will be required to handle this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Amendments to handle large numbers of 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 X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
When marked as delivered, the item will be removed from the list.

For Zenith, each product could come from multiple manufacturers and, as such, could have multiple unique barcodes that identify the product. Products can also have multiple EAN barcodes, although it is confirmed that the products are only sold by inner UOM and therefore should only be that barcode to be scanned. Furthermore, some products (liquid cleaning) have been labelled with Zenith barcodes. It should be noted that the Sage Product code must also be visible on the device. ''CALIDUS'' ePOD must be modified to allow the receipt of multiple alternate identifying barcodes with the products, and use those to identify the products when scanned on the device.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Scanning of alternate Product Barcodes.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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.

Zenith pick to pallet. The pallet can contain multiple SKUs for multiple customers and drops. The driver will break the product down on the vehicle and then deliver the quantity of the specific products to the customer.

The application will be modified to identify these bulk pallets. When scanned or selected from the Containers list, the application will not immediately mark them as delivered, but will instead list all the products required to be picked from the bulk pallet, similarly to the Loose Products container process shown above.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Identify Pallets that require Product Scanning.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

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

== Opening Delivery Process ==
Both container and loose product delivery is required within the same job. The delivery will consist of Pallets or Totes with multiple products (with products requiring to be scanned) and also loose products, which will be scanned individually.

The screens will look as per a normal delivery.

From the ''Containers'' tab, the device will show a list of the pallets or totes that are to be delivered on these jobs.

{{Note}} The ''Containers'' tab will only be displayed if there are Pallets or Totes as part of the delivery.

The Container list will be displayed with the same information as a normal delivery.

If there are also loose products to deliver, a Loose Products container will be displayed in the same way.

Each container on the list can be confirmed as delivered by the same mechanism as a normal delivery, as follows:
* 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 container ID manually and clicking '''Deliver'''
* scanning the container ID

When selected in this way, the device will display the products within this pallet or tote only. The products list will display the same level of information as Loose Products on a normal delivery.

Products within the container will then be scanned and marked as delivered in the same way that loose products can be scanned on a normal delivery.

When all products within a container are marked as complete (delivered or cancelled), the device will redisplay the Containers tab and will remove the completed container from the list

If a container 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, the user will have the facility to take a photo against the cancelled container, but this is optional.

Loose Products may be delivered as in a normal delivery, clicking on the Loose Products entry in the container list. The products list will display the same level of information as Loose Products on a normal delivery.

Each product on the list can be confirmed as delivered in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Deliver X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Deliver X'' from the pop-up menu.
* scanning the product code and clicking ''Deliver X'' from the pop-up menu.
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 in the same way as a normal delivery.

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 containers and products have been confirmed as delivered or cancelled, the Delivery process will close and the user will be directed to the Job Completion process.

==Collection Process==

Collection jobs will be sent as part of the route with the delivery jobs. These will be marked as collection jobs by the interface from Sage.

{{Note}} Full details have not been received on the collection process other than:
* Collections jobs are created solely for the return of product from a customer
* They feature Loose Product collection only.
This must be confirmed and/or further details provided by Zenith, otherwise the following process will apply.

The screens will look similar to a delivery job, with the general exception that the screen displays 'Collection' instead.

As collection jobs do not have any containers (pallets or totes) but only loose products, the container tab will not be shown.

Loose Products may be collected as in a normal delivery - the products list will display the same level of information as Loose Products as on a normal delivery.

Each product on the list can be confirmed as collected in the same manner as a normal delivery, as follows:
* long-clicking on the item in the list and choosing ''Collect X'' from the pop-up menu. {{Note}} This option can be removed by configuration if not required.
* entering the product code manually and clicking ''Collect X'' from the pop-up menu.
* scanning the product code and clicking ''Collect X'' from the pop-up menu.
When marked as collected, the item will be removed from the list.

The driver can change the quantity by choosing ''Change Quantity'' from the pop-up menu in the same way as a normal delivery.

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 containers and products have been confirmed as collected or cancelled, the Collection process will close and the user will be directed to the Job Completion process.



== Amending Jobs ==
Some customers check the products within the tote, and others do not. Zenith cannot advise ''CALIDUS'' ePOD electronically of which ones are which, as it can depend on whether a manager is on the premises at the time of delivery. So, on occasion, a customer will not check and at other times they will. The solution must cater for tote scanning without scanning products contained within it (as shown above) and confirmation of individual products where required.

So, the customer may request a change in what was delivered after scanning all items for delivery, or to refuse delivery of:
* All products in a tote
* All or some loose products
* All or some of an individual loose product
* All or some of an individual product in a tote or pallet

If the system is configured for amendment after job completion, once all items are confirmed, the screens will redisplay all containers (totes, pallets) and loose products on the screen, indicating a status (Complete, cancelled, etc) and coloured appropriately (cancelled in red, amended in amber, fully complete in green). The driver will be able to modify the quantity against a product in several ways:
* For loose products, select the Loose Product Container, then the product from the Products tab, then selecting the action required from the pop-up menu.
* For products within a tote or pallet, selecting the container on the list, then selecting Products from the pop-up action menu, then selecting the product from the Products tab, then selecting the action required from the pop-up menu.
* For cancelling a whole tote or pallet, select the container, then select Cancel from the pop-up actions menu.
* For delivering a whole tote or pallet that has been cancelled, select the container, then select Deliver from the pop-up actions menu.

{{Note}} It is expected that no changes are required to the system to allow for this functionality. This will be checked and confirmed as part of this project.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow amendment of products in containers after delivery.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Once the customer is happy with the delivery, the driver can proceed to job completion by moving to the ''Job Details'' tab and pressing the '''Complete''' button available there.

== Job Completion ==
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.

{{Note}} At this time, the expectation is that the configuration will require the Customer only to sign for collection and delivery of goods, although this can be changed on a per job type or per job group basis.

The device will prompt for Customer Signature.
<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_Signature1.png|''Signature and T&Cs''
File:REQ_330814_PDA_Signature2.png|''Containers''
File:REQ_330814_PDA_Signature3.png|''Products''
</gallery> 

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

The screen displays several tabs, allowing the user to see:
* Terms and Conditions, plus any data entry the user is required to confirm. These are configurable.
* Pallets and Totes collected/delivered.
* The quantity of loose products only being collected/delivered.
* If this is a consolidated group of jobs, a further tab will display the Job references.

The Terms and Conditions are configurable, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with check-boxes and data entry. This may be configured at any time.

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, updated email address, 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 prompt the user to enter Load End Metrics.

<gallery widths=310px heights=400px perrow=3>
File:REQ_330814_PDA_LoadEnd1.png|''Load End Metrics''
File:REQ_330814_PDA_LoadEnd2.png|''Load End Metrics''
</gallery> 

The metrics required are expected to be:
* ODO - Numeric entry
* Fuel Cost - Numeric entry
* Litres Bought - Numeric Entry
* Parking Ticket Number - optional text entry
All checks will be required, except Parking Ticket Number.

{{Note}} The following checks may also be added if this is required:
* Delivery Notes Signed/Printed
* Full Uniform Worn
* Failures phoned in
* Checked back at depot
* Sack Barrow Returned
All of these metrics are expected to be required entry, check-box only.

Vehicle Checks will be configured for the end of the load as well as the start of the load. These will be identical to the checks configured against the vehicle at the start of the load. {{Note}} The change specified above to stop completion of vehicle checks within a certian time will also apply to the vehicle checks at this stage.

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.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

== POC/POD Documents ==
{{Note}} The POD document format is being changed for the purposes of this project. The current format has been provided as a sample, as below:

[[file:REQ_330814_POD.PNG|border|600px]]
 ''Sample POD Format'' 

It is expected that the new POD format will remove or modify the existing format in some small way. As such, a prototype of how this will look within ePOD has not at this time been completed. This will be done at functional specification stage.

At this time, the following elements are on the POD format, and can be supported by the {{#var:System}} system, except where indicated.

Header
* Header with Logo - Fixed
* Zenith Address/contact information
* Driver Name
* TM (Territory Manager) Name
* "DELIVERY NOTE" - Fixed Text (based on job type)
* Date
* Account Number
* Purchase Order Number
* Delivery Number

Addresses:
* INVOICE TO
* DELIVERY TO

Product List:
* Product Code
* Product Description
* Qty Ord
* Qty Del
* Unit Price {{Note}} Not displayed if the job is configured to not have pricing information
* Total Price {{Note}} Not displayed if the job is configured to not have pricing information
* Weight

Footer:
* "HAVE YOU TRIED OUR ON-LINE ORDERING WEBSTORE WWW.ZHGPLC.COM" - Fixed Text
* Print Name
* Signature
* Date
* NETT {{Note}} Not displayed if the job is configured to not have pricing information
* VAT {{Note}} Not displayed if the job is configured to not have pricing information
* TOTAL {{Note}} Not displayed if the job is configured to not have pricing information
* NOTES
* Footer with logos - fixed.

The POD produced will expect to be paginated to accommodate the quantity of products on a single delivery job.

No images are required to be shown on the POD note, whether they are taken on the device or not.

{{Note}} Collection jobs will produce this format, but will replace the text 'Delivery' with the text 'Collection'. If an additional Collection note format is required that exceeds this stated change, additional modifications may be required that may increase the cost of this change, or an additional change may be raised with OBS Logistics for a new POC format.

The definition of what data maps to which fields on the POD depends on the mapping of the interface of jobs into ePOD and will be confirmed after discussion with Sage and at functional specification stage.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=POD Note Format.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

== Data Export ==
All files (inbound to and outbound from ''CALIDUS'' ePOD) will be transferred using an FTP method. It was noted that at a later stage Zenith would like to use webservices, but will use FTP to start as this is quicker for Zenith.

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 re-booked 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 will 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}}, or entered an the POD device at confirmation of the delivery. As part of the export, any jobs with this email address will be automatically sent with a PDF attachment of the POD report. Multiple recipients may be supported through the use of comma- or semicolon-delimited lists of emails addresses (the exact delimiter is based on the email server defined for the system's use).

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

The {{#var:System}} system may be modified to allow POD notes to be sent via FTP or other file transfer to an external document handling system. This is required for Zenith Hygiene. The files may be images or PDF format, and the name may be configured in several different ways.

== 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 TTM (Track and Trace) provides several enquiry and auto-updating screens to allow information to be collated and provided in easy to use formats. The system supports multiple user-defined groups that control the configuration of a user, allowing the control of data access for various different purposes, for example:
* End customers
* Contracts/Owners
* Customer Service Queries
* Transport Office

It is expected that ETAs will be shown on the Portal - this functionality requires a Nokia Maps account which is included in the contract

The following is a brief description of functionality available within ''CALIDUS'' Portal TTM Module - full user guides are referenced in [[#B.1 References|Appendix B]].

=== 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]]
 ''Order Enquiry Parameters'' 

The enquiry responds with a results table summarising the matched orders:

[[file:REQ_324746_TTM_OrdEnqResults.PNG|border|600px]]
 ''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 ====

[[file:REQ_324746_TTM_TripEnqParms.PNG|border]]
 ''Trip Enquiry Parameters'' 

[[file:REQ_324746_TTM_TripEnqResults.PNG|border|600px]]
 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 ====
[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''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.

If enabled, Postponed jobs will be clearly visible in these screens, as follows:

[[file:REQ_330814_TTM_OrderDetail_Events.PNG|border|600px]]
 ''Events Tab showing the Postponement event - prototype'' 

[[file:REQ_330814_TTM_OrderDetail_Reasons.PNG|border|600px]]
 ''Reasons Tab showing the Postponement reason code - prototype'' 

=== 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]]
 ''Arrive/Depart screen'' 

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


=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Document Management ===
It is a Zenith optional requirement to upload further documents pertaining to orders (for example, an invoice document and backing sheet) into the system, to be displayed on the Portal in the same way as the POD. There must also be functionality to download the documents.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Upload additional documents.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

A new ''Documents'' tab will be added to the Order Enquiry Results/Order Details page. This tab will show a table of all externally-uploaded documents. Note that internal POD documents (i.e. from ''CALIDUS'' ePOD) will not appear on this page, but are accessible through the existing POD button.

[[file:REQ_324746_TTM_OrderDetail.PNG|border|600px]]
 ''Order Enquiry Results to have Documents tab added to the right'' 

Clicking on the document will open the document through the user's browser. Depending on the file type, the browser and the applications installed on the user's computer, an external application may be opened to view the document. These applications may also allow saving of the documents. The documents may also be saved from Portal by right-clicking on the file in the list and selecting 'Save Target As...' - note that this functionality is dependent on the user's browser and security settings. Note that documents may not be able to be opened at all - this is dependent entirely on the computer accessing Portal and the applications installed on it.

This tab will also have the facility to upload a single document for this order. The upload will allow the user to select a document type (initially limited to 'Invoice' and 'Backing Sheet', extendible at a later date) and upload a document, similar to the existing Portal upload process.

[[file:REQ_330814_Portal_Upload.PNG|border|600px]]
 ''Gateway - Consignment Signature'' 

Zenith will be able to upload documents in bulk to ''CALIDUS'' Portal directly by uploading files through FTP onto the Portal server filesystem from another machine (i.e. not through the ''CALIDUS'' Portal screens).

{{Note}} This change allows for a single document upload through the Portal screens, and for a batch upload to be completed via FTP - if a batch upload is required through the Portal screens, additional development will be required.

If uploaded documents are not of the correct type or format, they may not be found and displayed on the list - it is the responsibility of the uploading user or system to ensure that they are of the correct type and name, and (for FTP uploads) are placed in the correct filesystem location.

Uploaded external documents will be cleared from ''CALIDUS'' Portal when older than 90 days.



= Appendix A: Out of Scope requirements =


=== Timer to prevent vehicle check completion ===
Zenith are concerned that the driver will just click through the vehicle defect checks without physically performing the checks. It should take a minimum amount of time to complete the check. Zenith would like some functionality added to set a timer when vehicle checks are started, so that the driver cannot complete the vehicle checks until a specified period of time has passed.

The device will be modified to set this time, and to display the countdown of the time remaining in place of the '''Confirm''' button. When this timer reaches zero, the button will change to '''Confirm''' and will be enabled. If the driver exits the app and restarts, the timer will also restart.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Timer to prevent Vehicle Check Completion.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

=== Postpone Job with Reason Code ===
It is a requirement from Zenith Hygiene to postpone a job, and enter a reason code for this.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Postpone Job with Reason Code.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

If enabled, an option to ''Postpone Job'' will be available when long-pressing against a job in the list. If selected, the driver will be taken to the Exception screen, where they will be provided a list of Postponement reason codes only and an optional comment box. If confirmed, the job will be marked as Postponed in the list, and other jobs may then be started ahead of it.

{{Note}} Two none development options have been provided for job postponement

1) If the driver arrives at site and the customer cannot take delivery at that time the driver can back out of the job and select the next job on their list. Note that this will not send any information back to the EPOD system. The job will just remain in progress on EPOD until the driver completes the job at a later time

2) The driver can cancel the job on the PDA with a reason code of Postponed or a reason code that Zenith configure within the admin system. This would then cancel the job on the EPOD system and debrief it back to Sage. The order can then be re-entered/rebooked on Sage and sent through again to EPOD after being planned on to the drivers load. The driver will then receive the job again as an update within their current list

As an extension to this, it is a future requirement to support multiple delivery windows within Sage and the ''CALIDUS'' suite of products. This is out of scope of this project at this time. When required, a separate change request will require raising with OBS Logistics to add this functionality.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Multiple Time Windows.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

===Re-key Email/Contact/Tel at Signature===
A job completion the signature screen will be modified to allow the user to confirm the email of the contact and the Telephone Number for POD purposes. To achieve this, the Email and Telephone Number will be added to the Terms and Conditions tab.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Re-key Email/Contact/Tel at Signature.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

The process will display the original email and Telephone Number and allow this to be changed. A change has also been requested to confirm the customer contact, which will be through the entry of the Signatory on this screen. For all fields, the server will be modified as part of this change to update the customer record with this information.

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, updated email address, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

== Unplanned Ad-Hoc Orders ==
Some orders are missed, either by not being planned or not keyed into the system, etc. If this occurs and the customer complains asking where there order is, on occasion a territory manager will deliver the goods. These drivers will not be given a device, however there is still the requirement to transfer the order to WEBFLEET.

In order for this to occur, the order must either be planned onto a route within Sage and sent on this new route, or the order should be sent singly to ''CALIDUS'' ePOD, then a new load created within the ePOD Admin system and the order assigned to it.

In order to then transfer this to WEBFLEET, there are several options:
* Assign the load to a driver specifically for this purpose, then log on to the mobile application on a device, selecting the correct vehicle at logon, and pick up the load. This will mark the load as in progress and send the instruction to WEBFLEET.
* Change the ePOD Admin application to allow an order to be set to in progress. This would then prompt for the vehicle to be entered for the load and send the job to WEBFLEET.

{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|Definition=Allow Admin to set a load in progress.
|Link=Appendix A: Table of SCRs and Ballpark Estimates
}}

Notes:
* Completing the order in WEBFLEET will not complete the order or load in ''CALIDUS'' ePOD.
* If the loads for these ad hoc orders are not completed through the ePOD mobile application, these loads will be left on the system and never completed, unless Sage explicitly sends through a deletion request.
* If the loads for these ad hoc orders are not allocated to a vehicle configured in WEBFLEET (i.e. a real fleet vehicle) the information will not be transferred to WEBFLEET.
* Setting this load to in progress (either by starting it through the mobile application or through the Admin Loads screen will set any other load for this vehicle back to pending status.

It is recommended that the operation choose to complete these jobs through the standard mobile device application.

=== Tracking Emails ===
''CALIDUS'' Portal can be configured for automatically triggered emails at certain system or operational events.

Events are configured in the Event Maintenance page:

[[file:REQ_330814_TTM_Events.PNG|border|600px]]
 ''Portal Events Maintenance'' 

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

[[file:REQ_330814_TTM_Events_Email.PNG|border|600px]]
 ''Portal Events Maintenance'' 

Both Subject and Body of the email can be completely defined through a text area. Clicking on the Data Field icon allows data items to be inserted in the text, from the following fields:
* Contact Name
* Owner
* Order Number
* Booking Reference
* TMS Reference
* PO Reference
* Customer Name
* Planned Arrival Date/Time
* Delivered Date/Time
* Signed By
* Tracking Link (only Body)

=== Customer Tracking Gateway ===
On clicking the tracking link from an external system or email, 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]]
 ''Enter Consignment'' 

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

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

[[file:REQ_324746_TTM_Gateway_Tracking.PNG|border|600px]]
 ''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.
** 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 customers 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 uses 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]]
 ''Gateway - Consignment Signature'' 

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=5|System=ePOD|Area=Vehicle Checks|Description=Timer to prevent Vehicle Check Completion.|Estimate=2.5|Notes=
}} {{REQ_SCR_Line
|SCR=7|System=ePOD/Portal|Area=Exception|Description=Postpone Job with Reason Code.|Estimate=13.5|Notes=2
}} {{REQ_SCR_Line
|SCR=8|System=ePOD/Portal|Area=Tracking|Description=Multiple Time Windows.|Estimate=0|Notes=Out of Scope
}} {{REQ_SCR_Line
|SCR=13|System=ePOD|Area=Signature|Description=Re-key Email/Contact/Tel at Signature.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=14|System=ePOD|Area=Loads Admin|Description=Allow Admin to set a load in progress.|Estimate=2.0|Notes=
}} {{REQ_SCR_Footer}}



= Appendix B: Table of SCRs and Ballpark Estimates =

== '''Essential''' ==

{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR=1|System=Sage|Area=Integration|Description=ePOD-Sage Integration meetings and specification.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=2|System=Portal|Area=Email|Description=Customer Tracking Email.|Estimate=2.75|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=3|System=ePOD|Area=Reporting|Description=Pricing.|Estimate=10|Notes=
}} {{REQ_SCR_Line
|SCR=4|System=ePOD|Area=Look and Feel|Description=Create customer-specific style on device.|Estimate=1|Notes=
}} {{REQ_SCR_Line
|SCR=6|System=ePOD|Area=Delivery|Description=Display Total Weight/Unique Products.|Estimate=7.25|Notes=
}} {{REQ_SCR_Line
|SCR=9|System=ePOD|Area=Delivery|Description=Amendments to handle large numbers of Products.|Estimate=4.5|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=10|System=ePOD|Area=Reporting|Description=Allow Scanning of alternate Product Barcodes.|Estimate=5.5|Notes=
}} {{REQ_SCR_Line
|SCR=11|System=ePOD|Area=Delivery|Description=Identify Pallets that require Product Scanning.|Estimate=4.5|Notes=
}} {{REQ_SCR_Line
|SCR=12|System=ePOD|Area=Delivery|Description=Allow amendment of products in containers after delivery.|Estimate=0|Notes=OBS Cost
}} {{REQ_SCR_Line
|SCR=15|System=ePOD|Area=Reporting|Description=POD Note Format.|Estimate=1.5|Notes=1.5 days additional to 3 days included in contract
}} {{REQ_SCR_Line
|SCR=16|System=Portal|Area=Loads Admin|Description=Upload additional documents.|Estimate=3.0|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.


{{Doc_Appendix
|Appendix=C
|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 - TTM
|RefV4=6.8
|RefDate4=12/11/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Michael Rayner
|Rev1Title=Zenith Hygiene
|Rev2=Matt Turner
|Rev2Title=OBS Logistics
}}</div>
[[Category:{{#var:Client}} REQ]]