Revision as of 17:43, 15 March 2019

Charity Fleet Care

CFC v2 Lite Requirements

CALIDUS ePOD

15th March 2019 - 0.5
Reference: REQ 354306

Introduction

This document is the CFC v2 Lite Requirements.

Objective

The primary purpose of this document is to document the requirements gathered from Matt Turner for new Charity Fleet Care implementations.

Scope and Limitations

Client Requirements

Overview

The systems have been created for implementation as follows:

v1 - VEhub + MCB
v2 - CTL-TMS + C-ePOD + TTM

The full v2 process is:

Plan a load per vehicle per day.
Create planned collection jobs for the load.
Create linked delivery jobs to charity store (optional).
Gather Gift Aid information and signature at arrival.
Ad Hoc Items at collection.
- Generate Ad Hoc items automatically on device.
- Print labels (optional).
Produce POC and Gift Aid form combined.
Email or store PDF automatically (optional).

The process needs the following hardware:

An Android device
A Mobile Bluetooth label printer (optional) supporting ZPLII language (optional)

Note:

The process can still be followed without mobile label printers.
The only label format currently being developed is in ZPLII printer language. If the printer supports standard Bluetooth connections and the printer language is compatible with the way that the application sends data (for example, EPL and CPCL would also work), then a different label format could be created. Note that this is dependent on a fully-configurable label format in C-ePOD.

The devices expected for customers implementing this system are as follows:

Brother RJ-4030 mobile printer.
TomTom PRO mobile devices.

Data

CALIDUS ePOD will receive loads consisting of jobs sent from TMS. These loads will be assigned to drivers and/or vehicles. The jobs on the load will be sequenced for collection.

Each loads will be assigned to a site, expected to be the charity shop.

Configuration in CALIDUS ePOD will control the process of collecting the goods from the donor.

It is expected that this configuration will be as follows:

Customer signature required at the end of a collection.
Ad Hoc item collection.
Print Item Labels (controlled by the label format).
Collection Note and Gift Aid Registration format.
A defined container (item) abel format.
Printing from EPOD devices.
Unmanned location.

Vehicles and users will be created when loads are received from CTL-TMS. They may also be maintained within the CALIDUS ePOD Admin Users and Vehicles maintenance screens.

Note: If using TomTom PRO devices with a WEBFLEET user, the CALIDUS ePOD user name should be created to match the WEBFLEET driver name, and the WEBFLEET vehicle ID entered against the vehicle. If this is not maintained, the application will not automatically log in using WEBFLEET login information.

DU (item) types (for example, BOX, BAG, etc) will be created and maintained within the CALIDUS ePOD Admin Codes maintenance screen.

The expected configuration of Arrival Terms and Conditions will be:

Enter Gift Aid ID
A button to Register for Gift Aid running the Gift Aid Registration sub-form.

The expected configuration of the Gift Aid Registration sub-form is expected to contain:

Several text labels describing the Gift Aid process:
A check-box to confirm Gift Aid, which must be checked.
The charity name, defaulted from the job, required to be entered.
Name, defaulted from the contact name on the job, required to be entered.
4 lines of address, defaulted from the job address, 1 line required to be entered.
Post Code, defaulted from the job address, required to be entered, validated as a UK post code.
Date, defaulted to the current date, required to be entered.
A Confirm button to save the Gift Aid Registration details.
A Cancel button to discard the Gift Aid Registration details.

Note: It is expected that a single set of T&Cs for a single job group or for the site will be required. However, the application will allow for different T&Cs (and Gift Aid Registration forms) to be configured for each customer (Job Group in C-ePOD). The POC note format will display all of these checks on a Gift Aid Registration page. Note however that formatting changes cannot be made to this page without further development.

PDA Login

The application will have a customised which will display the site logo on the login page.

Log In

The drivers will be provided a user-name and password, 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 CALIDUS ePOD. Note: User IDs that are created automatically as part of the Standing Data creation at Load Import will be available for use, but will have a default password created. This password should be modified before use as a security precaution.

Note: It is expected that the CALIDUS ePOD user name and password will be configured to be the TomTom WEBFLEET user name and password.

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.

When logged in to WEBFLEET, the device will automatically detect the user and vehicle and automatically log the user on to the application using these credentials if possible.

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

Printer Selection

If the site is set up for printing (as it is expected to be), the device starts the Printer Selection process after log-on:

The device prompts for a printer, showing all Bluetooth printers paired with the device, and an option to choose "No Printer".
The driver selects one.

