View source for FS 348867 T20180124.0019-SCR1 KoO Artex C-ePOD

<div class="noprint">
{{#vardefine:Client|PART}}
{{#vardefine:ClientName|Knights of Old}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Artex Implementation}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|27th February 2018}}
{{#vardefine:Reference|348867 T20180124.0019-SCR1}}
{{#vardefine:Year|2018}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

<!-- TOC --> 
<div class="noprint">
= Functional Overview  =
== Client Requirement  ==
The client requires an implementation of a new partner, Artex, plus some additional developments to support the process.

The following jobs are required to be processed:
* Loading Jobs on Loading loads.
* Delivery, Customer Collection and Unloading jobs back at the depot, on Radial loads.

''CALIDUS'' Portal TTM will be used by KoO and Artex for tracking and POD/POC viewing.


== Solution Overview  ==
A new site L98 will be created for the Artex operation.

''CALIDUS'' ePOD will be used for Loading and Radial purposes.

Loading and Radial jobs will be interfaced from Vigo to C-ePOD on separate loads.

Unloading jobs for each Customer Collection will be sent to C-ePOD on the Radial Loads.

Loading and Unloading jobs will be identified as such in the interface.

Each type of job will be identified with a slightly different Job Group (specified in Tracking System) for Artex, to control different functionality per job type.

The Partnerlink JobShare Interface will be modified in C-ePOD to handle these requirements.


Loading jobs are performed by warehouse (Artex) staff.

Radial (Delivery, Collection and Unloading back in the depot) performed by drivers.

Loading jobs will be consolidated together. The loading process will be assigned in EPOD to a warehouse loader and to the particular vehicle being loaded.

Radial Deliveries and Radial Collections will not be consolidated with other jobs.

Unloading jobs will be consolidated together and will be at the end of the Radial loads.

On completion of all jobs, an update will be sent out to Vigo in the standard OBS XML format. Each type job will be identified in the interface, to aid Vigo in updating the status. 


''CALIDUS'' ePOD Admin will be used to:
* Assign Loaders to Loading loads.
* View POD/POC.
* View Images taken against the jobs.

The standard KoO POD format will be used. There is at this time no intention to change this format specifically for the Artex contract.


''CALIDUS'' Portal TTM will be used by KoO and Artex operations:
* View POD/POC.
* View progress of loading and radials.


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

This solution will be implemented using the existing Partnerlink KoO database and system.


<!-- NEW PAGE --> 

= Set-up  =

== Pre-requisites  ==

== Menu Structure  ==

== Data  ==
A new Site L98 will be created for Artex.

The Artex or Knights logo may be uploaded here, although it should be noted that this logo will be used on the delivery documentation.


New Job Groups will be created under this Site:
* ARTEX_L - Loading jobs
* ARTEX_D - Delivery jobs
* ARTEX_C - Collection jobs
* ARTEX_U - Unloading Jobs


Site/Job Group Configuration:
* Deliver All disabled.
* Clausing disabled.
* Driver and Customer signatures:
** Loading - None or Driver Signature
** Unloading - Driver Signature
** Collections/Deliveries - Customer Signature
* Force container entry enabled.
* Capture Arrival times enabled.
* Consolidation enabled.
* KoO POD/POC format.
* Partnerlink PDA style.
* Container Only Delivery enabled.
* Scan Errors Intrusive enabled.
* Seamless Scanning enabled.
* Display Job Code set to "Job Code".
* User Notes enabled.
* Import Create Standing Data enabled.
* Job Photo:
** Loading - Required
** Unloading - None
** Collections/Deliveries - Optional


An Export configuration for the Artex site to the Vigo system will be created, as follows:
* Config ID	- L98
* Type	- FILE
* ID	- PART
* Destination	- E:\ftpserver\PartnerLink\ARTEX_PRD\OUT\
* Direction	- O


An export configuration for the Artex site for the POD in TIFF format will be created, as follows:
* Config ID	- POD_L98
* Description	- L98 POD
* Type	- FILE
* ID	- POD
* Destination	- E:\ftpserver\PartnerLink\ARTEX_PRD\OUT\POD
* Direction	- O
* Export Job Types	- C|D
* Export Format	- Image
* Image Type	- TIFF
* Tiff Compression	- Zip
* Filename	- (EPL_EXT_REF)-(DATE)-(TIME)-(UID)


An Import configuration for the Artex site from the Vigo system will be created, as follows:
* Config ID	- ARTEX_IMP
* Description	- Artex IMPORT
* Type	- FILE
* ID	- JOB
* Destination	- E:\ftpserver\PartnerLink\ARTEX_PRD\IN
* Direction	- I
* Account	- ARTEX
* Message Type	- Partnerlink


All standing data uploads and maintenance will be performed by the customer.


PDA Users will be configured for the drivers and Artex loading staff.


<!-- NEW PAGE --> 
= Functional Description  =
== Data Import ==
Loads and Jobs will be interfaced into C-ePOD from Vigo using the Partnerlink JobShare interface format.

This interface is documented here: [[FS 326965 Partnerlink EPOD Interface]]

Import files following this format will be placed into an area for Artex imports - this will be sent via FTP into the Partnerlink server. Account and password information will be advised later.

These files will be processed by the import and added to the C-ePOD database.


A separate load will be sent for Loading jobs.

A separate load will be sent for Radial Collection, Delivery and Unloading jobs.

{{Warning}} In order to process correctly in EPOD, the driver ''and'' vehicle must be set for one or both of the loads for a particular vehicle. It is ''not'' sufficient that both loads are sent in with the same Vehicle but without a driver, as this means that the loader could pick up the delivery load, causing issues assigning jobs to drivers. It is suggested that the radial load/jobs are allocated to a driver and vehicle.


Job Group on each job will be set by populating Tracking System (Column 65) with the following, based off the Job Type:
* ARTEX_L - Loading jobs
* ARTEX_D - Delivery jobs
* ARTEX_C - Collection jobs
* ARTEX_U - Unloading Jobs

Linked ID (column 66) on each job will be populated by the sending system if the jobs are to be consolidated i.e. completed together as a single job. This is expected to be populated on the Loading and Unloading jobs only. Each job with the same linked ID on the load will be consolidated together.

Job Type currently can be set to "C" for Collections or "D" for Deliveries. This will be extended to "L" for Loading jobs and "U" for Unloading jobs.

If there have been modifications from Loading, for example where items have not been loaded), the Radial load for this vehicle will be re-sent in total to ''CALIDUS'' ePOD with the modifications. The interface will load this and modify the jobs on this load with the new number of items.

{{Note}} If it is required that ''CALIDUS'' ePOD instead carries these Loading job modifications forward to the Delivery jobs, this will require additional modifications. This is ''not'' included in this change.


=== Partnerlink Import Development Details ===
Changes must be made to the Partnerlink JobShare Import processor in C-ePOD to achieve the following changes:
* Handle job type "L" and "U"
* Allow job group to be set without tracking number.

Changes will be made to the EPOD Server EPOD_DATAPROCESS.ProcessUpload function.


When processing collections or deliveries, when setting EPOD_JOB.EPL_JOB_GROUP, currently the system checks whether the tracking number is present. If not, the Job Group is only set from the Tracking System column if the tracking system is EUROPA. This will be changed to set this by default.


A new String strLoadingType will be added to store the Loading Type.

When determining the job type, this will be extended to check for job types of "U" and "L".

{| class="wikitable" border="1"
|- bgcolor="silver"
! JobType !! EPL_JOB_TYPE !! EPL_LOADING_TYPE !! Notes
|-
| C || C || "" || &nbsp;
|-
| L || C || L || &nbsp;
|-
| U || D || U || &nbsp;
|-
| D || D || "" || This is the default if the job type in the incoming file is not one of the indicated values.
|}

After creation of the job, the loading type should be set from the stored values above.


Currently this process does not update the containers (pallets/items) when this is a Collection (or Loading) job. This will be modified to do the same as the Delivery/Unloading jobs, refreshing the containers and deleting them and recreating them if necessary.


== Mobile Device Processes ==
Loading jobs are performed by warehouse (Artex) staff.

Radial (Delivery, Collection and Unloading back in the depot) performed by drivers.

The following sections show how each job would be processed in overview. As this is an existing system, it is not deemed necessary to detail all processes, as the product is already known by the operation. Please refer to the existing product documentation for a more detailed description and screen-shots.


=== Loading ===
Loading jobs will be consolidated together.  

The loading process will be assigned in C-ePOD to a warehouse loader and to the particular vehicle being loaded.

The process is:
* Assign the Load to the Artex loading staff.
* Log in as this staff user and password, and that vehicle.
* Start the Load
* Select the single job from the list
* Start the job.
* Arrive the job.
* Scan each item for loading - the order is not system directed and will be controlled by the loaders. The process will require that all items are scanned, not selected from the item list.
* Driver signature can be enabled, but is not expected to be required.
* Photo capture of the completed loading job will be required at the end of the load.


=== Radials ===
Radial Deliveries and Radial Collections will not be consolidated with other jobs.

The process is:
* Start the Load
* Select the first job from the list in sequence.
* Start the job.
* Navigate to the destination.
* Arrive the job.
* For Deliveries:
** Scan each item for delivery. The process will require that all items are scanned, not selected from the item list.
* For Collections:
** To be confirmed. It is expected that items labels will be printed and brought with the driver for customer collections, then the returned items labelled and scanned.
* Customer signature will be enabled.
* Photo capture of the completed loading job will be optional at the end of the load.


=== Unloading ===
Unloading jobs will be consolidated together and will be at the end of the Radial loads.

The process is:
* When all deliveries and collections are complete, start the return to base unloading jobs. There will be unloading jobs for:
** Every customer collection
** A single job for every non-delivered item.
* Navigate to the destination (depot).
* Arrive the job.
* Scan each item for unloading. The process will require that all items are scanned, not selected from the item list.
* Driver signature will be enabled.
* Photo capture of the completed loading job will be optional at the end of the load.


== Data Export ==
On completion of all jobs, an update will be sent out to Vigo in the standard OBS XML format. 

{{Note}} The job type will be identified as follows: 
* EPL_LOADING_TYPE = "L" - Loading job.
* EPL_LOADING_TYPE = "U" - Unloading job.
* EPL_LOADING_TYPE = "", EPL_JOB_TYPE = "D" - Delivery job.
* EPL_LOADING_TYPE = "", EPL_JOB_TYPE = "C" - Collection job.

This export will be put into an FTP folder awaiting pick up by the customer. The standard Partnerlink server will be used, but a new username and password will be provided, and a new area written to for the Artex partner code.


Additionally, the POC and POD documents will be exported to the Partnerlink POD system, in the standard manner. Note that, should any changes be required to the standard format for POC viewing, this will be handled under the generic implementation of the Artex operation, under log 348862, KoO P/O T20180126.0049.


All job-level information will be tracked and traced through the ''CALIDUS'' Portal TTM, which will be updated by ''CALIDUS'' ePOD in the standard manner.


== Viewing the POC and POD ==
The POC report for the loading and Unloading jobs can be viewed in C-ePOD Admin by finding the job and clicking the '''Report''' button.

''CALIDUS'' Portal TTM will be modified so that the POC can be viewed through the Order Enquiry results screen.

If the order has a DEL event (i.e. was delivered) a '''Delivery POD''' button is displayed on this screen. This will be changed to a '''View POD''' button.

If the order has a COL event (i.e. was collected) a '''View POC''' button will be on this screen.

When clicked, Portal will call the C-ePOD general report with an additional parameter (EPL_JOB_TYPE). If this parameter is not present, the report will work as now, retrieving the final delivery job for the specified job code.

If the new parameter is provided, the report will:
* Retrieve the the final delivery job for the specified job code if the parameter is "D".
* Retrieve the the initial collection job for the specified job code if the parameter is "C".

The C-ePOD POD or POC report will then be shown, based off the job selected.


<!-- MEDIA LANDSCAPE YES --> 
= Appendix A: TEST PLAN  =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=
|MenuAccess=N/A
|Prerequisites=Configured as per specification
|Objective=To test that: Job Type/Loading Type and Job Group are set; repeat transmissions of the same job will reduce/increase number of items and; the same job can be sent in multiple times, once on Loading load, once on Delivery load, and show correctly on the Portal.
}} 
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=All Systems
|Notes=Create test files for:
* A Loading load
** Assigned to a loading user and the same vehicle as the Radial load. 
** All jobs on this vehicle should match delivery job on the Radial load. 
** All jobs should have the job type "L".
** All jobs should have tracking system "ARTEX_L"
** All jobs should have Linked ID set to the same value.
* A Delivery load
** Assigned to a Driver and the same vehicle as the Loading load. 
** All delivery jobs on this vehicle should match loading jobs on the Loading load. 
** All delivery jobs should have the job type "D".
** All delivery jobs should have tracking system "ARTEX_D"
** All collection jobs should have the job type "C".
** All collection jobs should have tracking system "ARTEX_C"
** All unloading jobs on this vehicle should match collection jobs on this load. 
** All unloading jobs should have the job type "U".
** All unloading jobs should have tracking system "ARTEX_U"
** All unloading jobs should have Linked ID set to the same value.

All jobs should have 3 containers.

Create a third load in the normal style with some PallEx, Palletline, JobShare and normal (partner owned-executed) jobs on.
}} <!--INSERT TESTS HERE --> {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Upload the files.
|Result=The Loads and jobs are created separately. The loads are allocated to the correct vehicle and user. All jobs have the correct Job Type, Loading Type and Job Group. The addresses and times used are collection data for collection and loading jobs, and the delivery data for delivery and unloading jobs. The normal style load creates the jobs as it does now and is unaffected by this change. Each job has 3 containers.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Change all the files to have 2 containers and re-upload the files.
|Result=All jobs have been updated to have 4 containers.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the loading jobs, cancelling some items.
|Result=The Load shows only one entry on the Job List, for all of the jobs to be completed as one (consolidated). The jobs process as expected. Photos are required when the job is complete. Signatures are not prompted for (or driver signatures are, dependent on configuration). An export file is produced per job, clearly showing the loading type of "L" and reflecting the changes to the items loaded.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the Radial delivery load. Change the Radial import file to change the containers to 2 on one of the jobs. Import the file.
|Result=The Load shows one entry per delivery and collection job on the Job List, and one consolidated entry for all the unloading jobs. The changed job has been updated to have 2 containers. The device receives an update of the changed job (dependent on settings).
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the delivery jobs, cancelling one container on each job.
|Result=An Unloading (UNL) job should display as containers are cancelled. This is consolidated with the Unloading jobs. An export file is produced per job, reflecting the changes to the items delivered.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the collection jobs, cancelling one container on each job. 
|Result=An export file is produced per job, reflecting the changes to the items collected.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start the Unloading job.
|Result=There should be an unloading job for each collection, consolidated together. There should also be a general unloading (UNL) job for the non-delivered items. The items on these jobs should be all the non-delivered items, and all the collected items.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the Unloading job.
|Result=An export file is produced for each unloading job from a customer collection, clearly showing the loading type of "U". Nothing is exported for the generic unloading job.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the POD and POC for all these jobs.
|Result=The POC and POD produce correctly from C-ePOD and C-Portal TTM. The POD and POC are exported to the customer systems. 
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check Portal TTM for all these jobs
|Result=The orders and trips track correctly.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}} 
<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[FS 326965 Partnerlink EPOD Interface]]
|RefV1=1.0
|RefDate1=22/05/2015
|REQ=2.5
|EST=0
|FS=0
|TS=0
|DEV=1.75
|ST=0.75
|IMP=2
|PM=1.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]]