https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/api.php?action=feedcontributions&feedformat=atom&user=CakCalidus HUB - User contributions [en-gb]2026-07-01T19:25:45ZUser contributionsMediaWiki 1.39.8https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Outbound_Guide&diff=11469Support - Tesla EDI Outbound Guide2024-09-06T09:53:52Z<p>Cak: correct typo</p>
<hr />
<div><br />
== Order Tracking ==<br />
A customer specific tracking interface is required to track the milestones associated with an order.<br />
<br />
== System parameters ==<br />
USE_XML_ORDER_SUB_REFS should be set to Y for the appropriate cost centre.<br />
<br />
== Outbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost centre and the Tesla customer. The flow uses the standard ORD_XML_OUT flow type and includes a Milestones section.<br />
<br />
[[File:Tesla outbound edi 1.png|800x800px]]<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
[[File:Tesla outbound edi 2.png|800x800px]]<br />
<br />
== Messages sent ==<br />
The following message types will be sent <br />
<br />
· ORD<br />
<br />
· CAN<br />
<br />
· DEP<br />
<br />
· ARR<br />
<br />
· DEL<br />
<br />
== Triggering Events ==<br />
An '''‘ORD’''' message will be triggered when the first item is added to an order and will only be sent once. The EDI parameter called ‘PREVENT_RESEND_ORDER’ will be set to ‘Y’ to ensure that a control record for an ‘ORD’ message is not created when an earlier message has been processed successfully. The trigger ‘TRG_SOI_XML’ will create the control record. The OMS status is ‘UNSCHEDULED’ and the milestone comment is ‘Booking Acknowledged’<br />
<br />
A '''‘DEP’''' message will be created when the actual departure time on the collection stop of an order is updated to show that the vehicle has left the collection location.<br />
<br />
The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘Departed Origin’ if this is the initial collection location or ‘Departed Consolidation Facility’ if the location is a x-dock location.<br />
<br />
An '''‘ARR’''' message will be created when the actual arrival time on the delivery stop of an order is updated to show that the vehicle has arrived at the delivery location. The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘At Dest’ if this is the final delivery location or ‘At Consolidation Facility’ if the location is a x-dock location.<br />
<br />
'''**Note''' If an order exists on multiple trips the ‘DEP’ and ‘ARR’ messages will be sent for each leg of the orders journey.<br />
<br />
A '''‘DEL’''' message will be created when the delivered quantities on an order line are updated for the first time, i.e. when the delivered quantity is changed from null to 1, for example. The trigger TRG_SOL_XML will create the control record<br />
<br />
A '''‘CAN’''' message will be triggered if the status of an order is set to ‘CANCELLED’. The trigger ‘TRG_SCH_ORD_XML_INT’ will create the control record. The OMS status is ‘CANCELLED’ and the milestone comment ‘Booking Rejected’.<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\545095 - SCR-CTMS-02428249-05 - CTMS - Customer-Specific Tracking File<br />
<br />
<br />
P:\Development\CTMS\DHL\623640- Changes to Tesla tracking milestones<br />
[[Category:Support Documents]]<br />
[[Category:DHL Tesla]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Outbound_Guide&diff=11468Support - Tesla EDI Outbound Guide2024-09-06T09:50:47Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Tracking ==<br />
A customer specific tracking interface is required to track the milestones associated with an order.<br />
<br />
== System parameters ==<br />
USE_XML_ORDER_SUB_REFS should be set to Y for the appropriate cost center.<br />
<br />
== Outbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost center and the Tesla customer. The flow uses the standard ORD_XML_OUT flow type and includes a Milestones section.<br />
<br />
[[File:Tesla outbound edi 1.png|800x800px]]<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
[[File:Tesla outbound edi 2.png|800x800px]]<br />
<br />
== Messages sent ==<br />
The following message types will be sent <br />
<br />
· ORD<br />
<br />
· CAN<br />
<br />
· DEP<br />
<br />
· ARR<br />
<br />
· DEL<br />
<br />
== Triggering Events ==<br />
An '''‘ORD’''' message will be triggered when the first item is added to an order and will only be sent once. The EDI parameter called ‘PREVENT_RESEND_ORDER’ will be set to ‘Y’ to ensure that a control record for an ‘ORD’ message is not created when an earlier message has been processed successfully. The trigger ‘TRG_SOI_XML’ will create the control record. The OMS status is ‘UNSCHEDULED’ and the milestone comment is ‘Booking Acknowledged’<br />
<br />
A '''‘DEP’''' message will be created when the actual departure time on the collection stop of an order is updated to show that the vehicle has left the collection location.<br />
<br />
The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘Departed Origin’ if this is the initial collection location or ‘Departed Consolidation Facility’ if the location is a x-dock location.<br />
<br />
An '''‘ARR’''' message will be created when the actual arrival time on the delivery stop of an order is updated to show that the vehicle has arrived at the delivery location. The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘At Dest’ if this is the final delivery location or ‘At Consolidation Facility’ if the location is a x-dock location.<br />
<br />
'''**Note''' If an order exists on multiple trips the ‘DEP’ and ‘ARR’ messages will be sent for each leg of the orders journey.<br />
<br />
A '''‘DEL’''' message will be created when the delivered quantities on an order line are updated for the first time, i.e. when the delivered quantity is changed from null to 1, for example. The trigger TRG_SOL_XML will create the control record<br />
<br />
A '''‘CAN’''' message will be triggered if the status of an order is set to ‘CANCELLED’. The trigger ‘TRG_SCH_ORD_XML_INT’ will create the control record. The OMS status is ‘CANCELLED’ and the milestone comment ‘Booking Rejected’.<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\545095 - SCR-CTMS-02428249-05 - CTMS - Customer-Specific Tracking File<br />
<br />
<br />
P:\Development\CTMS\DHL\623640- Changes to Tesla tracking milestones</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_outbound_edi_2.png&diff=11467File:Tesla outbound edi 2.png2024-09-06T09:48:58Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_outbound_edi_1.png&diff=11466File:Tesla outbound edi 1.png2024-09-06T09:48:43Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Outbound_Guide&diff=11465Support - Tesla EDI Outbound Guide2024-09-06T09:47:46Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Tracking ==<br />
A customer specific tracking interface is required to track the milestones associated with an order.<br />
<br />
== System parameters ==<br />
USE_XML_ORDER_SUB_REFS should be set to Y for the appropriate cost center.<br />
<br />
== Outbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost center and the Tesla customer. The flow uses the standard ORD_XML_OUT flow type and includes a Milestones section.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
== Messages sent ==<br />
The following message types will be sent <br />
<br />
· ORD<br />
<br />
· CAN<br />
<br />
· DEP<br />
<br />
· ARR<br />
<br />
· DEL<br />
<br />
== Triggering Events ==<br />
An '''‘ORD’''' message will be triggered when the first item is added to an order and will only be sent once. The EDI parameter called ‘PREVENT_RESEND_ORDER’ will be set to ‘Y’ to ensure that a control record for an ‘ORD’ message is not created when an earlier message has been processed successfully. The trigger ‘TRG_SOI_XML’ will create the control record. The OMS status is ‘UNSCHEDULED’ and the milestone comment is ‘Booking Acknowledged’<br />
<br />
A '''‘DEP’''' message will be created when the actual departure time on the collection stop of an order is updated to show that the vehicle has left the collection location.<br />
<br />
The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘Departed Origin’ if this is the initial collection location or ‘Departed Consolidation Facility’ if the location is a x-dock location.<br />
<br />
An '''‘ARR’''' message will be created when the actual arrival time on the delivery stop of an order is updated to show that the vehicle has arrived at the delivery location. The trigger ‘TRG_STS_XML_OUT’ will create the control record. The OMS status is ‘SCHEDULED’ and the milestone comment is ‘At Dest’ if this is the final delivery location or ‘At Consolidation Facility’ if the location is a x-dock location.<br />
<br />
'''**Note''' If an order exists on multiple trips the ‘DEP’ and ‘ARR’ messages will be sent for each leg of the orders journey.<br />
<br />
A '''‘DEL’''' message will be created when the delivered quantities on an order line are updated for the first time, i.e. when the delivered quantity is changed from null to 1, for example. The trigger TRG_SOL_XML will create the control record<br />
<br />
A '''‘CAN’''' message will be triggered if the status of an order is set to ‘CANCELLED’. The trigger ‘TRG_SCH_ORD_XML_INT’ will create the control record. The OMS status is ‘CANCELLED’ and the milestone comment ‘Booking Rejected’.<br />
<br />
An example tracking message is included below<br />
<br />
<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\545095 - SCR-CTMS-02428249-05 - CTMS - Customer-Specific Tracking File<br />
<br />
<br />
P:\Development\CTMS\DHL\623640- Changes to Tesla tracking milestones</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Inbound_Guide&diff=11464Support - Tesla EDI Inbound Guide2024-09-06T09:40:09Z<p>Cak: Categorisation</p>
<hr />
<div><br />
== Order Template ==<br />
For each dealership an order will be created each day, this is a placeholder which will be added to by the import process. This is existing fixed schedules functionality which has not been modified for Tesla.<br />
<br />
== System parameters ==<br />
ALLOW_MULTIPLE_ADD_REFS should be set to Y for the appropriate cost centre.<br />
<br />
== Dealership Decodes ==<br />
The delivery locations in the inbound files are the Tesla dealership locations not CTMS locations and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
[[File:Tesla edi 1.png|800x800px]]<br />
<br />
== Du Type Decodes ==<br />
The du types in the inbound files are the Tesla du types not du types and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
[[File:Tesla edi 2.png|800x800px]]<br />
<br />
== Inbound Files ==<br />
An example inbound file is included below<br />
<br />
== EDI Tables ==<br />
Two new tables have been created to hold the details of the Inbound files<br />
<br />
* TESLA_EDI_ORDER_HEADER<br />
* TESLA_EDI_ORDER_DETAILS<br />
<br />
Each table has an associated sequence, and the detail is linked to the header by the header ID.<br />
== Inbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost centre and the Tesla customer. The import processes will be completed within the DP_TESLA_EDI package using the IMPORT_ORDERS procedure.<br />
<br />
[[File:Tesla edi 3.png|800x800px]]<br />
<br />
== File Format ==<br />
The test files provide simply have numeric a file name, so the file pattern is not specified on the EDI flow. An example file is included above.<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
[[File:Tesla edi 4.png|800x800px]]<br />
<br />
== EDI Report Values ==<br />
The following Report values are required<br />
<br />
[[File:Tesla edi 5.png|800x800px]]<br />
<br />
== Order Processing ==<br />
An order will exist on the correct schedule for each dealership in the inbound file the delivery date can be found in the “deliveryStartDateTime” tag and the dealership in the “referenceField7” tag<br />
<br />
[[File:Tesla edi 6.png|713x713px]]<br />
<br />
The correct CTMS dealership location will then be found using the decode<br />
<br />
[[File:Tesla edi 7.png|800x800px]]<br />
<br />
A skeleton order will exist in CTMS which will have been created by an existing process note the schedule and delivery location agree with your inbound file, if no order is found on the schedule for the dealership an error will be raised and the order will not be processed.<br />
<br />
[[File:Tesla edi 8.png|800x800px]]<br />
The product type is not contained in the inbound file so therefore must exist as a default parameter on the EDI flow. If no default is present an error will be raised and the order will not process.<br />
<br />
The Du type must also exist as an EDI parameter on the flow. An attempt will be made to decode the passed in palletSize value which contains a du type which has been mapped so in this example<br />
<br />
[[File:Tesla edi 9.png]]<br />
<br />
Maps to<br />
<br />
[[File:Tesla edi 10.png|800x800px]]<br />
<br />
If no mapping is found the EDI default will be used. If no default is present an error will be raised and the order will not process.<br />
<br />
Once the correct order has been located and the product and DU type validated. The order will be updated with the details in the inbound file.<br />
<br />
If the DU type doesn’t exist on the current order a new line will be created for that DU type, the placeholder line will be removed at this point if no items exist with the same du type.<br />
<br />
[[File:Tesla edi 11.png|800x800px]]<br />
<br />
Note the weight and volume on the line these are taken directly from the inbound pallet section and should not be manipulated.<br />
<br />
[[File:Tesla edi 12.png]]<br />
<br />
Order items will have been created<br />
<br />
[[File:Tesla edi 13.png]]<br />
<br />
Item contents will have been created<br />
<br />
[[File:Tesla edi 14.png|800x800px]]<br />
Additional References will have been created to indicate the Consolidated order reference, MH Order references(s) and Tesla references(s)<br />
<br />
[[File:Tesla edi 15.png|800x800px]]<br />
Each reference should only be stored once and the values are found as follows<br />
<br />
Consolidated Order – “aggregatedOrderNumber” tag, only 1 per order will be stored<br />
<br />
[[File:Tesla edi 16.png]]<br />
MH(Manhattan) Order ref – “OrderNumber” tag<br />
<br />
[[File:Tesla edi 17.png]]<br />
<br />
Tesla Reference – “referenceField4” of the line section<br />
<br />
[[File:Tesla edi 18.png]]<br />
<br />
== Interface Errors ==<br />
A new Tesla Orders tab page has been added to the interface errors screen which will contain the success/failure stats of each or the file imports and allow the user to reprocess any failed records after the issue has been corrected. This process will use the same package functionality as the inbound orders.<br />
<br />
[[File:Tesla edi 19.png|800x800px]]<br />
<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\543347 SCR - Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\613005 SCR - Changes to the Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\632041 - Changes to Tesla order interface for Aggregated order number<br />
[[Category:Support Documents]]<br />
[[Category:DHL Tesla]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Inbound_Guide&diff=11463Support - Tesla EDI Inbound Guide2024-09-06T09:39:09Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Template ==<br />
For each dealership an order will be created each day, this is a placeholder which will be added to by the import process. This is existing fixed schedules functionality which has not been modified for Tesla.<br />
<br />
== System parameters ==<br />
ALLOW_MULTIPLE_ADD_REFS should be set to Y for the appropriate cost centre.<br />
<br />
== Dealership Decodes ==<br />
The delivery locations in the inbound files are the Tesla dealership locations not CTMS locations and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
[[File:Tesla edi 1.png|800x800px]]<br />
<br />
== Du Type Decodes ==<br />
The du types in the inbound files are the Tesla du types not du types and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
[[File:Tesla edi 2.png|800x800px]]<br />
<br />
== Inbound Files ==<br />
An example inbound file is included below<br />
<br />
== EDI Tables ==<br />
Two new tables have been created to hold the details of the Inbound files<br />
<br />
* TESLA_EDI_ORDER_HEADER<br />
* TESLA_EDI_ORDER_DETAILS<br />
<br />
Each table has an associated sequence, and the detail is linked to the header by the header ID.<br />
== Inbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost centre and the Tesla customer. The import processes will be completed within the DP_TESLA_EDI package using the IMPORT_ORDERS procedure.<br />
<br />
[[File:Tesla edi 3.png|800x800px]]<br />
<br />
== File Format ==<br />
The test files provide simply have numeric a file name, so the file pattern is not specified on the EDI flow. An example file is included above.<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
[[File:Tesla edi 4.png|800x800px]]<br />
<br />
== EDI Report Values ==<br />
The following Report values are required<br />
<br />
[[File:Tesla edi 5.png|800x800px]]<br />
<br />
== Order Processing ==<br />
An order will exist on the correct schedule for each dealership in the inbound file the delivery date can be found in the “deliveryStartDateTime” tag and the dealership in the “referenceField7” tag<br />
<br />
[[File:Tesla edi 6.png|713x713px]]<br />
<br />
The correct CTMS dealership location will then be found using the decode<br />
<br />
[[File:Tesla edi 7.png|800x800px]]<br />
<br />
A skeleton order will exist in CTMS which will have been created by an existing process note the schedule and delivery location agree with your inbound file, if no order is found on the schedule for the dealership an error will be raised and the order will not be processed.<br />
<br />
[[File:Tesla edi 8.png|800x800px]]<br />
The product type is not contained in the inbound file so therefore must exist as a default parameter on the EDI flow. If no default is present an error will be raised and the order will not process.<br />
<br />
The Du type must also exist as an EDI parameter on the flow. An attempt will be made to decode the passed in palletSize value which contains a du type which has been mapped so in this example<br />
<br />
[[File:Tesla edi 9.png]]<br />
<br />
Maps to<br />
<br />
[[File:Tesla edi 10.png|800x800px]]<br />
<br />
If no mapping is found the EDI default will be used. If no default is present an error will be raised and the order will not process.<br />
<br />
Once the correct order has been located and the product and DU type validated. The order will be updated with the details in the inbound file.<br />
<br />
If the DU type doesn’t exist on the current order a new line will be created for that DU type, the placeholder line will be removed at this point if no items exist with the same du type.<br />
<br />
[[File:Tesla edi 11.png|800x800px]]<br />
<br />
Note the weight and volume on the line these are taken directly from the inbound pallet section and should not be manipulated.<br />
<br />
[[File:Tesla edi 12.png]]<br />
<br />
Order items will have been created<br />
<br />
[[File:Tesla edi 13.png]]<br />
<br />
Item contents will have been created<br />
<br />
[[File:Tesla edi 14.png|800x800px]]<br />
Additional References will have been created to indicate the Consolidated order reference, MH Order references(s) and Tesla references(s)<br />
<br />
[[File:Tesla edi 15.png|800x800px]]<br />
Each reference should only be stored once and the values are found as follows<br />
<br />
Consolidated Order – “aggregatedOrderNumber” tag, only 1 per order will be stored<br />
<br />
[[File:Tesla edi 16.png]]<br />
MH(Manhattan) Order ref – “OrderNumber” tag<br />
<br />
[[File:Tesla edi 17.png]]<br />
<br />
Tesla Reference – “referenceField4” of the line section<br />
<br />
[[File:Tesla edi 18.png]]<br />
<br />
== Interface Errors ==<br />
A new Tesla Orders tab page has been added to the interface errors screen which will contain the success/failure stats of each or the file imports and allow the user to reprocess any failed records after the issue has been corrected. This process will use the same package functionality as the inbound orders.<br />
<br />
[[File:Tesla edi 19.png|800x800px]]<br />
<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\543347 SCR - Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\613005 SCR - Changes to the Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\632041 - Changes to Tesla order interface for Aggregated order number</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_19.png&diff=11461File:Tesla edi 19.png2024-09-06T09:26:57Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_18.png&diff=11460File:Tesla edi 18.png2024-09-06T09:26:56Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_15.png&diff=11459File:Tesla edi 15.png2024-09-06T09:26:55Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_17.png&diff=11458File:Tesla edi 17.png2024-09-06T09:26:55Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_16.png&diff=11457File:Tesla edi 16.png2024-09-06T09:26:55Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_14.png&diff=11456File:Tesla edi 14.png2024-09-06T09:26:55Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_13.png&diff=11455File:Tesla edi 13.png2024-09-06T09:26:53Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_11.png&diff=11454File:Tesla edi 11.png2024-09-06T09:26:52Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_12.png&diff=11453File:Tesla edi 12.png2024-09-06T09:26:52Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_10.png&diff=11452File:Tesla edi 10.png2024-09-06T09:26:51Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_8.png&diff=11451File:Tesla edi 8.png2024-09-06T09:26:51Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_9.png&diff=11450File:Tesla edi 9.png2024-09-06T09:26:50Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_7.png&diff=11449File:Tesla edi 7.png2024-09-06T09:26:49Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_5.png&diff=11448File:Tesla edi 5.png2024-09-06T09:26:48Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_4.png&diff=11447File:Tesla edi 4.png2024-09-06T09:26:48Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_6.png&diff=11446File:Tesla edi 6.png2024-09-06T09:26:48Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_3.png&diff=11445File:Tesla edi 3.png2024-09-06T09:26:48Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_2.png&diff=11444File:Tesla edi 2.png2024-09-06T09:26:47Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_edi_1.png&diff=11443File:Tesla edi 1.png2024-09-06T09:26:45Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_EDI_Inbound_Guide&diff=11442Support - Tesla EDI Inbound Guide2024-09-06T09:25:26Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Template ==<br />
For each dealership an order will be created each day, this is a placeholder which will be added to by the import process. This is existing fixed schedules functionality which has not been modified for Tesla.<br />
<br />
== System parameters ==<br />
ALLOW_MULTIPLE_ADD_REFS should be set to Y for the appropriate cost center.<br />
<br />
== Dealership Decodes ==<br />
The delivery locations in the inbound files are the Tesla dealership locations not CTMS locations and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
== Du Type Decodes ==<br />
The du types in the inbound files are the Tesla du types not du types and as such must be decoded, scripts have been created and released during the normal release process to create these decodes<br />
<br />
== Inbound Files ==<br />
An example inbound file is included below<br />
<br />
== EDI Tables ==<br />
Two new tables have been created to hold the details of the Inbound files<br />
<br />
* TESLA_EDI_ORDER_HEADER<br />
* TESLA_EDI_ORDER_DETAILS<br />
<br />
Each table has an associated sequence, and the detail is linked to the header by the header ID.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== Inbound EDI ==<br />
A new EDI flow will be present for the DHLAA cost center and the Tesla customer. The import processes will be completed within the DP_TESLA_EDI package using the IMPORT_ORDERS procedure.<br />
<br />
== File Format ==<br />
The test files provide simply have numeric a file name, so the file pattern is not specified on the EDI flow. An example file is included above.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== EDI Parameters ==<br />
The following Parameters are required<br />
<br />
== EDI Report Values ==<br />
The following Report values are required<br />
<br />
<br />
<br />
== Order Processing ==<br />
An order will exist on the correct schedule for each dealership in the inbound file the delivery date can be found in the “deliveryStartDateTime” tag and the dealership in the “referenceField7” tag<br />
<br />
The correct CTMS dealership location will then be found using the decode<br />
<br />
A skeleton order will exist in CTMS which will have been created by an existing process note the schedule and delivery location agree with your inbound file, if no order is found on the schedule for the dealership an error will be raised and the order will not be processed.<br />
<br />
<br />
The product type is not contained in the inbound file so therefore must exist as a default parameter on the EDI flow. If no default is present an error will be raised and the order will not process.<br />
<br />
The Du type must also exist as an EDI parameter on the flow. An attempt will be made to decode the passed in palletSize value which contains a du type which has been mapped so in this example<br />
<br />
Maps to<br />
<br />
If no mapping is found the EDI default will be used. If no default is present an error will be raised and the order will not process.<br />
<br />
Once the correct order has been located and the product and DU type validated. The order will be updated with the details in the inbound file.<br />
<br />
If the DU type doesn’t exist on the current order a new line will be created for that DU type, the placeholder line will be removed at this point if no items exist with the same du type.<br />
<br />
Note the weight and volume on the line these are taken directly from the inbound pallet section and should not be manipulated.<br />
<br />
Order items will have been created<br />
<br />
Item contents will have been created<br />
<br />
<br />
Additional References will have been created to indicate the Consolidated order reference, MH Order references(s) and Tesla references(s)<br />
<br />
<br />
Each reference should only be stored once and the values are found as follows<br />
<br />
Consolidated Order – “aggregatedOrderNumber” tag, only 1 per order will be stored<br />
<br />
<br />
MH(Manhattan) Order ref – “OrderNumber” tag<br />
<br />
<br />
<br />
<br />
<br />
Tesla Reference – “referenceField4” of the line section<br />
<br />
== Interface Errors ==<br />
A new Tesla Orders tab page has been added to the interface errors screen which will contain the success/failure stats of each or the file imports and allow the user to reprocess any failed records after the issue has been corrected. This process will use the same package functionality as the inbound orders.<br />
<br />
== Specifications ==<br />
P:\Development\CTMS\DHL\543347 SCR - Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\613005 SCR - Changes to the Tesla Order Interface<br />
<br />
P:\Development\CTMS\DHL\632041 - Changes to Tesla order interface for Aggregated order number</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Category:DHL_Tesla&diff=11441Category:DHL Tesla2024-09-06T08:48:04Z<p>Cak: Categorisation</p>
<hr />
<div>[[Category:Documents by Client]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Category:Support_Documents&diff=11440Category:Support Documents2024-09-06T08:47:03Z<p>Cak: Categorisation</p>
<hr />
<div>[[Category:Documents by Type]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_Order_Search_Guide&diff=11439Support - Tesla Order Search Guide2024-09-06T08:44:02Z<p>Cak: Categorisation</p>
<hr />
<div><br />
== Order Search ==<br />
Two new items have been added to the Order search in both the orders and new orders screens.<br />
[[File:Tesla order search.png|800x800px]]<br />
<br />
<br />
<br />
These will allow the user to search for orders containing a Tesla or consolidated order reference. These values are stored in the SCH_ORD_REFRENCES table and can be viewed in the Additional References tab page.<br />
<br />
An order may have multiple references<br />
<br />
[[File:Tesla order search2.png|800x800px]]<br />
System parameter ALLOW_MULTIPLE_ADD_REFS will allow the user to enter multiple additional references with the same type manually if required.<br />
== ORS extracts ==<br />
The existing ORDER_ITEM ORS extract has been modified to add a new content level which will be used by Tesla full mapping details for the extract can be found in the Functional Spec located on the projects drive here - <br />
<br />
[[File:Tesla order search3.png|800x800px]]<br />
== Specification ==<br />
P:\Development\CTMS\DHL\528798 SCR-CTMS-02428249-04 - CTMS - Reports - Tracking Report - Spec<br />
[[Category:Support Documents]]<br />
[[Category:DHL Tesla]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_Order_Search_Guide&diff=11436Support - Tesla Order Search Guide2024-09-06T08:33:50Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Search ==<br />
Two new items have been added to the Order search in both the orders and new orders screens.<br />
[[File:Tesla order search.png|800x800px]]<br />
<br />
<br />
<br />
These will allow the user to search for orders containing a Tesla or consolidated order reference. These values are stored in the SCH_ORD_REFRENCES table and can be viewed in the Additional References tab page.<br />
<br />
An order may have multiple references<br />
<br />
[[File:Tesla order search2.png|800x800px]]<br />
System parameter ALLOW_MULTIPLE_ADD_REFS will allow the user to enter multiple additional references with the same type manually if required.<br />
== ORS extracts ==<br />
The existing ORDER_ITEM ORS extract has been modified to add a new content level which will be used by Tesla full mapping details for the extract can be found in the Functional Spec located on the projects drive here - <br />
<br />
[[File:Tesla order search3.png|800x800px]] <br />
<br />
P:\Development\CTMS\DHL\528798 SCR-CTMS-02428249-04 - CTMS - Reports - Tracking Report - Spec<br />
<br />
== Specification ==<br />
P:\Development\CTMS\DHL\528798 SCR-CTMS-02428249-04 - CTMS - Reports - Tracking Report - Spec</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_order_search3.png&diff=11435File:Tesla order search3.png2024-09-06T08:28:55Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_order_search2.png&diff=11434File:Tesla order search2.png2024-09-06T08:28:39Z<p>Cak: Uploaded with SimpleBatchUpload</p>
<hr />
<div></div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=Support_-_Tesla_Order_Search_Guide&diff=11433Support - Tesla Order Search Guide2024-09-06T08:23:30Z<p>Cak: Initial creation</p>
<hr />
<div><br />
== Order Search ==<br />
Two new items have been added to the Order search in both the orders and new orders screens.<br />
[[File:Tesla order search.png|800x800px]]<br />
<br />
<br />
These will allow the user to search for orders containing a Tesla or consolidated order reference. These values are stored in the SCH_ORD_REFRENCES table and can be viewd in the Additional References tab page.<br />
<br />
An order may have multiple references<br />
<br />
<br />
System parameter ALLOW_MULTIPLE_ADD_REFS will allow the user to enter multiple additional references with the same type manually if required.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
== ORS extracts ==<br />
The existing ORDER_ITEM ORS extract has been modified to add a new content level which will be used by Tesla full mapping details for the extract can be found in the Functional Spec located on the projects drive here - <br />
<br />
P:\Development\CTMS\DHL\528798 SCR-CTMS-02428249-04 - CTMS - Reports - Tracking Report - Spec<br />
<br />
== Specification ==<br />
P:\Development\CTMS\DHL\528798 SCR-CTMS-02428249-04 - CTMS - Reports - Tracking Report - Spec</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=File:Tesla_order_search.png&diff=11432File:Tesla order search.png2024-09-06T08:21:28Z<p>Cak: </p>
<hr />
<div>tesla order search</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_311856_Multiple_Serviceable_Items&diff=1287FS 311856 Multiple Serviceable Items2013-10-23T07:51:53Z<p>Cak: /* Database/DAL */</p>
<hr />
<div><div class="noprint"><br />
{{#vardefine:Client|LANE}}<br />
{{#vardefine:ClientName|Lanemark}}<br />
{{#vardefine:System|''CALIDUS'' eSERV}}<br />
{{#vardefine:Doc_Title|Multiple Serviceable Items}}<br />
{{#vardefine:Version|0.2}}<br />
{{#vardefine:Date|19th September 2013}}<br />
{{#vardefine:Reference|311856 309371-2}}<br />
{{#vardefine:Year|2013}}<br />
</div><br />
{{Doc_Title<br />
|Client={{#var:ClientName}}<br />
|System={{#var:System}}<br />
|Title={{#var:Doc_Title}}<br />
|Reference=FS {{#var:Reference}}<br />
|Version={{#var:Version}}<br />
|Date={{#var:Date}}<br />
|Year={{#var:Year}}<br />
}} <br />
<br />
<!-- TOC --> <br />
<div class="noprint"><br />
= Functional Overview =<br />
== Client Requirement ==<br />
* Multiple engineers assigned to one service job. <br />
* One job with multiple service items.<br />
<br />
== Solution Overview ==<br />
NAV can have multiple serviceable items on a single Job, allocated to multiple engineers. <br />
<br />
Where multiple engineers are required on a job, for example:<br />
* 3 engineers on site<br />
* 20 gas burners to service <br />
Each engineer will complete the service of several of the burners (the serviceable items) against the service.<br />
<br />
In practice, the lead engineer will assign the burners to each engineer on the job, rather than pre-assign.<br />
<br />
This will be completed through a link to NAV direct from a mobile unit (i.e. a PC). <br />
<br />
<br />
On the PDA Info tab, if there are multiple serviceable items on the job, the screen also would have navigation buttons left and right of the title (sections 1 and 2), to allow the user to switch between serviceable items. <br />
<br />
A label showing the record being processed (e.g. "1 of 6") would be shown, allowing the user to see how many there are. <br />
<br />
The Service Item number (LS Number) of the serviceable item will be displayed on the top of the Info tab, whereas the Service ID (SJ Number) will be displayed on the Job Details tab.<br />
<br />
Switching between the serviceable items will change the displayed data on each of the tabs to the next service record - the same affect can be made by swiping left or right on the title label. <br />
<br />
== Scope ==<br />
* These changes will be made in the latest version of the {{#var:System}} product only.<br />
* The changes will be made to the Android eSERV client only. Note that this change drives change into the Server processes that deal with PDA updates that would mean that the existing Windows Mobile and previous versions of the Android client may be incompatible with this version of the server.<br />
* {{Note}} The modifications seen here require NAV functionality to split a service job among several engineers, specifically assigning items to each engineer to complete. Any failure to deliver the required functionality will cause the processes described here to fail.<br />
* {{Note}} The changes in SCR 312116 specify some details that will be useful in the completion of this code. This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
<!-- NEW PAGE --> <br />
<br />
= Set-up =<br />
<br />
== Pre-requisites ==<br />
<br />
== Menu Structure ==<br />
<br />
== Data ==<br />
<br />
<!-- NEW PAGE --> <br />
= Functional Description =<br />
== Database/DAL ==<br />
The database table EPOD_SERVICE must have the indexes changed to reflect the new model, as follows:<br />
* The primary key (PK_EPOD_SERVICE_1) should be modified as follows:<br />
** EPL_SITE_ID, ascending<br />
** EPL_JOB_ID, ascending<br />
** EPL_SERVICE_ID, ascending<br />
* The secondary unique index (IX_EPOD_SERVICE) should stay - Service IDs should remain unique under Site.<br />
{{Note}} All database packages must be checked to ensure they reflect this change to the data model.<br />
<br />
The DAL object EPOD_JOB will be modified to have an EPOD_SERVICES collection added beneath it, consisting of all the EPOD_SERVICE records found against the EPOD_JOB. This will be completed when creating an EPOD_JOB DAL object for an EPOD_JOB record that already exists. If the EPOD_JOB DAL object created does not exist, an empty collection should be created.<br />
<br />
{{Note}} The XML Export of jobs and Services already allows EPOD_SERVICE to iterate within a tag of EPOD_SERVICES, as follows:<br />
<EPOD_JOB><br />
...<br />
<EPOD_SERVICES><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
</EPOD_SERVICES><br />
</EPOD_JOB><br />
This supports multiple EPOD_SERVICE records, but the EPOD_SERVICES tag must be changed to reflect multiple records, with a maxOccurs property of "unbounded" replacing "1". All XSDs must be modified to reflect this, including but not limited to:<br />
* EPOD_EXPORT_JOB_RESPONSE.xsd<br />
* EPOD_EXPORT_JOB.xsd<br />
* EPOD_EXPORT_LOAD_RESPONSE.xsd<br />
* EPOD_EXPORT_LOAD.xsd<br />
<br />
The XML Import process (through the web services ePOD_DataService.asmx and ePOD_DataService2.asmx) must be modified to allow the same functionality when receiving Service Jobs, i.e.:<br />
* Allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
Therefore the following changes must be made:<br />
* XMLUpload.xsd must be modified to allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
* EPOD_DATASERVICE.ProcessJobs must change to check for this EPOD_SERVICES tag - if it exists, each EPOD_SERVICE tag found inside should be passed to the ProcessService function - see the existing xePRODUCTS code above the EPOD_SERVICE code for an example of how this is achieved.<br />
* Any EPOD_SERVICE objects that have not been found on the XML update should be removed from the EPOD_JOB (i.e. deleted) unless they have already been cancelled.<br />
* Any EPOD_SERVICE tag that does not exist should be created.<br />
* The XMLUpload XSD should also be changed to include an optional EPL_USER_ID tag within the EPOD_JOB section. When an import is received if no load information is provided and the new EPL_USER_ID tag has been populated a check should be made against the Site to ascertain the value of the EPL_AUTO_GEN_LOAD flag, if this value is set a check should be performed to see if there is currently a load assigned to the user at Pending or In progress status, if found the jobs should be allocated to this load. If no load details are found a load should be created using the user id and the current date as the Load id and the jobs assigned to this load.<br />
<br />
== Server ==<br />
Changes will be made to the JOB_UPDATE message returned from the PDA, as follows:<br />
* Remove EPL_SITE_ID and EPL_SERVICE_ID from the ACTIVITY tag.<br />
* Add EPL_SERVICE_ID and EPL_SERVICE_TYPE to the top of the SERVICE tag.<br />
{{Note}} For the format of the XML update message, see the [[#Android Client|Android Client]] section of this document<br />
<br />
In order to match these changes, the function MessageProcess.ProcessJobUpdate must change as follows:<br />
* For each SERVICE tag found in SERVICES, create an EPOD_SERVICE object. Update this object with the details passed in the SERVICE tag from the PDA. This is similar processing to how the EPOD_SERVICE_PRODUCT and EPOD_SERVICE_ACTIVITY updates work in the same process.<br />
{{Note}} The change to EPOD_SERVICE_ACTIVITY (where two elements have been removed) need not be reflected, as these elements are never used.<br />
<br />
<br />
== Admin ==<br />
The Job and Service Screens will require modification when creating a new job. Those screens affected are:<br />
* ConfigurableJob.aspx<br />
* job_details.aspx<br />
When creating or editing a new Service job, a pop-up screen is displayed. The Service section (lower left) will be modified as follows:<br />
* When editing, all Service records will be loaded upon showing the pop-up form. When adding, only one will be assumed.<br />
* A navigation group will be added to this section, disabled initially, enabled if there are multiple service records for the job.<br />
* An '''Add''' button will be added to this section - each time this is pressed, a new service record will be allowed to be created in this section, by adding a navigable item to the navigation group and moving to this item.<br />
* A '''Delete''' button will be added to this section - when pressed, this will mark the associated service record as requiring deletion when the page is saved. It will still show on the screen (but will have all fields disabled) until the page is saved.<br />
* When a new item is created, the Service ID should be defaulted to EPL_JOB_CODE + "_" + count.<br />
* Moving between service items on the navigation group should show the details of the salient service record.<br />
* Saving will save all changed service records. Note that Service ID can be modified, and therefore care should be taken in updating each record. This should utilise the Service details on the page in the same sequence as the EPOD_SERVICE records in the EPOD_SERVICES collection in the DAL object. Therefore, even if the Service ID changes, this should update the correct EPOD_SERVICE record with these details.<br />
<br />
{{Note}} Time should be taken at this point to re-organise the layout of this pop-up - for example, Dates and Times associated to each other should be concatenated onto the same line:<br />
* Planned Date/Time<br />
* Actual Date/Time<br />
* Order Date/Time<br />
* Expiry Date/Time<br />
* Arrival Date/Time<br />
Additionally, the Service section should be labelled as such and only appear if the job is a Service type.<br />
<br />
{{Note}} The Service screen (service_job.aspx) utilises EPOD_SERVICE_JOB, a different DAL mechanism that allows only 1 service record per job. Although it should be possible to maintain and create Service jobs (with all the required fields) on this screen, it is not necessary to change this to allow creation of multiple service items on a single job. The screen itself ''should'' allow the searching for and displaying of each item, however. <br />
<br />
<br />
The Service Details screen (service_detail.aspx) will be modified as follows: <br />
* When retrieving the EPOD_JOB, modifications will need to be made throughout the code to accommodate the fact that the EPOD_SERVICE objects exist only within an EPOD_SERVICES collection and not directly from EPOD_JOB, even if there is only one EPOD_SERVICE record.<br />
* The "Service Details" section should be renamed "Job Details", and the items Service ID and Service Type removed from this section.<br />
* All further sections (Information, Pre-Work, Post-Work, Diagnosis, MC Refs and Products) should be included within another Section, labelled with the items Service ID and Service Type, in a larger, bolder font. <br />
* The Service Details section should be created for each EPOD_SERVICE under the EPOD_SERVICES collection under EPOD_JOB, printed one under each other - the browser scroll-bar can be used to see all the details.<br />
<br />
[[File:FS_311856_1.PNG|border|600px]]<br />
<br />New Job Details screen<br />
<br />
{{Note}} This sample also shows fields defined under SCR 312116 (status and reason code, and the '''Image''' button). This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
{{Note}} In the current screen, the Diagnosis and Products sections seem to be less wide than the Information section - this should be corrected on all affected sections.<br />
<br />
<br />
== Android Client ==<br />
The PDA_SERVICE DAL object will change to:<br />
* Add parameter Service ID on creation of a PDA_SERVICE object. <br />
** If one is provided, this should create a PDA_SERVICE object, retrieve the EPOD_SERVICE record and return the object.<br />
** If one is not provided, this should fetch all EPOD_SERVICE records for the job, create a PDASERVICES array and, for each record found, create a new PDA_SERVICE object (as PDASERVICE) and pass the Site, Job and Service ID parameters to the new object. Once all are created, return the PDASERVICES collection.<br />
* The existing function ProcessServiceUpdate (called when Job Lock Response is processed, on pressing the Start/Arrive/Continue button in Job Details) must change to iterate through a collection of Service records, and update each one separately, by creating a PDA_SERVICE object passing Site, Job ID and Service ID.<br />
<br />
All functions that create PDA_SERVICE objects must now be checked that they pass a Service ID correctly, or they are expecting a PDASERVICES collection returned.<br />
<br />
The PDA_JOB DAL object will change to:<br />
* hold a collection of PDA_SERVICE record (named PDASERVICES), rather than a single PDA_SERVICE object (PDASERVICE), as it does now.<br />
* On creation of a new Job, create a collection PDASERVICES from a new PDA_SERVICE object - this will return a collection from the instantiation.<br />
<br />
{{Note}} No further changes should be necessary on the importing of services - the existing InsertAllPDAServices (called by Job creation functions ) already iterates through a number of EPOD_SERVICE records within the passed XML tag EPOD_SERVICES and adds each record. As these functions delete all service records first before adding new records, no updating functionality should be required.<br />
<br />
<br />
The method PDA_JOB.ToUpdateXElement will be modified to create a SERVICES tag rather than a SERVICE tag, if there is more than one Service record in the PDASERVICES collection. Each element in the Services collection will then be iterated through, calling PDASERVICE.ToUpdateXElement().<br />
<br />
The method PDA_SERVICE.ToUpdateXElement will be modified to add EPL_SERVICE_ID and EPL_SERVICE_TYPE tags before any others.<br />
<br />
The method PDA_SERVICE_ACTIVITY.ToUpdateXElement will be modified to remove EPL_SITE_ID and EPL_SERVICE_ID.<br />
<br />
The resulting XML extraction for a job should then look as follows:<br />
<EPOD_JOB><br />
...<br />
<SERVICES><br />
<SERVICE><br />
<EPL_SERVICE_ID></EPL_SERVICE_ID><br />
<EPL_SERVICE_TYPE></EPL_SERVICE_TYPE><br />
<PREWORK><br />
<EPL_PREWORK_INTERIOR></EPL_PREWORK_INTERIOR><br />
<EPL_PREWORK_EXTERIOR></EPL_PREWORK_EXTERIOR><br />
<EPL_PREWORK_ELECTRIC></EPL_PREWORK_ELECTRIC><br />
<EPL_UDF_PREWORK></EPL_UDF_PREWORK><br />
</PREWORK><br />
<POSTWORK><br />
<EPL_POSTWORK_INTERIOR></EPL_POSTWORK_INTERIOR><br />
<EPL_POSTWORK_EXTERIOR></EPL_POSTWORK_EXTERIOR><br />
<EPL_POSTWORK_ELECTRIC></EPL_POSTWORK_ELECTRIC><br />
<EPL_UDF_POSTWORK></EPL_UDF_POSTWORK><br />
</POSTWORK><br />
<INFO><br />
<EPL_UNIT_TYPE></EPL_UNIT_TYPE><br />
<EPL_CODE_2></EPL_CODE_2><br />
<EPL_CODE_1></EPL_CODE_1><br />
<EPL_MILEAGE></EPL_MILEAGE><br />
<EPL_CODE_3></EPL_CODE_3><br />
<EPL_SPEC_REQUIRED></EPL_SPEC_REQUIRED><br />
<EPL_SERVICE_GROUP></EPL_SERVICE_GROUP><br />
<EPL_SYSTEM_TYPE></EPL_SYSTEM_TYPE><br />
<EPL_UDF_INFO></EPL_UDF_INFO><br />
</INFO><br />
<MC_REF><br />
<EPL_MC_REF_1></EPL_MC_REF_1><br />
<EPL_MC_REF_2></EPL_MC_REF_2><br />
<EPL_MC_REF_3><EPL_MC_REF_3><br />
<EPL_MC_REF_4></EPL_MC_REF_4><br />
<EPL_MC_REF_NARRATIVE></EPL_MC_REF_NARRATIVE><br />
</MC_REF><br />
<DIAGNOSIS><br />
<EPL_DIAGNOSIS_NARRATIVE></EPL_DIAGNOSIS_NARRATIVE><br />
<EPL_CUSTOMER_DAMAGE></EPL_CUSTOMER_DAMAGE><br />
<EPL_VNOS></EPL_VNOS><br />
<EPL_CHECKBOX_1></EPL_CHECKBOX_1><br />
<EPL_CHECKBOX_2></EPL_CHECKBOX_2><br />
<EPL_CHECKBOX_3></EPL_CHECKBOX_3><br />
<EPL_UDF_DIAGNOSIS></EPL_UDF_DIAGNOSIS><br />
</DIAGNOSIS><br />
<PRODUCT><br />
<EPL_PRODUCT_ID></EPL_PRODUCT_ID><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
<EPL_DIRECTION></EPL_DIRECTION><br />
<EPL_RETURN></EPL_RETURN><br />
<EPL_DESCRIPTION></EPL_DESCRIPTION><br />
<EPL_VEHICLE_ID></EPL_VEHICLE_ID><br />
</PRODUCT><br />
<ACTIVITY><br />
<EPL_ACTIVITY_CODE></EPL_ACTIVITY_CODE><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
</ACTIVITY><br />
</SERVICE><br />
</SERVICES><br />
</EPOD_JOB><br />
{{Note}} This includes the changes made under references 311577, 311636, 311753 and 311801. <br />
<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Job Details tab will be changed slightly, as follows:<br />
* The main label showing "Service:" will be modified to show the Job Code of the Job here (EPOD_JOB.EPL_JOB_CODE) rather than the Service ID of the Service record (EPOD_SERVICE.EPL_SERVICE_ID).<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Info tab will be changed slightly, as follows:<br />
* 2 buttons will be added to the left and right of the main label, labelled as "<" and ">". These will be '''Previous''' and '''Next''' buttons.<br />
* A new label will be added to the title, under the "Service:" label, in a very small font, showing "Item X of Y", where X is current Service record in the Services collection (vars.lngServiceRecord - see below) and Y is the total number of records in the Services collection (PDAJOB.PDASERVICES.length).<br />
<br />
<gallery widths=310px heights=400px perrow=3><br />
File:REQ_309187_2.PNG|Info tab, showing the position of the new previous/next buttons (1 and 2)<br />
</gallery><br /><br />
<br />
If the user clicks on the '''Next''' button, the next service item will be displayed on each of the Service tabs. If there is no next Service record, the first will be displayed instead. The '''Previous''' button will work in the same way, showing the previous Service record, or the last. A "swipe" event will also be added to the "Service:" label, to perform the same function.<br />
<br />
In order to do this, a function must be written to update each of the tabs with the information from a particular service record. So:<br />
* The screen will be changed to hold a current Service record number (vars.lngServiceRecord) that will be set on creating the screen.<br />
* Any labels that need to be updated with data from the Service record on any of the tabs should be assigned variable items in the vars object, rather that just being added directly to any parent view - this is so that the text value can be updated.<br />
* Any changes to the previous Service will be saved.<br />
* The current Service record (lngServiceRecord) will be changed to the appropriate next Service record, depending on which button was pressed, and where in the Services collection the screen currently is.<br />
* The new function will update:<br />
** Each label, button, picker, text and check variable item in the screen with the appropriate value from the current Service record (for example, PDAJOB.PDASERVICES[vars.lngServiceRecord].PDASERVICE.EPL_SERVICE_ID).<br />
* This new function will be called at start-up (through an "open" event added to the TabGroup object) - all assignations of value and text properties derived from Service data will be removed from each variable declaration, to ensure that only one part of the code sets these values, to make code support easier.<br />
<br />
The validateJob function will be modified to check that all PDA_SERVICE items have had all details entered against them. This should be completed by checking the validation of all the service items when pressing the '''Done''' button. The validation messages displayed should identify the Service Item with the issues. {{Note}} New field EPL_STATUS of EPOD_SERVICE (specified in SCR 312116, referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]]) may be used to check and store the status if required. In this way, validating a service need be done only once. Also, only non-cancelled Service records need be checked.<br />
<br />
If this is not the case, a validation message should be displayed - clearing this message will return the user to the Services process.<br />
<br />
<br />
<!-- MEDIA LANDSCAPE YES --> <br />
= Appendix A: TEST PLAN =<br />
{{TestPlan_Header<br />
|Title={{#var:Doc_Title}}<br />
|Log={{#var:Reference}}<br />
|Description=To test that multiple Serviceable Items are supported by {{#var:System}}<br />
|MenuAccess=Services<br />
|Prerequisites=As much as possible (as far as has been developed on other Lanemark changes to the point of testing this one), the Services created and configuration allowed should match closely to the Lanemark requirements.<br />
|Objective=To test (for single and multiple serviceable items) that: Import adds and amends Service data correctly; Admin screens add, find and amend Service data correctly; the PDA allows navigation and updating of serviceable items and; the system exports Service data correctly.<br />
}}<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Import<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with one service record.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the single-service job again, but with an additional service item.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the multiple-service job again, but with one of the original service items removed.<br />
|Result=The job should be saved, with all service records associated to the Job ID. The removed Service item should be deleted.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Admin<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with a single service.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Find these service records again.<br />
|Result=All should appear once only on the grid.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a single-service job and add another service<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a multiple-service job, and delete a service<br />
|Result=The job should be saved, with all service records associated to the Job ID, except the deleted one.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Repeat the above tests on the Configurable Job screen<br />
|Result=As expected<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Services screen, find all services.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a specific Serviceable Item<br />
|Result=The service should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a serviceable item (Service ID) that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Enter a partial Serial Number that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=PDA<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a single-service job on the device and complete.<br />
|Result=This should operate as before, to the limit of already-coded changes for Lanemark at the point of testing.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a multiple-service job on the device (at least 3 serviceable items).<br />
|Result=The Job Details screen will show the Job Code as the Service ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Change to the Info screen.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete details of the first serviceable item. Press Done.<br />
|Result=A validation error should be displayed, showing that not all details have been entered against all Serviceable Items.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Move to the Info tab and press Next.<br />
|Result=The details of the second serviceable item are displayed; Previous and Next buttons are present; a sub-title of "2 of 3" is displayed. No other details have been entered against this item.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the details of all remaining items (markedly different on all items), finishing on the third. <br />
|Result=The details of the third serviceable item are displayed; Previous and Next buttons are present; a sub-title of "3 of 3" is displayed. All details entered against the third item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Press Next.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed. All details entered against the first item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action= Press Done<br />
|Result=The service should complete (move to signature).<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the service job<br />
|Result=The results of all services should be returned to the system.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Post-PDA (Admin/Server)<br />
|Notes=Ensure that single- and multiple-item jobs have been completed.<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check all items on all jobs updated.<br />
|Result=All records are updated correctly<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a Single-item Service Job <br />
|Result=The screen has changed layout correctly - only one service item's details are displayed<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a multiple-item Service Job <br />
|Result=The screen has changed layout correctly - all service item's details are displayed on a scrolling screen.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Export<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a single-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a multiple-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
<!-- MEDIA LANDSCAPE NO --> <br />
{{Doc_Appendix<br />
|Appendix=B<br />
|Estimate=Y<br />
|Glossary=EPOD<br />
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]<br />
|RefV1=2.0<br />
|RefDate1=4/4/2012<br />
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]<br />
|RefV2=3.0<br />
|RefDate2=23/4/2013<br />
|Ref3=[[REQ_309371_Lanemark_eSERV_Requirements]]<br />
|RefV3=0.4<br />
|RefDate3=29/08/2013<br />
|Ref4=[[FS_312116_Service_Cancellation_Changes]]<br />
|RefV4=0.1<br />
|RefDate4=19/09/2013<br />
|REQ=0<br />
|EST=0<br />
|FS=1.25<br />
|TS=0.0<br />
|DEV=10.5<br />
|ST=2.0<br />
|IMP=0<br />
|FOC=Y<br />
|Client={{#var:Client}}<br />
|Year={{#var:Year}}<br />
|FSEST=N<br />
|Rev1=Julie Taylor<br />
|Rev1Title=OBS Project Manager<br />
|Rev2=Jeff Foster<br />
|Rev2Title=Client Representative<br />
|Rev3=Alan Thompson<br />
|Rev3Title=Client Representative<br />
}}</div> <br />
[[Category:{{#var:Client}} FS]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_311856_Multiple_Serviceable_Items&diff=1286FS 311856 Multiple Serviceable Items2013-10-23T07:50:30Z<p>Cak: /* Database/DAL */</p>
<hr />
<div><div class="noprint"><br />
{{#vardefine:Client|LANE}}<br />
{{#vardefine:ClientName|Lanemark}}<br />
{{#vardefine:System|''CALIDUS'' eSERV}}<br />
{{#vardefine:Doc_Title|Multiple Serviceable Items}}<br />
{{#vardefine:Version|0.2}}<br />
{{#vardefine:Date|19th September 2013}}<br />
{{#vardefine:Reference|311856 309371-2}}<br />
{{#vardefine:Year|2013}}<br />
</div><br />
{{Doc_Title<br />
|Client={{#var:ClientName}}<br />
|System={{#var:System}}<br />
|Title={{#var:Doc_Title}}<br />
|Reference=FS {{#var:Reference}}<br />
|Version={{#var:Version}}<br />
|Date={{#var:Date}}<br />
|Year={{#var:Year}}<br />
}} <br />
<br />
<!-- TOC --> <br />
<div class="noprint"><br />
= Functional Overview =<br />
== Client Requirement ==<br />
* Multiple engineers assigned to one service job. <br />
* One job with multiple service items.<br />
<br />
== Solution Overview ==<br />
NAV can have multiple serviceable items on a single Job, allocated to multiple engineers. <br />
<br />
Where multiple engineers are required on a job, for example:<br />
* 3 engineers on site<br />
* 20 gas burners to service <br />
Each engineer will complete the service of several of the burners (the serviceable items) against the service.<br />
<br />
In practice, the lead engineer will assign the burners to each engineer on the job, rather than pre-assign.<br />
<br />
This will be completed through a link to NAV direct from a mobile unit (i.e. a PC). <br />
<br />
<br />
On the PDA Info tab, if there are multiple serviceable items on the job, the screen also would have navigation buttons left and right of the title (sections 1 and 2), to allow the user to switch between serviceable items. <br />
<br />
A label showing the record being processed (e.g. "1 of 6") would be shown, allowing the user to see how many there are. <br />
<br />
The Service Item number (LS Number) of the serviceable item will be displayed on the top of the Info tab, whereas the Service ID (SJ Number) will be displayed on the Job Details tab.<br />
<br />
Switching between the serviceable items will change the displayed data on each of the tabs to the next service record - the same affect can be made by swiping left or right on the title label. <br />
<br />
== Scope ==<br />
* These changes will be made in the latest version of the {{#var:System}} product only.<br />
* The changes will be made to the Android eSERV client only. Note that this change drives change into the Server processes that deal with PDA updates that would mean that the existing Windows Mobile and previous versions of the Android client may be incompatible with this version of the server.<br />
* {{Note}} The modifications seen here require NAV functionality to split a service job among several engineers, specifically assigning items to each engineer to complete. Any failure to deliver the required functionality will cause the processes described here to fail.<br />
* {{Note}} The changes in SCR 312116 specify some details that will be useful in the completion of this code. This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
<!-- NEW PAGE --> <br />
<br />
= Set-up =<br />
<br />
== Pre-requisites ==<br />
<br />
== Menu Structure ==<br />
<br />
== Data ==<br />
<br />
<!-- NEW PAGE --> <br />
= Functional Description =<br />
== Database/DAL ==<br />
The database table EPOD_SERVICE must have the indexes changed to reflect the new model, as follows:<br />
* The primary key (PK_EPOD_SERVICE_1) should be modified as follows:<br />
** EPL_SITE_ID, ascending<br />
** EPL_JOB_ID, ascending<br />
** EPL_SERVICE_ID, ascending<br />
* The secondary unique index (IX_EPOD_SERVICE) should stay - Service IDs should remain unique under Site.<br />
{{Note}} All database packages must be checked to ensure they reflect this change to the data model.<br />
<br />
The DAL object EPOD_JOB will be modified to have an EPOD_SERVICES collection added beneath it, consisting of all the EPOD_SERVICE records found against the EPOD_JOB. This will be completed when creating an EPOD_JOB DAL object for an EPOD_JOB record that already exists. If the EPOD_JOB DAL object created does not exist, an empty collection should be created.<br />
<br />
{{Note}} The XML Export of jobs and Services already allows EPOD_SERVICE to iterate within a tag of EPOD_SERVICES, as follows:<br />
<EPOD_JOB><br />
...<br />
<EPOD_SERVICES><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
</EPOD_SERVICES><br />
</EPOD_JOB><br />
This supports multiple EPOD_SERVICE records, but the EPOD_SERVICES tag must be changed to reflect multiple records, with a maxOccurs property of "unbounded" replacing "1". All XSDs must be modified to reflect this, including but not limited to:<br />
* EPOD_EXPORT_JOB_RESPONSE.xsd<br />
* EPOD_EXPORT_JOB.xsd<br />
* EPOD_EXPORT_LOAD_RESPONSE.xsd<br />
* EPOD_EXPORT_LOAD.xsd<br />
<br />
The XML Import process (through the web services ePOD_DataService.asmx and ePOD_DataService2.asmx) must be modified to allow the same functionality when receiving Service Jobs, i.e.:<br />
* Allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
Therefore the following changes must be made:<br />
* XMLUpload.xsd must be modified to allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
* EPOD_DATASERVICE.ProcessJobs must change to check for this EPOD_SERVICES tag - if it exists, each EPOD_SERVICE tag found inside should be passed to the ProcessService function - see the existing xePRODUCTS code above the EPOD_SERVICE code for an example of how this is achieved.<br />
* Any EPOD_SERVICE objects that have not been found on the XML update should be removed from the EPOD_JOB (i.e. deleted) unless they have already been cancelled ({{Note}} This functionality will be specified under a different change).<br />
* Any EPOD_SERVICE tag that does not exist should be created.<br />
* The XMLUpload XSD should also be changed to include an optional EPL_USER_ID tag within the EPOD_JOB section. When an import is received if no load information is provided and the new EPL_USER_ID tag has been populated a check should be made against the Site to ascertain the value of the EPL_AUTO_GEN_LOAD flag, if this value is set a check should be performed to see if there is currently a load assigned to the user at Pending or In progress status, if found the jobs should be allocated to this load. If no load details are found a load should be created using the user id and the current date as the Load id and the jobs assigned to this load.<br />
<br />
== Server ==<br />
Changes will be made to the JOB_UPDATE message returned from the PDA, as follows:<br />
* Remove EPL_SITE_ID and EPL_SERVICE_ID from the ACTIVITY tag.<br />
* Add EPL_SERVICE_ID and EPL_SERVICE_TYPE to the top of the SERVICE tag.<br />
{{Note}} For the format of the XML update message, see the [[#Android Client|Android Client]] section of this document<br />
<br />
In order to match these changes, the function MessageProcess.ProcessJobUpdate must change as follows:<br />
* For each SERVICE tag found in SERVICES, create an EPOD_SERVICE object. Update this object with the details passed in the SERVICE tag from the PDA. This is similar processing to how the EPOD_SERVICE_PRODUCT and EPOD_SERVICE_ACTIVITY updates work in the same process.<br />
{{Note}} The change to EPOD_SERVICE_ACTIVITY (where two elements have been removed) need not be reflected, as these elements are never used.<br />
<br />
<br />
== Admin ==<br />
The Job and Service Screens will require modification when creating a new job. Those screens affected are:<br />
* ConfigurableJob.aspx<br />
* job_details.aspx<br />
When creating or editing a new Service job, a pop-up screen is displayed. The Service section (lower left) will be modified as follows:<br />
* When editing, all Service records will be loaded upon showing the pop-up form. When adding, only one will be assumed.<br />
* A navigation group will be added to this section, disabled initially, enabled if there are multiple service records for the job.<br />
* An '''Add''' button will be added to this section - each time this is pressed, a new service record will be allowed to be created in this section, by adding a navigable item to the navigation group and moving to this item.<br />
* A '''Delete''' button will be added to this section - when pressed, this will mark the associated service record as requiring deletion when the page is saved. It will still show on the screen (but will have all fields disabled) until the page is saved.<br />
* When a new item is created, the Service ID should be defaulted to EPL_JOB_CODE + "_" + count.<br />
* Moving between service items on the navigation group should show the details of the salient service record.<br />
* Saving will save all changed service records. Note that Service ID can be modified, and therefore care should be taken in updating each record. This should utilise the Service details on the page in the same sequence as the EPOD_SERVICE records in the EPOD_SERVICES collection in the DAL object. Therefore, even if the Service ID changes, this should update the correct EPOD_SERVICE record with these details.<br />
<br />
{{Note}} Time should be taken at this point to re-organise the layout of this pop-up - for example, Dates and Times associated to each other should be concatenated onto the same line:<br />
* Planned Date/Time<br />
* Actual Date/Time<br />
* Order Date/Time<br />
* Expiry Date/Time<br />
* Arrival Date/Time<br />
Additionally, the Service section should be labelled as such and only appear if the job is a Service type.<br />
<br />
{{Note}} The Service screen (service_job.aspx) utilises EPOD_SERVICE_JOB, a different DAL mechanism that allows only 1 service record per job. Although it should be possible to maintain and create Service jobs (with all the required fields) on this screen, it is not necessary to change this to allow creation of multiple service items on a single job. The screen itself ''should'' allow the searching for and displaying of each item, however. <br />
<br />
<br />
The Service Details screen (service_detail.aspx) will be modified as follows: <br />
* When retrieving the EPOD_JOB, modifications will need to be made throughout the code to accommodate the fact that the EPOD_SERVICE objects exist only within an EPOD_SERVICES collection and not directly from EPOD_JOB, even if there is only one EPOD_SERVICE record.<br />
* The "Service Details" section should be renamed "Job Details", and the items Service ID and Service Type removed from this section.<br />
* All further sections (Information, Pre-Work, Post-Work, Diagnosis, MC Refs and Products) should be included within another Section, labelled with the items Service ID and Service Type, in a larger, bolder font. <br />
* The Service Details section should be created for each EPOD_SERVICE under the EPOD_SERVICES collection under EPOD_JOB, printed one under each other - the browser scroll-bar can be used to see all the details.<br />
<br />
[[File:FS_311856_1.PNG|border|600px]]<br />
<br />New Job Details screen<br />
<br />
{{Note}} This sample also shows fields defined under SCR 312116 (status and reason code, and the '''Image''' button). This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
{{Note}} In the current screen, the Diagnosis and Products sections seem to be less wide than the Information section - this should be corrected on all affected sections.<br />
<br />
<br />
== Android Client ==<br />
The PDA_SERVICE DAL object will change to:<br />
* Add parameter Service ID on creation of a PDA_SERVICE object. <br />
** If one is provided, this should create a PDA_SERVICE object, retrieve the EPOD_SERVICE record and return the object.<br />
** If one is not provided, this should fetch all EPOD_SERVICE records for the job, create a PDASERVICES array and, for each record found, create a new PDA_SERVICE object (as PDASERVICE) and pass the Site, Job and Service ID parameters to the new object. Once all are created, return the PDASERVICES collection.<br />
* The existing function ProcessServiceUpdate (called when Job Lock Response is processed, on pressing the Start/Arrive/Continue button in Job Details) must change to iterate through a collection of Service records, and update each one separately, by creating a PDA_SERVICE object passing Site, Job ID and Service ID.<br />
<br />
All functions that create PDA_SERVICE objects must now be checked that they pass a Service ID correctly, or they are expecting a PDASERVICES collection returned.<br />
<br />
The PDA_JOB DAL object will change to:<br />
* hold a collection of PDA_SERVICE record (named PDASERVICES), rather than a single PDA_SERVICE object (PDASERVICE), as it does now.<br />
* On creation of a new Job, create a collection PDASERVICES from a new PDA_SERVICE object - this will return a collection from the instantiation.<br />
<br />
{{Note}} No further changes should be necessary on the importing of services - the existing InsertAllPDAServices (called by Job creation functions ) already iterates through a number of EPOD_SERVICE records within the passed XML tag EPOD_SERVICES and adds each record. As these functions delete all service records first before adding new records, no updating functionality should be required.<br />
<br />
<br />
The method PDA_JOB.ToUpdateXElement will be modified to create a SERVICES tag rather than a SERVICE tag, if there is more than one Service record in the PDASERVICES collection. Each element in the Services collection will then be iterated through, calling PDASERVICE.ToUpdateXElement().<br />
<br />
The method PDA_SERVICE.ToUpdateXElement will be modified to add EPL_SERVICE_ID and EPL_SERVICE_TYPE tags before any others.<br />
<br />
The method PDA_SERVICE_ACTIVITY.ToUpdateXElement will be modified to remove EPL_SITE_ID and EPL_SERVICE_ID.<br />
<br />
The resulting XML extraction for a job should then look as follows:<br />
<EPOD_JOB><br />
...<br />
<SERVICES><br />
<SERVICE><br />
<EPL_SERVICE_ID></EPL_SERVICE_ID><br />
<EPL_SERVICE_TYPE></EPL_SERVICE_TYPE><br />
<PREWORK><br />
<EPL_PREWORK_INTERIOR></EPL_PREWORK_INTERIOR><br />
<EPL_PREWORK_EXTERIOR></EPL_PREWORK_EXTERIOR><br />
<EPL_PREWORK_ELECTRIC></EPL_PREWORK_ELECTRIC><br />
<EPL_UDF_PREWORK></EPL_UDF_PREWORK><br />
</PREWORK><br />
<POSTWORK><br />
<EPL_POSTWORK_INTERIOR></EPL_POSTWORK_INTERIOR><br />
<EPL_POSTWORK_EXTERIOR></EPL_POSTWORK_EXTERIOR><br />
<EPL_POSTWORK_ELECTRIC></EPL_POSTWORK_ELECTRIC><br />
<EPL_UDF_POSTWORK></EPL_UDF_POSTWORK><br />
</POSTWORK><br />
<INFO><br />
<EPL_UNIT_TYPE></EPL_UNIT_TYPE><br />
<EPL_CODE_2></EPL_CODE_2><br />
<EPL_CODE_1></EPL_CODE_1><br />
<EPL_MILEAGE></EPL_MILEAGE><br />
<EPL_CODE_3></EPL_CODE_3><br />
<EPL_SPEC_REQUIRED></EPL_SPEC_REQUIRED><br />
<EPL_SERVICE_GROUP></EPL_SERVICE_GROUP><br />
<EPL_SYSTEM_TYPE></EPL_SYSTEM_TYPE><br />
<EPL_UDF_INFO></EPL_UDF_INFO><br />
</INFO><br />
<MC_REF><br />
<EPL_MC_REF_1></EPL_MC_REF_1><br />
<EPL_MC_REF_2></EPL_MC_REF_2><br />
<EPL_MC_REF_3><EPL_MC_REF_3><br />
<EPL_MC_REF_4></EPL_MC_REF_4><br />
<EPL_MC_REF_NARRATIVE></EPL_MC_REF_NARRATIVE><br />
</MC_REF><br />
<DIAGNOSIS><br />
<EPL_DIAGNOSIS_NARRATIVE></EPL_DIAGNOSIS_NARRATIVE><br />
<EPL_CUSTOMER_DAMAGE></EPL_CUSTOMER_DAMAGE><br />
<EPL_VNOS></EPL_VNOS><br />
<EPL_CHECKBOX_1></EPL_CHECKBOX_1><br />
<EPL_CHECKBOX_2></EPL_CHECKBOX_2><br />
<EPL_CHECKBOX_3></EPL_CHECKBOX_3><br />
<EPL_UDF_DIAGNOSIS></EPL_UDF_DIAGNOSIS><br />
</DIAGNOSIS><br />
<PRODUCT><br />
<EPL_PRODUCT_ID></EPL_PRODUCT_ID><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
<EPL_DIRECTION></EPL_DIRECTION><br />
<EPL_RETURN></EPL_RETURN><br />
<EPL_DESCRIPTION></EPL_DESCRIPTION><br />
<EPL_VEHICLE_ID></EPL_VEHICLE_ID><br />
</PRODUCT><br />
<ACTIVITY><br />
<EPL_ACTIVITY_CODE></EPL_ACTIVITY_CODE><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
</ACTIVITY><br />
</SERVICE><br />
</SERVICES><br />
</EPOD_JOB><br />
{{Note}} This includes the changes made under references 311577, 311636, 311753 and 311801. <br />
<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Job Details tab will be changed slightly, as follows:<br />
* The main label showing "Service:" will be modified to show the Job Code of the Job here (EPOD_JOB.EPL_JOB_CODE) rather than the Service ID of the Service record (EPOD_SERVICE.EPL_SERVICE_ID).<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Info tab will be changed slightly, as follows:<br />
* 2 buttons will be added to the left and right of the main label, labelled as "<" and ">". These will be '''Previous''' and '''Next''' buttons.<br />
* A new label will be added to the title, under the "Service:" label, in a very small font, showing "Item X of Y", where X is current Service record in the Services collection (vars.lngServiceRecord - see below) and Y is the total number of records in the Services collection (PDAJOB.PDASERVICES.length).<br />
<br />
<gallery widths=310px heights=400px perrow=3><br />
File:REQ_309187_2.PNG|Info tab, showing the position of the new previous/next buttons (1 and 2)<br />
</gallery><br /><br />
<br />
If the user clicks on the '''Next''' button, the next service item will be displayed on each of the Service tabs. If there is no next Service record, the first will be displayed instead. The '''Previous''' button will work in the same way, showing the previous Service record, or the last. A "swipe" event will also be added to the "Service:" label, to perform the same function.<br />
<br />
In order to do this, a function must be written to update each of the tabs with the information from a particular service record. So:<br />
* The screen will be changed to hold a current Service record number (vars.lngServiceRecord) that will be set on creating the screen.<br />
* Any labels that need to be updated with data from the Service record on any of the tabs should be assigned variable items in the vars object, rather that just being added directly to any parent view - this is so that the text value can be updated.<br />
* Any changes to the previous Service will be saved.<br />
* The current Service record (lngServiceRecord) will be changed to the appropriate next Service record, depending on which button was pressed, and where in the Services collection the screen currently is.<br />
* The new function will update:<br />
** Each label, button, picker, text and check variable item in the screen with the appropriate value from the current Service record (for example, PDAJOB.PDASERVICES[vars.lngServiceRecord].PDASERVICE.EPL_SERVICE_ID).<br />
* This new function will be called at start-up (through an "open" event added to the TabGroup object) - all assignations of value and text properties derived from Service data will be removed from each variable declaration, to ensure that only one part of the code sets these values, to make code support easier.<br />
<br />
The validateJob function will be modified to check that all PDA_SERVICE items have had all details entered against them. This should be completed by checking the validation of all the service items when pressing the '''Done''' button. The validation messages displayed should identify the Service Item with the issues. {{Note}} New field EPL_STATUS of EPOD_SERVICE (specified in SCR 312116, referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]]) may be used to check and store the status if required. In this way, validating a service need be done only once. Also, only non-cancelled Service records need be checked.<br />
<br />
If this is not the case, a validation message should be displayed - clearing this message will return the user to the Services process.<br />
<br />
<br />
<!-- MEDIA LANDSCAPE YES --> <br />
= Appendix A: TEST PLAN =<br />
{{TestPlan_Header<br />
|Title={{#var:Doc_Title}}<br />
|Log={{#var:Reference}}<br />
|Description=To test that multiple Serviceable Items are supported by {{#var:System}}<br />
|MenuAccess=Services<br />
|Prerequisites=As much as possible (as far as has been developed on other Lanemark changes to the point of testing this one), the Services created and configuration allowed should match closely to the Lanemark requirements.<br />
|Objective=To test (for single and multiple serviceable items) that: Import adds and amends Service data correctly; Admin screens add, find and amend Service data correctly; the PDA allows navigation and updating of serviceable items and; the system exports Service data correctly.<br />
}}<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Import<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with one service record.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the single-service job again, but with an additional service item.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the multiple-service job again, but with one of the original service items removed.<br />
|Result=The job should be saved, with all service records associated to the Job ID. The removed Service item should be deleted.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Admin<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with a single service.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Find these service records again.<br />
|Result=All should appear once only on the grid.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a single-service job and add another service<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a multiple-service job, and delete a service<br />
|Result=The job should be saved, with all service records associated to the Job ID, except the deleted one.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Repeat the above tests on the Configurable Job screen<br />
|Result=As expected<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Services screen, find all services.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a specific Serviceable Item<br />
|Result=The service should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a serviceable item (Service ID) that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Enter a partial Serial Number that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=PDA<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a single-service job on the device and complete.<br />
|Result=This should operate as before, to the limit of already-coded changes for Lanemark at the point of testing.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a multiple-service job on the device (at least 3 serviceable items).<br />
|Result=The Job Details screen will show the Job Code as the Service ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Change to the Info screen.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete details of the first serviceable item. Press Done.<br />
|Result=A validation error should be displayed, showing that not all details have been entered against all Serviceable Items.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Move to the Info tab and press Next.<br />
|Result=The details of the second serviceable item are displayed; Previous and Next buttons are present; a sub-title of "2 of 3" is displayed. No other details have been entered against this item.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the details of all remaining items (markedly different on all items), finishing on the third. <br />
|Result=The details of the third serviceable item are displayed; Previous and Next buttons are present; a sub-title of "3 of 3" is displayed. All details entered against the third item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Press Next.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed. All details entered against the first item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action= Press Done<br />
|Result=The service should complete (move to signature).<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the service job<br />
|Result=The results of all services should be returned to the system.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Post-PDA (Admin/Server)<br />
|Notes=Ensure that single- and multiple-item jobs have been completed.<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check all items on all jobs updated.<br />
|Result=All records are updated correctly<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a Single-item Service Job <br />
|Result=The screen has changed layout correctly - only one service item's details are displayed<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a multiple-item Service Job <br />
|Result=The screen has changed layout correctly - all service item's details are displayed on a scrolling screen.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Export<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a single-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a multiple-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
<!-- MEDIA LANDSCAPE NO --> <br />
{{Doc_Appendix<br />
|Appendix=B<br />
|Estimate=Y<br />
|Glossary=EPOD<br />
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]<br />
|RefV1=2.0<br />
|RefDate1=4/4/2012<br />
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]<br />
|RefV2=3.0<br />
|RefDate2=23/4/2013<br />
|Ref3=[[REQ_309371_Lanemark_eSERV_Requirements]]<br />
|RefV3=0.4<br />
|RefDate3=29/08/2013<br />
|Ref4=[[FS_312116_Service_Cancellation_Changes]]<br />
|RefV4=0.1<br />
|RefDate4=19/09/2013<br />
|REQ=0<br />
|EST=0<br />
|FS=1.25<br />
|TS=0.0<br />
|DEV=10.5<br />
|ST=2.0<br />
|IMP=0<br />
|FOC=Y<br />
|Client={{#var:Client}}<br />
|Year={{#var:Year}}<br />
|FSEST=N<br />
|Rev1=Julie Taylor<br />
|Rev1Title=OBS Project Manager<br />
|Rev2=Jeff Foster<br />
|Rev2Title=Client Representative<br />
|Rev3=Alan Thompson<br />
|Rev3Title=Client Representative<br />
}}</div> <br />
[[Category:{{#var:Client}} FS]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_311856_Multiple_Serviceable_Items&diff=1285FS 311856 Multiple Serviceable Items2013-10-23T07:49:14Z<p>Cak: /* Database/DAL */</p>
<hr />
<div><div class="noprint"><br />
{{#vardefine:Client|LANE}}<br />
{{#vardefine:ClientName|Lanemark}}<br />
{{#vardefine:System|''CALIDUS'' eSERV}}<br />
{{#vardefine:Doc_Title|Multiple Serviceable Items}}<br />
{{#vardefine:Version|0.2}}<br />
{{#vardefine:Date|19th September 2013}}<br />
{{#vardefine:Reference|311856 309371-2}}<br />
{{#vardefine:Year|2013}}<br />
</div><br />
{{Doc_Title<br />
|Client={{#var:ClientName}}<br />
|System={{#var:System}}<br />
|Title={{#var:Doc_Title}}<br />
|Reference=FS {{#var:Reference}}<br />
|Version={{#var:Version}}<br />
|Date={{#var:Date}}<br />
|Year={{#var:Year}}<br />
}} <br />
<br />
<!-- TOC --> <br />
<div class="noprint"><br />
= Functional Overview =<br />
== Client Requirement ==<br />
* Multiple engineers assigned to one service job. <br />
* One job with multiple service items.<br />
<br />
== Solution Overview ==<br />
NAV can have multiple serviceable items on a single Job, allocated to multiple engineers. <br />
<br />
Where multiple engineers are required on a job, for example:<br />
* 3 engineers on site<br />
* 20 gas burners to service <br />
Each engineer will complete the service of several of the burners (the serviceable items) against the service.<br />
<br />
In practice, the lead engineer will assign the burners to each engineer on the job, rather than pre-assign.<br />
<br />
This will be completed through a link to NAV direct from a mobile unit (i.e. a PC). <br />
<br />
<br />
On the PDA Info tab, if there are multiple serviceable items on the job, the screen also would have navigation buttons left and right of the title (sections 1 and 2), to allow the user to switch between serviceable items. <br />
<br />
A label showing the record being processed (e.g. "1 of 6") would be shown, allowing the user to see how many there are. <br />
<br />
The Service Item number (LS Number) of the serviceable item will be displayed on the top of the Info tab, whereas the Service ID (SJ Number) will be displayed on the Job Details tab.<br />
<br />
Switching between the serviceable items will change the displayed data on each of the tabs to the next service record - the same affect can be made by swiping left or right on the title label. <br />
<br />
== Scope ==<br />
* These changes will be made in the latest version of the {{#var:System}} product only.<br />
* The changes will be made to the Android eSERV client only. Note that this change drives change into the Server processes that deal with PDA updates that would mean that the existing Windows Mobile and previous versions of the Android client may be incompatible with this version of the server.<br />
* {{Note}} The modifications seen here require NAV functionality to split a service job among several engineers, specifically assigning items to each engineer to complete. Any failure to deliver the required functionality will cause the processes described here to fail.<br />
* {{Note}} The changes in SCR 312116 specify some details that will be useful in the completion of this code. This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
<!-- NEW PAGE --> <br />
<br />
= Set-up =<br />
<br />
== Pre-requisites ==<br />
<br />
== Menu Structure ==<br />
<br />
== Data ==<br />
<br />
<!-- NEW PAGE --> <br />
= Functional Description =<br />
== Database/DAL ==<br />
The database table EPOD_SERVICE must have the indexes changed to reflect the new model, as follows:<br />
* The primary key (PK_EPOD_SERVICE_1) should be modified as follows:<br />
** EPL_SITE_ID, ascending<br />
** EPL_JOB_ID, ascending<br />
** EPL_SERVICE_ID, ascending<br />
* The secondary unique index (IX_EPOD_SERVICE) should stay - Service IDs should remain unique under Site.<br />
{{Note}} All database packages must be checked to ensure they reflect this change to the data model.<br />
<br />
The DAL object EPOD_JOB will be modified to have an EPOD_SERVICES collection added beneath it, consisting of all the EPOD_SERVICE records found against the EPOD_JOB. This will be completed when creating an EPOD_JOB DAL object for an EPOD_JOB record that already exists. If the EPOD_JOB DAL object created does not exist, an empty collection should be created.<br />
<br />
{{Note}} The XML Export of jobs and Services already allows EPOD_SERVICE to iterate within a tag of EPOD_SERVICES, as follows:<br />
<EPOD_JOB><br />
...<br />
<EPOD_SERVICES><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
<EPOD_SERVICE><br />
...<br />
</EPOD_SERVICE><br />
</EPOD_SERVICES><br />
</EPOD_JOB><br />
This supports multiple EPOD_SERVICE records, but the EPOD_SERVICES tag must be changed to reflect multiple records, with a maxOccurs property of "unbounded" replacing "1". All XSDs must be modified to reflect this, including but not limited to:<br />
* EPOD_EXPORT_JOB_RESPONSE.xsd<br />
* EPOD_EXPORT_JOB.xsd<br />
* EPOD_EXPORT_LOAD_RESPONSE.xsd<br />
* EPOD_EXPORT_LOAD.xsd<br />
<br />
The XML Import process (through the web services ePOD_DataService.asmx and ePOD_DataService2.asmx) must be modified to allow the same functionality when receiving Service Jobs, i.e.:<br />
* Allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
Therefore the following changes must be made:<br />
* XMLUpload.xsd must be modified to allow an EPOD_SERVICES tag, containing the existing EPOD_SERVICE tag, allowing unbounded occurrences.<br />
* EPOD_DATASERVICE.ProcessJobs must change to check for this EPOD_SERVICES tag - if it exists, each EPOD_SERVICE tag found inside should be passed to the ProcessService function - see the existing xePRODUCTS code above the EPOD_SERVICE code for an example of how this is achieved.<br />
* Any EPOD_SERVICE objects that have not been found on the XML update should be removed from the EPOD_JOB (i.e. deleted) unless they have already been cancelled ({{Note}} This functionality will be specified under a different change).<br />
* Any EPOD_SERVICE tag that does not exist should be created.<br />
* The XMLUpload XSD should also be changed to include an optional EPL_USER_ID tag within the EPOD_JOB section. When an import is received if no load information is provided and the new EPL_USER_ID tag has been populated a check should be made against the Site to ascertain the value of the EPL_AUTO_GEN_LOAD flag, if this value is set a check should be performed to see if there is currently a load assigned to the user at Pending or In progress status and if found the jobs should be allocated to this load. If no load details are found a load should be created using the user id and the current date as the Load id and the jobs assigned to this load.<br />
<br />
== Server ==<br />
Changes will be made to the JOB_UPDATE message returned from the PDA, as follows:<br />
* Remove EPL_SITE_ID and EPL_SERVICE_ID from the ACTIVITY tag.<br />
* Add EPL_SERVICE_ID and EPL_SERVICE_TYPE to the top of the SERVICE tag.<br />
{{Note}} For the format of the XML update message, see the [[#Android Client|Android Client]] section of this document<br />
<br />
In order to match these changes, the function MessageProcess.ProcessJobUpdate must change as follows:<br />
* For each SERVICE tag found in SERVICES, create an EPOD_SERVICE object. Update this object with the details passed in the SERVICE tag from the PDA. This is similar processing to how the EPOD_SERVICE_PRODUCT and EPOD_SERVICE_ACTIVITY updates work in the same process.<br />
{{Note}} The change to EPOD_SERVICE_ACTIVITY (where two elements have been removed) need not be reflected, as these elements are never used.<br />
<br />
<br />
== Admin ==<br />
The Job and Service Screens will require modification when creating a new job. Those screens affected are:<br />
* ConfigurableJob.aspx<br />
* job_details.aspx<br />
When creating or editing a new Service job, a pop-up screen is displayed. The Service section (lower left) will be modified as follows:<br />
* When editing, all Service records will be loaded upon showing the pop-up form. When adding, only one will be assumed.<br />
* A navigation group will be added to this section, disabled initially, enabled if there are multiple service records for the job.<br />
* An '''Add''' button will be added to this section - each time this is pressed, a new service record will be allowed to be created in this section, by adding a navigable item to the navigation group and moving to this item.<br />
* A '''Delete''' button will be added to this section - when pressed, this will mark the associated service record as requiring deletion when the page is saved. It will still show on the screen (but will have all fields disabled) until the page is saved.<br />
* When a new item is created, the Service ID should be defaulted to EPL_JOB_CODE + "_" + count.<br />
* Moving between service items on the navigation group should show the details of the salient service record.<br />
* Saving will save all changed service records. Note that Service ID can be modified, and therefore care should be taken in updating each record. This should utilise the Service details on the page in the same sequence as the EPOD_SERVICE records in the EPOD_SERVICES collection in the DAL object. Therefore, even if the Service ID changes, this should update the correct EPOD_SERVICE record with these details.<br />
<br />
{{Note}} Time should be taken at this point to re-organise the layout of this pop-up - for example, Dates and Times associated to each other should be concatenated onto the same line:<br />
* Planned Date/Time<br />
* Actual Date/Time<br />
* Order Date/Time<br />
* Expiry Date/Time<br />
* Arrival Date/Time<br />
Additionally, the Service section should be labelled as such and only appear if the job is a Service type.<br />
<br />
{{Note}} The Service screen (service_job.aspx) utilises EPOD_SERVICE_JOB, a different DAL mechanism that allows only 1 service record per job. Although it should be possible to maintain and create Service jobs (with all the required fields) on this screen, it is not necessary to change this to allow creation of multiple service items on a single job. The screen itself ''should'' allow the searching for and displaying of each item, however. <br />
<br />
<br />
The Service Details screen (service_detail.aspx) will be modified as follows: <br />
* When retrieving the EPOD_JOB, modifications will need to be made throughout the code to accommodate the fact that the EPOD_SERVICE objects exist only within an EPOD_SERVICES collection and not directly from EPOD_JOB, even if there is only one EPOD_SERVICE record.<br />
* The "Service Details" section should be renamed "Job Details", and the items Service ID and Service Type removed from this section.<br />
* All further sections (Information, Pre-Work, Post-Work, Diagnosis, MC Refs and Products) should be included within another Section, labelled with the items Service ID and Service Type, in a larger, bolder font. <br />
* The Service Details section should be created for each EPOD_SERVICE under the EPOD_SERVICES collection under EPOD_JOB, printed one under each other - the browser scroll-bar can be used to see all the details.<br />
<br />
[[File:FS_311856_1.PNG|border|600px]]<br />
<br />New Job Details screen<br />
<br />
{{Note}} This sample also shows fields defined under SCR 312116 (status and reason code, and the '''Image''' button). This is referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]].<br />
<br />
{{Note}} In the current screen, the Diagnosis and Products sections seem to be less wide than the Information section - this should be corrected on all affected sections.<br />
<br />
<br />
== Android Client ==<br />
The PDA_SERVICE DAL object will change to:<br />
* Add parameter Service ID on creation of a PDA_SERVICE object. <br />
** If one is provided, this should create a PDA_SERVICE object, retrieve the EPOD_SERVICE record and return the object.<br />
** If one is not provided, this should fetch all EPOD_SERVICE records for the job, create a PDASERVICES array and, for each record found, create a new PDA_SERVICE object (as PDASERVICE) and pass the Site, Job and Service ID parameters to the new object. Once all are created, return the PDASERVICES collection.<br />
* The existing function ProcessServiceUpdate (called when Job Lock Response is processed, on pressing the Start/Arrive/Continue button in Job Details) must change to iterate through a collection of Service records, and update each one separately, by creating a PDA_SERVICE object passing Site, Job ID and Service ID.<br />
<br />
All functions that create PDA_SERVICE objects must now be checked that they pass a Service ID correctly, or they are expecting a PDASERVICES collection returned.<br />
<br />
The PDA_JOB DAL object will change to:<br />
* hold a collection of PDA_SERVICE record (named PDASERVICES), rather than a single PDA_SERVICE object (PDASERVICE), as it does now.<br />
* On creation of a new Job, create a collection PDASERVICES from a new PDA_SERVICE object - this will return a collection from the instantiation.<br />
<br />
{{Note}} No further changes should be necessary on the importing of services - the existing InsertAllPDAServices (called by Job creation functions ) already iterates through a number of EPOD_SERVICE records within the passed XML tag EPOD_SERVICES and adds each record. As these functions delete all service records first before adding new records, no updating functionality should be required.<br />
<br />
<br />
The method PDA_JOB.ToUpdateXElement will be modified to create a SERVICES tag rather than a SERVICE tag, if there is more than one Service record in the PDASERVICES collection. Each element in the Services collection will then be iterated through, calling PDASERVICE.ToUpdateXElement().<br />
<br />
The method PDA_SERVICE.ToUpdateXElement will be modified to add EPL_SERVICE_ID and EPL_SERVICE_TYPE tags before any others.<br />
<br />
The method PDA_SERVICE_ACTIVITY.ToUpdateXElement will be modified to remove EPL_SITE_ID and EPL_SERVICE_ID.<br />
<br />
The resulting XML extraction for a job should then look as follows:<br />
<EPOD_JOB><br />
...<br />
<SERVICES><br />
<SERVICE><br />
<EPL_SERVICE_ID></EPL_SERVICE_ID><br />
<EPL_SERVICE_TYPE></EPL_SERVICE_TYPE><br />
<PREWORK><br />
<EPL_PREWORK_INTERIOR></EPL_PREWORK_INTERIOR><br />
<EPL_PREWORK_EXTERIOR></EPL_PREWORK_EXTERIOR><br />
<EPL_PREWORK_ELECTRIC></EPL_PREWORK_ELECTRIC><br />
<EPL_UDF_PREWORK></EPL_UDF_PREWORK><br />
</PREWORK><br />
<POSTWORK><br />
<EPL_POSTWORK_INTERIOR></EPL_POSTWORK_INTERIOR><br />
<EPL_POSTWORK_EXTERIOR></EPL_POSTWORK_EXTERIOR><br />
<EPL_POSTWORK_ELECTRIC></EPL_POSTWORK_ELECTRIC><br />
<EPL_UDF_POSTWORK></EPL_UDF_POSTWORK><br />
</POSTWORK><br />
<INFO><br />
<EPL_UNIT_TYPE></EPL_UNIT_TYPE><br />
<EPL_CODE_2></EPL_CODE_2><br />
<EPL_CODE_1></EPL_CODE_1><br />
<EPL_MILEAGE></EPL_MILEAGE><br />
<EPL_CODE_3></EPL_CODE_3><br />
<EPL_SPEC_REQUIRED></EPL_SPEC_REQUIRED><br />
<EPL_SERVICE_GROUP></EPL_SERVICE_GROUP><br />
<EPL_SYSTEM_TYPE></EPL_SYSTEM_TYPE><br />
<EPL_UDF_INFO></EPL_UDF_INFO><br />
</INFO><br />
<MC_REF><br />
<EPL_MC_REF_1></EPL_MC_REF_1><br />
<EPL_MC_REF_2></EPL_MC_REF_2><br />
<EPL_MC_REF_3><EPL_MC_REF_3><br />
<EPL_MC_REF_4></EPL_MC_REF_4><br />
<EPL_MC_REF_NARRATIVE></EPL_MC_REF_NARRATIVE><br />
</MC_REF><br />
<DIAGNOSIS><br />
<EPL_DIAGNOSIS_NARRATIVE></EPL_DIAGNOSIS_NARRATIVE><br />
<EPL_CUSTOMER_DAMAGE></EPL_CUSTOMER_DAMAGE><br />
<EPL_VNOS></EPL_VNOS><br />
<EPL_CHECKBOX_1></EPL_CHECKBOX_1><br />
<EPL_CHECKBOX_2></EPL_CHECKBOX_2><br />
<EPL_CHECKBOX_3></EPL_CHECKBOX_3><br />
<EPL_UDF_DIAGNOSIS></EPL_UDF_DIAGNOSIS><br />
</DIAGNOSIS><br />
<PRODUCT><br />
<EPL_PRODUCT_ID></EPL_PRODUCT_ID><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
<EPL_DIRECTION></EPL_DIRECTION><br />
<EPL_RETURN></EPL_RETURN><br />
<EPL_DESCRIPTION></EPL_DESCRIPTION><br />
<EPL_VEHICLE_ID></EPL_VEHICLE_ID><br />
</PRODUCT><br />
<ACTIVITY><br />
<EPL_ACTIVITY_CODE></EPL_ACTIVITY_CODE><br />
<EPL_QUANTITY></EPL_QUANTITY><br />
</ACTIVITY><br />
</SERVICE><br />
</SERVICES><br />
</EPOD_JOB><br />
{{Note}} This includes the changes made under references 311577, 311636, 311753 and 311801. <br />
<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Job Details tab will be changed slightly, as follows:<br />
* The main label showing "Service:" will be modified to show the Job Code of the Job here (EPOD_JOB.EPL_JOB_CODE) rather than the Service ID of the Service record (EPOD_SERVICE.EPL_SERVICE_ID).<br />
<br />
If there are multiple serviceable items on the service job, the layout of the Info tab will be changed slightly, as follows:<br />
* 2 buttons will be added to the left and right of the main label, labelled as "<" and ">". These will be '''Previous''' and '''Next''' buttons.<br />
* A new label will be added to the title, under the "Service:" label, in a very small font, showing "Item X of Y", where X is current Service record in the Services collection (vars.lngServiceRecord - see below) and Y is the total number of records in the Services collection (PDAJOB.PDASERVICES.length).<br />
<br />
<gallery widths=310px heights=400px perrow=3><br />
File:REQ_309187_2.PNG|Info tab, showing the position of the new previous/next buttons (1 and 2)<br />
</gallery><br /><br />
<br />
If the user clicks on the '''Next''' button, the next service item will be displayed on each of the Service tabs. If there is no next Service record, the first will be displayed instead. The '''Previous''' button will work in the same way, showing the previous Service record, or the last. A "swipe" event will also be added to the "Service:" label, to perform the same function.<br />
<br />
In order to do this, a function must be written to update each of the tabs with the information from a particular service record. So:<br />
* The screen will be changed to hold a current Service record number (vars.lngServiceRecord) that will be set on creating the screen.<br />
* Any labels that need to be updated with data from the Service record on any of the tabs should be assigned variable items in the vars object, rather that just being added directly to any parent view - this is so that the text value can be updated.<br />
* Any changes to the previous Service will be saved.<br />
* The current Service record (lngServiceRecord) will be changed to the appropriate next Service record, depending on which button was pressed, and where in the Services collection the screen currently is.<br />
* The new function will update:<br />
** Each label, button, picker, text and check variable item in the screen with the appropriate value from the current Service record (for example, PDAJOB.PDASERVICES[vars.lngServiceRecord].PDASERVICE.EPL_SERVICE_ID).<br />
* This new function will be called at start-up (through an "open" event added to the TabGroup object) - all assignations of value and text properties derived from Service data will be removed from each variable declaration, to ensure that only one part of the code sets these values, to make code support easier.<br />
<br />
The validateJob function will be modified to check that all PDA_SERVICE items have had all details entered against them. This should be completed by checking the validation of all the service items when pressing the '''Done''' button. The validation messages displayed should identify the Service Item with the issues. {{Note}} New field EPL_STATUS of EPOD_SERVICE (specified in SCR 312116, referenced in [[#Appendix_B:_Quote_.26_Document_References|Appendix B]]) may be used to check and store the status if required. In this way, validating a service need be done only once. Also, only non-cancelled Service records need be checked.<br />
<br />
If this is not the case, a validation message should be displayed - clearing this message will return the user to the Services process.<br />
<br />
<br />
<!-- MEDIA LANDSCAPE YES --> <br />
= Appendix A: TEST PLAN =<br />
{{TestPlan_Header<br />
|Title={{#var:Doc_Title}}<br />
|Log={{#var:Reference}}<br />
|Description=To test that multiple Serviceable Items are supported by {{#var:System}}<br />
|MenuAccess=Services<br />
|Prerequisites=As much as possible (as far as has been developed on other Lanemark changes to the point of testing this one), the Services created and configuration allowed should match closely to the Lanemark requirements.<br />
|Objective=To test (for single and multiple serviceable items) that: Import adds and amends Service data correctly; Admin screens add, find and amend Service data correctly; the PDA allows navigation and updating of serviceable items and; the system exports Service data correctly.<br />
}}<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Import<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with one service record.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import a Service job in the new format, with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the single-service job again, but with an additional service item.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Import the multiple-service job again, but with one of the original service items removed.<br />
|Result=The job should be saved, with all service records associated to the Job ID. The removed Service item should be deleted.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Admin<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with a single service.<br />
|Result=The Job should be saved, with the service record associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Job screen, create a Service job with more than one (ideally three) service records.<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Find these service records again.<br />
|Result=All should appear once only on the grid.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a single-service job and add another service<br />
|Result=The job should be saved, with all service records associated to the Job ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Edit a multiple-service job, and delete a service<br />
|Result=The job should be saved, with all service records associated to the Job ID, except the deleted one.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Repeat the above tests on the Configurable Job screen<br />
|Result=As expected<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=In the Services screen, find all services.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a specific Serviceable Item<br />
|Result=The service should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Search for a serviceable item (Service ID) that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Enter a partial Serial Number that matches multiple serviceable items across multiple jobs.<br />
|Result=All services created should be found, with a single line for all serviceable items, not one per job.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=PDA<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a single-service job on the device and complete.<br />
|Result=This should operate as before, to the limit of already-coded changes for Lanemark at the point of testing.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Start a multiple-service job on the device (at least 3 serviceable items).<br />
|Result=The Job Details screen will show the Job Code as the Service ID.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Change to the Info screen.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete details of the first serviceable item. Press Done.<br />
|Result=A validation error should be displayed, showing that not all details have been entered against all Serviceable Items.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Move to the Info tab and press Next.<br />
|Result=The details of the second serviceable item are displayed; Previous and Next buttons are present; a sub-title of "2 of 3" is displayed. No other details have been entered against this item.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the details of all remaining items (markedly different on all items), finishing on the third. <br />
|Result=The details of the third serviceable item are displayed; Previous and Next buttons are present; a sub-title of "3 of 3" is displayed. All details entered against the third item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Press Next.<br />
|Result=The details of the first serviceable item are displayed; Previous and Next buttons are present; a sub-title of "1 of 3" is displayed. All details entered against the first item are displayed.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action= Press Done<br />
|Result=The service should complete (move to signature).<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Complete the service job<br />
|Result=The results of all services should be returned to the system.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Post-PDA (Admin/Server)<br />
|Notes=Ensure that single- and multiple-item jobs have been completed.<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check all items on all jobs updated.<br />
|Result=All records are updated correctly<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a Single-item Service Job <br />
|Result=The screen has changed layout correctly - only one service item's details are displayed<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Check the Service Details screen for a multiple-item Service Job <br />
|Result=The screen has changed layout correctly - all service item's details are displayed on a scrolling screen.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
{{TestPlan_CycleHeader<br />
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}<br />
|Title=Export<br />
|Notes=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a single-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}}{{TestPlan_Test<br />
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}<br />
|Action=Export a multiple-item Service Job<br />
|Result=The job is exported correctly and the resulting export XML matches the XSD.<br />
|Remarks= |PassFail=<br />
}} {{TestPlan_CycleFooter}}<br />
<br />
<!-- MEDIA LANDSCAPE NO --> <br />
{{Doc_Appendix<br />
|Appendix=B<br />
|Estimate=Y<br />
|Glossary=EPOD<br />
|Ref1=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291094_EPOD_Admin_User_Guide UG 291094 EPOD Admin User Guide]<br />
|RefV1=2.0<br />
|RefDate1=4/4/2012<br />
|Ref2=[http://{{SERVERNAME}}/calidus-assist/EPOD/index.php/UG_291097_EPOD_Client_User_Guide UG 291097 EPOD Client User Guide]<br />
|RefV2=3.0<br />
|RefDate2=23/4/2013<br />
|Ref3=[[REQ_309371_Lanemark_eSERV_Requirements]]<br />
|RefV3=0.4<br />
|RefDate3=29/08/2013<br />
|Ref4=[[FS_312116_Service_Cancellation_Changes]]<br />
|RefV4=0.1<br />
|RefDate4=19/09/2013<br />
|REQ=0<br />
|EST=0<br />
|FS=1.25<br />
|TS=0.0<br />
|DEV=10.5<br />
|ST=2.0<br />
|IMP=0<br />
|FOC=Y<br />
|Client={{#var:Client}}<br />
|Year={{#var:Year}}<br />
|FSEST=N<br />
|Rev1=Julie Taylor<br />
|Rev1Title=OBS Project Manager<br />
|Rev2=Jeff Foster<br />
|Rev2Title=Client Representative<br />
|Rev3=Alan Thompson<br />
|Rev3Title=Client Representative<br />
}}</div> <br />
[[Category:{{#var:Client}} FS]]</div>Cakhttps://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=User:Cak&diff=1278User:Cak2013-10-16T09:02:30Z<p>Cak: </p>
<hr />
<div>Tina Kinsella<br />
<br />
'''OBS Logistics Developer'''<br />
<br />
Direct Dial: +44(0)151 448 2925<br />
<br />
Internal: 1225<br />
<br />
Email Address: mailto:Christine.Kinsella@obs-logistics.com</div>Cak