Once selected, the load and job list is shown.

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 (or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.

Job List

The Job list on the mobile device is expected to be styled so that only the following items are displayed:

The planned date and time
The job number (the job code)
The location (address name)

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.

However, 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:

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

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 not be allowed at any time. Jobs with the same sequence (i.e. non-timed jobs) may be completed in any order, although not before any timed jobs i.e. jobs that are lower in sequence.

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. It is noted that this should not occur.

The driver has an option to change the label printer from the hamburger menu here, which re-starts the Printer Selection process described above.

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.

Job Details
Instructions

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

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

The screen will show a Navigation icon, which can be clicked to start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp, which can be linked 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: 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 not be allowed for jobs. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and will not be allowed to continue. Note that the application can if desired be configured to only issue a warning in this case, rather than prevent it outright.

Once started, the device will display a navigation button. Clicking this will commence immediate navigation to the address - the TomTom NavApp will be shown, which will immediately calculate a route to the destination address.

The Lat/Longs on the job (if present) will be used for navigation, otherwise the address will be evaluated at that time and used for navigation.

Once arrived at the destination, the driver will switch to the CALIDUS ePOD 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.

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

Arrival Process

The driver process when arriving at a collection point is:

Arrive at site, capturing arrival time automatically.
Capture Gift Aid information and signature.

The driver will press the Arrive Job button to show arrival at the location.

Arrive Job

On arrival to the location, the terms and conditions will show:

A facility to enter an existing Gift Aid ID for the charity.
A button to Register for Gift Aid.

Arrival Signature and T&Cs

Pressing the Register for Gift Aid button will open a form to enter the Gift Aid Registration details.

Gift Aid Registration
Gift Aid Registration
Gift Aid Registration
Gift Aid Registration

The Gift Aid Registration form will show the following:

Several text labels describing the Gift Aid process:
A check-box to confirm Gift Aid, which must be checked.
The charity name, defaulted from the job, required to be entered.
Name, defaulted from the contact name on the job, required to be entered.
4 lines of address, defaulted from the job address, 1 line required to be entered.
Post Code, defaulted from the job address, required to be entered, validated as a UK post code.
Date, defaulted to the current date, required to be entered.
A Confirm button to save the Gift Aid Registration details.
A Cancel button to discard the Gift Aid Registration details.

Any fields with a default value will be shown with the value of the data from the job.

Note: This form will not be required to be completed, and the provided Cancel button bay be used to return to the Arrival Signature.

Once complete and saved, the customer will sign for the collection.

The information on the device will be passed back to CALIDUS TMS. The signature and T&Cs (along with any completed Gift Aid declaration or existing Gift Aid ID) will be stored against additional order information when the collection has been confirmed as complete.

Note: The arrival signature process itself will be configured so that the driver can skip this process entirely if the customer is not a registered gift aider, nor desires to register.

The device will move on to the Collection process.

Collection Process

The driver process at a collection point is:

Confirm items collected.
Complete collection and capture customer signature.

Collections will initially consist of no items to be collected.

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

Job Details Tab
Job Details Tab - Addresses
Ad Hoc Tab
Notes Tab

The Job Details tab has multiple sections:

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

The driver clicks the New Item button which shows a pop-up:

The driver selects the DU from list, for example, BAG, BOX, LARGE ITEM, etc.
The driver selects the job destination (if consolidated).
If multiple labels are configured to be allowed to be created, the driver can also select the number of items to create/labels to print i.e. create 4 "BAG" items for destination "My Charity Store".

The label (or labels) will then be printed. A confirmation dialogue will be displayed, allowing the driver to:

Confirm printing OK.
Reprint the label (or labels).
Change the printer (through the Printer Selection process above).

The items created will be added to the list of items automatically.

SCR-354306-1:

Ad Hoc Item Generation and Label Printing

The driver can reprint any single label by long-pressing on the added item and select "Print Label" from the pop-up options.

If a label is damaged or not required, the driver can remove an item by long-pressing on the added item.

A single generic label format will be designed and delivered with the software. The label format has been prototyped and is shown below:

SCR-354306-2:

Label Format

The label format is expected to contain:

The charity store (the site name).
The item barcode.
The charity name (the owner name).
The donor name and address.

Note: Any additional label formats required by individual charities will accrue additional cost.

When all items have been confirmed as collected, the user will return to the Job Details tab, where a Complete button will be displayed, to complete the job.

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.

Job Completion

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

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

All of these processes are controlled during Job Completion.

Note: At this time, the expectation is that the configuration will require only the Customer to sign for collection of goods. It is an optional configuration for CALIDUS ePOD, where customer and driver signatures can be enabled or disabled for collections, and whether the device will prompt for Job Photos after signature.

The device will prompt for Customer Signature.

Customer Signature and T&Cs
Customer Signature and Items (Containers)

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 items being collected.

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.

The device can be configured to handle unmanned collections. On the device, if configured, the device will have a button on the screen, labelled as Unmanned Location.

If a signature is entered in the customer signature screen, the screen will change this button to "Done", so that the driver can accept the customer signature.

If a customer is not available, the driver can click the Unmanned Location button. The device will prompt for confirmation from the driver 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.

If driver signature is required, this displays very similarly to the customer signature above, with some differences:

Only T&Cs if configured will be shown on the tabs.
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.

The process can be configured to prompt for photos after completion of the signatures for collections.

It is expected that this will either be optional or not configured at all.

As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.

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

Post-Load

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

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

POC/POD Documents

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 job, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view.

Note: CALIDUS ePOD will be modified to create a single generic Charity Fleetcare POD/POC format, containing:

A front page detailing the charity, collection information, items collected and signature, signatory, date and time. Any existing
A second page showing the Gift Aid Registration form, if captured against that job.

SCR-354306-3:

Charity Fleetcare POC Format

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

Prototype Charity Fleetcare POC Format

Note: It is expected that a single set of T&Cs for a single job group or for the site will be required. However, the application will allow for different T&Cs (and Gift Aid Registration forms) to be configured for each customer (Job Group in C-ePOD). The POC note format will display all of these checks on a Gift Aid Registration page. Note however that formatting changes cannot be made to this page without further development.

The front page contains the POC (Proof of Collection) information as follows:

Site Logo.
Title "COLLECTION NOTE".
Collection Number.
Site Address/contact information.
Collection Address
Order Information.
Items collected, with barcode and type.
T&Cs displayed when the user signs for the collection. Also includes the Gift Aid ID.
The Signature, Name and Date.

The back page contains the Gift Aid Declaration (if present), as follows:

Site Logo
Title "GIFT AID DECLARATION"
The Gift Aid Form entered on arrival to the collection.
The Signature, Name, Date and Time.

Data Export

When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems or users. This is also true of cancelled jobs

Completed jobs with an email specified on the address will be picked up by a timed process and the POC may be configured to be automatically sent to that email address. The POD will be in PDF format. The email address will be that provided to C-ePOD from the customer record.

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

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

Email subject and content may be configured:

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

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

Further Reporting and Queries

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

Loads
Jobs
Items (Containers)

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 collection details can be accessed from this screen.

Jobs

Additionally, this information may be taken from the CALIDUS Portal system.

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

User Tracking - Activities
User Tracking - Location

Appendix A: Table of SCRs and Ballpark Estimates

SCR#	System	Area	Description	Estimate (Days)	Notes
1	EPOD	Mobile Printing	Ad Hoc Item Generation and Label Printing	22.00
2	EPOD	Mobile Printing	Label Format	2.50
3	EPOD	Reports	Charity Fleetcare POC Format	3.50

Notes:

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

Appendix B: Document References

B.1 References

Ref No	Document Title & ID	Version	Date
1

B.2 Glossary

Term or Acronym	Meaning
General Definitions
EPOD	Electronic Proof of Delivery. The OBSL EPOD system is CALIDUS ePOD. This also comprises the basis of the Service Completion system CALIDUS eServ.
Server	The portion of the CALIDUS ePOD/eServ systems that controls all the data and sends information to and receives updates from the mobile device.
Mobile Device; PDA	The device used by the driver to perform the jobs. Typically an Android mobile device or tablet.
Site	The site usually defines the depot, business or the transport group (carrier). It can be set to any value required by the customer. All transactions data (for example, loads and jobs) and standing data (for example, vehicles and uses) belong to a site. An EPOD user, on a device or in the Admin screen, can only see data for one site at a time.
Load	A single journey for the driver with a set of work attached. A load is identified by a unique load ID. This may also be referred to as a worklist or workload.
Job	Also Consignment. A single task for the driver as a specific location. This could be the collection of goods or the delivery of goods. Jobs may also be Services (for example, servicing, installing or de-installing a boiler). A job is identified by a unique job ID but can also have other references held against the job (e.g. job code, SO number, customer reference and external reference).
Job Group	Jobs must be tagged with a Job Group. All jobs tagged with a single job group are processed in the same way. The job group has configuration associated to it to control such items as: POD/POC Report settings; Pre-Job actions (such as signing at a gatehouse); Post-Job actions (such as who signs for the item, are photos required); configurable fields required for entry for the jobs; Terms and Conditions displayed and; driver/user process (such as photos required for cancellation, comments/notes allowed). The job group can be used for any or all Sites, and the configuration against the job group can be different in each site. Job Groups can also be restricted from Admin and Remote users, so that certain users only see jobs for certain groups.
Container	A generic term for any object that contains the items being collected or delivered. Examples of containers are: Pallet; Package; Carton; Item; Cage. A special container "Loose Products" - see Product below. A container is identified by a container ID which is unique to this physical container.
Product	A product is any goods that are being collected or delivered where the product has a 'Product Code' which identifies what the product is but which does not uniquely identify each individual item. A product will also have a quantity associated with it to indicate how many items of this 'Product Code' are being collected or delivered. Products can either be processed within a 'Container' or as 'Loose Products' without a 'Container'.
Owner	The owner of the order that created the job. Typically this is the sales team that took the order and will be responsible for dealing with queries from the customer regarding the status.
Operator; Executor	The Site (depot or carrier) that is executing the load or loads that are involved in the delivery of the items.
Item Related Definitions
Job Code	A reference associated with a job or job(s). This reference is common to connected jobs, for example this would be the same on both the collection of goods and the associated delivery of the same goods. Typically this would be the transport unique reference.
SO Number	A reference associated with a job which indicates the "Sales Order Number" this job is associated with.
Customer Reference	A reference associated with a job which has been provided by and will be recognised by the customer.
External Reference	A reference associated with a job which does not match any of the existing references, usually because it has been provided by an external system.
Pallet	An alternative for 'Container'. The term pallet is used when the operation only uses portable platforms as the container for goods.
Package	An alternative for 'Container'. The term package is used when the operation only uses boxes or wrapping as containers for goods.
Package Code	A code representing the type of 'Container'.
Package Desc	A description of the type of 'Container'.
Product Code	A code which identifies what a product is.
Item	A generic term for any individual item that can be collected or delivered. An item can represent a 'Container' or a 'Product'. This can also be used as an alternative for 'Container' when the operation only treats the goods as individual items, i.e. not as identifiable products.
Service Item	An item which will be serviced by a service job. See action 'Service'.
Issue Life	The time after which an item is no longer fit for purpose.
Pack Size; Case Quantity	A product may consist of a full quantity of items, inside a pack. The Pack Size (or Case Quantity) defines the amount of this product contained in a single pack. For example, if there are 85 items to deliver, with a pack size of 24, the number of full packs is determined to be 3 (24 * 3, or 72), with the remaining (13) being 'loose' quantity. This is displayed as "3/13" on the mobile application.
UOM; Item Type	Unit of Measure; The major (case) UOM. This can optionally be displayed on the mobile device when changing product quantities.
Product Type	A classification of the product being delivered. For example, a company may deliver 7 different mortar products and 80 different concrete slab products. The Product Types may be set to "MORTAR" and "SLABS". This may be used to attach additional configuration, changing the data required when collecting or delivering these product types.
Status Definitions
Status	An indicator of how far through the processing a 'Job', 'Container' or 'Product' has progressed.
Pending	A status indicating that the processing has not yet started, but is required to be completed.
In Progress	A status indicating that processing has started but not yet finished.
Complete	A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered.
Complete (Amended)	A status indicating that the 'Job', 'Container' or 'Product' has been collected or delivered but that some changes or amendments have been made. This means that not everything that was planned to be collected or delivered was collected or delivered, some items may have been cancelled or some products may only have had some of the planned quantities collected or delivered.
Complete (Claused)	A status indicating that the processing has been finished but that a 'Clause' condition has been recorded for this item.
Claused	See 'Complete (Claused)' and action 'Clause'.
Cancelled	A status indicating that the processing of this item or job is no longer required.
Cancelled at Collection	A status indicating that the delivery of a container or product is no longer required because the associated collection of this container or product was cancelled.
Submitted	An optional status that applies only to a 'Job' and which occurs after the 'Job' has been completed. This indicates that any time and expenses information recorded for the 'Job' has been submitted back to the server and can no longer be altered.
Action Definitions
Start	An action associated with a 'Job' meaning the driver is about to start the processing of this job or jobs. This action will mark the job(s) with a status of 'In Progress'.
Arrive	A conditional action associated with a 'Job' meaning the driver has arrived at the location the goods should be collected from or delivered to.
Continue	An action associated with a 'Job' meaning the driver has previously performed the 'Start' and/or 'Arrive' action and has exited the processing screen but is now going to continue the processing.
Collect	An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Collect Claused	An action associated with a specific 'Container' or a 'Product' meaning the driver has collected the 'Container' or 'Product' but with a condition under which the collection was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Deliver	An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product'. This action will mark the 'Container' or 'Product' with a status of 'Complete' or 'Complete (Amended)'.
Deliver Claused	An action associated with a specific 'Container' or a 'Product' meaning the driver has delivered the 'Container' or 'Product' but with a condition under which the delivery was accepted. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Clause	An action associated with a specific 'Container' or a 'Product' that has already been collected or delivered meaning the collection or delivery has been accepted with a condition. This action will accept the clause condition and then mark the 'Container' or 'Product' with a status of 'Complete (Claused)'.
Cancel	An action associated with a 'Job', 'Container' or 'Product' meaning the collection or delivery will not be performed for this 'Job', 'Container' or 'Product'.
Submit	An optional action which can conditionally be carried out after a 'Job' has been collection or delivered meaning that any/all required expense or time recording for this 'Job' has been completed and can be submitted back to the server.
Service	A service of a service item or items. Typically, Installation, Deinstallation or Service. The process of a service usually encompasses Pre- and Port-work checks, information gathering and diagnosis and resolution notes. Additional references (MC Refs) may also be captured.
Actioned	A general term describing completing a job. So, 'Actioned' may be used instead of 'Collected', 'Serviced', 'Delivered'.
Consolidate	The action of taking several jobs and linking them together, so they are actioned at the same time with one start, arrive and signature.
Deconsolidate	The action of taking a consolidation of jobs and breaking them down into the component jobs again.
Job Swap	The action of selecting an existing load not assigned to the user, and picking jobs to transfer onto the user's load.
Signature Capture	Usually the final action of a job, where the customer's name and signature are entered.
Other Definitions
Reason Code	A code which represents the reason that a job was cancelled or an item was cancelled or claused.
Vehicle	The vehicle used for transporting the goods.
Vehicle Checks	Also Defect Checks. A series of questions representing the results of checks intended to ensure the vehicle is in an acceptable condition.
Metrics Entry	A series of questions to capture information either at the start or end of a 'Load'.
Driver	The person performing the collections or deliveries; the user of the device/application.
Engineer	The person performing the services; the user of the device/application.
Customer	The person/company the goods are being collected from or delivered to.
Signatory	The name of the person providing a signature.
T&Cs	Terms and Conditions. The T&Cs are shown when signatures are prompted for. The text of the T&Cs are defined in the system itself.
Transfer Load	A load select from which to swap jobs to the user's load.
Base	E.g. 'Return to Base'. Typically the depot from which the driver departed.
Unplanned Ad Hoc Collection	A collection job that is created by the driver, usually after delivering to a customer.
Ad Hoc Container Entry/Scanning	The process of adding containers (items) to a job that have not been pre-advised on the job.
Completion Report	POD, POC, Service/Work Report.
Load Assignment	The action of assigning a vehicle and/or a driver to a load.
Job Assignment	The action of putting jobs onto a load.
Collection/Delivery Windows; Access Windows	Periods of time between which it is acceptable to deliver or collect from that customer. This has limited use in the system, mostly for reporting purposes.
Location/Map Terms
Lat-Longs; GPS Co-ordinates, GPS Position	Latitude and Longitude co-ordinates, specified together as a single entity, identifying the exact position of a location. There are multiple formats - CALIDUS ePOD uses decimal notation, for example "53.3490818,-2.8521498" identifies the OBS Logistics office building in Liverpool.
GPS	Global Positioning System; the satellite system used to obtain a GPS position, for use with navigation and location positioning.
Geocode; Reverse Geocode	Geocoding is the process of obtaining lat-longs from an address. Reverse Geocoding is the process obtaining an address from lat-longs.
Geofence; Geofence Break	A Geofence is a perimeter around a location. A Geofence Break occurs when a device passes through this perimeter on entry or exit from the location.

B.3 Authorised By

Murray Middleton	OBS Project Manager	_____________________________
Matt Turner	OBS Product Manager	_____________________________

Anonymous

Search

REQ 354306 CFC v2 Requirements: Difference between revisions

Namespaces

More

Page actions

Revision as of 17:43, 15 March 2019

Contents

Introduction

Objective

Scope and Limitations

Client Requirements

Overview

Data

PDA Login

Printer Selection

Obtain Workload/Job List

Job Details

Cancelling a Job

Navigation and Arriving

Arrival Process

Collection Process

Job Completion

Post-Load

POC/POD Documents

Data Export

Further Reporting and Queries

Appendix A: Table of SCRs and Ballpark Estimates

Appendix B: Document References

Navigation

Navigation

Translate

Wiki tools

Wiki tools

@@ Line 4: / Line 4: @@
 {{#vardefine:System|''CALIDUS'' ePOD}}
 {{#vardefine:Doc_Title|CFC v2 Lite Requirements}}
-{{#vardefine:Version|0.4}}
+{{#vardefine:Version|0.5}}
-{{#vardefine:Date|4th December 2018}}
+{{#vardefine:Date|15th March 2019}}
 {{#vardefine:Reference|354306}}
-{{#vardefine:Year|2018}}
+{{#vardefine:Year|2019}}
 </div>
 {{Doc_Title
@@ Line 33: / Line 33: @@
 <!-- NEW PAGE -->
 = Client Requirements =
+== Overview ==
 The systems have been created for implementation as follows:
 *	v1 - VEhub + MCB
-*	v2 - C-TMS + C-ePOD + TTM
+*	v2 - CTL-TMS + C-ePOD + TTM
-The customer has noted the following:
+The full v2 process is:
-*	C-TMS may be difficult to use for small charities with small fleets and may be overkill
+*	Plan a load per vehicle per day.
-*	MCB (for Gift Aid) is going to be phased out
+*	Create planned collection jobs for the load.
-*	Maintaining v1 and v2 requires duplicated developments between VEhub and C-ePOD.
+*	Create linked delivery jobs to charity store (optional).
+*	Gather Gift Aid information and signature at arrival.
-There exists then a requirement for an integrated solution with some planning, allowing Gift Aid entry (v2 Lite).
+*	Ad Hoc Items at collection.
-C-ePOD + TTM (potentially + VEhub) is seen to be the strongest contender for this.
+**	Generate Ad Hoc items automatically on device.
+**	Print labels (optional).
+*	Produce POC and Gift Aid form combined.
-In addition to the core functionality, the following are seen as required development areas to fulfil the scope of the v2 Lite implementation.
-'''Primary Developments:'''
-This section consists of absolute requirements, either for v2 Lite to work in any capacity, or for fundamental customer requirements. Essentially "M" in MoSCoW.
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Improved Load Assignment in EPOD
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Label Printing
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=POD based on Gift Aid entries in T&Cs
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Unplanned Ad Hoc Collection from any location
-}}
-'''Secondary Developments:'''
-This section consists of optional developments, either because they are extremely useful but not specifically required, or may not be required in the final solution. Essentially "SC" in MoSCoW
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Screen to create loads per vehicle per day, with loading and unloading jobs created automatically
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Interface to UK Changes (supporting existing C-TMS Trip/Order format)
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Show Load map for all jobs on load, numbered.
-}}
-'''Additional Developments:'''
-This section consists of optional developments unrelated to the core requirements. Essentially "W" in MoSCoW
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Route Building via PTV
-}}
-*	Route Optimisation, estimated through a variety of options:
-**	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=PTV
-}}
-**	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=HERE maps
-}}
-**	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Google Maps
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Pre-advise Collected DU Quantity and Weight
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Use C-ePOD for VEhub functionality
-}}
-**	Vehicle Checks
-**	Accident Reports
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Entering Collection/Delivery Windows
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Geocoding by HERE maps
-}}
-*	{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Report of Collections, including Gift Aid
-}}
-{{ #vardefine: SCR | 0 }}
-{{Note}} The assumption is that each development will be treated separately and therefore has been costed as such, including implementation and release time. If completed together, this time will be reduced. Certain options have already been combined and the combined cost worked out to show potential savings.
-The full v2 Lite process is:
-*	Plan a load per vehicle per day
-*	Create planned collection jobs for the load
-*	Create linked delivery jobs to charity store (optional)
-*	Unplanned Ad Hoc collections at any location
-*	Ad Hoc containers and/or planned containers
-*	Generate Ad Hoc container IDs automatically on device
-*	Print labels (optional)
-*	Gather Gift Aid at signature
-*	Produce POD + Gift Aid form combined
 *	Email or store PDF automatically (optional).
 The process needs the following hardware:
-* Android device
+* An Android device
-* Mobile Bluetooth label printer (optional) supporting ZPLII language (optional)
+* A Mobile Bluetooth label printer (optional) supporting ZPLII language (optional)
 {{Note}}
@@ Line 174: / Line 57: @@
 * The only label format currently being developed is in ZPLII printer language. If the printer supports standard Bluetooth connections and the printer language is compatible with the way that the application sends data (for example, EPL and CPCL would also work), then a different label format could be created. Note that this is dependent on a fully-configurable label format in C-ePOD.
+The devices expected for customers implementing this system are as follows:
+* Brother RJ-4030 mobile printer.
+* TomTom PRO mobile devices.
-== Improved Load Assignment in EPOD ==
-This product development is under way by the Solihull .NET team.
-It is assumed that this will match or exceed the functionality described in the SCR specification:
+== Data ==
-* [[FS 340547 PROD-75 Admin Job Assignment Improvements]]
+''CALIDUS'' ePOD will receive loads consisting of jobs sent from TMS. These loads will be assigned to drivers and/or vehicles. The jobs on the load will be sequenced for collection.
-In summary, this will achieve the following (from sections 3.2 and 3.3):
+Each loads will be assigned to a site, expected to be the charity shop.
-* An improved mechanism of searching for and adding jobs to an existing load, through a variety of additional filtering criteria
-* A mechanism of sequencing and consolidating jobs on a load, with drag and drop functionality.
-{{Note}} This functionality is expected to be available for evaluation on 27/11/2018 - awaiting confirmation from Neil Appadu.
+Configuration in ''CALIDUS'' ePOD will control the process of collecting the goods from the donor.
+It is expected that this configuration will be as follows:
+* Customer signature required at the end of a collection.
+* Ad Hoc item collection.
+* Print Item Labels (controlled by the label format).
+* Collection Note and Gift Aid Registration format.
+* A defined container (item) abel format.
+* Printing from EPOD devices.
+* Unmanned location.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Improved Load Assignment in EPOD
-}}
-'''Total dev''': 0d (potentially already completed product development).
-'''Ballpark''': 0d.
+Vehicles and users will be created when loads are received from CTL-TMS. They may also be maintained within the ''CALIDUS'' ePOD Admin Users and Vehicles maintenance screens.
+{{Note}} If using TomTom PRO devices with a WEBFLEET user, the ''CALIDUS'' ePOD user name should be created to match the WEBFLEET driver name, and the WEBFLEET vehicle ID entered against the vehicle. If this is not maintained, the application will not automatically log in using WEBFLEET login information.
-== Label Printing ==
-The changes have already been estimated for inclusion as part of v2.
-However, the device has since been received and tested with the following results:
+DU (item) types (for example, BOX, BAG, etc) will be created and maintained within the ''CALIDUS'' ePOD Admin Codes maintenance screen.
-* Once paired with the device, the printer is available to the test app.
-* The printer can be connected to through secure Bluetooth with no additional modifications.
-* The printer prints the GFG ZPLII format label identically to the Zebra QL410+ printer.
-The process as designed is as follows:
+The expected configuration of Arrival Terms and Conditions will be:
+* Enter Gift Aid ID
+* A button to '''Register for Gift Aid''' running the Gift Aid Registration sub-form.
-C-TMS collection jobs are created. These can be with items to be collected or without items, just volume for planning. So:
-*	Order lines of DU types and quantity e.g "BAG" qty 2
-*	Order items, one per qty of DU made up of OMS Ref and a unique counter e.g 123456001
+The expected configuration of the Gift Aid Registration sub-form is expected to contain:
+* Several text labels describing the Gift Aid process:
+* A check-box to confirm Gift Aid, which must be checked.
+* The charity name, defaulted from the job, required to be entered.
+* Name, defaulted from the contact name on the job, required to be entered.
+* 4 lines of address, defaulted from the job address, 1 line required to be entered.
+* Post Code, defaulted from the job address, required to be entered, validated as a UK post code.
+* Date, defaulted to the current date, required to be entered.
+* A '''Confirm''' button to save the Gift Aid Registration details.
+* A '''Cancel''' button to discard the Gift Aid Registration details.
-Jobs are planned and sent to EPOD.
+{{Note}} It is expected that a single set of T&Cs for a single job group or for the site will be required. However, the application will allow for different T&Cs (and Gift Aid Registration forms) to be configured for each customer (Job Group in C-ePOD). The POC note format will display all of these checks on a Gift Aid Registration page. Note however that formatting changes cannot be made to this page without further development.
-The driver logs on to device as normal.
+== PDA Login ==
+The application will have a customised which will display the site logo on the login page.
-As the site is set up for printing, the device starts the Printer Selection process after log-on:
+<gallery widths=300px heights=210px perrow=2>
-*	The device prompts for a printer, showing all Bluetooth printers paired with the device, and an option to choose "No Printer".
+File:REQ_354306_PDA_Login1.png|''Log In''
-*	The driver selects one
+</gallery><br />
-Once selected, the load and job list is shown.
+The drivers will be provided a user-name and password, 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.
-The driver has an option to select printer from the hamburger menu here, which re-starts the Printer Selection process above.
+{{Note}} It is expected that the ''CALIDUS'' ePOD user name and password will be configured to be the TomTom WEBFLEET user name and password.
+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.
-The driver starts and arrives the job.
+When logged in to WEBFLEET, the device will automatically detect the user and vehicle and automatically log the user on to the application using these credentials if possible.
-For pre-advised containers:
+{{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.
-*	The driver can long-press on a container and use the Print Label option to print a label.
-For ad hoc containers:
-*	The driver clicks the New Item button which shows a pop-up:
-**	The driver selects the DU from list.
-**	The driver selects the job destination (if consolidated)
-**	If generating container IDs, and site printing flag is set to Multiple, the driver can also select the number of containers to create/labels to print i.e. create 4 "BAG" items for destination "BHF Liverpool 1".
-*	If printing, and a printer is selected, and the job group of the container has a Label Format for that selected printer type, the label (or labels) will be printed.
-*	A confirmation dialogue will be displayed, allowing the driver to:
-**	Confirm printing OK
-**	Reprint the label (or labels)
-**	Change the printer (through the Printer Selection process above)
-*	The driver can reprint any single label by long-pressing on the added container and select "Print Label" from the pop-up options.
-The driver gets the signature and T&Cs gather either:
-*	Gift Aid Number
-*	Gift Aid Declaration
-The job is updated in EPOD, and updated in C-TMS as complete.
-Any Ad Hoc containers are created in C-TMS, as items (and potentially additional order lines/DUs).
-This process (minus the C-TMS processes list above) is still valid for the v2 Lite implementations.
-The developments break down as follows:
-'''Required development for any label printer model:'''
-'''Database/DAL:'''
-New EPOD_LABEL_FORMAT table
-* including ID, name, format string, and label type (Container Label, Product Label or Receipt)
-* Add DAL to export in XML structure
-New fields on EPOD_JOB_GROUP
-* Label Format
-* Container ID Generation Format
-Change DAL to export new fields on EPOD_JOB_GROUP
-EPOD_SITE changes
-* New Printing flag
-* Change DAL to export new field on EPOD_SITE
-'''Admin:'''
-New Label Format Maintenance Screen
-Site to allow new flag for Printing
-* Values Disabled/Enabled/Multiple
-Job Group to allow DDL of Label Formats
-* On the first tab.
-'''Server:'''
-Send EPOD_LABEL_FORMAT to mobile device on Log-on Response
-* new XML node, generated from DAL
-'''Device:'''
-Add new EPOD_LABEL_FORMATS table and DAL object
-* including method to select format based on Label Format Code.
-Add new field EPL_LABEL_FORMAT_ID to EPOD_JOB_GROUP
-Receive label formats in new EPOD_LABEL_FORMATS in log-on response
-Receive new EPOD_JOB_GROUPS fields
-* EPL_LABEL_FORMAT_NAME - NULL is OK.
-* EPL_CONT_ID_GEN_FMT
-Receive new EPOD_SITE Printing flag
-Implement calidusprintingsdk module
-Printer Selection process pop-up
-* Through an alert built on demand
-Generate Container ID process
-* (Time above assumes that the Label Substitution code below can be reused in this process)
-* e.g. [PDAJOB.EPL_JOB_CODE][PDACONTAINER.EPL_SEQUENCE(3)]
-* Generate sequence from next in sequence.
-Add Print Label to Container options on AH Containers and Containers
-Add New Item button if generating container IDs rather than Scan buttons
-Label Substitution process
-* Replace [PDAXXX.EPL_XXX] with data, supporting basic formatting required for this label.
-Add "Number to create" to the DU Type/Destination pop-up
-* If printing = "Multiple"
-Label Print process, based on printer type
-Print Confirmation process
-* Including OK/Reprint/Change Printer options
-{{Note}} These developments can be simplified if the following is true:
-* Only one label format for each charity.
-* Configuration of the label format not regularly required.
-In that case, the estimates below show as Common:Core (required regardless) and Common:Product (essentially the configuration element of the change.
-{{Note}} If Common:Core is selected, and further 3.0d would be required for the bespoke element of this change, regarding:
-* Storing label formats in style
-* Multiple label formats for CFC
-{{Warning}} It is '''''STRONGLY ADVISED''''' that, regardless of whether Common:Core is selected by the customer, that OBSL develop the complete solution, and view the contribution from the Charities as product development. Without this Core:Product development, the work done here is largely bespoke to GFG and of no use to other charities or C-ePOD/eServ customers.
-'''Required development for label printing'''
-Design required label format containing at least (for example GFG):
-* "GONE FOR GOOD" - fixed or site name
-* Unique container ID - as generated
-* Charity - Owner Name
-* Charity Destination Location - Alternate (delivery address) name or line 1
-* Donor Name - Customer or Job Address Name
-Other CFC customers may require bespoke labels. It is believed that the above format will not be entirely suitable for anyone except GFG.
-{{Note}} The following progress has been made on this change, during evaluation:
-* On-device code prototyped:
-** Merge and format labels
-** Generate container ID format
-** Print labels via Bluetooth printers in ZPLII format.
-** GFG label format already created.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Label Printing - Common:Core + Common Product
-}}
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}A
-|Definition=Label Printing - Common:Core + Additional
-}}
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}C
-|Definition=Label Printing - Add Brother Printers
-}}
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}D
-|Definition=Label Printing - GFG/CFC Label Formats
-}}
-'''Total Dev:'''
-* Common Changes:
-** Core: 11.0d
-** Product: 11.0d
-* Label Formats - 2.5d
-'''Ballpark:''' between 14d and 24.5d, depending on options.
-== POD based on Gift Aid entries in T&Cs ==
-The C-ePOD system has been modified to support a configurable variety of formats of Charity Gift Aid Declaration forms. These have been added through Sub-forms.
-Currently, C-ePOD does not have a facility to print or generate these as PDF files.
-The Configurable POD process must be modified to support this.
-It is expected that the following are the requirements:
-* The primary document required will be a POC.
-* This will be used for the customer and for the gift aid declaration, if present.
-* They may be different per charity.
-Scope:
-* A single POD/POC format
-* A first page showing the collected items and the TNCs (minus the Gift Aid declaration.
-* A second page showing the Gift Aid declaration, if present.
-* Although this will allow for a fair amount of customisation of these reports (in terms of look and feel and hiding fields), it will not be completely customisable (in terms of moving items around into multiple columns or grouping items together). There will also be no facility to identify individual fields in a sub-form. All of these can be completed, but at a later date.
-Development Required:
-* Existing extractions of full TNCs must be modified to exclude Gift Aid options.
-* Existing extractions of a single UDF Field must be modified to recognise buttons with sub-forms, and extract them as a full form with all values.
-* Each field extracted in this way will be strongly classed and ID'd for each field, so that it can be formatted using CSS for each report required.
-* Assuming a single format developed (a combination of Standard Container POD + Gone for Good Gift Aid Declaration page)
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=POC based on Gift Aid entries in T&Cs
-}}
-'''Total dev''': 3.5d
-'''Ballpark''': 7.75d
-== Unplanned Ad Hoc Collection from any location ==
-Currently v1 customers are using ''CALIDUS'' VEhub to do an ad hoc collection at an address without recording the address, with no printed labels, not recording the label IDs or address, using MCB to record Gift Aid.
-Currently, C-ePOD allows creation of an Unplanned Ad Hoc Collection at the point of the prior job just completed.
-In order for them to use v2 Lite as a replacement solution through a single app, C-ePOD must allow drivers to create a collection from any point.
-The proposed process will be:
-* Drivers will have a load created for them with an Unloading job (and potentially many planned collection jobs).
-* At any point, the driver may select the option 'Unplanned Collection' from the Job List menu.
-* The device will then:
-** Obtain the address from a reverse geocode lookup from the device's current GPS coordinates.
-** The address selected will be displayed on the device, allowing the user to modify this if necessary, and enter the donor (customer) name and contact details.
-** The device will also allow selection of the group, which will define the charity for which they are collecting.
-** Once entered, the device will create the ad hoc collection as it would any other, and start the job.
-** Ad Hoc Container Scanning and printing can still be done as per normal collections.
-** Gift Aid declarations will still be prompted for, in the correct format.
-* Once complete, the C-ePOD server and TTM will display the newly-created job on the trip.
-Required development:
-* Add configuration to the Unplanned Ad Hoc Collection process (in Admin and on device) to:
-** allow any address to be selected.
-** allow Group/Owner to be selected.
-* Device to reverse geocode from GPS coordinates
-* Create customers from this information on the device, linked to the job.
-* Create customers from this information on the server.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|Definition=Unplanned Ad Hoc Collection from any location (v2 Lite)
-}}
-'''Total dev''': 4.0d
-'''Ballpark''': 8.5d
-{{Note}} The process listed above would require additional development in C-TMS before this process could be used in v2, in order to:
-* Add/Lookup a location (from the customer)
-* Add a stop to the trip.
-This would add 1.5d dev.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|Definition=Unplanned Ad Hoc Collection from any location (v2)
-}}
-'''Total dev''': 5.5d
-'''Ballpark''': 12.0d
-== Screen to create loads per vehicle per day, with loading and unloading jobs created automatically ==
-As can be seen above, when using C-ePOD without interface to C-TMS requires that users create a load per vehicle per day, and then create a single job for unloading on that day back at the depot, in order to keep the load open.
-Without an open load, it will not be possible to operate C-ePOD devices.
-Two possible solutions are:
-* Ensure that a load is manually created per vehicle per day
-* Change C-ePOD to work without a load.
-The latter change is not appropriate - not only is this a fundamental concept of C-ePOD, the pre-planned jobs (a requirement of this solution) will still require a load.
-Therefore the users must create them when required.
-The users must take care to create a load per vehicle per day.
-It is up to the users whether they choose to create linked jobs to unload the collected items.
-However, the load will be automatically closed when all planned jobs are completed.
-It therefore makes sense to create an unloading job for end of day, for each load on each vehicle.
-Further, the device users must be made aware that the unloading job (or jobs) are NOT to be completed until they return to the base.
-Although this process of manually creating loads and unloading jobs will work, this is a considerable amount of work for the admin users to complete each day.
-In order to make this easier to create, a screen is proposed that allows the user to create these loads on demand.
-The process would be:
-* The user selects a day.
-* All available vehicles in the system are shown, along with any load associated to that vehicle (or none).
-* Any vehicles without a load on that date are automatically checked.
-* The user can check or un-check any vehicle from the list.
-* Clicking "Create Loads" will pop up a detail entry screen, to allow the user to specify the start and end dates and times for the loads created on that day. The Start Date will default to the date selected and cannot be changed, the end date can be moved on if desired, but will also default to the date selected.
-* The user will also be able to select whether to create a loading job or unloading job back at the site location.
-* Confirming on this screen will create a load for each vehicle, assigned to that vehicle, for the dates and times specified, creating loading or unloading jobs as required.
-* The screen will refresh, and will allow similar options to the Load screen (as developed in the improved job assignment development above).
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Screen to create loads per vehicle per day, with loading and unloading jobs created automatically
-}}
-'''Total dev''': 3.0d
-'''Ballpark''': 6.25d
-== Interface to UK Changes (supporting existing C-TMS Trip/Order format) ==
-In the v2 implementation, all pre-advised jobs come from UK Changes into C-TMS in the TripOrder XML format.
-In v2 Lite, there would potentially be no C-TMS.
-Potentially, C-ePOD could be modified to receive jobs in TripOrder XML format.
-{{Note}} It has been confirmed that UK Changes will NOT be in play for v2 Lite, and therefore there is no development required here.
+== Printer Selection ==
+If the site is set up for printing (as it is expected to be), the device starts the Printer Selection process after log-on:
+*	The device prompts for a printer, showing all Bluetooth printers paired with the device, and an option to choose "No Printer".
+*	The driver selects one.
+Once selected, the load and job list is shown.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Interface to UK Changes (supporting existing C-TMS Trip/Order format)
-}}
+== 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 (or vehicle), the device will tell the user that there is no work available. The driver can exit, or try to download again.
-== Show Load map for all jobs on load, numbered ==
-In the v2 Lite implementation, there is no automatic planning (excluding any other potential changes in this document).
-The C-ePOD product changes regarding job assignment to loads will seriously increase the speed of this process, but there is no indication that this is a reasonable route plan.
+<gallery widths=300px heights=210px perrow=2>
+File:REQ_354306_PDA_JobList2.png|''Job List''
+</gallery><br />
-Without the automatic route optimisation or building changes below, it will be necessary to view the stops on a map to allow reasonable route optimisation.
-The most basic way that this can be done is to leverage the existing map showing facility in C-ePOD Admin, utilising Google Maps.
+The Job list on the mobile device is expected to be styled so that only the following items are displayed:
+* The planned date and time
+* The job number (the job code)
+* The location (address name)
-The new Job Assignment screen and existing Load screen would be modified to include a Map button.
-This would retrieve the jobs in sequence (and date/time), and build points on a Google Map, highlighted with labels and pop-up information.
+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).
-This is very similar to the existing way the the User Tracking screen shows the Load life-cycle, and can be built based on that.
+The jobs are displayed in the sequence in which they should be completed.
+However, the jobs can be viewed in any sequence by clicking the line of the job - the device will display the Job Details page.
-{{SCR
+The '''Menu''' button can be used here to allow the following options:
-|Reference={{#var:Reference}}
+*    ''Show All / Outstanding Jobs'' - Toggle between showing all or only incomplete jobs.
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+*    ''Refresh'' - Refresh the Load/Worklist
-|Definition=Show Load map for all jobs on load, numbered.
+*    ''Settings'' - Show the Settings screen
-}}
-'''Total dev''': 1.5d
-'''Ballpark''': 3.0d
+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 not be allowed at any time. Jobs with the same sequence (i.e. non-timed jobs) may be completed in any order, although not before any timed jobs i.e. jobs that are lower in sequence.
-This could be extended to show the map as a panel on the Job Sequence screen, updating automatically as each job is sequenced and/or consolidated.
+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. It is noted that this should not occur.
+The driver has an option to change the label printer from the hamburger menu here, which re-starts the Printer Selection process described above.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}A
-|Definition=Always show Load map for all jobs on load, numbered, updated automatically.
-}}
-'''Total dev''': 3.0d
+== 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.
-'''Ballpark''': 6.0d
+<gallery widths=300px heights=210px perrow=2>
+File:REQ_354306_PDA_JobDetail3.png|''Job Details''
+File:REQ_354306_PDA_JobDetail4.png|''Instructions''
+</gallery><br />
+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 Instructions for the job.
+Clicking on the tabs will display the information.
-== Route Building via PTV ==
-To include route building via PTV, C-ePOD requires an import and export process.
-{{Note}}
+The ''Instructions'' tab will show instructions for the job, as well as any additional information passed through for the job.
-* This applies to v2 Lite - in v2, it would be expected that C-TMS would control planning of trips, whether it uses an external optimiser/builder or not.
-* This solution is simplified and does not include the settings up of profiles and projects or resource data - it is assumed this is already created and correct. The following is an example of the kind of setup required.
-** Projects and Profiles
-** Number and type of vehicles, potentially including capacity information.
-** User Shifts and Vehicles
-** Products (potentially DUs in use in the system) potentially including weight and volume information.
-** Settings such as:
-*** Call times per location
-*** Load/Unload times per DU (Product in PTV)
-* Licenses are required for PTV Route Optimiser - these costs are not included here.
-* This process assumes one profile per site, used for all days, with automatic importing and exporting.
-* Implementation costs regarding configuration and setup of PTV Route Optimiser are NOT included in this estimate.
-Scope:
+{{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.
-* Providing all loads and jobs to PTV Route Optimiser through web service calls.
-* Automatically importing jobs and built routes from PTV Route Optimiser.
-* The process assumes that ALL loads and jobs for that day will be planned via PTV Route Optimiser - none can be excluded.
-* The process is designed to work with pre-advised containers. If products are being used, modifications to the interface will be required.
-* The process does NOT include the facility to fix times for a particular job. This will be partially provided through Collection/Delivery Windows, and optional development (see later).
-{{Note}} PTV Support have inferred there is a simpler method for route building but have not provided details.
+=== Cancelling a Job ===
+The driver can cancel jobs by clicking the '''Cancel Job''' button on the job detail screen.
-PTV Route Optimiser will be set up as follows:
+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.
-* Products for each of the C-ePOD DUs, with an average weight and volume.
-* Loading and Unloading times at Depot
-* Loading and Unloading standard times for locations
-* Loading and Unloading times per Product (DU).
-* Users and Shifts
-* Numbers of Vehicle types, including capacity information.
+{{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.
-Orders are created in C-ePOD with the containers and the Package Code (DU).
+If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.
-{{Note}} Given that C-ePOD and PTV must have matching DU types for the jobs to plan in PTV, C-ePOD must restrict the entry of package code to predefined values. In this case, the C-ePOD Admin Container Entry/Edit pop-up screen will be modified to present a drop-down list of existing DU codes. When a DU code is selected, the Package Code will be set from this, and the Package Description will default from the Package Code.
-The system will be modified with settings for PTV Route Optimiser through XF Config settings against the site. This will point to the web services and identify the Route Builder as PTV.
+== Navigation and Arriving ==
+The screen will show a Navigation icon, which can be clicked to start navigation through the installed navigation app. For TomTom devices, this will be the TomTom NavApp, which can be linked to WEBFLEET.
-A new screen will control calling PTV Route Optimiser if configured.
+The TomTom NavApp will be sent the address by the C-ePOD app, and will commence immediate navigation to the address.
-This screen will allow selection of the date, and display the number of loads and jobs on that day (broken down by job type, planned or unplanned).
+The driver will select '''Start Job''' from the Job Details screen.
-The screen will offer options to plan the date or to upload a previous plan from PTV.
+{{Note}} 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.
-On selecting to plan the date, all loads and jobs that are not in progress, complete or cancelled will be sent to Route Optimiser in the required format.
+{{Note}} It is expected that re-sequencing of jobs will not be allowed for jobs. If a job is attempted to be started, arrived or delivered out of sequence, the user will be told this at this point and will not be allowed to continue. Note that the application can if desired be configured to only issue a warning in this case, rather than prevent it outright.
-Jobs will include:
-* The Job Code and ID.
-* Address details from Job Address or Customer, whichever is applicable.
-* Numbers of DUs calculated from pre-advised containers.
-* Up to 2 Collection/Delivery Windows against the Job Address or Customer, whichever is applicable.
-{{Note}} See additional changes below regarding Collection/Delivery Windows.
-The file will be sent to the web service with an indicator to show that this should be automatically planned. All existing loads will be allowed to be broken and re-planned with new unplanned orders.
+Once started, the device will display a navigation button. Clicking this will commence immediate navigation to the address - the TomTom NavApp will be shown, which will immediately calculate a route to the destination address.
-The EPOD-PTV interface collates the number of each Package Code and advises the order to PTV with each product (DU) and quantity. PTV Route Optimiser will use this information to calculate weight and volume and can use this to plan.
+The Lat/Longs on the job (if present) will be used for navigation, otherwise the address will be evaluated at that time and used for navigation.
+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.
-If the upload is successful, the process will wait and check for results, indicating this to the user of the screen. If this times out, the user will be informed and told to investigate with PTV Route Optimiser.
+The driver will then indicate arrival and start processing the Job by clicking the '''Arrive Job''' button.
-When the jobs have been planned, the web service will indicate that this is complete. The process will then offer to upload the routes created. At this point the user can use PTV Route Optimiser directly to make any manual changes.
+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.
-Returning to C-ePOD, if the user chooses to do so, this plan will uploaded into C-ePOD at this time. Note that the user can upload this later by choosing the Upload Only option from the main screen.
+The device will move on to the Arrival process.
-The upload process will get the results and:
-* Create Loads with Start and End times, storing the DPS auto-generated route code in the C-ePOD Route Code.
-* Assign jobs to loads and set the Planned Start and End Dates and Times, sequence and consolidation ID, if consolidating.
-* Jobs not on Routes (but in the import file) will be removed from any loads that they are on.
-* Jobs on loads already will be removed if they are not on the created load from PTV.
-* Any empty loads will be removed at the end of the process.
+== Arrival Process ==
+The driver process when arriving at a collection point is:
+* Arrive at site, capturing arrival time automatically.
+* Capture Gift Aid information and signature.
-The development required is as follows:
+The driver will press the '''Arrive Job''' button to show arrival at the location.
-* New XF Config settings
+<gallery widths=300px heights=210px perrow=2>
-* New Route Building screen
+File:REQ_354306_PDA_Arrival0.png|''Arrive Job''
-* Export Process
+</gallery><br />
-* Import Process
-* Container Entry/Edit pop-up - lookup on DU Codes
-{{SCR
+On arrival to the location, the terms and conditions will show:
-|Reference={{#var:Reference}}
+* A facility to enter an existing Gift Aid ID for the charity.
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
+* A button to '''Register for Gift Aid'''.
-|Definition=Route Building via PTV
-}}
-'''Total dev''': 11.0d
+<gallery widths=300px heights=210px perrow=2>
+File:REQ_354306_PDA_Arrival1.png|''Arrival Signature and T&Cs''
+</gallery><br />
-'''Ballpark''': 21.5d
+Pressing the '''Register for Gift Aid''' button will open a form to enter the Gift Aid Registration details.
-== Route Optimisation via PTV ==
+<gallery widths=300px heights=210px perrow=2>
-This process is similar to route building with PTV and is expected to utilise the same interface format. It will utilise the same interface parameters, so that Route Building and Route Optimisation can be delivered together as services to customers, for those that have paid for PTV Route Optimiser.
+File:REQ_354306_PDA_Arrival2.png|''Gift Aid Registration''
+File:REQ_354306_PDA_Arrival3.png|''Gift Aid Registration''
+File:REQ_354306_PDA_Arrival4.png|''Gift Aid Registration''
+File:REQ_354306_PDA_Arrival5.png|''Gift Aid Registration''
+</gallery><br />
-{{Note}} All of the same scope and assumptions are in place as per Route Building via PTV Route Optimiser.
+The Gift Aid Registration form will show the following:
+* Several text labels describing the Gift Aid process:
+* A check-box to confirm Gift Aid, which must be checked.
+* The charity name, defaulted from the job, required to be entered.
+* Name, defaulted from the contact name on the job, required to be entered.
+* 4 lines of address, defaulted from the job address, 1 line required to be entered.
+* Post Code, defaulted from the job address, required to be entered, validated as a UK post code.
+* Date, defaulted to the current date, required to be entered.
+* A '''Confirm''' button to save the Gift Aid Registration details.
+* A '''Cancel''' button to discard the Gift Aid Registration details.
-In the Load screen, an '''Optimise''' button will be added to the button bar in the header if the data has been selected (at least) by a date. When pressing this button, all loads that are not in progress, complete or cancelled on that planned date will be sent to Route Optimiser in the required format.
+Any fields with a default value will be shown with the value of the data from the job.
-In the Load screen, an '''Optimise''' button will be added against the actions available per load displayed, either as a button on the results table line, or in the Load Actions pop-up window. When pressing this button, only that load will be sent to Route Optimiser in the required format.
+{{Note}} This form will not be required to be completed, and the provided '''Cancel''' button bay be used to return to the Arrival Signature.
-In the Job Assignment screen, an '''Optimise''' button will be added to the button bar in the header. When pressing this button, only the load being built will be sent. The jobs will be saved onto the load first to Route Optimiser in the required format.
+Once complete and saved, the customer will sign for the collection.
-Jobs will include:
+The information on the device will be passed back to ''CALIDUS'' TMS. The signature and T&Cs (along with any completed Gift Aid declaration or existing Gift Aid ID) will be stored against additional order information when the collection has been confirmed as complete.
-* The Job Code and ID.
-* Address details from Job Address or Customer, whichever is applicable.
-* Numbers of DUs calculated from pre-advised containers.
-* Up to 2 Collection/Delivery Windows against the Job Address or Customer, whichever is applicable.
-{{Note}} See additional changes below regarding Collection/Delivery Windows.
-The file will be sent to the web service with an indicator to show that this should be automatically planned. The optimiser will be called with a parameter to ''only'' re-optimise the jobs on the loads - no loads will be broken and no jobs will be added.
+{{Note}} The arrival signature process itself will be configured so that the driver can skip this process entirely if the customer is not a registered gift aider, nor desires to register.
-If the upload is successful, the process will wait and check for results, indicating this to the user of the screen. If this times out, the user will be informed and told to investigate with PTV Route Optimiser.
-When the jobs have been planned, the web service will indicate that this is complete. The process will then upload the optimised loads into C-ePOD.
+The device will move on to the Collection process.
-The upload process will get the results and modify the jobs on the loads as follows:
-* Update the Loads with the Start and End times.
-* Update the jobs on the loads and set the Planned Start and End Dates and Times, sequence and consolidation ID, if consolidating.
-The screen will then refresh and show the results.
+== Collection Process ==
+The driver process at a collection point is:
+* Confirm items collected.
+* Complete collection and capture customer signature.
-The development required for this requires much of the same work as the PTV Route Builder. The work required is:
+Collections will initially consist of no items to be collected.
-* Add buttons to Load and Job Assignment screens
-* Add process to control PTV web services
-* New XF Config settings
-* Export Process
-* Import Process
-* Container Entry/Edit pop-up - lookup on DU Codes
+The following are the standard tabs that are expected to be displayed:
+<gallery widths=300px heights=210px perrow=2>
+File:REQ_354306_PDA_Collection1.png|''Job Details Tab''
+File:REQ_354306_PDA_Collection2.png|''Job Details Tab - Addresses''
+File:REQ_354306_PDA_Collection3.png|''Ad Hoc Tab''
+File:REQ_354306_PDA_Collection4.png|''Notes Tab''
+</gallery><br />
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|Definition=Route Optimisation by PTV
-}}
-'''Total dev''': 8.75d
+The ''Job Details'' tab has multiple sections:
+* Contact information
+* Address information - if supplied, both current address and origin address are shown.
+* Job Instructions
-'''Ballpark''': 17.75d
+The driver clicks the '''New Item''' button which shows a pop-up:
+*	The driver selects the DU from list, for example, BAG, BOX, LARGE ITEM, etc.
+*	The driver selects the job destination (if consolidated).
+*	If multiple labels are configured to be allowed to be created, the driver can also select the number of items to create/labels to print i.e. create 4 "BAG" items for destination "My Charity Store".
+The label (or labels) will then be printed.
+A confirmation dialogue will be displayed, allowing the driver to:
+*	Confirm printing OK.
+*	Reprint the label (or labels).
+*	Change the printer (through the Printer Selection process above).
+The items created will be added to the list of items automatically.
-If developed together with PTV Route Building, the full development required is as follows:
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-* Add buttons to Load and Job Assignment screens
+|Definition=Ad Hoc Item Generation and Label Printing
-* New XF Config settings
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
-* Add process to control PTV web services
-* New Route Building screen
-* Export Process
-* Import Process
-* Container Entry/Edit Pop-up - lookup on DU Codes
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|Definition=Route Building and Optimisation by PTV
 }}
-'''Total dev''': 13.75d
-'''Ballpark''': 26.75d
+The driver can reprint any single label by long-pressing on the added item and select "Print Label" from the pop-up options.
-== Route Optimisation via HERE maps ==
+If a label is damaged or not required, the driver can remove an item by long-pressing on the added item.
-HERE maps provides mechanisms to:
-* Find the time between stops (waypoints)
-* Suggest a sequence for the stops.
-The sequencing process also seems to be able to take into account time at waypoints and at least a two delivery window restrictions per waypoint. The process can also take into account vehicle type (car, truck or tractor/trailer), height weight and length restrictions, and other road restrictions (like tunnels).
+A single generic label format will be designed and delivered with the software. The label format has been prototyped and is shown below:
-Integrating this into C-ePOD would be a similar process to integrating PTV above, but this is a simpler interface.
+[[File:REQ_354306_Label.png|border|200px]]
-Scope:
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-* GPS co-ordinates (Lat-Longs) are required for every point (job address or customer).
+|Definition=Label Format
-* A Nokia account of sufficient authority to use the waypoint sequence webservice (Tier 4).
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
-* The Load must have a start planned date and time.
-* The solution below does not include any calculation of minutes at each point through loading or unloading minutes per stop or minutes per DU. Instead this uses a fixed parameter for every stop. This seems compatible with a "Lite" solution, but could be added at additional cost.
-* There is a limit of 150 addresses that can be sequenced. Any more than that should not allow optimisation.
-In the Load screen, an '''Optimise''' button will be added to the button bar in the header if the data has been selected (at least) by a date. When pressing this button, all loads that are not in progress, complete or cancelled on that planned date will be sent to HERE maps in the required format.
-In the Load screen, an '''Optimise''' button will be added against the actions available per load displayed, either as a button on the results table line, or in the Load Actions pop-up window. When pressing this button, only that load will be sent to HERE maps in the required format.
-In the Job Assignment screen, an '''Optimise''' button will be added to the button bar in the header. When pressing this button, only the load being built will be sent. The jobs will be saved onto the load first to HERE maps in the required format.
-The process will be configured by default to:
-* Truck navigation.
-* A configurable stop time (the same for each stop, for example, 5 minutes).
-* GPS co-ordinates of the Job Address or Customer, whichever is applicable.
-* A single Access Window against the Job Address or Customer, whichever is applicable.
-{{Note}} See additional changes below regarding Collection/Delivery Windows.
-{{Warning}} Whilst prototyping, setting the Access Window caused the HERE maps web service method to crash. Until this is confirmed working, this functionality must be excluded from the final released software, but should be developed anyway, in preparation for a fix.
-The file will be sent to the web service, consolidating jobs where applicable.
-The HERE web service will return the results, including:
-* Location sequence
-* Arrival and Departure time from each point
-The upload process will get the results and modify the jobs on the loads as follows:
-* Update the Loads with the Start and End times.
-* Update the jobs on the loads and set the Planned Start and End Dates and Times, sequence and consolidation ID, if consolidating.
-The screen will then refresh and show the results.
-The development required is as follows
-* Add buttons to Load and Job Assignment screens
-* New XF Config settings
-* Export Process
-* Import Process
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Route Optimisation by HERE
 }}
