REQ 313776 Brett Martin ePOD Requirements

From Calidus HUB





Aptean Logo.png







Brett Martin

ePOD Requirements

CALIDUS ePOD

12th December 2013 - 0.2
Reference: REQ 313776











































Introduction

This document is the ePOD Requirements document.

Objective

The primary purpose of this document is to document the requirements gathered from Brett Martin during the sales process, and to present an overview of the process that will be followed in and the work required to the CALIDUS ePOD system.

This document has been written in a manner such that it can be approved by non-technical representatives of Brett Martin whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

Scope and Limitations

This document is based on the documentation provided by the OBS Logistics Sales team, as well as information gathered at further meetings, specifically at the Brett Martin site on 22/11/2013.

  • The changes will be made in the latest version of the CALIDUS ePOD system.
  • The changes have been specified with the Android PDA client in mind.

Client Requirements

Overview

Brett Martin:

  • Michelle Carter - Supervisor
  • James Pashley - Planning
  • Tim Blackwell - Transport
  • Jack Bradin - Microsoft AX Technical

There are two sides to the business:

  • Ariel - Sheets/Fixings
  • Martin - Pack/Pallet/Bundle/Misc

Overview of the current process:

  • Each of depots plan the orders for completion:
    • Stavely/Luton - automated planning.
    • Cumbernauld - manual planning.
  • The start of the Picking process produces the despatch/delivery notes.
  • Pickers pick the stock and mark the DU's (Distribution Units, for example Pallet, Sheet, etc) on the delivery note with quantities. These are not currently held within Microsoft AX.
  • The paper delivery notes are allocated to the drivers.
  • The drivers deliver by the number of DU's - the product is not counted.
  • Driver and Customer both sign the documentation.
  • Discrepancies are handled after driver return by checking the quantities and amending orders where required. This sometimes leads to re-invoicing.


Although the operation has a goal of delivery by Product and Quantity, to improve accuracy, at this time, the operation does not support achieving this, the limiting factor being the quality of information gathered by the pickers, or entered by the users. Currently, physical DU's (i.e. pallets, bags) are not unique and are not systemically tagged with the products they contain, so there's no way of knowing which items have been delivered if there are shortages.

The decision is that, until the picking or system processes can be improved to identify the unique products picked, or the products within the unique DU, the system can only be set up to record the DU quantities. Therefore the delivery jobs will be sent to CALIDUS ePOD with DU and quantity information only, specified in place of Product and Quantity information.

Note Note: Although the collections process has not been specifically discussed, it is believed that the process follows a Product and quantity collection, rather than DU, so Collection jobs will have this information detailed instead.

It is possible that all jobs initially sent across have a 0 quantity (if the job is completely unplanned). Information should be confirmed overnight and entered in the morning or entered by the pickers, but this may be after the driver has left. Therefore the device will be updated in the field with any updated values entered in Microsoft AX.

Note Note: At this time, it is expected that this initial entry of 'Expected DU Quantities' will be completed through a new screen in Microsoft AX, developed for this purpose. It is expected that the pickers will be required to enter this information.


Devices

Training is scheduled to show Brett Martin resources the method for configuration of the devices. This will take place in OBS Logistics Liverpool offices. All subsequent device configurations will be the responsibility of Brett Martin

The devices will be configured for the requirements of the operation. This will include:

  • Setting up a Google account, common to all devices. This is likely to be [email protected], but will be confirmed at implementation. This can be used for Google Drive, GMail and Play store purposes.
  • All required applications installed from the Google Play market, including the CALIDUS ePOD app and SureLock lock-down applications.
  • SureLock will be configured to allow access only to the desired functionality, which typically includes:
    • CALIDUS ePOD, including all Android system functionality required (e.g. Ring-tone Picker)
    • Telephony, including common contacts (restricted black/white-list)
    • SMS (restricted black/white-list)
    • Email/Gmail - as required
    • Play updates, but not the application itself, to prevent unwanted app installation.
    • Camera
    • CoPilot Navigation Software
    • Google Drive or DropBox (TBC)
    • Customised background wallpaper

Standard documentation required by the drivers can be made accessible through a document sharing application, for example DropBox or Google Drive. Either application (or other) could be used, linked to the existing configured Google email address common across all devices. To be confirmed.


Data Import

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

  • Driver Signature.
  • POC/POD document format.
  • POC/POD business address and logo.
  • Terms and Conditions displayed.

The Job Groups will be defined and agreed in advance between the back-end software providers and OBS Logistics. There will need to be at least two Job Group configurations:

  • Ariel
  • Martin

If Job Groups are sent to CALIDUS ePOD that have not been created in advance, the interface will create them as a skeleton record, defaulting the configuration.

