NHSBT

C-EPOD Collection Changes

CALIDUS ePOD

22nd May 2014 - 0.1
Reference: FS 317761 SCR15

Functional Overview

Client Requirement

The following changes from the Solution Design document are included in this specification:

SCR-316403-68 - Round Robin/BMV

Ad Hoc Collection: The EPOD device will need to recognise that this is a consolidated collection at a depot with multiple destinations, and prompt the user to enter the destination location (selected from a drop-down list).

SCR-316403-69 - Single Trip Asset:

Prompt for Asset Type; Store DU on database

SCR-316403-74 - Ad Hoc Collection:

Ad Hoc Collection tab on Collection jobs; configuration (by Container or Stock); Ad Hoc Collection Process

SCR-316403-77 - Collection / Delivery:

Completion of a job for a location should move on to the next job at that location immediately.

SCR-316403-86 - Return Cancels to Depot:

Any cancelled items or entire cancelled deliveries must be returned to the depot and scanned off the vehicle.

Ad Hoc Collections of items should be added to scanned items to be returned

SCR-316403-88 - Scanning:

EPOD scanning of preadvised items will be seamless (stay in scanning)

SCR-316403-79 - Unloading:

EPOD will generate the items to be unloaded back at the depot on the device. This will include cancelled items and ad hoc collected items

SCR-316403-80 - Validation Rules:

The EPOD handheld device application will be modified to provide validation whether the wrong box has been used/where issue life is exceeded.

SCR-316403-83 - Scanning:

EPOD Application will be changed to recognise the different potential scan-able items, to distinguish between Permanent and Single Trip Asset tags, and to disregard any other barcodes scanned as invalid.

SCR-316403-84 - Auto-Login:

Disable Auto-Login

SCR-316403-95 - Ad Hoc Collection:

Ad Hoc Collection prompted for through Job Detail (automatically when other jobs at that location completed) or Job list (through menu)

SCR-316403-96 - Consolidation:

Use same location consolidation and possibly linked locations, EPOD config, signature controls, carrier controls

SCR-316403-98 - Resource Availability:

EPOD - store Logon/off message

SCR-316403-30 - Asset Tracking:

Single Trip Assets are not currently part of the Asset Management within EPOD. This will require a change to allow temporary asset tags to be scanned.

Additionally, this change will encompass ensuring that the terms used in the application are appropriate, for example (but not limited to):

Use the word "Item" rather than "Container" when collecting and delivering.
Lay out the Job List and Container rows as required for the operation.

Solution Overview

Scanning

The processes being used by the operation will extensively use scanning to validate the items and to help track assets throughout the network. To aid in this, the application allows scanning, both through a 'keyboard wedge' (where an external hardware device may be connected to the mobile device, typically through Bluetooth local wireless connectivity) or through an integrated scanning module (utilising the inbuilt camera on the mobile device).

The C-EPOD application will be modified for the scanning of items as follows:

Continuous scanning will be implemented within the C-EPOD application, to ensure that scanning speed is kept at a maximum.
The overlay/scanning window size should be maximised for the device, to ensure that larger barcodes may be scanned more easily.
Items scanned successfully should be immediately marked as delivered (no pop-up dialogue).
Unknown items will be identified with a message, but scanning will be allowed to continue without interruption.

(SCR-316403-88)

This applies when scanning preadvised items for collection and delivery, but not for Ad Hoc Collection.

The project team also allows the possibility of using external scanning modules connected via Bluetooth to help speed up this process, if it proves to be too slow to be practical.

The different barcodes used by the operation are expected to be as follows:

Permanent Asset Tag Format:

8004: 4-digit AI
00000000: 8-digit company prefix
XXX00000: 8-AN Asset ID.
GS1-standard (EAN-128)

Single Trip Asset Tag Format:

00: 2-digit AI (SSCC-ID)
00000000: 8-digit company prefix
0000000000: 10-digit Asset ID.
GS1-standard (EAN-128)

The C-EPOD Application will be changed to recognise the different potential items' barcode formats, for validation and data extraction purposes. The purpose of this is to distinguish between Permanent and Single Trip Asset tags, and to disregard any other barcodes scanned as invalid. (SCR-316403-83)

Note: The systems already support barcode scanning, and Asset registers. However, the specific mix of externally generated asset labels, as well as a concept of single-trip assets, results in changes being required both within C-TMS and C-EPOD, to handle that mix. (SCR-316403-30 and SCR-316403-75)

Login

The application will be pre-installed on the units, but can also be downloaded from stores or manually installed.

Once the application has been installed, it will be present on the application list of your device. Once clicked, the application will load.

Application Start Screen

On starting the application, the driver will be requested to Log In.

The device requests entry of the User ID, Vehicle and Password that the driver has been provided with. If there is any error regarding the values entered, the application will inform them of the error. A pop-up keyboard will be displayed for entry of the details. The device will be pre-configured with the site (depot) from which they are being allocated work.

Login Screen

If the device has not been configured for first use, the device will prompt the driver upon initial log on. This can be easily configured through the scan of a single barcode, which can be provided to the drivers, if this is required.

When successfully logged in and with a data connection, the application will download all of the latest configuration data from the server, and a load to be completed.

If the vehicle checks have not been completed recently, the application will direct the driver to complete the Vehicle Checks.

Vehicle Checks should be configured so that they are prompted for whenever a driver first uses a vehicle that day.

If no load has been assigned to that driver, the unit will display a message and ask if them to recheck.

If a Load has been assigned to the driver, they will be directed to the Job List screen to action it.

Note: Functionality exists within C-EPOD to automatically log a driver back in to the point where they left the application, after an unplanned closure of the application. It was noted that the NHSBT team do not want this functionality and that it should be capable of being disabled. This will require a modification to the standard functionality of the application. (SCR-316403-84)

The device and the Admin system will be modified to capture the login time from the user, so that it may be enquired on in the Admin system (SCR-316403-98).

Job List

This screen shows all the jobs on the Load (work-list) that has been assigned to the driver.

Job List Screen

The screen displays a grid containing:

Job Status through background or border colour
Job ID or Code
Job Type, one of:
- S - Service
- C - Collection
- D - Delivery
Planned Date/Time
Customer Name
Postcode
Job SO Number
Customer Reference Number
Container and Product Counts (for Collections/Deliveries)
Priority

The layout of this grid can be controlled through the style chosen in the PDA client configuration screen - this is expected to be configured for NHSBT requirements, within the existing capabilities of the system.

Where there are multiple jobs being actioned at the same location or depot (for example, loading or unloading at a depot, or delivering or collecting from the same hospital), the job list will show a single consolidated entry against the location, showing the number of consignments planned. If there are deliveries and collections to/from the same point, the Job List will show one consolidated entry for the deliveries, and one for the collections. It was noted that consolidated collections may have an exception where certain items are picked up and loaded from a different area. It was noted that these should be defined as coming from a different location, although this must be confirmed by the NHSBT team.

Depending on the application style chosen, the screen may display the status of the jobs on the load through a coloured outline, as follows:

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

