OBS Logistics Ltd

Marking Vehicle Checks as Defects

CALIDUS EPOD

14th December 2016 - 0.1
Reference: FS 340070 PROD-68

Functional Overview

Client Requirement

Vehicle Check results must identify when a check contains defects.

Solution Overview

The configuration of vehicle checks through UDF will allow the indication of whether a field/question is a defect check.

For DLL and multi-check fields, this will also allow the indication of which items in the field are considered defects.

This configuration will be sent to the device, which will check this when entering the checks. If a field is marked as a defect check, the value will be checked based on the type as follows:

Text and Numeric fields - if a value is entered, this is a defect.
Boolean - if the value is false, this is a defect.
Tri-state checks - if the value is "N", this is a defect.
Multi-checks - if the item indicated has a value of false, this item is a defect, as is the whole field.
Multi-tri-state checks - if the item indicated has a value of "N", this item is a defect, as is the whole field.
DDL - if the value selected is one of the values indicated as a defect, the whole field is a defect.

If any check on the vehicle check form is a defect, the whole check is marked as defect.

The field and values that are defects will be indicated in the data back to the server, as well as the whole check defect status. The process will store the status of the check:

If a defect is found, the status is "D" - Defect.
If a defect is not found, the status is "P" - Passed.

The Admin Vehicle Check Results screen will be modified to:

Filter by status.
Display the status on the table of results.
Display the status on the pop-up detail screen in the header.
Highlight the defect checks, with a red box around the defect checks.
Add a resolution section, if the status is Defect.

The user will be able to add resolution notes and clear the defect. In this case, the screen will save the status as "R" - Resolved. The date, time and user resolving the defect will be stored with the notes.

Scope

This specification does not cover additional phased functionality such as:

Alerts to the customer based on check status
Reports to the customer based on check status
Multiple resolution notes.
View Last Vehicle Checks of the device highlighting the defect fields.

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Add the following fields to EPOD_VEHICLE_CHECK:

EPL_STATUS = nvarchar(1)
EPL_RES_USER_ID - nvarchar(10)
EPL_RES_DATE - int
EPL_RES_TIME - int
EPL_RES_COMMENT - nvarchar(max)

These should be added to all database procedures. EPL_RES_COMMENT need not be added to the SELECT or SEARCH procedures.

An index IX_EPOD_VEHICLE_CHECK_STATUS should be added, as follows:

EPL_SITE_ID
EPL_STATUS
EPL_VEHICLE_CHECK_DATE
EPL_VEHICLE_CHECK_TIME
EPL_VEHICLE_ID

Admin

The UDF configuration screen (udf_config.aspx) should be modified to allow fields and items to be marked as potential defects, if the type of the checks is "Vehicle Checks" ("VEHICLECHECK").

When editing or creating a UDF Configuration of type "VEHICLECHECK", new functionality must be enabled:

Add new fields to the header:
- Frequency - a text box allowing numeric entry only. Default to 1. Hint help on mouse-over should be "Frequency of the Vehicle Checks in Days".
- Require at Load End - a check box, defaulting to unchecked. Hint help is "Require these vehicle checks at the end of a load as well as at the start".
- Signature - a check-box, defaulting to unchecked. Hint help is "Require a driver signature on completion of the Vehicle Checks".
Every field type created (except Label and Photo types) for a Vehicle Check UDF configuration must allow a "Defect" check-box fields to be configured, defaulting to unchecked.

UDF Configuration of Vehicle Checks fields

Note: If the type is changed, these new fields must be removed and any values entered in them removed.

When saving the configuration, the new header fields must be saved as attributes of the top-level FORM tag:

Frequency - a value of attribute FREQ
Require at Load End - a value of attribute AT_END. Only added if the check-box is checked, with value "Y".

The new Defect check-box will save as an attribute to the FIELD tag. Only added if the check-box is checked, with value "Y".

An example of the resulting checks (in UDF form) are:

<FORM FREQ="1" AT_END="N" REQUIRED="N">
   <FIELD ID="0001" DEFECT="Y">
       <TEXT>Fuel Tank Level</TEXT>
       <FORMAT>DDL</FORMAT>
       <REQUIRED>N</REQUIRED>
       <ITEMS>
           <ITEM CODE="0" DEFECT="Y">Empty</ITEM>
           <ITEM CODE="1">1/4</ITEM>
           <ITEM CODE="2">1/2</ITEM>
           <ITEM CODE="3">3/4</ITEM>
           <ITEM CODE="4">Full</ITEM>
       </ITEMS>
   </FIELD>
   <FIELD ID="0002" DEFECT="Y">
       <TEXT>Checks</TEXT>
       <FORMAT>X2</FORMAT>
       <REQUIRED>N</REQUIRED>
       <ITEMS>
           <ITEM>First Aid Kit</ITEM>
           <ITEM>Tyres</ITEM>
           <ITEM>Lights</ITEM>
           <ITEM>Oil</ITEM>
           <ITEM>Water</ITEM>
           <ITEM>Windows</ITEM>
           <ITEM>Mirrors</ITEM>
           <ITEM DEFECT="Y">COSHH Manual</ITEM>
       </ITEMS>
   </FIELD>
   <FIELD ID="0003" DEFECT="Y">
       <TEXT>Defects</TEXT>
       <FORMAT>T</FORMAT>
       <REQUIRED>N</REQUIRED>
   </FIELD>
</FORM>

The Vehicle Check Results screen (vehicle_check_response.aspx) should be modified.

The Filter panel should be modified to add the Status of the check, allowing values of

"D" - Defect.
"P" - Passed.
"R" - Resolved.

These values should be translated through values on EPOD_LIST and EPOD_LIST_ITEMS.

The results table should be modified to add the status of the check to the right-hand side of the table. The rows should be highlighted through the background colour if the check is status Defect (applying the standard class "Cancelled").

Vehicle Checks Search and Results Table

When clicking Select against a check, the pop-up details screen should be modified to display the status is the header. Additionally, each check displayed with an attribute of "DEFECT" set to "Y" should be highlighted with a red border. For multi-checks, each item with an attribute of "DEFECT" set to "Y" should be highlighted with a red border.

Vehicle Checks popup

The pop-up details screen should be expanded to have multiple tabs, along with an expansion on the size. The first tag should be "Results" and the second "Resolution Notes". The second tab should be displayed only if the status is not "P" - Passed.

The tab should include a Notes text area, allowing the user to enter any notes and displaying any already entered. A Check-box labelled "Resolved" should also be displayed, set to checked and disabled (but visible) if the status is "R" - resolved.

A Save button will be provided to save the resolution notes. This will save the notes and stamp the checks with the User ID, date and time. If the user checks the Resolved check-box and saves, the status will also be saved as "R" - "Resolved".

If resolved, the pop-up screen should show the Resolution Date and Time, plus the resolver user ID.

Vehicle Checks popup

Note: Vehicle Check Reports must be made compatible with the new UDF configuration and maintain compatible with the old (VEHICLE_CHECK) configuration.

Device

This configuration will be sent to the device, which will check this when entering the checks.

Each field will be marked as being a potential defect check by checking the attribute "DEFECT" against the field, and setting a property of "isDefect" value true against the field.

If the field is a DDL, each item marked as a potential defect will be stored in a delimited list in a property defectVals held against the field.

If a field is marked as a defect check, the value will be checked based on the type as follows:

Text and Numeric fields - if a value is entered, this is a defect.
Boolean - if the value is false, this is a defect.
Tri-state checks - if the value is "N", this is a defect.
Multi-checks - if the item indicated has a value of false, this item is a defect, as is the whole field.
Multi-tri-state checks - if the item indicated has a value of "N", this item is a defect, as is the whole field.
DDL - if the value selected is one of the values indicated as a defect, the whole field is a defect.

To mark as a defect, a new property hasDefects will be set to true against the field.

If any check on the vehicle check form is a defect (i.e. a field has a property hasDefects set to true), the whole check is marked as defect, by setting a property hasDefects to true against the whole UDF (pre-set to false initially).