The Jobs and Loads themselves will be interfaced with the data required to complete the jobs. This will be mapped outside of this document, but is expected to include:

  • Delivery Note - Job Code
  • Delivery Address - Customer or Job Address.
  • Customer Acc - Customer Code
  • Cust Order - Cust Ref
  • Customer Tele - Telephone #
  • Ship Date - Load Start Planned Date
  • Sales Order - SO Number
  • Requisition - External Ref.
  • Drop Number - Sequence.
  • Confirmed Ship Dt - Load Start Actual Date
  • Driver ID - User ID
  • Schedule ID - Load ID
  • Job Type - (C)ollection or (D)elivery

Details of jobs will differ based on Job Type.

  • Delivery
    • Description - DU
    • Unit - Blank
    • Delivered - Actual DU Qty, as confirmed by the driver when delivering.

For Delivery jobs, there are several scenarios:

  • Full DU and Quantity information is present initially.
  • No DU and Quantity information is present initially, updated before arriving at destination.
  • No DU and Quantity information is present initially, not updated before arriving at destination.

Lines that are not required need not be sent through on the interface. So, if some of the DU's are only required for one side of the business (for example, SHEETS are only required for Martin but not Ariel), then this DU need not be sent. If this is the case, these will not be displayed on the device for entry.

Initially, if the quantity is known, only the quantity against the lines required need be sent through. If the information is not known, all DU's should be sent through with a quantity of 0. When the quantities are known and entered in AX, they can then be sent through. Again, not all DU's need to be sent through if the quantities do not need to be entered.

In all cases, CALIDUS ePOD will ensure that the DU's that have been sent through are prompted for.

Note Note: This is data-driven from Microsoft AX - whatever DU lines have been passed will be forced to be entered, ensuring that the process can be directed to some extent from the Microsoft AX, rather than requiring extensive modification to CALIDUS ePOD for future changes.

  • Collection
  • For Collections:
    • Description - Product Code and Product Description
    • Unit - UOM passed in. Will be "Ea"
    • Delivered - Product Actual Qty, as confirmed by the driver when collecting.

Collections are an altogether simpler process. If a product requires collection, it will be added to the Job as a Loose Product with a quantity to be collected.

When a job is updated in Microsoft AX and sent to CALIDUS ePOD again, the device will ensure that the user knows that changes have been made. DU's not present on the update of the job will be removed. Therefore, if a job is sent with all 6 DUs at 0 quantity, but is then updated with only 2 with a quantity, the 4 not sent would be removed. This ensures that the driver is not prompted for entry of items if not required. However, if it is necessary that the system prompts for all DU's at all times, it must be ensured that Microsoft AX passes through all of the products each time, even if that quantity is 0.


There are additional interfaces to CALIDUS ePOD in order to keep standing data in line within the system, for example:

  • Drivers - used to allocate loads to drivers
  • Vehicles - used to allocate loads to tractors/trailers/vehicles
  • Reason Codes - used when exceptions are encountered (cancelling jobs, containers, products, changing quantity)

Each of these items can be agreed in advanced or administered within CALIDUS ePOD, negating the need for a developed interface. Furthermore, if drivers are assigned to a Load on a message and are not in CALIDUS ePOD, the interface will create them as a skeleton record, with the User ID as the Driver ID sent in, and the Name and Password defaulted, with default access created.


The exact timing of when messages will be sent to CALIDUS ePOD is not covered here - this must be decided by the back-end system developer. The full list of expected changes to this system (Microsoft AX) is as follows:

  • New DU and Quantity Entry screen - for Pickers to enter the amount of each DU picked for the order.
  • Interface of Jobs to CALIDUS ePOD, identifying the
  • Interface of Standing Data to CALIDUS ePOD - OPTIONAL
  • Interface of Completed Jobs from CALIDUS ePOD
  • Production of POD/POC reports


PDA Login

The application will haver a customised style created for Brett Martin, which will include:

  • An appropriate colour scheme (green/white)
  • The logo on the login page.

The drivers will be provided a user-name and password, and the loads will be allocated to specific drivers, ensuring that they can complete only the loads required. The users and their passwords must be configured within CALIDUS ePOD

A driver logs on to a device using their provided user name, password and vehicle. The device will remember the last used User name and Vehicle, but will always require that the password is entered.


Vehicle Checks

When log-in is complete, the device will prompt the driver for the vehicle checks required. The content and frequency of these checks is user-configurable, from the CALIDUS ePOD Admin system.

  • Vehicle Checks Sample

    Vehicle Checks Sample


Vehicle checks will be configured to be run daily, and will prompt for:

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

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

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

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

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


Obtain Workload/Job List

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

  • Job List

    Job List