-'''Total dev''': 4.25d
+The label format is expected to contain:
+* The charity store (the site name).
+* The item barcode.
+* The charity name (the owner name).
+* The donor name and address.
-'''Ballpark''': 8.25d
+{{Note}} Any additional label formats required by individual charities will accrue additional cost.
-== Route Optimisation via Google Maps ==
+When all items have been confirmed as collected, the user will return to the ''Job Details'' tab, where a '''Complete''' button will be displayed, to complete the job.
-{{Warning}} It has been determined that the Google Maps API does not provide a service to do this.
-{{SCR
+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.
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Route Optimisation by Google Maps
-}}
-== Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screens ==
+== Job Completion ==
-In order to support manual planning in C-ePOD (i.e. without an automatic Route Builder), we have modified the job assignment screen to make it more functional.
+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.
-As this is now likely to become more used, we need to drag in features relating to additional filtering options based on geographical region.
+{{Note}} At this time, the expectation is that the configuration will require only the Customer to sign for collection of goods. It is an optional configuration for {{#var:System}}, where customer and driver signatures can be enabled or disabled for collections, and whether the device will prompt for Job Photos after signature.
-'''Basic solution:'''
+The device will prompt for Customer Signature.
+<gallery widths=300px heights=210px perrow=2>
+File:REQ_354306_PDA_Signature1.png|''Customer Signature and T&Cs''
+File:REQ_354306_PDA_Signature2.png|''Customer Signature and Items (Containers)''
+</gallery><br />
-This solution adds the Postal Area and District to the screens that need it, allowing for selection, filtering and sorting as required.
+The signatory will by configuration be set to be blank and always required entry. The driver will be forced to enter one.
-* New fields on EPOD_JOB/EPOD_CUSTOMER
+The screen displays several tabs, allowing the user to see:
-* Not required on EPOD_JOB_ADDRESS if we have it on job.
+* Terms and Conditions, plus any data entry the user is required to confirm.
-* Automatically set the Postal Area and District from the postcode when saving Job Address or Customer.
+* The items being collected.
-* Manual entry of Planning Region against Job or Customer.
-* Automatically trigger updating of (non complete or cancelled) jobs when changing Job Address or Customer postcode or planning region.
-* Add Postal Area, District and Planning Region to the job assignment and jobs screens, so they can be sorted and selected.
+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.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|Definition=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen
-}}
-'''Total dev''': 2.75d
+The device can be configured to handle unmanned collections. On the device, if configured, the device will have a button on the screen, labelled as '''Unmanned Location'''.
-'''Ballpark''': 5.75d
+If a signature is entered in the customer signature screen, the screen will change this button to "Done", so that the driver can accept the customer signature.
+If a customer is not available, the driver can click the Unmanned Location button. The device will prompt for confirmation from the driver that no customer is available to sign for the job.
-'''Fully featured solution:'''
+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 solution allows for the users to create tables of Planning regions, with inclusions or exclusions of Postal Areas, Postal Districts or other Regions. These are then used when saving a customer or job address to automatically set the planning region from the configured codes, or leave as blank.
-The development for this is as the above basic solution, plus the following development:
+If driver signature is required, this displays very similarly to the customer signature above, with some differences:
+* Only T&Cs if configured will be shown on the tabs.
+* 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.
-* New Planning Region tables or Zone tables.
-* New Admin screens to maintain Planning Regions.
-* Create by including Postal Districts (e.g. L17) or Areas (e.g. WA) to a planning group.
-* Can also add exceptions e.g. not in District L17, or Area WA or Region R1
-* Automatically set the Planning Region by checking these tables when saving a Customer or Job Address, if the planning area or district has changed.
+The process can be configured to prompt for photos after completion of the signatures for collections.
-{{SCR
+It is expected that this will either be optional or not configured at all.
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|Definition=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen and automatically assign region to the job
-}}
-'''Total dev''': 6.25d
-'''Ballpark''': 11.75d
+As each job (or group of jobs) is completed, the information is updated back to the system, with all information captured on the device (actual times, quantities, signatures, images, etc) updated. The updates are sent whenever the driver has an internet connection, and may be delayed until that time.
+The user will be returned to the Job List screen and the completed Job will be removed from the list. Any completed jobs can be optionally viewed again, by pressing the Menu button and choosing ''Show All Jobs''. The list can be made to show only outstanding jobs again by pressing the Menu button and choosing ''Show Outstanding Jobs''.
-== Pre-advise Collected DU Quantity and Weight ==
-The orders for v2 Lite (when pre-advised) are going to be manually entered.
-If manually entering containers, and they want to (for example) collect 7 bags, they would have to manually enter 7 containers and manually enter 7 unique container IDs. Although possible, this is awkward.
+== Post-Load ==
+Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.
-{{Note}} It is not expected that orders created in v2 Lite will include pre-advised containers. It is much more likely that the orders will be created without containers at all.
+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.
-This will prove a problem for those automatic route builders or optimisers that use DU types to calculate weight or volume, for example PTV.
-Therefore it is required that the system resolve this, to allow advice of containers or , in limited detail, the quantity of DUs being collected.
-There are 2 proposals:
-* Pre-advise Multiple Containers manually
-* Pre-advise DU count only
-{{Note}} It is NOT required that any optimiser or builder know the weight or volume of each item to be collected, nor the total weight or volume on the order - these can operate without this information. This functionality is being created solely for those operations that request this and, as such, should not be part of the core developments needed to achieve v2 Lite, but instead optional developments either as part of a later product phase or funded by the operations themselves.
-=== Pre-advise Multiple Containers manually ===
-In C-eEPOD Admin, when creating new containers through the '''New Container''' button, a facility will be added to create multiple containers here (if configured to do so), through a new '''Add Multiple''' button.
-The screen would start in Multiple or Single "mode" depending on the configuration.
-Clicking the "Add Multiple" button will switch to that mode and switch the button to '''Add Single'''
-In that case, the top line of the pop-up entry screen (consisting of the Container ID and Sequence) will be replaced by a "Number to Create" entry field.
-A non-zero number must be entered.
-When saved, this will generate the number of containers required with the attributes set from what was entered. Additionally:
-*	The container ID would be generated from the same pattern that would be used when creating items in Ad Hoc Collection with the new label printing functionality (so this functionality is dependent on that development).
-*	The sequence would be set to the next highest value automatically.
-*	The process would ensure that no duplicates are created (in case some have been manually entered)
-The standard entry screen will also be modified so that the container ID and sequence are defaulted when creating a single container in normal circumstances. These will be default values.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|Definition=Pre-advise Collected DU Quantity and Weight
-}}
-'''Total dev''': 1.00d
-'''Ballpark''': 2.25d
-=== Pre-advise DU count only ===
-There is no mechanism in EPOD by which numbers of items or DUs can be pre-advised.
-However, currently C-TMS has a mechanism whereby it uses UDF to pre-advise the DU quantity against the order.
-{{Warning}} '''Using this process means that Job UDF ''cannot'' be used, as UDF has already been provided.'''
-This is used for display only on the device.
-However, this may be used as a kind of pre-advice of DUs and items for optimisers/route builders.
-When creating the job, the user would select the DU type and enter the quantity against each, in a new panel of the Edit/Create Job pop-up.
-This would be controlled through a new value of the EPOD System flag, set to "Charity".
-When saved, this would save into the Job UDF.
-When showing the form, this would load the UDF into a table for editing.
-This information would then be used when optimising or creating routes.
-The alternative to this process is to create a "job detail" table in EPOD to store this information, which would be much more expensive. This has not been estimated.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|Definition=Pre-advise Collected DU Quantity and Weight
-}}
-'''Total dev''': 2.5d
-'''Ballpark''': 5.5d
-== Use C-ePOD for VEhub functionality ==
-''CALIDUS'' VEhub has the following functionality:
-* Vehicle Checks
-** Configurable Vehicle Checks
-** Vehicle Check Templates
-** Vehicle Check Alerting
-** Unchecked Vehicle Alerting
-** Defect resolution
-* Accident Reporting
-** Configurable Accident Reports
-** Accident Report Alerting
-* Resource Tracking (e.g. Trailers)
-* Unplanned Charity Collections
-''CALIDUS'' ePOD already has the following functionality
-* Vehicle Checks
-** Configurable Vehicle Checks
-** Different checks per vehicle type (by description, equivalent to Templates)
-** Enforced (ensure checks are done as required) and Ad Hoc (any time) Vehicle Checks
-** Defect resolution
-{{Note}} Accident Reports have been prototyped in the device code and can be reactivated.
-{{Note}} The above are summaries only - both systems include additional functionality.
-In order to achieve similar functionality in C-ePOD as in VEhub, the following changes must be made:
-* Vehicle Check Alerting
-* Accident Reporting functionality
-Unplanned collections have already been dealt with in this document, and Trailer ID entry is already part of C-ePOD functionality.
-=== Vehicle Check Alerting ===
-For Vehicle Check alerting, a new interfaces must be created to generate emails to defined addresses whenever a defective vehicle check occurs. This will be achieved through the existing Auto-Export process, by adding a new Export Type for Vehicle Checks. This process will allow the user to determine whether all or just defective vehicle checks are alerted.
-For Unchecked Vehicle alerting, new site parameters must be created to determine the period and start time.
-A new interface will be created for unchecked vehicles, to email a list of all vehicles that have not been checked within the period.
-The Auto-Export process will be modified for this, and to reset the Next Check date and time after running.
-The required development for both is:
-* XF Config screen modified for new types for Vehicle Check Alert and Unchecked Vehicles interfaces
-* Auto-export modifications.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|Definition=Vehicle Check Alerting
-}}
-'''Total dev''': 2.0d
-'''Ballpark''': 4.25d
-=== Accident Reporting ===
-Accident reporting will need to be added to C-ePOD. This has already been prototyped and should be used.
-The process would be configurable through UDF (as vehicle checks)
-The development required is:
-* New Accident Report tables in the database.
-* New Accident Report format parameter against the Site.
-* New Accident Report UDF type.
-* New Accident Report option on the Job List menu.
-* New Accident Report Update web service, to store the accident reports.
-* New Admin screen to see Accident Reports
-* New Accident Report format
-* XF Config screen modified for new type for Accident Report Alert interface
-* Auto-export modifications.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|Definition=Accient Reports and Alerting
-}}
-'''Total dev''': 6.75d
+== 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.
-'''Ballpark''': 13.25d
+All photos taken by the driver during the execution of the job (i.e. at cancellation of job, job photos) will be displayed in the C-ePOD Admin system for the administrative users to view.
-{{Note}} If combined with the above Vehicle Checks changes, the resulting cost will be cheaper:
+{{Note}} CALIDUS ePOD will be modified to create a single generic Charity Fleetcare POD/POC format, containing:
+* A front page detailing the charity, collection information, items collected and signature, signatory, date and time. Any existing
+* A second page showing the Gift Aid Registration form, if captured against that job.
-{{SCR
+{{SCR|Reference={{#var:Reference}}|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Reference={{#var:Reference}}
+|Definition=Charity Fleetcare POC Format
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}
+|Link=Appendix A: Table of SCRs and Ballpark Estimates
-|Definition=Combined Vehicle Checks and Accident Reports
 }}
-'''Total dev''': 7.25d
+The format of the POD note has been prototyped to show capability. The format has been provided and the prototype is shown below:
-'''Ballpark''': 13.75d
-== Entering Collection/Delivery Windows ==
-The C-ePOD database allows for external systems to specif Collection or Delivery windows. Core C-ePOD does not use these.
-However, in order to constrain planning through an external Route Optimiser, some concept of window must be obtained.
-Because the Route Building process is setting and overwriting the planned times, these cannot be used in re-planning jobs that have already been planned against a load through Route Optimiser. Therefore the entry and maintenance of Collection and Delivery windows against a job or customer/location must be added to C-ePOD if route building (and some of the potential Route Optimisation process) is to be used.
-{{Note}} In terms of optimisation:
-*	PTV Route Optimiser supports up to 2 non-overlapping windows.
-*	It is believed that neither HERE nor Google maps support any kind of fixed delivery window - both require further investigation.
-C-ePOD does not limit entry or non-entry of windows - users can enter as many as they like against a customer or job, and must take care not to enter more than their chosen optimiser can support.
+[[file:REQ_354306_POC.png|border|600px]]
+<br />''Prototype Charity Fleetcare POC Format''<br />
+[[file:REQ_354306_GiftAid.png|border|600px]]
+<br />''Prototype Charity Fleetcare POC Format''<br />
-C-ePOD will allow entry of windows against:
+{{Note}} It is expected that a single set of T&Cs for a single job group or for the site will be required. However, the application will allow for different T&Cs (and Gift Aid Registration forms) to be configured for each customer (Job Group in C-ePOD). The POC note format will display all of these checks on a Gift Aid Registration page. Note however that formatting changes cannot be made to this page without further development.
-*	A Customer
-*	A Job Address.
-Any number of (non-overlapping) windows will be allowed to be created in C-ePOD.
-The new screens will also allow the user to set specific job delivery windows, which will set this against the job address (and copy the customer address as a job address if there wasn't one already). Job Address windows will default to the windows of the customer selected.
+The front page contains the POC (Proof of Collection) information as follows:
+* Site Logo.
+* Title "COLLECTION NOTE".
+* Collection Number.
+* Site Address/contact information.
+* Collection Address
+* Order Information.
+* Items collected, with barcode and type.
+* T&Cs displayed when the user signs for the collection. Also includes the Gift Aid ID.
+* The Signature, Name and Date.
-Any entered planned start and end time against the jobs, which users will be required to enter when creating jobs, will be ignored by the optimisation or building engines. If the user enters (up to 2) windows against the job address or the customer, PTV Route Optimiser will respect that. When C-ePOD get the response back from whatever optimiser is being used, the optimiser will indicate the planned start/end date and time again, which will be used to replace whatever the user entered.
+The back page contains the Gift Aid Declaration (if present), as follows:
+* Site Logo
+* Title "GIFT AID DECLARATION"
+* The Gift Aid Form entered on arrival to the collection.
+* The Signature, Name, Date and Time.
-The required development is as follows:
+== Data Export ==
-* A new tab for the Customer maintenance screen, for Windows.
+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 or users. This is also true of cancelled jobs
-* A new tab for the Job maintenance screen, for Windows.
-* Allow copying or setting job windows from customer windows and creating a job address for this purpose.
-{{SCR
+Completed jobs with an email specified on the address will be picked up by a timed process and the POC may be configured to be automatically sent to that email address. The POD will be in PDF format. The email address will be that provided to C-ePOD from the customer record.
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Entering Collection/Delivery Windows
-}}
-'''Total dev''': 2.0d
+{{Note}} This feature requires access to a mail server for the use of the customer.
-'''Ballpark''': 4.0d
+Automatic emails may also be sent to a central email address if required. This may be configured at any time.
+Email subject and content may be configured:
+*	Customer Name.
+*	A/C Number.
+*	Order Reference, one of:
+**	Job ID - ePOD internal unique job reference.
+**	Job Code.
+**	Cust Ref.
+**	SO Ref.
+**	Ext Ref.
+*	Date.
+*	Job Type (Collection).
-== Geocoding by HERE maps ==
+It is also possible to configure the system to send a copy of the POD/POC note at completion of the jobs, for the purposes of updating a Document Management System (DMS). The POD/POC can be sent in image or PDF format, to multiple destinations, by flat file transfer. The POD/POC file can be named with several items to aid identification of which order/job the POD/POC belongs.
-In order for route optimisation to work, C-ePOD needs to have GPS coordinates for our addresses (customer or job). The system currently does this through WEBFLEET geocoder web service calls.
-If the customer is paying for HERE web services, they are unlikely to want to pay for a WEBFLEET subscription to do something that HERE can do and is included in the price.
-Therefore there is a need to evaluate the HERE geocoding functionality and write an interface to use that, as an option to WEBFLEET.
+== Further Reporting and Queries ==
+The {{#var:System}} Admin system allows admin users (i.e. non-PDA users) the ability to access loads, jobs and item (container) details, as mentioned previously.
-The process will be configured as an automated export process in the C-ePOD XF configuration attached to a site or job group.
+<gallery widths=600px heights=300px perrow=1>
+File:REQ_354306_AdminLoad2.png|''Loads''
+File:REQ_354306_AdminJob1.png|''Jobs''
+File:REQ_354306_AdminContainers1.png|''Items (Containers)''
+</gallery><br />
-Every time an address is created or amended, a message will be added to the process to get the Lat-Long of (or geocode) the address.
-The process will call the HERE geocode web service method, passing in a concatenation of the address fields. The fields used will be subject to system configuration, not modifiable by the customer.
+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.
-The results will be stored against the address.
+POD/POC reports and full collection details can be accessed from this screen.
+<gallery widths=600px heights=300px perrow=1>
+File:REQ_354306_AdminJob2.png|''Jobs''
+</gallery><br />
-The development required is as follows
-* New Admin XF Config settings
-* Triggers to write HERE Geocode control messages
-* Auto-Export Process to
-** send the message
-** process the result
+Additionally, this information may be taken from the ''CALIDUS'' Portal system.
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Entering Collection/Delivery Windows
-}}
-'''Total dev''': 3.0d
+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
-'''Ballpark''': 6.0d
+<gallery widths=600px heights=300px perrow=1>
+File:REQ_354306_Admin_UserTracking1.png|''User Tracking - Activities''
+File:REQ_354306_Admin_UserTracking2.png|''User Tracking - Location''
+</gallery><br />
-== Report of Collections, including Gift Aid ==
-The customer has requested a report of all collections that have been completed, where they have identified Gift Aid (either pre-existing Gift Aid ID or signed up for Gift Aid).
-This data is held in UDF, and the report will be required to extract the UDF fields into the returned record-set so that the values can be collated and counted/reported correctly.
-The development required is as follows
-* Add new report to Excel Reports - 0.5d
-* Create query for the report - 1.0d
-{{SCR
-|Reference={{#var:Reference}}
-|SCRNo={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|Definition=Report of Collections, including Gift Aid
-}}
-'''Total dev''': 1.50d
-'''Ballpark''': 3.50d
 <!-- MEDIA LANDSCAPE YES -->
 = Appendix A: Table of SCRs and Ballpark Estimates  =
-== Appendix A1: All Changes ==
 {{ #vardefine: SCR | 0 }}
 {{REQ_SCR_Header}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Load Building
-|Description=Improved Load Assignment in EPOD
-|Estimate=0.00
-|Notes=&nbsp;
-}}
 {{REQ_SCR_Line
 |SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |System=EPOD
 |Area=Mobile Printing
-|Description=Label Printing - Common:Core + Common:Product
+|Description=Ad Hoc Item Generation and Label Printing
 |Estimate=22.00
-|Notes=2
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}A
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - Common:Core + Additional
-|Estimate=14.00
-|Notes=3
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}C
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - Add Brother Printers
-|Estimate=0.00
 |Notes=&nbsp;
 }}
 {{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}D
+|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
 |System=EPOD
 |Area=Mobile Printing
-|Description=Label Printing - GFG/CFC Label Formats
+|Description=Label Format
 |Estimate=2.50
 |Notes=&nbsp;
@@ Line 1,223: / Line 548: @@
 |System=EPOD
 |Area=Reports
-|Description=POC based on Gift Aid entries in T&Cs
+|Description=Charity Fleetcare POC Format
-|Estimate=7.75
+|Estimate=3.5
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|System=EPOD
-|Area=Collection
-|Description=Unplanned Ad Hoc Collection from any location (v2 Lite)
-|Estimate=8.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|System=EPOD
-|Area=Collection
-|Description=Unplanned Ad Hoc Collection from any location (v2)
-|Estimate=12.00
-|Notes=4
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Load Building
-|Description=Screen to create loads per vehicle per day, with loading and unloading jobs created automatically
-|Estimate=6.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Interface
-|Description=Interface to UK Changes (supporting existing TMS Trip/Order format)
-|Estimate=0.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Load Building
-|Description=Show Load map for all jobs on load, numbered.
-|Estimate=3.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}A
-|System=EPOD
-|Area=Load Building
-|Description=Always show Load map for all jobs on load, numbered, updated automatically.
-|Estimate=6.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Load Building
-|Description=Route Building via PTV
-|Estimate=21.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|System=EPOD
-|Area=Optimisation
-|Description=Route Optimisation by PTV
-|Estimate=17.75
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|System=EPOD
-|Area=Load Building
-|Description=Route Building and Optimisation by PTV
-|Estimate=26.75
-|Notes=5
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Optimisation
-|Description=Route Optimisation by HERE
-|Estimate=8.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Optimisation
-|Description=Route Optimisation by Google Maps
-|Estimate=0
-|Notes=9
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|System=EPOD
-|Area=Load Building
-|Description=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen
-|Estimate=5.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|System=EPOD
-|Area=Load Building
-|Description=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen and automatically assigning region to the job.
-|Estimate=11.25
-|Notes=6
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}A
-|System=EPOD
-|Area=Job Creation
-|Description=Preadvise Multiple Containers manually
-|Estimate=2.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|System=EPOD
-|Area=Job Creation
-|Description=Preadvise DU count only
-|Estimate=5.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Vehicle Checks
-|Description=Combined Vehicle Checks and Accident Reports
-|Estimate=13.75
-|Notes=7
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}A
-|System=EPOD
-|Area=Vehicle Checks
-|Description=Vehicle Checks Alerting
-|Estimate=4.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} }} }}B
-|System=EPOD
-|Area=Vehicle Checks
-|Description=Accident Reports and Alerting
-|Estimate=13.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Job Creation
-|Description=Entering Collection/Delivery Windows
-|Estimate=4.00
-|Notes=8
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Load Building
-|Description=Geocoding by HERE maps
-|Estimate=6.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
-|System=EPOD
-|Area=Reports
-|Description=Report of Collections, including Gift Aid
-|Estimate=6.00
 |Notes=&nbsp;
 }}