When resulting XML is produced:

If an item has a defect value, the item has an attribute "DEFECT" set to "Y".
If a field has a defect value or an item with a defect value, the field has an attribute "DEFECT" set to "Y".
If a form has a field with a defect value, the form has an attribute "DEFECT" set to "Y".

An example of the resulting update is as follows:

<VEHICLE_CHECK_UPDATE ID="1" SITE="MAN_TRSPT" USER="xx" PASSWORD="xx" 
   DEVICE_ID="b17834c3cfe800e0" GPS_STAMP="53.3490522,-2.8521485" 
   DEVICE_OS="android 6.0" DEVICE_TYPE="P9000" TZ="Europe/London">
   <EPL_SITE_ID>MAN_TRSPT</EPL_SITE_ID>
   <EPL_VEHICLE_ID>MF61 OGG</EPL_VEHICLE_ID>
   <EPL_USER_ID>xx</EPL_USER_ID>
   <DATE_TIME>2016-12-13T15:24:21</DATE_TIME>
   <FORM DEFECT="Y">
       <FIELD ID="0001" DEFECT="Y">
           <TEXT>Fuel Tank Level</TEXT>
           <SUBTEXT />
           <GROUP />
           <POST />
           <FORMAT>DDL</FORMAT>
           <REQUIRED>N</REQUIRED>
           <ITEMS>
               <ITEM CODE="">Select a Value</ITEM>
               <ITEM CODE="0" DEFAULT="Y">Empty</ITEM>
               <ITEM CODE="1">1/4</ITEM>
               <ITEM CODE="2">1/2</ITEM>
               <ITEM CODE="3">3/4</ITEM>
               <ITEM CODE="4">Full</ITEM>
           </ITEMS>
           <VALUE>0<VALUE>
       </FIELD>
       <FIELD ID="0002" DEFECT="Y">
           <TEXT>Checks</TEXT>
           <SUBTEXT />
           <GROUP />
           <POST />
           <FORMAT>X2</FORMAT>
           <REQUIRED>N</REQUIRED>
           <ITEMS>
               <ITEM ID="0001" VALUE="false">First Aid Kit</ITEM>
               <ITEM ID="0002" VALUE="false">Tyres</ITEM>
               <ITEM ID="0003" VALUE="false">Lights</ITEM>
               <ITEM ID="0004" VALUE="false">Oil</ITEM>
               <ITEM ID="0005" VALUE="false">Water</ITEM>
               <ITEM ID="0006" VALUE="false">Windows</ITEM>
               <ITEM ID="0007" VALUE="false">Mirrors</ITEM>
               <ITEM ID="0008" VALUE="N" DEFECT="Y">COSHH Manual</ITEM>
           </ITEMS>
       </FIELD>
       <FIELD ID="0003" DEFECT="Y">
           <TEXT>Defects</TEXT>
           <SUBTEXT />
           <GROUP />
           <POST />
           <FORMAT>T</FORMAT>
           <REQUIRED>N</REQUIRED>
           <VALUE>Has Defects</VALUE>
       </FIELD>
   </FORM>
   <REQUEST_TIME_DATE>2016-12-13T15:24:21</REQUEST_TIME_DATE>
</VEHICLE_CHECK_UPDATE>

Appendix A: TEST PLAN

Test Script / Scenario Reference	Marking Vehicle Checks as Defects	Call Number(s): 340070 PROD-68
Test Script / Scenario Description	Testing that Vehicle Checks can be marked as defective, then resolved.	PASS / ISSUES / FAIL
Menu Access	N/A
Pre-requisites	None	Tested By:
Test Objective	To test that: Vehicle Checks can be configured through UDF correctly; vehicle checks can be marked as defects; the results can be reported and viewed; defects can be resolved.	Date:

Step	Action	Result	Remarks	P/F
1	Admin (Configuration)

