REQ 354306 CFC v2 Requirements

From Calidus HUB
Revision as of 17:53, 28 November 2018 by Anw (talk | contribs) (v0.2 - Completed Optimiser estimates)





Aptean Logo.png







Charity Fleet Care

CFC v2 Lite Requirements

CALIDUS ePOD

28th November 2018 - 0.2
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

The systems have been created for implementation as follows:

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

The customer has noted the following:

  • C-TMS may be difficult to use for small charities with small fleets and may be overkill
  • MCB (for Gift Aid) is going to be phased out
  • Maintaining v1 and v2 requires duplicated developments between VEhub and C-ePOD.

There exists then a requirement for an integrated solution with some planning, allowing Gift Aid entry (v2 Lite). C-ePOD + TTM (potentially + VEhub) is seen to be the strongest contender for this.


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.

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 SCR-354306-5: Screen to create loads per vehicle per day, with loading and unloading jobs created automatically
  • SCR SCR-354306-6: Interface to UK Changes (supporting existing C-TMS Trip/Order format)
  • SCR SCR-354306-7: 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


Note 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
  • Mobile Bluetooth label printer (optional) supporting ZPLII language (optional)

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


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:

In summary, this will achieve the following (from sections 3.2 and 3.3):

  • 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 Note: This functionality is expected to be available for evaluation on 27/11/2018 - awaiting confirmation from Neil Appadu.


SCR SCR-354306-1: Improved Load Assignment in EPOD

Total dev: 0d (potentially already completed product development).

Ballpark: 0d.


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:

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

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


Jobs are planned and sent to EPOD.


The driver logs on to device as normal.

As the site is set up for printing, 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.


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


The driver starts and arrives the job.

For pre-advised containers:

  • 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 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 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 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 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 SCR-354306-2: Label Printing - Common:Core + Common Product
SCR SCR-354306-2A: Label Printing - Common:Core + Additional
SCR SCR-354306-2C: Label Printing - Add Brother Printers
SCR SCR-354306-2D: 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 SCR-354306-3: 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 SCR-354306-4A: Unplanned Ad Hoc Collection from any location (v2 Lite)

Total dev: 4.0d

Ballpark: 8.5d


Note 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 SCR-354306-4B: 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 SCR-354306-5: 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 Note: It has been confirmed that UK Changes will NOT be in play for v2 Lite, and therefore there is no development required here.


SCR SCR-354306-6: Interface to UK Changes (supporting existing C-TMS Trip/Order format)


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.

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

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.


SCR SCR-354306-7: Show Load map for all jobs on load, numbered.

Total dev: 1.5d

Ballpark: 3.0d


Route Building via PTV

To include route building via PTV, C-ePOD requires an import and export process.

Note Note:

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

  • 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 Note: PTV Support have inferred there is a simpler method for route building but have not provided details.


PTV Route Optimiser will be set up as follows:

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


Orders are created in C-ePOD with the containers and the Package Code (DU).

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

A new screen will control calling PTV Route Optimiser if configured.

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 screen will offer options to plan the date or to upload a previous plan from PTV.

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.

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

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.


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 offer to upload the routes created. At this point the user can use PTV Route Optimiser directly to make any manual changes.


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


The development required is as follows:

  • New XF Config settings
  • New Route Building screen
  • Export Process
  • Import Process
  • Container Entry/Edit pop-up - lookup on DU Codes


SCR SCR-354306-8: Route Building via PTV

Total dev: 11.0d

Ballpark: 21.5d


Route Optimisation via PTV

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.

Note Note: All of the same scope and assumptions are in place as per Route Building via PTV Route Optimiser.


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.

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.

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.

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

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 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 for this requires much of the same work as the PTV Route Builder. The work required is:

  • 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


SCR SCR-354306-9A: Route Optimisation by PTV

Total dev: 8.75d

Ballpark: 17.75d


If developed together with PTV Route Building, the full development required is as follows:

  • Add buttons to Load and Job Assignment screens
  • New XF Config settings
  • 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 SCR-354306-9B: Route Building and Optimisation by PTV

Total dev: 13.75d

Ballpark: 26.75d


Route Optimisation via HERE maps

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

Integrating this into C-ePOD would be a similar process to integrating PTV above, but this is a simpler interface.

Scope:

  • GPS co-ordinates (Lat-Longs) are required for every point (job address or customer).
  • A Nokia account of sufficient authority to use the waypoint sequence webservice.
  • Note Note: This process has not been prototyped.
  • 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.


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.
  • Up to 2 Collection/Delivery Windows against the Job Address or Customer, whichever is applicable.

Note Note: See additional changes below regarding Collection/Delivery Windows.

The file will be sent to the web service.

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 SCR-354306-10: Route Optimisation by HERE

Total dev: 4.25d

Ballpark: 8.25d


Route Optimisation via Google Maps

Warning Warning: It has been determined that the Google Maps API does not provide a service to do this.

SCR SCR-354306-11: Route Optimisation by Google Maps


Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screens

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.

As this is now likely to become more used, we need to drag in features relating to additional filtering options based on geographical region.

Basic solution:

This solution adds the Postal Area and District to the screens that need it, allowing for selection, filtering and sorting as required.

  • New fields on EPOD_JOB/EPOD_CUSTOMER
  • Not required on EPOD_JOB_ADDRESS if we have it on job.
  • Automatically set the Postal Area and District from the postcode when saving Job Address or Customer.
  • 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.


SCR SCR-354306-12A: Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen

Total dev: 2.75d

Ballpark: 5.75d


Fully featured solution:

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:

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


SCR SCR-354306-12B: 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


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.

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

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 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 SCR-354306-13A: 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 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 SCR-354306-13B: 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 Note: Accident Reports have been prototyped in the device code and can be reactivated.