@@ Line 1,399: / Line 556: @@
 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.
-#If this change is completed as a product change, use this cost, plus the costs of 2C and 2D.
-#If this change is completed as a bespoke change, use this cost, plus the costs of 2C and 2D.
-#The cost for this change includes C-TMS costs into the estimate above.
-# This changes combines 8 and 9A.
-# This change is a replacement for 12A, and far more functional.
-# This change combines 14A and B.
-# This change is an optional change for PTV Route Building or Route Optimisation changes (8, 9A and B).
-# This change cannot be achieved as the API does not support this.
-<!-- NEW PAGE -->
-== Appendix A2: Minimum Changes ==
-It is expected that the following are the minimum changes required to implement v2 Lite with the functionality as requested:
-{{ #vardefine: SCR | 0 }}
-{{REQ_SCR_Header}}
-{{REQ_SCR_Line
-|SCR=1
-|System=EPOD
-|Area=Load Building
-|Description=Improved Load Assignment in EPOD
-|Estimate=0.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=2
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - Common:Core + Common:Product
-|Estimate=22.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=2D
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - GFG/CFC Label Formats
-|Estimate=2.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=3
-|System=EPOD
-|Area=Reports
-|Description=POC based on Gift Aid entries in T&Cs
-|Estimate=7.75
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=4A
-|System=EPOD
-|Area=Collection
-|Description=Unplanned Ad Hoc Collection from any location (v2 Lite)
-|Estimate=8.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=17
-|System=EPOD
-|Area=Reports
-|Description=Report of Collections, including Gift Aid
-|Estimate=6.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Footer}}
-Notes:
-* If automatic route optimisation is required, consider adding HERE maps optimisation.
-* If automatic route building is required, consider adding PTV Route Optimiser here.
-* If TomTom WEBFLEET is not part of the solution, consider adding Geocoding by HERE Maps here.
-<!-- NEW PAGE -->
-== Appendix A3: Recommended Changes ==
-The following changes would provide the greatest degree of functionality to the product.
-{{ #vardefine: SCR | 0 }}
-{{REQ_SCR_Header}}
-{{REQ_SCR_Line
-|SCR=1
-|System=EPOD
-|Area=Load Building
-|Description=Improved Load Assignment in EPOD
-|Estimate=0.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=2
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - Common:Core + Common:Product
-|Estimate=22.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=2D
-|System=EPOD
-|Area=Mobile Printing
-|Description=Label Printing - GFG/CFC Label Formats
-|Estimate=2.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=3
-|System=EPOD
-|Area=Reports
-|Description=POC based on Gift Aid entries in T&Cs
-|Estimate=7.75
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=4B
-|System=EPOD
-|Area=Collection
-|Description=Unplanned Ad Hoc Collection from any location (v2)
-|Estimate=12.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=5
-|System=EPOD
-|Area=Load Building
-|Description=Screen to create loads per vehicle per day, with loading and unloading jobs created automatically
-|Estimate=6.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=7A
-|System=EPOD
-|Area=Load Building
-|Description=Always show Load map for all jobs on load, numbered, updated automatically.
-|Estimate=6.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=9B
-|System=EPOD
-|Area=Load Building
-|Description=Route Building and Optimisation by PTV
-|Estimate=26.75
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=12B
-|System=EPOD
-|Area=Load Building
-|Description=Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen and automatically assigning region to the job.
-|Estimate=11.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=13A
-|System=EPOD
-|Area=Job Creation
-|Description=Preadvise Multiple Containers manually
-|Estimate=2.25
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=13B
-|System=EPOD
-|Area=Job Creation
-|Description=Preadvise DU count only
-|Estimate=5.50
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=14
-|System=EPOD
-|Area=Vehicle Checks
-|Description=Combined Vehicle Checks and Accident Reports
-|Estimate=13.75
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=15
-|System=EPOD
-|Area=Job Creation
-|Description=Entering Collection/Delivery Windows
-|Estimate=4.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Line
-|SCR=17
-|System=EPOD
-|Area=Reports
-|Description=Report of Collections, including Gift Aid
-|Estimate=6.00
-|Notes=&nbsp;
-}}
-{{REQ_SCR_Footer}}
-Notes:
-* If TomTom WEBFLEET is not part of the solution, consider adding Geocoding by HERE Maps here.
@@ Line 1,598: / Line 563: @@
 |Estimate=N
 |Glossary=EPOD2
-|Ref1=[[FS 340547 PROD-75 Admin Job Assignment Improvements]]
+|Ref1=&nbsp;
-|RefV1=0.2
+|RefV1=&nbsp;
-|RefDate1=24/01/2017
+|RefDate1=&nbsp;
 |REQ=0
 |EST=0

Anonymous

Search

REQ 354306 CFC v2 Requirements: Difference between revisions

Revision as of 17:43, 15 March 2019

Introduction

Objective

Scope and Limitations

Client Requirements

Overview

Data

PDA Login

Printer Selection

Obtain Workload/Job List

Job Details

Cancelling a Job

Navigation and Arriving

Arrival Process

Collection Process

Job Completion

Post-Load

POC/POD Documents

Data Export

Further Reporting and Queries

Appendix A: Table of SCRs and Ballpark Estimates

Appendix B: Document References

Navigation

Wiki tools

Page tools

Categories