Calidus HUB - User contributions [en-gb]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2018-06-07T15:23:28Z

AppaduN: Minor corrections

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|7th June 2018}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

OBS Logistics have been requested to write the interface in order to speed up the delivery of the project.

The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.

{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This occurs quite frequently on radial deliveries.

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

== Solution Overview ==
The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.

{{Note}} The C-ePOD system will be hosted by OBS, whilst the ERP is hosted by the customer. This interface will need to connect to this ERP to access the view to get the job details. There is a technical requirement to have the two servers connected, which will require action by OBS technical services and the customer in collaboration.

A scheduled import process will be created on the system, running at a timed interval.

There will be multiple manifests sent for the same vehicle on the same day. These must be combined into a single manifest on C-ePOD. {{Note}} In order for the interface to successfully combine manifests, it is assumed that there will be one load required per vehicle per depot (Site) per day.

{{Note}} Manifests (that create Loads in C-ePOD) will be allocated to a vehicle and/or driver. This allows the loads to be created and allocated to a driver for completion. Note however that, once created, the {{#var:System}} Admin system (Load or User screens) may be used to change allocation of vehicles and drivers on a load.

The interface will create loads, one per vehicle per depot (Site) per day.

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

It is noted that EBB will tidy up the list of drivers before the implementation

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

The following columns are also noted from the MSA view:
* DefaultSiteID - the final delivery depot
* Originating Depot - the depot from which the product is sourced. {{Note}} The ''depot'' attribute of the '''order''' tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).

The manifest on which a job is received will be stored against the job in C-ePOD, as well as any of the other customer references. This will be used by the interface to determine if the manifest has been received before. If this is the case, and the manifest has been modified (i.e. orders or products removed or added), this will be used by the system to determine whether jobs are to be added to the created load for this vehicle and day, or whether the jobs will be removed (deleted). Products not on the jobs updated will be removed, and new products added.

The jobs will be placed on the Load in the order in which they are received in the manifest file. If a further manifest is received for this vehicle, the jobs will be added to the end of the manifest. A hard sequence will be generated for the jobs on the manifest.

In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

{{Note}} Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.

Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.

When receiving jobs through the interface, the invoice (customer) address will be updated, if this has changed. EBB Paper have confirmed that the Invoice address changing is as expected. It has been confirmed that any previous jobs with this invoice (customer) address will from that point show the new invoice address, and this is acceptable to EBB Paper.

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

{{Note}} Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 06000000 (06:00)
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 14000000 (14:00).

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS - Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
* METRES SQUARED - quantity will be multiplied by 1000.
* LINEAR METRES - quantity will be multiplied by 1000.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

Note that the above method has been confirmed by the customer.

This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. {{Note}} This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).

== Scope ==
This change will be applied to system version 4.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery><br />

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery><br />

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery><br />

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery><br />

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery><br />

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file. This file will be downloaded before processing to ensure that all characters that should have been URL encoded have been. The file will be pre-parsed to remove any non printable characters.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag starts with the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them. The case will be converted to uppercase.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - Not equal to "C" "X" if the '''driver''' attribute is not explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new customer will be created on EPOD_CUSTOMER as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Manifest No (manfest), Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 06000000 (06:00)
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 14000000 (14:00).
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

{{Note}} that if updating a job at EPL_STATUS of "X", any existing products/containers associated with this job will also be reset to pending status.

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR
* EPL_SEQUENCE - linenumber/16384 (first 4 characters of this if not a whole number)

Note that ITEMNMBR and ITEMDESC may contain control characters not compatible with the EPOD device software. These should be stripped out before saving into the EPOD database.

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || linenumber/16384 (first 4 characters of this if not a whole number)
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=2.5
|ETS=0
|EDEV=15.5
|ESTT=3.50
|EIMP=1.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2018-06-07T15:22:37Z

AppaduN: Minor corrections

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

OBS Logistics have been requested to write the interface in order to speed up the delivery of the project.

The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.

{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This occurs quite frequently on radial deliveries.

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

== Solution Overview ==
The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.

{{Note}} The C-ePOD system will be hosted by OBS, whilst the ERP is hosted by the customer. This interface will need to connect to this ERP to access the view to get the job details. There is a technical requirement to have the two servers connected, which will require action by OBS technical services and the customer in collaboration.

A scheduled import process will be created on the system, running at a timed interval.

There will be multiple manifests sent for the same vehicle on the same day. These must be combined into a single manifest on C-ePOD. {{Note}} In order for the interface to successfully combine manifests, it is assumed that there will be one load required per vehicle per depot (Site) per day.

{{Note}} Manifests (that create Loads in C-ePOD) will be allocated to a vehicle and/or driver. This allows the loads to be created and allocated to a driver for completion. Note however that, once created, the {{#var:System}} Admin system (Load or User screens) may be used to change allocation of vehicles and drivers on a load.

The interface will create loads, one per vehicle per depot (Site) per day.

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

It is noted that EBB will tidy up the list of drivers before the implementation

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

The following columns are also noted from the MSA view:
* DefaultSiteID - the final delivery depot
* Originating Depot - the depot from which the product is sourced. {{Note}} The ''depot'' attribute of the '''order''' tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).

The manifest on which a job is received will be stored against the job in C-ePOD, as well as any of the other customer references. This will be used by the interface to determine if the manifest has been received before. If this is the case, and the manifest has been modified (i.e. orders or products removed or added), this will be used by the system to determine whether jobs are to be added to the created load for this vehicle and day, or whether the jobs will be removed (deleted). Products not on the jobs updated will be removed, and new products added.

The jobs will be placed on the Load in the order in which they are received in the manifest file. If a further manifest is received for this vehicle, the jobs will be added to the end of the manifest. A hard sequence will be generated for the jobs on the manifest.

In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

{{Note}} Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.

Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.

When receiving jobs through the interface, the invoice (customer) address will be updated, if this has changed. EBB Paper have confirmed that the Invoice address changing is as expected. It has been confirmed that any previous jobs with this invoice (customer) address will from that point show the new invoice address, and this is acceptable to EBB Paper.

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

{{Note}} Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 06000000 (06:00)
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 14000000 (14:00).

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS - Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
* METRES SQUARED - quantity will be multiplied by 1000.
* LINEAR METRES - quantity will be multiplied by 1000.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

Note that the above method has been confirmed by the customer.

This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. {{Note}} This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).

== Scope ==
This change will be applied to system version 4.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery><br />

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery><br />

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery><br />

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery><br />

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery><br />

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file. This file will be downloaded before processing to ensure that all characters that should have been URL encoded have been. The file will be pre-parsed to remove any non printable characters.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag starts with the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them. The case will be converted to uppercase.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - Not equal to "C" "X" if the '''driver''' attribute is not explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new customer will be created on EPOD_CUSTOMER as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Manifest No (manfest), Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 06000000 (06:00)
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 14000000 (14:00).
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

{{Note}} that if updating a job at EPL_STATUS of "X", any existing products/containers associated with this job will also be reset to pending status.

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR
* EPL_SEQUENCE - linenumber/16384 (first 4 characters of this if not a whole number)

Note that ITEMNMBR and ITEMDESC may contain control characters not compatible with the EPOD device software. These should be stripped out before saving into the EPOD database.

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || linenumber/16384 (first 4 characters of this if not a whole number)
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=2.5
|ETS=0
|EDEV=15.5
|ESTT=3.50
|EIMP=1.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2018-06-05T17:06:16Z

AppaduN: v1.1 - Changes reflecting changes after development

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

OBS Logistics have been requested to write the interface in order to speed up the delivery of the project.

The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.

{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This occurs quite frequently on radial deliveries.

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

== Solution Overview ==
The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.

{{Note}} The C-ePOD system will be hosted by OBS, whilst the ERP is hosted by the customer. This interface will need to connect to this ERP to access the view to get the job details. There is a technical requirement to have the two servers connected, which will require action by OBS technical services and the customer in collaboration.

A scheduled import process will be created on the system, running at a timed interval.

There will be multiple manifests sent for the same vehicle on the same day. These must be combined into a single manifest on C-ePOD. {{Note}} In order for the interface to successfully combine manifests, it is assumed that there will be one load required per vehicle per depot (Site) per day.

{{Note}} Manifests (that create Loads in C-ePOD) will be allocated to a vehicle and/or driver. This allows the loads to be created and allocated to a driver for completion. Note however that, once created, the {{#var:System}} Admin system (Load or User screens) may be used to change allocation of vehicles and drivers on a load.

The interface will create loads, one per vehicle per depot (Site) per day.

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

For example:
* "DAVID EASTMAN" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

It is noted that EBB will tidy up the list of drivers before the implementation

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

The following columns are also noted from the MSA view:
* DefaultSiteID - the final delivery depot
* Originating Depot - the depot from which the product is sourced. {{Note}} The ''depot'' attribute of the '''order''' tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).

The manifest on which a job is received will be stored against the job in C-ePOD, as well as any of the other customer references. This will be used by the interface to determine if the manifest has been received before. If this is the case, and the manifest has been modified (i.e. orders or products removed or added), this will be used by the system to determine whether jobs are to be added to the created load for this vehicle and day, or whether the jobs will be removed (deleted). Products not on the jobs updated will be removed, and new products added.

The jobs will be placed on the Load in the order in which they are received in the manifest file. If a further manifest is received for this vehicle, the jobs will be added to the end of the manifest. A hard sequence will be generated for the jobs on the manifest.

In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

{{Note}} Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.

Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.

When receiving jobs through the interface, the invoice (customer) address will be updated, if this has changed. EBB Paper have confirmed that the Invoice address changing is as expected. It has been confirmed that any previous jobs with this invoice (customer) address will from that point show the new invoice address, and this is acceptable to EBB Paper.

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

{{Note}} Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 0600
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS - Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
* METRES SQUARED - quantity will be multiplied by 1000.
* LINEAR METRES - quantity will be multiplied by 1000.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

Note that the above method has been confirmed by the customer.

This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. {{Note}} This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).

== Scope ==
This change will be applied to system version 3.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery><br />

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery><br />

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery><br />

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery><br />

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery><br />

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file. This file will be downloaded before processing to ensure that all characters that should have been URL encoded have been. The file will be pre-parsed to remove any non printable characters.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag starts with the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them. The case will be converted to uppercase.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - Not equal to "C" "X" if the '''driver''' attribute is not explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new customer will be created on EPOD_CUSTOMER as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Manifest No (manfest), Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 06000000 (06:00)
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 14000000 (14:00).
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

{{Note}} that if updating a job at EPL_STATUS of "X", any existing products/containers associated with this job will also be reset to pending status.

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR
* EPL_SEQUENCE - linenumber/16384 (first 4 characters of this if not a whole number)

Note that ITEMNMBR and ITEMDESC may contain control characters not compatible with the EPOD device software. These should be stripped out before saving into the EPOD database.

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || linenumber/16384 (first 4 characters of this if not a whole number)
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=2.5
|ETS=0
|EDEV=15.5
|ESTT=3.50
|EIMP=1.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 344273 SCR-343463-01 EBB Paper Bespoke Import Interface

2018-06-05T16:59:55Z

AppaduN: Changes reflecting changes after development

<div class="noprint">
{{#vardefine:Client|EBB}}
{{#vardefine:ClientName|EBB Paper}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Bespoke Import Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th August 2017}}
{{#vardefine:Reference|344273 SCR-343463-01}}
{{#vardefine:Year|2017}}
</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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
SCR-343463-01: Bespoke Import Interface

OBS Logistics have been requested to write the interface in order to speed up the delivery of the project.

The loads are interfaced from MSA in a custom XML format in a flat-file, after the routes are planned. A button is pressed when the manifest is finished planning to create this file.

{{Note}} The manifests are used for picking. If additional orders are added to the vehicle (add-ons), the orders are placed on a separate manifest, for the same vehicle on the same day. This is because adding orders to an existing manifest (which is possible) will confuse the pickers and potentially result in double picks. This occurs quite frequently on radial deliveries.

This file does not contain all the information required to create the jobs. Predominantly, address information and product case details are missing from this interface file. The remaining information is to be accessed directly from a view on the ERP system, running a SQL Server database.

== Solution Overview ==
The interface created will be triggered by the receipt of the TMS XML file. The processing of the jobs on this file will retrieve the information on the orders from a view available in the ERP, through direct connection to this database.

{{Note}} The C-ePOD system will be hosted by OBS, whilst the ERP is hosted by the customer. This interface will need to connect to this ERP to access the view to get the job details. There is a technical requirement to have the two servers connected, which will require action by OBS technical services and the customer in collaboration.

A scheduled import process will be created on the system, running at a timed interval.

There will be multiple manifests sent for the same vehicle on the same day. These must be combined into a single manifest on C-ePOD. {{Note}} In order for the interface to successfully combine manifests, it is assumed that there will be one load required per vehicle per depot (Site) per day.

{{Note}} Manifests (that create Loads in C-ePOD) will be allocated to a vehicle and/or driver. This allows the loads to be created and allocated to a driver for completion. Note however that, once created, the {{#var:System}} Admin system (Load or User screens) may be used to change allocation of vehicles and drivers on a load.

The interface will create loads, one per vehicle per depot (Site) per day.

The system will be configured to create standing data from the received import information, such as:
* Drivers
* Customers (Invoice Addresses)
* Vehicles
As noted above, it is expected that this data will be created at implementation.

When C-ePOD receives an inbound file from the customer, drivers and vehicles will be created as part of this interface, if they do not exist. The driver ID will be created as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them.

For example:
* "DAVID EASTMAN" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"
Note that where other drivers have similar names, the generated ID will increment the unique identifier. So:
* "DIANE EASTMAN" will become "DEAST002"
* "SANDERSON JOHN" will become "SJOHN002"

The password will be defaulted to the user name.

It is noted that EBB will tidy up the list of drivers before the implementation

Sites will be created for each depot, following the encoding within the customer systems:
{| class="wikitable" border="1"
|- bgcolor="silver"
!GP Site ID !!GP ADI Site ID !!Fleet name
|-
|03 CHARLTO ||903 ADI ||Thurrock
|-
|04 FARNBOR ||904 ADI ||Farnborough
|-
|05 WATFORD ||905 ADI ||Watford
|-
|09 YEOVIL ||909 ADI ||BRISTOL
|-
|10 BIRMING ||910 ADI ||Birmingham
|-
|11 MANCHES ||911 ADI ||Manchester
|-
|12 SHEFFIE ||912 ADI ||Sheffield
|-
|13 NEWCAST ||913 ADI ||Newcastle
|-
|14 GLASGOW ||914 ADI ||Glasgow
|-
|31 FELIXST ||931 ADI ||Felixstowe
|-
|32 MAREXPO ||932 ADI ||Marexport
|}
{{Note}} The site is taken from the Originating Depot. The ADI site ID will be considered to be the GP site ID in this interface. Any manifests in the file for sites not in this list will not have loads or jobs created for them.

The interface must identify the Site (the executing depot) and the Owner (the originator).
* The owner is considered the Sales Territory (column SALSTERR in the MSA view)
* The executing depot is the depot property on the '''manifest''' tag in the XML file.

It is noted that the following will be Owners only and will not be operators:
* 08 PRINTMT
* 20 EBBOFFI
* 30 GLOSSOP

The following columns are also noted from the MSA view:
* DefaultSiteID - the final delivery depot
* Originating Depot - the depot from which the product is sourced. {{Note}} The ''depot'' attribute of the '''order''' tag in the TMS XML file also identifies the originating depot. For example, if this contains "\03" this identifies "03 CHARLTON" as the depot (and THURROCK as the fleet).

The manifest on which a job is received will be stored against the job in C-ePOD, as well as any of the other customer references. This will be used by the interface to determine if the manifest has been received before. If this is the case, and the manifest has been modified (i.e. orders or products removed or added), this will be used by the system to determine whether jobs are to be added to the created load for this vehicle and day, or whether the jobs will be removed (deleted). Products not on the jobs updated will be removed, and new products added.

The jobs will be placed on the Load in the order in which they are received in the manifest file. If a further manifest is received for this vehicle, the jobs will be added to the end of the manifest. A hard sequence will be generated for the jobs on the manifest.

In the interface, orders for the same customer code will be linked together and consolidated on the device, ensuring that only one delivery instruction is present, although both orders will be maintained.

The interface will consolidate jobs together if:
* The manifest on which the job is received is determined to be on the same Load as other jobs.
* The job has the same customer and delivery address as another job on the load.
* The other jobs are not completed or cancelled.
* They are the same type i.e. deliveries can consolidate with deliveries and collections with collections only.
Note that the consolidation process will not use the delivery time of the orders when determining whether to consolidate jobs.

Note also that the driver will have the ability to manually consolidate and deconsolidate jobs on the device when executing the load.

There are many different types of orders. The type is identified through the alpha prefix against the order. The main types are below:
* INV - Delivery order
* CAL - Call-off. Considered to be the same as an INV order.
* RTN - Collection from customer.

{{Note}} Only these order types will be uploaded to the C-ePOD system as jobs. All other types will be excluded when processing the files.

{{Note}} Any manifests marked as TRUNK (in the '''trailer''' tag of the TMS XML file) will also not be processed.

Desk collections will be interfaced to C-ePOD on a separate manifest per depot, but with a driver of "WAREHOUSE". {{Note}} The view MSA contains a column that identifies whether this is a customer collection (column CustColl), but this is unreliable.

Job Instructions should be populated with Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together.

When receiving jobs through the interface, the invoice (customer) address will be updated, if this has changed. EBB Paper have confirmed that the Invoice address changing is as expected. It has been confirmed that any previous jobs with this invoice (customer) address will from that point show the new invoice address, and this is acceptable to EBB Paper.

Planned delivery times will be maintained on each job created.

There are essentially 2 types of order:
* A non-timed delivery will have a cut off of 14:00
* Timed Delivery

{{Note}} Development work is required with GP to allow the EBB Paper sales team to maintain times on the order. This will be an EBB Paper task to complete.

The start and end planned dates and times will be populated from the values in the following MSA view columns:
* Start Planned Date - ReqShipDate
* Start Planned Time - StartTime if populated, else 0600
* End Planned Date - ReqShipDate
* End Planned Time - DelTime if populated, else FinishTime if populated, else 1400.

All jobs will be set with a configuration element known as Job Group - this will define the process to be followed against each job, such as:
* Driver Signature.
* POC/POD document format.
* POC/POD business address and logo.
* Terms and Conditions displayed.

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled
For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

The products will be created on each job created with the details taken from the ERP. The details expected to be received are:
* Product Code
* Product Description - stored as a truncated value
* FSC number (optional) - stored with the full product description in the long description field.
* Pack Size
* UOM
* Weight
* Quantity

The pack size of the product will be taken from the ERP view in the interface. This will come from Sell Pack in the interface. It is noted that there is also a Purch Pack field, and it is confirmed that C-ePOD has no place to store this information.

UOFM is the defined unit of measure of the product being delivered. There are multiple products UOMs that require the quantity to be decimal (for example, Weight (TONNES), Length (LINEAR METRES), Area (METRES SQUARED). In order for this to be achieved, the C-ePOD import interface for this system will multiply the quantities by a factor (for example, SHEETS UOM is in 1000's, so quantity 1.4 is actually 1400 sheets).

The following is a list of the UOFMs known at this time and the proposals to handle them:
* 1 - always 1 - accepted as such, but rounded up if decimal.
* 1000 - quantity will be multiplied by 1000.
* BOTTLE - always integer value - accepted as such, but rounded up if decimal.
* BOX - always integer value - accepted as such, but rounded up if decimal.
* CHARGE - Excluded - this is a delivery charge. No line will be created.
* EACH - always integer value - accepted as such, but rounded up if decimal.
* ENVS - Envelopes. Quantity will be multiplied by 1000.
* MISC - always integer value - accepted as such, but rounded up if decimal.
* ROLL - always integer value - accepted as such, but rounded up if decimal.
* SETS - Multi-part paper. Quantity will be multiplied by 1000.
* SHEETS - quantity will be multiplied by 1000
* TONNE - quantity will be multiplied by 1000 and the UOM set to "KGS".
* METRES SQUARED - quantity will be multiplied by 1000.
* LINEAR METRES - quantity will be multiplied by 1000.

There are then essentially 4 rules:
{| class="wikitable" border="1"
|- bgcolor="silver"
!RULE !!UOMS
|-
|Multiply by 1000 ||1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round up to nearest integer value ||1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||CHARGE
|-
|Multiply by 1000 and change to KGS ||TONNE
|}
Any not on the list would follow the first rule (i.e. multiply quantity by 1000).

Note that the above method has been confirmed by the customer.

This process will create jobs as part of loads on the interface. It is possible that additional information may need to be communicated to the driver whilst out in the field. In this case, the WEBFLEET messaging function will be used by the operation. Furthermore, it is noted that additional jobs may be created in C-ePOD Admin for ad-hoc collections. For example, adding a job at the end of the shift (load) to go to a customer and pick up some empty pallets. {{Note}} This job will exist solely in C-ePOD, as the jobs are not being interfaced back to GP when complete. EBB Paper must take care when adding jobs of this type, ensuring that any subsequent actions required for these jobs is handled (for example, invoicing).

== Scope ==
This change will be applied to system version 3.X.

This change includes up to 2 days relating to the external MSA view, for set-up and testing.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Interface ID of "EBB", description "EBB", will be added to the EPOD_LIST_ITEMS for XF Interface IDs.

A new Code Type of "UOM", description "UOMs", will be added to the EPOD_LIST_ITEMS for Reason Codes.

A new EPOD_LISTS ID must be configured for Code Conversion Types, with the following List Items on EPOD_LIST_ITEMS, with Description and Value set as follows:
* Value "MULTIPLY", Description "Multiply". This is the default value for EBB Paper.
* Value "ROUND", description "Round".
* Value "EXCLUDE", description "Exclude".
* Value "DEFAULT", description "As Received". This is the default value for all other customers.

Sites for each depot will be configured. Each site will be set up with EPL_EXT_FLEET set to the fleet name, as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Site ID !!Fleet
|-
|03 CHARLTO ||THURROCK
|-
|04 FARNBOR ||FARNBOROUGH
|-
|05 WATFORD ||WATFORD
|-
|09 YEOVIL ||BRISTOL
|-
|10 BIRMING ||BIRMINGHAM
|-
|11 MANCHES ||MANCHESTER
|-
|12 SHEFFIE ||SHEFFIELD
|-
|13 NEWCAST ||NEWCASTLE
|-
|14 GLASGOW ||GLASGOW
|-
|31 FELIXST ||FELIXSTOWE
|-
|32 MAREXPO ||MAREXPORT
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Site1.png|''Site Maintenance''
</gallery><br />

A new Import Interface configuration will be set up. This is required only for one of the sites, expected to be the first site "03 CHARLTO":
* EPL_XF_CONFIG_ID - "03 CHARLTO"
* EPL_DESCRIPTION - As required
* EPL_XF_TYPE - "FTP" or "FILE"
* EPL_XF_DESTINATION - remote FTP server and path for FTP, local file path for FILE
* EPL_XF_ID - "EBB"
* EPL_WEB_USER - FTP user for FTP
* EPL_WEB_PASSWORD - FTP password for FTP
* EPL_DB_CONNECTION - MSA database connection information e.g. "Data Source=[SERVER];Initial Catalog=[DB_NAME];User Id=[USER];Password=[PASSWORD];"
* EPL_XF_DIRECTION - "I" - Import type
* EPL_EXPORT_JOB_TYPES - "INV|CAL|RTN" - list of Order Types to be processed, pipe-delimited. Up to 5 allowed
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''New EBB Import Configuration''
</gallery><br />

A generic TTM Export configuration will be created (as ID "TTM"), as well as a specific TTM Export configuration for the first site (e.g. "03 CHARLTO"). The configuration of both will be identical apart from the Config ID.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig2.png|''TTM Export Sample Configuration''
</gallery><br />

The Interfaces for each site will be set as follows:
* For Site ID "03 CHARLTO", set the XF Config ID to "03 CHARLTO".
* For all other sites, set to "TTM"

It is expected that there will need to be Job Group configurations for the different job types, as they will have different execution processes on the mobile devices.

Job Groups will be created as follows for each site above:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Job Group !!Description
|-
|COL || Radial Collection
|-
|DEL || Radial Delivery
|-
|DESK || Desk Collections
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_JobGroups1.png|''Job Groups Maintenance''
</gallery><br />

The set-up of each job group will include the following:
* Radial Collection/Delivery
** Customer Signature
** Unmanned Location Signature enabled
** Deliver All functionality enabled
* Desk Collect
** Customer Signature
** Unmanned Location Signature will ''not'' be enabled
** Deliver All functionality enabled

For all jobs groups, it is expected that the following will also be configured:
* No Job Photo
* EBB Paper POD format
* Terms and Conditions is expected to be set to:
** Please be sure to check every consignment before signing. All sales are subject to Conditions of Sale, a copy of which is at the back of the EBB Price List and on our website http://www.ebbpaper.co.uk

All of the UOMs required by the customer should be configured on the Admin Codes Maintenance screen for all sites. The values known at this time are as follows, with the Conversion settings required for each:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Conversion Type !! Value !! Code !! UOMS
|-
|Multiply || 1000 ||  || 1000, ENVS, SETS, SHEETS, METRES SQUARED, LINEAR METRES
|-
|Round || 1 ||  || 1, BOTTLE, BOX, EACH, MISC, ROLL
|-
|Exclude ||  ||  || CHARGE
|-
|Multiply || 1000 || KGS || TONNE
|}

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />


= Functional Description =
== Database & Data Access Layer ==
The following fields will be added to the Job table EPOD_REASON_CODE:
* EPL_CONV_TYPE - nvarchar(10)
* EPL_CONV_VALUE - float
* EPL_CONV_CODE - nvarchar(20)

These fields will be added to all stored procedures in the database that require them.

These fields are ''not'' required on the device.

These fields are ''not'' required to be set on codes imported through the standard XML import (flat file or webservice).

These fields are ''not'' required to be contained within the Export.

These fields are ''not'' required to be used when filtering data for selection.

The following fields will be added to the Job table EPOD_XF_CONFIG:
* EPL_DB_CONNECTION - nvarchar(255)

This field will be added to all stored procedures in the database that require it.

This field is ''not'' required on the device.

This field is ''not'' required to be used when filtering data for selection.

{{Note}} All DAL objects that link to XF_CONFIG may also require change.

The EPOD_SETUP stored procedure will be modified for the new EPOD_LISTS and EPOD_LIST_ITEMS values.

== Admin ==
=== Codes Maintenance Screen ===
The Codes Maintenance screen (reason_code.aspx) will be modified to support UOMs.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_Codes1.png|''Codes Maintenance''
</gallery><br />

The '''Find''' criteria will be modified to allow selection of the new "UOM" type. Additionally, a blank "-- Select --" option will also be provided, for when the user wished to see all codes of all types. A new Code Type of "UOM" (description "UOMs") will be added to the EPOD_LIST_ITEMS for Reason Codes.

The results table does ''not'' require modifications.

The pop-up Entry/Edit form will be modified for entry of the new UOM codes.

This is accessed when entering a new code using the '''New''' button, and when editing existing codes by clicking the '''Select''' button against a line in the results table.

The user will be allowed to enter codes of type "UOM", selected from the drop-down list. A new Code Type of "UOM" will be added to the EPOD_LIST_ITEMS for Reason Codes.

When editing or adding reason codes of type "UOM" ''only'', new fields will be present on the pop-up form, as shown below:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Label !!Field !!Pop-up Help
|-
|Conversion Type || EPL_CONV_TYPE ||USED BY BESPOKE INTERFACES ONLY to determine whether the quantity is modified or the line processed when the UOM against the product line matches this value
|-
|Value || EPL_CONV_VALUE ||USED BY BESPOKE INTERFACES ONLY. If Conversion Type is "Multiply", this value is used to multiply the product quantity. If Conversion Type is "Round", this is used to round the quantity to the nearest value provided here.
|-
|XRef Code || EPL_CONV_CODE ||USED BY BESPOKE INTERFACES ONLY. If present, the UOM is converted to the value provided here.
|}

These should be laid out as shown in the screenshot in the pop-up form.

The Conversion Type will be added with the following drop-down list items, populated from the EPOD_LISTS and EPOD_LIST_ITEMS tables.
* "Multiply" - enter numeric value for multiplication.
* "Round" - enter value to round to (e.g. 1 means integer value, 0.25 is round to nearest 0.25, etc)
* "Exclude" - lines of this DU type are not added at all - Value field disabled.
* "As Received" - no calculation - Value field disabled.

The default value for this list will be set by the default value in the EPOD_LIST_ITEMS table, as follows:
* Defaults to Type "Multiply" for EBB Paper
* Default to "As Received" for all other customers.

The Value field will be enabled only if the following values are selected in the Conversion Type:
* Multiply
* Round
The Value field will be a numeric text field, allowing decimal entry, defaulting to "1000" if enabled.

The XRef Code will be a drop-down list of all codes of the Code Type being edited/added by this screen, and will be populated on selection of the Code Type. This drop-down list will include a blank default value of "Blank", and show the Code and Descriptions of all the selected codes. The list will be ordered by the Code, ascending.

When saving, the values will be saved in the appropriate fields on the EPOD_REASON_CODE table, as shown above.

=== Interface Config Screen ===
The Import/Export Maintenance screen (xf_config.aspx) will be modified to support configuration of the new EBB Paper interface.

<gallery widths=600px heights=350px perrow=1>
File:FS_344273_Admin_XFConfig1.png|''Import/Export Configuration Maintenance''
</gallery><br />

Fields required to be displayed when configuring the "EBB" interface:
* EPL_XF_CONFIG_ID - Always displayed.
* EPL_DESCRIPTION - Always displayed.
* EPL_XF_TYPE - Always displayed.
* EPL_XF_DESTINATION - Always displayed.
* EPL_XF_ID - Always displayed. This drop-down list will be modified to include ID "EBB".
* EPL_XF_DIRECTION - Always displayed.
* EPL_WEB_USER - only if FTP or SOAP transfer types are selected.
* EPL_WEB_PASSWORD - only if FTP or SOAP type selected
* EPL_DB_CONNECTION - This new field will only display if type "EBB" is selected and will include validation that it must be entered. This will be labelled as "Database Connection". The field will be a wide entry field (at least double the width of a standard field).
* EPL_EXPORT_JOB_TYPES - Display if type is "EBB". The validation on this field will be modified so that pipe-delimited list of anything can be entered, if the type is "EBB".
* EPL_FILENAME - Filename to match when picking up files. Expected to be "Manifest_*.xml".
* EPL_EMAIL_ERRORS - email address for file processing error notifications.

== Auto-Import ==
=== General ===
The process will update and create all data as required, committing each as they are processed.

There are instances where the failure reason will result in the following processing:
* Stop processing this file and all further files (Failed Import).
* Stop processing this file and process subsequent files (Failed File).
* Stop processing this order and move to the next order (Failed Order).

Failed Import reasons:
* Unable to connect to MSA

Failed File reasons:
* Standing Data not being created:
** User does not exist
** Vehicle does not exist
** Job Group does not exist
* Non-DESK manifest is on a load that has already been completed

Failed Order reasons:
* No details of this order in MSA
* Job for this order already complete

Reasons why a Manifest file will not create Loads and Jobs:
* Site does not exist
* Manifest is a trunk.
* Jobs are of the wrong type.
* There are no valid products on the job.
* There are no valid jobs on a Load.

If there are issues processing, the whole file will be rejected and will need to be reprocessed. However, all data saved to that point will be present.

Audit records will be maintained, identifying successfully processed and failed import files, identifying the reason why a file failed to import.

It is possible for a manifest to generate multiple audit reasons when processing a file. All of these codes will be audited. Multiple audit records may be maintained per file, or a single audit record created with all details in it. This will be decided when developed, based on which method is a more generic solution for the C-ePOD product.

Rejected files will be emailed (depending on configuration) and will be stored in the standard Failed files location, as the processes do now.

{{Note}} The process generating the email will be modified to include the auditing of the file.

When a file is reprocessed, this will over-write and update the existing data, as specified in the processing below.

The processing of each file will proceed as follows:
* Retrieve Manifest files.
* Filter and validate the manifest file.
* Create User and Vehicle data.
* Create a new Load or combine to an existing Load.
* Create or update jobs on the load, through a link to the MSA view.
* Create or update products on the jobs.
* Remove any products from the job not contained in the manifest file.
* Remove any jobs from the load not contained in the manifest file.
These areas are covered in the following sections

=== Retrieve Manifest Files ===
For FILE transfer type, currently all files in the specified destination folder (EPL_XF_DESTINATION) are processed (using Directory.GetFiles). This will be modified so that, if a filename pattern is specified (in EPOD_XF_CONFIG.EPL_FILENAME), the process will only retrieve and process files matching this pattern (by passing a second parameter to the GetFiles method, specifying the pattern from EPOD_XF_CONFIG.EPL_FILENAME).

For FTP transfer type, the same is true, in that all files are retrieved (using ListDirectory in method GetFileList). No facility exists to pattern-match file names. Therefore the method GetFileList will be modified so that, if a filename pattern is specified (to be passed to an overloaded method in a new parameter, passing EPOD_XF_CONFIG.EPL_FILENAME), the process will only add these to the result if the filename returned matches the pattern provided.

Regardless of whether the file was retrieved through FTP or from the filesystem, each file (representing a single manifest) will be passed to a new processing method to validate and process the contents and create jobs and products. The current process bases this on EPL_MSG_TYPE. This will be extended to check the EPL_XF_ID field - should this be "EBB", the new processing method will be called.

A file failing to process will not stop subsequent files from processing. However, if the MSA view cannot be connected to, processing will stop (see section Create Jobs for details on the MSA View connection).

=== Validate the Manifest ===
This process will receive the manifest contents as an XML file. This file will be downloaded before processing to ensure that all characters that should have been URL encoded have been. The file will be pre-parsed to remove any non printable characters.

The '''depot''' tag will be extracted from the '''manifest/header''' tag contents. The site will be retrieved using the EPL_EXT_FLEET field. If a site is not found with a fleet matching the '''depot''' tag, the manifest will not be processed. {{Note}} This is not an error and will not be audited as such - the manifest will be marked as successfully processed.

The site retrieved will be stored by the process in an EPOD_SITE DAL object.

The '''trailer''' tag will be extracted from '''manifest/header''' tag contents. If this tag starts with the text "TRUNK", then this manifest will not be processed.

=== Create Vehicles and Users ===
The '''driver''' tag will be extracted from the '''manifest/header''' tag contents.

If this driver is set to "WAREHOUSE", the user ID will be created as this value.

If this is a non-zero value that is not explicitly "WAREHOUSE", C-ePOD will attempt to create the driver ID (if configured to do so) as the first character of the first name, and up to the first 4 characters of the surname, with a 3-digit unique identifier added to them. The case will be converted to uppercase.

For example:
* "David Eastman" will become "DEAST001"
* "SMITH JOHN" will become "SJOHN001"
* "DEREK MAY" will become "DMAY001"
* "TRUNKER M25". TRUNKER M25 will become "TM25001"

The process will attempt to find this user using the Site ID and the generated User ID above. If a record is found, the process will compare the user name in the XML file to the user name on the database. If different, the 3-digit id will be incremented by 1 and the process repeated until a matching EPOD_USER record is found, or one is not found for this ID.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_USER record is not found, the file should be rejected. An audit record of "User X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_USER record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_USER_ID || either "WAREHOUSE", or as generated above
|-
|EPL_USER_PASSWORD || set to the same value as the user ID
|-
|EPL_USER_NAME || '''driver'''
|-
|EPL_USER_ADMIN || "N"
|-
|EPL_USER_ACTIVE || "Y"
|-
|EPL_USER_ACTIVITY_DATE || 0
|-
|EPL_USER_ACTIVITY_TIME || 0
|-
|EPL_PASSWORD_VISIBLE_IND || 1
|}

The '''vehiclereg''' tag will be extracted from the '''manifest/header''' tag contents. If this is a non-zero value, C-ePOD will attempt to create the driver ID (if configured to do so).

The process will attempt to find this vehicle using the Site ID and the Vehicle ID as the Vehicle Reg above. If a record is found, this will be stored by the process as EPOD_VEHICLE.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_VEHICLE record is not found, the file should be rejected. An audit record of "Vehicle X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_VEHICLE record will be created and updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_VEHICLE_ID || '''vehiclereg'''
|-
|EPL_VEHICLE_REG || '''vehiclereg'''
|-
|EPL_DESCRIPTION || '''vehiclereg'''
|-
|EPL_STATUS || "Y"
|}

{{Note}} Data created on these tables will be truncated. Comparisons to this data as described above with be truncated before comparison, in case the data is space-filled in the XML file.

=== Create a Load ===
A load will be attempted to be found using the following data, providing that at least a vehicle or user has been provided:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_LOAD_START_PLANNED_DATE - '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
* EPL_VEHICLE_ID - EPOD_VEHICLE.EPL_VEHICLE_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_USER_ID - EPOD_USER.EPOD_USER_ID if one is present, otherwise this is not set as an parameter for the selection.
* EPL_STATUS - Not equal to "C" "X" if the '''driver''' attribute is not explicitly set to "WAREHOUSE", otherwise this is not set as an parameter for the selection.

If one is not found, a new load will be created on EPOD_LOAD as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID ||EPOD_SITE.EPL_SITE_ID
|-
|EPL_LOAD_ID || generated by the EPOD system.
|-
|EPL_LOAD_START_PLANNED_DATE || extracted from the '''deliverydate''' tag. Note that this value must be reformatted to YYYYMMDD format from DD-MM-YYYY format.
|-
|EPL_LOAD_START_PLANNED_TIME || extracted from the '''starttime''' tag. Note that this value must be reformatted (removing the embedded colon character and adding "0000" to the end. Note that if this tag is not present or blank, this field should be set to 6000000.
|-
|EPL_LOAD_END_PLANNED_DATE || as the Load Start Planned Date.
|-
|EPL_LOAD_END_PLANNED_TIME || 0
|-
|EPL_VEHICLE_ID || EPOD_VEHICLE.EPL_VEHICLE_ID
|-
|EPL_USER_ID || EPOD_VEHICLE.EPL_USER_ID
|-
|EPL_STATUS || "P"
|-
|EPL_LOAD_INFORMATION || the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
|}

If a load is found and the manifest is ''not'' for desk collection (i.e. where the '''driver''' tag value is not explicitly "WAREHOUSE"), the status (EPL_STATUS) should be checked. If this value is not "P" then the file should be rejected. An audit record of "Load X at wrong status" shall be created.

If a load is found, the Load Information field EPL_LOAD_INFORMATION should be checked that it contains the text built from:
* the ''number'' attribute of the '''manifest''' tag concatenated with the '''addinstruct''' tag, delimited by a dash.
If it does not contain this, this should be added to the text already in the field, delimited by a newline character.

The load (found or created) should be stored in an EPOD_LOAD object and updated.

=== Create Jobs ===
The process will find and store the highest sequence of any jobs already attached to the EPOD_LOAD object, by checking the content of the EPOD_JOBS list on the EPOD_LOAD object.

The process will extract the list of allowed order prefixes from the EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES field. {{Note}} If this parameter is empty, all orders will be processed.

The process will loop through all instances of the '''order''' tag in the ''manifest/data'' tag. Note that this is separated by a '''customer''' tag.

Each '''order''' tag will be processed to create EPOD_JOB records, which will be added to the EPOD_LOAD.EPOD_JOBS list.

The ''sopnumber'' attribute of the '''order''' tag will be extracted. if the attribute does not exist or has no value, this tag may be skipped.

The trimmed attribute value will be checked to see whether the value begins with any of the allowed order prefixes. If it does not, then then the order will not be processed.

A connection will be made to the MSA database for the order details. This will be achieved by opening a connection using the connection information stored in EPOD_XF_CONFIG.EPL_DB_CONNECTION. The connection should be attempted several times (for example, 3 times). If a connection cannot be made, then the file should be rejected. An audit record of "Order X: Cannot connect to MSA" shall be created. {{Note}} As this is a fundamental requirement of the process, should this fail, processing of this file ''and all others'' should be terminated for this run.

The connection details will be specified in a connection string in EPOD_XF_CONFIG.EPL_DB_CONNECTION.

{{Note}} At this time, the following information has not yet been confirmed.
* Connection details (IP, user, password, port)
* Database type
* View name

{{Note}} This MSA view is used from this point onwards for all details. Should the connection fail when attempting to retrieve subsequent records from the MSA view, the connection should be attempted to be re-established, again retrying several times, to ensure that this process is predominantly uninterrupted.

In the instance where the connection fails, the file need not be rejected and moved to the Failure area - it can be left to be reprocessed immediately on the next run.

When the connection is established, the details of the order will be retrieved from the MSA view using a standard SQL query, querying on the SOP Number.

Should the view return no details, then the order will not be processed. An audit record of "Order X: No details in MSA" shall be created. The process will continue with the next order in the XML file.

The Load will be checked to see whether the order already exists - the process will look for the order in EPOD_LOAD.EPOD_JOBS, where the job code (EPL_JOB_CODE_ is equal to the trimmed value of the '''sopnumber''' tag. If an order is found, an EPOD_JOB object will be created and set to the value of the job in the EPOD_LOAD.EPOD_JOBS EPOD_JOB object by reference.

If the job found is already complete (EPL_STATUS = "C"), then the process will skip updating this order. An audit record of "Order X: already complete" shall be created. The process will continue with the next order in the XML file.

If a job is not found, a new job will be created using the key values:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_LOAD_ID - EPOD_LOAD.EPL_LOAD_ID.
* EPL_JOB_TYPE - If the left 3 characters of the '''sopnumber''' tag are "RTN", set this value to "C", otherwise set this value to "D".
* EPL_JOB_CODE - the trimmed value of the '''sopnumber''' tag.
A value in EPL_JOB_ID will be generated for this job at this stage.

The Job Group should be calculated as follows:
* If the EPL_JOB_TYPE is "C", set to "COL"
* else if EPOD_LOAD.EPL_USER_ID = "WAREHOUSE", set to "DESK"
* else set to "DEL"

The process will attempt to find this Job Group using:
* EPL_SITE_ID - EPOD_LOAD.EPL_SITE_ID.
* EPL_JOB_GROUP - as set above.
If a record is found, this will be stored by the process as an EPOD_JOB_GROUPS DAL object.

Check the EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG. If this is set to "N" and an EPOD_JOB_GROUPS record is not found, the file should be rejected. An audit record of "Job Group X Not Found" shall be created.

If one is not found and EPOD_SITE.EPL_IMPORT_CREATE_SD_FLAG is "Y", the EPOD_JOB_GROUPS record will be created as follows:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_JOB_GROUP - as set above.
* EPL_DESCRIPTION:
** If EPL_JOB_GROUP is "COL", set to "Collections".
** If EPL_JOB_GROUP is "DEL", set to "Deliveries".
** If EPL_JOB_GROUP is "DESK", set to "Desk Collections".
All flags will be set as their default values.

The customer code, invoice address and contact information will be retrieved from the MSA view. The customer code will be checked as to whether it is already created in the system, by checking for an EPOD_CUSTOMER record using the keys:
* EPL_SITE_ID - EPOD_SITE.EPL_SITE_ID
* EPL_CUSTOMER_CODE - column CUSTNMBR from the MSA view.

If this record does not exist, or a record does exist but the details are different, the record will be updated as follows:
If one is not found, a new customer will be created on EPOD_CUSTOMER as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_CUSTOMER_CODE || CUSTNMBR
|-
|EPL_CUSTOMER_NAME || CUSTNAME
|-
|EPL_ADDRESS_1 || InvAdd1
|-
|EPL_ADDRESS_2 || InvAdd2
|-
|EPL_ADDRESS_3 || InvAdd3
|-
|EPL_ADDRESS_4 || InvCity
|-
|EPL_ADDRESS_5 || InvState
|-
|EPL_POSTCODE || InvZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

The delivery address and contact information will then be compared to this Invoice address, comparing the following items:
* EPL_CUSTOMER_NAME - DelName
* EPL_ADDRESS_1 - DelAdd1
* EPL_ADDRESS_2 - DelAdd2
* EPL_ADDRESS_3 - DelAdd3
* EPL_ADDRESS_4 - DelCity
* EPL_ADDRESS_5 - DelState
* EPL_POSTCODE - DelZip

If any of the values are different, a Job Address will be created through an EPOD_JOB_ADDRESS DAL object, populated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_SITE.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_JOB_TYPE || EPOD_JOB.EPL_JOB_TYPE
|-
|EPL_NAME || DelName
|-
|EPL_ADDRESS_1 || DelAdd1
|-
|EPL_ADDRESS_2 || DelAdd2
|-
|EPL_ADDRESS_3 || DelAdd3
|-
|EPL_ADDRESS_4 || DelCity
|-
|EPL_ADDRESS_5 || DelState
|-
|EPL_POSTCODE || DelZip (Spaces removed and truncated to 8 characters)
|}

{{Note}} All values above are leading/trailing space trimmed unless otherwise stated.

If this is not the first job being processed for the load, the process will check whether the job being created is not the first job being created for the customer code in this manifest. If this is not a subsequent job for this customer code, blank any stored values for the following fields:
* EPL_SEQUENCE
* EPL_LINKED_ID

If this is not a subsequent job for this customer code, the process will then loop through existing jobs in EPOD_LOAD.EPOD_JOBS in reverse sequence, looking for any job that matches as follows:
* EPL_CUSTOMER_CODE is the same
* EPL_STATUS not "C" or "X"
* EPL_JOB_TYPE is the same as the job being created.
* The delivery address is the same as the job being created.

If a match is found, check the value of the field EPL_LINKED_ID. If there is no value, set this to the value in the record's EPL_SEQUENCE field and update the object. The process will then store the values in the following fields:
* EPL_SEQUENCE - EPL_SEQUENCE of the job found
* EPL_LINKED_ID - EPL_LINKED_ID of the job found

The EPOD_JOB object will then be updated with the values as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_JOB_GROUP || The calculated Job Group above
|-
|EPL_JOB_INSTRUCTION || Manifest No (manfest), Order comments (OrdComm) and Delivery Instructions (DelIns) concatenated together with a space separator.
|-
|EPL_STATUS || "P"
|-
|EPL_CUSTOMER_CODE || The customer code (CUSTNMBR).
|-
|EPL_SEQUENCE || Stored value of EPL_SEQUENCE if there is one, or the maximum value of sequences of jobs on this load, plus 1.
|-
|EPL_START_PLANNED_DATE || ReqShipDate
|-
|EPL_START_PLANNED_TIME || StartTime if populated, else 06000000 (06:00)
|-
|EPL_END_PLANNED_DATE || ReqShipDate
|-
|EPL_END_PLANNED_TIME || DelTime if populated, else FinishTime if populated, else 14000000 (14:00).
|-
|EPL_JOB_CODE || the trimmed value of the '''sopnumber''' tag.
|-
|EPL_CUST_REF ||  
|-
|EPL_OFFICE_INSTRUCTION || tcsFLST_Route
|-
|EPL_SO_NUMBER ||  
|-
|EPL_ORDER_DATE || CREATDDT
|-
|EPL_SALES_CONTACT || UserID
|-
|EPL_OWNER_NAME || The sales territory (SALSTERR)
|-
|EPL_EXT_REF || The manifest (extracted from the ''number'' attribute of the '''manifest''' tag)
|-
|EPL_ACCOUNT ||  
|-
|EPL_LINKED_ID || Stored value of EPL_LINKED_ID if there is one.
|-
|EPL_TIMEZONE ||  
|-
|EPL_LOAD_LOCATION || Originating Depot
|-
|EPL_TTM_STOP_NUMBER || Set to the value in EPL_SEQUENCE
|}

{{Note}} that if updating a job at EPL_STATUS of "X", any existing products/containers associated with this job will also be reset to pending status.

The process will then store the following:
* EPL_CUSTOMER_CODE - the Customer code last processed in this manifest file.
* EPL_SEQUENCE - EPL_SEQUENCE of the job created
* EPL_LINKED_ID - EPL_LINKED_ID of the job created

The job will be updated and saved at this point.

The Job ID of the job created will be added to a comma-delimited string of jobs processed for this manifest.

=== Create Products ===
The process will loop through each record from MSA view, in order to create the product lines. {{Note}} All lines in the MSA view detail product information, including the first line.

The value in UOFM field of the MSA view will be looked up against the EPOD_REASON_CODE table matching the following parameters:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM

If a record is not found, create an EPOD_PRODUCT DAL object with values set as follows:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_REASON_CODE - UOFM
* EPL_DESCRIPTION - UOFM
* EPL_CONV_TYPE - "MULTIPLY"
* EPL_CONV_VALUE - 1000
* EPL_CONV_CODE - ""
Update this UOM code.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "EXCLUDE", this product will not be added - the process will move to the next record in the MSA view.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "MULTIPLY", multiply the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "ROUND", round the value in the QUANTITY field of the MSA view by the value stored in EPL_CONV_VALUE and store as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_TYPE is "DEFAULT", store the value in the QUANTITY field of the MSA view as the quantity.

If the value of EPOD_PRODUCT.EPL_CONV_CODE has a valid value, store the EPL_CONV_CODE as the UOM.

If the value of EPOD_PRODUCT.EPL_CONV_CODE is blank or null, store the UOFM field from the MSA view as the UOM.

The process will check to see if a product already exists on the job by checking the EPOD_JOB.EPOD_PRODUCTS list for an object with the following values:
* EPL_SITE_ID - EPOD_JOB.EPL_SITE_ID
* EPL_JOB_ID - EPOD_JOB.EPL_JOB_ID
* EPL_CONTAINER_ID - "000000000000000" (15 zeroes in a string, denoting a loose product)
* EPL_PRODUCT_CODE - ITEMNMBR
* EPL_SEQUENCE - linenumber/16384 (first 4 characters of this if not a whole number)

Note that ITEMNMBR and ITEMDESC may contain control characters not compatible with the EPOD device software. These should be stripped out before saving into the EPOD database.

If one is not found, an EPOD_PRODUCT object will be created and added to the EPOD_JOB.EPOD_PRODUCTS list.

If one is found or created above, an EPOD_PRODUCT object will be pointed to this object by reference.

The EPOD_PRODUCT object (found or created) will have the fields updated as follows:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Field !!Populated by
|-
|EPL_SITE_ID || EPOD_JOB.EPL_SITE_ID
|-
|EPL_JOB_ID || EPOD_JOB.EPL_JOB_ID
|-
|EPL_CONTAINER_ID || "000000000000000"
|-
|EPL_PRODUCT_CODE || ITEMNMBR
|-
|EPL_SEQUENCE || linenumber/16384 (first 4 characters of this if not a whole number)
|-
|EPL_DESCRIPTION || ITEMDESC, truncated to 40 characters
|-
|EPL_PRODUCT_QTY_PLANNED || The quantity calculated and stored above
|-
|EPL_PRODUCT_QTY_CASE || SellPack if populated and numeric, else 0.
|-
|EPL_STATUS || "P"
|-
|EPL_PRODUCT_WEIGHT || ITEMSHWT
|-
|EPL_CUST_REF || CustordNo
|-
|EPL_ITEM_TYPE ||
|-
|EPL_UNIT_TYPE || The UOM stored above.
|-
|EPL_DESCRIPTION_LONG || ITEMDESC and ebbFLTX_Sales_Comments concatenated with CR/LF characters.
|-
|EPL_PRODUCT_QTY_ORDERED || Set to the same value as EPL_PRODUCT_QTY_PLANNED
|}

The product record on EPOD_PRODUCT will then be updated.

The Product Code of the product created will be added to a comma-delimited string of products processed for this job.

=== Remove Products not on the Job ===
All subsequent records on the MSA view will be processed in this manner and stored on the job.

When all products are processed, the process will check through all products on the job and compare to the list of products processed on this manifest for this job. Any products on the job but not in the manifest will be deleted.

If, after this, there are no products on the job, the job will be deleted. An audit record of "No Products on Order X - order deleted" shall be created.

=== Remove Jobs not on the Load for that Manifest ===
All subsequent order tags in the Manifest will be processed in this manner and stored on the load.

When all orders on the manifest are processed, the process will check through all jobs on the load (with that Manifest number, as stored in EPL_EXT_REF) and compare to the list of jobs processed on this manifest. Any jobs for this manifest on the load but not in the manifest will be deleted.

If, after this, there are no jobs on the load, the load will be deleted. An audit record of "No Jobs on Load X - load deleted" shall be created.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the new EBB paper interface can be configured and works as expected.
|MenuAccess=N/A
|Prerequisites=A system configured as EBB Paper.
|Objective=To test that: UOMs may be entered with conversion types; the EBB Paper interface may be configured and; the EBB paper interface works as expected.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin
|Notes= 
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new Interface type as expected for EBB Paper.
|Result=The new EBB Paper interface can be configured and edited as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a new reason code. Select type "UOM".
|Result=Type UOM can be selected from the drop-down list. The Conversion fields are displayed and defaulted as expected.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select Conversion Type "Round" and "Multiply".
|Result=A Value may be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code. Select other Conversion Types.
|Result=A Value may not be entered.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Save the code. Enter another code with an Xref code and conversion type "As Received".
|Result=The XRef code is entered and saved.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Find all UOM codes.
|Result=UOM can be selected as a filter element. All UOM codes are displayed.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Edit UOM codes.
|Result=The codes are displayed as they were entered. The Conversion fields are displayed as expected.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Interface
|Notes=Set up the site to NOT create standing data. Configure the interface for FTP file transfer. Configure the MSA connection to be incorrect.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create valid manifest files in the configured FTP area, one named "Manifest_test1.xml" and one named "incorrect.xml". Both should have a user that does not match an existing vehicle. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid user. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change the interface configuration to FILE transfer type. Create valid manifest files in the configured FILE area, one named "Manifest_test2.xml" and one named "incorrect.xml". Both should have a vehicle that does not match an existing vehicle, but with a valid user. Run the import process.
|Result=Only the manifest matching the filename is processed. This is rejected for an invalid vehicle. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest (any transfer method) with a valid user and vehicle, with job groups not created.
|Result=The file is rejected for invalid job group. The file is placed in a Failed directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the system to create standing data. Create two valid (but different) manifests, with a user and vehicle that does not match any existing data. Ensure there is a valid job with at least one valid product.
|Result=The first file is processed and rejected due to being unable to connect to MSA. The second file is not processed at all.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Configure the interface with the correct MSA view connection details. Process the manifests above again.
|Result=The files are processed without errors. The Vehicle is created. The Users is created. The Job Group is created. The Customer is created. The Load is created. The Job is created. The products are created. The file is audited as processed successfully. The file is placed in a Success directory.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest almost identical to the last manifest, but with different Load start time, Job Start time, product quantities. Ensure the invoice address is changed. Ensure that there are comments on the Manifest. Process the manifest.
|Result=The load, job and products are updated. The manifest comments are appended to the Load Instructions. The invoice (customer) address is updated.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with one valid sopnumber, and all others as invalid SOP numbers. Ensure the valid order is not for the same customer as the prior manifest. Process the manifest.
|Result=A job is created on the load for the one valid order. All others are not processed. The job is sequenced after all others
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with an order with a valid INV sopnumber. Ensure the order is for the same customer as the first manifest. Process the manifest.
|Result=A job is created on the load for the order. The job is sequenced and linked to the matching job from the first manifest.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID as the existing INV job on the load for this customer.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for the same date, vehicle and user, with orders with a valid sopnumber with the same customer code as the last manifest. Ensure two are RTN jobs and two are INV jobs. Ensure the delivery address is different to the invoice address. Process the manifest.
|Result=Jobs are created on the load for the orders. The jobs are correctly identified as Collection and Delivery jobs, with the correct Job Group. The jobs are sequenced after any existing jobs on the load. The RTN jobs will have the same sequence and linked ID. The INV jobs will have the same sequence and linked ID. No jobs will be linked to existing jobs on the manifest. The Job Address is created for these loads.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a manifest for a different date, vehicle and user, with orders with valid sopnumbers, for many customers. Ensure that they have a mix of UOMs configured with Round, Multiply, As Received, Exclude and Xref Code conversions, as well as a product without a configured UOM.
|Result=The jobs and products are created as expected. The Exclude product is not created. The quantities are set as per the conversion type rules. The unknown UOM is created with default values.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process the same manifest file.
|Result=The manifest is rejected for invalid load status.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a DESK COLLECT manifest with a user of "WAREHOUSE"
|Result=A load is created. The user is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete or cancel the load created. Process another DESK COLLECT manifest file.
|Result=A new load is created.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Process a manifest with a job with no valid products.
|Result=The file is processed successfully. Audit history is recorded as the job having no products, and the load having no jobs.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[REQ 343463 EBB Paper Solution Design]]
|RefV1=2.0
|RefDate1=01/08/2017
|EREQ=0
|EEST=0
|EFS=2.5
|ETS=0
|EDEV=15.5
|ESTT=3.50
|EIMP=1.25
|EPM=1.5
|REQ=0
|EST=0
|FS=0.0
|TS=0
|DEV=5
|ST=0.0
|IMP=0.0
|PM=0.0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Rebecca Elliott
|Rev2Title=EBB Paper Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 318517 SCR22 NHSBT C-EPOD Hospital Own Transport

2014-09-22T11:36:43Z

AppaduN: Minor corrections

<div class="noprint">
{{#vardefine:Client|NHS}}
{{#vardefine:ClientName|NHSBT}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Hospital Own Transport}}
{{#vardefine:Version|0.5}}
{{#vardefine:Date|22nd July 2014}}
{{#vardefine:Reference|318517 SCR22}}
{{#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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==

The following changes from the Solution Design document are included in this specification:
* '''SCR-316403-05''' - Hospital Own Transport
: EPOD Scanning at handover at Depot and delivery into depot from 3rd-party carriers and Hospital Own Transport - Configured via CTMS. This needs to include empties and samples collected from hospitals and all items collected from sessions by TNT. EPOD application development

== Solution Overview ==
In detail, the following C-EPOD execution functionality was requested:

The process for Hospital Own Transport deliveries is as follows:
* Hospital Services will scan all tags to Assets, as normal.
* These jobs will be planned onto a Trip assigned to a hospital-related user (i.e. one per hospital or depot), for the carrier "Hospital Own Transport". The Resource Allocation functionality will assist in choosing an available "driver". The trip will be allocated a vehicle (it is suggested only one vehicle is created and this same one is used for all trips for this carrier) and set to Accepted.
* When giving the jobs to Hospital Own Transport, Hospital Services will log on to the C-EPOD device and select the Job that the user is picking up. C-EPOD will be configured to allow users to select any job out of sequence.
* Hospital Services will scan to complete this collection, via the Asset tags. If there are any Buff Tags that have not been scanned to Assets, the device will make this known at this time.
* Once all items have been scanned, Hospital Services will obtain the driver's name and Signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* No scanning or user entry is required for the delivery job - this will be automatically completed with the collection job.

Hospital Own Transport will be bringing samples and/or empty Assets into the network themselves. It was requested that the C-EPOD device prompt the user at the end of the collection if there is anything additional to collect from Hospital Own Transport. This is an Ad Hoc Delivery and is currently unsupported by C-EPOD. This should be completed via the manual Debrief screen in C-TMS.

Assets may be manually marked as in the depot by:
* Manually adding an order and adding the assets or samples to the order before confirming the job completed.
* Using the Asset Maintenance screen
* Waiting until they are scanned again for Tag to Asset (for deliveries) or Ad Hoc Collection later.

To complete this manually (i.e. without C-EPOD), the following steps would be taken:
* If offered and accepted, C-TMS should be used to create a planned, empty collection from the hospital back to the depot, and assign this to the trip on which the Delivery is being completed.
* When the carrier returns with assets or samples, these can then be actioned as with Hospital Own Transport above.

The process for 3rd-party Carrier deliveries is as follows:
* Hospital Services will scan all tags to Assets, as normal.
* These jobs will be planned as per the normal process (i.e. sent through the DPS interface or manually planned) onto a Trip and then assigned to a driver code (using resource allocation), for the specific 3rd-party Carrier. Default driver codes may be created, for example, "TNT1", "TNT2", etc. The Resource Allocation functionality will assist in choosing an available "driver". The trip will be allocated a vehicle (it is suggested only one vehicle is created and this same one is used for all trips for this carrier) and set to Accepted.
* When giving the items for the jobs to the carrier, Hospital Services will log on to the C-EPOD device with the correct user (the driver code) and select the Job that the carrier is picking up. C-EPOD will be configured to allow users to select any job out of sequence.
* Hospital Services will scan to complete this collection, via the Asset tags. If there are any Buff Tags that have not been scanned to Assets, the device will make this known at this time.
* Once all items have been scanned, Hospital Services will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* No scanning is required for the delivery job - the debrief will be manually completed when the 3rd-party carrier returns the completed POD documentation.

3rd-party Carriers may be offered the option of a return leg to the depot, to bring back any planned (e.g. sample) or unplanned items (e.g. empty assets). 3rd-party Carriers are also regularly used for Session collections.

The process for 3rd-party Carrier returns to depot is as follows:
* The return order (the order to collect at the hospital and return items to the depot) will be created and planned on the trip above, which will have been allocated to the TNT 'driver' above.
* When the TNT driver returns to the depot with the collected goods, a user (transport or hospital services) will obtain the paperwork, retrieve the trip that the driver is completing and find out the TNT user. This can be through many different methods, the easiest being:
** Through the C-TMS Waterfall screen, if the user has access to C-TMS.
** Through the C-EPOD Admin Loads or Users screen, if the user has access to C-EPOD.
** Through the C-Portal Arrive/Depart (Airport) screen, if the user has access to C-Portal, or the C-Portal Airport screen is displayed in transport and/or hospital services.
* The user will log in to the C-EPOD device using this TNT driver and select the order from the list.
* The user will scan any preadvised items for delivery (e.g. Samples) and use a new "Ad Hoc Delivery" process to scan any other items brought in by the TNT driver (e.g. unplanned samples, returned assets, etc). If the TNT driver was planned to collect from multiple hospitals, the process will request the user to enter the hospital from which the items were collected. If single trip are scanned, the process will request the user to identify the asset type.
* Once all items have been scanned, Hospital Services will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* The TNT paperwork will then be used to manually debrief the collection from the various hospitals.

The process for 3rd-party Carrier Session collections is as follows:
* For sessions, these will already have an order and will be planned on a trip. This will have been set to TNT carrier, resourced (allocated to a TNT driver code and vehicle) and set to status Accepted.
* When the TNT driver returns to the depot with the collected goods, a user will obtain the paperwork, retrieve the trip (as above) and find out the TNT driver code assigned to the trip.
* The user will log in to the C-EPOD device using this TNT driver code and select the order from the list.
* The user will use a new "Ad Hoc Delivery" process to scan any items brought in by the TNT driver (e.g. polar bags of blood, document packs, returned assets, etc). If the TNT driver was planned to collect from multiple sessions, the process will request the user to enter the session location from which the items were collected. If single trip labels are scanned, the process will request the user to identify the asset type.
* Once all items have been scanned, the user will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* The TNT paperwork will then be used to manually debrief the collection from the various sessions.

== Scope ==
{{Note|This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.}}
{{Note|This functionality is dependent on FS 317761 SCR15 C-EPOD Collection Changes.}}
{{Note|This functionality informs on and is informed by FS 317907 SCR01 C-TMS-C-EPOD Interface.}}
{{Note|Although it is possible with this solution to combine several trips together onto one trip, for ease of use on the C-EPOD device, rather than planning accurately as described above, this is not recommended for the following reasons:
* Individual PO cost will not be able to be calculated per trip, only for the trip as planned (i.e. all combined)
* Consolidation of jobs together at the depot (to provide a single loading task) may compromise the use of the C-EPOD application, if several distinct jobs are to be collected by different TNT drivers within the same collection or delivery timeframe, as these will be consolidated together.
* Mitigation of the above (i.e. turning off consolidation) would be impractical, as this would result in instructions to load assets multiple times (once for each job with contents in the asset), as the system has been instructed not to consolidate.
}}


= Set-up =

== Pre-requisites ==
* A working {{#var:System}} system.

=== C-TMS Interface Changes ===
* C-EPOD Configuration per Carrier, at certain location types. Broadly, this would be configured to send tasks to C-EPOD at depots, not at customer locations (hospitals), specifying a different job group.
* For HOT, Delivery jobs out to the hospital will not be sent to C-EPOD. The collections (loading) at the depot will, however.
* For 3PC, Delivery and Collection jobs at the hospital will not be sent to C-EPOD. Collections (loading) and Deliveries (unloading) at the depot will, however.
* These unloading jobs at the depot will include the 'from' address information.
* A configuration flag will be held against the carrier type, to indicate this sending of information.
* Configuration flags will also be created and held against the carrier, to control whether the paired jobs are automatically completed (i.e. HOT deliveries to hospital) or not (i.e. TNT deliveries that will be manually debriefed later from the paperwork returned).

== Menu Structure ==
None

== Data ==
* A site record will be created for each 3rd-party carrier or for a single hospital own transport carrier.
* The standard Job Groups will
* Only one vehicle per site will be created.
* No vehicle checks are required.
* Multiple drivers will be created for the 3rd-party Carrier, to allow multiple trips to be actioned per day.
* Multiple drivers will be created for the Hospital Own Transport, one per hospital or depot.
* The jobs group created for other carriers will also be created for these sites and be configured similarly, except for:
** allow drivers to select any incoming job from the job list.
** prompt for signature on collections and deliveries.


= Functional Description =
== Database/DAL changes ==
* New flag Ad Hoc Delivery
Table EPOD_SITE requires the following modifications:
* EPL_AD_HOC_DELIVERY - 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>
''<EPL_AD_HOC_DELIVERY></EPL_AD_HOC_DELIVERY>''
</EPOD_SITE>

Table EPOD_JOB_GROUP requires the following modification:
* EPL_AD_HOC_DELIVERY - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.

Existing packages will be modified to allow the creating, editing and selecting of the new flag, including but not limited to:
* EPOD_JOB_GROUP_INSERT
* EPOD_JOB_GROUP_SEARCH
* EPOD_JOB_GROUP_SELECT
* EPOD_JOB_GROUP_SELECT_UPDATED_DATA
* EPOD_JOB_GROUP_UPDATE

The existing EPOD_JOB_GROUP DAL object will be changed to:
* Export the new flag in XML requests
* Read the new flag

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

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

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

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

== Import/Export Messages ==
The PDA web request server (Calidus_ePOD.asmx, both the XML and JSON versions) will be modified to include the new Site and Job Group flags in the LOGON_REQUEST message processor (through the LOGON_RESPONSE message).

== Admin Changes ==
The Job Group and Site maintenance screens (job_group.aspx and site_header.aspx respectively) will be modified to allow the system to be configured for:
* EPL_AD_HOC_DELIVERY, a checkbox, labelled as "AD Hoc Delivery", defaulting to 'N' (Disabled).
This configuration field will be added to the PDA tab of these screens.

{{Note}} Ensure that the new check-boxes line up with the existing fields.

== PDA Changes ==
=== Database/DAL changes ===
A new column will be added to the EPOD_SITE and EPOD_JOB_GROUP tables:
* EPL_AD_HOC_DELIVERY - This will be a one character field with of Values 'Y' and 'N'. The default value is 'N'.
This new field should be added to every procedure as part of the PDA_SITE and PDA_JOB_GROUP DAL objects.

=== Login ===
{{Note}} No changes are required to the Login process - this section described how the process will work when configured as described.

The device will be configured for the Carrier (i.e. TNT or the hospital) as the site.

The transport user will log on using the carrier driver assigned to the trip (either found through C-TMS or preset to a single default value), select the default vehicle and enter the password.

This will retrieve the list of jobs on the load assigned to that user and display them on the job list.

=== Job List ===
{{Note}} No changes are required to the Job List process - this section described how the process will work when configured as described.

Only the jobs on the current trip will be shown. The Job List will be configured to allow the user to select any of the jobs on that load, and also to show all jobs singly (i.e. not consolidated together).

=== Delivery Process ===
When a Delivery job (i.e. in this case, a depot unloading task) is selected from the Job List and started from the Job Details form, the Delivery screen will show.

This will be modified to display the ''Ad Hoc'' tab in a similar way to the

{{Note}} The existing ''Items'' tab is there to show all preadvised items - unplanned delivery of items will be shown on a different tab (described later). The Items (Container) tab will only be shown if there are items preadvised for the jobs. If there are none, 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 deliver.
* The application is configured for Ad Hoc Delivery (new Job Group flag EPL_AD_HOC_DELIVERY is enabled).

When all preadvised items have been scanned as 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 delivery job, and the application has been configured for Ad Hoc Delivery (EPL_AD_HOC_DELIVERY is enabled). 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 Delivery process (in the next section).

=== Ad Hoc Delivery Tab ===
This tab will have functionality extremely similar to the Ad Hoc Collection tab - this functionality is re-stated here, with any exceptions noted.

The Ad Hoc Delivery process allows the driver to specify the items delivered, at the point of Delivery, without the specific items for those Deliveries being planned in advance. This appears as a separate tab on the PDA within the Delivery process, labelled as "Ad Hoc" when this feature is enabled (through the flag EPL_ADHOC_DELIVERY for Delivery-type jobs only). This tab will be to the right of the existing ''Containers'' and ''Products'' tabs, but before the ''Notes'' tab.

The layout of the tab will be almost identical to the existing ''Items (Containers)'' tab. The following are sample screen layouts for the features of the tab.

<gallery widths=260px heights=400px perrow=2 caption="Ad Hoc Delivery Prototype Screen-shots">
File:FS_317761_AdHoc1.PNG|''Unplanned item details''
File:FS_317761_AdHoc2.PNG|''Ad Hoc item list''
</gallery><br />

{{Note}} These are the Ad Hoc Collection prototype screenshots.

The tab will allow items to be entered in exactly the same way as the ''Items (Containers)'' tab:
* Through a "Scan Container" text box and '''Deliver''' button.
* Through the use of the built in Camera Scanner feature, through the '''Scan''' button.
Note that there is no method of entry through the table (i.e. pressing or long-pressing on the table row will show no ''Deliver'' option).

This table of items on the screen will start empty - as items are scanned, these will be added to the table. {{Note}} Developer Note: The table should be built to the same scrolling view mechanism as the Items (Container) table on that tab.

Like the ''Items (Containers)'' tab, this tab will only allow asset formats to be scanned in the formats detailed in the Scanning section - any invalid formats will be discarded with a transient message displayed on the screen.

The tab will check whether the scanned item is an item that has been preadvised for the job. If so, and the item has already been confirmed as received, a transient message will inform the driver "This item already scanned". If this preadvised item has not yet been scanned for Delivery, the tab will interrupt the scanning (if continuous scanning is enabled) and will display an alert "Ad Hoc Delivery"/"Preadvised items must be scanned on the Items tab". If this preadvised item has been marked as cancelled on the preadvised list, the tab will interrupt the scanning (if continuous scanning is enabled) and will display an alert "Ad Hoc Delivery"/"Preadvised item has been cancelled and cannot be delivered.".

The tab will check whether the scanned item has already been scanned by the Ad Hoc Delivery process. If so, a transient message will inform the driver "This item already scanned".

The different types of Asset will be dealt with differently:
* 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. These will simply be added directly to the table.
* Single Trip Assets must have an asset type entered.
Additionally, the application will check to see if this collection is part of a consolidation (multiple delivery jobs) with multiple collection destinations. Note that this is completed differently to the Ad Hoc Collection screen, in that the device will check for the address from the Alternate address sent to the device from the server, rather than from a linked job (that will not have been sent to C-EPOD from C-TMS). If the addresses found are different, then the driver must be prompted to enter a destination location.

After these checks are made on a scanned Item ID, and further entry is required, the application will stop the scanning process (if continuous scanning is in use) and display a pop-up data entry screen. This will have the following fields:
* Header label, showing the scanned Item ID.
* Location label and drop-down list. These will only be shown if there are multiple collection locations. If this is the case, the location names will be listed in a drop-down list, forcing the driver to select one. The default entry on the drop-down list will be "Select a Location".
* Type label and drop-down list. These will only be shown if the item scanned is a single-trip format Item ID. If this is the case, all DUs (Asset Types) will be displayed in a drop-down list, forcing the driver to select one. The default entry on the drop-down list will be "Select a Type". The list will be built from all DU-type codes on the Reason Codes table (EPL_DESCRIPTION from EPOD_REASON_CODE where EPL_REASON_TYPE = "DU").
* A '''Cancel''' button. When pressed, this closes the pop-up data entry screen. The scanned ID will be discarded and not added to the Ad Hoc Items list.
* A '''Save''' button. When pressed, this button will validate that all required data is entered. If not, the screen will display a pop-up alert showing the item that has not been entered ("Ad Hoc Additional Details"/"You must select a (Field)", where (Field) is replaced with the data type that has not been entered, i.e. "Type" or "Location"). When this alert is cleared, the user will be returned to the pop-up entry screen. If there are no errors found when clicking the '''Save''' button, the pop-up data entry screen will be closed and the item will be added to the Ad Hoc Items list.

If items have been scanned and need to be added to the list, they will be added as a new row on the EPOD_CONTAINER table, as follows:
* EPL_JOB_ID - This will be from the job being scanned. If there are consolidated jobs with the same (or linked) destinations, this will be the Job ID of the first job. If there are consolidated jobs with different destinations, this will be the Job ID of the job with the destination as selected by the driver in the pop-up details entry screen
* EPL_CONTAINER_ID - As scanned, minus the leading barcode application identifiers ("00" or "8004")
* EPL_CONTAINER_PACKAGE_CODE - If this is a permanent Asset barcode ("8004"), this will be left blank. If not, this will be the code of the asset type selected by the driver in the pop-up details entry screen (EPL_REASON_CODE).
* EPL_CONTAINER_PACKAGE_DESC - If this is a permanent Asset barcode ("8004"), this will be left blank. If not, this will be the description of the asset type selected by the driver in the pop-up details entry screen (EPL_DESCRIPTION).
* EPL_STATUS - "C"
* EPL_TYPE - "A", to indicate that this is an Ad Hoc Delivery
* EPL_SEQUENCE - Set as 3-digit numeric counting from 001, incrementing with each item added to this screen.
All other items will be blank or added as normal.

These records will be added as a new row at the top of the list, by retrieving all records in reverse sequence order (through the PDA_CONTAINER DAL function SelectAllContainersForJob with parameter p_blnAdHoc set to true). This will return only scanned Ad Hoc items, in reverse sequence. The details displayed will differ, depending on the information delivered:
* Item ID - EPL_CONTAINER_ID
* Type - EPL_CONTAINER_PACKAGE_DESC
* Location - EPL_CUSTOMER_NAME of EPOD_JOB

Pressing or long-pressing on an item in this Ad Hoc table will allow the driver to remove an item from the Delivery. The application will display a pop-up alert "Ad Hoc Delivery"/"Do you want to remove this item?" with options "Yes" and "No". Choosing "No" will leave the item on the list. Choosing "Yes" will delete the item from the scanned containers and refresh the list without this item.

A '''Complete''' button should be available on the ''Job Details'' tab, to allow the users to manually indicate that all items have now been delivered. 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 Delivery (and Ad Hoc Delivery 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 Delivery process and activate the ''Ad Hoc'' scanning tab.


= Appendix A: TEST PLAN =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test the C-EPOD changes made for NHSBT.
|MenuAccess=None
|Prerequisites=Data set up as per Data Setup section; Note that individual setup information is provided for each test area.
|Objective=To test that: Admin can view and maintain configuration for the changes; the EPOD Client application can perform Ad Hoc Deliveries.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{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 fields are present and can be set and maintained.
|Result=New fields can be set, changed and saved:
* New checkbox "Ad Hoc Delivery"
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 Job Group Maintenance screen. Ensure the new fields are present and can be set and maintained.
|Result=New fields can be set, changed and saved:
* New checkbox "Ad Hoc Delivery"
The tabs are well organised, making good use of space.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Ad Hoc Delivery.
|Notes=Create a load with several deliveries from hospitals and deliveries to the depot and assign to the carrier, user and vehicle. Ensure that there are planned items on some deliveries and deliveries.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Log in to the application and pick up the load.
|Result=The ''''Job List'''' is displayed:
* No deliveries at the hospitals should be shown.
* Deliveries to the depot should not be consolidated, and labelled as Unloading jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the second unloading job and start it at the Job Details page.
|Result=No error will be displayed; the job may be started and the delivery screen shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''.
|Result=The device checks for any changes to the jobs. When checked, the ''''Delivery'''' screen is displayed:
* There is a '''Complete''' button.
* There are 3 tabs: ''Job Details''; ''Items''; ''Ad Hoc''.
* The jobs are shown as "In Progress" in Admin.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click the '''Complete''' button.
|Result=An error should be displayed showing that there are still items awaiting scanning.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Items'' tab. Cancel one of the items and confirm the exception with a reason code.
|Result=The Items list is displayed with only one item on it.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Ad Hoc'' tab
|Result=The Items list is displayed (with nothing in it). The screen is laid out as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Using the provided text box, enter "invalid". Click ''Deliver''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "8004invalid". Click ''Deliver''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "00invalidlength". Click '''Deliver'''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "00invalidformat00000". Click '''Deliver'''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Type only. The type list should show all valid Asset types.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Type details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a type. Click '''Save'''
|Result=The item should be added to the list, showing the selected type. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Scan''' button.
|Result=A Scan reticule should be displayed, allowing barcodes to be scanned.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Repeat the item tests for invalid formats and items above ("invalid", "8004invalid", "00invalidlength", "00invalidformat00000")
|Result=Each time these items are scanned, a transient error should display, as previously. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan an invalid barcode type (for example, a CODE 39 or EAN-8 or EAN-13 barcode).
|Result=A transient error should display, showing that the format is invalid. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan the cancelled item from the planned items list.
|Result=The Scan reticule should be closed and the ''Ad Hoc'' tab be displayed, showing a pop-up error, saying that the item must not be Delivered, as it has already been cancelled.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Scan''' button. Scan the remaining planned item from the planned items list.
|Result=The Scan reticule should be closed and the ''Ad Hoc'' tab be displayed, showing a pop-up error, saying that the item must be Delivered through the Items tab.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Items'' tab and scan the item.
|Result=A transient message should be displayed, showing that the item has been Delivered. The Scan reticule should be closed and the ''Items'' tab be displayed, with no items on the Items list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Ad Hoc'' tab and scan the same item.
|Result=A transient message should be displayed, showing that the item has already been Delivered. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan an item that is already on the ''Ad Hoc'' items list.
|Result=A transient message should be displayed, showing that the item has already been Delivered. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Close the Scan reticule.
|Result=The ''Ad Hoc'' tab and Items list should be displayed, showing the items scanned, with the latest at the top.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click on the top item.
|Result=An alert should ask whether the item should be removed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''No'''.
|Result=The ''Ad Hoc'' tab and Items list should be displayed again, with item selected still on the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click on the top item. When prompted, click '''Yes'''.
|Result=The Items list should be displayed again. The item selected should be removed from the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Move to the ''Job Details'' tab and press the '''Complete''' button.
|Result=The signature should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the signature.
|Result=A transient message should display that the job is complete.
The jobs will be completed in Admin.
The Job list should be redisplayed.
The Unloading task will be removed from the Job List.
|Remarks=
|PassFail=

}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a trip with consolidated deliveries back to the depot, from different collection locations. Log in to the C-EPOD device, start the job and move to the ''Ad Hoc Items'' tab. Enter a valid permanent Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Location only. The Location list should show a list of all unique collection locations for the orders.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid permanent Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Location. Click '''Save'''
|Result=The item should be added to the list, showing the selected location. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid single trip Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Type and Location. The type list should show all valid Asset types. The Location list should show a list of all unique collection locations for the orders.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Type and Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a type. Click '''Save'''
|Result=An error should be displayed, asking for Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Location. Click '''Save'''
|Result=The item should be added to the list, showing the selected type and location. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{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= 
|RefDate2= 
|Ref3=FS 317761 SCR15 NHSBT C-EPOD Collection Changes
|RefV3=0.4
|RefDate3=04/06/2014
|REQ=0
|EST=0
|FS=0.75
|TS=0
|DEV=3
|ST=0.5
|IMP=0
|EREQ=0
|EEST=0
|EFS=0.75
|ETS=0
|EDEV=3
|ESTT=0.5
|EIMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Julie Scott
|Rev1Title=Project Manager
|Rev2=Ed Bond
|Rev2Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 318517 SCR22 NHSBT C-EPOD Hospital Own Transport

2014-09-22T11:33:47Z

AppaduN: Undo revision 1595 by AppaduN (talk)

<div class="noprint">
{{#vardefine:Client|NHS}}
{{#vardefine:ClientName|NHSBT}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Hospital Own Transport}}
{{#vardefine:Version|0.5}}
{{#vardefine:Date|22nd July 2014}}
{{#vardefine:Reference|318517 SCR22}}
{{#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}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==

The following changes from the Solution Design document are included in this specification:
* '''SCR-316403-05''' - Hospital Own Transport
: EPOD Scanning at handover at Depot and delivery into depot from 3rd-party carriers and Hospital Own Transport - Configured via CTMS. This needs to include empties and samples collected from hospitals and all items collected from sessions by TNT. EPOD application development

== Solution Overview ==
In detail, the following C-EPOD execution functionality was requested:

The process for Hospital Own Transport deliveries is as follows:
* Hospital Services will scan all tags to Assets, as normal.
* These jobs will be planned onto a Trip assigned to a hospital-related user (i.e. one per hospital or depot), for the carrier "Hospital Own Transport". The Resource Allocation functionality will assist in choosing an available "driver". The trip will be allocated a vehicle (it is suggested only one vehicle is created and this same one is used for all trips for this carrier) and set to Accepted.
* When giving the jobs to Hospital Own Transport, Hospital Services will log on to the C-EPOD device and select the Job that the user is picking up. C-EPOD will be configured to allow users to select any job out of sequence.
* Hospital Services will scan to complete this collection, via the Asset tags. If there are any Buff Tags that have not been scanned to Assets, the device will make this known at this time.
* Once all items have been scanned, Hospital Services will obtain the driver's name and Signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* No scanning or user entry is required for the delivery job - this will be automatically completed with the collection job.

Hospital Own Transport will be bringing samples and/or empty Assets into the network themselves. It was requested that the C-EPOD device prompt the user at the end of the collection if there is anything additional to collect from Hospital Own Transport. This is an Ad Hoc Delivery and is currently unsupported by C-EPOD. This should be completed via the manual Debrief screen in C-TMS.

Assets may be manually marked as in the depot by:
* Manually adding an order and adding the assets or samples to the order before confirming the job completed.
* Using the Asset Maintenance screen
* Waiting until they are scanned again for Tag to Asset (for deliveries) or Ad Hoc Collection later.

To complete this manually (i.e. without C-EPOD), the following steps would be taken:
* If offered and accepted, C-TMS should be used to create a planned, empty collection from the hospital back to the depot, and assign this to the trip on which the Delivery is being completed.
* When the carrier returns with assets or samples, these can then be actioned as with Hospital Own Transport above.

The process for 3rd-party Carrier deliveries is as follows:
* Hospital Services will scan all tags to Assets, as normal.
* These jobs will be planned as per the normal process (i.e. sent through the DPS interface or manually planned) onto a Trip and then assigned to a driver code (using resource allocation), for the specific 3rd-party Carrier. Default driver codes may be created, for example, "TNT1", "TNT2", etc. The Resource Allocation functionality will assist in choosing an available "driver". The trip will be allocated a vehicle (it is suggested only one vehicle is created and this same one is used for all trips for this carrier) and set to Accepted.
* When giving the items for the jobs to the carrier, Hospital Services will log on to the C-EPOD device with the correct user (the driver code) and select the Job that the carrier is picking up. C-EPOD will be configured to allow users to select any job out of sequence.
* Hospital Services will scan to complete this collection, via the Asset tags. If there are any Buff Tags that have not been scanned to Assets, the device will make this known at this time.
* Once all items have been scanned, Hospital Services will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* No scanning is required for the delivery job - the debrief will be manually completed when the 3rd-party carrier returns the completed POD documentation.

3rd-party Carriers may be offered the option of a return leg to the depot, to bring back any planned (e.g. sample) or unplanned items (e.g. empty assets). 3rd-party Carriers are also regularly used for Session collections.

The process for 3rd-party Carrier returns to depot is as follows:
* The return order (the order to collect at the hospital and return items to the depot) will be created and planned on the trip above, which will have been allocated to the TNT 'driver' above.
* When the TNT driver returns to the depot with the collected goods, a user (transport or hospital services) will obtain the paperwork, retrieve the trip that the driver is completing and find out the TNT user. This can be through many different methods, the easiest being:
** Through the C-TMS Waterfall screen, if the user has access to C-TMS.
** Through the C-EPOD Admin Loads or Users screen, if the user has access to C-EPOD.
** Through the C-Portal Arrive/Depart (Airport) screen, if the user has access to C-Portal, or the C-Portal Airport screen is displayed in transport and/or hospital services.
* The user will log in to the C-EPOD device using this TNT driver and select the order from the list.
* The user will scan any preadvised items for delivery (e.g. Samples) and use a new "Ad Hoc Delivery" process to scan any other items brought in by the TNT driver (e.g. unplanned samples, returned assets, etc). If the TNT driver was planned to collect from multiple hospitals, the process will request the user to enter the hospital from which the items were collected. If single trip are scanned, the process will request the user to identify the asset type.
* Once all items have been scanned, Hospital Services will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* The TNT paperwork will then be used to manually debrief the collection from the various hospitals.

The process for 3rd-party Carrier Session collections is as follows:
* For sessions, these will already have an order and will be planned on a trip. This will have been set to TNT carrier, resourced (allocated to a TNT driver code and vehicle) and set to status Accepted.
* When the TNT driver returns to the depot with the collected goods, a user will obtain the paperwork, retrieve the trip (as above) and find out the TNT driver code assigned to the trip.
* The user will log in to the C-EPOD device using this TNT driver code and select the order from the list.
* The user will use a new "Ad Hoc Delivery" process to scan any items brought in by the TNT driver (e.g. polar bags of blood, document packs, returned assets, etc). If the TNT driver was planned to collect from multiple sessions, the process will request the user to enter the session location from which the items were collected. If single trip labels are scanned, the process will request the user to identify the asset type.
* Once all items have been scanned, the user will obtain the driver's name and signature on the device, to confirm change of ownership.
* C-TMS will automatically complete this job.
* The TNT paperwork will then be used to manually debrief the collection from the various sessions.

== Scope ==
{{Note|This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.}}
{{Note|This functionality is dependent on FS 317761 SCR15 C-EPOD Collection Changes.}}
{{Note|This functionality informs on and is informed by FS 317907 SCR01 C-TMS-C-EPOD Interface.}}
{{Note|Although it is possible with this solution to combine several trips together onto one trip, for ease of use on the C-EPOD device, rather than planning accurately as described above, this is not recommended for the following reasons:
* Individual PO cost will not be able to be calculated per trip, only for the trip as planned (i.e. all combined)
* Consolidation of jobs together at the depot (to provide a single loading task) may compromise the use of the C-EPOD application, if several distinct jobs are to be collected by different TNT drivers within the same collection or delivery timeframe, as these will be consolidated together.
* Mitigation of the above (i.e. turning off consolidation) would be impractical, as this would result in instructions to load assets multiple times (once for each job with contents in the asset), as the system has been instructed not to consolidate.
}}


= Set-up =

== Pre-requisites ==
* A working {{#var:System}} system.

=== C-TMS Interface Changes ===
* C-EPOD Configuration per Carrier, at certain location types. Broadly, this would be configured to send tasks to C-EPOD at depots, not at customer locations (hospitals), specifying a different job group.
* For HOT, Delivery jobs out to the hospital will not be sent to C-EPOD. The collections (loading) at the depot will, however.
* For 3PC, Delivery and Collection jobs at the hospital will not be sent to C-EPOD. Collections (loading) and Deliveries (unloading) at the depot will, however.
* These unloading jobs at the depot will include the 'from' address information.
* A configuration flag will be held against the carrier type, to indicate this sending of information.
* Configuration flags will also be created and held against the carrier, to control whether the paired jobs are automatically completed (i.e. HOT deliveries to hospital) or not (i.e. TNT deliveries that will be manually debriefed later from the paperwork returned).

== Menu Structure ==
None

== Data ==
* A site record will be created for each 3rd-party carrier or for a single hospital own transport carrier.
* The standard Job Groups will
* Only one vehicle per site will be created.
* No vehicle checks are required.
* Multiple drivers will be created for the 3rd-party Carrier, to allow multiple trips to be actioned per day.
* Multiple drivers will be created for the Hospital Own Transport, one per hospital or depot.
* The jobs group created for other carriers will also be created for these sites and be configured similarly, except for:
** allow drivers to select any incoming job from the job list.
** prompt for signature on collections and deliveries.


= Functional Description =
== Database/DAL changes ==
* New flag Ad Hoc Delivery
Table EPOD_SITE requires the following modifications:
* EPL_AD_HOC_DELIVERY - 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>
''<EPL_AD_HOC_DELIVERY></EPL_AD_HOC_DELIVERY>''
</EPOD_SITE>

Table EPOD_JOB_GROUP requires the following modification:
* EPL_SCAN_AT_VEHICLE - nvarchar(1), NOT NULL DEFAULT 'N', values 'Y' or 'N'.

Existing packages will be modified to allow the creating, editing and selecting of the new flag, including but not limited to:
* EPOD_JOB_GROUP_INSERT
* EPOD_JOB_GROUP_SEARCH
* EPOD_JOB_GROUP_SELECT
* EPOD_JOB_GROUP_SELECT_UPDATED_DATA
* EPOD_JOB_GROUP_UPDATE

The existing EPOD_JOB_GROUP DAL object will be changed to:
* Export the new flag in XML requests
* Read the new flag

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

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

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

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

== Import/Export Messages ==
The PDA web request server (Calidus_ePOD.asmx, both the XML and JSON versions) will be modified to include the new Site and Job Group flags in the LOGON_REQUEST message processor (through the LOGON_RESPONSE message).

== Admin Changes ==
The Job Group and Site maintenance screens (job_group.aspx and site_header.aspx respectively) will be modified to allow the system to be configured for:
* EPL_AD_HOC_DELIVERY, a checkbox, labelled as "AD Hoc Delivery", defaulting to 'N' (Disabled).
This configuration field will be added to the PDA tab of these screens.

{{Note}} Ensure that the new check-boxes line up with the existing fields.

== PDA Changes ==
=== Database/DAL changes ===
A new column will be added to the EPOD_SITE and EPOD_JOB_GROUP tables:
* EPL_AD_HOC_DELIVERY - This will be a one character field with of Values 'Y' and 'N'. The default value is 'N'.
This new field should be added to every procedure as part of the PDA_SITE and PDA_JOB_GROUP DAL objects.

=== Login ===
{{Note}} No changes are required to the Login process - this section described how the process will work when configured as described.

The device will be configured for the Carrier (i.e. TNT or the hospital) as the site.

The transport user will log on using the carrier driver assigned to the trip (either found through C-TMS or preset to a single default value), select the default vehicle and enter the password.

This will retrieve the list of jobs on the load assigned to that user and display them on the job list.

=== Job List ===
{{Note}} No changes are required to the Job List process - this section described how the process will work when configured as described.

Only the jobs on the current trip will be shown. The Job List will be configured to allow the user to select any of the jobs on that load, and also to show all jobs singly (i.e. not consolidated together).

=== Delivery Process ===
When a Delivery job (i.e. in this case, a depot unloading task) is selected from the Job List and started from the Job Details form, the Delivery screen will show.

This will be modified to display the ''Ad Hoc'' tab in a similar way to the

{{Note}} The existing ''Items'' tab is there to show all preadvised items - unplanned delivery of items will be shown on a different tab (described later). The Items (Container) tab will only be shown if there are items preadvised for the jobs. If there are none, 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 deliver.
* The application is configured for Ad Hoc Delivery (new Job Group flag EPL_AD_HOC_DELIVERY is enabled).

When all preadvised items have been scanned as 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 delivery job, and the application has been configured for Ad Hoc Delivery (EPL_AD_HOC_DELIVERY is enabled). 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 Delivery process (in the next section).

=== Ad Hoc Delivery Tab ===
This tab will have functionality extremely similar to the Ad Hoc Collection tab - this functionality is re-stated here, with any exceptions noted.

The Ad Hoc Delivery process allows the driver to specify the items delivered, at the point of Delivery, without the specific items for those Deliveries being planned in advance. This appears as a separate tab on the PDA within the Delivery process, labelled as "Ad Hoc" when this feature is enabled (through the flag EPL_ADHOC_DELIVERY for Delivery-type jobs only). This tab will be to the right of the existing ''Containers'' and ''Products'' tabs, but before the ''Notes'' tab.

The layout of the tab will be almost identical to the existing ''Items (Containers)'' tab. The following are sample screen layouts for the features of the tab.

<gallery widths=260px heights=400px perrow=2 caption="Ad Hoc Delivery Prototype Screen-shots">
File:FS_317761_AdHoc1.PNG|''Unplanned item details''
File:FS_317761_AdHoc2.PNG|''Ad Hoc item list''
</gallery><br />

{{Note}} These are the Ad Hoc Collection prototype screenshots.

The tab will allow items to be entered in exactly the same way as the ''Items (Containers)'' tab:
* Through a "Scan Container" text box and '''Deliver''' button.
* Through the use of the built in Camera Scanner feature, through the '''Scan''' button.
Note that there is no method of entry through the table (i.e. pressing or long-pressing on the table row will show no ''Deliver'' option).

This table of items on the screen will start empty - as items are scanned, these will be added to the table. {{Note}} Developer Note: The table should be built to the same scrolling view mechanism as the Items (Container) table on that tab.

Like the ''Items (Containers)'' tab, this tab will only allow asset formats to be scanned in the formats detailed in the Scanning section - any invalid formats will be discarded with a transient message displayed on the screen.

The tab will check whether the scanned item is an item that has been preadvised for the job. If so, and the item has already been confirmed as received, a transient message will inform the driver "This item already scanned". If this preadvised item has not yet been scanned for Delivery, the tab will interrupt the scanning (if continuous scanning is enabled) and will display an alert "Ad Hoc Delivery"/"Preadvised items must be scanned on the Items tab". If this preadvised item has been marked as cancelled on the preadvised list, the tab will interrupt the scanning (if continuous scanning is enabled) and will display an alert "Ad Hoc Delivery"/"Preadvised item has been cancelled and cannot be delivered.".

The tab will check whether the scanned item has already been scanned by the Ad Hoc Delivery process. If so, a transient message will inform the driver "This item already scanned".

The different types of Asset will be dealt with differently:
* 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. These will simply be added directly to the table.
* Single Trip Assets must have an asset type entered.
Additionally, the application will check to see if this collection is part of a consolidation (multiple delivery jobs) with multiple collection destinations. Note that this is completed differently to the Ad Hoc Collection screen, in that the device will check for the address from the Alternate address sent to the device from the server, rather than from a linked job (that will not have been sent to C-EPOD from C-TMS). If the addresses found are different, then the driver must be prompted to enter a destination location.

After these checks are made on a scanned Item ID, and further entry is required, the application will stop the scanning process (if continuous scanning is in use) and display a pop-up data entry screen. This will have the following fields:
* Header label, showing the scanned Item ID.
* Location label and drop-down list. These will only be shown if there are multiple collection locations. If this is the case, the location names will be listed in a drop-down list, forcing the driver to select one. The default entry on the drop-down list will be "Select a Location".
* Type label and drop-down list. These will only be shown if the item scanned is a single-trip format Item ID. If this is the case, all DUs (Asset Types) will be displayed in a drop-down list, forcing the driver to select one. The default entry on the drop-down list will be "Select a Type". The list will be built from all DU-type codes on the Reason Codes table (EPL_DESCRIPTION from EPOD_REASON_CODE where EPL_REASON_TYPE = "DU").
* A '''Cancel''' button. When pressed, this closes the pop-up data entry screen. The scanned ID will be discarded and not added to the Ad Hoc Items list.
* A '''Save''' button. When pressed, this button will validate that all required data is entered. If not, the screen will display a pop-up alert showing the item that has not been entered ("Ad Hoc Additional Details"/"You must select a (Field)", where (Field) is replaced with the data type that has not been entered, i.e. "Type" or "Location"). When this alert is cleared, the user will be returned to the pop-up entry screen. If there are no errors found when clicking the '''Save''' button, the pop-up data entry screen will be closed and the item will be added to the Ad Hoc Items list.

If items have been scanned and need to be added to the list, they will be added as a new row on the EPOD_CONTAINER table, as follows:
* EPL_JOB_ID - This will be from the job being scanned. If there are consolidated jobs with the same (or linked) destinations, this will be the Job ID of the first job. If there are consolidated jobs with different destinations, this will be the Job ID of the job with the destination as selected by the driver in the pop-up details entry screen
* EPL_CONTAINER_ID - As scanned, minus the leading barcode application identifiers ("00" or "8004")
* EPL_CONTAINER_PACKAGE_CODE - If this is a permanent Asset barcode ("8004"), this will be left blank. If not, this will be the code of the asset type selected by the driver in the pop-up details entry screen (EPL_REASON_CODE).
* EPL_CONTAINER_PACKAGE_DESC - If this is a permanent Asset barcode ("8004"), this will be left blank. If not, this will be the description of the asset type selected by the driver in the pop-up details entry screen (EPL_DESCRIPTION).
* EPL_STATUS - "C"
* EPL_TYPE - "A", to indicate that this is an Ad Hoc Delivery
* EPL_SEQUENCE - Set as 3-digit numeric counting from 001, incrementing with each item added to this screen.
All other items will be blank or added as normal.

These records will be added as a new row at the top of the list, by retrieving all records in reverse sequence order (through the PDA_CONTAINER DAL function SelectAllContainersForJob with parameter p_blnAdHoc set to true). This will return only scanned Ad Hoc items, in reverse sequence. The details displayed will differ, depending on the information delivered:
* Item ID - EPL_CONTAINER_ID
* Type - EPL_CONTAINER_PACKAGE_DESC
* Location - EPL_CUSTOMER_NAME of EPOD_JOB

Pressing or long-pressing on an item in this Ad Hoc table will allow the driver to remove an item from the Delivery. The application will display a pop-up alert "Ad Hoc Delivery"/"Do you want to remove this item?" with options "Yes" and "No". Choosing "No" will leave the item on the list. Choosing "Yes" will delete the item from the scanned containers and refresh the list without this item.

A '''Complete''' button should be available on the ''Job Details'' tab, to allow the users to manually indicate that all items have now been delivered. 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 Delivery (and Ad Hoc Delivery 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 Delivery process and activate the ''Ad Hoc'' scanning tab.


= Appendix A: TEST PLAN =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test the C-EPOD changes made for NHSBT.
|MenuAccess=None
|Prerequisites=Data set up as per Data Setup section; Note that individual setup information is provided for each test area.
|Objective=To test that: Admin can view and maintain configuration for the changes; the EPOD Client application can perform Ad Hoc Deliveries.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{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 fields are present and can be set and maintained.
|Result=New fields can be set, changed and saved:
* New checkbox "Ad Hoc Delivery"
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 Job Group Maintenance screen. Ensure the new fields are present and can be set and maintained.
|Result=New fields can be set, changed and saved:
* New checkbox "Ad Hoc Delivery"
The tabs are well organised, making good use of space.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA Ad Hoc Delivery.
|Notes=Create a load with several deliveries from hospitals and deliveries to the depot and assign to the carrier, user and vehicle. Ensure that there are planned items on some deliveries and deliveries.
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Log in to the application and pick up the load.
|Result=The ''''Job List'''' is displayed:
* No deliveries at the hospitals should be shown.
* Deliveries to the depot should not be consolidated, and labelled as Unloading jobs.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the second unloading job and start it at the Job Details page.
|Result=No error will be displayed; the job may be started and the delivery screen shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Start Job'''.
|Result=The device checks for any changes to the jobs. When checked, the ''''Delivery'''' screen is displayed:
* There is a '''Complete''' button.
* There are 3 tabs: ''Job Details''; ''Items''; ''Ad Hoc''.
* The jobs are shown as "In Progress" in Admin.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click the '''Complete''' button.
|Result=An error should be displayed showing that there are still items awaiting scanning.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Items'' tab. Cancel one of the items and confirm the exception with a reason code.
|Result=The Items list is displayed with only one item on it.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Ad Hoc'' tab
|Result=The Items list is displayed (with nothing in it). The screen is laid out as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Using the provided text box, enter "invalid". Click ''Deliver''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "8004invalid". Click ''Deliver''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "00invalidlength". Click '''Deliver'''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter "00invalidformat00000". Click '''Deliver'''.
|Result=A transient error should be displayed, showing that the format is invalid.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Type only. The type list should show all valid Asset types.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Type details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a type. Click '''Save'''
|Result=The item should be added to the list, showing the selected type. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Scan''' button.
|Result=A Scan reticule should be displayed, allowing barcodes to be scanned.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Repeat the item tests for invalid formats and items above ("invalid", "8004invalid", "00invalidlength", "00invalidformat00000")
|Result=Each time these items are scanned, a transient error should display, as previously. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan an invalid barcode type (for example, a CODE 39 or EAN-8 or EAN-13 barcode).
|Result=A transient error should display, showing that the format is invalid. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan the cancelled item from the planned items list.
|Result=The Scan reticule should be closed and the ''Ad Hoc'' tab be displayed, showing a pop-up error, saying that the item must not be Delivered, as it has already been cancelled.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Scan''' button. Scan the remaining planned item from the planned items list.
|Result=The Scan reticule should be closed and the ''Ad Hoc'' tab be displayed, showing a pop-up error, saying that the item must be Delivered through the Items tab.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Items'' tab and scan the item.
|Result=A transient message should be displayed, showing that the item has been Delivered. The Scan reticule should be closed and the ''Items'' tab be displayed, with no items on the Items list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Switch to the ''Ad Hoc'' tab and scan the same item.
|Result=A transient message should be displayed, showing that the item has already been Delivered. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan an item that is already on the ''Ad Hoc'' items list.
|Result=A transient message should be displayed, showing that the item has already been Delivered. The Scan reticule should stay open.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Close the Scan reticule.
|Result=The ''Ad Hoc'' tab and Items list should be displayed, showing the items scanned, with the latest at the top.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click on the top item.
|Result=An alert should ask whether the item should be removed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''No'''.
|Result=The ''Ad Hoc'' tab and Items list should be displayed again, with item selected still on the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click on the top item. When prompted, click '''Yes'''.
|Result=The Items list should be displayed again. The item selected should be removed from the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Move to the ''Job Details'' tab and press the '''Complete''' button.
|Result=The signature should be prompted for.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the signature.
|Result=A transient message should display that the job is complete.
The jobs will be completed in Admin.
The Job list should be redisplayed.
The Unloading task will be removed from the Job List.
|Remarks=
|PassFail=

}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a trip with consolidated deliveries back to the depot, from different collection locations. Log in to the C-EPOD device, start the job and move to the ''Ad Hoc Items'' tab. Enter a valid permanent Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Location only. The Location list should show a list of all unique collection locations for the orders.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid permanent Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Location. Click '''Save'''
|Result=The item should be added to the list, showing the selected location. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid single trip Asset ID. Click ''Deliver''.
|Result=The pop-up ''''Details'''' window should be shown, prompting for Type and Location. The type list should show all valid Asset types. The Location list should show a list of all unique collection locations for the orders.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Cancel'''
|Result=The ''Ad Hoc'' tab should be shown. The item should not be added to the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a valid temporary Asset ID. Click ''Deliver''. Click '''Save''' in the pop-up up ''''Details'''' window.
|Result=An error should be displayed, asking for Type and Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a type. Click '''Save'''
|Result=An error should be displayed, asking for Location details.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Location. Click '''Save'''
|Result=The item should be added to the list, showing the selected type and location. The format of the list row should be as expected.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{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= 
|RefDate2= 
|Ref3=FS 317761 SCR15 NHSBT C-EPOD Collection Changes
|RefV3=0.4
|RefDate3=04/06/2014
|REQ=0
|EST=0
|FS=0.75
|TS=0
|DEV=3
|ST=0.5
|IMP=0
|EREQ=0
|EEST=0
|EFS=0.75
|ETS=0
|EDEV=3
|ESTT=0.5
|EIMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|Rev1=Julie Scott
|Rev1Title=Project Manager
|Rev2=Ed Bond
|Rev2Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 318517 SCR22 NHSBT C-EPOD Hospital Own Transport

2014-09-22T11:30:24Z

AppaduN: /* Database/DAL changes */