Note 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 SCR-354306-14A: 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 SCR-354306-14B: Accient Reports and Alerting

Total dev: 6.75d

Ballpark: 13.25d


Note Note: If combined with the above Vehicle Checks changes, the resulting cost will be cheaper:

SCR SCR-354306-14: Combined Vehicle Checks and Accident Reports

Total dev: 7.25d

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


C-ePOD will allow entry of windows against:

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


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 required development is as follows:

  • A new tab for the Customer maintenance screen, for Windows.
  • 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 SCR-354306-15: Entering Collection/Delivery Windows

Total dev: 2.0d

Ballpark: 4.0d


Appendix A: Table of SCRs and Ballpark Estimates

Appendix A1: All Changes

SCR#SystemAreaDescriptionEstimate (Days)Notes
1 EPOD Load Building Improved Load Assignment in EPOD  0.00   
2 EPOD Mobile Printing Label Printing - Common:Core + Common:Product  22.00  2
2A EPOD Mobile Printing Label Printing - Common:Core + Additional  14.00  3
2C EPOD Mobile Printing Label Printing - Add Brother Printers  0.00   
2D EPOD Mobile Printing Label Printing - GFG/CFC Label Formats  2.50   
3 EPOD Reports POC based on Gift Aid entries in T&Cs  7.75   
4A EPOD Collection Unplanned Ad Hoc Collection from any location (v2 Lite)  8.50   
4B EPOD Collection Unplanned Ad Hoc Collection from any location (v2)  12.00  4
5 EPOD Load Building Screen to create loads per vehicle per day, with loading and unloading jobs created automatically  6.25   
6 EPOD Interface Interface to UK Changes (supporting existing TMS Trip/Order format)  0.00   
7 EPOD Load Building Show Load map for all jobs on load, numbered.  3.00   
8 EPOD Load Building Route Building via PTV  21.50   
9A EPOD Optimisation Route Optimisation by PTV  17.75   
9B EPOD Load Building Route Building and Optimisation by PTV  26.75  5
10 EPOD Optimisation Route Optimisation by HERE  8.25   
11 EPOD Optimisation Route Optimisation by Google Maps  0.00  9
12A EPOD Load Building Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen  5.50   
12B EPOD Load Building Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen and automatically assigning region to the job.  11.25  6
13A EPOD Job Creation Preadvise Multiple Containers manually  2.25   
13B EPOD Job Creation Preadvise DU count only  5.50   
14 EPOD Vehicle Checks Combined Vehicle Checks and Accident Reports  13.75  7
14A EPOD Vehicle Checks Vehicle Checks Alerting  4.25   
14B EPOD Vehicle Checks Accident Reports and Alerting  13.25   
15 EPOD Job Creation Entering Collection/Delivery Windows  4.00  8


Notes:

  1. 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.
  2. If this change is completed as a product change, use this cost, plus the costs of 2C and 2D.
  3. If this change is completed as a bespoke change, use this cost, plus the costs of 2C and 2D.
  4. The cost for this change includes C-TMS costs into the estimate above.
  5. This changes combines 8 and 9A.
  6. This change is a replacement for 12A, and far more functional.
  7. This change combines 14A and B.
  8. This change is an optional change for PTV Route Building or Route Optimisation changes (8, 9A and B).
  9. This change cannot be achieved as the API does not support this.

Appendix A2: Minimum Changes

It is expected that the following are the minimum changes required to implement v2 Lite with the functionality as requested:


SCR#SystemAreaDescriptionEstimate (Days)Notes
1 EPOD Load Building Improved Load Assignment in EPOD  0.00   
2 EPOD Mobile Printing Label Printing - Common:Core + Common:Product  22.00   
2D EPOD Mobile Printing Label Printing - GFG/CFC Label Formats  2.50   
3 EPOD Reports POC based on Gift Aid entries in T&Cs  7.75   
4A EPOD Collection Unplanned Ad Hoc Collection from any location (v2 Lite)  8.50   


Notes:

  • If automatic route optimisation is required, consider adding HERE maps optimisation.
  • If automatic route building is required, consider adding PTV Route Optimiser here.


Appendix A3: Recommended Changes

The following changes would provide the greatest degree of functionality to the product.


SCR#SystemAreaDescriptionEstimate (Days)Notes
1 EPOD Load Building Improved Load Assignment in EPOD  0.00   
2 EPOD Mobile Printing Label Printing - Common:Core + Common:Product  22.00   
2D EPOD Mobile Printing Label Printing - GFG/CFC Label Formats  2.50   
3 EPOD Reports POC based on Gift Aid entries in T&Cs  7.75   
4B EPOD Collection Unplanned Ad Hoc Collection from any location (v2)  12.00   
5 EPOD Load Building Screen to create loads per vehicle per day, with loading and unloading jobs created automatically  6.25   
7 EPOD Load Building Show Load map for all jobs on load, numbered.  3.00   
9B EPOD Load Building Route Building and Optimisation by PTV  26.75   
12B EPOD Load Building Add Planning Region/Postal Area/Postal District to the EPOD Job/Load Building screen and automatically assigning region to the job.  11.25   
13A EPOD Job Creation Preadvise Multiple Containers manually  2.25   
13B EPOD Job Creation Preadvise DU count only  5.50   
14 EPOD Vehicle Checks Combined Vehicle Checks and Accident Reports  13.75   
15 EPOD Job Creation Entering Collection/Delivery Windows  4.00   



Appendix B: Document References

B.1 References

Ref NoDocument Title & IDVersionDate
1FS 340547 PROD-75 Admin Job Assignment Improvements0.224/01/2017


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		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=REQ_354306_CFC_v2_Requirements&oldid=6628’