FS 318084 SCR17 NHSBT C-EPOD Swap Van
NHSBT
Swap Van
CALIDUS ePOD
4th June 2014 - 0.1
Reference: FS 318084 SCR17
Contents
Functional Overview
Client Requirement
The following changes from the Solution Design document are included in this specification:
- SCR-316403-91 - CTMS-EPOD Interface
- The EPOD interface to the device regarding users and vehicles must be modified to ensure that only changed vehicles and drivers are interfaced (including any drivers/vehicles that have been deleted).
- SCR-316403-99 - Swap Van
- Ensure driver informed to swap vehicle; perform vehicle checks
Solution Overview
On some BMV journeys (rather than waiting for a BMV to get to the correct temperature), and also on Birmingham-Stoke-Manchester journeys specifically, the entire contents of the vehicles are swapped. In this case, the items are not scanned off and on each vehicle, but instead the drivers simply swap vehicles.
To achieve this functionality within the systems, changes will be required to complete this (SCR-316403-06 and SCR-316403-99). The functionality would be expected to be as follows:
The decision to swap vehicles is made by the planners, and therefore there needs to be a capability to set this on the trip drops before they depart. If the trip is marked as a swap required by the planners, then the C-EPOD device must be configured not to scan items on or off the vehicle, just provide instructions about to whom to pass the keys. Signature will still be required for the delivery aspect, however.
Driver - Collect at Depot:
The loading of the items at the depots can include single-trip assets (i.e. for other transport). The items that are being loaded may be for multiple orders and therefore multiple destinations.
- The driver navigates to the depot using TomTom.
- The driver selects the location from the CALIDUS ePOD Job List screen. If there are multiple orders being collected, the orders will be consolidated into one location. The device will show how many of each asset type are expected to be loaded.
- The driver scans to collect through the Asset ID (either permanent Cage assets or Single Trip assets, like post). If there are multiple destinations on the orders, the C-EPOD device will prompt the user to select the destination for the cage from a drop-down list. This is the same process as BMV movements.
- A signature is not required.
Driver - Deliver at Swap Vehicle location:
- The driver navigates to the depot using TomTom.
- The driver selects the location from the CALIDUS ePOD Job List screen. If there are multiple orders being delivered, the orders will be consolidated into one location.
- The Job Details screen will display instructions to "swap to vehicle X and obtain driver signature".
- The device will show how many of each asset type are expected to be delivered.
- The driver will click the Start Job button.
- The Delivery screen is shown - no Item details are presented for this delivery job. The screen will just shows the Job Details tab.
- The driver will click the Complete button.
- A signature is required when delivering – the signature of the other driver will be obtained.
- The driver changes the driver ID on the TomTom device in cab on the new vehicle.
Driver - Collect at Swap Vehicle location:
- The Collection (i.e. the Swap Van) from this location immediately starts.
- The Job Details screen shows that this is a Swap Vehicle job, showing the registration to be swapped to.
- The driver will click the Start Job button.
- The device will prompt the driver to confirm the vehicle being swapped to, displaying the registration. The driver will press a Confirm button.
- The device will then display the Vehicle Defect checks for the new vehicle - these must be completed for the new vehicle.
- Once completed, the Collection screen is shown - no Item details are presented for this delivery job. The screen will just shows the Job Details tab.
- The driver will click the Complete button.
- A signature is not required - the device will move back to the Job List screen.
Driver - Deliver to destination location:
- The driver navigates to the depot using TomTom.
- The driver selects the location from CALIDUS ePOD. If there are multiple orders being delivered, the orders will be consolidated into one location.
- The driver scans to deliver through the Asset ID - all items are scanned off the vehicle. The device will show all deliverable items.
- A signature is required when delivering.
Scope

