View source for FS 318084 SCR17 NHSBT C-EPOD Swap Van

<div class="noprint">
{{#vardefine:Client|NHS}}
{{#vardefine:ClientName|NHSBT}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Swap Van}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th July 2014}}
{{#vardefine:Reference|318084 SCR17}}
{{#vardefine:Year|2014}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

<!-- TOC --> 
<div class="noprint">
= 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 Round Robin 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: 

== BMV ==
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. The collect at the depot will be marked with a different vehicle against that stop, which will trigger a confirmation of a vehicle change. All other functionality (scanning items, signatures) will remain as per normal deliveries. 


'''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.
*	A signature is not required. 


'''Driver - Deliver at Depot:'''
*	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 device will show how many of each asset type are expected to be delivered.
*   The driver will click the '''Start Job''' button.
*	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 – the signature of the other driver will be obtained. 


'''Driver - Collect at Depot:'''
*   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 defect checks are completed, 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.
*   A signature is not required for collections. The device will move back to the Job List screen. 
*   The driver changes the driver ID on the TomTom device in cab on the new vehicle.


'''Driver - Deliver to Depot:'''
*	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.


== Round Robin ==
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. The collect at the depot will be marked with a different vehicle against that stop, which will trigger a confirmation of a vehicle change. The delivery and collection at the depot stop is marked as "swap required" by the planners, which will instruct the C-EPOD device 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:'''

{{Note|On a full trip, the driver may have several normal deliveries to this depot as well as those that are being swapped with the other driver. In this case, these items will be seen as a separate job or job consolidation on the job list before the "swap van" jobs, and therefore will be completed separately. In the same way, there could be several orders for collection from hospital services from this depot - these should be prompted for after the swapping of the van.}}
*	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 not shown, as there are no details to confirm for the delivery job.
*	A signature is required when delivering – the signature of the other driver will be obtained. 


'''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 defect checks are completed, the job will be completed. There is no Collection screen to be shown - no Item details are presented for this job - and a signature is not required for collections. The device will move back to the Job List screen. 
*   The driver changes the driver ID on the TomTom device in cab on the new vehicle.


'''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 ==
{{Note|This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.}}
{{Note|Changes to planned vehicles on the trips that have planned a Swap Vehicle cross-dock of this type will require the orders on both trips updating, at the delivery and collection jobs (for instructions and to change the trailer ID). It is expected that this will not happen automatically and will be achieved manually through the screens in C-TMS.}}


<!-- NEW PAGE --> 
= Set-up  =

== Pre-requisites  ==
* A working {{#var:System}} 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 changes regarding the EPOD interface for Swap Vehicle will be completed under reference 317771/SCR17:
** The interface will identify when a vehicle swap is being made against the collection and delivery jobs at this location through a new flag EPL_SWAP_VEHICLE against all the job records on the trips at this location.
** The interface will also identify when the vehicle being swapped to against the collection job at this location, through the use of the Trailer ID (EPL_TRAILER_ID of EPOD_JOB). This applies to BMV and Round Robin vehicle swaps.
** Item/container details will be present for the delivery and collection jobs at this Swap Vehicle location as normal - C-EPOD will handle whether the items must be displayed, based on whether it is marked as a Swap Vehicle job. This applies only to Round Robin swaps - BMV swaps will not require this.
** 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", if the Swap Vehicle flag is set. This applies only to Round Robin swaps - BMV swaps will not require this.
** On a full trip, the driver may have several normal deliveries to this depot as well as those that are being swapped with the other driver. In this case, these items will be seen as a separate job or job consolidation on the job list before the "swap van" jobs, and therefore will have a different Linked ID to identify this.
** 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.
** {{Note}} Changes to planned vehicles on the trips that have planned a Swap Vehicle cross-dock of this type will require the orders on both trips updating, at the delivery and collection jobs (for instructions and to change the trailer ID). It is expected that this will not happen automatically and will be achieved manually through the screens in C-TMS.
* 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.


== 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")


<!-- NEW PAGE --> 
= 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>
  

Table EPOD_JOB requires the following modification:
*    EPL_SWAP_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 field, including but not limited to:
*    EPOD_JOB_INSERT
*    EPOD_JOB_SEARCH
*    EPOD_JOB_SELECT
*    EPOD_JOB_SELECT_DATE_RANGE
*    EPOD_JOB_UPDATE 
The existing EPOD_JOB DAL object will be changed to:
*    Export the new field in XML requests
*    Read the new field
{{Note}} It is not necessary to add this field 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_JOB records will now look as follows: 
    <EPOD_JOB>
      <EPL_SITE_ID></EPL_SITE_ID>
      <EPL_JOB_ID></EPL_JOB_ID>
      <EPL_LOAD_ID></EPL_LOAD_ID>
      <EPL_JOB_TYPE></EPL_JOB_TYPE>
      <EPL_JOB_GROUP></EPL_JOB_GROUP>
      <EPL_JOB_INSTRUCTION></EPL_JOB_INSTRUCTION>
      <EPL_JOB_SIGNATURE></EPL_JOB_SIGNATURE>
      <EPL_REASON_CODE></EPL_REASON_CODE>
      <EPL_LINKED_REASON></EPL_LINKED_REASON>
      <EPL_STATUS></EPL_STATUS>
      <EPL_CUSTOMER_CODE></EPL_CUSTOMER_CODE>
      <EPL_PHOTO_ID></EPL_PHOTO_ID>
      <EPL_PHOTO></EPL_PHOTO>
      <EPL_ENG_SIGNATURE></EPL_ENG_SIGNATURE>
      <EPL_SEQUENCE></EPL_SEQUENCE>
      <EPL_START_PLANNED_DATE></EPL_START_PLANNED_DATE>
      <EPL_START_PLANNED_TIME></EPL_START_PLANNED_TIME>
      <EPL_END_PLANNED_DATE></EPL_END_PLANNED_DATE>
      <EPL_END_PLANNED_TIME></EPL_END_PLANNED_TIME>
      <EPL_START_ACTUAL_DATE></EPL_START_ACTUAL_DATE>
      <EPL_START_ACTUAL_TIME></EPL_START_ACTUAL_TIME>
      <EPL_END_ACTUAL_DATE></EPL_END_ACTUAL_DATE>
      <EPL_END_ACTUAL_TIME></EPL_END_ACTUAL_TIME>
      <EPL_DISTANCE_PLANNED></EPL_DISTANCE_PLANNED>
      <EPL_DISTANCE_ACTUAL></EPL_DISTANCE_ACTUAL>
      <EPL_DRIVING_TIME></EPL_DRIVING_TIME>
      <EPL_CUSTOMER_NAME></EPL_CUSTOMER_NAME>
      <EPL_INVOICED></EPL_INVOICED>
      <EPL_CUST_SIGNATORY></EPL_CUST_SIGNATORY>
      <EPL_JOB_CODE></EPL_JOB_CODE>
      <EPL_CUST_REF></EPL_CUST_REF>
      <EPL_OFFICE_INSTRUCTION></EPL_OFFICE_INSTRUCTION>
      <EPL_SIGNED_UNCHECKED></EPL_SIGNED_UNCHECKED>
      <EPL_SO_NUMBER></EPL_SO_NUMBER>
      <EPL_TNCS></EPL_TNCS>
      <EPL_ORDER_DATE></EPL_ORDER_DATE>
      <EPL_ORDER_TIME></EPL_ORDER_TIME>
      <EPL_SALES_CONTACT></EPL_SALES_CONTACT>
      <EPL_USER_NOTES></EPL_USER_NOTES>
      <EPL_OWNER_NAME></EPL_OWNER_NAME>
      <EPL_SERVICE_LEVEL></EPL_SERVICE_LEVEL>
      <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
      <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
      <EPL_ARRIVAL_DATE></EPL_ARRIVAL_DATE>
      <EPL_ARRIVAL_TIME></EPL_ARRIVAL_TIME>
      <EPL_XF_VALUES></EPL_XF_VALUES>
      <EPL_EXT_REF></EPL_EXT_REF>
      <EPL_TRAILER_ID></EPL_TRAILER_ID>
      <EPL_PF_DEPOT></EPL_PF_DEPOT>
      <EPL_PF_TRACKING_NO></EPL_PF_TRACKING_NO>
      <EPL_JOB_STATUS></EPL_JOB_STATUS>
      <EPL_UDF_JOBDETS></EPL_UDF_JOBDETS>
      <EPL_LINKED_ID></EPL_LINKED_ID>
      <EPL_ACCOUNT></EPL_ACCOUNT>
      <EPL_LOADING_TYPE></EPL_LOADING_TYPE>
      <EPL_GENERATED></EPL_GENERATED>
      ''<EPL_SWAP_VEHICLE></EPL_SWAP_VEHICLE>''
      <EPOD_CONTAINERS></EPOD_CONTAINERS>
      <EPOD_SERVICES></EPOD_SERVICES>
    </EPOD_JOB>


== 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, updated 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 the Last Changed Date and Time 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 the Last Changed Date and Time fields. 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.


Both the dataservice and PDA web request servers (ePOD_DataService.asmx, ePOD_DataService2.asmx and Calidus_ePOD.asmx) and the AutoExport and AutoImport applications will need to import and export the new EPOD_JOB field EPL_SWAP_VEHICLE. The messages affected are:
* AutoImport and ePOD_DataService:
** EPOD_XML_IMPORT 
* AutoExport:
**    EPOD_EXPORT_LOAD
**    EPOD_EXPORT_JOB 
* ePOD_DataService
**    EPOD_EXPORT_LOAD_RESPONSE
**    EPOD_EXPORT_JOB_RESPONSE 


{{Note}} All XSDs should be modified to include the new field, along with the standard documentation. This includes but is not limited to:
*    XMLUpload.xsd

The field definition should be added to the XSD in the appropriate position as follows:
    <xsd:element name="EPL_SWAP_VEHICLE" nillable="true" minOccurs="0" maxOccurs="1">
      <xsd:annotation>
        <xsd:documentation>
          Indicates whether the job is a vehicle swap (i.e. requires no item-related action in C-EPOD)
        </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:maxLength value="1" />
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
The element will be added in the EPOD_JOB tag as the last elements before EPOD_CONTAINERS.


The PDA web request server (Calidus_ePOD.asmx, both the XML and JSON versions) will be modified 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
{{Note}} This may be achieved within the EPOD_USER and EPOD_VEHICLE DAL objects, so that this functionality may also be replicated within the Admin screens without any additional effort.


The PDA web request server (Calidus_ePOD.asmx) will be modified 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. Additionally, this must be changed to move the sequence of data tags around as follows:
* EPOD_CUSTOMERS
* EPOD_SERVICE_PRODUCT_MASTERS
* EPOD_VEHICLES
* EPOD_USERS
* EPOD_REASON_CODES
* EPOD_LOADS
* EPOD_JOBS
This is to ensure that standing data is created before transactional data, ensuring that they can both be specified and used in the same file without the transactional data failing validation.


== 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) but not when 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.
{{Note}} Changes to the vehicle Description or Mileage should not result in the Last Changed Date and Time being changed. This is most likely controlled already through changes to the EPOD_VEHICLE DAL object.


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) but not when adding new users (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 ' '.
*    EPL_SWAP_VEHICLE - nvarchar(1), 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 field 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>


The updating of job-level information from server update messages will change to ensure that changes to the collection details of a job (i.e. the number of items/containers of products) will ''not'' automatically trigger an alerted to the driver that the jobs have changed - only a change to key Job-level fields will trigger this. This affects the processing of the following messages:
*    JOB_LOCK_RESPONSE
*    LOAD_RESPONSE
*    AUTO_UPDATE_RESPONSE
In order to achieve that, the PDA_JOB DAL object will be changed to ignore changed updates from container records (in function ProcessJobUpdate).


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


{{Note|Developer Notes:}}
* 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 check 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 List ===
On a full trip, the driver may have several normal deliveries to this depot as well as those that are being swapped with the other driver. In this case, these items will be seen as a separate job or job consolidation on the job list before the "swap van" jobs, and therefore will be completed separately. 

On a full trip, the driver may have several normal deliveries to this depot as well as those that are being swapped with the other driver. In this case, these items will be seen as a separate job or job consolidation on the job list before the "swap van" jobs, and therefore will be completed separately. In the same way, there could be several orders for collection from hospital services from this depot - these should be prompted for after the swapping of the van.

Currently, the job list ensures that deliveries are displayed before collections, and each job is displayed in the sequence received under that.

The Job List will be populated so that the jobs for delivery are ordered so that "swap van" delivery jobs for this location are displayed ''after'' normal delivery jobs, but before any collections at this location. Normal collections will be displayed ''after'' "swap van" collection jobs.


Additionally, these normal jobs and "swap van" jobs must not be consolidated together on the job list. They must also appear in the sequence as shown above.

{{Note}} C-TMS will have passed through a different Linked ID (EPL_LINKED_ID) for any jobs that are consolidated together, to ensure that they are not consolidated together.

For example, where a location contains the following:
* 1 job for delivery on its own to location 1
* 2 jobs consolidated together to location 1
* 2 jobs remain on the van to be swapped
* 2 jobs on a van to be swapped to
* 2 consolidated collections jobs from location 1
* 1 collection on its own from location 1

The Job List would display as follows:
* 1 job for delivery on its own to location 1
* 2 jobs consolidated together to location 1
* 2 jobs remain on the van to be swapped
* 2 jobs on a van to be swapped to
* 1 collection on its own from location 1
* 2 consolidated collections jobs from location 1


=== Job Details ===
When a job is selected from the Job List, the Job Details screen is displayed.

<gallery widths=260px heights=400px perrow=2>
File:FS_318084_Swap_Vehicle1.PNG|''Swap Vehicle showing on Job Details''
File:FS_318084_Swap_Vehicle2.PNG|''Swap Vehicle Dialogue''
</gallery><br /> 

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. This field and label will only be displayed if the EPL_TRAILER_ID field has data and this is different to the logged-on Vehicle ID, if the new Site flag "Trailer/Vehicle Combined" is enabled (EPL_TRAILER_VEHICLE_FLAG = "Y") . Otherwise this field and label will not be added to the screen.


When the driver presses the '''Start Job''' button, the screen will check whether 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 and is different to the logged-on vehicle ID, 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 (EPL_TRAILER_ID of EPOD_JOB), and the options are '''Back''' and '''Confirm'''. If the user clicks '''Back''' 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, if they are required.

{{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. Note that the vehicle will be marked on the internal database as having had vehicle checks completed on that vehicle by that driver. Therefore, if the driver backs out of the job and re-starts at any later time, vehicle checks will no longer be required.

If the "Trailer-Vehicle" configuration is as expected (EPL_TRAILER_VEHICLE of EPOD_SITE = "Y"), 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 (EPL_TRAILER_VEHICLE of EPOD_SITE = "N"), the Trailer ID should be left as is and the device should not prompt for anything - this may be expanded at a future time for Trailer Swap functionality.


{{Note}} The Trailer ID will be pre-set on all jobs received from C-TMS.


The process will recognise that the job is a Swap Vehicle job (through the new EPOD_JOB flag EPL_SWAP_VEHICLE = "Y"). In this case, the process will not call the Delivery or Collection process, but will instead simply complete the job.

The process will then action the job completion which, for the different job types, requires a different process (i.e. delivery to the swap location requires a signature, collection from it does not), all defined by the configuration against the job itself. In this case, the application will apply the logic of the Collection/Delivery process here (i.e. check the configuration and call the signature process appropriately). 


{{Note|Development Notes:}}
* The completion for the job will require the job to be set to completed status, and also for all containers and products on the job to be set to completed also, if they have not already been cancelled. A new method to the PDA_JOB DAL object may be the best way to approach this.
* This functionality affects all orders that are have the new EPOD_JOB flag EPL_SWAP_VEHICLE = "Y", regardless of whether they have a trailer ID preadvised against the job being processed.
* The decision regarding which Job Completion processes to instigate is through the existing nextJobEndTask function of the ColDel.js module. This will need to either be replicated in JobDetail.js or, better, extracted to an external function that can be maintained in one place and called on demand from both modules.


{{Note}} Cancellation of a Swap Vehicle delivery job will generate Return to Depot tasks for the orders not delivered. Cancellation of the Job Swap collection jobs will automatically cancel the deliveries associated to them. All of this functionality is generic and requires no changes.


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


<!-- MEDIA LANDSCAPE YES -->
= Appendix A: TEST PLAN  =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test the Swap Van functionality.
|MenuAccess=None
|Prerequisites=Data set up as per Data Setup section.
|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.
}} {{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Import/Export Tests
|Notes=This series of tests depends on developments completed under reference 317907/SCR01.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test adding a new vehicle through the webservices Import interface.
|Result=The new vehicle should be added. The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test editing a vehicle through the webservices Import interface. Change any of the following:
*    EPL_DESCRIPTION
*    EPL_VEHICLE_MILEAGE
|Result=The vehicle should be updated with the changed details. The Last Updated Date and Time should not be changed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test editing a vehicle through the webservices Import interface. Change any field but the ones in the last test.
|Result=The vehicle should be updated with the changed details. The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test deleting a vehicle through the webservices Import interface.
|Result=The vehicle should be marked as deleted (status = "X"). The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test adding a new user through the webservices Import interface.
|Result=The new user should be added. The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test editing a user through the webservices Import interface. Change any field.
|Result=The user should be updated with the changed details. The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Test deleting a user through the webservices Import interface.
|Result=The user should be marked as deleted (User Active = "X"). The Last Updated Date and Time should be now.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin Tests
|Notes=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter the Site Maintenance screen. Ensure the new field is present and can be set and maintained.
|Result=New checkbox field "Change Vehicle through Trailer" can be set, changed and saved:
The tabs are well organised, making good use of space.	 	 
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter the Vehicle Maintenance screen. Find all vehicles. Press '''Select''' against a vehicle and then '''Delete''' to delete the vehicle.
|Result=The vehicle should disappear from the table of vehicles.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the find button. Filter by Status.
|Result=An option of "Deleted" is available.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Filter by Deleted status
|Result=Only the previously deleted vehicle is shown on the table. The status is shown as "Deleted".
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit the vehicle 
|Result=The status should show as "Deleted". This should be an available option in the Status drop-down list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Delete''' button.
|Result=The record should be deleted. The Vehicle table should be redisplayed with no items in it.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''New''' button.
|Result=The pop-up screen should be shown. The Status drop-down list should not contain "Deleted".
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Add the vehicle back again and click '''Save'''
|Result=The vehicle should be added.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter the Users Maintenance screen. Find all users. Press '''Select''' against a user and then '''Delete''' to delete the user.
|Result=The user should disappear from the table of users.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the find button.
|Result=A Status drop-down list is available. Options of "Active", "Inactive" and "Deleted" are available.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Filter by "Deleted" status
|Result=Only the previously deleted user is shown on the table. The status is shown as "Deleted".
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit the user.
|Result=The status should show as "Deleted". This should be an available option in the Active drop-down list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Delete''' button.
|Result=The record should be deleted. The Users table should be redisplayed with no items in it.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''New''' button.
|Result=The pop-up screen should be shown. The Active drop-down list should not contain "Deleted".
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Add the user back again and click '''Save'''
|Result=The user should be added.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Login Tests
|Notes=Start from a clean installation of the device application.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set-up and log on to the device. Perform the initial grace log-on.
|Result=The LOGON_REQUEST message should not request changed data only. All data should be shown on the LOGON_RESPONSE message and downloaded onto the device.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Add a user and vehicle to the C-EPOD data (through Admin or WebServices). Log on as a valid user, vehicle and password.
|Result=The LOGON_REQUEST message should request changed data only. Only the added user and vehicle should be shown on the LOGON_RESPONSE message. All other data should be preserved.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Amend a vehicle (through Admin or WebServices), changing only the following fields:
*    EPL_DESCRIPTION
*    EPL_VEHICLE_MILEAGE
Log on as a valid user, vehicle and password.
|Result=The LOGON_REQUEST message should request changed data only. No vehicle data should be shown on the LOGON_RESPONSE message - all data should be preserved.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Amend a user and vehicle to the C-EPOD data (through Admin or WebServices). Log on as a valid user, vehicle and password.
|Result=The LOGON_REQUEST message should request changed data only. Only the changed user and vehicle should be shown on the LOGON_RESPONSE message. All other data should be preserved.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Delete a user and vehicle - setting the status to deleted - through Admin or WebServices. Log on as a valid user, vehicle and password.
|Result=The LOGON_REQUEST message should request changed data only. Only the deleted user and vehicle should be shown on the LOGON_RESPONSE message. These marked records should be deleted - all other data should be preserved.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Swap Vehicle Tests - Round Robin
|Notes=Create and plan 3 orders for delivery between 2 depots (order 1 from depot 1 to depot 2, and orders 2 and 3 from depot 2 to depot 1):
* Trip 1 for depot 1 should contain order 1. This should be cross-docked through depot 3.
* Trip 2 for depot 2 should contain orders 2 and 3. These should be cross-docked through 3.
* Trip 1 should then pick up the onward plan of orders 2 and 3 back to depot 1.
* Trip 2 should then pick up the onward plan of order 1 back to depot 2.
* Both trips should mark the collection/delivery at depot 3 as a vehicle swap.
* Both trips should be resourced (vehicle 1 and driver 1 to trip 1, vehicle 2 and driver 2 to trip 2).
Ensure that the new Site flag "Change Vehicle through Trailer" is enabled.

Ensure that driver 1 and 2 are operated on separate EPOD devices, as they will be operating concurrently.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set both trips to Accepted status in C-TMS.
|Result=Both loads and all jobs should be created in C-EPOD. The jobs at depot 3 should all be Swap Vehicle jobs, with instructions to swap with the appropriate driver/vehicle. All jobs on the trip up to but not including the collections at depot 3 should show a trailer ID set as the Vehicle ID assigned to the trip; all jobs from the collections at depot 3 forwards should show a trailer ID assigned, which should be the vehicle ID of the other trip.  Vehicle 2 on depot 1 and vehicle 1 on depot 2 should be Inactive.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Log on to C-EPOD as driver 1, vehicle 1 and load order 1 at depot 1. Ad Hoc Scan an item onto the job. Complete the job.
|Result=The job should be completed. C-TMS and C-EPOD should update all jobs for both trips for this order to show the additional item.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Select the delivery to depot 3 on the job list.
|Result=The Job Details screen should be displayed, showing the instructions to swap with driver 2 on vehicle 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Start Job'''.
|Result=The Delivery process should not be shown. The signature screen should be shown, requesting the customer signature.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Enter the driver 2 signature and name and confirm the job.
|Result=The delivery should be marked as complete, as well as all items on that delivery. The Job List should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Log on to C-EPOD as driver 2, vehicle 2 and load orders 2 and 3 at depot 21. As Hoc Scan an item. Complete the job.
|Result=The jobs should be completed. C-TMS and C-EPOD should update all jobs for both trips for these orders to show the additional item.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Select the consolidated delivery to depot 3 on the job list.
|Result=The Job Details screen should be displayed, showing the instructions for both jobs to swap with driver 2 on vehicle 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Start Job'''.
|Result=The Delivery process should not be shown. The signature screen should be shown, requesting the customer signature.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Enter the driver 1 signature and name and confirm the job.
|Result=The delivery jobs should be marked as complete, as well as all items on those deliveries. The Job List should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Select the consolidated Collection at depot 3 on the job list.
|Result=The Job Details screen should be displayed, showing the consolidated instructions to swap with driver 2 on vehicle 2 for orders 2 and 3. The Vehicle should be shown on the ''Address & Contact'' tab.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Start Job'''.
|Result=The application should prompt for confirmation of the vehicle through a pop-up.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Back'''
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Start Job'''. Click '''Confirm'''.
|Result=Vehicle Defect Checks should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Back out of the vehicle checks (if allowed)
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Start Job'''. Click '''Confirm'''. Complete vehicle checks.
|Result=The Collection process should not be shown. The signature screen should not be shown. The application should display the jobs as completed. The Job List should be displayed. The collections for order 2 and 3 should be marked as complete, as well as all items on those collections. Vehicle 1 on depot 1 should be marked as Inactive. Vehicle 2 on depot 1 should be Active.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Select the Collection at depot 3 on the job list.
|Result=The Job Details screen should be displayed, showing the instructions to swap with driver 2 on vehicle 2. The Vehicle should be shown on the ''Address & Contact'' tab.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Start Job'''.
|Result=The application should prompt for confirmation of the vehicle through a pop-up.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Back'''
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Start Job'''. Click '''Confirm'''.
|Result=Vehicle Defect Checks should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Back out of the vehicle checks (if allowed)
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Start Job'''. Click '''Confirm'''. Complete vehicle checks.
|Result=The Collection process should not be shown. The signature screen should not be shown. The application should display the job as completed. The Job List should be displayed. The collection for order 1 should be marked as complete, as well as all items on that collection. Vehicle 2 on depot 2 should be marked as Inactive. Vehicle 1 on depot 2 should be Active.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Select the final consolidated unloading jobs at depot 1 on the job list.
|Result=The job details screen should display, showing the details of orders 2 and 3.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Click '''Start Jobs'''.
|Result=The Delivery process should start, showing all the items to be unloaded from this vehicle at depot 1 for orders 2 and 3, including the Ad Hoc items loaded at depot 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Scan to unload all items.
|Result=A signature should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 1:''' Complete the signature.
|Result=The 2 jobs are completed in depot 1. The Job List is displayed, and the device checks for any more work for driver 1 using vehicle 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Select the final unloading job at depot 1 on the job list.
|Result=The job details screen should display, showing the details of order 1.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Click '''Start Jobs'''.
|Result=The Delivery process should start, showing all the items to be unloaded from this vehicle at depot 2 for order 1, including the Ad Hoc item loaded at depot 1.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Scan to unload all items.
|Result=A signature should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action='''DRIVER 2:''' Complete the signature.
|Result=The job is completed in depot 2. The Job List is displayed, and the device checks for any more work for driver 2 using vehicle 1.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Swap Vehicle Tests - BMV
|Notes=Create and plan 2 BMV orders for delivery between 2 depots (order 1 from depot 1 to depot 2, and order 2 from depot 2 to depot 1). Mark the collection at depot 2 as changing to a new vehicle.
Ensure that the new Site flag "Change Vehicle through Trailer" is enabled.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Set the trip to Accepted status in C-TMS.
|Result=Both loads and all jobs should be created in C-EPOD. All jobs on the trip up to but not including the collection at depot 2 should show a trailer ID set as the Vehicle ID assigned to the trip; all jobs from the collection at depot 2 forwards should show a trailer ID assigned, which should be the select vehicle ID. Vehicle 2 on depot 1 and vehicle 1 on depot 2 should be Inactive.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Log on to C-EPOD as driver 1, vehicle 1 and load order 1 at depot 1. Ad Hoc Scan an item onto the job. Complete the job.
|Result=The job should be completed. C-TMS and C-EPOD should update all jobs for both trips for this order to show the additional item.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the delivery to depot 2 on the job list.
|Result=The Job Details screen should be displayed; It should not show instructions to swap with another driver.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''.
|Result=The Delivery process should be shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete entry of all items.
|Result=The signature screen should be shown, requesting the customer signature.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter the depot signature and name and confirm the job.
|Result=The delivery should be marked as complete, as well as all items on that delivery. The collection at depot 2 should be immediately shown. The Job Details screen should be displayed. No instructions to swap should be displayed. The Vehicle to be swapped to should be shown on the ''Address & Contact'' tab.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''.
|Result=The application should prompt for confirmation of the vehicle through a pop-up.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Back'''
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''. Click '''Confirm'''.
|Result=Vehicle Defect Checks should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Back out of the vehicle checks (if allowed)
|Result=The Job Details screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''. Click '''Confirm'''. Complete vehicle checks.
|Result=The Collection process should be shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete entry of all items. Ad Hoc Scan an item onto the job. Complete the job.
|Result=The signature screen should not be shown. The application should display the jobs as completed. The Job List should be displayed. The collections for order 2 and 3 should be marked as complete, as well as all items on those collections. Vehicle 1 on depot 1 should be marked as Inactive. Vehicle 2 on depot 1 should be Active.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the final unloading jobs at depot 1 on the job list.
|Result=The job details screen should display, showing the details of order 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Jobs'''.
|Result=The Delivery process should start, showing all the items to be unloaded from this vehicle at depot 1 for order 2, including the Ad Hoc items loaded at depot 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan to unload all items.
|Result=A signature should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the signature.
|Result=The 2 jobs are completed in depot 1. The Job List is displayed, and the device checks for any more work for driver 1 using vehicle 2.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Job List Tests
|Notes=Ensure that there is a Round-Robin style order, as follows:
*    Create and plan 3 orders for delivery between 2 depots (order 1 from depot 1 to depot 2, and orders 2 and 3 from depot 2 to depot 1).
*    Create 2 more orders 4, and 5, for direct delivery from depot 1 to depot 3.
*    Create 1 more orders 6, for direct delivery from depot 3 to depot 1.
*    Trip 1 for depot 1 should contain order 1. This should be cross-docked through depot 3.
*    Trip 1 for depot 1 should include orders 4 and 5 direct to depot 3.
*    Trip 2 for depot 2 should contain orders 2 and 3. These should be cross-docked through 3. 
*    Trip 1 should then pick up the onward plan of orders 2 and 3 back to depot 1.
*    Trip 1 should then pick up order 6 back from depot 3 to depot 1.
*    Trip 2 should then pick up the onward plan of order 1 back to depot 2.
*    Both trips should mark the collection/delivery at depot 3 as a vehicle swap.
*    Both trips should be resourced (vehicle 1 and driver 1 to trip 1, vehicle 2 and driver 2 to trip 2). 
{{Note}} In this test, only driver 1 for trip 1 will be considered, as this shows the functionality we wish to test.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start trip 1 with driver 1.
|Result=The Job List should show all jobs in the sequence as follows:
* Consolidated Loading of 3 consignments at depot 1 (orders 1, 4 and 5).
* Consolidated delivery of 2 consignments (orders 4 and 5) to depot 3.
* Delivery of job 1 (swap van) to depot 3.
* Consolidated collection of 2 consignments (orders 2 and 3) from depot 3.
* Collection of order 6 from depot 3.
* Consolidated Unloading of 3 consignments (orders 2, 3 and 6) at depot 1.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Regression Tests
|Notes=Ensure that the new Site flag "Change Vehicle through Trailer" is disabled.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Send through the jobs as the previous tests. Complete jobs through to seeing the details of the job at the collection at depot 3 by driver 1. Click '''Start Job'''.
|Result=No pop-up confirmation of vehicle should be shown. The Collection process should start, showing all items to be collected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Send through a normal collection and delivery job (not at the user's depot). Select the Delivery job and click '''Start Job''' on the Job Details screen.
|Result=No pop-up confirmation of vehicle should be shown. The Delivery process should start, showing all items to be delivered.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the Collection job and click '''Start Job''' on the Job Details screen.
|Result=No swap vehicle should be shown on the Job Details. No pop-up confirmation of vehicle should be shown. The Collection process should start, showing all items to be collected.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=NHSBT High Level Solution Design v2.0.doc
|RefV1=2.0
|RefDate1=21/05/2014
|Ref2=FS 317907 SCR01 EPOD-TMS Interface 
|RefV2=&nbsp;
|RefDate2=&nbsp;
|Ref3=FS 317761 SCR15 NHSBT C-EPOD Collection Changes 
|RefV3=0.4
|RefDate3=04/06/2014
|Ref4=FS 317771 SCR17 NHSBT C-TMS Swap Van 
|RefV4=&nbsp;
|RefDate4=&nbsp;
|Ref5=FS 316291 SCR02 NHSBT TomTom Interface 
|RefV5=&nbsp;
|RefDate5=&nbsp;
|REQ=0
|EST=0
|FS=2.25
|TS=0
|DEV=8.25
|ST=2.25
|IMP=0
|EREQ=0
|EEST=0
|EFS=1.25
|ETS=0
|EDEV=6
|ESTT=1.25
|EIMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=Y
|Rev1=Julie Scott
|Rev1Title=Project Manager
|Rev2=Ed Bond
|Rev2Title=Client Representative
}}</div> 
[[Category:{{#var:Client}} FS]]