FS 313749 AUNZ-031 LFS Secondary Non-conformance

From Calidus HUB
Revision as of 11:53, 14 February 2014 by Anw (talk | contribs) (Slight format changes)





Aptean Logo.png







LFS

LFS Secondary Non-conformance


CALIDUS ePOD

3rd February 2014 - 0.1
Reference: FS 313749/AUNZ-031












































Functional Overview

Client Requirement

The included functionality to be specified is shown below:

LFS drivers scan the goods in the van before taking them to the customer. The driver then just hands the device to the customer to sign. If the driver arrives and they reject a package there is currently no way of cancelling a container on the order. We need to be able to cancel containers from the signature screen


Solution Overview

The driver scans the packages as they are moved off the vehicle and, when complete, will then move to the destination to deliver the packages.

The device will not move on the to Signature screen, but will instead stay on the Delivery processing screen. The screen will refresh to display all the packages on the job, indicating the status (Cancelled, Delivered, Claused), as well as a coloured border to help identify this:

  • Cancelled - Red
  • Delivered or Claused - Green

The customer may want to reflect that some packages are not to be delivered. The driver can reflect this by choosing to change any package, in one of several ways:

  • select an package from the list
  • Scan the item with the camera
  • Scan or Enter the package ID in the provided text box

When a package is selected in this way, the device will display a pop-up option, allowing the driver to select what they can do, as follows:

  • Deliver - If the package is marked as Cancelled, they can choose to Deliver that package instead. In that case, the driver will be asked to confirm this, at which point the package will be marked as Delivered instead.
  • Cancel - If the package is marked as Delivered or Claused, they can choose to Cancel that package (i.e. not delivered). In that case, the normal Cancellation exception screen will be displayed allowing the user to identify a reason for the non-delivery. The user can back out f this screen without cancelling the delivery of the package.
  • Info - See some additional information about that package.
  • Close - No Action


Once the driver has cancelled all packages that the signatory does not wish to sign for, the driver can press the Complete button to go to the Signature screen, which shows the following:

  • Terms and Conditions of the delivery or deliveries.
  • The details of all the packages being delivered, and those that could not be found. This will reflect all the changes made by the driver when taking them off the vehicle, and any changes by the customer.
  • Contact/Signatory information.