1.01	Configure a new Vehicle Checks UDF, with multiple fields, and check or enter values in all the new entry items. Save all items and the UDF.	The UDF header allows entry of new fields. Each field allows entry of Defect checkbox. The UDF is generated as expected.
1.02	Configure a new Vehicle Checks UDF, with multiple fields, and DO NOT change values in all the new entry items. Save all items and the UDF.	The UDF is generated as expected.
1.03	Create any other UDF configuration except vehicle checks. Add fields. Save all items and UDF.	The UDF header does not contain the new fields. Each field does not show the entry of Defect checkbox. The UDF is generated as expected.
1.04	Edit a Vehicle Checks UDF. Change the type to any other type. Save.	When the type is changed, the new fields are removed. When saving, none of the new tags are saved with the UDF.

Step	Action	Result	Remarks	P/F
2	Mobile Device Application
	Configure UDF Vehicle Checks with all field types, with and without defect values. For multi-types (list types) DDLs, ensure that some values are defect, some are not. Ensure all are not required fields.
2.01	Do vehicle checks. Check all check boxes. Enter nothing in the text, area or numeric boxes. Select a value from the DDLs that are not defect values.	The resulting check will not be a defect.
2.02	Do vehicle checks as per the first test. Set all Tri-state elements (list and single) to "N" (red X).	The result should be a defect.
2.03	Do the vehicle checks as per the first test. Enter a value in all text, area and numeric boxes.	The result should be a defect.
2.04	Do the vehicle checks as per the first test. Enter the DDL value that is a defect.	The result should be a defect.
2.05	Do vehicle checks. Leave all fields blank.	The result should be a defect due to the Boolean and Check List types being unset.

Step	Action	Result	Remarks	P/F
3	Admin (Results)
	Dependent on the prior checks. Can be run in tandem with the device checks.
3.01	Enter the Vehicle Check Results screen.	The Find panel should display a facility to filter by Status.
3.02	Find only Defects	Only defective checks are shown, all highlighted in red. The status is displayed.
3.03	Refind, clear all filters and find all.	All checks from the previous test should be present, with defects highlighted in red. The status is displayed.
3.04	Select a Passed check.	The information is displayed in the popup. Only the Results tab is shown. The status is displayed. No checks are highlighted in red as defects.
3.05	Select a Defect check.	The information is displayed in the popup. The Results and Resolution Notes tabs are shown. The status is displayed. Defect checks are highlighted in red.
3.06	Click Resolution Notes. Enter a note. Do not check the Resolved check-box. Save.	The check is saved. The status is still Defect.
3.07	Click Resolution Notes. Enter a note. Do not check the Resolved check-box. Save.	The check is saved, The status is Resolved. The Resolution Date/Time and User is shown on the header.
3.08	Exit and Re-find the data in the screen, filtering for status Resolved.	Only Resolved checks are shown. The status is displayed.
3.09	Run the report on a defective, passed and resolved set of checks.	The report is displayed as expected.

Appendix B: 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	1.00	0.50	0	£0.00
Technical Specification	0.00	0.00	0	£0.00
Development	4.00	4.25	0	£0.00
Testing and Release	0.75	1.00	0	£0.00
Implementation	0.25	0.25	0	£0.00
Project Management	0.25	0.25	0	£0.00

TOTAL	6.25	6.25		£0.00

Estimate excludes training, release to live and go live support.

B.1 References

Ref No	Document Title & ID	Version	Date
1

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

Murray Middleton

OBSL Development Manager

_____________________________

Anonymous

Search

FS 340070 PROD-68 Marking Vehicle Checks as Defects

Namespaces

More

Page actions

Contents

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Admin

Device

Appendix A: TEST PLAN

Appendix B: Quote & Document References

Navigation

Navigation

Translate

Wiki tools

Wiki tools

Anonymous

Search

FS 340070 PROD-68 Marking Vehicle Checks as Defects

Functional Overview

Client Requirement

Solution Overview

Scope

Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database/DAL

Admin

Device

Appendix A: TEST PLAN

Appendix B: Quote & Document References

Navigation

Wiki tools

Page tools

Categories