This status is also displayed prominently in the Job Details screen.

The identifying field for the job (Job ID, Code or many other references) can be selected through configuration in Admin against the Site.

The jobs are displayed in the sequence in which they should be completed, with the first job selected. The device will be configured to require that the top-most job is completed first. However, the jobs can be viewed in any sequence by clicking the line of the job the driver wants to see - they will then be taken to the Job Details page.

The driver can also long-press against the line for some options from a pop-up menu:

Details - show the Job Details screen.
Cancel - Cancel the job - this job will be cancelled. The unit will take to the driver to an Exception screen and prompt to enter a reason code explaining why this job was cancelled. This may be used to report Accidents, when the job has been affected to the degree that it can no longer be delivered.

Clicking the Back button here will confirm whether the driver wants to log off from the CALIDUS ePOD application.

The device and the Admin system will be modified to capture the logout time from the user, so that it may be enquired on in the Admin system. (SCR-316403-98) The Menu button can be used here to allow the following options:

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

There are also some bug-reporting options available on this pop-up menu.

This menu will be added to allow a user to elect to do an ad hoc collection for the last completed delivery point, to pick up any samples or returned assets for that location. (SCR-316403-95). This menu will also be modified to add Change Vehicle and Relogon options – some slight restructuring of the menu will be required.

Should the trip that is allocated to this user be modified by C-TMS or DPS, in response to planning and order demand, the C-EPOD device will indicate this to the driver, by way of a pop-up dialogue and audible alert.

Job Details

This screen displays full details of the job being undertaken.

This screen will be displayed regardless of job type. The translated job type will be displayed on the top of the screen (i.e. COLLECTION, DELIVERY), along with the Job ID (or other descriptive text, as configured for the system). The status of the job will also be displayed.

Job Details
Job Instructions

The screen has several Tabs, each showing:

The Job Type (Collection, Delivery, Service)
The customer details (Customer Code, Name, Address and Postcode)
The contact information (Contact name and number)
The Instructions for the job (The driver will be forced to view any C-TMS-provided order instructions before starting the Job.)

Where there are multiple jobs being actioned at the same location or depot, this screen will allow you to move between the information of each job.

From these tabs, the driver can:

Call the customer by clicking on the Call button, if a phone number has been provided. The device will display the dialler with the Phone number already entered.
Navigate to the customer's address by clicking on the Navigate button. The device will use whatever navigation software is installed on the device, or route through a browser search.
SMS message the customer. The device will display the SMS message, with the phone number and job details already entered.

The driver can start the job using the Start Job button.

Note: The requirement for Location Check Digit has been superseded by a GPS Location Point that should be stamped against pressing this button here, which will be audited in the C-EPOD Admin system. This may be enquired upon using the C-EPOD Admin system (see the Admin section for details of how this can be seen). This will not be passed back to C-TMS to be viewed there.

The user will then be taken to the following process, based on job type:

Collection
Delivery

There are many acknowledged reasons for a delivery to be cancelled during execution:

Misdirected
Cancelled after starting
Patient no longer requires product

If the driver presses Cancel Job, this job will be cancelled. The unit will take them to an Exception screen and prompt to enter a reason code explaining why this job was cancelled. This may be used to report Accidents, when the job has been affected to the degree that it can no longer be delivered.

Note: In the instance that a driver is early, this is not a reason for cancellation of the order - the driver has instructions to wait until someone is available to accept the product, and will call hospital services or staff to facilitate that.

Note: Cancelled items or entire cancelled deliveries must be returned to the depot and scanned off the vehicle. (SCR-316403-79 and SCR-316403-86)

Collection

This process will be followed for any collection of any type at any location.

Collection jobs from a hospital may be planned or unplanned. Planned collections can be preadvised with items (i.e. the specific assets to be collected) or Ad Hoc (a number of items are to be collected, without knowing the specific IDs). Planned Ad Hoc collections will typically be collections of a number of specific samples. Unplanned collections are intended to allow the driver to pick up any items (i.e. assets, pick up samples, post, etc.) - these will be generated by the driver, when requested by the device, after all planned jobs at this location have been completed. The following process covers all aspects of collection.

If the job is a Collection, the driver will be shown this screen. They will be initially presented with a summary screen.

Job Details Tab
Containers Tab

There are multiple possible tabs on this screen:

Job Details - address and instructions (where any have been provided by C-TMS against the order)
Items (Containers) - where assets are marked as collected/loaded.

Where there are multiple collection jobs being actioned at the same location or depot, this screen will allow the user to move between the information of each job. All of the items to be collected will be consolidated together, however.

If any items have been preadvised to be collected specifically (as when loading at the depot, for example), these will be shown on the Item (Container) list, for collection.

The system will be configured to not allow the user the option to deliver/collect an item directly from the grid row itself. This will force scanning of asset barcodes.

From the Containers tab, the driver can enter the Container in the text box and click the Collected button, which will mark the item as collected. The process also supports scanning of the barcode of the items preadvised to be collected, either through an attached external barcode scanner (through additional software and hardware purchases) or an internal laser scanner – entered through the Enter Container text box provided, or using the device's camera to scan within the application, using the Scan button provided.

Warning:

What should we do here? Allow this to happen and simply add to the ad hoc containers list?

If a container is scanned that is not expected, the device will display a temporary error on the screen, to inform the driver that the item is not expected.

Note: Incorrect scans are not audited within C-EPOD or C-TMS.

As each item is successfully scanned (or otherwise confirmed as collected), it will be removed from the list.

When collecting Assets at the centre, if the driver finds that any items are missing, the driver should alert this immediately to Hospital Services. The driver will wait until the issue is resolved, rather than cancelling the pickup of the specific missing item.

In the case where these exceptions cannot be resolved, the driver will have the facility to remove certain items from the job. This will be through the Container Cancellation feature on the C-EPOD application (from long-pressing against the missing item in the list and choosing Cancel from the pop-up menu).

The driver is able to long-press any container in the grid. This will provide a pop-up menu, allowing visibility of details of the selected container, showing:

ID (note that this may not be removed or hidden at this time, nor may the option to show this screen be configured to be hidden).
Package Code and Description
Weight
Code 1/2/3 (Multi-use fields)

The pop-up menu also allows cancellation or collection, as above.

Pop-up Menu

The Collection process can also be configured with an Ad Hoc Collection facility. (SCR-316403-74)

The Ad Hoc Collection process allows the driver to specify the items collected, at the point of collection, without the specific items for those collections being planned in advance. This appears as a separate tab on the PDA within the Collections process, labelled as "Ad Hoc".

When this feature is enabled, the user is able to scan the preadvised items for collection on the "Containers" tab, as well as any additional ones on this new tab. The application will not automatically complete a job when all preadvised items have been scanned - the driver will always have an opportunity to enter more and then complete the job manually.

The tab will allow the user to scan or enter Asset IDs - this works similarly as to the standard Container scanning, but will only allow scanning one item at a time.

Warning:

Should we have this checking the list of preadvised containers (if exists) and not adding if they have already been scanned here? Should we just remove it from the list if it was preadvised and not yet scanned? Ignore if on there and already scanned?

The application will only allow asset formats to be scanned in the formats detailed in the Scanning section. The different types of Asset will be dealt with separately:

Fixed (Permanent) Assets IDs will always be associated with a particular Asset Type in C-TMS, so the application will not require the driver to confirm the Asset Type for a Fixed Asset.
Temporary Assets must have an asset type entered. (SCR-316403-69).

Additionally, the application will check to see if this collection is part of a consolidation (multiple collection jobs) with multiple destinations, which can happen in the following instances:

For processed blood deliveries from a manufacturing centre to SHU, the cages could be being delivered to different destinations, for example one cage on one order to the first SHU, with the other 2 cages to go to a second SHU on a different order. The cages will be labelled with their destination.
For Round Robin movements, 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 application will deal with these requirements by recognising this and popping up a dialogue box when scanning, if required. It will request the user to select the Asset Type and/or destination for the scanned Asset. (SCR-316403-68 and SCR-316403-69)

Note that this process applies only for unplanned collections of assets scanned in this tab.

The Asset Type will be selected through the use of a drop-down list (DDL). The types (amongst many) are:

"Sample", "Post", "Waste", "Other", "Cage", "BAM", "Clinomed", "Va-Q-Tec", "Blue".

The list of Asset Types will be maintained as standing data within C-TMS and used within C-EPOD, to allow the asset types used by the drivers to be maintained centrally by the operation. (SCR-316403-69)

The Asset Types prompted for will be all available Asset Types within the system, as a single trip asset ID may be used when an Asset loses its label, as well as identifying real single trip items.

It was noted that the status of permanent Assets need not be checked when scanning assets in C-EPOD - this should already have been checked in the Tag to Asset Scanning process.

When entered, the Asset will be added to a scrolling list on this tab - each item scanned this way will be added to this list.

Any items collected in this manner must be added to the items to be unloaded back in the depot. The application will be modified to add these to the unloading jobs back at the depot. This also applies to any items that were cancelled for delivery (SCR-316403-79 and SCR-316403-86)

Once all containers have been collected you are required to click the Complete button. During collections of any type, the driver will not be required to capture a signature from the person handing them the items, the driver is accepting them - the physical scan of the items is enough to confirm that they are now in the driver's possession. The system will be configured to immediately complete the job. Therefore, once completed, the driver will be returned to the Job Menu to pick up the next task or Load/Work-list. The completed job will be transferred back to the main system with all the details, signatures and photos.

Delivery

This process will be followed for any delivery of any type at any location.

If the job is a Delivery, the driver will be shown this screen. They will be initially presented with a summary screen.

Note that the general layout of these screens is almost identical to the collection screens, albeit using the word 'Deliver' rather than 'Collect'. There is no Ad Hoc tab, however.

There are multiple possible tabs on this screen:

Job Details - address and instructions (where any have been provided by C-TMS against the order)
Items (Containers) - where assets are marked as delivered/unloaded.

Where there are multiple delivery jobs being actioned at the same location or depot, this screen will allow the user to move between the information of each job. All of the items to be delivered will be consolidated together, however.

If any items have been advised to be collected specifically (as when loading at the depot, for example), these will be shown on the Container list, for collection.

As with collections, the project team requested the ability to display only a small part of the Item ID on the device. (SCR-316403-85) The options available are covered in that process. From here the driver can scan or enter the Container in the text box and clicking Delivered, which will mark the item as delivered. Options regarding quick entry through clicking on the item in the list will be disabled in this configuration, to force scanning of Asset barcodes. The driver is able to long-press any container in the grid. This will provide a pop-up menu, displaying the details of the selected container, showing the same details as in the Collection screens.

As each item is scanned (or otherwise confirmed as delivered), it will be removed from the outstanding list. When delivering items at a Hospital these items may be refused (or be incapable of being delivered). In this case, these items will be cancelled through the Container Cancellation feature on the C-EPOD application (from long-pressing against the missing item in the list and choosing Cancel from the pop-up menu) and be managed by C-EPOD and C-TMS back into the centre. (SCR-316403-79 and SCR-316403-86)

Once all containers have been delivered, the driver is required to click the Complete button. During deliveries of any type, the driver will always be required to capture a signature from the person they are handing the items to, to confirm that they are now in their possession. This button press will take the driver to the Job Confirmation screen.

Job Confirmation

This screen controls the confirmation that the job has been completed satisfactorily. The process can be configured for:

Customer Signature
Driver or Engineer Signature
Job Photo Capture (also referred to as Document Photo Capture).

For Collections, nothing will be prompted. For Deliveries, a customer signature will be required.

Signature

The Signatory box defaults to the customer contact name (if present on the job) and also allows free text entry, which will be sent back to the main system if the customer contact is not the person planned for the job. To clear the signature, the driver may click Clear.

Depending on Job Type and the data, several other tabs may appear in this section:

T&Cs - Terms and Conditions, along with up to 3 optional check boxes for entry. This is configurable within the Admin system.
Items (Containers) - All containers delivered or collected.

The Containers tab can also be used by the person signing for the goods to comment against delivery jobs (accept the delivery with a clause).

If containers are accepted but the customer wishes to note that the delivery may be queried later, they can enter clause text against specific containers.
Click the container in the grid, and a pop-up will be displayed, allowing the user to enter clause information.
When saved, the Container tab will be redisplayed, showing in the status that the container is claused.

The C-EPOD device application will be modified here to provide validation as to whether the product in the box is still valid (i.e. it has been out of cold storage for longer than it is validated to be). (SCR-316403-80) This will be based on an issue life passed to the C-EPOD application per item, based on the pack time, the product and the box type. The device will display a pop-up warning to the user when the signature screen is displayed, expected to be "Issue life exceeded on some items. Please see the detail of the items affected below".

Additionally, the screen will be modified to pre-identify items that are out of issue life as status "Claused" on the Containers tab here. Clicking on a claused item will display the reason, expected to be "Issue life exceeded - product must be checked".

Signature entry (and therefore job completion) is confirmed by clicking Done. The driver will be prompted for a final confirmation before continuing. Once completed, they will be returned to the Job List to pick up the next task or Load/Work-list. The completed job will be transferred back to the main system with all the details, signatures and photos.

Deliveries to a hospital (i.e. not unloading tasks at a depot) will always be followed by a collection, planned or unplanned:

If the Hospital staff have arranged a planned collection of specific items (such as Assets or Samples) at the same time as the delivery, the application will immediately start the collection job for the user. In this case, the user will not be prompted if they want to do an ad-hoc collection, as this can be done with the standard collection (SCR-316403-77).
If there is no planned collection, in order to allow the driver to pick up any returned assets or samples, the driver will be prompted as to whether they wish to do an ad hoc collection at this stage (SCR-316403-95). If so, the device will create a job for this location and prompt the user as per any normal collection process.

Scope