The driver will capture the actual signatory's name here and request signature. The signatory has several options:

  • To place a comment against the package, but still receive them (by clicking on a pallet and entering Clause information.
  • To sign for all delivered packages in the list, regardless of whether they have made comment.
  • To refuse delivery of some or all of the packages again.

In order to refuse delivery of some or all of the items, the driver can then press the Back button on the device to return to the Delivery process screen, where the delivered packages can again be modified as per the customer's request.

Only when the customer is satisfied will they be required to enter their signature.

To cancel to entire delivery, the user can move back to the Job Details screen (using the Back button from the Delivery screen) and click the Cancel Job button.


Scope

Note Note: This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.
Note Note: CALIDUS TMS functionality is mentioned only by reference in this solution - see elsewhere for specification of the changes to that system.


Set-up

Pre-requisites

  • A working CALIDUS ePOD system.
  • A working CALIDUS TMS system, accessible to the CALIDUS ePOD system.


Menu Structure

None

Data

All Job Groups on EPL_JOB_GROUP that require this functionality enabled must have the new flag set to "Enabled"


Functional Description

Database/DAL

Table EPOD_SITE requires the following modification:

  • EPL_SCAN_AT_VEHICLE - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.

Existing packages will be modified to allow the creating, editing and selecting of the new flag, including but not limited to:

  • EPOD_SITE_INSERT
  • EPOD_SITE_SELECT
  • EPOD_SITE_SELECT_UPDATED_DATA
  • EPOD_SITE_UPDATE

The existing EPOD_SITE DAL object will be changed to:

  • Export the new flag in XML requests
  • Read the new flag

Note Note: It is not necessary to add this flag as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.

Example: The XML Export of EPOD_SITE records will now look as follows:

 <EPOD_SITE>
   <EPL_SITE_ID></EPL_SITE_ID>
   <EPL_DESCRIPTION></EPL_DESCRIPTION>
   <EPL_SERVICE_POD_FORMAT></EPL_SERVICE_POD_FORMAT>
   <EPL_DELIVERY_POD_FORMAT></EPL_DELIVERY_POD_FORMAT>
   <EPL_COLLECTION_POD_FORMAT></EPL_COLLECTION_POD_FORMAT>
   <EPL_SERVICE_ACTIVITIES></EPL_SERVICE_ACTIVITIES>
   <EPL_SERVICE_PREWORK></EPL_SERVICE_PREWORK>
   <EPL_SERVICE_INFO></EPL_SERVICE_INFO>
   <EPL_SERVICE_PRODUCTS></EPL_SERVICE_PRODUCTS>
   <EPL_SERVICE_MC_REF></EPL_SERVICE_MC_REF>
   <EPL_SERVICE_DIAGNOSIS></EPL_SERVICE_DIAGNOSIS>
   <EPL_SERVICE_POSTWORK></EPL_SERVICE_POSTWORK>
   <EPL_AUTO_COMPLETE_EMAIL></EPL_AUTO_COMPLETE_EMAIL>
   <EPL_AD_HOC_COLLECTION></EPL_AD_HOC_COLLECTION>
   <EPL_DEL_DRIVER_SIGN></EPL_DEL_DRIVER_SIGN>
   <EPL_COL_DRIVER_SIGN></EPL_COL_DRIVER_SIGN>
   <EPL_DELIVERY_PAYMENT></EPL_DELIVERY_PAYMENT>
   <EPL_DOCUMENT_PHOTO></EPL_DOCUMENT_PHOTO>
   <EPL_CONTAINER_ONLY></EPL_CONTAINER_ONLY>
   <EPL_PDA_DIS_JOB_CODE></EPL_PDA_DIS_JOB_CODE>
   <EPL_LINKED_C_D></EPL_LINKED_C_D>
   <EPL_METRICS_ENTRY></EPL_METRICS_ENTRY>
   <EPL_NOTES></EPL_NOTES>
   <EPL_FORCED_ENTRY></EPL_FORCED_ENTRY>
   <EPL_SYSTEM_TYPE></EPL_SYSTEM_TYPE>
   <EPL_UPDATE_FUNCTIONS></EPL_UPDATE_FUNCTIONS>
   <EPL_VEHICLE_CHECK_CONFIG></EPL_VEHICLE_CHECK_CONFIG>
   <EPL_JOB_LIST_CFG></EPL_JOB_LIST_CFG>
   <EPL_ARRIVAL_FLAG></EPL_ARRIVAL_FLAG>
   <EPL_SCAN_ERROR_FLAG></EPL_SCAN_ERROR_FLAG>
   <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
   <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
   <EPL_RESEQUENCE></EPL_RESEQUENCE>
   <EPL_CLAUSE_DELIVERY></EPL_CLAUSE_DELIVERY>
   <EPL_JOB_STATUS></EPL_JOB_STATUS>
   <EPL_CONSOLIDATION></EPL_CONSOLIDATION>
   <EPL_VEHICLE_STOCK_FLAG></EPL_VEHICLE_STOCK_FLAG>
   <EPL_SCAN_AT_VEHICLE></EPL_SCAN_AT_VEHICLE>
 </EPOD_SITE>


Table EPOD_JOB_GROUP requires the following modification:

  • EPL_SCAN_AT_VEHICLE - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.

Existing packages will be modified to allow the creating, editing and selecting of the new flag, including but not limited to:

  • EPOD_JOB_GROUP_INSERT
  • EPOD_JOB_GROUP_SEARCH
  • EPOD_JOB_GROUP_SELECT
  • EPOD_JOB_GROUP_SELECT_UPDATED_DATA
  • EPOD_JOB_GROUP_UPDATE

The existing EPOD_JOB_GROUP DAL object will be changed to:

  • Export the new flag in XML requests
  • Read the new flag

Note Note: It is not necessary to add this flag as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.

Example: The XML Export of EPOD_JOB_GROUP records will now look as follows:

 <EPOD_JOB_GROUP>
   <EPL_SITE_ID></EPL_SITE_ID>
   <EPL_JOB_GROUP></EPL_JOB_GROUP>
   <EPL_DESCRIPTION></EPL_DESCRIPTION>
   <EPL_SERVICE_POD_FORMAT></EPL_SERVICE_POD_FORMAT>
   <EPL_DELIVERY_POD_FORMAT></EPL_DELIVERY_POD_FORMAT>
   <EPL_COLLECTION_POD_FORMAT></EPL_COLLECTION_POD_FORMAT>
   <EPL_SERVICE_ACTIVITIES></EPL_SERVICE_ACTIVITIES>
   <EPL_SERVICE_PREWORK></EPL_SERVICE_PREWORK>
   <EPL_SERVICE_INFO></EPL_SERVICE_INFO>
   <EPL_SERVICE_PRODUCTS></EPL_SERVICE_PRODUCTS>
   <EPL_SERVICE_MC_REF></EPL_SERVICE_MC_REF>
   <EPL_SERVICE_DIAGNOSIS></EPL_SERVICE_DIAGNOSIS>
   <EPL_SERVICE_POSTWORK></EPL_SERVICE_POSTWORK>
   <EPL_AUTO_COMPLETE_EMAIL></EPL_AUTO_COMPLETE_EMAIL>
   <EPL_AD_HOC_COLLECTION></EPL_AD_HOC_COLLECTION>
   <EPL_DEL_DRIVER_SIGN></EPL_DEL_DRIVER_SIGN>
   <EPL_COL_DRIVER_SIGN></EPL_COL_DRIVER_SIGN>
   <EPL_DEL_CUST_SIGN></EPL_DEL_CUST_SIGN>
   <EPL_COL_CUST_SIGN></EPL_COL_CUST_SIGN>
   <EPL_SIGN_CHECK_LBL></EPL_SIGN_CHECK_LBL>
   <EPL_DELIVERY_PAYMENT></EPL_DELIVERY_PAYMENT>
   <EPL_DOCUMENT_PHOTO></EPL_DOCUMENT_PHOTO>
   <EPL_CONTAINER_ONLY></EPL_CONTAINER_ONLY>
   <EPL_METRICS_ENTRY></EPL_METRICS_ENTRY>
   <EPL_NOTES></EPL_NOTES>
   <EPL_TNCS></EPL_TNCS>
   <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
   <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
   <EPL_JOB_STATUS></EPL_JOB_STATUS>
   <EPL_CONSOLIDATION></EPL_CONSOLIDATION>
   <EPL_SCAN_AT_VEHICLE></EPL_SCAN_AT_VEHICLE>
 </EPOD_JOB_GROUP>


The existing database package EPOD_SETUP will be modified to ensure that the new flags are defaulted appropriately.


Import/Export Message

The PDA web request service (Calidus_ePOD.asmx) will export the new field EPL_SCAN_AT_VEHICLE on EPOD_SITE and EPOD_JOB_GROUP in the XML responses. This should be handled by the DAL changes above. The responses affected are:

  • Calidus_ePOD:
    • LOGIN_RESPONSE


Admin Changes

The Job Group and Site screens (job_group.aspx and site_header.aspx respectively) will be modified to allow the system to be configured for:

  • Scan at Vehicle - add field EPL_SCAN_AT_VEHICLE to the PDA tab as a check-box.

Note Note: Ensure as part of this change that the existing check-boxes line up.


PDA Changes

PDA DAL/Database Changes

A new column will be added to the EPOD_SITE table:

  • EPL_SCAN_AT_VEHICLE - This will be a one character field with of Values 'Y' and 'N'. The default value is 'N'.

This new field should be added to every procedure as part of the PDA_SITE DAL object.


A new column will be added to the EPOD_JOB_GROUPS table:

  • EPL_SCAN_AT_VEHICLE - This will be a one character field with of Values 'Y' and 'N'. The default value is 'N'.

This new field should be added to every procedure as part of the PDA_JOB_GROUP DAL object.


Collection / Delivery

Note Note: The processes for Collection and Delivery are identical within CALIDUS ePOD. This new functionality must affect Delivery-type jobs ONLY.


Note Note: For the purposes of deciding upon which settings are used to control how the consolidated jobs are processed, the Job Group of the first job will be used to obtain the values of flags.


For Collection-type jobs, or when the new EPOD_JOB_GROUP flag EPL_SCAN_AT_VEHICLE is disabled ('N'), this screen (created in ColDel.js) will act as it does now.

The existing function to display all the packages on the screen's Container table (BindContainerData) will be modified to:

  • First fetch the required display package data itself from SelectAllContainersForJob(true) i.e. retrieving only unconfirmed data.
  • If this returns no data, and this is a Delivery-type job, and the new EPOD_JOB_GROUP flag EPL_SCAN_AT_VEHICLE is enabled ('Y'), then call SelectAllContainersForJob(false) i.e. retrieving all data, including confirmed data.
  • Populate the table from the returned data.
  • Add status classes if the status of the container being added is unconfirmed (i.e. not 'P' or 'I').


All calls to BindContainerData will be modified to not require the passing of the data to be bound, as the function now does this itself.


Selecting containers from the list will be modified, if the status of the container is unconfirmed. In this case, all actions, regardless of how they occurred (long-press, press, scan, text entry) will result in displaying the Container Action dialogue (through function ContainerActionWithDialogue). The actions allowed against the container depend on the status:

  • Deliver - This action sets the status to Confirmed. If the status is already Cancelled ('X'), a confirmation dialogue should be displayed, asking "Changing from Cancelled to Delivered - Please confirm" with options "Yes" and "No". If the use chooses "No", no action will be taken. If the user chooses "Yes", the existing value of the reason code (EPL_REASON_CODE) will be blanked, and the status changed to Confirmed ('C'). If the Container was already at confirmed status, choosing this option will not do anything.
  • Cancel - This action sets the status to Cancelled. If the status of the container was Confirmed (Delivered), the normal Cancellation screen (CancelContainer) will be called. If the user backs out of this cancellation in the Cancellation screen, no action will be taken. If cancellation is confirmed, the container should be set to Cancelled status in the normal manner (with reason code), and the Container list refreshed. If the Container was already at Cancelled status, choosing this option will not do anything.
  • Info - Display some information about the package.
  • Close - Close the dialogue.

Note Note: These former two actions are slightly different to the current functionality where the containers have contained products, or this is the Loose Products container. In these cases, the screen would normally display the Products tab automatically, which in this instance will now be suppressed.


Currently, the screen automatically completes jobs (i.e. moves on to signature capture) that have no more pending containers to scan (and have passed validation). This is done in the ContainerAction... functions (by calling ValidateJob, then CompleteJob). If this is a Delivery-type job, and the new EPOD_JOB_GROUP flag EPL_SCAN_AT_VEHICLE is enabled ('Y'), this CompleteJob function will not be called here - it will only be called when clicking the Complete button.

Note Note: The same modification (regarding preventing automatic job completion) should be made to the ProductAction... functions.


Once the driver has cancelled all packages that the signatory does not wish to sign for, the driver can press the Complete button to go back to the Signature screen - any changes to delivered packages will be shown on the summary Containers (packages) tab as now.


All calls to the existing SignatureCapture function (from existing function nextJobEndTask) should now include a 'Back' callback function, which is executed by the Signature screen is the user chooses to back out. In this case, this function should be set to the existing BindContainerData function, to force a refresh of the Container list.


Job Completion

The existing Signature screen (created in Signature.js) requires modifications.


Note Note: For the purposes of deciding upon which settings are used to control how the consolidated jobs are processed, the Job Group of the first job will be used to obtain the values of flags.

Note Note: The general functionality of this screen when signing for a consolidated group of jobs is as follows:

  • One signature is required for all jobs
  • One set of T&Cs will be displayed (from the first job) and used against all jobs.
  • The Containers tab will show a consolidated view of all containers for all jobs.
  • The Products tab will show a consolidated view of all Products for all jobs.

The main function SignatureCapture will be modified to accept a backout callback function as a parameter.

For Collection-type jobs, or when the new EPOD_JOB_GROUP flag EPL_SCAN_AT_VEHICLE is disabled ('N'), this screen will act as it does now.

For Delivery-type jobs, when the new EPOD_JOB_GROUP flag EPL_SCAN_AT_VEHICLE is enabled ('Y') the screen will be modified to allow the driver to back out of the screen. If this happens, the screen must execute the callback function passed to it (to refresh the Delivery processing screen's list of packages). Note Note: As this function is used throughout the system in many different places, the screen must check whether this is passed parameter is null or undefined. If so, this should not be executed.


Appendix A: Quote & Document References

Cost Details
Activity Estimate
No. of Days
No. of Days Rate per Day (£) Cost (£ Exc. VAT)
Requirements 0.00 0.00 0 £0.00
Change Request Evaluation 0.00 0.00 0 £0.00
Functional Specification 0.00 0.75 0 £0.00
Technical Specification 0.00 0.00 0 £0.00
Development 0.00 3.50 0 £0.00
Testing and Release 0.00 0.50 0 £0.00
Implementation 0.00 0.25 0 £0.00
Project Management First argument to "number_format" must be a number. First argument to "number_format" must be a number. 0 £First argument to "number_format" must be a number.
 
TOTAL First argument to "number_format" must be a number. First argument to "number_format" must be a number.   £First argument to "number_format" must be a number.
Estimate excludes training, release to live and go live support.

A.1 References

Ref NoDocument Title & IDVersionDate
1


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


A.3 Authorised By


Matt Tipping

Project Manager
_____________________________

____________________(PRINT)

Client Representative
_____________________________