FS 341168 Palletline Integration - Revision history

Anw: v0.6 - Amended layout of the signature screen and added examples.

2017-04-13T10:02:40Z

v0.6 - Amended layout of the signature screen and added examples.

← Older revision		Revision as of 12:02, 13 April 2017
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|Palletline Interface}}		{{#vardefine:Doc_Title\|Palletline Interface}}
	{{#vardefine:Version\|0.5}}		{{#vardefine:Version\|0.6}}
	{{#vardefine:Date\|13th April 2017}}		{{#vardefine:Date\|13th April 2017}}
	{{#vardefine:Reference\|341168}}		{{#vardefine:Reference\|341168}}
Line 207:		Line 207:

	=== Signature ===		=== Signature ===
	The signature captured by the device will be 25% shorter by changing the signature height from the base height sigHeight from 235 to 180. The view containing this will also be shortened.		The signature captured by the device will be 25% shorter by changing the signature height from the base height sigHeight from 235 to 180. The view containing this will also be shortened. Note that the background customer text view should be styled correctly for this change, moving the styling to the central Style repository and reducing the height of the font to fit the new signature height.

	The signature itself will be positioned to the top of the available space rather than the centre.		The signature itself will be positioned to the top of the available space rather than the centre.

			The Signature Terms and Conditions view will be increased in size from 40% to 50% and be moved up 10%, making better use of the available space from the smaller signature.

			{{Note}} All these style changes can be styled so that they only apply when the new SVG signatures are required for the jobs being completed (through the new EPL_SVG_SIGNATURE_IND Job Group flag), so that current customers and customers that do not require SVG signatures are unaffected and keep the same layout.

			<gallery widths=250px heights=300px perrow=3>
			File:FS_341168_Signature1.PNG\|''Signature with SVG required''
			File:FS_341168_Signature2.PNG\|''Without SVG required''
			</gallery>


	The captured vector signature will be blue, and 2 pixels wide.		The captured vector signature will be blue, and 2 pixels wide.
Line 218:		Line 228:
	vars.vector = vars.vector.replace(/\.\d*?(\,\|\s)/g, $1);		vars.vector = vars.vector.replace(/\.\d*?(\,\|\s)/g, $1);
	{{Note}} The vector SVG signature should still be captured on touching the screen on the device, as this is used to determine whether the user has entered a signature. However, this will only be returned to the function if the new Job Group EPL_SVG_SIGNATURE_IND flag is enabled (set to 1). If the signature process is called by a process that is not Customer or Driver signature at Job Confirmation (for example, Vehicle Checks or Pre-Job signatures), no SVG signature will be returned.		{{Note}} The vector SVG signature should still be captured on touching the screen on the device, as this is used to determine whether the user has entered a signature. However, this will only be returned to the function if the new Job Group EPL_SVG_SIGNATURE_IND flag is enabled (set to 1). If the signature process is called by a process that is not Customer or Driver signature at Job Confirmation (for example, Vehicle Checks or Pre-Job signatures), no SVG signature will be returned.

	~~The Signature Terms and Conditions view will be increased in size from 40% to 50%, making better use of the available space from the smaller signature.~~

	The utility function to control the sequence of tasks after a job is complete, including signatures (funNextJobEndTask) will be modified to add an extra parameter p_strSVG to the success callback function definition. This will then be used to update all the jobs being completed with the SVG Signature returned. This will be done for both Customer and Driver Signature, updating the appropriate fields on PDA_JOB (respectively EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG).		The utility function to control the sequence of tasks after a job is complete, including signatures (funNextJobEndTask) will be modified to add an extra parameter p_strSVG to the success callback function definition. This will then be used to update all the jobs being completed with the SVG Signature returned. This will be done for both Customer and Driver Signature, updating the appropriate fields on PDA_JOB (respectively EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG).
Line 234:		Line 242:
	...		...

	{{Note}} This device work has been extensively prototyped and is available to be ~~implemented~~.		{{Note}} This device work has been extensively prototyped and is available to be used by the developer as a base for the above developments.

Anw: v0.5 - After review by RM.

2017-04-13T09:31:37Z

v0.5 - After review by RM.

← Older revision		Revision as of 11:31, 13 April 2017
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|Palletline Interface}}		{{#vardefine:Doc_Title\|Palletline Interface}}
	{{#vardefine:Version\|0.4}}		{{#vardefine:Version\|0.5}}
	{{#vardefine:Date\|13th April 2017}}		{{#vardefine:Date\|13th April 2017}}
	{{#vardefine:Reference\|341168}}		{{#vardefine:Reference\|341168}}
Line 75:		Line 75:

	The reason codes used by Palletline are not currently used in the Partnerlink system, so these will not cause any contention in the system. It is assumed that any conflicts between these reason codes and any generic or partner-specific reason codes of the same type will be resolved by the partners.		The reason codes used by Palletline are not currently used in the Partnerlink system, so these will not cause any contention in the system. It is assumed that any conflicts between these reason codes and any generic or partner-specific reason codes of the same type will be resolved by the partners.


			This change applies only to Customer and Driver signatures at Job Confirmation. Other signatures (for example, Vehicle Checks, Pre-job signatures, etc) are not affected and will not produce SVG signatures. They are not required for this functionality.


Line 204:		Line 207:

	=== Signature ===		=== Signature ===
	The signature captured by the device will be 25% shorter by changing the signature height from the base height sigHeight from 235 to 180.		The signature captured by the device will be 25% shorter by changing the signature height from the base height sigHeight from 235 to 180. The view containing this will also be shortened.

	The signature itself will be positioned to the top of the available space rather than the centre.		The signature itself will be positioned to the top of the available space rather than the centre.
Line 214:		Line 217:
	The vector signature result will be parsed to remove all decimal components and the results passed back to the success callback function p_fncSuccess. The decimal components can be removed using a Regular Expression as follows (example):		The vector signature result will be parsed to remove all decimal components and the results passed back to the success callback function p_fncSuccess. The decimal components can be removed using a Regular Expression as follows (example):
	vars.vector = vars.vector.replace(/\.\d*?(\,\|\s)/g, $1);		vars.vector = vars.vector.replace(/\.\d*?(\,\|\s)/g, $1);
	{{Note}} The vector SVG signature should still be captured on touching the screen on the device, as this is used to determine whether the user has entered a signature. However, this will only be returned to the function if the new Job Group EPL_SVG_SIGNATURE_IND flag is enabled (set to 1).		{{Note}} The vector SVG signature should still be captured on touching the screen on the device, as this is used to determine whether the user has entered a signature. However, this will only be returned to the function if the new Job Group EPL_SVG_SIGNATURE_IND flag is enabled (set to 1). If the signature process is called by a process that is not Customer or Driver signature at Job Confirmation (for example, Vehicle Checks or Pre-Job signatures), no SVG signature will be returned.

	The Signature Terms and Conditions view will be increased in size from 40% to 50%, making better use of the available space from the smaller signature.		The Signature Terms and Conditions view will be increased in size from 40% to 50%, making better use of the available space from the smaller signature.

Anw: v0.4 - Added test case for jobs cancelled through Admin

2017-04-13T08:58:55Z

v0.4 - Added test case for jobs cancelled through Admin

← Older revision		Revision as of 10:58, 13 April 2017
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|Palletline Interface}}		{{#vardefine:Doc_Title\|Palletline Interface}}
	{{#vardefine:Version\|0.3}}		{{#vardefine:Version\|0.4}}
	{{#vardefine:Date\|13th April 2017}}		{{#vardefine:Date\|13th April 2017}}
	{{#vardefine:Reference\|341168}}		{{#vardefine:Reference\|341168}}
Line 486:		Line 486:

	The job not requiring export has no file.		The job not requiring export has no file.
			\|Remarks=
			\|PassFail=
			}}{{TestPlan_Test
			\|Test={{ #vardefineecho: SubCycle \| {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
			\|Action=Create a new job requiring export to Palletline with multiple containers and cancel using the Admin console.
			\|Result=The Job has a Palletline export file created for it, with the correct name. The file is populated correctly. The GPS is not present. There is no signature. The containers are included in the file, marked with status NDNV.
	\|Remarks=		\|Remarks=
	\|PassFail=		\|PassFail=

Anw: v0.3 - After review by RE

2017-04-13T08:29:35Z

v0.3 - After review by RE

← Older revision		Revision as of 10:29, 13 April 2017
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|Palletline Interface}}		{{#vardefine:Doc_Title\|Palletline Interface}}
	{{#vardefine:Version\|0.2}}		{{#vardefine:Version\|0.3}}
	{{#vardefine:Date\|~~12th~~ April 2017}}		{{#vardefine:Date\|13th April 2017}}
	{{#vardefine:Reference\|341168}}		{{#vardefine:Reference\|341168}}
	{{#vardefine:Year\|2017}}		{{#vardefine:Year\|2017}}
Line 64:		Line 64:
	* Palletline's Contrado system will be updated separately to the partner's TMS systems.		* Palletline's Contrado system will be updated separately to the partner's TMS systems.
	* The Consignment will already exist within the Palletline Contrado system, ready for updating with POD information from ''CALIDUS'' ePOD.		* The Consignment will already exist within the Palletline Contrado system, ready for updating with POD information from ''CALIDUS'' ePOD.

			{{Warning}} If this process requires the files to be sent to an FTP destination, the FTP server, username and password for this remote server must be provided.


			{{Warning}} The configuration and the development below assumes that the files created for the Palletline Contrado system will always be placed in the same folder or FTP destination for the depot. If this requires to be identified through different sub-folders for each owning (rather than executing) depot, then this will require additional development.


Line 69:		Line 74:


	The reason codes used by Palletline are not currently used in the Partnerlink system ~~(2 character numeric values from 01 to 19)~~, so these will not cause any contention in the system. It is assumed that any conflicts between these reason codes and any generic or partner-specific reason codes of the same type will be resolved by the partners.		The reason codes used by Palletline are not currently used in the Partnerlink system, so these will not cause any contention in the system. It is assumed that any conflicts between these reason codes and any generic or partner-specific reason codes of the same type will be resolved by the partners.


Line 81:		Line 86:

	== Data ==		== Data ==
	~~A new Job Group "PLINE" will be set up for Palletline jobs. This will initially be a copy of the Palletforce job group "PALLET".~~

	A new Auto-Export configuration will be created for each partner that requires it, linked to the job group PLINE:		A new Auto-Export configuration will be created for each partner that requires it, linked to the job group PLINE:
			* EPL_XF_CONFIG_ID - As required. For example, for Hathaways, this may be "PLINE_L02".
	* EPL_XF_ID - PLINE		* EPL_XF_ID - PLINE
	* EPL_XF_TYPE - FILE		* EPL_XF_TYPE - FILE
	* EPL_XF_DIRECTION - O		* EPL_XF_DIRECTION - O
	* EPL_XF_DESTINATION - E:\ftpserver\PartnerLink\~~HATHAWAY_TST~~\~~PLINE~~		* EPL_XF_DESTINATION - E:\ftpserver\PartnerLink\PALLETLINE_TST\L02\OUT
	* EPL_EXPORT_JOB_TYPES - D		* EPL_EXPORT_JOB_TYPES - D
	{{Note}} This configuration is for the test system and assumes that the folder will be created.		{{Note}} This configuration is for the test system and assumes that the folder will be created.

	{{Warning}} This configuration above assumes that the files will be placed in the {{#var:System}} local file system - in this case, an FTP service, username and password must be provided to Palletline's Contrado system to collect the files from this location only. Alternatively, if this process requires the files to be sent to an FTP destination, the FTP server, username and password for this remote server must be provided.		{{Warning}} This configuration above assumes that the files will be placed in the {{#var:System}} local file system - in this case, an FTP service, username and password must be provided to Palletline's Contrado system to collect the files from this location only. Alternatively, if this process requires the files to be sent to an FTP destination, the FTP server, username and password for this remote server must be provided.

			{{Warning}} Further to this, the configuration and the development below assumes that the files created for the Palletline Contrado system will always be placed in the same folder or FTP destination for the depot. If this requires to be identified through different sub-folders for each owning (rather than executing) depot, then this will require additional development.


			A new Job Group "PLINE" will be set up for Palletline jobs. This will initially be a copy of the Palletforce job group "PALLET". The Export Config ID will be set to the Export Configuration created above (e.g. "PLINE_L02").


	Palletline Reason Codes will be added for all sites that require the ability to complete Palletline jobs, as follows:		Palletline Reason Codes will be added for all sites that require the ability to complete Palletline jobs, as follows:
Line 172:		Line 182:
	* PLINE, description "Palletline"		* PLINE, description "Palletline"

	{{Note}} The Filename field will be increased in length to match the		{{Note}} The Filename field will be increased in length to match the Destination field.

	{{Note}} When complete, the standard interface configuration documentation must be modified to add the new Palletline interface. This is referenced in [[#Appendix B: Quote & Document References\|Appendix B]].		{{Note}} When complete, the standard interface configuration documentation must be modified to add the new Palletline interface. This is referenced in [[#Appendix B: Quote & Document References\|Appendix B]].
Line 225:		Line 235:

	== Server Job Update Processing ==		== Server Job Update Processing ==
	When processing the job update back from the server (in EPODServer.MessageProcess.ProcessJobUpdate), the two new fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG will be saved to the EPOD_JOB record, if the tags exist and contain data.		When processing the job update back from the server (in EPODServer.MessageProcess.ProcessJobUpdate), the two new fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG will be saved to the EPOD_JOB record, if the tags exist and contain data. Unlike JPEG signatures, these SVG signatures need only be stored directly in the database, not translated and saved to the filesystem.

			{{Note}} The SVG signatures can only be populated if normal signatures are also populated, therefore no further work is required to use the SVG signatures in any other modules other than the Palletline export at this time (such as the POD/POC reports).


Line 347:		Line 359:
	See P:\EPOD\Support\Utils\Web Tools\SVGHEXConvert\SVGHEXConvert.html for details and capability of testing results.		See P:\EPOD\Support\Utils\Web Tools\SVGHEXConvert\SVGHEXConvert.html for details and capability of testing results.

			{{Note}} This is coded in JavaScript to show capability and test the results - it is not expected that this test/prototype code will be used within the export process. Note that the code uses basic string manipulation and conversion routines as follows:
			• RegExp replaces
			• String.split
			• parseInt
			• toString and toSting(16)
			The conversion from HEX back to SVG in this test page is required only to aid testing, and is not required in the server or export processes.

	''' Codes '''
			''' Status Codes '''

	* For claused pallets - The reason code entered will be included in the Code tag at all times if present. If this is not present, use the code MPOD. The user comment (if present) will be included in the Notes tag.		* For claused pallets - The reason code entered will be included in the Code tag at all times if present. If this is not present, use the code MPOD. The user comment (if present) will be included in the Notes tag.
	* For cancelled jobs - The Job reason code will be identified against all pallets on the job, in the Code field. No comment is required.		* For cancelled jobs - The Job reason code will be identified against all pallets on the job, in the Code field. No comment is required.
	* For delivered jobs - Any pallets with a reason code against them will have the reason code entered in the Code tag. For pallets that have been successfully delivered, use the code MPOD.		* For delivered jobs - Any pallets with a reason code against them will have the reason code entered in the Code tag. For pallets that have been successfully delivered, use the code MPOD.

			{{Note}} Should the job be cancelled through the Admin system rather than from a device, each pallet on the job should be sent in this message with the code NDNV.

Anw: v0.2 - Minor formatting issues

2017-04-12T13:21:34Z

v0.2 - Minor formatting issues

← Older revision		Revision as of 15:21, 12 April 2017
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|Palletline Interface}}		{{#vardefine:Doc_Title\|Palletline Interface}}
	{{#vardefine:Version\|0.1}}		{{#vardefine:Version\|0.2}}
	{{#vardefine:Date\|~~11th~~ April 2017}}		{{#vardefine:Date\|12th April 2017}}
	{{#vardefine:Reference\|341168}}		{{#vardefine:Reference\|341168}}
	{{#vardefine:Year\|2017}}		{{#vardefine:Year\|2017}}
Line 24:		Line 24:

	== Client Requirement ==		== Client Requirement ==
	Andy Ward advises that David Hathaway Transport are joining the Palletline network and require the POD debrief information to be sent from ~~Calidus~~ ePOD to Palletline's Contrado system.		Andy Ward advises that David Hathaway Transport are joining the Palletline network and require the POD debrief information to be sent from CALIDUS ePOD to Palletline's Contrado system.


Line 32:		Line 32:
	* New Palletline Jobs will be sent to Partnerlink through the existing JobShare format, or directly to the back-end TMSs.		* New Palletline Jobs will be sent to Partnerlink through the existing JobShare format, or directly to the back-end TMSs.
	* When planned, these jobs will be sent to ''CALIDUS'' ePOD through the existing interface in use for the existing partners, and will be identified with a new Job Group e.g. PLINE. The Pallet Depot will be set to the Palletline depot code provided to the carrier, in Hathaway's case, this is "053". The Pallet Consignment will be sent in as the Palletline ID. {{Note}} This will require change to the sending process from the Partner's TMS system to accommodate these new values for every partner that wishes to join the Palletline network.		* When planned, these jobs will be sent to ''CALIDUS'' ePOD through the existing interface in use for the existing partners, and will be identified with a new Job Group e.g. PLINE. The Pallet Depot will be set to the Palletline depot code provided to the carrier, in Hathaway's case, this is "053". The Pallet Consignment will be sent in as the Palletline ID. {{Note}} This will require change to the sending process from the Partner's TMS system to accommodate these new values for every partner that wishes to join the Palletline network.
	* {{Note}} The Palletline ID is noted to be field 4 in the Palletline manifest download file.
	* The jobs will be completed like any other normal delivery.		* The jobs will be completed like any other normal delivery.
	* When jobs are completed, the existing AutoExport functionality will update the Partners (identified through their Partner Codes) using a flat-file export of the job details in OBS Logistics' XML format, as it does now.		* When jobs are completed, the existing AutoExport functionality will update the Partners (identified through their Partner Codes) using a flat-file export of the job details in OBS Logistics' XML format, as it does now.
Line 84:		Line 83:
	A new Job Group "PLINE" will be set up for Palletline jobs. This will initially be a copy of the Palletforce job group "PALLET".		A new Job Group "PLINE" will be set up for Palletline jobs. This will initially be a copy of the Palletforce job group "PALLET".

	A new Auto-Export configuration will be created for each partner that requires ~~ite~~, linked to the job group PLINE:		A new Auto-Export configuration will be created for each partner that requires it, linked to the job group PLINE:
	* EPL_XF_ID - PLINE		* EPL_XF_ID - PLINE
	* EPL_XF_TYPE - FILE		* EPL_XF_TYPE - FILE
Line 125:		Line 124:


	The interface of job data from the host TMS systems will be modified to identify the Pallet System in use ~~(for example, Palletforce, Palletline, Fortec). This will also pass in~~ the Consignment ~~Barcode~~. For Palletline jobs, this will be:		The interface of job data from the host TMS systems will be modified to identify the Pallet System in use and the Consignment ID. For Palletline jobs, this will be:
	* PF Tracking Number - Consignment ~~Barcode~~		* PF Tracking Number - Consignment ID. {{Note}} The Palletline ID is noted to be field 4 in the Palletline manifest download file.
	* Tracking System - "PLINE"		* Tracking System - "PLINE"

Line 187:		Line 186:
	== Mobile Device Application ==		== Mobile Device Application ==
	=== Database/DAL ===		=== Database/DAL ===
	The EPOD_JOB_GROUP table and DAL object will have field EPL_SVG_SIGNATURE_IND added to them, allowing a ~~muneric~~ value defaulting to 0. The field will be populated upon log-on through the Logon Response message from the server, defaulting to 0.		The EPOD_JOB_GROUP table and DAL object will have field EPL_SVG_SIGNATURE_IND added to them, allowing a numeric value defaulting to 0. The field will be populated upon log-on through the Logon Response message from the server, defaulting to 0.

	The EPOD_JOB database table and DAL object will have fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG added to them, allowing the maximum text.		The EPOD_JOB database table and DAL object will have fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG added to them, allowing the maximum text.
Line 201:		Line 200:
	The captured vector signature will be blue, and 2 pixels wide.		The captured vector signature will be blue, and 2 pixels wide.

	The vector ~~svg~~ tag will include the height and width as integers, set from the base width and height values (sigHeight and sigWidth).		The vector SVG tag will include the height and width as integers, set from the base width and height values (sigHeight and sigWidth).

	The vector signature result will be parsed to remove all decimal components and the results passed back to the success callback function p_fncSuccess. The decimal components can be removed using a Regular Expression as follows (example):		The vector signature result will be parsed to remove all decimal components and the results passed back to the success callback function p_fncSuccess. The decimal components can be removed using a Regular Expression as follows (example):
Line 287:		Line 286:
	!Field !!EPOD Field !!Notes		!Field !!EPOD Field !!Notes
	\|-		\|-
	\|Id \|\|EPL_PF_TRACKING_NO \|\|		\|Id \|\|EPL_PF_TRACKING_NO \|\|
	\|-		\|-
	\|PodDate \|\| EPL_ACTUAL_END_DATE in YYYY-MM-DD format\|\|		\|PodDate \|\| EPL_ACTUAL_END_DATE in YYYY-MM-DD format\|\|
	\|-		\|-
	\|PodName \|\| EPL_CUST_SIGNATORY\|\|		\|PodName \|\| EPL_CUST_SIGNATORY\|\|
	\|-		\|-
	\|PodTime \|\| EPL_ACTUAL_END_TIME in HH:MM:SS format, zero-filled\|\|		\|PodTime \|\| EPL_ACTUAL_END_TIME in HH:MM:SS format, zero-filled\|\|
	\|-		\|-
	\|Signature \|\| EPL_SVG_CUST_SIGNATORY, formatted \|\|See following for format details.		\|Signature \|\| EPL_SVG_CUST_SIGNATORY, formatted \|\|See following for format details.
	\|-		\|-
	\|PhotosAvailable \|\|"0", always \|\|		\|PhotosAvailable \|\|"0", always \|\|
	\|-		\|-
	\|Latitude \|\| \|\|See following.		\|Latitude \|\|  \|\|See following.
	\|-		\|-
	\|LatitudeIndicator \|\| \|\|See following.		\|LatitudeIndicator \|\|  \|\|See following.
	\|-		\|-
	\|Longitude \|\| \|\|See following.		\|Longitude \|\|  \|\|See following.
	\|-		\|-
	\|LongitudeIndicator \|\| \|\|See following.		\|LongitudeIndicator \|\|  \|\|See following.
	\|-		\|-
	\|Item \|\| \|\|One created per pallet on the job. All fields below come from EPOD_CONTAINER.		\|Item \|\|  \|\|One created per pallet on the job. All fields below come from EPOD_CONTAINER.
	\|-		\|-
	\|No \|\|Last 2 digits of EPL_CONTAINER_ID \|\|		\|No \|\|Last 2 digits of EPL_CONTAINER_ID \|\|
	\|-		\|-
	\|Status \|\|EPL_REASON_CODE if populated, else "MPOD" \|\|See following.		\|Status \|\|EPL_REASON_CODE if populated, else "MPOD" \|\|See following.
	\|-		\|-
	\|Notes \|\|EPL_CUST_COMMENTS if populated, else do not include the tag. \|\|		\|Notes \|\|EPL_CUST_COMMENTS if populated, else do not include the tag. \|\|
	\|}		\|}
	{{Note}} Unless noted otherwise, all fields are obtained from EPOD_JOB.		{{Note}} Unless noted otherwise, all fields are obtained from EPOD_JOB.
Line 445:		Line 444:
	\|Action=Cancel one SVG job.		\|Action=Cancel one SVG job.

	Complete both of the other jobs, cancelling some containers with different reasons.		Complete both of the other jobs, cancelling some containers with different reasons. Clause some delivered containers.

	Clause some delivered containers.

	Check the database.		Check the database.
	\|Result=The jobs requiring SVG signatures have a value in both SVG signature fields. The SVG signatures are valid, and have width and height attributes with ~~integrer~~ values only (check the data, and load the SVG into a website to check formatting - one has been created in WebTools for this purpose).		\|Result=The jobs requiring SVG signatures have a value in both SVG signature fields. The SVG signatures are valid, and have width and height attributes with integer values only (check the data, and load the SVG into a website to check formatting - one has been created in WebTools for this purpose).

	The job not requiring SVG signatures has both fields blank.		The job not requiring SVG signatures has both fields blank.
Line 459:		Line 456:
	\|Cycle={{ #vardefineecho: Cycle \| {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle \| {{ #var: Cycle }} }}		\|Cycle={{ #vardefineecho: Cycle \| {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle \| {{ #var: Cycle }} }}
	\|Title=Auto-Export		\|Title=Auto-Export
	\|Notes=Ensure that the Job Group with SVG signatures required is linked to an XF Configuration for type PLINE.		\|Notes=Ensure that the Job Group with SVG signatures required is linked to an XF Configuration for type PLINE. Ensure that this configuration points to a file location. Ensure that the other job's job group is not linked to this XF Configuration.

	Ensure that this ~~configruation~~ points to a file location.

	Ensure that the other job's job group is not linked to this XF Configuration.
	}} <!--INSERT TESTS HERE --> {{TestPlan_Test		}} <!--INSERT TESTS HERE --> {{TestPlan_Test
	\|Test={{ #vardefineecho: SubCycle \| {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}		\|Test={{ #vardefineecho: SubCycle \| {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}

Anw: v0.1 - Initial Draft

2017-04-12T12:47:29Z

v0.1 - Initial Draft

New page

<div class="noprint">
{{#vardefine:Client|PART}}
{{#vardefine:ClientName|Partnerlink}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Palletline Interface}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|11th April 2017}}
{{#vardefine:Reference|341168}}
{{#vardefine:Year|2017}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


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

== Client Requirement ==
Andy Ward advises that David Hathaway Transport are joining the Palletline network and require the POD debrief information to be sent from Calidus ePOD to Palletline's Contrado system.

== Solution Overview ==
The process will be as follows:
* Palletline-specific reason codes will be set up within ''CALIDUS'' ePOD, conforming to the list of delivery codes used by Palletline. These reason codes will be exclusive to the Palletline job group, and the Palletline job group will be configured so that only those codes can be used on Palletline jobs.
* New Palletline Jobs will be sent to Partnerlink through the existing JobShare format, or directly to the back-end TMSs.
* When planned, these jobs will be sent to ''CALIDUS'' ePOD through the existing interface in use for the existing partners, and will be identified with a new Job Group e.g. PLINE. The Pallet Depot will be set to the Palletline depot code provided to the carrier, in Hathaway's case, this is "053". The Pallet Consignment will be sent in as the Palletline ID. {{Note}} This will require change to the sending process from the Partner's TMS system to accommodate these new values for every partner that wishes to join the Palletline network.
* {{Note}} The Palletline ID is noted to be field 4 in the Palletline manifest download file.
* The jobs will be completed like any other normal delivery.
* When jobs are completed, the existing AutoExport functionality will update the Partners (identified through their Partner Codes) using a flat-file export of the job details in OBS Logistics' XML format, as it does now.
* The AutoExport process will also export the files to Palletline Contrado system, identified through the Job's Group and the configuration attached to it.
* The AutoExport functionality will store the success or failure of the export, along with any of the returned reasons from the export.

The development required will be as follows:

The mobile device application will be modified to capture the signature in vector format as well as the standard mechanism of an image format. The application will be configured to store this and use it for the Palletline export process.

The Admin Export Configuration screen will be changed to allow Palletline export types to be configured in it.

The Partnerlink Import process will be modified to identify the Palletline job group (e.g. "PLINE"). This will then generate Pallet Ids in the normal way.

The ''CALIDUS'' ePOD AutoExport function will be modified to recognise jobs with the Palletline job group and export a file in the Palletline format.

This format will identify the pallets delivered and any reason codes against them, including claused and cancelled pallets. This will also identify the signatory and signature (if delivered), the GPS coordinates (if available) and the status (POD Uploaded for pallets that were delivered, the selected reason code for clauses and cancellations).

The format will be in XML and will be named following the conventions specified by Palletline. A single file will be created per job completed or cancelled.

{{Note}} It is as yet undecided what mechanism will be used to send this file to Palletline. It will however be one of the following:
* Create the file locally to the ''CALIDUS'' ePOD server and host an FTP service so that Palletline can pick up the file.
* Create the file and send immediately through FTP to the Palletline FTP server.
The process will support either case as standard.

== Scope ==
Assumptions:
* Jobs will be sent to Partnerlink and through to {{#var:System}} using the existing JobShare interfaces, specified in [[FS 326965 Partnerlink EPOD Interface]], referenced in [[#Appendix B: Quote & Document References|Appendix B]].
* Pallets for the Palletline pallet network will be labelled with their own network's pallet labels, and not Partnerlink labels. It is expected that pallet IDs will be created by {{#var:System}} in the normal way, identifying the individual pallets by assigning each pallet a unique ID, counting from the 1 to the total number of pallets.
* Palletline's Contrado system will be updated separately to the partner's TMS systems.
* The Consignment will already exist within the Palletline Contrado system, ready for updating with POD information from ''CALIDUS'' ePOD.

Changes will be made to latest version of {{#var:System}} only, and will require an update to all application components and full system and user acceptance testing.

The reason codes used by Palletline are not currently used in the Partnerlink system (2 character numeric values from 01 to 19), so these will not cause any contention in the system. It is assumed that any conflicts between these reason codes and any generic or partner-specific reason codes of the same type will be resolved by the partners.



= Set-up =

== Pre-requisites ==

== Menu Structure ==

== Data ==
A new Job Group "PLINE" will be set up for Palletline jobs. This will initially be a copy of the Palletforce job group "PALLET".

A new Auto-Export configuration will be created for each partner that requires ite, linked to the job group PLINE:
* EPL_XF_ID - PLINE
* EPL_XF_TYPE - FILE
* EPL_XF_DIRECTION - O
* EPL_XF_DESTINATION - E:\ftpserver\PartnerLink\HATHAWAY_TST\PLINE
* EPL_EXPORT_JOB_TYPES - D
{{Note}} This configuration is for the test system and assumes that the folder will be created.

{{Warning}} This configuration above assumes that the files will be placed in the {{#var:System}} local file system - in this case, an FTP service, username and password must be provided to Palletline's Contrado system to collect the files from this location only. Alternatively, if this process requires the files to be sent to an FTP destination, the FTP server, username and password for this remote server must be provided.

Palletline Reason Codes will be added for all sites that require the ability to complete Palletline jobs, as follows:
{| border="1"
|- bgcolor="silver"
!Code !!Description !!Type !!Note
|-
|DELD ||Delivered damaged ||CLA || 
|-
|DELS ||Delivered with Shortages ||CLA || 
|-
|DNDS ||Delivered DSC Failure ||CLA || 
|-
|MPOD ||Delivered OK || ||Normal Successful Delivery
|-
|NDNV ||Not Del Not On Vehicle DSC ||DET || 
|-
|NDOE ||Not Del Order Error ||DET || 
|-
|NDOT ||Not Del Out of Time ||JOB || 
|-
|NDPC ||Not Del Premise Closed ||JOB || 
|-
|NDRD ||Not Del Refused Damaged ||DET || 
|-
|NDRE ||Not Del Refused and Return ||DET || 
|-
|NDRS ||Not Del Refused Short ||JOB || 
|-
|NDTC ||Not Del T and Cs refused ||JOB || 
|}

The interface of job data from the host TMS systems will be modified to identify the Pallet System in use (for example, Palletforce, Palletline, Fortec). This will also pass in the Consignment Barcode. For Palletline jobs, this will be:
* PF Tracking Number - Consignment Barcode
* Tracking System - "PLINE"



= Functional Description =
== Database ==
Stored Procedure EPOD_SETUP_LISTS will be modified to add PLINE to EPOD_LIST_ITEMS for Export Types (List 38 - EXPORTS_CLIENT_TYPE). {{Note}} This meta-data needs to be added to the system upon implementation by OBSL staff to ensure that Palletline jobs trigger messages to the Palletline Contrado system. No code modifications are required to the trigger to write the control records, as adding this record will then handle that.

The EPOD_JOB table and DAL object will be modified to add the following new fields:
* EPL_JOB_SIGNATURE_SVG - nvarchar(MAX)
* EPL_ENG_SIGNATURE_SVG - nvarchar(MAX)
These fields will be added to all required stored procedures in the database. {{Note}} These fields are not to be added to the fields for searching or selecting data.

These fields will be added to the standard XML export process, if populated. If not, the tags will not be added.

{{Note}} The Export XSDs must be modified to add these tags as optional tags (minOccurs 0).

{{Note}} When this code is included in a build for release to a customer, the standard Export documentation must be created for this version including these new tags.

The EPOD_JOB_GROUPS table and DAL object will be modified to add the following new field:
* EPL_SVG_SIGNATURE_IND - smallint, not null, default 0
This field will be added to all required stored procedures in the database. {{Note}} this field is not to be added to the fields for searching or selecting data.

This field will be added to the XML export, returned when a mobile device logs on to the system.

The indexes on table EPOD_USER_AUDIT must be examined for completeness - an compound index must exist called IX_EPOD_USER_AUDIT_JOB_LOAD_SITE_GPS with the following fields:
* EPL_JOB_ID
* EPL_LOAD_ID
* EPL_SITE_ID
* EPL_GPS_COORD

== Admin ==
=== Export Configuration Screen ===
The Admin Export Configuration screen will be changed to allow the parameters for the new Palletline extract to be specified against it.

[[File:FS_341168_ExportConfig1.PNG|border|600px]]
<br />''Export Configuration Maintenance''<br />

The ID drop-down list will be modified to allow the new values below when entering a new configuration:
* PLINE, description "Palletline"

{{Note}} The Filename field will be increased in length to match the

{{Note}} When complete, the standard interface configuration documentation must be modified to add the new Palletline interface. This is referenced in [[#Appendix B: Quote & Document References|Appendix B]].

=== Job Group Maintenance ===
A new Job Group flag EPL_SVG_SIGNATURE_IND will be added to the PDA tab under the Driver Signatures, with values Enabled (Y) or Disabled (N), with label "SVG Signatures", and a popup tooltip (title) of "Capture SVG signature as well as JPG signature on device" added to the input field and label.

[[File:FS_341168_JobGroup1.PNG|border|600px]]
<br />''Job Group Maintenance''<br />

== Mobile Device Application ==
=== Database/DAL ===
The EPOD_JOB_GROUP table and DAL object will have field EPL_SVG_SIGNATURE_IND added to them, allowing a muneric value defaulting to 0. The field will be populated upon log-on through the Logon Response message from the server, defaulting to 0.

The EPOD_JOB database table and DAL object will have fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG added to them, allowing the maximum text.

The PDA_JOBS DAL object will be modified to have the two fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG added to it as properties.

=== Signature ===
The signature captured by the device will be 25% shorter by changing the signature height from the base height sigHeight from 235 to 180.

The signature itself will be positioned to the top of the available space rather than the centre.

The captured vector signature will be blue, and 2 pixels wide.

The vector svg tag will include the height and width as integers, set from the base width and height values (sigHeight and sigWidth).

The vector signature result will be parsed to remove all decimal components and the results passed back to the success callback function p_fncSuccess. The decimal components can be removed using a Regular Expression as follows (example):
vars.vector = vars.vector.replace(/\.\d*?(\,|\s)/g, $1);
{{Note}} The vector SVG signature should still be captured on touching the screen on the device, as this is used to determine whether the user has entered a signature. However, this will only be returned to the function if the new Job Group EPL_SVG_SIGNATURE_IND flag is enabled (set to 1).

The Signature Terms and Conditions view will be increased in size from 40% to 50%, making better use of the available space from the smaller signature.

The utility function to control the sequence of tasks after a job is complete, including signatures (funNextJobEndTask) will be modified to add an extra parameter p_strSVG to the success callback function definition. This will then be used to update all the jobs being completed with the SVG Signature returned. This will be done for both Customer and Driver Signature, updating the appropriate fields on PDA_JOB (respectively EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG).

The Job Update XML will be modified so that the SVG signatures are returned as well as the normal signatures. If there is no data in the SVG signature fields, the tags should not be present. These tags will be added to the CONFIRMATION tag, after the existing elements.

...
<CONFIRMATION>
<EPL_ENG_SIGNATURE></EPL_ENG_SIGNATURE>
<EPL_JOB_SIGNATURE></EPL_JOB_SIGNATURE>
'''''<EPL_JOB_SIGNATURE_SVG></EPL_JOB_SIGNATURE_SVG>'''''
'''''<EPL_ENG_SIGNATURE_SVG></EPL_ENG_SIGNATURE_SVG>'''''
</CONFIRMATION>
...

{{Note}} This device work has been extensively prototyped and is available to be implemented.

== Server Job Update Processing ==
When processing the job update back from the server (in EPODServer.MessageProcess.ProcessJobUpdate), the two new fields EPL_JOB_SIGNATURE_SVG and EPL_ENG_SIGNATURE_SVG will be saved to the EPOD_JOB record, if the tags exist and contain data.

== Auto-Export ==
The auto-export process retrieves all completed jobs that have not yet been transferred out of the system, and checks whether they require transfer.

Any that do not require transfer will be marked as transferred.

Any that have an applicable export configuration (see the database package modification above) will be passed to a procedure to transfer out according to the type (XF_ID) and parameters set against the configuration.

This function (EPOD_SYS_EXPORT.ExportXFControl) will be modified when checking dalEPOD_XF_CONFIG.EPL_XF_ID, adding another case:
* PLINE - for Palletline exports (see next section) - calls new function EPOD_SYS_EXPORT.GeneratePlineContent, defined below.

The Filename will be defined in the Export Configuration as (EPL_PF_DEPOT)-(DATE)-(TIME)-(UID).xml
Where:
* EPL_PF_DEPOT - the PF Depot for the job.
* DATE - date sent in YYYYMMDD format.
* TIME - time sent in HHMMSS format.
* UID - a 2-digit unique sequence for every file sent.
The file will always be "xml" extension.

{{Note}} The EPODServer.EPOD_SYS_EXPORT.translateFilename function will be modified to achieve the above.

Once all the data is created, the function then sends the message in the format specified on the transfer configuration record, as now.

=== New Palletline Auto-Export Process ===
A new export process EPOD_SYS_EXPORT.GeneratePlineContent will be created to handle this export.

Full details of the Palletline export format can be found in the ''Service - DSC Imports'' specification, referenced in [[#Appendix B: Quote & Document References|Appendix B]].

The file will be created in XML format, as follows:
<Root>
<Job>
<Id> </Id>
<PodDate> </PodDate>
<PodName> </PodName>
<PodTime> </PodTime>
<Signature> </Signature>
<PhotosAvailable> </PhotosAvailable>
<Latitude> </Latitude>
<LatitudeIndicator> </LatitudeIndicator>
<Longitude> </Longitude>
<LongitudeIndicator> </LongitudeIndicator>
<Pallets>
<Item>
<No></No>
<Status>
<Code> </Code>
<Notes> </Notes>
</Status>
</Item>
</Pallets>
</Job>
</Root>

The field are populated as follows:
{| border="1"
|- bgcolor="silver"
!Field !!EPOD Field !!Notes
|-
|Id ||EPL_PF_TRACKING_NO ||
|-
|PodDate || EPL_ACTUAL_END_DATE in YYYY-MM-DD format||
|-
|PodName || EPL_CUST_SIGNATORY||
|-
|PodTime || EPL_ACTUAL_END_TIME in HH:MM:SS format, zero-filled||
|-
|Signature || EPL_SVG_CUST_SIGNATORY, formatted ||See following for format details.
|-
|PhotosAvailable ||"0", always ||
|-
|Latitude || ||See following.
|-
|LatitudeIndicator || ||See following.
|-
|Longitude || ||See following.
|-
|LongitudeIndicator || ||See following.
|-
|Item || ||One created per pallet on the job. All fields below come from EPOD_CONTAINER.
|-
|No ||Last 2 digits of EPL_CONTAINER_ID ||
|-
|Status ||EPL_REASON_CODE if populated, else "MPOD" ||See following.
|-
|Notes ||EPL_CUST_COMMENTS if populated, else do not include the tag. ||
|}
{{Note}} Unless noted otherwise, all fields are obtained from EPOD_JOB.

''' GPS Coordinates '''

The GPS co-ordinates will be obtained from the Job Update user audit record for this job.

The GPS coordinates will be added only if present/found - if not, the tags will be omitted. The GPS coordinate is split to latitude and longitude, which are then converted to degrees, minutes and seconds, then sent as DDMM.S format.

For example:
+52° 43' 19.80", -1° 21' 46.21" (52.722166, -1.362835)

52.722166 becomes +52° 43' 19.80". This is converted and stored as 5243.20.

{{Note}} The seconds are stored and displayed as strings with no zero filling.

Therefore:
* if there are 3 seconds, this is shown as ".3", not ".03".
* if there are 20 seconds, this is shown as ".20", not ".2".

For conversion of GPS coordinates to custom format:
* See P:\EPOD\Support\Utils\Web Tools\JSTest\jstest.html, function convertGPS for details.

''' Signature '''

The signature is sent in a bespoke format, converted from SVG into HEX couplets.

At the same time, the signature is also re-sized to the required size.

See P:\EPOD\Support\Utils\Web Tools\SVGHEXConvert\SVGHEXConvert.html for details and capability of testing results.

''' Codes '''

* For claused pallets - The reason code entered will be included in the Code tag at all times if present. If this is not present, use the code MPOD. The user comment (if present) will be included in the Notes tag.
* For cancelled jobs - The Job reason code will be identified against all pallets on the job, in the Code field. No comment is required.
* For delivered jobs - Any pallets with a reason code against them will have the reason code entered in the Code tag. For pallets that have been successfully delivered, use the code MPOD.

''' Sample file '''
<Root>
<Job>
<Id>CON12345678</Id>
<PodDate>2017-03-09</PodDate>
<PodName>Jack Jones</PodName>
<PodTime>08:33:00</PodTime>
<Signature>...</Signature>
<PhotosAvailable>0</PhotosAvailable>
<Latitude>5243.20</Latitude>
<LatitudeIndicator>N</LatitudeIndicator>
<Longitude>00121.46</Longitude>
<LongitudeIndicator>W</LongitudeIndicator>
<Pallets>
<Item>
<No>01</No>
<Status>
<Code>MPOD</Code>
</Status>
</Item>
<Item>
<No>02</No>
<Status>
<Code>MPOD</Code>
</Status>
</Item>
<Item>
<No>03</No>
<Status>
<Code>NDRC</Code>
</Status>
</Item>
<Item>
<No>04</No>
<Status>
<Code>DELD</Code>
<Notes>Some Clause Notes</Notes>
</Status>
</Item>
</Pallets>
</Job>
</Root>

See sample files created for Palletline:
* P:\EPOD\Estimates & Specifications\Estimates\341168 - PalletLine Interface\053-20170309-083300-01.xml
* P:\EPOD\Estimates & Specifications\Estimates\341168 - PalletLine Interface\053-20170309-083300-02.xml


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing Exports out to the Palletline Contrado system from {{#var:System}}.
|MenuAccess=Administration/Auto-Export
|Prerequisites=A system configured as Partnerlink Test.
|Objective=To test: Auto-Export may be configured for Palletline exports and; Auto-Export exports the jobs correctly to the Palletline Contrado system.
}} {{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin System
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that Palletline exports may be configured through the Auto-Export screen.
|Result=New Export Configurations may be created of ID PLINE, allowing selection of this through the drop-down grid and displayed on the table on the screen.
|Remarks=
|PassFail=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Ensure that the new SVG Signatures flag can be set and amended on new and existing job groups.
|Result=New Job Groups may be created with the SVG Signature flag set or unset and saved with no issues.

Job groups may be edited and the SVG Signatures flag set and unset and saved with no issues.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=SVG Signature Capture
|Notes=Ensure that there are 3 jobs, 2 with a job group that requires the SVG signature, and one that does not. Each should have multiple containers.

Ensure that the job requires driver and customer signature.

Ensure the correct reason codes are entered for the Job Group requiring SVG signatures, and that they are the only ones that can be used for that job.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Cancel one SVG job.

Complete both of the other jobs, cancelling some containers with different reasons.

Clause some delivered containers.

Check the database.
|Result=The jobs requiring SVG signatures have a value in both SVG signature fields. The SVG signatures are valid, and have width and height attributes with integrer values only (check the data, and load the SVG into a website to check formatting - one has been created in WebTools for this purpose).

The job not requiring SVG signatures has both fields blank.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Auto-Export
|Notes=Ensure that the Job Group with SVG signatures required is linked to an XF Configuration for type PLINE.

Ensure that this configruation points to a file location.

Ensure that the other job's job group is not linked to this XF Configuration.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check the export directory.
|Result=The Job requiring export that was completed has a Palletline export file created for it, with the correct name. The file is populated correctly. The GPS is set correctly. The Signature is converted correctly (use the WebTools page for checking this). The containers are included in the file - all normally delivered containers are marked with status MPOD, while all others have the correct reasons. The claused container has the correct clause code and notes against it.

The Job requiring export that was cancelled has a Palletline export file created for it, with the correct name and contents as before, but all pallets are cancelled with correct job cancellation reason code, and no signature is included.

The job not requiring export has no file.
|Remarks=
|PassFail=
}}{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1=[[EST 341168 PalletLine Integration]]
|RefV1=1.0
|RefDate1=30/03/2015
|Ref2=[[FS 326965 Partnerlink EPOD Interface]]
|RefV2=1.0
|RefDate2=22/05/2015
|Ref3=Service - DSC Imports.docx
|RefV3=0.17
|RefDate3=16/07/2010
|Ref4=[http://172.198.45.54/calidus-assist/EPOD/index.php/Standard_Interface_Configuration Standard Interface Configuration (''CALIDUS'' Assist)]
|RefV4= 
|RefDate4= 
|EREQ=0
|EEST=1.50
|EFS=1.50
|ETS=0
|EDEV=7
|ESTT=1.25
|EIMP=0.25
|EPM=0.50
|REQ=0
|EST=1.50
|FS=1.50
|TS=0
|DEV=7
|ST=1.25
|IMP=0.25
|PM=0.50
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|FOC=N
|DiscountPerc=50
|DiscountText=Hathaways Discount
|Rev1=Matt Turner
|Rev1Title=OBSL Account Manager
|Rev2=Andy Ward
|Rev2Title=Customer Representative
}}</div>
[[Category:{{#var:Client}} FS]]