Calidus HUB - User contributions [en-gb]

FS 338835 KOO-GAP-SCR1 GAP Scan Store Barcode on Arrival

2016-11-04T16:32:49Z

Rmg: v2.0 - Update container BOL number references

<div class="noprint">
{{#vardefine:Client|PART}}
{{#vardefine:ClientName|Knights of Old}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|GAP Scan Store Barcode on Arrival}}
{{#vardefine:Version|2.0}}
{{#vardefine:Date|26th October 2016}}
{{#vardefine:Reference|338835 KOO-GAP-SCR1}}
{{#vardefine:Year|2016}}
</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 ==
As part of the Knights of Old GAP contract, add configuration to allow the driver to scan a store barcode upon arrival to the store.

The GAP contract is owned by KOO, but every part of the process is performed by GAP or 3rd parties.

The GAP warehouse in Rugby loads the trailers by handballing of cartons and creates ASNs in their system. This is likely the full quantity of product required for the week in France. Each carton is uniquely labelled.

A French 3PL TSA goes to the GAP warehouse and collects the trailer and trunks the load to Paris.
The Paris depot is owned and operated by French 3PL MCE, which unloads the trailer.
This is updated onto Empirica, KOO's WMS, which is being updated by MCE.
This initiates an 861 "Arrival Scan at Pooler" message from Empirica to TrueCommerce (an EDI hub) and on to GAP.
The unloaded cartons are sorted into stores. These store cartons are then palletised.
These cartons are then loaded onto vehicles, physically scanning each item being loaded.
This is updated onto Empirica, KOO's WMS, which is being updated by MCE, which generates an 861 "Pooler Outbound Scan from their Facility" message from Empirica to True Commerce and on to GAP.
Empirica is also updated with a load number and each job is routed onto specific days (fixed route/milk runs) and assigned to a trailer. All cartons for a particular store are loaded onto the same load.
This also generates messages to ''CALIDUS'' ePOD for the execution of the jobs.

MCE then organises the final leg delivery of the cartons to the GAP stores. There are 3 MCE depots:
* Paris - 8 devices
* Lyon - 2 devices
* Strasbourg - 2 devices.
The Paris depot trunks to the other two depots, not controlled by C-ePOD.

The driver process is as follows:
* Log on using a provided user/password and the trailer ID.
* Complete the jobs in sequence where possible.
* Start and navigate to the store.
* Arrive and scan store barcode - these will be unmanned locations.
* Scan every carton off the vehicle.
* No signature is required.
* Cancellation of jobs and cartons is allowed, through a curated list of reason codes.

== Solution Overview ==
As the existing Partnerlink JobShare CSV interface does not support explicit naming of individual containers (cartons), Empirica will send the required loads and jobs to C-ePOD through the OBS C-ePOD XML format, which allows this. This will be sent as an FTP or flat-file transfer of the file, which will be uploaded by C-ePOD - this is standard functionality.

Mapping has been completed on all aspects of the load and jobs and will be documented as a mapping spreadsheet for the purposes of the project. Additional standard interface documentation (e.g. XSDs, sample files, standard specifications) will also be provided.

'''Mapping Notes:'''
* All MCE depots will be seen as 1 site within C-ePOD - there is no need to split these.
* The carton ID is 18 digits. This may need to be expanded to 20 alpha-numeric characters. As C-ePOD's Container ID (where this is stored) is 30 characters, this is not an issue.

When the job is completed in C-ePOD, there is no required update back to Empirica. A message will be created from C-ePOD to TrueCommerce, consisting of a formatted 861 message is ANSI X12 format. This is covered elsewhere in a separate specification.

The mobile device process for Store Barcode Scanning will be as follows:
* After Arrival is pressed, but before scanning starts, the mobile device must show a ''Store Barcode'' screen, to scan a store barcode.
* The "Store Barcode" field will allow entry through a pop-up keyboard, as well as through the embedded device scanner. A button will be provided for the user to use the camera scanner as a backup.
* A '''Confirm''' button will be provided. Once the barcode is scanned, the driver will click this button. This will validate the scanned barcode against the Store Number. If they do not match, or the entered barcode value is the wrong format or length, or nothing is entered, the screen will pop up an alert, informing the user that "the store barcode is incorrect - continue anyway?". The driver will be offered options of '''Yes''' or '''No''', with '''No''' being the default. If '''No''' is clicked, the screen will be re-shown, displaying the Store Barcode field in red border, as it has an error.
* If '''Yes''' is clicked, or the store barcode matches the store number, the driver will be allowed to continue.

The mobile device process must include:
* No Deliver All functionality
* No Clausing
* No signatures
* Force container entry

The mobile device will be configured to use a version of the standard Partnerlink style. Note that the image displayed on the login screen will be that configured for the Site, so this may be the KOO or GAP logo, or other if required, with no further development required.

The style will translate the word "Container" to "Carton".

A French language translation file will be created for the mobile device. This is likely to be delivered after the initial go-live. It is further noted that, due to the configurable nature of the labels within the device, this is likely to be an iterative process, and will probably require several releases to ensure that the language file is correctly translated. This is not covered by a specification.

== Scope ==
An implementation of the latest version of the ''CALIDUS'' ePOD application is required for this contract.

This will be a separate instance of ''CALIDUS'' ePOD, hosted on the existing Partnerlink servers. Although this will utilise the Partnerlink servers and database, the application will be distinct and separate and the data will be kept in a separate schema, , to ensure that no issues are generated to the Partnerlink contract.

''CALIDUS'' Portal TTM is not required.

The mobile devices that will be used are M3 SM10 devices, with 1D barcode scanners. 12 are required.

With respect to the Scan Store Barcode functionality, the following scope is assumed:
* The barcode scanned by the driver is used purely for validation - this will not be sent back to the server for storing in the database, visible in the Admin console or exported out with any standard job exports. As the Admin console is not likely to be generally used by the operation, and there is no job export other than the bespoke GAP export (which does not include this information), this will not cause an issue.
* The scanned barcode will not be visible on the device after it is entered. As this is simply used to prevent the driver from arriving before the job begins, this will not cause an issue.
* The configuration of this screen may not be amended within the ''CALIDUS'' ePOD Admin console at this time - during implementation, the OBSL teams will make any necessary changes to the configuration until this is confirmed as working as expected. Any further modifications will require software support logs to be raised with OBSL, which may then be chargeable.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
A new PreJob UDF will be created for this implementation:
* Description "Store Barcode"
* Type: "Pre-Job"
* Key Type: "Job Group"
* Key Value: "GAP|GAP"
* Name: "Store Barcode"
* Generated UDF:
<FORM NAME="Store Barcode" REQUIRED="Y">
<FIELD ID="STORE_BARCODE">
<TEXT>Scan Store Barcode</TEXT>
<FORMAT>T</FORMAT>
<ACTION>B</ACTION>
<REGEXP>DBV:GPS3PL.{7,8}([EPOD_JOB.EPL_CUSTOMER_CODE])</REGEXP>
<REQUIRED>C</REQUIRED>
</FIELD>
<BUTTON CONFIRM="The store barcode is incorrect - continue anyway?">
<TYPE>C</TYPE>
<TEXT>Confirm</TEXT>
</BUTTON>
</FORM>

{{Note}} This configuration may not be amended within the ''CALIDUS'' ePOD Admin console at this time - during implementation, the OBSL teams will make any necessary changes to the configuration until this is confirmed as working as expected. Any further modifications will require software support logs to be raised with OBSL, which may then be chargeable.

{{Note}} Trailers will be mapped as Vehicles. These need not be pre-created within ''CALIDUS'' ePOD - these will be created if required when the loads are created.

Reason Codes mapped for Job and Detail - no clause codes will be created as they are not required.
* JOB Cancellation Reason Codes
** "NA" - "No Access to Store"
* DETAIL cancellation Reason Codes
** "01" - "Damaged Carton"
** "04" - "Quality Problem (e.g. Carton open, missing items)"

Site/Job Group Configuration:
* Deliver All disabled.
* Clausing disabled.
* Driver and Customer signatures disabled for collections and deliveries.
* Force container entry enabled.
* Capture Arrival times enabled.
* Consolidation disabled.
* Generic container POD format should be set.
* The new KOO GAP style should be set.
* Container Only Delivery enabled.
* Scan Errors Intrusive enabled.
* Scan at Vehicle enabled.
* Seamless Scanning enabled.
* Display Job Code set to "Job Code".
* User Notes enabled.
* Import Create Standing Data enabled.



= Functional Description =

== Data Import ==
Mapping has been completed on all aspects of the load and jobs and will be documented as a mapping spreadsheet for the purposes of the project. Additional standard interface documentation (e.g. XSDs, sample files, standard specifications) will also be provided.

'''Mapping Notes:'''
* All MCE depots will be seen as 1 site within C-ePOD - there is no need to split these. It is assumed this will be "GAP".
* The carton ID is 18 digits. This may need to be expanded to 20 alpha-numeric characters. As C-ePOD's Container ID (where this is stored) is 30 characters, this is not an issue.

Load:
* Load ID - From the entered load ID.
* Start Planned Date - Delivery Date
* Start Planned Time - 00000000
* Assigned Vehicle - the trailer ID
Job:
* Job Code - Empirica BOL
* Job Type - "D" for delivery
* Job Group - fixed text, assumed to be "GAP"
* Start Planned Date - Delivery Date
* Start Planned Time - if available, set to the defined delivery time, else "0900"
* End Planned Date/Time - If no planned start time is available, set these to the Delivery Date and "1700" respectively, or end end windows time.
* Customer Code - the GAP Store code, fully zero-filled. For example, "012345"
* Name/Address/Post Code - the store delivery address.
* Telephone - from the store address
* Sequence - Drop Number
Containers (Cartons)
* Container ID - the carton number, fully-qualified. So, this is an 18-digit number, but is qualified with a 2-digit prefix of "00". So this should be included, as this is matched when scanning carton barcodes.
* Package Code - "CTN"
* Package Description - "CARTON"
* Long Description - GAP BOL #

== Logon ==
It is expected that a device style will be created based on the Partnerlink style. The logo will be taken from the logo uploaded against the site, and is likely to be the KOO or GAP logo. Note that the screen-shots shown in this document are the standard Partnerlink style - this can be modified before development begins. Note that the current style uses the word "Pallet" in preference to "Container" or "Carton" - this will be changed in the final style. The log-in screen-shots below show first the Partnerlink style, then the intended GAP style.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_Login1.png|''Log In''
File:FS_338835_PDA_Login2.png|''Log In - updated style''
</gallery><br />

The drivers will be provided a user-name and password, and the loads will be allocated to specific vehicles, ensuring that they can complete only the loads required. The users and their passwords must be configured within ''CALIDUS'' ePOD.

A driver will log on to a device using the provided user name, password and vehicle. The vehicle can be selected from a list, and will be a list of trailers. The device will remember the last used User name and Vehicle, but will always require that the password is entered.

{{Note}} Vehicle checks are not required.

== Job List ==
When log-in is complete, the assigned work-list will be downloaded onto the device, showing all the jobs in sequence on a Job List screen. If no workload has been assigned to the vehicle, the device will tell the user that there is no work available. The driver can exit, or try to download again.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_JobList2.png|''Job List''
</gallery><br />

The device will show a list of the jobs on this load, showing:
* Job Reference - configured to show the Job Code (KOO BOL Number)
* Job Type - Collection/Delivery
* Customer Name
* Postcode
* Planned Date/Time - {{Note}} Unlike the screen-shot above, this will be the full date and time, including the year.
* Carton Count (the sub-totalled quantity of all items on the job)

The screen will display the status of the jobs on the load through a coloured background, as follows:
* Red - Cancelled
* Green - Completed
* Blue - Completed (with amendments)
* Yellow - In Progress
* None - Pending/Incomplete
Note that this status is also displayed prominently in the Job Details screen (following).

The jobs are displayed in the sequence in which they should be completed, with the first job selected. However, the jobs can be viewed in any sequence by clicking the line of the job to be completed - the device will display the Job Details page.

The '''Menu''' button can be used here to allow the following options:
* ''Refresh Load'' - Refresh the Load/Worklist
* ''Show All / Outstanding Jobs'' - Toggle between showing all or only incomplete jobs.
* ''Log Out'' - Log out of the system and return to the log-in screen.
* '' Change Vehicle'' - Return to the log-in screen to change only the vehicle.
* ''Load Information'' - display any load information. This is also accessible from the Information button on the title bar.
* ''Vehicle Checks'' - perform ad hoc vehicle defect checks, if configured.
* ''Cancel Jobs'' - select jobs to cancel from a list.
Some support information can also be accessed from this menu.

The system can be configured to control allowing the drivers' ability to complete jobs out of sequence, as follows:
* No re-sequencing of jobs - this is not allowed by the driver - the jobs must be completed in the order planned, or cancelled if they cannot be completed.
* Confirm re-sequencing allowed - this requests the user to confirm first.
* Always allowed - no confirmation.
This configuration will be decided at the point of implementation, but is expected that initially re-sequencing will be allowed with a warning.

If any jobs have been added to a Load while the load is in progress, the ''Refresh'' option (which also is timed to happen on a regular 5 minute interval) will get the details of the new job and add it to the job list, showing the user a summary of the job(s) added. This functionality will also pick up any amendments to the jobs if, for example, if quantities have been amended, products added, etc.

Jobs can be cancelled by the driver at this time, by long-pressing on the job in the table and choosing ''Cancel'' from the pop-up options. The user will be prompted to enter a reason why this job is being cancelled, and optionally take a picture. If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list. It is expected that there will a single reason code to cancel jobs, to account for the scenario whereby jobs cannot be delivered due to failed access to the site. However, the reason codes used for job cancellation are controlled by the system and may be modified or added to at any time.

{{Note}} The system may be configured for Image Capture in the following ways:
* Force Image Capture at all times when cancelling or changing quantity (i.e. at Job and Detail level)
* Optional Image Capture at all times.
It is expected that Photo at exception and at Job completion will be allowed but optional.

== Job Details ==
Selecting a job from the Job List will show the user the job report and customer contact details (on a Job Details screen). The user can back out of the selected Job and view any Job on the list.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_JobDetail3.png|''Job Details''
</gallery><br />

The screen has several Tabs, showing:
* The Job Type (Collection, Delivery, Service)
* The customer details (Customer Code, Name, Address and Postcode)
* The contact information (Contact name and number)
* The Instructions for the job
Clicking on the tabs will display the information.

{{Note}} The screen allows the driver to contact the customer (through either text or phone) by clicking on the provided buttons.

=== Cancelling a Job ===
The driver can cancel jobs by clicking the '''Cancel Job''' button on the job detail screen.

This will call the cancellation screen where the user will be prompted to enter a reason why this job is being cancelled. The cancellation screen also allows the user to take a picture.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_JobDetail4.png|''Job Cancellation''
</gallery><br />

{{Note}} Whether or not a picture is required for a job cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Job Only' then a picture must be taken to cancel a job, otherwise the picture is optional.

If a job is confirmed cancelled, the device will show the Job List again with the cancelled job removed from the list.

{{Note}} This job cancellation screen can also be called from the job list.

=== Starting/Navigating ===
When the driver has selected their Job, they can choose the Job with the '''Start Job''' button.

Delivery instructions are not expected to be provided through the interface. However, if there have been instructions provided on the Job and the driver has not already switched to this tab to view the instructions, the device will switch to the Instructions tab, to force the user to see the instructions before starting.

{{Note}} It is expected that re-sequencing of jobs is initially to be allowed with a warning. If a job is attempted to be started out of sequence, the user will be told this at this point and allowed to confirm.

When clicking this button to start or arrive at the job, the application performs a check whether the job has been changed since it was loaded on the device, to ensure that the latest data is on the device for the job. If there are changes, the driver will be informed and the screen will refresh.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_JobDetail5.png|''Arrive Job''
</gallery><br />

When a Job is successfully started, this will take the Job to 'In Progress' status, at this point the 'Start Job' button will change to an 'Arrive Job' button and the navigation icon is shown. When the navigation icon is clicked on the device will use a navigation application installed on the device to navigate to the destination using any installed navigation application. The destination address will be entered in the device and will allow immediate navigation to the address.

=== Arriving ===
Once arrived at the destination, the driver will then indicate arrival by clicking the '''Arrive Job''' button. The mobile device will be configured to display the Store Barcode scan screen at this point.

The Store Barcode screen will be configured through User-definable fields, with a title of "Store Barcode", a "Scan Store Barcode" text field with a barcode button, and a '''Confirm''' button.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_PreJob1.png|''Store Barcode Scanning''
</gallery><br />

The screen will be configured to allow the use of the mobile device's built-in scanner - the text field will be highlighted and ready for input, and the on-screen keyboard will not be shown.

The driver will scan the store barcode, an example of which is shown below:

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_Store_Barcode.png|''Store Barcode''
</gallery><br />

If the barcode cannot be scanned using the internal scanner, the app's camera scanner may be used by pressing the Barcode action button against the field.

If the barcode cannot be scanned at all, the text from the barcode may be manually keyed into the text field, using the on-screen keyboard, activated by clicking the field.

The driver will then click the '''Confirm''' button. The device will compare the store barcode text entry to the configuration of the barcode contents. This is expected to be:
* "GPS3PL"
* 7 or 8 intervening characters
* The Store Number
e.g. "GPS3PL 000000001234"

If this entry does not match this pattern, the device will highlight this by displaying a pop-up message:
* "The store barcode is incorrect - continue anyway?"

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_PreJob2.png|''Store Barcode Scanning''
</gallery><br />

The driver will be offered options of "Yes" or "No", with "No" being the default. If "No" is clicked, the screen will be re-shown, displaying the Store Barcode field in red border, as it has an error.

If "Yes" is clicked, or the store barcode matches the store number, the driver will be allowed to continue without confirmation.

The device will move on to the Delivery process.

==== Scan Store Barcode - Technical Information ====
In order to achieve the above, the following mobile device changes will be made:

The EPOD_JOB table and DAL object will be modified to add a new field EPL_UDF_PREJOB.

The Job Update export back to the server will be modified to add this field, although this will be ignored at this time in the server.

A createUDFButtons method will be created in the Style object to create buttons as per the current Services Pre-/Post-work screen. This will then be modified to check if any fields in the UDF being actioned by these buttons have a REQUIRED attribute/tag of "C". If so, the Confirm button will display the confirmation dialogue if any of these indicated fields fail validation.

The createUDFields2 method will be modified to support the REQUIRED tag value of "C". It will also be modified to extend the REGEXP tag validation for data-bound validation.

If the REGEXP tag begins with "DBV:", this is a data-bound validation. In this case, replace any data tags with the value from the DAL objects referenced and remove the DBV indicator. For example:
* DBV:GPS3PL.{7,8}([EPOD_JOB.EPL_CUSTOMER_CODE])
This will have the Customer Code from the job inserted into the pattern in the indicated place (between and including the square brackets). The prefix "DBV:" will be removed. Assuming a customer code of "01234", this will result in a pattern of:
* GPS3PL.{7,8}(01234)
This pattern may then be stored against the field and used for standard validation.

A new pop-up screen will be created in Job Details, to display PreJob UDF forms when the '''Arrive Job''' button is clicked. This will be in the standard way that this is achieved in the current Services Pre-/Post-work screens. This will be modified to use the new createUDFButtons style method. This new pop-up screen must listed for the auto-updates event, and exit gracefully if this event is raised. This form will allow back-out.

The screen will include a title taken from the UDF title, and a form of all the fields in the UDF. Any buttons will be displayed as standard on the bottom of the form.

A new function will be created in the Job Details form to control which tasks must be completed when the '''Arrive Job''' or '''Continue Job''' button is pressed - this will be called nextJobStartTask. This will start tasks in the following sequence:
* NextJobStartTask in the following sequence:
** Arrival
** PreJobUDF
** PreJob Signature
** ActionJob (Vehicle Swap or Col/Del/Service)

The PreJob UDF action will check if the job has any saved UDF against it in the new EPOD_JOB field EPL_UDF_PREJOB. If there is none, the action will check if there is any configured PreJob UDF (based on the site and job group). If present, the new PreJob UDF pop-up screen will be shown.

If the user backs out of the PreJob UDF screen, the usual confirmation dialogue will be displayed. When returning from the screen, if no UDF is present to store, the Action should check the FORM tag's REQUIRED attribute. If set to "Y", the action should stop at this point. If set to anything else, the action can continue to the next task.

== Delivery Processing ==
{{Note}} There are only delivery jobs in this implementation.

Deliveries will initially consist of multiple cartons to deliver.

The following are the standard tabs that are expected to be displayed:
<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_Delivery1.png|''Job Details Tab''
File:FS_338835_PDA_Delivery2.png|''Job Details Tab - Addresses''
File:FS_338835_PDA_Delivery3.png|''Containers (Cartons) Tab''
File:FS_338835_PDA_Delivery4.png|''Notes Tab''
</gallery><br />

The ''Job Details'' tab has multiple sections:
* Contact information
* Address information - if supplied, both current address and origin address are shown.
* Job Instructions, if provided.

{{Note}} A '''Deliver All''' button will '''NOT''' be available on this first tab.

From the ''Cartons'' tab, the device will show a list of the cartons to be delivered, which can show:
* Carton ID
* Package Description
* Status ("Pending")
* Weight
* Long Description - the GAP BOL #

Actions against the cartons can be activated by long-pressing against the row, and have the following actions:
* ''Cancel''
* ''Info''
<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_Delivery5.png|''Carton Long-press Pop-up''
File:FS_338835_PDA_Delivery6.png|''Carton Info Pop-up''
</gallery><br />
For information on the actions above, see the appropriate following sections.

When all cartons have been confirmed as delivered or cancelled, the Delivery process will return to the Job Details tab, where a '''Complete''' button will be displayed, to complete the job. It is then possible to review the list of cartons delivered and change this if required. The list will display a border and status to indicate whether the products have been delivered:
* Red - Cancelled
* Green - Delivered in full.
The status will be displayed for confirmation.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_Delivery8.png|''Completed Cartons''
File:FS_338835_PDA_Delivery9.png|''Complete Button''
</gallery><br />

When the driver has confirmed that everything is complete and clicked the '''Complete''' button, this screen will close and the user will be directed to the Job Completion process.

=== Delivering a Carton ===
Each carton on the list can be confirmed as delivered by either:
* entering the carton ID manually and clicking the ''Deliver'' button.
* scanning the carton ID.

The carton label looks as follows:
<gallery widths=400px heights=600px perrow=1>
File:FS_338835_Carton_Label.png|''Carton Label''
</gallery><br />

{{Note}} Either the top or bottom barcodes may be scanned, as they both contain the carton ID - for training purposes, assume that the bottom barcode is the barcode that must be scanned by the driver.

When marked as delivered, the item will be removed from the list.

=== Cancelling a Carton ===
If a carton can't be delivered, it can be removed from the list with the pop-up option ''Cancel''. Again, the exception screen will be shown where the driver can enter the reason for the cancellation.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_Delivery7.png|''Cancel Carton''
</gallery><br />

The reason codes mapped for carton cancellation will be as follows:
* "01" - Damaged Carton
* "04" - Quality Problem (e.g. Carton open, missing items)

The user will also be able to optionally take a picture associated with this cancellation.

{{Note}} Whether or not a picture is required for a product cancellation is controlled by the 'Image Required for Cancellations' setting against the job group for the job. If this is set to 'All' or 'Detail Only' then a picture must be taken to cancel a product, otherwise the picture is optional.

{{Note}} No clausing i.e. entering a comment against a delivered carton) will be allowed.

== Job Completion ==
It is expected that no signatures (driver or customer) will be required for this implementation. Furthermore, no additional photos are required at this point. Both of these may be configured at a later date if required.

Therefore, when all items are complete (delivered or cancelled) and the driver has clicked the '''Complete''' button, the driver will be returned to the Job List screen and the completed Job will be removed from the list. Any completed jobs can be optionally viewed again, by pressing the Menu button and choosing ''Show All Jobs''. The list can be made to show only outstanding jobs again by pressing the Menu button and choosing ''Show Outstanding Jobs''.

== Post-Load ==
Once all Jobs have been completed, the Load will be marked as completed when the user returns to the Job List screen.

<gallery widths=310px heights=400px perrow=3>
File:FS_338835_PDA_JobList3.png|''Completed Load''
</gallery><br />

The device will attempt to download a new load for the user and/or vehicle. If one has not been provided, the device will confirm this and allow the user to check again or log off the system.

== POC/POD Documents ==
No POD documents are required to be produced for this implementation - POD confirmation is through the GAP 861 EDI message. The generic container report will be configured.

== Data Export ==
There is no requirement to update Empirica with completed jobs. However, GAP must be updated through the development of a new 861 EDI message. This is specified elsewhere.



= Appendix A: TEST PLAN =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Tests covering the whole mobile device process.
|MenuAccess=N/A
|Prerequisites=Configured as per specification
|Objective=To test that: Scan Store Barcodes are displayed and validate as expected and; the device styling is correct.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Mobile Device
|Notes=Requires 3 jobs on a load, the first two configured for the PreJob store barcode as shown above, the third with a different job group without any pre-job configuration.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that the app is styled as expected
|Result=The app is coloured as expected. The login screen displays the correct logo. The Job List and Container tab are styled correctly. The app always shows "Carton" where "Container" would be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Log on and pick up a load for the vehicle. Select the first job and start it. Click '''Arrive Job'''
|Result=The configured Scan Store Barcode screen should be displayed, laid out as expected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Back out of this screen using the '''Back''' button.
|Result=The app should return to the Job Details screen. The '''Continue Job''' button should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Continue Job'''.
|Result=The Scan Store Barcode screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Confirm'''
|Result=A confirmation alert should be displayed with the expected wording.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''No'''
|Result=The Scan Store Barcode screen should be displayed again.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (or scan using the device's internal scanner) an invalid barcode (wrong length). Click '''Confirm'''.
|Result=A confirmation alert should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''No'''. Key in an invalid barcode (right store number but without the preceding characters). Click '''Confirm'''.
|Result=A confirmation alert should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''No'''. Use the app scanner to enter an invalid barcode (right format, wrong store number) . Click '''Confirm'''.
|Result=A confirmation alert should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Click '''Yes'''.
|Result=The Delivery screen should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Back out of the delivery. Click '''Continue Job'''.
|Result=The Delivery screen should be displayed as the store barcode has already been saved.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the job by scanning/entering all the cartons.
|Result=No signatures should be prompted. The Job List screen should be displayed.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the next job. Click '''Arrive Job'''. Scan a valid store barcode. Click '''Confirm'''.
|Result=The Delivery screen should be displayed without confirmation.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the job. Start the next job. Click '''Arrive Job'''.
|Result=The Delivery screen should be displayed, as there is no store barcode configuration.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=EPOD
|Ref1=[[FS 338875 KOO-GAP-SCR2 GAP Export Interface]]
|RefV1=0.1
|RefDate1=26/10/2016
|EREQ=0
|EEST=0
|EFS=1.25
|ETS=0
|EDEV=5
|ESTT=1
|EIMP=0
|EPM=.5
|REQ=0
|EST=0
|FS=1.25
|TS=0
|DEV=5
|ST=1
|IMP=0
|PM=.5
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Ken Hayes
|Rev1Title=KOO Representative
|Rev2=Matt Turner
|Rev2Title=OBSL Representative
}}</div>
[[Category:{{#var:Client}} FS]]

EST 333750 Allow Job Details UDF to be amended

2016-03-02T15:20:35Z

Rmg: Initial Draft

{{Template:Estimate
|Supimix_Client_Code=HEW
|Supimix_Project_Code=DEV
|Supimix_Site_Code=BSE
|Supimix_Client_Reference= 
|Supimix_Number=333750
|The_version_of_the_document=0.1
|Your_Name=Rob McGee
|Supimix_PO_Reference= 
|Supimix_Priority=3
|Date_(DD/MM/YY)=02/03/2016
|Clients_Customer= 
|System_Version_being_changed=3.X
|Client_Request=On the device require the ability to enter or change the trailer ID against a job and the ability to change the job details UDF from the driver signature screen.

On the admin system require the ability to enter or change the trailer ID against a job and the ability to change the job details UDF.
|OBS_Solution=
<br/>
<u>ePOD Admin Changes:</u>

A new 'Amend Job Details UDF' flag will be added to te job group maintenance page. This will control whether or not job details UDF can be amended on both the device's driver signature screen and the admin system job details page.

The Job Details pop-up will have the following changes made:
* If the job has been completed the edit button will only be present if edit functions are allowed.
* Clicking the edit button for a completed job will issue a warning to the user before allowing them to edit the job.
* The trailer ID of the job will be added as a new field on the Details tab. The user will be able to change this field even if the job has been completed.
* A new job detail UDF tab will be added to allow the display and editing of job details UDF for the job. This tab will only be shown if the new 'Amend Job Details UDF' flag is set, the job has been completed and the job has some job details UDF.

Whenever the user selects the job details UDF tab the system will build and show the job details UDF questions in the same way as the device does. When saving any changes to the job details UDF this will again be done in the same was as on the device, including all entries are valid based on teh UDF before saving any changes.
This means that any UDF fields associated with a value from the job (e.g. the trailer ID) will be set to the value from the job when the UDF is built and will update the value on the job when any changes to the UDF are saved.

'''Warning:''' Changing the trailer ID through the new trailer ID field on the job details tab will not apply any format validation from the UDF meaning the admin users will be able to bypass the UDF validation.<br/>'''Note:''' Any changes to the trailer ID through the new trailer ID field on the job details tab will not update the job details UDF until that UDF is next viewed and saved.

<u>ePOD Device Changes:</u>

The ePOD device currently copies the trailer ID from the load to the job when the job is completed. This is done regardless of any trailer ID set against the job (i.e. this currently overwrites any trailer ID stored against the job).

This will be changed so the trailer ID is copied from the load to the job when the job is started, this is so the trailer ID for the job is available when the user opens the collection/delivery screen. Also the trailer ID will only be copied from the load to the job if the job does not already have a trailer ID (i.e. the trailer ID against the job is blank). This is to prevent any trailer ID entered for the job in the admin system being overwritten by the trailer ID from the load.

The job details UDF creation will be changed to pass the job to the UDF creation in order to allow UDF fields to be associated with a value on the job (i.e. the trailer ID).

The UDF creation will be changed so that when building the UDF fields if a field is associated with a field from the database the value for the UDF field will automatically be set to the value of the associated field. This will affect all UDF including the load metrics UDF and the job details UDF. This change will mean when UDF fields are shown on the device:
* The load metrics trailer ID field will initially be set to the trailer ID from the load.
* The job details UDF trailer ID will initially be set to the trailer ID from the job.

The signature screen will then be changed to allow a new job details UDF tab to be shown when capturing a driver signature. This tab will only be shown if the new 'Amend Job Details UDF' (see admin changes above) is set and if job details UDF exist for the job/jobs being signed for. When shown this tab will appear in the same place as the customer signature terms and conditions tab (i.e. below the signature for portrait or to the right for landscape).

If the signature is being captured for a single job the tab will just show the job details UDF for that job.
If the signature is being captured for multiple jobs the tab will show the display job reference followed by the job details UDF for each job.

In all cases the job details UDF tab will be a scrollable tab so that if the data shown does not fit into the space available the user will be able to scroll to see the remaining data.

<u>Implementaion:</u>

When the changes are released OBS will update the existing job details UDF to add a trailer ID field. This will be the same as the trailer ID field included on the load metrics with the exception that this text field will be associated with the trailer of the job.

<br/>
|Requirements_Days=0
|Estimation_Days=1.00
|Functional_Specification_Days=1.25
|Technical_Specification_Days=0.00
|Development_Days=2.50
|Testing_and_Release_Days=1.50
|Implementation_Days=0.25
|Project_Management_Days=0.00
|Year=2016
|Free_Of_Charge=N
|Supimix_Client_Code=HEW}}

FS 331694 Deliver All function

2015-11-26T13:15:09Z

Rmg: Initial Draft

<div class="noprint">
{{#vardefine:Client|PART}}
{{#vardefine:ClientName|Partnerlink}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Deliver All function}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|26th November 2015}}
{{#vardefine:Reference|331694}}
{{#vardefine:Year|2015}}
</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 ==
For bulk deliveries (i.e. 26 pallets) change the ePOD application to allow management of exception items then click a “Deliver All” for the remaining pallets.

== Solution Overview ==
A new ‘Deliver All’ flag will be added to the site maintenance in the ePOD Admin system, this flag will be set as a checkbox and the value (i.e. checked or unchecked) will be included in the site data sent to the devices.

The device will be changed so that if the new ‘Deliver All’ flag is checked when processing a delivery job (or consolidated group of delivery jobs) for which there are outstanding containers (pallets) or products the Job Details tab will include a ‘Deliver All’ button.

If the user clicks this button a confirmation box will be shown with the message “All remaining items will be marked as delivered - please confirm” and tow buttons, an ‘OK’ button and a ‘Cancel’ button.

If the user clicks the ‘Cancel’ button the confirmation box will be removed and no action will be taken (i.e. nothing will be marked as completed).

If the user clicks the ‘OK’ button then any containers (pallets) or products that have not previously been marked as complete or cancelled for the job(s) being processed will be marked as complete. The device will then run the standard job completion processing based on the setup as if all of the items had been manually completed (e.g. prompt for driver signature, customer signature and/or job photos based on setup).

If the ‘Deliver All’ site option is not checked then the ‘Deliver All’ button will not be shown.
If the job(s) being processed are not delivery jobs then the ‘Deliver All’ button will not be shown.
If the job(s) being processed do not have any outstanding items, i.e. all containers (pallets) and products have already been marked as complete or cancelled then the ‘deliver All’ button will not be shown (as with existing functionality the ‘Complete’ button will still be shown).

== Scope ==
Changes will be made in the latest device and server versions only (i.e. versions 3.x.x.x).

The new ‘Deliver All’ flag will affect ALL delivery jobs for the partner’s site.

The deliver all functionality will override any required user entry for containers and/or products (for example any container level user defined fields or setting of non-zero quantities for products with a zero planned quantity).

The deliver all functionality is at the discretion of the driver and will process the outstanding items in the same way as the manual processing (i.e. it will not be possible to determine if a container (pallet) has been manually marked as being delivered via the deliver option or if it has been marked as being delivered via the new deliver all functionality).



= Set-up =

== Pre-requisites ==
There are no set-up pre-requisites specific to this development.

== Menu Structure ==
There is no menu structure set-up required for this development.

== Data ==
In order to make the ‘Deliver All’ option available to the drivers for all delivery jobs for a partner’s site the new ‘Deliver All’ checkbox on the site maintenance page must be checked.



= Functional Description =
== Database / Server ==
A new numeric flag (called EPL_DELIVER_ALL_IND) will be added to the database on the site record (EPOD_SITE) to allow the new “Deliver All” option to be stored for a site.

All data access functions for creating, updating or selecting a site will be updated to include this new flag as will the XML request (used for sending the site data to the PDA’s). This will store (and in the XML report) this value as 1 if the option has been checked or 0 otherwise.

The default value for this new flag should be 0.

Note: It is not necessary to add this field as a search-able item.

== Admin ==
=== Site Maintenance ===
The admin web application includes a Site Maintenance page (within the Administration menu) to allow setting for a partner’s site to be maintained. This page includes a ‘PDA’ tab to allow the site level settings for options that will affect the PDA to be maintained.

A new field will be added to this ‘PDA’ tab of the Site Maintenance page. This field will be shown with the label ‘Deliver All’ and will use a check-box to allow the user to set or un-set this option.

The check-box will include a hint text (shown when hovering over the checkbox) showing the message ‘Using deliver all will override any container or product level data entry’.

Note: The default for new sites or when this option is first added to an existing site will be for this check-box to be un-checked.

== Android Application ==
=== Database / DAL ===
The device’s database will be changed to add the new numeric flag (called EPL_DELIVER_ALL_IND) to the site record (EPOD_SITE) to allow the new “Deliver All” option to be stored for a site.

All data access functions (including those that set the site data based on the data passed from the server) will be updated to include this new flag. The default value for this flag (if one has not been passed from the site) should be 0.

=== Collection / Delivery Screen ===
The collection / delivery screen is used for processing all collections or deliveries. This screen includes a ‘Job Details’ tab which shows the job details for the job (or selected job if processing a consolidated group of jobs).

When processing a job or group of jobs that have not been complete/cancelled if all of the items for the job(s) have been completed or cancelled the ‘Job Details’ tab currently includes a ‘Complete’ button which will complete the job(s) being processed.

The collection / delivery screen will be changed so that when it is opened the device will check the new ‘Deliver All’ option for the current site and the type of job(s) being processed.

If the ‘Deliver All’ option was checked and the job(s) being processed are delivery jobs it will go on to check if there are any containers (pallets) or products for the job(s) that have not been completed or cancelled.

If this check finds there are outstanding containers (pallets) or products for the job(s) being processed then a new ‘Deliver All’ button will be added to the bottom of the Job Details tab, in the same position as the ‘Complete’ button is shown.

If the ‘Deliver All’ option was not checked for the current site or if the job(s) being processed were not delivery jobs or if the job(s) did not have any outstanding items the ‘Deliver All’ button will not be shown.

When the ‘Deliver All’ button is shown clicking it will present the user with a confirmation pop-up. This confirmation pop-up will show the message ‘All remaining items will be marked as delivered - please confirm’ along with an ‘OK’ button and a ‘Cancel’ button.

If the user clicks the ‘Cancel’ button (or uses the devices back button) then the deliver all processing will be cancelled. The confirmation pop-up will be removed and none of the outstanding containers (pallets) or products will be completed at this time.

If the user clicks the ‘OK’ button then the device will validate that the job(s) are ready to be completed. This validation will ignore any outstanding items (as these will be completed) but will include the other job level validation (e.g. check whether any job level user defined fields have been entered or whether the user should confirm no ad-hoc items are required).

If this validation generates any warnings or errors these will be issued before any outstanding items are marked as complete. Warnings would allow the user to abort or continue with the deliver all process, errors would abort the deliver all process (i.e. the user would have to correct the error before clicking the ‘Deliver All’ button again).

If the validation shows the job(s) are ready to be completed then any outstanding containers (pallets) will be marked as complete and any outstanding products will have the actual quantity set to the planned quantity and will be marked as complete.

Once all of the outstanding items have been completed the device will run the standard job completion processing. This will replace the ‘Deliver All’ button with the ‘Complete’ button and perform any job end processing that is required by the data setup (for example capture any signatures that are required, conditionally allow a job photo ti be taken and mark the job as complete before returning to the job list).

Notes:
• Using the deliver all functionality will override any container or product data entry. For example if there are container level user defined fields the user will not be prompted to enter these when using the deliver all functionality. Similarly if there are products with a zero planned quantity the user will not be prompted to enter a quantity for these products when using the deliver all functionality.
• Using the deliver all will not override any job level data entry. For example if there are job level user defined fields which are required entry fields the user will need to enter these fields before the deliver all process can be used.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=ePOD Deliver All functionality
|MenuAccess=
|Prerequisites=An ePOD Admin system and ePOD android application.
|Objective=Ensure the deliver all functionality works as described.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=ePOD Admin
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure the ‘Deliver All’ checkbox is present in the site maintenance page and can be set/unset.
|Result=The checkbox is present and can be checked or unchecked.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=ePOD Android Application
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that with the ‘Deliver All’ option unchecked the ‘Deliver All’ button is not shown for single collection jobs, single delivery jobs, consolidated collection jobs or consolidated delivery jobs.
|Result=The ‘Deliver All’ button is not shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that with the ‘Deliver All’ option checked the ‘Deliver All’ button is not shown for single collection jobs or consolidated collection jobs.
|Result=The ‘Deliver All’ button is not shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that with the ‘Deliver All’ option checked the ‘Deliver All’ button is shown for single delivery jobs or consolidated delivery jobs where there are outstanding containers/products.
|Result=The ‘Deliver All’ button is shown.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that clicking the ‘Deliver All’ button presents the user with a confirmation pop-up and that clicking the ‘Cancel’ button does not complete any containers/items.
|Result=Cancelling the deliver all does not mark any containers/products as complete.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=For a single delivery job with outstanding containers/products (but with no job details UDF) click the ‘Deliver All’ button followed by the ‘OK’ button.
|Result=All containers/products are marked as complete and the job completion is processed (i.e. any signatures that are required are prompted for, any photo allowed is prompted for and the job is completed).
|Remarks=Signature and photo capture are controlled by the data setup against the job group.
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=For a single delivery job with outstanding containers/products which has incomplete required job details UDF click the ‘Deliver All’ button followed by the ‘OK’ button.
|Result=An error is issued for the missing job details UDF, no containers/products are marked as complete.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Repeat the last three tests for a group of consolidated delivery jobs.
|Result=Results are the same as for a single job.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=
|Ref1=
|RefV1=
|RefDate1=
|Ref2=
|RefV2=
|RefDate2=
|Ref3=
|RefV3=
|RefDate3=
|Ref4=
|RefV4=
|RefDate4=
|EREQ=0
|EEST=0
|EFS=0
|ETS=0
|EDEV=0
|ESTT=0
|EIMP=0
|EPM=0
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|PM=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=Y
|FIXEDCOST=0
|Rev1=Murray Middleton
|Rev1Title=Development Manager
|Rev2=
|Rev2Title=
}}</div>
[[Category:{{#var:Client}} FS]]

FS 326965 Partnerlink EPOD Interface

2015-05-22T15:52:31Z

Rmg: v1.0 Ready for issue

<div class="noprint">
{{#vardefine:Client|PART}}
{{#vardefine:ClientName|PartnerLink}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|EPOD-Partner System Interface}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|22nd May 2015}}
{{#vardefine:Reference|326965}}
{{#vardefine:Year|2015}}
</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 =
The document is intended to describe the import and export formats for the Partnerlink Partner systems connecting to the {{#var:System}} system.

== Client Requirement ==

* The Partner system will send messages to the {{#var:System}} system to define Loads and Trips to be completed, as well as indicators of whether this is a pallet network job.
* {{#var:System}} will inform the Partner system that the jobs are completed or cancelled.
* {{#var:System}} will inform any Pallet Network systems that the jobs are completed or cancelled, and send the signature.

== Solution Overview ==
A bespoke interface to and from ''CALIDUS'' EPOD exists for this purpose. This is heavily based around the existing JobShare interface used by the partners.

The summary of the solution requirements are:
# Standing Data (Vehicles, Users, Reason Codes, Job Groups, Sites) will be manually set up within {{#var:System}} - no automated drip-feed of this data will be entered into.
# Sending of data to {{#var:System}} will be through the Partnerlink CSV format.
# Receiving data from {{#var:System}} will be through the OBS XML format.
# The mechanism of sending data will be through Flat File transfer via a shared folder or FTP.
# The mechanism of receiving data will be through webservices (pushed or pulled), Flat File transfer via a shared folder or FTP.
# The sending of data to {{#var:System}} will be controlled through the partner's TMS, at an appropriate trigger point (i.e. when the trips/loads/routes have been confirmed and/or resource-allocated.
# Delivery and Collection jobs for a single load will be merged into a single load when sending data to {{#var:System}}.
# The partner TMS must sort the data in the planned start time, if available, or sequence to be completed, as required by the customer (Partnerlink).
# Amendments to the manifests should be automatically re-exported to {{#var:System}} using the same transfer format.
# {{#var:System}} exporting of completed or cancelled jobs will be through a timed process, expected to be every 5 minutes.
# A Partner code must be assigned and used for the jobs.

The Partnerlink CSV format allows for:
* Collection and Delivery jobs.
* The pallet network and additional pallet network parameters to be identified.
* Automatic creation of pallet identifiers, based on the Partner Job ID and a sequence counting for the number of pallets e.g. a job of 3 pallets for Partner Job ID L0100004573083 for partner L01 will have pallets automatically generated as L010000457308301, L010000457308302 and L010000457308303.
* Automatic creation of pallet identifiers, based on the pallet network parameters provided (currently only Palletforce formats are present - all other formats are assumed to be as standard Partnerlink formats).

This will require the Partner TMS systems to be modified as follows:
* Ensure a single load is created for any manifests for the same vehicle/day/driver.
* Pass the load and job information into {{#var:System}} in the agreed CSV format (described in this document) at trigger points (e.g. Load confirmed, Load amended, etc).
* FTP or copy the file containing the CSV-formatted payload to an agreed folder.
* Create a process for importing data back from the OBS XML format through flat file or webservices.

{{Note}} For details of the standard {{#var:System}} webservices, see the standard documentation referenced in [[#Appendix A: Document References|Appendix A]].

== Scope ==

{{Note}} There are modifications being made to the {{#var:System}} system, both for product enhancement and specifically for the Partnerlink customer that are driving changes into both the import and export functionality described here. Some have not yet been finalised. All known modifications to the schemas have been added to this document. Should any further requirements be known after this document is issued, this document will be revised and reissued at that time.

{{Note}} Future modifications may be made to the exporting of data from {{#var:System}} to the partner TMS systems. When modifications of this nature are made, a new validation schema (XSD) for the XML payload will be issued. The modifications to the partner TMS systems to import this data should be made in such a way that this new XSD can be replaced into the system without program modifications in the future.

{{Note}} It is not deemed necessary at this time to map interfaces from partner TMS systems for Standing Data, as it was agreed that this would be maintained separately and manually within {{#var:System}}. Those flows are:
* Vehicles
* Reason Codes (used when cancelling jobs or pallets, or clausing deliveries)
* Users (Drivers)
* Customers


= Set-up =

== Pre-requisites ==
* Working Partner TMS systems and {{#var:System}} system must be in place and configured as agreed.
* At a minimum, the systems must be able to connect via a shared folder, either through an internet or LAN connection. This must be accessible directly, without user and password information, through a shared user-name on the two servers or domain. This will be coordinated and configured by the Partnerlink IT team.

== Menu Structure ==
None

== Data ==
As described below.



= Functional Description =

== Creating the Messages to {{#var:System}} ==

The sending of data to {{#var:System}} will be controlled through the partner's TMS, at an appropriate trigger point (i.e. when the trips/loads/routes have been confirmed and/or resource-allocated.

A list of all the fields in the interface for Load (Manifest) and Job follows. A full spreadsheet of all the import flows and fields containing all the limitations on length and defaulted values is provided separately.

{| border="1"
|- bgcolor="silver"
!# !!Field Name !!Type !!Max Length !!width="50%"|Notes
|-
|1 ||Requestor ||C ||3 ||Owning Partner - the Partner that owns the JobShare job (if present), else the Delivery or Collection Partner, depending on Job Type
|-
|2 ||Reference 1 ||C ||7 || Partner Job Number
|-
|3 ||Reference 2 ||C ||16 || Customer Reference
|-
|4 ||Reference 3 ||C ||16 || Additional Reference
|-
|5 ||PartnerJobID ||C ||14 || Partnerlink Job ID. This is used to form the pallet ID of the pallets to be delivered (this field plus 2-digit count from 01 to Total Pallets)
|-
|6 ||Job Date ||C ||8 || 
|-
|7 ||Collection Name ||C ||30 ||Collection details - required for POD note (Consignor address)
|-
|8 ||Collection Address 1 ||C ||30 ||Collection details - required for POD note (Consignor address)
|-
|9 ||Collection Address 2 ||C ||30 ||Collection details - required for POD note (Consignor address)
|-
|10 ||Collection Address 3 ||C ||30 ||Collection details - required for POD note (Consignor address)
|-
|11 ||Collection Address 4 ||C ||30 ||Collection details - required for POD note (Consignor address)
|-
|12 ||Collection Postcode ||C ||10 ||Collection details - required for POD note (Consignor address)
|-
|13 ||Collection Contact ||C ||30 ||This field is always to be sent blank, to force the users to enter a signatory on the Mobile Device application.
|-
|14 ||Collection Phone Number ||C ||16 ||Collection details - required for POD note (Consignor address)
|-
|15 ||Collecting Partner ||C ||3 ||Partner code of the partner executing the job (if it is a collection job type)
|-
|16 ||Collection Date ||C ||8 ||Planned Start Date
|-
|17 ||Collection Time ||C ||5 ||Planned Start Time
|-
|18 ||Delivery Name ||C ||30 ||Customer or Job Address
|-
|19 ||Delivery Address 1 ||C ||30 ||Customer or Job Address
|-
|20 ||Delivery Address 2 ||C ||30 ||Customer or Job Address
|-
|21 ||Delivery Address 3 ||C ||30 ||Customer or Job Address
|-
|22 ||Delivery Address 4 ||C ||30 ||Customer or Job Address
|-
|23 ||Delivery Postcode ||C ||10 ||Customer or Job Address
|-
|24 ||Delivery Contact ||C ||30 || This field is always to be sent blank, to force the users to enter a signatory on the Mobile Device application.
|-
|25 ||Delivery Phone Number ||C ||16 || 
|-
|26 ||Delivery Partner ||C ||3 ||Partner code of the partner executing the job (if it's a delivery job type)
|-
|27 ||Delivery Date ||C ||8 ||Planned Start Date
|-
|28 ||Delivery Time ||C ||5 ||Planned Start Time
|-
|29 ||Number of Full Pallets ||N ||  ||Added to form Total Pallets
|-
|30 ||Number of Half Pallets ||N ||  ||Added to form Total Pallets
|-
|31 ||Number of Quarter Pallets ||N ||  ||Added to form Total Pallets
|-
|32 ||Number of OverSize Pallets ||N ||  ||Added to form Total Pallets
|-
|33 ||Weight in Kilos ||N ||  ||Divided by Total Pallets to create a Weight per pallet
|-
|34 ||Manifest Notes 1 ||C ||48 ||Job Instructions
|-
|35 ||Manifest Notes 1 ||C ||48 ||Job Instructions
|-
|36 ||Manifest Notes 1 ||C ||48 ||Office Instructions
|-
|37 ||Manifest Notes 1 ||C ||48 ||Office Instructions
|-
|38 ||Service ||C ||2 ||Service Level
|-
|39 ||Surcharges ||C ||16 || N/A
|-
|40 ||Pallet Spaces ||N ||  || N/A
|-
|41 ||Number of Chep pallets ||N ||  ||N/A
|-
|42 ||Hazardous ||C ||1 ||N/A
|-
|43 ||ADR Number ||N ||5.2 ||N/A
|-
|44 ||Packing Group ||C ||10 ||N/A
|-
|45 ||Category ||C ||10 ||N/A
|-
|46 ||Product name ||C ||10 ||N/A
|-
|47 ||UN Number ||C ||10 ||N/A
|-
|48 ||24 Hour Phone Number ||C ||10 ||N/A
|-
|49 ||Number of Packs ||N ||  ||N/A
|-
|50 ||Number of Litres ||N ||  ||N/A
|-
|51 ||Weight in Kilos ||N ||  ||N/A
|-
|52 ||Value 1 ||N ||  ||N/A
|-
|53 ||Value 2 ||N ||  ||N/A
|-
|54 ||Value 3 ||N ||  ||N/A
|-
|55 ||Spare Text 1 ||C ||6 ||N/A
|-
|56 ||Job Bar Code ||C ||16 ||N/A
|-
|57 ||Manifest Number ||C ||20 || The unique Load ID
|-
|58 ||Account Code ||C ||12 || Used for display in the POD format
|-
|59 ||Trailer Number ||C ||10 ||Trailer ID
|-
|60 ||Driver ID ||C ||10 ||Driver to whom the job has been assigned
|-
|61 ||Vehicle ID ||C ||10 || Vehicle to which the job has been assigned, or blank
|-
|62 ||Job Type ||C ||2 ||Identifying Collection "C" or Delivery "D"
|-
|bgcolor="red"|* ||PF Depot ||C ||10 ||Pallet Tracking System depot code, used when generating Pallet IDs for this pallet network.
|-
|bgcolor="red"|* ||PF Tracking Number ||C ||30 ||Pallet Tracking System tracking number, used when generating Pallet IDs for this pallet network.
|-
|bgcolor="red"|* ||Tracking System ||C ||29 ||This identifies any external pallet tracking system in use for this job. Currently values of "PALLET", "PALLEX", "FORTRACK". If this is not set, and Pallet Tracking System Depot Code and Tracking number are set, defaults to "PALLET" (for the Palletforce network).
|-
|bgcolor="red"|* ||Linked ID ||C ||40 ||If this is set, any jobs with the same linked ID on the same load will be consolidated into a single delivery or collection. {{Note}} Only link jobs of the same type and partner or pallet network.
|-
|bgcolor="red"|* ||Load Information ||C ||500 ||If this is set, shown on the ePOD Device Load Information pop-up.
|}

{{Note}} Those items marked with * above have changed or been added since the last implementation of this interface, or are subject to change at this time.

Notes:
* Job planned start dates and times should be sent through on the message.
* Jobs without planned start dates and times, but with a service level agreement against them i.e. AM or PM deliveries, should have the time defaulted appropriately. For example:
** AM - set to 11:59
** PM - set to 16:59
* The jobs should be sent through in the order in which they should be completed on the manifest.

== Transferring messages to {{#var:System}} ==
The files can be :
* Sent by the partner TMS systems via FTP to an FTP service hosted by OBS Logistics or the partner.
* Pulled by {{#var:System}} via FTP from an FTP service hosted by the partner.
* Copied by {{#var:System}} from a shared folder on the partner TMS systems.
* Copied by the partner TMS systems to a shared folder on {{#var:System}}.
{{Note}} It is expected that this transfer will be via file transfer though a shared folder on the partner TMS systems.

If a flat-file transfer mechanism is chosen, the final destination folder should contain only completed files in the agreed naming convention, not files in the process of being built. The files should be built and copied under a temporary naming convention, before renaming to CSV file (i.e. .tmp files).

The files to be picked up will be named as follows:
* <SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>_<TIME>_<SEQ>.CSV
where
* <SENDER> is the system sending the file - expected to be the name of the partner TMS systems
* <RECEIVER> is the system receiving the file - expected to be "epod"
* <OPERATING_PARTNER> is the operating partner code, i.e. L02, L03, etc.
* <DATE> is the date in YYYYMMDD format
* <TIME> is the time in HHMMSSNN format
* <SEQ> is a unique counting sequence for each file created in a run.

No responses to the files shall be given - the receiving system ({{#var:System}} in this case) will maintain an audit trail to be examined by the user on event of failure. It is the originating partner's responsibility to monitor their export process for success or failure.

Each manifest should be sent in a separate file, to minimise disruption if a single file fails.

The entire content of the file will fail if there is any issue with the format of the file. A single job will fail if there is an issue with the content of that job - all other jobs will process if they are valid.

== Importing into {{#var:System}} ==
A load will be created for the manifest and assigned to the driver and vehicle.

Load start and end times will be set based on the earliest and latest planned start and end times specified against the jobs for that load.

If Load information is provided, this will be added.

If the vehicle does not exist, one will be created with basic information.

Customers will be created for all jobs if they do not already exist. If a customer already exists with a different address, a job-specific address will be created, and the original customer address will not be updated.

Jobs will be created with a specific group per partner (to control partner-specific configuration), unless the job is marked as part of a pallet network, when the configuration will change to that required for the pallet network.

If a linked ID is provided, the jobs with the same linked ID on the load will be consolidated for delivery/collection.

Pallets will be created for the total number of pallets (totalled from the Full, Half, Quarter and Oversize pallets fields), based on the Partner Job ID and a sequence counting for the number of pallets. For example, a job of 3 pallets for Partner Job ID L0100004573083 for partner L01 will have pallets automatically generated as L0100004573083001, L0100004573083002 and L0100004573083003.

Pallets will be generated through different mechanisms, depending on the Pallet Network in use. For example, for Palletforce jobs, these will be created as "506" + PF Depot + ServiceLevel + PF Tracking No + 2-digit sequence. It is expected that any other pallet network/tracking system may employ different naming mechanisms, but these PF fields may be used for any extra data required to be used in the generation of pallet IDs for that system. {{Note}} At this time, only one standard generation mechanism (for Partnerlink) and one bespoke generation mechanism (for Palletforce) exists. If any others are required, these will be undertaken as a change request to the system and charged appropriately.

== Receiving Job Updates from {{#var:System}} ==
A process runs on a timed schedule within the ''CALIDUS'' EPOD application, to pick up any jobs that have been completed and export them to external systems. Alternatively, a data webservice is hosted within {{#var:System}} so that these can be requested on demand, by Job or Date.

== {{#var:System}} Export Message Content ==
A list of all the fields in the interface for Job follows. A full spreadsheet of all the export flows and fields containing all the limitations on length and defaulted values is provided separately.

'''EPOD_JOB'''
{| border="1"
|- bgcolor="silver"
!Name !!width="50%"|Description !! Notes
|-
|EPL_SITE_ID ||Unique Reference for the Site that the Job belongs to ||The assigned Partner Code
|-
|EPL_JOB_ID ||Unique reference for the job. If not provided on Import, this will be generated by EPOD || N/A
|-
|EPL_LOAD_ID ||Unique Reference for the Load that the Job belongs to. If not provided, defaulted from the enclosing EPOD_LOAD || As Sent
|-
|EPL_JOB_TYPE ||D=Delivery, C=Collection, S=Service || As Sent
|-
|EPL_JOB_GROUP ||EPL_JOB_GROUP: This is setup within the Admin system. Each job group has its own settings and will determine how the Job is processed dependant on these settings. || As Sent
|-
|EPL_JOB_INSTRUCTION ||Instructions for the Driver || As Sent
|-
|EPL_JOB_SIGNATURE ||The signature taken from the customer when the job was completed. This is in the form of a Base64-encrypted Jpeg file || 
|-
|EPL_REASON_CODE ||If a job has been cancelled, the Job-level reason code entered by the user is held here. ||  
|-
|EPL_LINKED_REASON ||If the job is a delivery, and a collection of the same load with the same EPL_JOB_CODE is cancelled, this delivery will be cancelled, and this field will be set to "Y" || N/A
|-
|EPL_STATUS ||EPL_STATUS: Status of the job. "C" for any items delivered/collected with any quantity, "X" if cancelled. ||  
|-
|EPL_CUSTOMER_CODE ||Customer Code from external system. If not provided, one will be generated from EPL_CUSTOMER_NAME || As Sent
|-
|EPL_PHOTO_ID ||If cancelled, a photo may have been taken by the user. If so, this field is populated with a unique ID. || N/A
|-
|EPL_PHOTO ||The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file ||  
|-
|EPL_ENG_SIGNATURE ||The signature taken from the driver/engineer when the job was completed, if required. This is in the form of a Base64-encrypted Jpeg file ||  
|-
|EPL_SEQUENCE ||The sequence of the job. This could be the sequence sent on Import, a pre-defined sequence (if one was not provided) or a user-changed value (if enabled) || As Sent
|-
|EPL_START_PLANNED_DATE ||Collection/Delivery Window || As Sent
|-
|EPL_START_PLANNED_TIME ||Collection/Delivery Window || As Sent
|-
|EPL_END_PLANNED_DATE ||Collection/Delivery Window || As Sent
|-
|EPL_END_PLANNED_TIME ||Collection/Delivery Window || As Sent
|-
|EPL_START_ACTUAL_DATE ||The date the user actually chose to start the job. Format: YYYYMMDD ||  
|-
|EPL_START_ACTUAL_TIME ||The time the user actually chose to start the job. Format HHMMSSNN ||  
|-
|EPL_ARRIVAL_DATE ||The date the user indicated they arrived at the destination. Format: YYYYMMDD ||  
|-
|EPL_ARRIVAL_TIME ||The time the user indicated they arrived at the destination. Format HHMMSSNN ||  
|-
|EPL_END_ACTUAL_DATE ||The date the user completed or cancelled the job. Format: YYYYMMDD ||  
|-
|EPL_END_ACTUAL_TIME ||The time the user completed or cancelled the job. Format HHMMSSNN || 
|-
|EPL_DISTANCE_PLANNED ||  || N/A
|-
|EPL_DISTANCE_ACTUAL ||  || N/A
|-
|EPL_DRIVING_TIME ||  || N/A
|-
|EPL_CUSTOMER_NAME ||The Name of the customer || As Sent
|-
|EPL_JOB_ADDRESS ||A flag indicating whether this is a default Customer Address or a specific address for this job alone. || As Sent
|-
|EPL_ADDRESS_1 ||  || As Sent
|-
|EPL_ADDRESS_2 ||  || As Sent
|-
|EPL_ADDRESS_3 ||  || As Sent
|-
|EPL_ADDRESS_4 ||  || As Sent
|-
|EPL_ADDRESS_5 ||  || As Sent
|-
|EPL_POSTCODE ||  || As Sent
|-
|EPL_CONTACT ||  || As Sent
|-
|EPL_TELEPHONE ||  || As Sent
|-
|EPL_EMAIL ||  || As Sent
|-
||EPL_INVOICED ||A flag indicating the driver ticked an Invoiced box when completing the job. ||  
|-
|EPL_CUST_SIGNATORY ||The name of the customer signatory on the job. ||  
|-
|EPL_JOB_CODE ||External reference for the Job. This element can be used to link a collection and delivery together under the same reference. So, if an order is being collected at A and delivered at B, there are 2 jobs, each with a unique Job ID, but with the same Job Code. Optionally, EPOD will keep the Delivery leg of a linked job updated with the information captured from the collection. || As Sent
|-
|EPL_CUST_REF ||Customer's Order Reference || As Sent
|-
|EPL_OFFICE_INSTRUCTION ||Instructions for Admin staff || As Sent
|-
|EPL_SIGNED_UNCHECKED ||An indication whether the customer signed for the goods without checking them first. Note that this field can be used for any check-box entry, as this is configurable. ||  
|-
|EPL_SO_NUMBER ||Sales Order Reference. || As Sent
|-
|EPL_TNCS ||An XML fragment, displaying the Terms and Conditions agreed to by the customer when signing for the goods. This can also include up to 3 configurable check-boxes that the user may check. ||  
|-
|EPL_ORDER_DATE ||Date Order created - defaulted to the date the order was received if not provided || As Sent
|-
|EPL_ORDER_TIME ||Time Order Created || As Sent
|-
|EPL_SALES_CONTACT ||The operative who took the order. Can be used as a display field for documentation || As Sent
|-
|EPL_USER_NOTES ||Optional Notes entered by the driver while completing the job. ||  
|-
|EPL_OWNER_NAME ||Can be used as a display field for documentation, or indicating another Site ID that owns the job that is being executed by this site. || As Sent
|-
|EPL_SERVICE_LEVEL ||Display field, containing Service Level text || As Sent
|-
|EPL_TRAILER_ID ||To be used if the vehicle being used to fulfil the job is a Tractor unit, and a trailer ID has been entered by the user. ||  
|-
|EPL_PF_DEPOT ||External Pallet System Depot Code || As Sent
|-
|EPL_PF_TRACKING_NO ||External Pallet System Tracking code, used to generate External Pallet System Pallet IDs || As Sent
|-
|EPL_EXT_REF ||An external reference for the host system if required. For Partnerlink, this will be the PartnerJobID. || As Sent
|-
|EPL_LAST_CHANGED_DATE ||  ||  
|-
|EPL_LAST_CHANGED_TIME ||  ||  
|-
|EPL_JOB_STATUS ||A Job Status entered by the driver, usually to indicate whether a job should be re-scheduled. Optional. ||  
|-
|EPL_COL_DATE ||Collection Date || As Sent
|-
|EPL_UDF_JOBDETS ||Contains user-defined fields entered when processing Collections and Deliveries on the Job Details tab, in UDF formatted XML || N/A
|-
|EPL_ACCOUNT ||Account Name || N/A
|-
|EPL_LINKED_ID ||An identifier that informs the system that this job has been linked (consolidated) with other jobs manually by the driver. The format is irrelevant - if multiple jobs on the same load have the same linked ID, they were consolidated. || As Sent
|-
|EPL_TIMEZONE ||TimeZone || N/A
|-
|EPL_LOADING_TYPE ||Controls whether this job is seen to be a Loading task at a depot (Job Type = "C") or unloading at a depot (Job Type = "D"). Values can be "Y" or "N" or "" - only "Y" indicates whether the job is a loading/unloading task. || As Sent
|-
|EPL_GENERATED ||Indicates whether the job is generated within C-EPOD. || N/A
|-
|EPL_SWAP_VEHICLE ||Whether the vehicle was swapped || N/A
|-
|EPOD_JOB_ADDRESS ||Any Job address against the job, if different to the customer address. Consisting of the following tags if present: || As Sent
|-
|EPL_ADDRESS_TYPE ||"D" or "C" || As Sent
|-
|EPL_ADDRESS_1 ||  || As Sent
|-
|EPL_ADDRESS_2 ||  || As Sent
|-
|EPL_ADDRESS_3 ||  || As Sent
|-
|EPL_ADDRESS_4 ||  || As Sent
|-
|EPL_ADDRESS_5 ||  || As Sent
|-
|EPL_POSTCODE ||  || As Sent
|-
|EPL_CONTACT ||  || As Sent
|-
|EPL_TELEPHONE ||  || As Sent
|-
|EPL_EMAIL ||  || As Sent
|-
|EPOD_CONTAINERS ||Contains a series of EPOD_CONTAINER objects, detailing all the deliverable items on this load. If there are loose products, there will also be a container with ID '000000000000000' holding these products. ||  
|-
|EPOD_SERVICES ||If the job is a Service, this object contains a series of EPOD_SERVICE objects, each holding all the service-related information for each service item. In that case, no containers or products will be specified against the job. || N/A
|}

'''EPOD_CONTAINER'''
{| border="1"
|+ align="bottom"|''Sample Code Setup''
|- bgcolor="silver"
!Name !!width="50%"|Description !! Notes
|-
|EPL_SITE_ID ||Unique Reference for the Site that the Job belongs to || As Containing Job
|-
|EPL_JOB_ID ||Unique reference for the job. If not provided on Import, this will be generated by EPOD || As Containing Job
|-
|EPL_CONTAINER_ID ||EPL_CONTAINER_ID: The unique identifier for a container. || The Partnerlink Pallet ID, as generated from the import file (dependent on pallet network).
|-
|EPL_STATUS ||EPL_STATUS: Status of the current Container. C-Completed, X-Cancelled. ||  
|-
|EPL_SEQUENCE ||A sequence for the containers to be shown on the user's device. || As Sent
|-
|EPL_CONTAINER_PACKAGE_CODE ||  || As Sent
|-
|EPL_CONTAINER_PACKAGE_DESC ||  || As Sent
|-
|EPL_REASON_CODE ||If a job has been cancelled, the reason code entered by the user is held here. ||  
|-
|EPL_LINKED_REASON ||If the job is a delivery, and a collection of this container on the same load with the same EPL_JOB_CODE is cancelled, this container will be cancelled, and this field will be set to "Y" || N/A
|-
|EPL_PHOTO_ID ||If cancelled, or received with a clause, a photo may have been taken by the user. If so, this field is populated with a unique ID. || N/A
|-
|EPL_PHOTO ||The photo taken for the exception. This is in the form of a Base64-encrypted Jpeg file ||  
|-
|EPL_GROSS_WEIGHT ||Gross Weight || As Sent
|-
|EPL_DESCRIPTION_LONG ||  || As Sent
|-
|EPL_CODE_1 ||Multi-purpose field || As Sent
|-
|EPL_CODE_2 ||Multi-purpose field || As Sent
|-
|EPL_CODE_3 ||Multi-purpose field || As Sent
|-
|EPL_LAST_CHANGED_DATE ||  || N/A
|-
|EPL_LAST_CHANGED_TIME ||  || N/A
|-
|EPL_CUST_COMMENTS ||Optional entry by the user, indicating whether the customer has identified an issue with the received item (a claused receipt). If present, the customer may have requested an image, which would be contained in EPL_PHOTO. ||  
|-
|EPL_VALID_DATE ||The date up until the contents of the package are valid - controls warnings at delivery. || N/A
|-
|EPL_VALID_TIME ||The time up until the contents of the package are valid - controls warnings at delivery. || N/A
|-
|EPL_TYPE ||Shows whether this container was Ad Hoc Scanned ("A") or was preplanned (blank) || N/A
|-
|EPOD_PRODUCTS ||Contains a series of EPOD_PRODUCTS objects, detailing the products within the container, or loose products || N/A
|}

{{Note}} Regarding Signature and Photo data formats in this message:
This data is stored and transmitted as a text string, Base64-encrypted. This data can be decoded and saved as binary data once received if required.

A sample of a single job with a single pallet is shown below:
<pre>
<EPOD_EXPORT_JOB>
<EPOD_JOBS>
<EPOD_JOB>
<EPL_SITE_ID>L03</EPL_SITE_ID>
<EPL_JOB_ID>0000000001</EPL_JOB_ID>
<EPL_LOAD_ID>000000000002</EPL_LOAD_ID>
<EPL_JOB_TYPE>D</EPL_JOB_TYPE>
<EPL_JOB_GROUP>L03</EPL_JOB_GROUP>
<EPL_JOB_INSTRUCTION>Very Fragile Parcel..Please handle with Care</EPL_JOB_INSTRUCTION>
<EPL_JOB_SIGNATURE>R0lGODlh4AB4APcA...NKdJTY4EBAA7</EPL_JOB_SIGNATURE>
<EPL_REASON_CODE></EPL_REASON_CODE>
<EPL_LINKED_REASON>N</EPL_LINKED_REASON>
<EPL_STATUS>C</EPL_STATUS>
<EPL_CUSTOMER_CODE>OBS</EPL_CUSTOMER_CODE>
<EPL_PHOTO_ID></EPL_PHOTO_ID>
<EPL_ENG_SIGNATURE></EPL_ENG_SIGNATURE>
<EPL_SEQUENCE>1</EPL_SEQUENCE>
<EPL_START_PLANNED_DATE>20111108</EPL_START_PLANNED_DATE>
<EPL_START_PLANNED_TIME>12000000</EPL_START_PLANNED_TIME>
<EPL_END_PLANNED_DATE>0</EPL_END_PLANNED_DATE>
<EPL_END_PLANNED_TIME>0</EPL_END_PLANNED_TIME>
<EPL_START_ACTUAL_DATE>20111108</EPL_START_ACTUAL_DATE>
<EPL_START_ACTUAL_TIME>10490000</EPL_START_ACTUAL_TIME>
<EPL_END_ACTUAL_DATE>20111108</EPL_END_ACTUAL_DATE>
<EPL_END_ACTUAL_TIME>10520000</EPL_END_ACTUAL_TIME>
<EPL_DISTANCE_PLANNED>0</EPL_DISTANCE_PLANNED>
<EPL_DISTANCE_ACTUAL>0</EPL_DISTANCE_ACTUAL>
<EPL_DRIVING_TIME>0</EPL_DRIVING_TIME>
<EPL_CUSTOMER_NAME>OBS Logistics</EPL_CUSTOMER_NAME>
<EPL_JOB_ADDRESS>N</EPL_JOB_ADDRESS>
<EPL_ADDRESS_1>Southern Gateway</EPL_ADDRESS_1>
<EPL_ADDRESS_2>Speke Boulevard</EPL_ADDRESS_2>
<EPL_ADDRESS_3>Liverpool</EPL_ADDRESS_3>
<EPL_ADDRESS_4>Merseyside</EPL_ADDRESS_4>
<EPL_ADDRESS_5></EPL_ADDRESS_5>
<EPL_POSTCODE>L24 9HZ</EPL_POSTCODE>
<EPL_CONTACT>Xavier Wai</EPL_CONTACT>
<EPL_TELEPHONE>01514480331</EPL_TELEPHONE>
<EPL_EMAIL>x.y@obs-logistics.co.uk</EPL_EMAIL>
<EPL_INVOICED></EPL_INVOICED>
<EPL_CUST_SIGNATORY></EPL_CUST_SIGNATORY>
<EPL_JOB_CODE>L03</EPL_JOB_CODE>
<EPL_CUST_REF></EPL_CUST_REF>
<EPL_OFFICE_INSTRUCTION></EPL_OFFICE_INSTRUCTION>
<EPL_SIGNED_UNCHECKED></EPL_SIGNED_UNCHECKED>
<EPL_SO_NUMBER></EPL_SO_NUMBER>
<EPL_TNCS></EPL_TNCS>
<EPL_ORDER_DATE>0</EPL_ORDER_DATE>
<EPL_SALES_CONTACT></EPL_SALES_CONTACT>
<EPL_USER_NOTES></EPL_USER_NOTES>
<EPL_OWNER_NAME></EPL_OWNER_NAME>
<EPL_SERVICE_LEVEL></EPL_SERVICE_LEVEL>
<EPL_TRAILER_ID></EPL_TRAILER_ID>
<EPL_EXT_REF></EPL_EXT_REF>
<EPL_LAST_CHANGED_DATE>20120314</EPL_LAST_CHANGED_DATE>
<EPL_LAST_CHANGED_TIME>9420098</EPL_LAST_CHANGED_TIME>
<EPOD_CONTAINERS>
<EPOD_CONTAINER>
<EPL_SITE_ID>L03</EPL_SITE_ID>
<EPL_JOB_ID>0000000001</EPL_JOB_ID>
<EPL_CONTAINER_ID>000000000000001</EPL_CONTAINER_ID>
<EPL_SEQUENCE>0</EPL_SEQUENCE>
<EPL_CONTAINER_PACKAGE_CODE>XX</EPL_CONTAINER_PACKAGE_CODE>
<EPL_CONTAINER_PACKAGE_DESC>Pallet</EPL_CONTAINER_PACKAGE_DESC>
<EPL_REASON_CODE></EPL_REASON_CODE>
<EPL_LINKED_REASON></EPL_LINKED_REASON>
<EPL_STATUS>C</EPL_STATUS>
<EPL_PHOTO_ID></EPL_PHOTO_ID>
<EPL_CUST_COMMENTS></EPL_CUST_COMMENTS>
<EPL_GROSS_WEIGHT>120</EPL_GROSS_WEIGHT>
<EPL_DESCRIPTION_LONG></EPL_DESCRIPTION_LONG>
<EPL_CODE_1>1</EPL_CODE_1>
<EPL_CODE_2></EPL_CODE_2>
<EPL_CODE_3></EPL_CODE_3>
<EPL_LAST_CHANGED_DATE>20120614</EPL_LAST_CHANGED_DATE>
<EPL_LAST_CHANGED_TIME>16362322</EPL_LAST_CHANGED_TIME>
</EPOD_CONTAINER>
</EPOD_CONTAINERS>
<EPOD_SERVICES></EPOD_SERVICES>
</EPOD_JOB>
</EPOD_JOBS>
</EPOD_EXPORT_JOB>
</pre>
{{Note}} The signature has been shortened for the purposes of this document.

== {{#var:System}} Export Mechanism ==
The files can be:
* Pulled by the partner TMS system via FTP from an FTP service hosted by OBS.
* Sent by {{#var:System}} via FTP to an FTP service hosted by OBS Logistics or the partner TMS provider.
* Copied by {{#var:System}} to a shared folder between {{#var:System}} and the partner TMS system.
* Copied by the partner TMS system from a shared folder between {{#var:System}} and the partner TMS system.
* Pushed to a webservice hosted by the partner TMS system.
{{note}} It is expected that this transfer will be via file transfer though a shared folder on the partner TMS system.

Regardless of the mechanism chosen above, the final destination folder should contain only completed files in the agreed naming convention, not files being built. The files should be built and copied under a temporary naming convention, before renaming to CSV file (i.e. .tmp files).

The files to be picked up will be named as follows:
* <SENDER>_<RECEIVER>_<OPERATING_PARTNER>_<DATE>_<TIME>_<SEQ>.xml
where
* <SENDER> is the system sending the file - expected to be "epod".
* <RECEIVER> is the system receiving the file - expected to be the name of the partner TMS systems.
* <OPERATING_PARTNER> is the operating partner code, i.e. L02, L03, etc.
* <DATE> is the date in YYYYMMDD format
* <TIME> is the time in HHMMSSNN format
* <SEQ> is a unique counting sequence for each file created in a run.

No responses to the files shall be given - the receiving system (the partner TMS system in this case) will maintain an audit trail to be examined by the user on event of failure.

{{#var:System}} export mechanism includes facility to automatically resend failed transmissions.

Each job will be sent in a separate file, to minimise disruption if a single file fails.


{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1=JobShare Mapping v1.1.xlsx
|RefV1=1.1
|RefDate1=20/05/2015
|Ref2=EPOD Export Mapping v3.11.xlsx
|RefV2=3.11
|RefDate2=20/05/2015
|Ref3=FS 291096 Interface with CALIDUS ePOD v1.0.pdf
|RefV3=1.0
|RefDate3=5/02/2015
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Matt Turner
|Rev1Title=OBS Account Manager
|Rev2=Murray Middleton
|Rev2Title=OBS Product Development Manager
}}</div>
[[Category:{{#var:Client}} FS]]

FS 313475 PROD Orders on Multiple Trips

2014-03-18T08:19:45Z

Rmg: Update version for last edit

<div class="noprint">
{{#vardefine:Client|PROD}}
{{#vardefine:ClientName|PROD}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|PROD Orders on Multiple Trips}}
{{#vardefine:Version|0.3}}
{{#vardefine:Date|5th February 2014}}
{{#vardefine:Reference|313475}}
{{#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 included functionality to be specified is shown below:
:Currently ePOD does not support a single C-TMS order being delivered across multiple trips – an order/job can only exist on one load. Current job ID/ Job code is not sufficient to support this.

== Solution Overview ==
The problems with orders on multiple trips exist in both ''CALIDUS'' TMS' and EPOD's interfaces, as follows:
;''CALIDUS'' TMS:
* EPL_JOB_ID is currently set to a repeating value in the interface (from OMS_REF and a Job Type). The interface must be changed to remove this in a configurable fashion, and the following field mapping to take its place:
** OMS_REF to EPL_JOB_CODE
** SO_REF to EPL_CUST_REF
;{{#var:System}}:
* The system currently identifies jobs as duplicates (and therefore requiring an update) by EPL_SITE_ID and EPL_JOB_ID. If EPL_JOB_ID is not provided in the interface (as will now be the case with the ''CALIDUS'' TMS interface changes), the system currently uses a combination of EPL_SITE_ID, EPL_JOB_CODE and EPL_JOB_TYPE. This is not appropriate when the order (EPL_JOB_CODE) can exist on multiple loads (trips) at the same time, for example for cross-dock or inter-depot transfers. This will change to be EPL_SITE_ID, EPL_LOAD_ID, EPL_JOB_CODE and EPL_JOB_TYPE and will be added to the generic webservices import process and auto-import process.
* A unique index will be added to the database to allow this search to be quick. Additionally, large volumes of data will be checked on multiple client sites to ensure that this will not cause issues. If so, this index will still be added but will be made repeating instead.
* If the job is found this way, the job will be updated. If not, a new job will be created.
* If a job is removed from a load, the job will have the load removed if this combination of EPL_SITE/EPL_LOAD/EPL_JOB_CODE/EPL_JOB_TYPE does not already exist, wherein it will be deleted instead.
* Due to the changes in the data being sent to {{#var:System}}, it is now no longer appropriate to display EPL_JOB_ID as the main reference for most customers, as this is generally a system-generated field. Instead, {{#var:System}} will be modified to allow the selection of several fields as the main identifier displayed on the system, at a Site level. This will allow the selection from the following references: EPL_JOB_ID, EPL_JOB_CODE, EPL_SO_REF, EPL_CUST_REF, EPL_EXT_REF. This change will remain backward-compatible by ensuring the existing values of Y and N map to EPL_JOB_CODE and EPL_JOB_ID respectively.
* Loads are unique within ''CALIDUS'' TMS without Site, and it is capable of dynamically changing the site on a Load. The Import mechanism will allow for this by checking whether a particular Site is configured to allow this kind of change (through a new configuration flag):
** If configured, add the following processing at the start of the processing:
** Search for the Load as normal.
** If not found and the Site is configured to allow this kind of change (through a new configuration flag):
*** Search for the Load with a wild-card (%) in the Site parameter, but with the passed-in Trip ID.
*** If found, and the site is different on the XML to the record, delete this load (and all contained jobs) under the old Site ID.
** Continue adding the load under the new Site.

== Scope ==
{{Note|This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.}}
{{Note|''CALIDUS'' TMS functionality is mentioned only by reference in this solution - see elsewhere for specification of the changes to that system.}}


= Set-up =

== Pre-requisites ==
* A working {{#var:System}} system.
* A working ''CALIDUS'' TMS system, accessible to the {{#var:System}} system.

== Menu Structure ==
None

== Data ==
None


= Functional Description =
== Database/DAL ==
Table EPOD_SITE requires the following modification:
* EPL_DISP_JOB_CODE - amended to nvarchar(40), NOT NULL DEFAULT 'N', no specific values.
* EPL_SYSTEM_LOADS_UNIQUE - nvarchar(1), NOT NULL DEFAULT 'N', VALUES 'Y', 'N'.
Existing packages will be modified to allow the creating, editing and selecting of the flags, including but not limited to:
*EPOD_SITE_INSERT
*EPOD_SITE_SELECT
*EPOD_SITE_SELECT_UPDATED_DATA
*EPOD_SITE_UPDATE

Table EPOD_JOB requires the following modification:
* Add a unique index to the table as follows:
** EPL_SITE_ID
** EPL_LOAD_ID
** EPL_JOB_CODE
** EPL_JOB_TYPE
{{Note}} Large volumes of customers' data must be checked on multiple client sites to ensure that this will not cause issues. If this is the case, this index will still be added but will be made repeating instead.

== Import Changes ==
The dataservice webservices (ePOD_DataService.asmx and ePOD_DataService2.asmx) and the AutoImport application will need to change how jobs are imported. The messages affected are:
* AutoImport and ePOD_DataService:
** EPOD_XML_IMPORT

The functional changes required are:
* Add EPL_LOAD ID when checking whether a Job exists without using EPL_JOB_ID. I.e. this becomes EPL_SITE_ID, EPL_LOAD_ID, EPL_JOB_CODE, EPL_JOB_TYPE. Add this to generic webservices import process and auto-import process.
* If the job is found this way, the job will be updated. If not, a new job will be created.
* If jobs are removed from a load (i.e. when completed processing all the jobs on the XML, there are still Jobs remaining on the Load that were not in the XML), these job will be deleted.
* Additionally, if a trip is sent through with no jobs, or a deletion notification, the entire Load and Jobs within it shall be deleted as well. {{Note}} The existing method PDA_LOAD.Delete() does not delete the jobs - it specifically orphans them, so the deletion of jobs should be issued first, followed by the deletion of the load.

Loads are unique within ''CALIDUS'' TMS without Site, and it is capable of dynamically changing the Site on a Load. The Import mechanism will allow for this by checking whether a particular Site is configured to allow this kind of change (through the new EPL_SYSTEM_LOADS_UNIQUE flag being set to 'Y')
* If configured, add the following processing at the start of the processing:
* Search for the Load as normal.
* If not found and the Site is configured to allow this kind of change (through a new configuration flag):
** Search for the Load with a wild-card (%) in the Site parameter, but with the passed-in Trip ID.
** If found, and the site is different on the XML to the record, delete this load (and all contained jobs) under the old Site ID.
* Continue adding the load under the new Site.

== Admin Changes ==
The Site screen (site_header.aspx) will be modified as follows when editing or adding new data:
* PDA tab:
** The existing label "Display Job Code" will become "Display Job As"
** The check box will become a drop-down list with the following values:
*** "EPL_JOB_ID", description "Job ID"
*** "EPL_JOB_CODE", description "Job Code/Order No"
*** "EPL_SO_NUMBER", description "S/O No"
*** "EPL_CUST_REF", description "Customer's Ref"
*** "EPL_EXT_REF", description "External System Ref"
** Existing data will be translated as follows, when saving:
*** Value "N" becomes "EPL_JOB_ID"
*** Value "Y" becomes "EPL_JOB_CODE"
** {{Note}} As this element is becoming a drop-down list rather than a check-box entry, it must be repositioned in the screen with the other drop-down-lists. Ensure as part of this change that the existing check-boxes still line up and are displayed neatly.
* Admin tab:
** A new flag will be added to update the new flag EPL_SYSTEM_LOADS_UNIQUE, labelled as "Loads Unique Within System". This will be added as a check-box, where checked sets the value to 'Y' when saved, and unchecked sets the value to 'N'.

[[file:FS_313475_1.PNG|border|600px]]<br />Site Admin screen<br />

== PDA Changes ==
=== PDA DAL/Database Changes ===
The following changes will be made to the EPOD_SITE table:
* EPL_DISP_JOB_CODE – This will become a 40 character field. The default value will now be 'Y'.
This new field should be added to every procedure as part of the PDA_SITE DAL object.

The following fields will be added to the EPOD_JOB table:
* EPL_SO_NUMBER - This is a 40 character field. The default value is "" (a null string).
* EPL_CUST_REF - This is a 30 character field. The default value is "" (a null string).
* EPL_EXT_REF - This is a 30 character field. The default value is "" (a null string).
These new fields should be added to every procedure as part of the PDA_SITE DAL object.

The existing functionality to set the value of the property EPL_DISP_JOB_ID in PDA_JOB based on the setting of EPL_PDA_DIS_JOB_CODE in PDA_SITE will be modified to use the name of the field specified in the EPL_PDA_DIS_JOB_CODE field, with the following exceptions:
* Value "N" becomes "EPL_JOB_ID"
* Value "Y" becomes "EPL_JOB_CODE"

{{Note}} In the event that the chosen data field has no data in it (i.e. is blank, a null string), then the system should default to the following fields, in this order, if they are not blank themselves:
* EPL_JOB_CODE
* EPL_JOB_ID



{{Doc_Appendix
|Appendix=A
|Estimate=Y
|Glossary=EPOD
|Ref1=
|RefV1=
|RefDate1=
|REQ=0
|EST=0
|FS=0.5
|TS=0
|DEV=5
|ST=0.5
|IMP=0.25
|EREQ=0
|EEST=0
|EFS=0
|ETS=0
|EDEV=0
|ESTT=0
|EIMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=Y
|Rev1=Matt Tipping
|Rev1Title=Project Manager
|Rev2Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 313475 PROD Orders on Multiple Trips

2014-03-18T08:18:51Z

Rmg: Clarification of PDA setting of EPL_DISP_JOB_ID and removing some redundant options

<div class="noprint">
{{#vardefine:Client|PROD}}
{{#vardefine:ClientName|PROD}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|PROD Orders on Multiple Trips}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|5th February 2014}}
{{#vardefine:Reference|313475}}
{{#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 included functionality to be specified is shown below:
:Currently ePOD does not support a single C-TMS order being delivered across multiple trips – an order/job can only exist on one load. Current job ID/ Job code is not sufficient to support this.

== Solution Overview ==
The problems with orders on multiple trips exist in both ''CALIDUS'' TMS' and EPOD's interfaces, as follows:
;''CALIDUS'' TMS:
* EPL_JOB_ID is currently set to a repeating value in the interface (from OMS_REF and a Job Type). The interface must be changed to remove this in a configurable fashion, and the following field mapping to take its place:
** OMS_REF to EPL_JOB_CODE
** SO_REF to EPL_CUST_REF
;{{#var:System}}:
* The system currently identifies jobs as duplicates (and therefore requiring an update) by EPL_SITE_ID and EPL_JOB_ID. If EPL_JOB_ID is not provided in the interface (as will now be the case with the ''CALIDUS'' TMS interface changes), the system currently uses a combination of EPL_SITE_ID, EPL_JOB_CODE and EPL_JOB_TYPE. This is not appropriate when the order (EPL_JOB_CODE) can exist on multiple loads (trips) at the same time, for example for cross-dock or inter-depot transfers. This will change to be EPL_SITE_ID, EPL_LOAD_ID, EPL_JOB_CODE and EPL_JOB_TYPE and will be added to the generic webservices import process and auto-import process.
* A unique index will be added to the database to allow this search to be quick. Additionally, large volumes of data will be checked on multiple client sites to ensure that this will not cause issues. If so, this index will still be added but will be made repeating instead.
* If the job is found this way, the job will be updated. If not, a new job will be created.
* If a job is removed from a load, the job will have the load removed if this combination of EPL_SITE/EPL_LOAD/EPL_JOB_CODE/EPL_JOB_TYPE does not already exist, wherein it will be deleted instead.
* Due to the changes in the data being sent to {{#var:System}}, it is now no longer appropriate to display EPL_JOB_ID as the main reference for most customers, as this is generally a system-generated field. Instead, {{#var:System}} will be modified to allow the selection of several fields as the main identifier displayed on the system, at a Site level. This will allow the selection from the following references: EPL_JOB_ID, EPL_JOB_CODE, EPL_SO_REF, EPL_CUST_REF, EPL_EXT_REF. This change will remain backward-compatible by ensuring the existing values of Y and N map to EPL_JOB_CODE and EPL_JOB_ID respectively.
* Loads are unique within ''CALIDUS'' TMS without Site, and it is capable of dynamically changing the site on a Load. The Import mechanism will allow for this by checking whether a particular Site is configured to allow this kind of change (through a new configuration flag):
** If configured, add the following processing at the start of the processing:
** Search for the Load as normal.
** If not found and the Site is configured to allow this kind of change (through a new configuration flag):
*** Search for the Load with a wild-card (%) in the Site parameter, but with the passed-in Trip ID.
*** If found, and the site is different on the XML to the record, delete this load (and all contained jobs) under the old Site ID.
** Continue adding the load under the new Site.

== Scope ==
{{Note|This functionality will be developed in the Android application only and will not be available in the Windows Mobile application.}}
{{Note|''CALIDUS'' TMS functionality is mentioned only by reference in this solution - see elsewhere for specification of the changes to that system.}}


= Set-up =

== Pre-requisites ==
* A working {{#var:System}} system.
* A working ''CALIDUS'' TMS system, accessible to the {{#var:System}} system.

== Menu Structure ==
None

== Data ==
None


= Functional Description =
== Database/DAL ==
Table EPOD_SITE requires the following modification:
* EPL_DISP_JOB_CODE - amended to nvarchar(40), NOT NULL DEFAULT 'N', no specific values.
* EPL_SYSTEM_LOADS_UNIQUE - nvarchar(1), NOT NULL DEFAULT 'N', VALUES 'Y', 'N'.
Existing packages will be modified to allow the creating, editing and selecting of the flags, including but not limited to:
*EPOD_SITE_INSERT
*EPOD_SITE_SELECT
*EPOD_SITE_SELECT_UPDATED_DATA
*EPOD_SITE_UPDATE

Table EPOD_JOB requires the following modification:
* Add a unique index to the table as follows:
** EPL_SITE_ID
** EPL_LOAD_ID
** EPL_JOB_CODE
** EPL_JOB_TYPE
{{Note}} Large volumes of customers' data must be checked on multiple client sites to ensure that this will not cause issues. If this is the case, this index will still be added but will be made repeating instead.

== Import Changes ==
The dataservice webservices (ePOD_DataService.asmx and ePOD_DataService2.asmx) and the AutoImport application will need to change how jobs are imported. The messages affected are:
* AutoImport and ePOD_DataService:
** EPOD_XML_IMPORT

The functional changes required are:
* Add EPL_LOAD ID when checking whether a Job exists without using EPL_JOB_ID. I.e. this becomes EPL_SITE_ID, EPL_LOAD_ID, EPL_JOB_CODE, EPL_JOB_TYPE. Add this to generic webservices import process and auto-import process.
* If the job is found this way, the job will be updated. If not, a new job will be created.
* If jobs are removed from a load (i.e. when completed processing all the jobs on the XML, there are still Jobs remaining on the Load that were not in the XML), these job will be deleted.
* Additionally, if a trip is sent through with no jobs, or a deletion notification, the entire Load and Jobs within it shall be deleted as well. {{Note}} The existing method PDA_LOAD.Delete() does not delete the jobs - it specifically orphans them, so the deletion of jobs should be issued first, followed by the deletion of the load.

Loads are unique within ''CALIDUS'' TMS without Site, and it is capable of dynamically changing the Site on a Load. The Import mechanism will allow for this by checking whether a particular Site is configured to allow this kind of change (through the new EPL_SYSTEM_LOADS_UNIQUE flag being set to 'Y')
* If configured, add the following processing at the start of the processing:
* Search for the Load as normal.
* If not found and the Site is configured to allow this kind of change (through a new configuration flag):
** Search for the Load with a wild-card (%) in the Site parameter, but with the passed-in Trip ID.
** If found, and the site is different on the XML to the record, delete this load (and all contained jobs) under the old Site ID.
* Continue adding the load under the new Site.

== Admin Changes ==
The Site screen (site_header.aspx) will be modified as follows when editing or adding new data:
* PDA tab:
** The existing label "Display Job Code" will become "Display Job As"
** The check box will become a drop-down list with the following values:
*** "EPL_JOB_ID", description "Job ID"
*** "EPL_JOB_CODE", description "Job Code/Order No"
*** "EPL_SO_NUMBER", description "S/O No"
*** "EPL_CUST_REF", description "Customer's Ref"
*** "EPL_EXT_REF", description "External System Ref"
** Existing data will be translated as follows, when saving:
*** Value "N" becomes "EPL_JOB_ID"
*** Value "Y" becomes "EPL_JOB_CODE"
** {{Note}} As this element is becoming a drop-down list rather than a check-box entry, it must be repositioned in the screen with the other drop-down-lists. Ensure as part of this change that the existing check-boxes still line up and are displayed neatly.
* Admin tab:
** A new flag will be added to update the new flag EPL_SYSTEM_LOADS_UNIQUE, labelled as "Loads Unique Within System". This will be added as a check-box, where checked sets the value to 'Y' when saved, and unchecked sets the value to 'N'.

[[file:FS_313475_1.PNG|border|600px]]<br />Site Admin screen<br />

== PDA Changes ==
=== PDA DAL/Database Changes ===
The following changes will be made to the EPOD_SITE table:
* EPL_DISP_JOB_CODE – This will become a 40 character field. The default value will now be 'Y'.
This new field should be added to every procedure as part of the PDA_SITE DAL object.

The following fields will be added to the EPOD_JOB table:
* EPL_SO_NUMBER - This is a 40 character field. The default value is "" (a null string).
* EPL_CUST_REF - This is a 30 character field. The default value is "" (a null string).
* EPL_EXT_REF - This is a 30 character field. The default value is "" (a null string).
These new fields should be added to every procedure as part of the PDA_SITE DAL object.

The existing functionality to set the value of the property EPL_DISP_JOB_ID in PDA_JOB based on the setting of EPL_PDA_DIS_JOB_CODE in PDA_SITE will be modified to use the name of the field specified in the EPL_PDA_DIS_JOB_CODE field, with the following exceptions:
* Value "N" becomes "EPL_JOB_ID"
* Value "Y" becomes "EPL_JOB_CODE"

{{Note}} In the event that the chosen data field has no data in it (i.e. is blank, a null string), then the system should default to the following fields, in this order, if they are not blank themselves:
* EPL_JOB_CODE
* EPL_JOB_ID



{{Doc_Appendix
|Appendix=A
|Estimate=Y
|Glossary=EPOD
|Ref1=
|RefV1=
|RefDate1=
|REQ=0
|EST=0
|FS=0.5
|TS=0
|DEV=5
|ST=0.5
|IMP=0.25
|EREQ=0
|EEST=0
|EFS=0
|ETS=0
|EDEV=0
|ESTT=0
|EIMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=Y
|Rev1=Matt Tipping
|Rev1Title=Project Manager
|Rev2Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 314696 Allow Zero Quantity Products

2014-02-19T12:31:27Z

Rmg: Change log number

<div class="noprint">
{{#vardefine:Client|BM}}
{{#vardefine:ClientName|Brett Martin}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Allow Zero Quantity Products}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|11th February 2014}}
{{#vardefine:Reference|314696}}
{{#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 application requires a customised style created for Brett Martin.

The current functionality for collection or delivery of DU’s (products) which have a zero planned quantity needs to allow the setting of a zero or non-zero quantity.

== Solution Overview ==
A Brett Martin style (with green/white colour scheme and a Brett martin logo) will be created.

The existing collection/delivery functionality for DU’s (products) with a zero planned quantity will be changed to allow a zero quantity to be entered when confirming a product.

== Scope ==
* These changes will be made in the latest version of the CALIDUS ePOD product only.
* The changes will be made to the Android CALIDUS ePOD client only.



= Set-up =

== Pre-requisites ==
There are no set-up pre-requisites specific to this development.

== Menu Structure ==
There is no menu structure set-up required for this development.

== Data ==
Once the new ‘Force Non-zero Product Quantities’ flag has been added to the job groups maintenance page this will need to be unchecked to allow zero quantities to be used for products with a zero planned quantity.


= Functional Description =
== Database / Server ==
A new flag (called EPL_FORCE_PROD_QTY) will be added to the database on the job group record (EPOD_JOB_GROUPS) to allow the new “Force Non-Zero Product Quantities” option to be stored for a job group.

All data access functions for creating, updating or selecting a job group will be updated to include this new flag as will the XML request (used for sending the job group data to the PDA’s). This will store (and in the XML report) this value as “Y” if the option has been checked or “N” otherwise.

== ePOD Admin ==
The admin web application includes a job groups maintenance page. This page uses a details pop-up (with multiple tabs) to allow the user to set the options associated with a job group.

This details pop-up will be changed to include a new “Force Non-Zero Product Quantities” flag. This flag will appear in the PDA tab of the details pop-up and will be a check-box style option (i.e. can be checked or not checked). This will allow the flag to be set for new job groups or changed for existing job groups. There will not be any functionality to allow the user to search for job groups based on this flag.

== Android Client ==
=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== Job Details Product Tab ===
When processing a delivery or collection job which contains products (DU’s) the PDA will include a products tab which will list the products for this job. The user can select a product to collect / deliver by clicking or long-pressing on the product in the products list (and the selecting the deliver or collect option), entering the product code in the product text box or scanning the product code.

When clicking or long-pressing a product in the products list the user is either taken to the set product quantity screen or presented with a list of options.

If the product has a non-zero planned quantity (i.e. the PDA has already been informed of the quantity that should be delivered or collected) then clicking or long-pressing on a product will display list of the following options:
Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will mark this product as having the planned quantity delivered or collected.
Change Quantity – Selecting this option allows the user to set the quantity to be delivered or collected, along with a reason for the discrepancy from the planned quantity and confirm the delivery/collection.
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

This list of options will not be changed.

If the product had a zero planned quantity then clicking the product would call the set product quantity screen to allow the user to set the quantity being delivered or collected and confirm the delivery/collection (see next section for details on the set product quantity screen).

If the product had a zero planned quantity then long-pressing on a product will display list of options. This list does not currently include a deliver/collect option and does include a comments option (not required for the Brett Martin functionality). This will be changed to add the deliver/collect option and remove the comments option for Brett Martin users. This will mean the list will show the following options:

Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will call the set product quantity screen, i.e. the same clicking on the product (see next section for details on the set quantity screen).
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

=== Job Details Product Tab ===
When called this page allows the user to set the quantity for a product and confirm it as delivered or collected. This page is only called for products with a zero planned quantity (i.e. where the quantity is not known in advance).

The current functionality will only allow the product to be confirmed as delivered or collected once a non-zero quantity has been entered.

This will be changed so that the new ‘Force Non-Zero Product Quantities’ flag for the job group associated with this job will determine if zero is accepted as a valid value. If this flag has been set (i.e. checked in the maintenance page) then the system will continue to force the user to enter a non-zero quantity before allowing confirmation. If this flag is not set (i.e. is un-checked in the maintenance screen) then this screen will allow the user to confirm the delivery / collection of this product if they have entered a numeric value, including zero, for the quantity.

In order to confirm the delivery / collection the user will have to enter a quantity, i.e. this can not be left blank (regardless of the ‘Force Non-Zero Product Quantities’). The page will only allow the confirmation if the value is a numeric integer value, this can not contain characters or decimal places.


{{Doc_Appendix
|Appendix=C
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 313776 Brett Martin ePOD Requirements]]
|RefV3=0.2
|RefDate3=12/12/2013
|REQ=0
|EST=0
|FS=0.75
|TS=0.0
|DEV=2.75
|ST=0.50
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Scott
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} FS]]

FS 313776 Allow Zero Quantity Products

2014-02-19T12:29:00Z

Rmg: moved FS 313776 Allow Zero Quantity Products to FS 314696 Allow Zero Quantity Products: Moved to separate log number

#REDIRECT [[FS 314696 Allow Zero Quantity Products]]

FS 314696 Allow Zero Quantity Products

2014-02-19T12:29:00Z

Rmg: moved FS 313776 Allow Zero Quantity Products to FS 314696 Allow Zero Quantity Products: Moved to separate log number

<div class="noprint">
{{#vardefine:Client|BM}}
{{#vardefine:ClientName|Brett Martin}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Allow Zero Quantity Products}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|11th February 2014}}
{{#vardefine:Reference|313776}}
{{#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 application requires a customised style created for Brett Martin.

The current functionality for collection or delivery of DU’s (products) which have a zero planned quantity needs to allow the setting of a zero or non-zero quantity.

== Solution Overview ==
A Brett Martin style (with green/white colour scheme and a Brett martin logo) will be created.

The existing collection/delivery functionality for DU’s (products) with a zero planned quantity will be changed to allow a zero quantity to be entered when confirming a product.

== Scope ==
* These changes will be made in the latest version of the CALIDUS ePOD product only.
* The changes will be made to the Android CALIDUS ePOD client only.



= Set-up =

== Pre-requisites ==
There are no set-up pre-requisites specific to this development.

== Menu Structure ==
There is no menu structure set-up required for this development.

== Data ==
Once the new ‘Force Non-zero Product Quantities’ flag has been added to the job groups maintenance page this will need to be unchecked to allow zero quantities to be used for products with a zero planned quantity.


= Functional Description =
== Database / Server ==
A new flag (called EPL_FORCE_PROD_QTY) will be added to the database on the job group record (EPOD_JOB_GROUPS) to allow the new “Force Non-Zero Product Quantities” option to be stored for a job group.

All data access functions for creating, updating or selecting a job group will be updated to include this new flag as will the XML request (used for sending the job group data to the PDA’s). This will store (and in the XML report) this value as “Y” if the option has been checked or “N” otherwise.

== ePOD Admin ==
The admin web application includes a job groups maintenance page. This page uses a details pop-up (with multiple tabs) to allow the user to set the options associated with a job group.

This details pop-up will be changed to include a new “Force Non-Zero Product Quantities” flag. This flag will appear in the PDA tab of the details pop-up and will be a check-box style option (i.e. can be checked or not checked). This will allow the flag to be set for new job groups or changed for existing job groups. There will not be any functionality to allow the user to search for job groups based on this flag.

== Android Client ==
=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== Job Details Product Tab ===
When processing a delivery or collection job which contains products (DU’s) the PDA will include a products tab which will list the products for this job. The user can select a product to collect / deliver by clicking or long-pressing on the product in the products list (and the selecting the deliver or collect option), entering the product code in the product text box or scanning the product code.

When clicking or long-pressing a product in the products list the user is either taken to the set product quantity screen or presented with a list of options.

If the product has a non-zero planned quantity (i.e. the PDA has already been informed of the quantity that should be delivered or collected) then clicking or long-pressing on a product will display list of the following options:
Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will mark this product as having the planned quantity delivered or collected.
Change Quantity – Selecting this option allows the user to set the quantity to be delivered or collected, along with a reason for the discrepancy from the planned quantity and confirm the delivery/collection.
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

This list of options will not be changed.

If the product had a zero planned quantity then clicking the product would call the set product quantity screen to allow the user to set the quantity being delivered or collected and confirm the delivery/collection (see next section for details on the set product quantity screen).

If the product had a zero planned quantity then long-pressing on a product will display list of options. This list does not currently include a deliver/collect option and does include a comments option (not required for the Brett Martin functionality). This will be changed to add the deliver/collect option and remove the comments option for Brett Martin users. This will mean the list will show the following options:

Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will call the set product quantity screen, i.e. the same clicking on the product (see next section for details on the set quantity screen).
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

=== Job Details Product Tab ===
When called this page allows the user to set the quantity for a product and confirm it as delivered or collected. This page is only called for products with a zero planned quantity (i.e. where the quantity is not known in advance).

The current functionality will only allow the product to be confirmed as delivered or collected once a non-zero quantity has been entered.

This will be changed so that the new ‘Force Non-Zero Product Quantities’ flag for the job group associated with this job will determine if zero is accepted as a valid value. If this flag has been set (i.e. checked in the maintenance page) then the system will continue to force the user to enter a non-zero quantity before allowing confirmation. If this flag is not set (i.e. is un-checked in the maintenance screen) then this screen will allow the user to confirm the delivery / collection of this product if they have entered a numeric value, including zero, for the quantity.

In order to confirm the delivery / collection the user will have to enter a quantity, i.e. this can not be left blank (regardless of the ‘Force Non-Zero Product Quantities’). The page will only allow the confirmation if the value is a numeric integer value, this can not contain characters or decimal places.


{{Doc_Appendix
|Appendix=C
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 313776 Brett Martin ePOD Requirements]]
|RefV3=0.2
|RefDate3=12/12/2013
|REQ=0
|EST=0
|FS=0.75
|TS=0.0
|DEV=2.75
|ST=0.50
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Scott
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} FS]]

FS 314696 Allow Zero Quantity Products

2014-02-14T11:02:12Z

Rmg: Initial draft

<div class="noprint">
{{#vardefine:Client|BM}}
{{#vardefine:ClientName|Brett Martin}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Allow Zero Quantity Products}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|11th February 2014}}
{{#vardefine:Reference|313776}}
{{#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 application requires a customised style created for Brett Martin.

The current functionality for collection or delivery of DU’s (products) which have a zero planned quantity needs to allow the setting of a zero or non-zero quantity.

== Solution Overview ==
A Brett Martin style (with green/white colour scheme and a Brett martin logo) will be created.

The existing collection/delivery functionality for DU’s (products) with a zero planned quantity will be changed to allow a zero quantity to be entered when confirming a product.

== Scope ==
* These changes will be made in the latest version of the CALIDUS ePOD product only.
* The changes will be made to the Android CALIDUS ePOD client only.



= Set-up =

== Pre-requisites ==
There are no set-up pre-requisites specific to this development.

== Menu Structure ==
There is no menu structure set-up required for this development.

== Data ==
Once the new ‘Force Non-zero Product Quantities’ flag has been added to the job groups maintenance page this will need to be unchecked to allow zero quantities to be used for products with a zero planned quantity.


= Functional Description =
== Database / Server ==
A new flag (called EPL_FORCE_PROD_QTY) will be added to the database on the job group record (EPOD_JOB_GROUPS) to allow the new “Force Non-Zero Product Quantities” option to be stored for a job group.

All data access functions for creating, updating or selecting a job group will be updated to include this new flag as will the XML request (used for sending the job group data to the PDA’s). This will store (and in the XML report) this value as “Y” if the option has been checked or “N” otherwise.

== ePOD Admin ==
The admin web application includes a job groups maintenance page. This page uses a details pop-up (with multiple tabs) to allow the user to set the options associated with a job group.

This details pop-up will be changed to include a new “Force Non-Zero Product Quantities” flag. This flag will appear in the PDA tab of the details pop-up and will be a check-box style option (i.e. can be checked or not checked). This will allow the flag to be set for new job groups or changed for existing job groups. There will not be any functionality to allow the user to search for job groups based on this flag.

== Android Client ==
=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== PDA Login and Style ===
A new Brett martin style will be created. This will use green colouring for the buttons and heading sections within the application and the login page will include the Brett Martin logo.

=== Job Details Product Tab ===
When processing a delivery or collection job which contains products (DU’s) the PDA will include a products tab which will list the products for this job. The user can select a product to collect / deliver by clicking or long-pressing on the product in the products list (and the selecting the deliver or collect option), entering the product code in the product text box or scanning the product code.

When clicking or long-pressing a product in the products list the user is either taken to the set product quantity screen or presented with a list of options.

If the product has a non-zero planned quantity (i.e. the PDA has already been informed of the quantity that should be delivered or collected) then clicking or long-pressing on a product will display list of the following options:
Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will mark this product as having the planned quantity delivered or collected.
Change Quantity – Selecting this option allows the user to set the quantity to be delivered or collected, along with a reason for the discrepancy from the planned quantity and confirm the delivery/collection.
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

This list of options will not be changed.

If the product had a zero planned quantity then clicking the product would call the set product quantity screen to allow the user to set the quantity being delivered or collected and confirm the delivery/collection (see next section for details on the set product quantity screen).

If the product had a zero planned quantity then long-pressing on a product will display list of options. This list does not currently include a deliver/collect option and does include a comments option (not required for the Brett Martin functionality). This will be changed to add the deliver/collect option and remove the comments option for Brett Martin users. This will mean the list will show the following options:

Deliver or Collect – Depending on whether this is a delivery or a collection job. Selecting this option will call the set product quantity screen, i.e. the same clicking on the product (see next section for details on the set quantity screen).
Cancel – Selecting this option allows the user to specify a reason for the cancellation and cancel the delivery/collection of this product.
Close – Selecting this option closes the options list with making any changes.

=== Job Details Product Tab ===
When called this page allows the user to set the quantity for a product and confirm it as delivered or collected. This page is only called for products with a zero planned quantity (i.e. where the quantity is not known in advance).

The current functionality will only allow the product to be confirmed as delivered or collected once a non-zero quantity has been entered.

This will be changed so that the new ‘Force Non-Zero Product Quantities’ flag for the job group associated with this job will determine if zero is accepted as a valid value. If this flag has been set (i.e. checked in the maintenance page) then the system will continue to force the user to enter a non-zero quantity before allowing confirmation. If this flag is not set (i.e. is un-checked in the maintenance screen) then this screen will allow the user to confirm the delivery / collection of this product if they have entered a numeric value, including zero, for the quantity.

In order to confirm the delivery / collection the user will have to enter a quantity, i.e. this can not be left blank (regardless of the ‘Force Non-Zero Product Quantities’). The page will only allow the confirmation if the value is a numeric integer value, this can not contain characters or decimal places.


{{Doc_Appendix
|Appendix=C
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 313776 Brett Martin ePOD Requirements]]
|RefV3=0.2
|RefDate3=12/12/2013
|REQ=0
|EST=0
|FS=0.75
|TS=0.0
|DEV=2.75
|ST=0.50
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Scott
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} FS]]

FS 311908 Configurable Pre-Work Checks

2013-12-10T16:37:45Z

Rmg: Update to test plan for completion of service item.

<div class="noprint">
{{#vardefine:Client|LANE}}
{{#vardefine:ClientName|Lanemark}}
{{#vardefine:System|''CALIDUS'' eSERV}}
{{#vardefine:Doc_Title|Configurable Pre-Work Checks}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|4th October 2013}}
{{#vardefine:Reference|311908 309371-4/5}}
{{#vardefine:Year|2013}}
</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 user will be forced to enter Risk Assessment details before being allowed to start work against a Serviceable item, unless those checks have been completed before-hand.

The Risk Assessment checks are shown in [[#Appendix A: Risk Assessment Form|Appendix A]]

== Solution Overview ==
A '''Pre-Work Checks''' button will be shown in section 4 (titled ''Risk Assessment'') - this pops up the Pre-work checks pop-up form:

All contents will be configured, entered like Vehicle Checks, through a scrolling frame.

The items required during Risk Assessment will be based on the existing form - some changes will be made to the Risk Control section.
* Person responsible for your safety - text entry - required.
* Brief description of work to be done - text entry - required.
* Hazards associated section:
** This will list a number of check-boxes, identical to those on the sheet. It is not required that all be checked.
** Risks (Other) - text entry - optional.
* Overall Risk Assessment - drop-down list of: High/Medium/Low - required.
* Risk Control section (Measures to be taken...):
** A number of check-boxes will be identified for the user to tick here, to make entry of this easier than it currently is on the sheet. These are optional.
** Risk Control (Other) - text entry - optional.

On saving the checks, the user will be asked to confirm that these are now completed (through a '''Complete''' button). If so, they will be marked as such and the user will be allowed to exit and the title of the '''Risk Assessment''' button will be updated to show the status (Complete or Incomplete).

The user will also be offered a button to indicate that the checks are not required (through a '''Not Required''' button). If this is clicked, the user will be asked to confirm this and, if so, the checks will be marked as not required, but completed anyway.

Initially, the user will not be able to select any tab except Job Details and Info. Only when the Risk Assessment checks for this particular Serviceable Item are complete (or marked as pre-completed) will the user be able to select any other tabs for this Serviceable item.

{{Note}} These configurable Pre-Work Checks are not search-able, exportable or reportable within {{#var:System}}, but can be displayable in the Admin client or on the Service Report.

== Scope ==
* These changes will be made in the latest version of the {{#var:System}} product only.
* The changes will be made to the Android eSERV client only.
* {{Warning}} This change requires that the UDF modifications and Multiple Serviceable Items are complete first - see [[#Appendix_D:_Quote_.26_Document_References|Appendix D]] for references.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
Table EPOD_UDF_CONFIG must have new records created for the site:
* EPL_DESCRIPTION = "Risk Assessment checks"
** EPL_KEY_TYPE = "S"
** EPL_KEY_VAL = "{EPL_SITE_ID}"
** EPL_CONFIG_TYPE = "PREWORK"
** EPL_UDF_FIELDS - see [[#Appendix B: Risk Assessment Configuration|Appendix B]]


= Functional Description =
== Android Client ==
{{Note}} The UDF Modifications change should already be complete - among many other items, this made the following changes to the PDA Service process:
{{comment|text=
The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing in the configuration setting.

The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

...
''(on the Diagnosis tab)''

The validation against the '''OK''' button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:
* If PDA_UDF_PREWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Pre-work checks, referred to by the Name element of the Pre-work configuration. The device should return the user to the services screen on clearing this message.
...
* If PDA_UDF_PREWORK is not null, save the resulting XML from the Pre-work UDF object into the new Service field EPL_UDF_PREWORK.
|sign=[[FS 311636 UDF Modifications]]|date=11/9/2013 11:32:53}}

There will be some slight modifications to this here, to allow for Multiple Serviceable Items processing, along with the changes required for this functionality.

The Pre-work button will be labelled with the NAME attribute of the FORM in the XML, plus a status in parentheses, based on the Confirm attribute of the UDF created, one of:
* Blank - "Incomplete"
* C - The label of the '''Complete''' button
* X - the label of the '''Cancel''' button
{{Note}} The '''Ignore''' button alone will not change the status, as this is the equivalent to the Android Back button.

These Pre-work Checks can be completed for all Serviceable items, or just for the one in progress, so a user may choose to complete one, move to the next serviceable item, complete those checks, move on, etc, until all are complete. Therefore, when displaying this button for the first time, the screen must check the value of the CONFIRM attribute of the FORM tag from the UDF XML stored in EPL_UDF_PREWORK.

When the screen has been exited with a '''Cancel''' or '''Confirm''' button press, the Confirm parameter will have been stored against the object and the items validated. This parameter must also be stored as an attribute against the FORM tag (CONFIRM="X|I|C") on the returned XML. This will also change the label of the Pre-work button, to reflect the new status.

When Cancelling (using an X-type button), the XML must still be built and saved, but without the users' answers (i.e. as the passed-in configuration). As before, the CONFIRM attribute must be added and the Pre-work label changed.

{{Note}} The XML returned to the FORM should be placed in EPL_UDF_PREWORK. This should be saved if the user chooses to exit the service or if the user changes Serviceable Items, through the functionality designed for Multiple Serviceable Items.

The Android BACK key may be used to back out of the Pre-work screen - in this case, a confirmation back to the user be made (standard, not configurable) informing them that all entered data will be lost. If not confirmed, the user will be returned to the Pre-work screen. If confirmed, the user will be returned to the Info tab, nothing will be validated or saved, including the Confirm attribute, which should still be set to blank.

If the Pre-work status has been set to 'C' or 'X', the user should NOT be allowed back in to change the status - the checks have been entered and confirmed by the user and may not be changed.

If the FORM tag REQUIRED attribute has been set on the configuration XML to 'Y', the Pre-work checks MUST be complete before any work (other than Information-gathering) begins - the screen should not allow moving onto any tab other than Job Details and Information (i.e. any tab index greater than 1). If the user attempts to do this, an error should be displayed and the user should be returned to the Info or Job Details tab.


= Appendix A: Risk Assessment Form =
[[File:REQ_309187_RISK.jpg|600px|border]]


= Appendix B: Risk Assessment Configuration =
<FORM NAME="Risk Assessment" REQUIRED="Y">
<FIELD ID="PERSON">
<TEXT>Person on site responsible for your safety</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>Y</REQUIRED>
</FIELD>
<FIELD ID="DESCRIPTION">
<TEXT>Brief description of work to be done</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>Y</REQUIRED>
</FIELD>
<FIELD ID="HAZARDS">
<TEXT>Identify hazards associated</TEXT>
<FORMAT>X</FORMAT>
<REQUIRED>N</REQUIRED>
<ITEMS>
<ITEM>Existing live pipework, services and plant</ITEM>
<ITEM>Adverse weather conditions</ITEM>
<ITEM>Chemicals/Substances present in existing System</ITEM>
<ITEM>Transport of Items to and from site</ITEM>
<ITEM>Tripping/Slipping</ITEM>
<ITEM>Fall from height (platform)</ITEM>
<ITEM>Transport of vehicles around site</ITEM>
<ITEM>Mechanical lifting and moving</ITEM>
<ITEM>Use of Substances hazardous to health</ITEM>
<ITEM>Use of portable electrical tools</ITEM>
<ITEM>Ventilation</ITEM>
<ITEM>Contact with hot and cold surfaces</ITEM>
<ITEM>Fire (including static electricity</ITEM>
<ITEM>Storage/Stacking</ITEM>
<ITEM>Falling from height (ladder)</ITEM>
<ITEM>Solitary working</ITEM>
<ITEM>Manual handling of materials</ITEM>
<ITEM>Disposal of substances</ITEM>
<ITEM>Explosion</ITEM>
<ITEM>Lighting</ITEM>
<ITEM>Noise</ITEM>
<ITEM>Electricity</ITEM>
<ITEM>Hand Tools</ITEM>
<ITEM>Radiation sources</ITEM>
<ITEM>Confined Spaces</ITEM>
<ITEM>Fall of materials</ITEM>
<ITEM>General Dust / Debris</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="HAZARDS_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>N</REQUIRED>
</FIELD>
<FIELD ID="RISK_ASSESSMENT">
<TEXT>Overall Assessment of Risk</TEXT>
<FORMAT>DDL</FORMAT>
<REQUIRED>Y</REQUIRED>
<ITEMS>
<ITEM DEFAULT="Y">LOW</ITEM>
<ITEM>MED</ITEM>
<ITEM>HIGH</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL">
<TEXT>Risk Control Measures</TEXT>
<FORMAT>X</FORMAT>
<REQUIRED>N</REQUIRED>
<ITEMS>
<ITEM>Boots</ITEM>
<ITEM>Hard Hat</ITEM>
<ITEM>Hi Vis</ITEM>
<ITEM>Chemical Boots</ITEM>
<ITEM>Googles</ITEM>
<ITEM>Glasses</ITEM>
<ITEM>Gloves</ITEM>
<ITEM>Chemical Gloves</ITEM>
<ITEM>Harness</ITEM>
<ITEM>Lanyard</ITEM>
<ITEM>Trolley</ITEM>
<ITEM>Checmical Suit</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>N</REQUIRED>
</FIELD>
<BUTTON CONFIRM="Are the risks now considered to be accepted?">
<TYPE>C</TYPE>
<TEXT>Complete</TEXT>
</BUTTON>
<BUTTON CONFIRM="Please confirm that a Method Statement has been produced.">
<TYPE>X</TYPE>
<TEXT>Not Required</TEXT>
</BUTTON>
</FORM>


= Appendix C: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test specific Lanemark Pre-work Checks UDF configuration and functionality.
|MenuAccess=Services
|Prerequisites=Ensure that the site being used has the UDF configuration as described in the [[#Data|Data]] section and [[#Appendix B: Risk Assessment Configuration|Appendix B]]. Ensure there are single- and multiple-item jobs (with at least 3 items) to check.
|Objective=To test that: Required checks are completed; validation is forced on the checks; validation is forced so that they are entered before any other information; status is displayed correctly and; data is updated correctly.
}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA - Process
|Notes=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a single-item service job. press onto the Diagnosis tab.
|Result=A validation error should be displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the '''Pre-work''' button label
|Result=It says "Risk Assessment (Incomplete)"
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=The pre-work pop-up is shown. The label says Risk Assessment. All fields required are present in a scrolling form. There are 2 buttons: '''Complete''' and '''Not Required'''
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back key
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back button and Confirm the confirmation dialogue.
|Result=The Info tab is shown again. The label still says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Re-enter the Pre-work pop-up. press the '''Complete''' button.
|Result=A validation error should be displayed, as not all required information has been entered.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter all required information. press the '''Complete''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press "No"
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Complete''' button and press '''Yes''' on the confirmation dialogue.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new single-item job. Press the '''Pre-work''' button. Press the '''Not Required''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on. It is marked as not required.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new multiple-item job. On the first item, press the '''Pre-work''' button. Enter all required information. Press the '''Complete''' button and confirm.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button.
|Result=The next service item is shown. The Pre-work label says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Prev''' button.
|Result=The previous service item is shown. The Pre-work label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Back key and confirm. Press the '''Prev''' button, complete any required information (e.g. model on the info tab or comments on the diagnosis tab). Move to the Diagnosis tab and press '''Complete'''.
|Result=The service is completed, the next incomplete service is displayed.
|Remarks= |PassFail= }} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=D
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 309371 Lanemark eSERV Requirements]]
|RefV3=0.4
|RefDate3=29/08/2013
|Ref4=[[FS 311636 UDF Modifications]]
|RefV4=0.3
|RefDate4=05/09/2013
|Ref5=[[FS 311856 Multiple Serviceable Items]]
|RefV5=0.1
|RefDate5=10/09/2013
|REQ=0
|EST=0
|FS=0.5
|TS=0.0
|DEV=3.5
|ST=0.5
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Taylor
|Rev1Title=OBS Project Manager
|Rev2=Jeff Foster
|Rev2Title=Client Representative
|Rev3=Alan Thompson
|Rev3Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 311908 Configurable Pre-Work Checks

2013-11-29T09:37:44Z

Rmg: Update pre-work XML for risk control and change use of skipable to required

<div class="noprint">
{{#vardefine:Client|LANE}}
{{#vardefine:ClientName|Lanemark}}
{{#vardefine:System|''CALIDUS'' eSERV}}
{{#vardefine:Doc_Title|Configurable Pre-Work Checks}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|4th October 2013}}
{{#vardefine:Reference|311908 309371-4/5}}
{{#vardefine:Year|2013}}
</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 user will be forced to enter Risk Assessment details before being allowed to start work against a Serviceable item, unless those checks have been completed before-hand.

The Risk Assessment checks are shown in [[#Appendix A: Risk Assessment Form|Appendix A]]

== Solution Overview ==
A '''Pre-Work Checks''' button will be shown in section 4 (titled ''Risk Assessment'') - this pops up the Pre-work checks pop-up form:

All contents will be configured, entered like Vehicle Checks, through a scrolling frame.

The items required during Risk Assessment will be based on the existing form - some changes will be made to the Risk Control section.
* Person responsible for your safety - text entry - required.
* Brief description of work to be done - text entry - required.
* Hazards associated section:
** This will list a number of check-boxes, identical to those on the sheet. It is not required that all be checked.
** Risks (Other) - text entry - optional.
* Overall Risk Assessment - drop-down list of: High/Medium/Low - required.
* Risk Control section (Measures to be taken...):
** A number of check-boxes will be identified for the user to tick here, to make entry of this easier than it currently is on the sheet. These are optional.
** Risk Control (Other) - text entry - optional.

On saving the checks, the user will be asked to confirm that these are now completed (through a '''Complete''' button). If so, they will be marked as such and the user will be allowed to exit and the title of the '''Risk Assessment''' button will be updated to show the status (Complete or Incomplete).

The user will also be offered a button to indicate that the checks are not required (through a '''Not Required''' button). If this is clicked, the user will be asked to confirm this and, if so, the checks will be marked as not required, but completed anyway.

Initially, the user will not be able to select any tab except Job Details and Info. Only when the Risk Assessment checks for this particular Serviceable Item are complete (or marked as pre-completed) will the user be able to select any other tabs for this Serviceable item.

{{Note}} These configurable Pre-Work Checks are not search-able, exportable or reportable within {{#var:System}}, but can be displayable in the Admin client or on the Service Report.

== Scope ==
* These changes will be made in the latest version of the {{#var:System}} product only.
* The changes will be made to the Android eSERV client only.
* {{Warning}} This change requires that the UDF modifications and Multiple Serviceable Items are complete first - see [[#Appendix_D:_Quote_.26_Document_References|Appendix D]] for references.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
Table EPOD_UDF_CONFIG must have new records created for the site:
* EPL_DESCRIPTION = "Risk Assessment checks"
** EPL_KEY_TYPE = "S"
** EPL_KEY_VAL = "{EPL_SITE_ID}"
** EPL_CONFIG_TYPE = "PREWORK"
** EPL_UDF_FIELDS - see [[#Appendix B: Risk Assessment Configuration|Appendix B]]


= Functional Description =
== Android Client ==
{{Note}} The UDF Modifications change should already be complete - among many other items, this made the following changes to the PDA Service process:
{{comment|text=
The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing in the configuration setting.

The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

...
''(on the Diagnosis tab)''

The validation against the '''OK''' button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:
* If PDA_UDF_PREWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Pre-work checks, referred to by the Name element of the Pre-work configuration. The device should return the user to the services screen on clearing this message.
...
* If PDA_UDF_PREWORK is not null, save the resulting XML from the Pre-work UDF object into the new Service field EPL_UDF_PREWORK.
|sign=[[FS 311636 UDF Modifications]]|date=11/9/2013 11:32:53}}

There will be some slight modifications to this here, to allow for Multiple Serviceable Items processing, along with the changes required for this functionality.

The Pre-work button will be labelled with the NAME attribute of the FORM in the XML, plus a status in parentheses, based on the Confirm attribute of the UDF created, one of:
* Blank - "Incomplete"
* C - The label of the '''Complete''' button
* X - the label of the '''Cancel''' button
{{Note}} The '''Ignore''' button alone will not change the status, as this is the equivalent to the Android Back button.

These Pre-work Checks can be completed for all Serviceable items, or just for the one in progress, so a user may choose to complete one, move to the next serviceable item, complete those checks, move on, etc, until all are complete. Therefore, when displaying this button for the first time, the screen must check the value of the CONFIRM attribute of the FORM tag from the UDF XML stored in EPL_UDF_PREWORK.

When the screen has been exited with a '''Cancel''' or '''Confirm''' button press, the Confirm parameter will have been stored against the object and the items validated. This parameter must also be stored as an attribute against the FORM tag (CONFIRM="X|I|C") on the returned XML. This will also change the label of the Pre-work button, to reflect the new status.

When Cancelling (using an X-type button), the XML must still be built and saved, but without the users' answers (i.e. as the passed-in configuration). As before, the CONFIRM attribute must be added and the Pre-work label changed.

{{Note}} The XML returned to the FORM should be placed in EPL_UDF_PREWORK. This should be saved if the user chooses to exit the service or if the user changes Serviceable Items, through the functionality designed for Multiple Serviceable Items.

The Android BACK key may be used to back out of the Pre-work screen - in this case, a confirmation back to the user be made (standard, not configurable) informing them that all entered data will be lost. If not confirmed, the user will be returned to the Pre-work screen. If confirmed, the user will be returned to the Info tab, nothing will be validated or saved, including the Confirm attribute, which should still be set to blank.

If the Pre-work status has been set to 'C' or 'X', the user should NOT be allowed back in to change the status - the checks have been entered and confirmed by the user and may not be changed.

If the FORM tag REQUIRED attribute has been set on the configuration XML to 'Y', the Pre-work checks MUST be complete before any work (other than Information-gathering) begins - the screen should not allow moving onto any tab other than Job Details and Information (i.e. any tab index greater than 1). If the user attempts to do this, an error should be displayed and the user should be returned to the Info or Job Details tab.


= Appendix A: Risk Assessment Form =
[[File:REQ_309187_RISK.jpg|600px|border]]


= Appendix B: Risk Assessment Configuration =
<FORM NAME="Risk Assessment" REQUIRED="Y">
<FIELD ID="PERSON">
<TEXT>Person on site responsible for your safety</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>Y</REQUIRED>
</FIELD>
<FIELD ID="DESCRIPTION">
<TEXT>Brief description of work to be done</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>Y</REQUIRED>
</FIELD>
<FIELD ID="HAZARDS">
<TEXT>Identify hazards associated</TEXT>
<FORMAT>X</FORMAT>
<REQUIRED>N</REQUIRED>
<ITEMS>
<ITEM>Existing live pipework, services and plant</ITEM>
<ITEM>Adverse weather conditions</ITEM>
<ITEM>Chemicals/Substances present in existing System</ITEM>
<ITEM>Transport of Items to and from site</ITEM>
<ITEM>Tripping/Slipping</ITEM>
<ITEM>Fall from height (platform)</ITEM>
<ITEM>Transport of vehicles around site</ITEM>
<ITEM>Mechanical lifting and moving</ITEM>
<ITEM>Use of Substances hazardous to health</ITEM>
<ITEM>Use of portable electrical tools</ITEM>
<ITEM>Ventilation</ITEM>
<ITEM>Contact with hot and cold surfaces</ITEM>
<ITEM>Fire (including static electricity</ITEM>
<ITEM>Storage/Stacking</ITEM>
<ITEM>Falling from height (ladder)</ITEM>
<ITEM>Solitary working</ITEM>
<ITEM>Manual handling of materials</ITEM>
<ITEM>Disposal of substances</ITEM>
<ITEM>Explosion</ITEM>
<ITEM>Lighting</ITEM>
<ITEM>Noise</ITEM>
<ITEM>Electricity</ITEM>
<ITEM>Hand Tools</ITEM>
<ITEM>Radiation sources</ITEM>
<ITEM>Confined Spaces</ITEM>
<ITEM>Fall of materials</ITEM>
<ITEM>General Dust / Debris</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="HAZARDS_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>N</REQUIRED>
</FIELD>
<FIELD ID="RISK_ASSESSMENT">
<TEXT>Overall Assessment of Risk</TEXT>
<FORMAT>DDL</FORMAT>
<REQUIRED>Y</REQUIRED>
<ITEMS>
<ITEM DEFAULT="Y">LOW</ITEM>
<ITEM>MED</ITEM>
<ITEM>HIGH</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL">
<TEXT>Risk Control Measures</TEXT>
<FORMAT>X</FORMAT>
<REQUIRED>N</REQUIRED>
<ITEMS>
<ITEM>Boots</ITEM>
<ITEM>Hard Hat</ITEM>
<ITEM>Hi Vis</ITEM>
<ITEM>Chemical Boots</ITEM>
<ITEM>Googles</ITEM>
<ITEM>Glasses</ITEM>
<ITEM>Gloves</ITEM>
<ITEM>Chemical Gloves</ITEM>
<ITEM>Harness</ITEM>
<ITEM>Lanyard</ITEM>
<ITEM>Trolley</ITEM>
<ITEM>Checmical Suit</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<REQUIRED>N</REQUIRED>
</FIELD>
<BUTTON CONFIRM="Are the risks now considered to be accepted?">
<TYPE>C</TYPE>
<TEXT>Complete</TEXT>
</BUTTON>
<BUTTON CONFIRM="Please confirm that a Method Statement has been produced.">
<TYPE>X</TYPE>
<TEXT>Not Required</TEXT>
</BUTTON>
</FORM>


= Appendix C: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test specific Lanemark Pre-work Checks UDF configuration and functionality.
|MenuAccess=Services
|Prerequisites=Ensure that the site being used has the UDF configuration as described in the [[#Data|Data]] section and [[#Appendix B: Risk Assessment Configuration|Appendix B]]. Ensure there are single- and multiple-item jobs (with at least 3 items) to check.
|Objective=To test that: Required checks are completed; validation is forced on the checks; validation is forced so that they are entered before any other information; status is displayed correctly and; data is updated correctly.
}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA - Process
|Notes=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a single-item service job. press onto the Diagnosis tab.
|Result=A validation error should be displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the '''Pre-work''' button label
|Result=It says "Risk Assessment (Incomplete)"
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=The pre-work pop-up is shown. The label says Risk Assessment. All fields required are present in a scrolling form. There are 2 buttons: '''Complete''' and '''Not Required'''
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back key
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back button and Confirm the confirmation dialogue.
|Result=The Info tab is shown again. The label still says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Re-enter the Pre-work pop-up. press the '''Complete''' button.
|Result=A validation error should be displayed, as not all required information has been entered.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter all required information. press the '''Complete''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press "No"
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Complete''' button and press '''Yes''' on the confirmation dialogue.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new single-item job. Press the '''Pre-work''' button. Press the '''Not Required''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on. It is marked as not required.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new multiple-item job. On the first item, press the '''Pre-work''' button. Enter all required information. Press the '''Complete''' button and confirm.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button.
|Result=The next service item is shown. The Pre-work label says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Prev''' button.
|Result=The previous service item is shown. The Pre-work label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Back key and confirm. Press the '''Prev''' button, move to the Diagnosis tab and press '''Done'''.
|Result=A validation error should be displayed, as not all Pre-work checks for all items have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete entry for all items on this service job and complete this job.
|Result=All Pre-work check information is saved and can be displayed and reported on for the job.
|Remarks= |PassFail= }} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=D
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 309371 Lanemark eSERV Requirements]]
|RefV3=0.4
|RefDate3=29/08/2013
|Ref4=[[FS 311636 UDF Modifications]]
|RefV4=0.3
|RefDate4=05/09/2013
|Ref5=[[FS 311856 Multiple Serviceable Items]]
|RefV5=0.1
|RefDate5=10/09/2013
|REQ=0
|EST=0
|FS=0.5
|TS=0.0
|DEV=3.5
|ST=0.5
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Taylor
|Rev1Title=OBS Project Manager
|Rev2=Jeff Foster
|Rev2Title=Client Representative
|Rev3=Alan Thompson
|Rev3Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

FS 311908 Configurable Pre-Work Checks

2013-11-29T09:31:59Z

Rmg: Add Risk Control items following client confirmation

<div class="noprint">
{{#vardefine:Client|LANE}}
{{#vardefine:ClientName|Lanemark}}
{{#vardefine:System|''CALIDUS'' eSERV}}
{{#vardefine:Doc_Title|Configurable Pre-Work Checks}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|4th October 2013}}
{{#vardefine:Reference|311908 309371-4/5}}
{{#vardefine:Year|2013}}
</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 user will be forced to enter Risk Assessment details before being allowed to start work against a Serviceable item, unless those checks have been completed before-hand.

The Risk Assessment checks are shown in [[#Appendix A: Risk Assessment Form|Appendix A]]

== Solution Overview ==
A '''Pre-Work Checks''' button will be shown in section 4 (titled ''Risk Assessment'') - this pops up the Pre-work checks pop-up form:

All contents will be configured, entered like Vehicle Checks, through a scrolling frame.

The items required during Risk Assessment will be based on the existing form - some changes will be made to the Risk Control section.
* Person responsible for your safety - text entry - required.
* Brief description of work to be done - text entry - required.
* Hazards associated section:
** This will list a number of check-boxes, identical to those on the sheet. It is not required that all be checked.
** Risks (Other) - text entry - optional.
* Overall Risk Assessment - drop-down list of: High/Medium/Low - required.
* Risk Control section (Measures to be taken...):
** A number of check-boxes will be identified for the user to tick here, to make entry of this easier than it currently is on the sheet. These are optional.
** Risk Control (Other) - text entry - optional.

On saving the checks, the user will be asked to confirm that these are now completed (through a '''Complete''' button). If so, they will be marked as such and the user will be allowed to exit and the title of the '''Risk Assessment''' button will be updated to show the status (Complete or Incomplete).

The user will also be offered a button to indicate that the checks are not required (through a '''Not Required''' button). If this is clicked, the user will be asked to confirm this and, if so, the checks will be marked as not required, but completed anyway.

Initially, the user will not be able to select any tab except Job Details and Info. Only when the Risk Assessment checks for this particular Serviceable Item are complete (or marked as pre-completed) will the user be able to select any other tabs for this Serviceable item.

{{Note}} These configurable Pre-Work Checks are not search-able, exportable or reportable within {{#var:System}}, but can be displayable in the Admin client or on the Service Report.

== Scope ==
* These changes will be made in the latest version of the {{#var:System}} product only.
* The changes will be made to the Android eSERV client only.
* {{Warning}} This change requires that the UDF modifications and Multiple Serviceable Items are complete first - see [[#Appendix_D:_Quote_.26_Document_References|Appendix D]] for references.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
Table EPOD_UDF_CONFIG must have new records created for the site:
* EPL_DESCRIPTION = "Risk Assessment checks"
** EPL_KEY_TYPE = "S"
** EPL_KEY_VAL = "{EPL_SITE_ID}"
** EPL_CONFIG_TYPE = "PREWORK"
** EPL_UDF_FIELDS - see [[#Appendix B: Risk Assessment Configuration|Appendix B]]


= Functional Description =
== Android Client ==
{{Note}} The UDF Modifications change should already be complete - among many other items, this made the following changes to the PDA Service process:
{{comment|text=
The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing in the configuration setting.

The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

...
''(on the Diagnosis tab)''

The validation against the '''OK''' button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:
* If PDA_UDF_PREWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Pre-work checks, referred to by the Name element of the Pre-work configuration. The device should return the user to the services screen on clearing this message.
...
* If PDA_UDF_PREWORK is not null, save the resulting XML from the Pre-work UDF object into the new Service field EPL_UDF_PREWORK.
|sign=[[FS 311636 UDF Modifications]]|date=11/9/2013 11:32:53}}

There will be some slight modifications to this here, to allow for Multiple Serviceable Items processing, along with the changes required for this functionality.

The Pre-work button will be labelled with the NAME attribute of the FORM in the XML, plus a status in parentheses, based on the Confirm attribute of the UDF created, one of:
* Blank - "Incomplete"
* C - The label of the '''Complete''' button
* X - the label of the '''Cancel''' button
{{Note}} The '''Ignore''' button alone will not change the status, as this is the equivalent to the Android Back button.

These Pre-work Checks can be completed for all Serviceable items, or just for the one in progress, so a user may choose to complete one, move to the next serviceable item, complete those checks, move on, etc, until all are complete. Therefore, when displaying this button for the first time, the screen must check the value of the CONFIRM attribute of the FORM tag from the UDF XML stored in EPL_UDF_PREWORK.

When the screen has been exited with a '''Cancel''' or '''Confirm''' button press, the Confirm parameter will have been stored against the object and the items validated. This parameter must also be stored as an attribute against the FORM tag (CONFIRM="X|I|C") on the returned XML. This will also change the label of the Pre-work button, to reflect the new status.

When Cancelling (using an X-type button), the XML must still be built and saved, but without the users' answers (i.e. as the passed-in configuration). As before, the CONFIRM attribute must be added and the Pre-work label changed.

{{Note}} The XML returned to the FORM should be placed in EPL_UDF_PREWORK. This should be saved if the user chooses to exit the service or if the user changes Serviceable Items, through the functionality designed for Multiple Serviceable Items.

The Android BACK key may be used to back out of the Pre-work screen - in this case, a confirmation back to the user be made (standard, not configurable) informing them that all entered data will be lost. If not confirmed, the user will be returned to the Pre-work screen. If confirmed, the user will be returned to the Info tab, nothing will be validated or saved, including the Confirm attribute, which should still be set to blank.

If the Pre-work status has been set to 'C' or 'X', the user should NOT be allowed back in to change the status - the checks have been entered and confirmed by the user and may not be changed.

If the FORM tag REQUIRED attribute has been set on the configuration XML to 'Y', the Pre-work checks MUST be complete before any work (other than Information-gathering) begins - the screen should not allow moving onto any tab other than Job Details and Information (i.e. any tab index greater than 1). If the user attempts to do this, an error should be displayed and the user should be returned to the Info or Job Details tab.


= Appendix A: Risk Assessment Form =
[[File:REQ_309187_RISK.jpg|600px|border]]


= Appendix B: Risk Assessment Configuration =
<FORM NAME="Risk Assessment" REQUIRED="Y">
<FIELD ID="PERSON">
<TEXT>Person on site responsible for your safety</TEXT>
<FORMAT>T</FORMAT>
<SKIPABLE>N</SKIPABLE>
</FIELD>
<FIELD ID="DESCRIPTION">
<TEXT>Brief description of work to be done</TEXT>
<FORMAT>T</FORMAT>
<SKIPABLE>N</SKIPABLE>
</FIELD>
<FIELD ID="HAZARDS">
<TEXT>Identify hazards associated</TEXT>
<FORMAT>X</FORMAT>
<SKIPABLE>Y</SKIPABLE>
<ITEMS>
<ITEM>Existing live pipework, services and plant</ITEM>
<ITEM>Adverse weather conditions</ITEM>
<ITEM>Chemicals/Substances present in existing System</ITEM>
<ITEM>Transport of Items to and from site</ITEM>
<ITEM>Tripping/Slipping</ITEM>
<ITEM>Fall from height (platform)</ITEM>
<ITEM>Transport of vehicles around site</ITEM>
<ITEM>Mechanical lifting and moving</ITEM>
<ITEM>Use of Substances hazardous to health</ITEM>
<ITEM>Use of portable electrical tools</ITEM>
<ITEM>Ventilation</ITEM>
<ITEM>Contact with hot and cold surfaces</ITEM>
<ITEM>Fire (including static electricity</ITEM>
<ITEM>Storage/Stacking</ITEM>
<ITEM>Falling from height (ladder)</ITEM>
<ITEM>Solitary working</ITEM>
<ITEM>Manual handling of materials</ITEM>
<ITEM>Disposal of substances</ITEM>
<ITEM>Explosion</ITEM>
<ITEM>Lighting</ITEM>
<ITEM>Noise</ITEM>
<ITEM>Electricity</ITEM>
<ITEM>Hand Tools</ITEM>
<ITEM>Radiation sources</ITEM>
<ITEM>Confined Spaces</ITEM>
<ITEM>Fall of materials</ITEM>
<ITEM>General Dust / Debris</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="HAZARDS_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<SKIPABLE>Y</SKIPABLE>
</FIELD>
<FIELD ID="RISK_ASSESSMENT">
<TEXT>Overall Assessment of Risk</TEXT>
<FORMAT>DDL</FORMAT>
<SKIPABLE>N</SKIPABLE>
<ITEMS>
<ITEM DEFAULT="Y">LOW</ITEM>
<ITEM>MED</ITEM>
<ITEM>HIGH</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL">
<TEXT>Risk Control Measures</TEXT>
<FORMAT>X</FORMAT>
<SKIPABLE>Y</SKIPABLE>
<ITEMS>
<ITEM>Boots</ITEM>
<ITEM>Hard Hat</ITEM>
<ITEM>Hi Vis</ITEM>
<ITEM>Chemical Boots</ITEM>
<ITEM>Googles</ITEM>
<ITEM>Glasses</ITEM>
<ITEM>Gloves</ITEM>
<ITEM>Chemical Gloves</ITEM>
<ITEM>Harness</ITEM>
<ITEM>Lanyard</ITEM>
<ITEM>Trolley</ITEM>
<ITEM>Checmical Suit</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="RISK_CONTROL_OTHER">
<TEXT>Others (please specify)</TEXT>
<FORMAT>T</FORMAT>
<SKIPABLE>Y</SKIPABLE>
</FIELD>
<BUTTON CONFIRM="Are the risks now considered to be accepted?">
<TYPE>C</TYPE>
<TEXT>Complete</TEXT>
</BUTTON>
<BUTTON CONFIRM="Please confirm that a Method Statement has been produced.">
<TYPE>X</TYPE>
<TEXT>Not Required</TEXT>
</BUTTON>
</FORM>


= Appendix C: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test specific Lanemark Pre-work Checks UDF configuration and functionality.
|MenuAccess=Services
|Prerequisites=Ensure that the site being used has the UDF configuration as described in the [[#Data|Data]] section and [[#Appendix B: Risk Assessment Configuration|Appendix B]]. Ensure there are single- and multiple-item jobs (with at least 3 items) to check.
|Objective=To test that: Required checks are completed; validation is forced on the checks; validation is forced so that they are entered before any other information; status is displayed correctly and; data is updated correctly.
}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=PDA - Process
|Notes=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a single-item service job. press onto the Diagnosis tab.
|Result=A validation error should be displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the '''Pre-work''' button label
|Result=It says "Risk Assessment (Incomplete)"
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=The pre-work pop-up is shown. The label says Risk Assessment. All fields required are present in a scrolling form. There are 2 buttons: '''Complete''' and '''Not Required'''
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back key
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Android Back button and Confirm the confirmation dialogue.
|Result=The Info tab is shown again. The label still says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Re-enter the Pre-work pop-up. press the '''Complete''' button.
|Result=A validation error should be displayed, as not all required information has been entered.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter all required information. press the '''Complete''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press "No"
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Complete''' button and press '''Yes''' on the confirmation dialogue.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new single-item job. Press the '''Pre-work''' button. Press the '''Not Required''' button.
|Result=A confirmation dialogue is displayed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel this.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete this service-job.
|Result=All Pre-work check information is saved and can be displayed and reported on. It is marked as not required.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a new multiple-item job. On the first item, press the '''Pre-work''' button. Enter all required information. Press the '''Complete''' button and confirm.
|Result=The Info tab is shown again. The label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button.
|Result=The next service item is shown. The Pre-work label says "Incomplete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Not Required''' button and confirm.
|Result=The Info tab is shown again. The label says "Not Required".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Prev''' button.
|Result=The previous service item is shown. The Pre-work label says "Complete".
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=A validation error should be displayed, as the Pre-work checks have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the '''Next''' button, then the '''Pre-work''' button.
|Result=The Pre-work pop-up is displayed again.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Press the Back key and confirm. Press the '''Prev''' button, move to the Diagnosis tab and press '''Done'''.
|Result=A validation error should be displayed, as not all Pre-work checks for all items have been completed.
|Remarks= |PassFail= }} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete entry for all items on this service job and complete this job.
|Result=All Pre-work check information is saved and can be displayed and reported on for the job.
|Remarks= |PassFail= }} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=D
|Estimate=Y
|Glossary=EPOD
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]
|RefV1=2.0
|RefDate1=4/4/2012
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]
|RefV2=3.0
|RefDate2=23/4/2013
|Ref3=[[REQ 309371 Lanemark eSERV Requirements]]
|RefV3=0.4
|RefDate3=29/08/2013
|Ref4=[[FS 311636 UDF Modifications]]
|RefV4=0.3
|RefDate4=05/09/2013
|Ref5=[[FS 311856 Multiple Serviceable Items]]
|RefV5=0.1
|RefDate5=10/09/2013
|REQ=0
|EST=0
|FS=0.5
|TS=0.0
|DEV=3.5
|ST=0.5
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Julie Taylor
|Rev1Title=OBS Project Manager
|Rev2=Jeff Foster
|Rev2Title=Client Representative
|Rev3=Alan Thompson
|Rev3Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]