TEST: Difference between revisions

From Calidus HUB
VisualWikitext
No edit summary
No edit summary
Line 1: Line 1:
<div class="noprint">
Add Multiple Photos to Export.
{{#vardefine:Client|OBS}}
{{#vardefine:ClientName|OBS Logistics Ltd}}
{{#vardefine:System|''CALIDUS'' WMS}}
{{#vardefine:Doc_Title|Release Notes}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|8th May 2016}}
{{#vardefine:Reference|091}}
{{#vardefine:Year|2016}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=P{{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}
<!-- TOC -->
<div class="noprint">


= SUMMARY INTRODUCTION =
== INTRODUCTION ==
The main aim of this document is to provide {{#var:System}} users with the level of detail required to accurately test all software included in the patch.  The document also contains set-up and configuration details to enable the user to configure the system correctly for the new functionality to work.


Requirement:


=== GLOSSARY OF TERMS ===
Since the product development of multiple photo capture within the processing of a job, the export process does not include these any more. The export must be modified to include these in a new structure under EPOD_JOB.
 
 
Solution:
 
A new XML tag will be added to the export - EPOD_PHOTOS. This will contain a collection of EPOD_PHOTO tags. This tag will contain all photos related to the job of any type.
 
    <EPOD_PHOTO>
        <EPL_PHOTO_ID></EPL_PHOTO_ID>
        <EPL_DESCRIPTION></EPL_DESCRIPTION>
        <EPL_PHOTO></EPL_PHOTO>
        <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
        <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
        <EPL_SITE_ID></EPL_SITE_ID>
        <EPL_IMAGE_TYPE></EPL_IMAGE_TYPE>
        <EPL_KEYVAL_1></EPL_KEYVAL_1>
        <EPL_KEYVAL_2></EPL_KEYVAL_2>
        <EPL_KEYVAL_3></EPL_KEYVAL_3>
        <EPL_KEYVAL_4></EPL_KEYVAL_4>
        <EPL_KEYVAL_5></EPL_KEYVAL_5>
    </EPOD_PHOTO>
 
The details are:
* EPL_PHOTO_ID - a unique identifier of the photo.
* EPL_DESCRIPTION - a comment entered against the photo when taken.
* EPL_PHOTO - the photo, in BASE64-encoded JPEG format.
* EPL_LAST_CHANGED_DATE - the date the photo was updated
* EPL_LAST_CHANGED_TIME - the time the photo was updated
* EPL_SITE_ID - the unique site ID.
* EPL_IMAGE_TYPE - the type of image - see later
* EPL_KEYVAL_1 - key values based on the type.
* EPL_KEYVAL_2 - key values based on the type.
* EPL_KEYVAL_3 - key values based on the type.
* EPL_KEYVAL_4 - key values based on the type.
* EPL_KEYVAL_5 - key values based on the type.
 
 
Image types and key values are as follows:


{| border="1"
{| border="1"
|- bgcolor="silver"
|- bgcolor="silver"
!Term !! Meaning
!EPL_IMAGE_TYPE !!Description !!EPL_KEYVAL_1 !!EPL_KEYVAL_2 !!EPL_KEYVAL_3 !!EPL_KEYVAL_4 !!EPL_KEYVAL_5
|-
|-
|C-TMS || Transport Management System
|J ||Job Photo. ||EPL_JOB_ID ||&nbsp; ||&nbsp; ||&nbsp; ||&nbsp;
|-
|-
|C-WMS || Warehouse Management System
|JU/JU1/JU2/JU3 ||Job UDF ||EPL_JOB_ID ||UDF Item ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|-
|CR || Change Request
|C ||Container ||EPL_JOB_ID ||EPL_CONTAINER_ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|-
|C-WCS || Warehouse Control System
|CU ||Container UDF ||EPL_JOB_ID ||EPL_CONTAINER_ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|-
|C-ePOD || Electronic Proof of Delivery
|P ||Product ||EPL_JOB_ID ||EPL_CONTAINER_ID ||EPL_PRODUCT_CODE ||EPL_SEQUENCE ||&nbsp;
|-
|-
|C-MCS || Mobile Control System
|PU ||Product UDF ||EPL_JOB_ID ||EPL_CONTAINER_ID ||EPL_PRODUCT_CODE ||EPL_SEQUENCE ||UDF Item ID
|-
|-
|C-TTM || Track and Trace Management
|S ||Service Item ||EPL_JOB_ID ||EPL_SERVICE_ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|-
|EDI || Electronic Data Interchange
|SIU ||Service Item Info UDF ||EPL_JOB_ID ||EPL_SERVICE_ID ||UDF Item ID ||&nbsp; ||&nbsp;
|-
|-
|TID || Testing Issue Development, or Log
|SPR ||Service Item Prework UDF ||EPL_JOB_ID ||EPL_SERVICE_ID ||UDF Item ID ||&nbsp; ||&nbsp;
|-
|SPO ||Service Item Postwork UDF ||EPL_JOB_ID ||EPL_SERVICE_ID ||UDF Item ID ||&nbsp; ||&nbsp;
|-
|SDU ||Service Item Diagnosis UDF ||EPL_JOB_ID ||EPL_SERVICE_ID ||UDF Item ID ||&nbsp; ||&nbsp;
|-
|LSU ||Load Start Metrics UDF ||EPL_LOAD_ID ||UDF Item ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|LEU ||Load End Metrics UDF ||EPL_LOAD_ID ||UDF Item ID ||&nbsp; ||&nbsp; ||&nbsp;
|-
|VC ||Vehicle Checks ||EPL_VEHICLE_ID ||EPL_VEHICLE_CHECK_DATE<br />EPL_VEHICLE_CHECK_TIME ||UDF Item ID ||&nbsp; ||&nbsp;
|}
|}




<!-- NEW PAGE -->
== TESTING PROCESS ==
===TIDs AND RESOLUTION===
If there are any areas of the functionality that are not acceptable or do not meet the requirement specified in the Change Request then these should be expressed by raising a TID.
=== FINAL 'END TO END' TESTING ===
Prior to release to a production database, a full 'End to End' test is required on the test system by all sites using the database. Once this is signed off, a release date can be arranged.
=== AUTHORISATION ===
Authorisation from nominated release personnel only will be required when requesting a release to a production environment
= CHANGE REQUESTS =
<!--
== CR REF:  ==
=== Reporter ===
=== OBS Log Number ===
=== Summary of request ===
=== Release notes ===
=== Set-up and configuration ===
-->
== CR REF: AR-A6LBE3 ==
=== Reporter ===
Andrew Rowe
=== OBS Log Number ===
333070
=== Summary of request ===
RTB report has zero quantities when failure is at stop level 329671 is a program bug that doesn’t calculate the quantities correctly if multiple failure reasons are captured against a delivery. The fix involves checking the quantities recorded against each reason code.
Log 331450 is a problem with the data coming in from Microlise which was exposed by the fix for 329671; the fixed report looks for the quantity against the failure reason, but Microlise isn’t passing it in.
There is a solution, which is to amend the interface to check if a zero quantity is passed for a failure reason and assume that the quantity failed is the to-deliver quantity when updating the database. The data on the database will then be right and will appear correctly on the report.
=== Release notes ===
A new system parameter called 'MIC_CALC_REASON_QTY' will need to be set to 'Y' for the appropriate cost centre.
If 'MIC_CALC_REASON_QTY' is 'Y' and the reason code is a type of 'FAILURE' and a non-zero quantity has not been provided, the quantity will be calculated as the despatched quantity of the item multiplied by -1 for a negative adjustment (with the assumption that only one reason code will be provided).
If 'MIC_CALC_REASON_QTY' is 'N', the quantity from the file will be used.
=== Set-up and configuration ===
Path & Name: MIC_CALC_REASON_QTY
Setting Value: Y
Result: Sets the item reason quantity to the despatched quantity if a reason code is provided with a quantity of 0 instead of an accurate quantity and the type of reason code is ‘FAILURE’
Path & Name: MIC_CALC_REASON_QTY
Setting Value: N
Result: Existing functionality will set the item reason quantity to 0
<!-- NEW PAGE -->
== CR REF: JB-A3GDS9 ==
=== Reporter ===
Jeremy Brooks
=== OBS Log Number ===
330895
=== Summary of request ===
Review capability to provide web service access into Unison 414 has an MS Access database called DAVE that currently relies on manually run quiz reports. We are looking to replace this with a SQL backend and .net frontend and to remove the manually triggered reports and move to web services , if this is not possible or too expensive then need to understand any other options.
Suggested data required : o    Order line status…. Picker ref/Loader ref…. The intent here is to combine resource info and line detail to facilitate better status updates and productivity visibility.
Order Ref, Product code, Picker ID, Pick volume, Pick completion DTM, Loader ref, Loaded vol, Load completion DTM
=== Release notes ===
Add TEMP_CTRL to TRIP_DETAIL and ORDER_HEADER sections for LOTS records
=== Set-up and configuration ===
No set-up or configuration required
<!-- NEW PAGE -->
== CR REF: DS-A76DXR ==
=== Reporter ===
Denis Starodubov
=== OBS Log Number ===
333530
=== Summary of request ===
External Carriers pre-advice to be sent via EDI every few hours. At the moment external carriers such as Polarspeed get a pre-advice EDI message sent over every time trip set to En-route in CTMS, however this is end of day procedure at which point sometime it can be too late and therefore deliveries have to be moved to the next day by the carrier. The requirement is to have ability to send an EDI pre-advice (what orders are on the trip) at trip status such as Planned & Tendered utilising existing flows. Also, perhaps this can be manipulated by the carrier and how often the pre-advice sent over by CTMS, so this is fully automated process that can be tailored to our needs and developed as a blanket solution for all external carriers.
Benefits: External carriers get order detail pre-advice messages much sooner or as often as they require. That gives them ability to plan pickup and deliveries on time. This will improve delivery process and should eliminate late deliveries overall.
=== Release notes ===
The following changes will need to be made to the EDI process to produce an electronic manifest, for example:
Triggers:
Type = STATUS
Value = TENDERED (and/or ACCEPTED)
Parameters:
Param = PROCESS_INTERVAL
Value = 60
N.B. Changed to a parameter from a report value in FS.
The electronic manifest will be triggered as at present when the trip is updated to EN-ROUTE.
The electronic manifest will also be triggered when the trip is updated to a status listed for the EDI trigger and when an order is assigned to, or removed from, a trip that is EN-ROUTE or listed for the EDI trigger.
The EDI parameter for the interval will be used to only send a new electronic manifest when a previous file has been sent for the trip when the interval has elapsed.
The EDI parameter will not be used when the trip is EN-ROUTE so that the external carrier is informed immediately of any changes at that status.
=== Set-up and configuration ===
No set-up or configuration required
= SUPPORT INCIDENTS =
<!--
== Customer Ref:  ==
=== OBS Log Number ===
=== Reporter ===
=== Summary of Call ===
=== Detail of Fix ===
=== Set-up and configuration ===
-->
== Customer Ref: INC11247922 ==
=== OBS Log Number ===
330656
=== Reporter ===
=== Summary of Call ===
Inconsistency in the column count, extra column "lifts" in database
=== Detail of Fix ===
Change extract to always include lifts
=== Set-up and configuration ===
A WCS change is required with this call
== Customer Ref: INC11277761 ==
=== OBS Log Number ===
330751
=== Reporter ===
Suzie Maskery
=== Summary of Call ===
Exports not running correctly
=== Detail of Fix ===
Data fixes to the following three reports for search criteria issues:
* Outbound Shortage
* Receipt Scanning
* Driver Scanning
=== Set-up and configuration ===
An EPOD change is required with this call
= TID CHANGES =
<!--
== OBS Log Number: 331329 ==
=== Reporter ===
=== Summary of Call ===
=== Detail of Fix ===
=== Set-up and configuration ===
-->
== OBS Log Number: 331329 ==
=== Reporter ===
Andy Rowe
=== Summary of Call ===
Blank pages on BS RTB report
=== Detail of Fix ===
Stop collection orders being selected even when a delivery failure reason code has been used against it.
=== Set-up and configuration ===
No set-up or configuration is required
== OBS Log Number: 332187 ==
=== Reporter ===
Michelle Naumovski
=== Summary of Call ===
Change to remove job swap validation
=== Detail of Fix ===
Add fix to epod functionality to resolve job swapping issues.  This fix relates to both the following logs: 332187 & 332188
=== Set-up and configuration ===
A WCS change is required with the log
= OBSL PRODUCT DEVELOPMENT =
<!--
== OBS Log Number:  ==
=== Reporter ===
=== Summary of Call ===
=== Detail of Fix ===
=== Set-up and configuration ===
-->
== OBS Log Number: 334960 ==
=== Reporter ===
Paul Roscoe
=== Summary of Call ===
Main version of branched version 334939
=== Detail of Fix ===
This log has been raised to incorporate a branched version for log 334939 into the main version of the database package for export files.
=== Set-up and configuration ===
No set-up or configuration required
= ADDITIONAL CHANGES =
== WCS ==
A WCS change is required for the following logs:
* 330656
* 332187


== EPOD/T2A ==
A new Site parameter will control how photos are exported:
* N - Not exported
* Y - Job exported when all photos received.
* P - Job exported when ready and when any photos are received
* K - Job exported with Photo Key values only.


An EPOD/T2A change is required for the following logs:
* 330751


== MCS ==


There are no MCS changes required.
The device application will be modified to send back the key values of the photos for the job within the Job Update Request, as well as sending the photos separately.


== PORTAL/TTM ==
    <EPOD_PHOTOS>
        <EPOD_PHOTO>
            <EPL_DEVICE_PHOTO_ID></EPL_PHOTO_ID>
            <EPL_DESCRIPTION></EPL_DESCRIPTION>
            <EPL_SITE_ID></EPL_SITE_ID>
            <EPL_IMAGE_TYPE></EPL_IMAGE_TYPE>
            <EPL_KEYVAL_1></EPL_KEYVAL_1>
            <EPL_KEYVAL_2></EPL_KEYVAL_2>
            <EPL_KEYVAL_3></EPL_KEYVAL_3>
            <EPL_KEYVAL_4></EPL_KEYVAL_4>
            <EPL_KEYVAL_5></EPL_KEYVAL_5>
        </EPOD_PHOTO>
        <EPOD_PHOTO>
            ...
        </EPOD_PHOTO>
    </EPOD_PHOTOS>


There are no Portal/TTM changes required.
An EPOD_PHOTO tag will be sent back per EPOD_PHOTO for the EPL_JOB_ID, regardless of type.


== EDI ==


There are no EDI changes required.
The server Job Update request processor will recognise this content and create EPOD_PHOTO records for each EPOD_PHOTO tag, recording the details and marking the photos as not yet received.


The server Photo Request processor will update these records when received from the device. When received and complete, the processor will mark the job as not exported (EPL_XFER_FLAG) if the new Site parameter is set to "P".


</div>
The export process will check this flag when building XML for a job to export:
[[Category:{{#var:Client}} PATCH]]
* N - Do not include the EPOD_PHOTOS tag at all.
* Y - Only process the job if all photos for the job have EPL_COMPLETE set to "Y".
* P - Export with all photos with EPL_COMPLETE set to "Y" only.
* K - Job exported with Photo Key values only.

Revision as of 17:47, 3 February 2017

Add Multiple Photos to Export.


Requirement:

Since the product development of multiple photo capture within the processing of a job, the export process does not include these any more. The export must be modified to include these in a new structure under EPOD_JOB.


Solution:

A new XML tag will be added to the export - EPOD_PHOTOS. This will contain a collection of EPOD_PHOTO tags. This tag will contain all photos related to the job of any type. 

   <EPOD_PHOTO>
       <EPL_PHOTO_ID></EPL_PHOTO_ID>
       <EPL_DESCRIPTION></EPL_DESCRIPTION>
       <EPL_PHOTO></EPL_PHOTO>
       <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
       <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
       <EPL_SITE_ID></EPL_SITE_ID>
       <EPL_IMAGE_TYPE></EPL_IMAGE_TYPE>
       <EPL_KEYVAL_1></EPL_KEYVAL_1>
       <EPL_KEYVAL_2></EPL_KEYVAL_2>
       <EPL_KEYVAL_3></EPL_KEYVAL_3>
       <EPL_KEYVAL_4></EPL_KEYVAL_4>
       <EPL_KEYVAL_5></EPL_KEYVAL_5>
   </EPOD_PHOTO>

The details are:

  • EPL_PHOTO_ID - a unique identifier of the photo.
  • EPL_DESCRIPTION - a comment entered against the photo when taken.
  • EPL_PHOTO - the photo, in BASE64-encoded JPEG format.
  • EPL_LAST_CHANGED_DATE - the date the photo was updated
  • EPL_LAST_CHANGED_TIME - the time the photo was updated
  • EPL_SITE_ID - the unique site ID.
  • EPL_IMAGE_TYPE - the type of image - see later
  • EPL_KEYVAL_1 - key values based on the type.
  • EPL_KEYVAL_2 - key values based on the type.
  • EPL_KEYVAL_3 - key values based on the type.
  • EPL_KEYVAL_4 - key values based on the type.
  • EPL_KEYVAL_5 - key values based on the type.


Image types and key values are as follows:

EPL_IMAGE_TYPE Description EPL_KEYVAL_1 EPL_KEYVAL_2 EPL_KEYVAL_3 EPL_KEYVAL_4 EPL_KEYVAL_5
J Job Photo. EPL_JOB_ID        
JU/JU1/JU2/JU3 Job UDF EPL_JOB_ID UDF Item ID      
C Container EPL_JOB_ID EPL_CONTAINER_ID      
CU Container UDF EPL_JOB_ID EPL_CONTAINER_ID      
P Product EPL_JOB_ID EPL_CONTAINER_ID EPL_PRODUCT_CODE EPL_SEQUENCE  
PU Product UDF EPL_JOB_ID EPL_CONTAINER_ID EPL_PRODUCT_CODE EPL_SEQUENCE UDF Item ID
S Service Item EPL_JOB_ID EPL_SERVICE_ID      
SIU Service Item Info UDF EPL_JOB_ID EPL_SERVICE_ID UDF Item ID    
SPR Service Item Prework UDF EPL_JOB_ID EPL_SERVICE_ID UDF Item ID    
SPO Service Item Postwork UDF EPL_JOB_ID EPL_SERVICE_ID UDF Item ID    
SDU Service Item Diagnosis UDF EPL_JOB_ID EPL_SERVICE_ID UDF Item ID    
LSU Load Start Metrics UDF EPL_LOAD_ID UDF Item ID      
LEU Load End Metrics UDF EPL_LOAD_ID UDF Item ID      
VC Vehicle Checks EPL_VEHICLE_ID EPL_VEHICLE_CHECK_DATE
EPL_VEHICLE_CHECK_TIME		 UDF Item ID    


A new Site parameter will control how photos are exported:

  • N - Not exported
  • Y - Job exported when all photos received.
  • P - Job exported when ready and when any photos are received
  • K - Job exported with Photo Key values only.


The device application will be modified to send back the key values of the photos for the job within the Job Update Request, as well as sending the photos separately. 

   <EPOD_PHOTOS>
       <EPOD_PHOTO>
           <EPL_DEVICE_PHOTO_ID></EPL_PHOTO_ID>
           <EPL_DESCRIPTION></EPL_DESCRIPTION>
           <EPL_SITE_ID></EPL_SITE_ID>
           <EPL_IMAGE_TYPE></EPL_IMAGE_TYPE>
           <EPL_KEYVAL_1></EPL_KEYVAL_1>
           <EPL_KEYVAL_2></EPL_KEYVAL_2>
           <EPL_KEYVAL_3></EPL_KEYVAL_3>
           <EPL_KEYVAL_4></EPL_KEYVAL_4>
           <EPL_KEYVAL_5></EPL_KEYVAL_5>
       </EPOD_PHOTO>
       <EPOD_PHOTO>
           ...
       </EPOD_PHOTO>
   </EPOD_PHOTOS>

An EPOD_PHOTO tag will be sent back per EPOD_PHOTO for the EPL_JOB_ID, regardless of type.


The server Job Update request processor will recognise this content and create EPOD_PHOTO records for each EPOD_PHOTO tag, recording the details and marking the photos as not yet received.

The server Photo Request processor will update these records when received from the device. When received and complete, the processor will mark the job as not exported (EPL_XFER_FLAG) if the new Site parameter is set to "P".

The export process will check this flag when building XML for a job to export:

  • N - Do not include the EPOD_PHOTOS tag at all.
  • Y - Only process the job if all photos for the job have EPL_COMPLETE set to "Y".
  • P - Export with all photos with EPL_COMPLETE set to "Y" only.
  • K - Job exported with Photo Key values only.
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=TEST&oldid=4079’