REQ 356284 Changes to On-time Report
MASH Purveyors
Changes to On-time Report
CALIDUS ePOD
11th March 2019 - 1.0
Reference: REQ 356284
Contents
Introduction
This document relates to Changes to On-time Report.
Objective
The primary purpose of this document is to document the requirements gathered from MASH Purveyors regarding changes required to the On-time Report (previously known as the OTIF report).
This document has been written in a manner such that it can be approved by non-technical representatives of MASH Purveyors 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 MASH Purveyors in emails and points clarified and confirmed in subsequent emails.
- The changes will be made in the latest version of the CALIDUS ePOD system.
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>
Appendix A: Document References
A.1 References
Ref No | Document Title & ID | Version | Date |
1 |
A.2 Glossary
Term | Definition |
---|---|
EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
A.3 Authorised By
Barry Preece | OBS Project Manager | _____________________________ |