View source for REQ 356284 Changes to On-time Report

<div class="noprint">
{{#vardefine:Client|MASH}}
{{#vardefine:ClientName|MASH Purveyors}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:SystemCode|EPOD}}
{{#vardefine:Doc_Title|Changes to On-time Report}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|11th March 2019}}
{{#vardefine:Reference|356284}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}} 

<!-- TOC --> 
<div class="noprint">
= Introduction  =
<!-- The introduction will detail the initial requirements supplied by the client -->
This document relates to {{#var:Doc_Title}}.

== Objective  ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}} regarding changes required to the On-time Report (previously known as the OTIF report).

<!-- List all amendments to the requirements here, and reference in final section, e.g. The document also encompasses the follow-up meeting held at X, with Y and Z attending, where the requirements were modified. See the minutes of the meeting referenced as item X in appendix B --> 

This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.
<!-- ANY scope or limitations, bulleted. -->
*The changes will be made in the latest version of the {{#var:System}} system.
<!-- ANY other systems? e.g. does this link to TTM, WMS, 414, 770, etc? -->
{{ #vardefine: SCR | 0 }}
<!-- NEW PAGE --> 

= Client Requirements =
There are two separate requirements covered in this document, as detailed below.
The intention is that both requirements will be developed and delivered together in a single release.

== Report by Planned Date ==
The requirement here is to allow the report to select by planned date instead of the current actual date, so that it will include any orders that have not yet been delivered.
The Proposed solution for this is an option on when requesting the report to select whether the entered date range applies to actual or planned date.

Note that incomplete orders without an actual date would be classed as 'not on time' even if the planned date is in the future.

== Report to XML ==
The requirement here is stated as follows


We are looking to take the output direct from the point of creation (whilst keeping the option to open the spreadsheet as currently happens) into a dedicated directory where it can be picked up from and taken into a site based reports generator where the data will be manipulated to provide graphics, on time reports etc.
So effectively:-
* We run the report as normal
* If we want open the spreadsheet the options remains
* At the time the report is run it is copied to a dedicated directory (folder), preferably in XML format 
* The file is picked up each time it is run from the report option and dropped into the folder by a site based package which will create dedicated kpis / statistical information, updating each time we run the report


The proposed solution for this is to provide a web service which can be called by specifying the report parameters and will return the report as XML.

The call to the web service would supply an XML request payload with authorisation, the report to be run and the parameters.
For example, the payload would look similar to this:

 <EPOD_REPORT_REQUEST EPL_SITE_ID="" EPL_USER_ID="" EPL_USER_PASSWORD="">
   <REPORT>MashOTIFReport</REPORT>
   <SITE></SITE>
   <DATE_TYPE>PLANNED</DATE_TYPE>
   <DATE_FROM></DATE_FROM>
   <DATE_TO></DATE_TO>
   <CUSTOMER_CODE></CUSTOMER_CODE>
   <ROUTE_CODE></ROUTE_CODE>
   <LOAD_ID></LOAD_ID>
   <JOB_TYPE></JOB_TYPE>
 </EPOD_REPORT_REQUEST>

ePOD would respond with the XML in a response message similar to this:

 <EPOD_REPORT_RESPONSE RESULT="ACK">
  <NewDataSet>
    <MashOTIFReport>
      <Customer_Code>M1</Customer_Code>
      <Customer_Name>Manchester Blood Centre</Customer_Name>
      <Load_ID>TRN-00001432</Load_ID>
      <Job_Code>NHS1432-1</Job_Code>
      <Status>C</Status>
      <Reason />
      <Sequence>1</Sequence>
      <Service />
      <Planned_Date>23/10/2014</Planned_Date>
      <Planned_Time>14:44</Planned_Time>
      <Arrival_Date />
      <Arrival_Time />
      <On_Time>N</On_Time>
    </MashOTIFReport>
    <MashOTIFReport>
      ...
    </MashOTIFReport>
  </NewDataSet>
 </EPOD_REPORT_RESPONSE>

Failures when running the report or with parameters would be returned in the standard mechanism, e.g.:

 <EPOD_REPORT_RESPONSE RESULT="NAK">
   <ERRORS>
     <ERROR error="USER DETAILS NOT VALID"/>
   </ERRORS>
 </EPOD_REPORT_RESPONSE>

<!-- Any standard processes should be referenced here and in the references section -->

<!-- NEW PAGE --> 
{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1=&nbsp;
|RefV1=&nbsp;
|RefDate1=&nbsp;
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]
[[Category:{{#var:SystemCode}}]]