FS 312147 Service Report Formats

From Calidus HUB





Aptean Logo.png







Lanemark

Service Report Formats

CALIDUS eSERV

4th October 2013 - 0.2
Reference: FS 312147 309371-15











































Functional Overview

Client Requirement

Create service reports for the different Lanemark ranges. Create Risk Assessment forms. Create Test Results forms.

Solution Overview

Service reports can be run against completed jobs. Initially, these will be run from the Admin system and saved to disk, to be stored within the customer's Document Management System.

Note Note: The product is being modified at this time to provide an automatic export of these Service Reports to a defined file-system or FTP server - it is expected that this will be used when available to automatically produce these Service Reports in PDF form in a specific folder with a defined naming convention. It should also be noted that this process could then be modified further (as part of a later phase) to export to specific sub-folders.

There is 1 Risk Assessment format and 4 Service Report formats.

These formats are not based on configuration against the Job Group (other than to choose Lanemark's format) - they are based on the serviceable product type (Range), which should be entered against the service records.

Note Note: As only the Test Results section varies, the customer has agreed that one consolidated format should be used for the electronic format, spanning multiple pages:

  • Page 1 - The Risk Assessment (always produced)
  • Page 2 - The Service Report consolidated format (always produced)
  • Page 3 - The specific Test results, based on the service item being tested (if the item was not cancelled). This will be based on the Product Group selected against the Serviceable Item.

The pages will be printed per Serviceable Item on the Service Job.

Note Note: With all these formats, "Sheet X of Y" is no longer necessary.

All service report formats will be presented in Portrait orientation.

All service report formats feature the sections containing the same data, detailed here:

  • Service Job number - Job Code
  • Customer Name and Site Address - from the Customer/Job Address information
  • Customer Reference No - Customer Reference
  • Site Name - Placed in Owner Name
  • Site Reference Number - External Reference
  • Customer Order No - Sales Order Number
  • Site Contact Name - from the Customer/Job Address information
  • Site Contact Tel. Number - from the Customer/Job Address information
  • Burner Model - System Type.
  • Burner Serial No - Code 1
  • Lanemark Service Item Number - Service ID. Entered by Admin.
  • Application - User-defined variable (UDF) data.
  • Location On Site - User-defined variable (UDF) data.
  • Reason For Site Visit - Service Type
  • Office Instruction - Office or Job Instructions
  • Details of Parts/Materials Used During Visit:
    • Part Number - Service Product identified by user - blank if this is a new 'Other' product
    • Description - Service Product Description or Other description
    • Quantity - Quantity entered by user.
  • Engineer Visit Comments - Diagnosis Narrative entered by user
  • Revisit Required - Flag for entry against Service
  • Follow Up Required - Flag for entry against Service
  • Site Contact Name - Signatory entered by Engineer (defaulted from Customer Contact)
  • Site Contact Signature - Customer Signature
  • Service Engineer Name - User Name from Log-on
  • Service Engineer Signature - Engineer Signature.
  • Is Burner System Safe For Use - Flag for entry against Service.
  • Travel Time
    • Day - Day name from Date below
    • Date - Arrival Date
    • Start Time - Arrival Time
    • Finish Time - Actual End Time

The Test Results section of the various forms differ - this data will be taken from the configurable fields data against the different product groups:

  • TX/TRX/MTX
  • DB
  • FD/FDB
  • Non-Lanemark

Each will be configurable with the post-work Test Results that are required.

Scope

  • These changes will be made in the latest version of the CALIDUS eSERV product only.
  • The changes will be made to the Android eSERV client only.


Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Admin

In the Job screen (job_details.aspx), the Report button will call the new Lanemark.aspx report for each serviceable item under the Service Job, by passing in the Site and Job ID only as the parameters.

In the Services screen (service_job.aspx), the Report button will produce the report only for the serviceable item selected, by passing in the Site, Job ID and Service ID.

The Job Group and Site screens (job_group.aspx and site_header.aspx respectively) will be modified to allow the system to be configured for the new Lanemark Service report, by adding this as an option to the DDLs in the editing pop-up forms. Additionally, the grid will be modified to display this correctly if selected.

Service Report Format

The report to be produced are heavily based around the existing reports, but have been consolidated into one format, adapting some of the page formats to allow for slight changes to the entered data, or to allow for a better electronic format.

The report will be called Lanemark.aspx.

The existing formats can be seen in Appendix A.

The reports will be broken down into 3 pages per serviceable item:

  • Risk Assessment
  • Service Report
  • Test Results

Prototypes of the pages are available, to aid in coding the final reports.

Note Note: The latter pages will only be produced if the Risk Assessment passed (i.e. the serviceable item was not cancelled, EPOD_SERVICE.EPL_STATUS != "X").


Risk Assessment Page

This page will be produced for all serviceable items, regardless of status.

The page will be made up of several sections:

  • Header, comprising the Logo, and Job and Service-level details.
  • Details, comprising the Risk Assessment and Results
  • Footer, comprising the signatures and page footer logos.

The data items on the page will be populated as follows:

  • Header
    • Site - EPL_CUSTOMER_NAME
    • Service Job - EPL_JOB_CODE
    • Service Item - EPL_SERVICE_ID
    • Date - EPL_ACTUAL_START_DATE
    • Person On Site Responsible For Your Safety - EPL_UDF_PREWORK.PERSON
    • Brief Description of Work to be Done - EPL_UDF_PREWORK.DESCRIPTION
  • Details
    • Identify the Hazards... - EPL_UDF_PREWORK.HAZARDS
    • Other (Please Specify) - EPL_UDF_PREWORK.HAZARDS_OTHER
    • Overall Assessment of Risk - EPL_UDF_PREWORK.RISK_ASSESSMENT
    • Measures to be taken - EPL_UDF_PREWORK.RISK_CONTROL and RISK_CONTROL_OTHER
    • Risk Accepted - EPL_UDF_PREWORK.CONFIRM attribute
  • Footer
    • Engineer Print - EPL_USER_NAME
    • Engineer Sign - EPL_ENG_SIGNATURE
    • Customer Print - EPL_CUST_SIGNATORY (if the serviceable item is not cancelled status)
    • Customer Sign - EPL_SIGNATURE (if the serviceable item is not cancelled status)

Note Note: A service ID has been added to this page, for visibility.


In the details section, 1 row will be added to a table per FIELD tag in the FORM tag. The format of the fields will be as follows:

  • Each row will be 100% width, with a solid border.
  • Each DDL, Boolean, Numeric or Text FIELD will result in the LABEL being displayed (with a trailing colon, if one is not already in the text), followed immediately by user-entered data (VALUE).
  • Each Option will result in the tale row being populated with the the LABEL being displayed (with a trailing colon, if one is not already in the text), followed by a table of each ITEM, up to a maximum of three columns, displayed vertically.


This "option" code should be written generically, allowing re-use.

The function should accept parameters of the number of columns (p_lngNumCols), and whether the columns should be populated vertically or horizontally (p_strLayout).

For Vertical layout, get a count of the number of items, divide by the total columns, to give the number of rows. If there is a remainder, add another row. Create the rows in advance in an array. For each ITEM found, append a TD element with a check box (labelled with the LABEL tag and checked if the VALUE tag indicated so) to each row element until the maximum rows is reached, then return to the top.

For Horizontal layout, add the TD and check box to each row until you reach the number of columns, then close the row and move to the next.

Each "option" column's (TD) width percentage should be set using the style attribute to evenly distribute the space on the resulting page - any remaining width unallocated should be added to the final column.

The process should return the generated HTML for the label and table rows.


The elements taken from the EPL_UDF_PREWORK element will be specifically selected by the ID attribute and used on the indicated position on this form. Note Note: If the UDF fields change (with the exception of the check-boxes for Hazards and Risk Control), this form will not reflect this and the Service Report Format will require further changes.

A sample layout follows:

FS 312147 1.PNG
Risk Assessment Page

The Hazards section will be displayed by taking all the items from the HAZARDS ID UDF element and producing Check-box fields for each item, checked or unchecked based on the returned value. There will be 3 cells per row, with the number of rows being defined as the amount required to display all the checks.

The Control Measures section has been changed to allow the user to check a number of predefined control measures. These will be displayed as Check-boxes in the same way as the Hazards section.

The Overall Assessment of Risk has now been changed to a simple label display of the risk selected by the user.

The Risk Accepted has been changed to a simple label display, based on the value of the CONFIRM attribute to the Risk Assessment checks. If the user confirmed the checks (and therefore entered all values), this would be C, and therefore the value should be "Yes". If the value is "X", the user has confirmed that there was a Method Statement produced, and therefore the Risk Assessment is not required - the value should be Yes, but a label should be added under this one, stating "METHOD STATEMENT PRODUCED".

Service Report Page

The Service Report page has been formatted taking the common elements of the three available reports and removing the Test Results to a separate page.

This page will be produced for all serviceable items, if the service was completed (i.e. not cancelled).

The page will be made up of several sections:

  • Header, comprising the Job and Service-level details and engineer-entered Info.
  • Details, comprising the Products Used in the service.
  • Footer, comprising the signatures and times, and engineer-entered Diagnosis Check-boxes.

The data items on the page will be populated as follows:

  • Header
    • Service Job number - EPL_JOB_CODE
    • Customer Name and Site Address - from the Customer/Job Address information (EPOD_CUSTOMER or EPOD_JOB_ADDRESS, using fields EPL_NAME, EPL_ADDRESS_LINE_1/2/3/4/5, EPL_POST_CODE).
    • Customer Reference No - EPL_CUST_REF
    • Site Name - EPL_OWNER_NAME
    • Site Reference Number - EPL_EXT_REF
    • Customer Order No - EPL_SO_NUMBER
    • Site Contact Name - from the Customer/Job Address information (EPL_CONTACT)
    • Site Contact Tel. Number - from the Customer/Job Address information (EPL_PHONE)
    • Burner Model - EPL_SYSTEM_TYPE
    • Burner Serial No - EPL_CODE_1
    • Lanemark Service Item Number - EPL_SERVICE_ID
    • Application - EPL_UDF_INFO.APPLICATION
    • Location On Site - EPL_UDF_INFO.LOCATION
    • Reason For Site Visit - EPL_SERVICE_TYPE
    • Office Instruction - EPL_OFFICE_INSTRUCTIONS if present, else EPL_JOB_INSTRUCTIONS
    • Engineer Visit Comments - EPL_DIAGNOSIS_NARRATIVE
  • Details - from EPOD_SERVICE_PRODUCTS
    • PART NUMBER - EPL_PRODUCT_CODE
    • DESCRIPTION - EPL_DESCRIPTION if non-blank, or from EPOD_SERVICE_PRODUCT_MASTER
    • QTY - EPL_QUANTITY
  • Footer
    • Revisit Required - EPL_CHECK_1
    • Follow Up Required - EPL_CHECK_2
    • Service Engineer Name - EPL_USER_NAME
    • Service Engineer Signature - EPL_ENG_SIGNATURE
    • Site Contact Name - EPL_CUST_SIGNATORY
    • Site Contact Signature - EPL_SIGNATURE
    • Day of Week - Day Name from EPL_ARRIVAL_DATE
    • Date - EPL_ARRIVAL_DATE
    • Start - EPL_ARRIVAL_TIME
    • Finish - EPL_ACTUAL_END_DATE
    • Is Burner Safe for Use - EPL_CHECK_3

A sample layout follows:

FS 312147 2.PNG
Service Report Page

The Details section should display at least 5 lines, even if there are no products used. The table should be extended to show all lines if there are more than 5.


Test Results Page

The Service Report page has been formatted taking the common elements of the three available reports and removing the Test Results to a separate page.

This page will be produced for all serviceable items, if the service was completed (i.e. not cancelled).

The page will be made up of several sections:

  • Header, comprising the Job and Service-level details and engineer-entered Info.
  • Details, comprising the Products Used in the service.
  • Footer, comprising the signatures and times, and engineer-entered Diagnosis Check-boxes.

The data items on the page will be populated as follows:

  • Header
    • Site - EPL_CUSTOMER_NAME
    • Service Job - EPL_JOB_CODE
    • Service Item - EPL_SERVICE_ID
    • Date - EPL_ACTUAL_START_DATE
  • Details - a table made up of the individual test results from EPL_UDF_POSTWORK. See later for details.
  • Footer
    • Service Engineer Name - EPL_USER_NAME
    • Service Engineer Signature - EPL_ENG_SIGNATURE

The details section is made of title rows and data rows, built as follows: 

    <table class="header" style="white-space: nowrap;">
    <!-- HEADER ROW -->
    <tr><td class="cell">
        REF
    </td><td colspan="2" class="cell">
        TEST RESULTS
    </td><td colspan="{title_span}" class="cell">
        {group_titles} 
    </td></tr>
    <!-- RESULT ROW - one per field or link chain -->
    <tr><td class="cell">
        {counter}
    </td><td class="cell">
        {EPL_UDF_POSTWORK.TEXT}
    </td><td colspan="{subtext_span}" class="cell">
        {EPL_UDF_POSTWORK.SUBTEXT}
    </td>{value_cells}</tr>
    </table>
  • Linked fields are defined as a field that has a LINK attribute that refers to the ID or the LINK attribute of the FIELD immediately before it. If this chain is broken (by an unlinked field or a field that does not link to the original field ID or LINK attribute), a new row will start.
  • chain - any number of fields linked together.
  • title_span - 2 plus {max_link_items}
  • max_chain_items - the maximum number of fields in any {chain} in the UDF as a whole on any line.
  • chain_items - the number of fields in this {chain}.
  • group_titles - for each grouped element, the text of this GROUP attribute here. If this text does not equal the text of the title field in the same position of the group_titles, then a new title row should be inserted here, replacing the titles with the new one here. This new title row should be inserted before the current row being built.
  • counter - A count incrementing for every row (i.e. for every unlinked field or {chain}).
  • subtext_span - {max_chain_items} minus {chain_items}.
  • value_cells - a cell for each field's VALUE and POST tags. The cell should be made up as follows:
    <td class="cell">
        {EPL_UDF_POSTWORK.VALUE} {EPL_UDF_POSTWORK.POST}
    </td>
  • group_titles - for each grouped element, the text of this GROUP attribute goes into a cell here. If this text does not equal the text of the title field in the same position of the group_titles, then a new title row should be inserted here, replacing the titles with the new one here. This new title row should be inserted before the current row being built. The group title cells should be built as follows:
    <td class="cell">
        {group_title} 
    </td>

No limit is placed on the number of fields that can be tested per page - all will display on one page.

A sample layout follows:

FS 312147 3.PNG
Test Results Page

Appendix A: REPORT FORMATS

Service Report - TX/TRX/MTX

Note Note: This format is similar to the non-Lanemark Service Report - the only difference is in the Test Results section, which will be printed as a separate page.

REQ 309187 SR3.jpg

Service Report - DB

REQ 309187 SR2.jpg

Service Report - FD/FDB

REQ 309187 SR1.jpg

Engineer Site Risk Assessment

REQ 309187 RISK.jpg

Appendix B: TEST PLAN

Test Script / Scenario ReferenceService Report FormatsCall Number(s): 312147 309371-15
Test Script / Scenario DescriptionTo test Lanemark Service ReportsPASS / ISSUES / FAIL
Menu AccessServices 
Pre-requisitesEnsure there are completed single- and multiple-item jobs (with some cancelled items and cancelled risk assessments) to check, of all different product types.Tested By:
 
Test ObjectiveTo test that: Multiple-page documents are produced in the right formats, one for each Serviceable Item.Date:
 


Step Action Result Remarks P/F
1 Admin      
       
1.01 Run the report for a single serviceable item The report should show 3 pages (Risk Assessment, Service Report, Test Results).    
1.02 Run the report for a service with multiple serviceable items, one of each type. The report should show 3 pages (Risk Assessment, Service Report, Test Results) per serviceable item. The Test Results page should show different results for each serviceable item. The test results should be formatted as required.    
1.03 Run the report for a service with multiple serviceable items, one of which has had Risk Assessments cancelled. The report should show 3 pages (Risk Assessment, Service Report, Test Results) per serviceable item. The Risk Assessment page for the item with the cancelled Risk Assessment should show "METHOD STATEMENT PRODUCED"    
1.04 Run the report for a service with multiple serviceable items, one of which was cancelled. The report should show 3 pages (Risk Assessment, Service Report, Test Results) per completed serviceable item. The cancelled item should show only the Risk Assessment page.    


Appendix C: Quote & Document References

Cost Details
Activity No. of Days Rate per Day (£) Cost (£ Exc. VAT)
Requirements 0.00 0 £0.00
Change Request Evaluation 0.00 0 £0.00
Functional Specification 1.00 0 £0.00
Technical Specification 0.00 0 £0.00
Development 3.75 0 £0.00
Testing and Release 0.25 0 £0.00
Implementation 0.00 0 £0.00
Project Management First argument to "number_format" must be a number. 0 £First argument to "number_format" must be a number.
 
TOTAL First argument to "number_format" must be a number.   £First argument to "number_format" must be a number.
Estimate excludes training, release to live and go live support.

C.1 References

Ref NoDocument Title & IDVersionDate
1UG 291094 EPOD Admin User Guide2.04/4/2012
2UG 291097 EPOD Client User Guide3.023/4/2013
3REQ 309371 Lanemark eSERV Requirements0.429/08/2013


C.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.


C.3 Authorised By


Julie Taylor
OBS Project Manager		_____________________________

Jeff Foster
Client Representative		_____________________________

Alan Thompson
Client Representative		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_312147_Service_Report_Formats&oldid=1270’