The screen will display the status of the jobs on the load through a coloured outline, as follows:

  • Red - Cancelled
  • Green - Completed
  • Blue - Completed (with amendments)
  • Yellow - In Progress
  • None - Pending/Incomplete

Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job you want to complete - the device will display the Job Details page.

The Menu button can be used here to allow the following options:

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

The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:

  • No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed.
  • Confirm re-sequencing allowed - this requests the user to confirm first.
  • Always allowed - no confirmation.

This configuration will be decided at the point of implementation, but is expected that re-sequencing is allowed.


If any jobs have been added to a Load while the load is in progress, the Refresh option (which also is timed to happen on a regular 5 minute interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs, for example, if DU quantities have been entered or amended.


Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing Cancel from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.


Job Details

Selecting a job from the Job List will show the user the job report and customer contact details (on a Job Details screen). The user can back out of the selected Job and view any Job on the list.

  • Job Details

    Job Details


The screen has several Tabs, showing:

  • The Job Type (Collection, Delivery, Service)
  • The customer details (Customer Code, Name, Address and Postcode)
  • The contact information (Contact name and number)
  • The Instructions for the job

Clicking on the tabs will display the information.

The screen allows the user to contact the customer (through text or phone). Text and Phone connectivity may be limited by a telephony black- or white-list provided by the customer, so the device may not be allowed to contact this customer. If this is the case, the device will prevent contact and return to the CALIDUS ePOD application.


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

If there have been instructions provided on the Job, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

Note Note: It is expected that re-sequencing of jobs is allowed by the driver. If is is not allowed, or the allowed only by confirmation, the user will be told this at this point.


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


Jobs can be cancelled by the driver at this time by clicking the Cancel Job button. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.


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

The device will use any navigation application installed on the device for this navigation. It is expected that this will be through the Co-Pilot Truck navigation application.


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


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


Delivery Process

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

  • Job Details Tab

    Job Details Tab

  • Products Tab

    Products Tab


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

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

  • The Product Code (set to the DU)
  • The Sequence
  • The Description
  • Any Customer Reference associated to this product
  • The Planned Quantity
  • The Item Type
  • The Unit Type

For Delivery jobs, there are several scenarios:

  • Full DU and Quantity information is present initially.
  • No DU and Quantity information is present initially, updated before arriving at destination.
  • No DU and Quantity information is present initially, not updated before arriving at destination.

The user will be shown a list of all the possible DUs, displaying the quantity of each required. In all cases, CALIDUS ePOD will ensure that the DU's that have been sent through are prompted for.

Note Note: This is data-driven from Microsoft AX - whatever DU lines have been passed will be forced to be entered, ensuring that the process can be directed to some extent from the Microsoft AX, rather than requiring extensive modification to CALIDUS ePOD for future changes.

When processing on the device:

  • A list of the DU's requiring entry will be displayed, regardless of whether they have a quantity. The line will display the information required clearly, for example, the DU name (e.g. PALLETS, BAGS) will be displayed, and the quantity required.
  • The user will confirm the delivery or collection of the items by clicking on the line that they wish to confirm.
  • If the line has no quantity, the user will be required to enter a quantity against it. The user can enter 0.
  • If the line has a quantity, the user will be offered a choice of actions:
    • Deliver - deliver the quantity required.
    • Change Quantity
    • Cancel


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

  • long-clicking on the item in the list and choosing Deliver from the pop-up menu
  • entering the product code manually and clicking Deliver
  • scanning the product code

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

The driver can change the quantity by choosing Change Quantity from the pop-up menu - the device will direct them to an exception screen where the quantity can be changed, and a reason code entered as to why the quantity is changed. This will allow decimal entry of quantity, and will display the unit type, for clarification.


SCR SCR-313776-1: Force Quantity Entry - allow 0 quantity


If a product can't be found on the vehicle, it can be removed from the list with the pop-up option Cancel. Again, the exception screen will be shown where the driver can enter the reason why.

Note Note: During this exception process (either quantity change or product cancellation), the user can take an image with a description, if desired.

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


Collection Process

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

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

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

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


Job Completion

Note Note: At this time, the assumption is that the configuration will require the Driver and Customer to sign for collection and delivery of goods. It is an optional configuration for CALIDUS ePOD, where driver signatures can be enabled or disabled for collections or deliveries. Note that by default, the the driver is considered to have 'signed for' items by use of the unique user-name and password used at log-on, so this may be omitted if desired.


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.

If required, the device will first prompt for Customer Signature.

  • Customer Signature form

    Customer Signature form


The signatory will default to the customer contact sent through on the job, but this can be changed. If one is not sent through, the driver will be forced to enter one.

The screen displays several tabs, allowing the user to see:

  • Terms and Conditions, plus any check boxes the user is required to confirm. These are configurable.
  • The products and quantities collected/delivered.


The Terms and Conditions may differ for each customer, but will appear in the same place on the screen (under the signature). Unlimited T&Cs text can be configured, along with 3 potential check-boxes. It is expected that these will be set to simply "Received in Good Order".


When the signature is entered and confirmed (or if one is not required), the process will check whether Driver Signature is required. The signature screen is extremely similar to the Customer Signature, but the Driver name is fixed, and the tabbed area is left blank.


Once the Job Completion process has finished, the job will then be sent back to the CALIDUS ePOD server for completion, where all entered data, signatures and images will be stored and the job marked as complete. The user will be returned to the Job List screen and the Job will be removed from the list.


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

Note Note: The Collection process has not been discussed in detail. Documentation of this process must be provided to OBS Logistics. At this time, it is assumed that the collection process will be identifying products and quantities rather than DUs. However, it should be noted that the CALIDUS ePOD collection process is configured primarily based on the data received, so if the process requires collection of DUs, as long as the collection job received details the DUs and quantities to collect, the device process will work.


There are currently two POC and POD formats, one for Ariel, one for Martin. It has been agreed that the formats can be identical, with the exception of the Logo. This will be set against the produced POC/POD from the logo of the Job Group passed against the Job.

The mapped values will be: Page Header:

  • Ariel Plastics address and Logo - Will be set from the Job Group passed in.

Header:

  • Delivery Note - Job Code
  • Delivery Address - Customer or Job Address.
  • Customer Acc - Customer Code
  • Cust Order - Cust Ref
  • Customer Tele - Telephone #
  • Ship Date - Load Start Planned Date
  • Sales Order - SO Number
  • Requisition - External Ref.
  • Drop Number - Sequence.
  • Confirmed Ship Dt - Load Start Actual Date
  • Driver ID - User ID
  • Schedule ID - Load ID

Details - This information will come from the Products sent to CALIDUS ePOD.

  • For Deliveries:
    • Description - DU
    • Unit - Blank
    • Delivered - Actual DU Qty, as confirmed by the driver when delivering.

Footer:

  • Delivery Contact - Customer Contact
  • Delivery Contact Phone - This would be the same as Customer Telephone above.
  • "Received in Good order" - T&Cs or Fixed text.
  • Sign - Customer Signature
  • Print - Cust Signatory
  • Date - Actual End Date
  • Driver - Driver Name or Driver Signatory. Warning Warning: TBC
  • "All Shortages..." - T&Cs or fixed text.


The format will be changed slightly if the job is a collection:

  • The text 'Delivery' will be changed to 'Collection'.
  • The text 'Delivered' will be changed to 'Collected'.
  • For Collections:
    • Description - Product Code and Product Description
    • Unit - UOM passed in. Will be "Ea"
    • Delivered - Product Actual Qty, as confirmed by the driver when collecting.
SCR SCR-313776-2: POD/POC Report Formats

It should be noted that the collection and delivery notes are largely to be produced through Microsoft AX based on the completion data passed back to there from CALIDUS ePOD, as the information received by the device is not sufficient at this time to produce an accurate note.


Data Export

When jobs have been completed all the job is updated in the CALIDUS ePOD server, these jobs are then available for exporting to external systems. This is also true of cancelled jobs. All completed and cancelled Jobs will be transferred to Microsoft AX through the standard interface.


For jobs that have been completed, POD documents may need to be sent to the customer. It is expected that this will be controlled through Microsoft AX, until such time as the data set to CALIDUS ePOD is detailed enough.


Appendix A: Table of SCRs

SCR#SystemAreaDescriptionEstimate (Days)Notes
1 ePOD PDA Force Quantity Entry - allow 0 quantity  4.00 
2 ePOD Admin POD/POC Report Formats  6.00 


Notes:

  1. All ballpark costs in this document are provided as-is, are legally non-binding and subject to raising a formal change request with OBS Logistics.


Appendix B: Document References

B.1 References

Ref NoDocument Title & IDVersionDate
1UG 291094 EPOD Admin User Guide2.04/4/2012
2UG 291097 EPOD Client User Guide3.023/4/2013


B.2 Glossary

Term Definition
EPOD Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD.
CALIDUS eSERV The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system.
PDA The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android.
DAL Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it.
GPS Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device.
GPRS, 3G, HSDPA, Data Service All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet.


B.3 Authorised By


Julie Scott
OBS Project Manager		_____________________________

____________________(PRINT)
Brett Martin Representative		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=REQ_313776_Brett_Martin_ePOD_Requirements&oldid=1342’