Note: This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.

Note: CALIDUS TMS functionality is mentioned only by reference in this solution - see elsewhere for specification of the changes to that system.

Note: When entering barcodes using a wedge or integrated scanner, rather than the application scanner, the application has no direct control over the wedge scanner, so it is not possible to limit the wedge scanner in terms of which barcodes it is allowed to scan. If this is required, it requires device-specific configuration of the scanner and further bespoke code written within the application. As wedge scanners have not at this time been confirmed, this is not part of the scope of this change. If this is required after confirmation of this development, this will accrue additional cost.

Set-up

Pre-requisites

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

CALIDUS TMS Interface Changes

Warning:

Not finished yet

EPL_UDF_JOBDETS to be populated with PACKAGING, GEL and DRY ICE counts, in UDF format, on collections. Format example:

<FORM NAME="Job Details" REQUIRED="Y">
  <FIELD ID="DU1_COUNT">
     <TEXT>No. of DU1: X</TEXT>
     <FORMAT>L</FORMAT>
  </FIELD>
  <FIELD ID="DU2_COUNT">
     <TEXT>No. of DU2: X</TEXT>
     <FORMAT>L</FORMAT>
  </FIELD>
</FORM>

New fields EPL_VALID_DATE and EPL_VALID_TIME will be passed through for box-level validation, against each EPOD_CONTAINER record.
EPL_LINKED_ID will be passed through against each EPOD_JOB record to identify consolidated collections and deliveries
New field EPL_LOADING_TYPE will be passed through against each EPOD_JOB record to indicate whether this is the loading or unloading job.
Warning: What will CODE 1 be mapped to, if anything? Is it required?
Warning: New Asset Type information will be passed though on the EPOD_REASON_CODES stream, with EPL_REASON_TYPE = "DU".

Warning:

Removing contact number from the hospitals?