Set-up
Pre-requisites
- A working CALIDUS ePOD system.
CALIDUS TMS Interface Changes
The interface of jobs through to C-EPOD will include the following details and changes:
- The interface will include details of the availability of vehicles, through the existing C-EPOD EPOD_IMPORT tag EPOD_VEHICLES. These changes regarding the EPOD interface will be completed under reference 317907/SCR01.
- The interface will identify when a vehicle swap is being made, through the use of the Trailer ID against the job (EPL_TRAILER_ID of EPOD_JOB). The changes regarding the EPOD interface for this will be completed under reference 317771/SCR17
- No Item details will be present for the delivery or collection job at the location at which the drivers will swap vehicles.
- The instructions for the collection and delivery jobs at this "Swap Vehicle" location will show instructions to "Swap with Driver X, vehicle Y and obtain signature".
- The interface to the TomTom device will show all locations up to the swap location from trip 1, then all locations from that swap location on trip 2. Changes for the TomTom interface are specified under reference 316291/SCR02.
- If trips have been created that swap vehicles with other depots, the vehicles should be added to both depots when this was indicated by the user. This should be through the standard EPOD_VEHICLES interface format. This may be prepended to the EPOD_TRIP message sent in to the driver, although if required this will require a change to the sequence of tabs in the standard C-EPOD upload XSD.
Menu Structure
None
Data
- Device configured to NHSBT style
- Sites set up for each depot (carrier), with the following PDA options:
- "Trailer/Vehicle Combined" enabled (EPL_TRAILER_VEHICLE_FLAG = "Y")
Functional Description
Database/DAL changes
Table EPOD_USER requires the following modification:
- EPL_USER_ACTIVE will be modified to nvarchar(2)
Existing packages will be modified to allow the creating, editing and selecting of the new fields, including but not limited to:
- EPOD_USER_INSERT
- EPOD_USER_NAMESELECT
- EPOD_USER_SEARCH
- EPOD_USER_SELECT
- EPOD_USER_SELECT_UPDATED_DATA
- EPOD_USER_SELECT2
- EPOD_USER_UPDATE
The existing EPOD_USER DAL object will be changed to effect this field length modification.
Table EPOD_VEHICLE requires the following modification:
- EPL_STATUS will be modified to nvarchar(2)
Existing packages will be modified to allow the creating, editing and selecting of the new fields, including but not limited to:
- EPOD_VEHICLE_INSERT
- EPOD_VEHICLE_SELECT
- EPOD_VEHICLE_SELECT_UPDATED_DATA
- EPOD_VEHICLE_UPDATE
The existing EPOD_VEHICLE DAL object will be changed to effect this field length modification.
Table EPOD_SITE requires the following modifications:
- EPL_TRAILER_VEHICLE_FLAG - 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:
- Read the new flag
Note: It is not necessary to add this flag as a search-able 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.
The XML Export of EPOD_SITE records will 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> <EPL_PDA_FULL_ADDRESSES></EPL_PDA_FULL_ADDRESSES> <EPL_JOB_TRANSFER></EPL_JOB_TRANSFER> <EPL_NEXT_JOB_FLAG></EPL_NEXT_JOB_FLAG> <EPL_RETURNS_DEPOT_FLAG></EPL_RETURNS_DEPOT_FLAG> <EPL_SCANNING_FLAG></EPL_SCANNING_FLAG> <EPL_AUTOLOGIN_FLAG></EPL_AUTOLOGIN_FLAG> <EPL_ADHOC_ANYTIME_CONFIG></EPL_ADHOC_ANYTIME_CONFIG> <EPL_AUDIT_LOGIN_FLAG></EPL_AUDIT_LOGIN_FLAG> <EPL_TRAILER_VEHICLE_FLAG></EPL_TRAILER_VEHICLE_FLAG> </EPOD_SITE>
Import/Export Messages
Both the dataservice webservices (ePOD_DataService.asmx and ePOD_DataService2.asmx) and the AutoImport application will need to change the way Vehicles are imported into C-EPOD.
When receiving records, an Action tag is received, showing what should be done with the message. The values of this EPL_ACTION field should be:
- "A" - Add/Amend the indicated Vehicle
- "D" - Delete the indicated Vehicle
- "X" - Delete all Vehicles for the indicated site
When deleting, the status of the vehicle (EPL_STATUS) should be set to "X".
When adding or updating, ensure that the service checks for a record present first and, if found, updates accordingly.
When updating records through this interface, the Last Changed date and time should be updated if the details have changed in any way. Note: Just issuing an update to a record is not a reason to set the Last Changed record - actual changes must be made to other data to do this.
When refreshing all Vehicle records for a site, the received file should start with a request to delete all vehicle records for the site, then a record for each item to be added again. The incoming file should resemble the following example:
<EPOD_VEHICLES> <EPOD_VEHICLE> <EPL_SITE_ID>SITE</EPL_SITE_ID> <ACTION>X</ACTION> </EPOD_VEHICLE> <EPOD_VEHICLE> <EPL_SITE_ID>SITE</EPL_SITE_ID> <EPL_VEHICLE_ID>1</EPL_VEHICLE_ID> <EPL_VEHICLE_REG>AB12XYZ</EPL_VEHICLE_REG> <EPL_DESCRIPTION>LWB Transit</EPL_DESCRIPTION> <EPL_VEHICLE_MILEAGE>0</EPL_VEHICLE_MILEAGE> <EPL_STATUS>Y</EPL_STATUS> <ACTION>A</ACTION> </EPOD_VEHICLE> ... </EPOD_VEHICLES>
In this case, the process should first mark all records as potential to be deleted (by inserting "X" after the current value of the EPL_STATUS field against EPOD_VEHICLE e.g. EPL_STATUS of "Y" becomes "YX"). Each subsequent entry in the file will then update the concomitant EPOD_VEHICLE record in the database, checking whether anything has changed, ensuring that the value of EPL_STATUS in the EPOD_VEHICLE file is checked against only the first character in the database field. If nothing has changed, only the EPL_STATUS field should be updated, not Last Changed fields. If any other fields have changed, the Last Update fields should be changed to the current date and time stamp. Once all Vehicle records in the incoming file are dealt with, the process should check for any records with an EPL_STATUS field of 2 characters, set the EPL_STATUS field to "X", and update the Last Changed date and time to the current date and time.
When refreshing all User records for a site, the received file should start with a request to delete all user records for the site, then a record for each item to be added again. The incoming file should resemble the following example:
<EPOD_USERS> <EPOD_USER> <EPL_SITE_ID>SITE</EPL_SITE_ID> <ACTION>X</ACTION> </EPOD_USER> <EPOD_USER> <EPL_SITE_ID>SITE</EPL_SITE_ID> <EPL_USER_ID>USER1</EPL_USER_ID> <EPL_USER_NAME>D. River-Name</EPL_USER_NAME> <EPL_USER_ADMIN>N</EPL_USER_ADMIN> <EPL_USER_ACTIVE>Y</EPL_USER_ACTIVE> <ACTION>A</ACTION> </EPOD_USER> ... </EPOD_USERS>
In this case, the process should first mark all records as potential to be deleted (by inserting an X after the current value of the EPL_USER_ACTIVE field against EPOD_USER e.g. EPL_USER_ACTIVE of "Y" becomes "YX"). Each subsequent entry in the file will then update the concomitant EPOD_USER record in the database, checking whether anything has changed, ensuring that the value of EPL_USER_ACTIVE in the EPOD_USER file is checked against only the first character in the database field. If nothing has changed, only the EPL_USER_ACTIVE field should be updated, not Last Changed. If any other fields have changed, the Last Update fields should be changed to the current date and time stamp. Once all User records in the incoming file are dealt with, the process should check for any records with an EPL_USER_ACTIVE field of 2 characters, set the EPL_USER_ACTIVE field to "X", and update the Last Changed date and time to the current date and time.
The PDA web request server (Calidus_ePOD.asmx, both the XML and JSON versions) will be modified to to ensure that only changed vehicles and drivers are interfaced (including any drivers/vehicles that have been deleted).
The LOGON_REQUEST message will be modified to add a new value to the existing UPDATE_REQUIRED tag, as follows:
<LOGON_REQUEST ID="" ...> <EPL_SITE_ID>XXXXXXXXXX</EPL_SITE_ID> <EPL_USER_ID>XXXXXXXXXX</EPL_USER_ID> <EPL_VEHICLE_ID>XXXXXXXXXX</EPL_VEHICLE_ID> <EPL_LAST_UPDATE_DATE_TIME>2011-01-01T09:09:09</EPL_LAST_UPDATE_DATE_TIME> <PDA_VERSIONS> <EPOD_CLIENT version="" debug="" /> <EPOD_UPDATER version="" /> </PDA_VERSIONS> <JSONIF>Y</JSONIF> <UPDATE_REQUIRED>C</UPDATE_REQUIRED> </LOGON_REQUEST>
If the "UPDATE_REQUIRED" tag is present with a value of "C", the process will respond with details in the same way as it does if the flag is "Y", except for the EPOD_VEHICLE and EPOD_USER tables.
Currently, the process retrieves all records for these tables for the site, if any record on the table has changed since the last successful logon response message was processed by the device (the values in EPL_LAST_UPDATE_DATE_TIME>.
For these tables, the process will change to retrieve only the records with a Last Changed date and time after the value in the EPL_LAST_UPDATE_DATE_TIME flag and return those records only.
Note that the UPDATE_REQUIRED tag will be returned with the LOGON_RESPONSE message, with the value as set in the LOGON_REQUEST message. Note also that this does not affect initial logon messages - these will still retrieve and return all standing data for all tables.
In order for this change to work as expected, there must be a firm control of when the last update date and time are changed for these records. This should be as follows:
- When records are changed from an inbound webservice or the AutoImport process.
- When standing data is changed through the maintenance screens.
The last update date and time fields should not be changed if:
- Any of the following fields are updated against the user:
- EPL_USER_ACTIVITY_DATE
- EPL_USER_ACTIVITY_TIME
- EPL_USER_VEHICLE
- EPL_USER_LOAD
- EPL_USER_JOB
- Any of the following fields are updated against the vehicle:
- EPL_DESCRIPTION
- EPL_VEHICLE_MILEAGE
- EPL_LAST_POSITION
- EPL_LAST_POSITION_DATE
- EPL_LAST_POSITION_TIME
The PDA web request server (Calidus_ePOD.asmx) will be modified to to ensure that swapped vehicles are updated when the Job is updated. This affects the JOB_UPDATE_REQUEST message processor.
The process will be modified to update the trailer on the job from the incoming message (EPL_TRAILER_ID of EPOD_JOB).
If the new processing is required (EPL_TRAILER_VEHICLE_FLAG = "Y"), the process will also be modified to:
- Update the current user with the new vehicle from the Trailer ID (EPL_USER_VEHICLE of EPL_USER set to EPL_TRAILER_ID).
- To mark this vehicle as Active (EPL_STATUS = "Y" of the EPOD_VEHICLE record where for this site and EPL_TRAILER_ID).
- To mark the vehicle previously used on this load as inactive (set EPL_STATUS = "N" where the EPOD_VEHICLE record for this site and EPL_VEHICLE_ID of EPOD_LOAD).
- To mark the Load as now using this vehicle (EPL_VEHICLE_ID of EPOD_LOAD set to the value in EPL_TRAILER_ID).
The XMLUpload XSD file and all standard documentation must be updated to show all the changes identified here.
Admin Changes
The Site maintenance screen (site_header.aspx) will be modified to allow the system to be configured for:
- EPL_TRAILER_VEHICLE, a checkbox, labelled as "Change Vehicle through Trailer", defaulting to 'N' (Disabled).
This configuration field will be added to the PDA tab of this maintenance screen.
Note: Ensure that the new check-boxes line up with the existing fields.
The Vehicle maintenance screen (vehicle_maintenance.aspx) will be modified as follows:
- The Delete button will now only mark records for deletion, by setting the Status field to "X".
- Pressing the Delete button on a record that has been marked for deletion will delete the record from the database.
- The filter (accessible through the Find button) will allow the selection of Deleted as one of the options in the Status drop-down list.
- Pressing the Search button with no Status selected will only show records that are not marked for deletion by default.
- The Status drop-down list will be able to show the value "Deleted" when editing (through the Select button) and adding new vehicles (through the New button.
- The vehicles table will display the status as "Deleted" if the record is found and displayed with that status.
The Users maintenance screen (vehicle_maintenance.aspx) will be modified as follows:
- The Delete button will now only mark records for deletion, by setting the Status field to "X".
- Pressing the Delete button on a record that has been marked for deletion will delete the record from the database.
- The Search filter (found through clicking the Find button) will have the "User Active" field added (with label "Status"), to allow filtering of the users. This new drop-down list will show values "Active", "Inactive" and "Deleted" for selection, as well as a default value.
- Pressing the Search button with no Status selected will only show records that are not marked for deletion by default.
- The Active drop-down list will be able to show the value "Deleted" when editing (through the Select button) and adding new vehicles (through the New button.
- The users table will display the status as "Deleted" if the record is found and displayed with that status.
PDA Changes
Database/DAL changes
Table EPOD_SITE requires the following modifications:
- EPL_TRAILER_VEHICLE_FLAG - nvarchar(1), default 'N'.
Table EPOD_JOB requires the following modification:
- EPL_TRAILER_ID - nvarchar(20), DEFAULT ' '.
The DAL objects for the tables above must be modified as follows:
- Add these items as parameters to every method definition and SQL parameter that uses the tables, along with all other functions within the DAL js files, dealing with the tables.
- The functions for populating the tables will be modified to ensure that the default values are correctly set for the fields.
The PDA objects affected are:
- PDA_SITE
- PDA_JOB
The XML Export of EPOD_JOB will change to add the new fields EPL_TRAILER_ID. This will be changed in the PDA_JOB DAL object method ToUpdateXElement. The new format will be as follows:
<EPOD_JOB> <EPL_SITE_ID></EPL_SITE_ID> <EPL_LOAD_ID></EPL_LOAD_ID> <EPL_JOB_ID></EPL_JOB_ID> <EPL_USER_ID></EPL_USER_ID> <EPL_VEHICLE_ID></EPL_VEHICLE_ID> <EPL_START_DATE_TIME></EPL_START_DATE_TIME> <EPL_ARRIVAL_DATE_TIME></EPL_ARRIVAL_DATE_TIME> <EPL_END_DATE_TIME></EPL_END_DATE_TIME> <EPL_STATUS></EPL_STATUS> <EPL_CONTACT></EPL_CONTACT> <EPL_INVOICED></EPL_INVOICED> <EPL_SIGNED_UNCHECKED></EPL_SIGNED_UNCHECKED> <EPL_USER_NOTES></EPL_USER_NOTES> <EPL_TNCS></EPL_TNCS> <EPL_AMENDED_FLAG></EPL_AMENDED_FLAG> <EPL_JOB_STATUS></EPL_JOB_STATUS> <EPL_UDF_JOBDETS></EPL_UDF_JOBDETS> <EPL_LINKED_ID></EPL_LINKED_ID> <EPL_GENERATED></EPL_GENERATED> <EPL_TRAILER_ID></EPL_TRAILER_ID> <CONFIRMATION> <EPL_ENG_SIGNATURE></EPL_ENG_SIGNATURE> <EPL_JOB_SIGNATURE></EPL_JOB_SIGNATURE> </CONFIRMATION> <EXCEPTION type="job"> <EPL_REASON_CODE></EPL_REASON_CODE> </EXCEPTION> <ADDITIONAL>...</ADDITIONAL> <SERVICES>...</SERVICES> <CONTAINERS>...</CONTAINERS> </EPOD_JOB>
Login
When a driver logs in to the application, or Re-logs in or changes vehicle (through the Job List menu), the application will show the Login screen.
If an on-line login has been completed successfully, the server will return a Logon Response message, detailing the standing data in the system.
Under this new mechanism, this message will be processed differently by the server and the content of the Vehicle and User portions of these portions of the Logon Response message will now be solely the changes that have occurred since the last successful "log on" message was processed. This will be indicated in the Logon Response message by the UPDATE_REQUIRED tag being returned as "C".
The Logon Response process will be modified to reflect this, by:
- No longer deleting all User and Vehicle records when a Login message is received.
- Add, Update or Delete User and Vehicle records as they are received instead.

- For an on-line login, set the UPDATE_REQUIRED tag on the LOGON_REQUEST message to "C". The value of this tag will be returned in the LOGON_RESPONSE message.
- The ProcessLoginResponse function will checking for the UPDATE_REQUIRED tag.
- If "Y", the process will act as now. If "C":
- For EPOD_VEHICLE records:
- If the field EPL_STATUS = "X", find and delete the EPOD_VEHICLE record indicated.
- In any other case, attempt to find the indicated record first. If not found, create the record, if found, update the record.
- For EPOD_USER records:
- If the field EPL_USER_ACTIVE = "X" or "N", find and delete the EPOD_USER record indicated.
- In any other case, attempt to find the indicated record first. If not found, create the record, if found, update the record.
- This change does not affect first logon messages.
Job Details
When a job is selected from the Job List, the Job Details screen is displayed.
When delivering to the Swap Vehicle location, the information on the jobs at this location will show the Vehicle and Driver with whom to swap vehicles. This will be as sent through from C-TMS to C-EPOD. The text is expected to say "Swap with Driver X, vehicle Y and obtain signature".
The Address & Contact tab will be modified to display the vehicle registration of the vehicle that the user is expected to collect. This will be the registration of the vehicle ID sent through to C-EPOD from C-TMS, on the collection job only. This can be seen in the screen prototypes above.
This will be sent to the EPOD device in the existing field EPL_TRAILER_ID of EPOD_JOB.
When the driver presses the Start Job button, the screen will check whether the the device is configured for vehicle changes through the trailer ID (EPL_TRAILER_VEHICLE_FLAG = "Y"). If so, and the Trailer ID of the job has been set, the device will display a pop-up alert, asking for confirmation that the vehicle has been swapped with the text "Confirm Swap Vehicle"/"Confirm swapping to vehicle X", where X is the vehicle registration, and the options are Cancel and Confirm. If the user clicks Cancel the device will return to the Job Details screen. If the user clicks Confirm, the screen will call the Vehicle Check process, to perform the defect checks on the new vehicle.
Note: The vehicle checks must be completed. This requires either that there is no way to exit the vehicle checks, or that, if pressed, an appropriate pop-up choice is provided and the user taken back to the Job Details screen.
When the vehicle defect checks are completed, the process will then action the job (i.e. move on to the Collection process).
If the "Trailer-Vehicle" configuration is as expected, and the Trailer ID has not been set against the job, the Trailer ID should be defaulted to be the current vehicle ID (i.e. EPL_TRAILER_ID set to EPL_USER_VEHICLE of EPOD_USER).
If the "Trailer-Vehicle" configuration is disabled, the Trailer ID should be left blank.
Note: The Trailer ID will only be pre-set in this way on the Collection job from the Job Swap location.
Delivery/Collection Process
Note: Their should be no changes required to this process - the overview shows the current functionality as expected to be configured for this process, using the standard configuration for the operation. As there will be no items on these jobs for these loads, both at the collection and delivery point, the jobs may be completed by pressing the Complete button on the Job Details tab. This will move on to the Job Completion process below.
Job Completion
Delivery jobs are expected to be configured to require a customer signature and so the device will display the Customer Signature screen. This will be completed by the other driver, capturing the driver name and signature.
Collections are expected to be configured without any required signature and so will immediately display that the job has been completed.
Note: No software changes are required for this functionality - this is the standard configuration of jobs for this customer.
When the collection job is completed for a job swap (i.e. a different vehicle in the trailer ID to the one that the driver is currently using), the vehicles should be updated on the device. If the new processing is required (EPL_TRAILER_VEHICLE_FLAG = "Y"), the process will also be modified to:
- Update the current user with the new vehicle from the Trailer ID (EPL_USER_VEHICLE of EPL_USER set to EPL_TRAILER_ID).
- To mark this vehicle as Active (EPL_STATUS = "Y" of the EPOD_VEHICLE record where for this site and EPL_TRAILER_ID).
- To mark the vehicle previously used on this load as inactive (set EPL_STATUS = "N" where the EPOD_VEHICLE record for this site and EPL_VEHICLE_ID of EPOD_LOAD).
- To mark the Load as now using this vehicle (EPL_VEHICLE_ID of EPOD_LOAD set to the value in EPL_TRAILER_ID).
Appendix A: TEST PLAN
Test Script / Scenario Reference | Swap Van | Call Number(s): 318084 SCR17 |
Test Script / Scenario Description | Test the Swap Van functionality. | PASS / ISSUES / FAIL |
Menu Access | None | |
Pre-requisites | Data set up as per Data Setup section. | Tested By: |
Test Objective | To test that: vehicles and users are correctly interfaced from C-TMS; vehicles and users are incrementally updated correctly to the Android application; Swapping a van at a specific point on two trips is recognised and prompted; swapped vehicles are defect checked. | Date: |
Step | Action | Result | Remarks | P/F |
1 | Import/Export Tests | |||
1.01 |
Step | Action | Result | Remarks | P/F |
2 | PDA Tests | |||
2.01 |
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.25 | 1.25 | 0 | £0.00 |
Technical Specification | 0.00 | 0.00 | 0 | £0.00 |
Development | 6.00 | 6.00 | 0 | £0.00 |
Testing and Release | 1.25 | 1.25 | 0 | £0.00 |
Implementation | 0.00 | 0.00 | 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. |
B.1 References
Ref No | Document Title & ID | Version | Date |
1 | NHSBT High Level Solution Design v2.0.doc | 2.0 | 21/05/2014 |
2 | FS 317907 SCR01 EPOD-TMS Interface | ||
3 | FS 317761 SCR15 NHSBT C-EPOD Collection Changes | 0.4 | 04/06/2014 |
4 | FS 317771 SCR17 NHSBT C-TMS Swap Van | ||
5 | FS 316291 SCR02 NHSBT TomTom Interface |
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 | Project Manager | _____________________________ |
Ed Bond | Client Representative | _____________________________ |