Are we removing this?
Are we sending through the same number (i.e. the depot's Hospital Services number instead, or just leaving this programmed into the phone as a contact?

Warning:

EPOD-CTMS Inbound Interface changes

Additional Ad Hoc Collections
Additional containers
Reference the EPOD Interface change for the details of these changes.

Menu Structure

None

Data

Warning:

Not finished yet

Device configured to NHSBT style
Asset Types configured within C-TMS and C-EPOD.
Job Groups set up with the following PDA options:
- Ad Hoc Collection enabled
- Job Consolidation enabled
- Driver Sign Delivery enabled
- Note: All other options are expected to be disabled.
Sites set up for each depot (carrier), with the following PDA options:
- "Seamless Scanning" enabled
- "Driver Sign Delivery" enabled
- "Next Job Automatic" enabled
- "Prompt for Ad Hoc Collection" enabled
- "Ad Hoc Collection" enabled
- Configured for generation of return items to depot
- "Auto-Login" disabled
- "Job Consolidation" enabled
- "Forced Container and Product Entry" enabled
- "Capture Arrival Times" disabled
- "Link C & D on Job Code" enabled
- "Display Job Code on PDA" enabled ( Note: Depending on other changes, this flag may now be a drop-down list labelled as "Display Job As" - if so, select value "Job Code/Order No", or any required value other than "Job ID").
- "Scan Errors Intrusive" disabled
- "Clause Delivery" enabled ( Note: Depending on other changes, this flag may now be a drop-down list, allowing the choice of functionality - if so, this should be set to any option that requires "Claused Delivery Description", preferably option "1").
- "Resequencing Options" disabled.
- Note: All other options are expected to be disabled, but may be set as desired.

Functional Description

Database/DAL

Table EPOD_SITE requires the following modifications:

EPL_NEXT_JOB_FLAG - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.
EPL_RETURNS_DEPOT_FLAG - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.
EPL_SCANNING_FLAG - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.
EPL_AUTOLOGIN_FLAG - nvarchar(1), NOT NULL DEFAULT 'Y', values 'Y' or 'N'.
EPL_ADHOC_ANYTIME_FLAG - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.
EPL_AUDIT_LOGIN_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_FLAG></EPL_ADHOC_ANYTIME_FLAG>
   <EPL_AUDIT_LOGIN_FLAG></EPL_AUDIT_LOGIN_FLAG>
 </EPOD_SITE>

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

Table EPOD_JOB requires the following modification:

EPL_LOADING_TYPE - nvarchar(2), NOT NULL DEFAULT ' ', 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_LOADING_TYPE></EPL_LOADING_TYPE>
     <EPOD_CONTAINERS></EPOD_CONTAINERS>
     <EPOD_SERVICES></EPOD_SERVICES>
   </EPOD_JOB>

Table EPOD_CONTAINER requires the following modification:

EPL_VALID_DATE - integer(8), NOT NULL DEFAULT 0.
EPL_VALID_TIME - integer(8), NOT NULL DEFAULT 0.

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

EPOD_CONTAINER_INSERT
EPOD_CONTAINER_SELECT
EPOD_CONTAINER_UPDATE

The existing EPOD_CONTAINER DAL object will be changed to:

Export the new fields in XML requests
Read the new fields

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_CONTAINER records will now look as follows:

   <EPOD_CONTAINER>
     <EPL_SITE_ID></EPL_SITE_ID>
     <EPL_JOB_ID></EPL_JOB_ID>
     <EPL_CONTAINER_ID></EPL_CONTAINER_ID>
     <EPL_SEQUENCE></EPL_SEQUENCE>
     <EPL_CONTAINER_PACKAGE_CODE></EPL_CONTAINER_PACKAGE_CODE>
     <EPL_CONTAINER_PACKAGE_DESC></EPL_CONTAINER_PACKAGE_DESC>
     <EPL_REASON_CODE></EPL_REASON_CODE>
     <EPL_LINKED_REASON></EPL_LINKED_REASON>
     <EPL_STATUS></EPL_STATUS>
     <EPL_PHOTO_ID></EPL_PHOTO_ID>
     <EPL_GROSS_WEIGHT></EPL_GROSS_WEIGHT>
     <EPL_DESCRIPTION_LONG></EPL_DESCRIPTION_LONG>
     <EPL_CODE_1></EPL_CODE_1>
     <EPL_CODE_2></EPL_CODE_2>
     <EPL_CODE_3></EPL_CODE_3>
     <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
     <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
     <EPL_CUST_COMMENTS></EPL_CUST_COMMENTS>
     <EPL_VALID_DATE></EPL_VALID_DATE>
     <EPL_VALID_TIME></EPL_VALID_TIME>
     <EPOD_PRODUCTS></EPOD_PRODUCTS>
   </EPOD_CONTAINER>

Import/Export Messages

Warning:

Not finished yet

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 and EPOD_CONTAINER fields. 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
Calidus_ePOD (predominantly handled by the DAL changes above):
- JOB_LOCK_RESPONSE
- LOAD_RESPONSE
- AUTO_UPDATE_RESPONSE

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

EPOD_EXPORT_LOAD_RESPONSE.xsd
XMLUpload.xsd
EPOD_EXPORT_JOB.xsd
EPOD_EXPORT_JOB_RESPONSE.xsd
ePOD_ImportResponce.xsd

The field definitions should be added to the XSDs in the appropriate position as follows:

   <xsd:element name="EPL_LOADING_FLAG" nillable="true" minOccurs="0" maxOccurs="1">
     <xsd:annotation>
       <xsd:documentation>
         Controls whether this job is seen to be a Loading task at a depot (Job Type = "C") 
         or unloading at a depot (Job Type = "D"). Values can be "Y" or "N" or "" - 
         only "Y" indicates whether the job is a loading/unloading task.
       </xsd:documentation>
     </xsd:annotation>
     <xsd:simpleType>
       <xsd:restriction base="xsd:string">
         <xsd:maxLength value="1" />
       </xsd:restriction>
     </xsd:simpleType>
   </xsd:element>
   <xsd:element name="EPL_VALID_DATE" type="xsd:int" nillable="false" minOccurs="0" maxOccurs="1">
     <xsd:annotation>
       <xsd:documentation>
         The date up until the contents of the package are valid - controls warnings at delivery.
       </xsd:documentation>
     </xsd:annotation>
   </xsd:element>
   <xsd:element name="EPL_VALID_TIME" type="xsd:int" nillable="false" minOccurs="0" maxOccurs="1">
     <xsd:annotation>
       <xsd:documentation>
         The time up until the contents of the package are valid - controls warnings at delivery.
       </xsd:documentation>
     </xsd:annotation>
   </xsd:element>

The elements will be added at the following positions:

In EPOD_JOB as the last element before EPOD_CONTAINERS.
In EPOD_CONTAINER as the last elements before EPOD_PRODUCTS.

Warning:

EPOD_JOB_UPDATE: Receipt of jobs without a job ID or a blank Job ID

Warning:

EPOD_JOB_UPDATE: Receipt of containers that don't exist in the job

The PDA web request server (Calidus_ePOD.asmx) will be modified to allow for Login and Logout messages to be stored on the server.

The LOGON_REQUEST message will be modified to add a new tag UPDATE_REQUIRED, 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></UPDATE_REQUIRED>
</LOGON_REQUEST>

If the UPDATE_REQUIRED tag is set to "N", the processor should only validate the message for Username, site and password and respond with a standard message received format message, rather than a full logon response. The message will be logged s normal to the audit table. The user will be marked as using the vehicle indicated on the message.

A new message handler for LOGOFF_REQUEST messages will be added to the web service. The message will be received in the following format:

<LOGOFF_REQUEST ID="" ...>
 <EPL_SITE_ID>XXXXXXXXXX</EPL_SITE_ID>
 <EPL_USER_ID>XXXXXXXXXX</EPL_USER_ID>
 <EPL_VEHICLE_ID>XXXXXXXXXX</EPL_VEHICLE_ID>
</LOGOFF_REQUEST>

The handler will validate the message for Username, site and password and respond with a standard message received format. The message will be logged to the audit table.

Admin Changes

The Site maintenance screen (site_header.aspx) will be modified to allow the system to be configured for:

EPL_NEXT_JOB_FLAG, a checkbox, defaulting to 'N' (Disabled).
EPL_RETURNS_DEPOT_FLAG, defaulting to 'N' (Disabled).
EPL_SCANNING_FLAG, defaulting to 'N' (Disabled).
EPL_AUTOLOGIN_FLAG, defaulting to 'Y' (Enabled).
EPL_ADHOC_ANYTIME_FLAG, defaulting to 'N' (Disabled).
EPL_AUDIT_LOGIN_FLAG, defaulting to 'N' (Disabled).

These flags 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 main menu will rename the Reason Codes maintenance screen as 'Codes' on the Maintenance menu.

The Reason Codes maintenance screen (Reason_Code.aspx) will be modified as follows:

The screen title will be renamed 'Codes'
When finding and filtering through Type, a new Type will be added to the drop-down list - code 'DU', description 'DU'.
When adding or editing codes, the Type drop-down list in the pop-up screen will be modified to add the same value as above.
The grid will be modified to show the new DU type correctly.
Any labels or informational messages on the screen that say 'Reason Code' will be modified to say only 'Code' instead.

Note: If these drop-down lists have not been modified to use the database-generated values rather than hard-coding them in the screen, then this should be modified for this now.

Warning:

Change the Job Screen to show the type as Loading or Unloading, depending on the value of the new EPL_LOADING_TYPE field?

Warning:

Change the User Tracking screen to allow selection of messages by type (e.g. Login, Logout, fuzzy match)?

PDA Changes

PDA DAL/Database Changes

Table EPOD_SITE requires the following modifications:

EPL_NEXT_JOB_FLAG - nvarchar(1), default 'N'.
EPL_RETURNS_DEPOT_FLAG - nvarchar(1), default 'N'.
EPL_SCANNING_FLAG - nvarchar(1), default 'N'.
EPL_AUTOLOGIN_FLAG - nvarchar(1), default 'Y'.
EPL_ADHOC_ANYTIME_FLAG - nvarchar(1), default 'N'.
EPL_AUDIT_LOGIN_FLAG - nvarchar(1), default 'N'.

Table EPOD_JOB requires the following modification:

EPL_LOADING_TYPE - nvarchar(2), DEFAULT ' '.

Table EPOD_CONTAINER requires the following modification:

EPL_VALID_DATE - integer(8).
EPL_VALID_TIME - integer(8).

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 XML Exports from these tables need not be modified.

The PDA objects affected are:

PDA_SITE
PDA_JOB
PDA_CONTAINER

General

A specific 'NHSBT' style preference will be added to the application, which will control the following:

A conversion of all mentions of the work "Container" to "Item". This will affect:
- All messages
- All tab titles
- All labels
The Job List row layout.
The Container List row layout.

The details of how this will affect each screen will be laid out in the following sections.

Warning:

Preferences

Allow vibration and alert sound to be defaulted on the device, both through scanning and normal setting
How can we default the alert sound?

Login

Functionality exists within C-EPOD to automatically log a driver back in to the point where they left the application, after an unplanned closure of the application. It was noted that the NHSBT team do not want this functionality and that it should be capable of being disabled. This will require a modification to the standard functionality of the application. Specifically, the first time the application opens the login screen, the auto-login feature will only be checked if the device improperly logged out (as now) and that the new Site-level configuration flag EPL_AUTOLOGIN_FLAG is enabled. If this flag is not enabled, the autologin feature will not be activated, meaning that no further changes need to be made to the other screens that access this feature.

NHSBT require that both the login and logout messages be stored on the server, for enquiry later. In order to achieve this, the messaging to the server will be modified.

The LOGON_REQUEST message will be modified to add a new UPDATE_REQUIRED tag to the message, in the format shown below:

<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></UPDATE_REQUIRED>
</LOGON_REQUEST>

This tag controls whether the server will respond with standing data updates. When logging on, and no internet connection is established, the LOGON_REQUEST message should be written to the message queue for processing. In this case, the UPDATE_REQUIRED tag should be set to "N", informing the server that no standing data updates are necessary. The server will respond with a standard message received response message, which may be handled and discarded.

If the message is sent normally as now, the UPDATE_REQUIRED tag may be omitted, or set to "Y", whichever is simpler. In this case, the server will respond with a standard LOGON_RESPONSE message, with all changed standing data.

Whenever the user logs out of the application (for example, here, vehicle checks or the job list screen, by backing out or pressing a dedicated Exit button), the application will now attempt to send a new Logoff message to the server, in the following format:

<LOGOFF_REQUEST ID="" ...>
 <EPL_SITE_ID>XXXXXXXXXX</EPL_SITE_ID>
 <EPL_USER_ID>XXXXXXXXXX</EPL_USER_ID>
 <EPL_VEHICLE_ID>XXXXXXXXXX</EPL_VEHICLE_ID>
</LOGOFF_REQUEST>

This will attempt to be sent immediately, waiting for a response. If this fails, or there is no internet connectivity, this should be added to the message queue, and the standard exit functionality called. This will inform the driver that there are messages pending, and can wait until these messages are successfully sent, ensuring the messages are received on the server, for enquiry.

To achieve the above, a new message sender and response processor will be written (LogoffRequest and ProcessLogoffResponse in WebServices) and a new Logoff function in system utilities, to call the existing ExitApp function after the message has been enqueued. This same process will be followed wherever the existing ExitApp function is called.

The Job List screen will be changed to allow the user to request re-login or change vehicle, which will return the user to the login screen.

For re-login, this should act as per the normal login procedure.

For Vehicle Change, the user and password should be disabled for entry, and only the vehicle checked. In this case, the LOGON_REQUEST message sent to the server may be modified to identify that this message requires no update response, just validation of the vehicle passed in and marking the vehicle as in use by that user. To achieve that, the message can have the UPDATE_REQUIRED tag set to "N".

In both of these instances, because the vehicle and user has changed, the device should force a refresh of the load on the device - it does not need to ask the driver whether the active load should be refreshed.

Note: As with the existing logging in process, as the vehicle has changed, the server may return a different load to process that the one that may have been in progress previously. The driver must ensure that they choose the correct vehicle, as this is normal behaviour.

Warning:

GPS-tag messages

The requirement for Location Check Digit has been superseded by a GPS Location Point.
The whole timer thing must be rewritten - requires a PROD spec to complete this.
Must enable GPS signals and keep refreshed within the application.
Use the GPS Message timer for this, and enable ASAP (i.e. at login).

Vehicle Checks

If the driver chooses to exit the system from vehicle checks, the application will send a logout message to the server, as specified earlier.

Job List

Pressing the android device's Menu button will show the existing menu for the application. This will be modified as follows (new items in italics):

Refresh Load
Show All/Outstanding Jobs
Re-logon
Change Vehicle
Unplanned Ad Hoc Collection
Audit Activity
Email Pending Messages

Additionally, all icons on this menu will be removed, as they do not display effectively on ultra-high and low-resolution devices, and some versions of Android.

When Re-logon or Change Vehicle are chosen, the job list screen will exit, to show the existing Login screen. In the case of Change Vehicle, the user and password should be locked. See the Login section for details on how this will react.

The option Unplanned Ad Hoc Collection should perform some validations:

The last location visited should be checked (by finding the last job completed on this load):
- If a location has not been visited, no ad hoc collection may be completed - the application should issue an error "Ad Hoc Collection"/"No location - no collection can be made".
- If the last visited location was a loading or unloading location, the application should issue an error "Ad Hoc Collection"/"No ad hoc collection at a depot".
If fine, a new job should be created for this last location visited, copying the details from the last completed job, as follows:
- Copy address and contact details of the last location visited.
- The Job ID should be left blank on the device database at this time.
- The Job Code should be set to the text "AHC", plus the Load ID, plus a unique counter for each Unplanned Ad Hoc Collection created on this load. So, if this was the 5th unplanned collection on Load 1234567890, the Job ID and Job Code should be set to "AHC_1234567890_5".
- All other references should be blank.
- Planned Start and End date and time and Actual Start date and time should be immediately set to now.
- Sequence should be copied.

This created Ad Hoc Collection job should be immediately started. Note: Once created, this job will act as all other jobs, in that it will require the job to be completed normally through the collection process, or cancelled if not required.

The automatic update and refresh of loads through a timed AutoUpdate process should not delete or remove any of these unplanned Ad Hoc Collection jobs - they should be left on the load, as the server is at this time unaware that these jobs exist.

The applications (C-TMS and C-EPOD) will be configured to consolidate jobs together when they have been planned on the same stop for the same location. In this case, the jobs themselves will be consolidated into a single row on the job list screen:

Job List
Proposed layout
Current layout

Note: The Job List should be consolidating based on location and Job Type (i.e. collection or delivery), ensuring there is 1 row for any deliveries at the location, and one row for any collections. Further more, the jobs on the job list should be sorted by sequence, planned time and then by the job type, as follows:

Delivery
Service
Collection

Although it is unlikely that the situation would occur that the current sorting of the rows would cause an issue with the NHSBT operation, this sorting mechanism will ensure that this will not be an issue in the future.

When a job is completed, the Job List is returned to by the signature screen or Job Completion process calling back to it. This call-back function must be modified to find the next job in the Job List. If the new EPL_NEXT_JOB_FLAG is enabled, and there is a job (or job consolidation) for the same location, then this job should be started automatically, displaying the Job Details screen for this next series of jobs immediately.

If there is no other job for this location, and the new EPL_ADHOC_ANYTIME_FLAG is enabled, and there was a delivery job completed at the last location, and that delivery job was not marked as a loading or unloading job, then the application should immediately display a choice to the driver - "Unplanned Collection"/"Is a collection required at this location?" with options "Yes" and "No". If "No" is selected, the application will simply display the Job List again. If "Yes" is selected, the application will follow the process as if the Unplanned Ad Hoc Collection menu option was selected.

If the driver chooses to exit the system from the job list screen (using the Android Back button), the application will send a logout message to the server, as specified earlier.

Job Detail

Note: As per standard functionality, the application will display Phone and SMS buttons if the customer contact on the job has a telephone number. If these buttons are not required, then the contact should not be sent through from C-TMS (i.e. not set up against the customer within C-TMS). No changes are necessary to this functionality within the application.

No changes will be made to the layout of the screen from the standard functionality. If consolidated jobs have been selected, the screen can allow more information to be seen, as in the following screenshots:

Job Details
Address and Contact Information
Instructions

Note the job counts and the navigation buttons available to the driver to page through the details of each job, and also the consolidated view of the instructions for each job (if they have any).

On clicking the Start Job button, the application will note whether this is a generated unplanned Ad Hoc Collection job (by checking the Job ID or Job Code as generated above). If this is the case, the application will not send a message to the server to inform it that the job has started or that the job needs updating (a JOB_LOCK message). This is because the server does not yet know of this job.

Collect / Deliver

Note that if the collection or delivery is part of a consolidation, the screen can allow more information to be seen, as in the following screenshots:

Collect / Deliver Screens when Consolidated
Job Details
Items (Containers)

Note: The existing Items tab is there to show all preadvised items - unplanned collection of items will be shown on a different ab (described later). The Items tab will only be shown if there are items preadvised for the jobs. If there are nonoe, this tab will not be present.

Note: The Complete button should only appear on the Job Details tab if any of the following conditions are true:

There are no preadvised items to collect or deliver.
The application is configured for Ad Hoc Collection (EPL_ADHOC_COLLECTION is enabled).

For NHSBT, the items on each job may be repeated, showing that the items for the jobs have been packed together into the same polar box (a reusable asset). The Items (Containers) list will be modified as part of this change to ensure that the these reusable assets appear once only in the list.

So, if there are two orders, one packed into asset IDs 00001 and 00002, and the second into asset IDs 00002 and 00003, the application would normally show 4 rows, as follows:

Item ...00001 for Order1
Item ...00002 for Order1
Item ...00002 for Order2
Item ...00003 for Order2

The application will now show only 3 rows:

Item ...00001 for Order1
Item ...00002 for 2 consignments
Item ...00003 for Order2

The proposed layout for the items is to show:

Item/Asset (Container) ID
Asset Type
Status
CODE 1 - a multi-use field. If this is blank in the interface, nothing will be displayed here.
Job ID - The chosen identifier of the job from which the item came. If this came from multiple jobs, this would show a count of these i.e. "X Consignments".
Customer Name - the name of the location (hospital or depot).

The expected layout is as follows:

Items (Containers) Proposed Layout

Note: Developer Notes:

As part of this change, the existing container tableview and contents should be converted to scrolling views instead.
The layout of the container rows should be modified so that they can grow or shrink based on content, rather than fixing the height of the row as now. To achieve this, a combination of horizontal and vertical layout schemes with Ti.UI.SIZE properties should be applied to the views and the elements contained therein. These have been prototyped and are available on request.
Any existing customer-specific layouts should be modified and tested to ensure that they work with the new layout mechanism.
The consolidation of containers together may be achieved similarly to the consolidation of the Job List.
With the above in mind, the linking to a container or containers when selecting it (from the table, key entry or scan) should look the container up in the list of containers for the jobs, as in the case of funFindContainer, for example in btnScan's click event. This would require modification to return an array of containers rather than the single container found, as now, as the container may be in multiple Jobs.
Bearing in mind multi-phase scanning (i.e. scan at truck), the list of containers for each job should show all containers at all times, including any already scanned (status C) or cancelled (status X). When binding or looking up containers on the PDACONTAINERS collections, this should bear in mind the phase of scanning and reject status C or X containers accordingly.
When marking containers as complete or cancelled, the PDACONTAINER objects in the PDACONTAINERS arrays should be updated directly, rather than retrieving a new object from the database, then updating, then refreshing the PDACONTAINERS lists or PDAJOB objects again. This will result in faster operation, as the Confirm and Cancel methods of the PDACONTAINER objects already refresh their parent object's internal data.
With this in mind, the refreshing of the container list after marking a container as complete or cancelled should not recreate the entire list, but simply rebind the data from the existing list.
The majority of these changes are achieved through changes to the existing BindContainerData function.

Note: As the system is expected to be configured for "Forced Container and Product Entry" (EPL_FORCED_ENTRY enabled), pressing or long-pressing on the grid should not have any options to Collect or Deliver items, although all other options should be present.

The Info option from this drop-down menu hows details of the selected item on a pop-up screen. Amongst other items, for consolidations, the screen displays:

Job Identifier - An identifier for the job, configured through the Admin system flag "Display Job As" (EPL_PDA_DIS_JOB_CODE displayed as EPL_JOB_DISP_ID).
Customer Name - Location Name from the Job.

In the case where the container is consolidated on the list, this screen should show a list if all the jobs and locations in sequence. This pop-up screen will allow the user to scroll to see all of the data if this exceeds the available space.

Warning:

Deconsolidating containers that are used on multiple orders?

The process supports the scanning of the barcode of the items preadvised to be collected, either through an attached external barcode scanner (through additional software and hardware purchases) or an internal laser scanner – this is entered through the Enter Container text box and Collect/Deliver button provided, or using the device's camera to scan within the application, using the Scan button provided. In both cases, the scanning of the items should validate the data.

When entering item IDs through the text box, the whole asset ID must be entered, including any leading application identifiers. Through training, the river must be informed to not enter the parenteses - if entered, the ID will not be recognised. When the Collect/Deliver button is pressed, the following will checked, if the application is configured for style NHSBT:

The leading 2 character will be extracted and checked.
If '00', the remaining text in the ID will be checked - if this is numeric only and 18 digits, then this will be accepted as a single trip Asset ID. If not, the Item will be rejected.
If '80', the next 2 characters will be extracted and checked - if this is '04, and the remaining length in the ID is 14 characters, then this will be accepted as Permanent Asset ID. If not, the item will be rejected.
If none of the above, the item will be rejected.

The rejection message will be "Item is in invalid format - rejected".

It is expected that the configuration on the device ("Scan Errors Intrusive" not enabled on flag EPL_SCAN_ERRORS) will be such that the message will not interrupt the driver or require them to clear the error - the message will simply appear on the bottom of the device, then clear after a few seconds. However, if this is enabled, then the message will default to an alert. This will stop the scanning process and display an alert that requires acceptance before continuing.

When entering items through the Scan button, the application will configure and display a scanning reticule using the device camera. The configuration for this will be modified so that the barcode scanner screen will accept only barcode type CODE 128. This configuration will be applied as part of the NHSBT style.

Note: Developer Notes:

The system styles may be used to complete this configuration. Create a generic styles for barcode scanning, namely:

barcodeConfig
barcodeConfigContainer
barcodeConfigProduct

All should generically be empty objects.

Style-specific version of these class configuration objects may then be added to the customer-specific section of the configItems object, to add in the configuration, in this case:

barcodeConfigContainer : {
    acceptedFormats: [7]
}

7 is the Ti.barcode declared value of the constant FORMAT_CODE_128.

The barcode object's scan method in Barcode.js will then require modification to allow a style to be passed, and to merge that style into the object, using the standard style object methods.

The call to the scan method in the containers and products tabs in this screen will be modified to pass in the style object to configure the scan, i.e.

Ti.App.Barcode.Scan('barcodeConfigContainer');

Note that this will also affect Services code, therefore similar configurations should be created for any uses of the Barcode.Scan method in the services code.

Note: When entering barcodes using a wedge or integrated scanner, rather than the application scanner, the application has no direct control over the wedge scanner, so it is not possible to limit the wedge scanner in terms of which barcodes it is allowed to scan. If this is required, it requires device-specific configuration of the scanner and further bespoke code written within the application. As wedge scanners have not at this time been confirmed, this is not part of the scope of this change.

Scanning through the Scan button will validate the scanned IDs is exactly the same way as they are when entered through the Enter Container text box and Collect/Deliver button.

Scanning through the Scan button will be modified to allow continuous scanning (i.e. not returning to application between scans were possible). This configuration is controlled by the new flag EPL_SCANNING_FLAG. This is to ensure the fasting scanning possible through the application and the device's camera.

The changes that will be made generically to achieve this are:

The overlay/scanning window size should be maximised for the device, to ensure that larger barcodes may be scanned more easily.
Items scanned successfully should be immediately marked as collected or delivered without requesting a pop-up dialogue confirmation.

If the new flag is configured, the following will also be enabled:

Unknown items will be identified with a message, but scanning will be allowed to continue without interruption.

Scanning may be interrupted for the following reasons:

When scanning preadvised items at collection and delivery, and all items have been found.
When ad hoc scanning an unadvised item, that requires Location or Asset Type entry (see the Ad Hoc Collection section)
When a critical scanning alert is encountered while scanning, that requires the user to accept a message.

Note that Critical scanning dialogues do not include scanning an incorrect format barcode (i.e. the wrong type, the wrong length, not numeric, etc) - these messages will be displayed but will not cause an alert box to be shown. Additionally, scanning an item again that has already been successfully scanned before will display a transient message but will not interrupt the scanning.

Note: Developer Notes:

The barcode object's Scan method will be again modified to check the value of this flag. If enabled, this will set a flag against the object (to declare that continuous scanning has been enabled) and set configure the scanner with the 'keepOpen' object property set to 'true'. A Stop method will also be created to cancel continuous barcode scanning (by calling the barcode object's cancel() method. This new Stop method must be used whenever the application wishes to close the scanning reticule, at the times shown above.
The code for this already prototyped and can be provided on request.
When the application is set up for intrusive scan errors, only Scanning an item ID that does not exist for the job should be seen to be intrusive. All other errors should be audible, vibrate the device and display a transient message, but should not display and blocking alert dialogue box.

When all preadvised items have been scanned as collected/delivered (or marked as cancelled), the application currently recognises this and automatically moves on to the Job Completion stage. This will not occur if this is a collection job, and the application has been configured for Ad Hoc Collection (EPL_ADHOC_COLLECTION). In this case, the device will simply display the empty items list (as there are no more items to scan) and wait, as there may be unplanned items to scan as part of the Ad Hoc Collection process (in the next section).

Ad Hoc Collection Tab

Note:

Ad Hoc Collection Prototype Screen-shots
Unplanned item details
Ad Hoc item list

Warning:

Prompt for location, if consolidated with multiple destinations

Warning:

Prompt for Asset Type, if single trip

Warning:

validate barcode types

NHSBT style only

Warning:

Validate that items on the preadvised list are allowed?

Warning:

Seamless scanning

If we're having the same functionality in both (i.e. scanning here can remove an item from the Preadvised list), then the seamless scanning should be allowed in this tab too, breaking out only when an unadvised item is scanned.

A Complete button should be available on the Job Details tab, to allow the users to manually indicate that all items have now been collected. Clicking this will instigate the Job Completion stage. If at this time no items have been scanned as part of the Ad Hoc Scanning tab for this collection (and Ad Hoc Collection is enabled), a pop-up alert will be displayed, showing "Unplanned Items"/"Please confirm that there are no unplanned items to scan", with options "Confirm" and "Cancel". Choosing "Confirm" will move on to Job Completion, whereas "Cancel" will return to the Collection process and activate the Ad Hoc Scanning tab.

Job Confirmation

Note: Regardless of whether any signatures are required for this job, this section covers all the functionality required within the processing of completing a job.

Warning:

Validation rules pop-up and auto-clausing

The device will display a pop-up warning to the user when the signature screen is displayed, expected to be "Issue life exceeded on some items. Please see the detail of the items affected below".
Claused text: "Issue life exceeded - product must be checked"

Warning:

Add containers to Unloading job for Ad Hoc Collections/Cancelled deliveries

If the new EPL_RETURNS_DEPOT_FLAG is enabled, the following functionality should be added when confirming the completion of jobs:

For collections, find the linked job if present and cancel any cancelled containers from the delivery with the reason code (should already do this, if the flag EPL_LINKED_C_D is enabled).
For cancelled collections, find the linked job if present and cancel it (should already do this, if the flag EPL_LINKED_C_D is enabled).
For deliveries, find the following Unloading job and add any cancelled containers to it. If no containers are cancelled or an unload job is not found, this does not need to be added at all.
For cancelled deliveries, find the following Unloading job and add a job to it, having all containers from that cancelled delivery job on it. If an unload job is not found, this does not need to be added at all.
For collections, find the following Unloading job and add any ad hoc scanned containers to it. If one is not found, this does not need to be added at all.
For new Ad Hoc Collections (i.e. created in response to the driver requesting them from the menu, or confirming that one is required from the prompt when completing other jobs), add a job to the next following Unloading location, with the same details of the job, with a new generated Job ID. Link this to the existing unloading tasks. Note: If an unloading task is not found following the job just added, one does not need to be added at all.

Warning:

Container list - take into account consolidated containers on consolidated jobs.

Warning:

Clause container - take into account consolidated containers on consolidated jobs

Warning:

Start the next job automatically

Actually in Job List

Warning:

Prompt for Ad Hoc Collection for the location

Actually in job List

Warning:

JOb ID must be set for Unplanned Ad Hoc Collections at this time. Must stay unique.

Warning:

Sending back the data to the server - any changes not already covered?

Appendix A: TEST PLAN

Test Script / Scenario Reference	C-EPOD Collection Changes	Call Number(s): 317761 SCR15
Test Script / Scenario Description	Test the ...	PASS / ISSUES / FAIL
Menu Access	None
Pre-requisites	None	Tested By:
Test Objective	To test that: ...	Date:

Step	Action	Result	Remarks	P/F
1	Test Title

1.01	Do something	Some expected results

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	0.00	7.00	0	£0.00
Technical Specification	0.00	0.00	0	£0.00
Development	0.00	35.50	0	£0.00
Testing and Release	0.00	7.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

Warning:

SDD document

2.0

21/05/2014

2

Warning:

EPOD-TMS Interface document - 317907

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	_____________________________

Anonymous

Search

FS 317761 SCR15 NHSBT C-EPOD Collection Changes

Functional Overview

Client Requirement

Solution Overview

Scanning

Login

Job List

Job Details

Collection

Delivery

Job Confirmation

Scope

Set-up

Pre-requisites

CALIDUS TMS Interface Changes

Menu Structure

Data

Functional Description

Database/DAL

Import/Export Messages

Admin Changes

PDA Changes

PDA DAL/Database Changes

General

Login

Vehicle Checks

Job List

Job Detail

Collect / Deliver

Ad Hoc Collection Tab

Job Confirmation

Appendix A: TEST PLAN

Appendix B: Quote & Document References

Navigation

Wiki tools

Page tools

Categories