FS 311636 UDF Modifications

From Calidus HUB
Revision as of 17:56, 2 September 2013 by Anw (talk | contribs) (v0.1 - Initial Creation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)





Aptean Logo.png







Lanemark

UDF Modifications

CALIDUS eSERV

2nd September 2013 - 0.1
Reference: FS 311636 309371-1











































Functional Overview

Client Requirement

Allow user-defined variable field entry against Services processing of Pre-work, Post-work, Info and Diagnosis. This should be configurable against Site, Job Group and Product Group, in this sequence.

Solution Overview

A new User-defined Field (UDF) configuration table will be added, to allow UDF configuration.

This configuration will be through a defined XML format, similar to the existing Vehicle Checks configuration.

The configurations will be passed through to the PDA client for storage. This client will also be modified to read these configurations and store them for use at points during the Service processing.

The configuration will be applied to a particular key type, as follows:

  • Product Group
  • Job Group
  • Site

The order of these is important, as the settings are hierarchical. In other words, if a setting for a particular process exists against as Product Group, this would be used in preference to one created for the same process against the Job Group or Site.

The configuration will be marked as being of a particular type, as follows:

  • Info
  • Diagnosis
  • Pre-check
  • Post-check

If a configuration exists for a particular process, the fields contained within it will be added to the existing Service tab. The validation of the Service will be modified to ensure that any required fields have been entered.

A generic UDF type will be added to the project, to allow the creation and validation of UDF fields. This will include:

  • Create a sizeable, scrollable entry frame
  • Display Labels
  • Display Post-labels (e.g. UOMs)
  • Validate entry (optional or required entry against individual fields)
  • Allow entry of different Field Types, such as:
    • DDL (Drop-down List)
    • Text entry (plus barcode)
    • Numeric entry (plus barcode)
    • Option entry
    • Check Field Group entry
  • Produce Results in a pre-defined XML format

In a second phase, a new Admin Maintenance screen will be created for maintaining these UDF configurations. This will include the abilities to:

  • Create a new configuration
  • Specify button names and types of validation required
  • Add or modify variable fields to be entered, including such elements as:
    • Labels
    • Post-labels (e.g. UOMs)
    • Validation (optional or required entry)
    • Field Types, such as:
      • DDL (Drop-down List)
      • Text entry
      • Numeric entry
      • Option entry
      • Check Field Group entry
  • Delete fields.
  • Change the sequence of fields.

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.
  • Note Note: This solution combines a number of the generic UDF requirements and the Lanemark-specific requirements into one document, for clarity. Some of these elements have already been completed, some are being completed as Product Enhancements, and some are completed as bespoke additions required for the Lanemark process.
  • Note Note: Although there is some description of an Admin screen, this is NOT included in the estimates provided in this specification - this will be completed at a later data through Product enhancements.


Set-up

Pre-requisites

Menu Structure

Data

Functional Description

Database and DAL

A new table will be created, EPOD_UDF_CONFIG, as follows:

  • EPL_CONFIG_ID - long numeric, auto-incrementing.
  • EPL_DESCRIPTION - nvarchar(50), required not-null.
  • EPL_UDF_FIELDS - nvarchar(max), required not-null
  • EPL_KEY_TYPE - nvarchar(10), required not-null.
  • EPL_KEY_VAL - nvarchar(50), required not-null.
  • EPL_CONFIG_TYPE - nvarchar(50), required not-null.
  • EPL_LAST_CHANGED_DATE - long numeric, required not-null.
  • EPL_LAST_CHANGED_TIME - long numeric, required not-null.

Indexes and Keys:

  • Primary Index: EPL_CONFIG_ID
  • Unique Alternate: EPL_KEY_TYPE, EPL_KEY_VAL, EPL_CONFIG_TYPE

A DAL object (EPOD_UDF_CONFIG) will be created to allow the creation, deletion and amendment of records on this table. This will required packages to be created for this object, including (but not limited to):

  • EPOD_UDF_CONFIG_INSERT
  • EPOD_UDF_CONFIG_SELECT
  • EPOD_UDF_CONFIG_UPDATE

The object will allow all standard functions (for examples, see any existing simple DAL object, like EPOD_REASON_CODES). The object must allow exporting of Configuration data as XML.

The existing EPOD_SERVICES table will be modified to add new fields as follows:

  • EPL_UDF_INFO - nvarchar(max)
  • EPL_UDF_DIAGNOSIS - nvarchar(max)
  • EPL_UDF_PREWORK - nvarchar(max)
  • EPL_UDF_POSTWORK - nvarchar(max)

Existing packages will be modified to allow the creating, editing and selecting of the new fields, including but not limited to:

  • EPOD_SERVICE_INSERT
  • EPOD_SERVICE_JOB_SEARCH
  • EPOD_SERVICE_JOB_SELECT
  • EPOD_SERVICE_SELECT
  • EPOD_SERVICE_UPDATE

The existing EPOD_SERVICE/SERVICE_JOB DAL object will be changed to:

  • Export the new fields in XML requests
  • Read the new fields

Note Note: It is not necessary to add this flag as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.

Server

The LOGIN_RESPONSE message sent when processing a LOGIN_REQUEST message (through the calidus_epod.asmx web service) will be modified to add a new section, detailing ONLY the EPOD_CONFIG records found that have changed since the last update. An XML Structure sample follows: 

<EPOD_CONFIGS>
  <EPOD_CONFIG>
    <EPL_CONFIG_ID></EPL_CONFIG_ID>
    <EPL_DESCRIPTION></EPL_DESCRIPTION>
    <EPL_UDF_FIELDS></EPL_UDF_FIELDS>
    <EPL_KEY_TYPE></EPL_KEY_TYPE>
    <EPL_KEY_VAL></EPL_KEY_VAL>
    <EPL_CONFIG_TYPE></EPL_CONFIG_TYPE>
    <EPL_LAST_CHANGED_DATE></EPL_LAST_CHANGED_DATE>
    <EPL_LAST_CHANGED_TIME></EPL_LAST_CHANGED_TIME>
  </EPOD_CONFIG>
</EPOD_CONFIGS>

This section will be added after all existing sections.

Admin

Note Note: This is a phase 2 deliverable item - for phase 1, all administration of UDF configuration items will be through the database and will be directly administered by OBS support or implementation staff.

Warning Warning: Screen designed here.

Android Client

The database will be modified to add the new table EPOD_UDF_CONFIG.

The Webservices.LOGON_RESPONSE processing function will be modified to add all new EPOD_UDF_CONFIG messages.

Note Note: The function should be written not to delete all items, but just to add or update items.

A new DAL object will be added, called PDA_UDF_CONFIG. This will include all the options required to maintain the EPOD_UDF_CONFIG table, using:

  • Update
  • Add
  • Delete

There will also be global functions to process additions and updates to the table through logon, as follows:

  • InsertAllUDFConfigs
  • InsertUDFConfig

The format and functions required should be copied from an existing PDA DAL object, for example PDA_REASON_CODES.

The DAL object should include an ability to get the configuration matching certain Job configurations. So, a function is required to return a single EPOD_CONFIG item, when passed in the following parameters:

  • EPL_CONFIG_TYPE (required)
  • EPL_SITE_ID (required)
  • EPL_JOB_GROUP
  • EPL_PRODUCT_GROUP

The function should retrieve all records found for the Config Type required, matching against the key elements provided. Note Note: Any null or blank optional parameters should be ignored when fetching UDF Configurations. All would be sorted so that the hierarchy below is followed:

  • Product Group - 1
  • Job Group - 2
  • Site - 3

The highest available configuration in the hierarchy will be returned as a PDA_UDF_GROUP object. If one is not found, null will be returned.

The suggested name for this function is GetUDFConfig.

Example:

If the following parameters are provided:

  • EPL_CONFIG_TYPE - "INFO"
  • EPL_SITE_ID - "TEST"
  • EPL_JOB_GROUP - "JG01"
  • EPL_PRODUCT_GROUP - "PG01"

The procedure should fetch all configurations for key elements as follows:

  • EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "SITE" and EPL_KEY_VALUE = "TEST"
  • EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "JOB_GROUP" and EPL_KEY_VALUE = "JG01"
  • EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "PROD_GROUP" and EPL_KEY_VALUE = "PG01"

The lowest hierarchical record found will be returned, in this case, the Product Group record, as a DAL object.


A generic UDF object will be used in the project, in Style.js, to allow the creation and validation of UDF fields. This will:

  • Create a sizeable, scrollable entry frame
  • Display Labels
  • Display Post-labels (e.g. UOMs)
  • Validate entry (optional or required entry against individual fields)
  • Allow entry of different Field Types, such as:
    • DDL (Drop-down List)
    • Text entry (plus barcode)
    • Numeric entry (plus barcode)
    • Option entry
    • Check Field Group entry
  • Produce Results in a pre-defined XML format

Note Note: An object has already been written to do this, utilising Titanium Tables, and is used in Vehicle Checks. This object should be modified to allow the additional functionality specified above, whilst maintaining compatibility with the Vehicle Checks functionality.

The fields shown in the object itself are subject to a configuration XML string, which will be found in the new UDF_CONFIG table.

The existing configuration conforms to the following XSD (for vehicle checks): 

<xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <xsd:element name="VEHICLE_CHECK">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element maxOccurs="unbounded" name="QUESTION">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="TEXT" type="xsd:string" />
               <xsd:element name="FORMAT" nillable="false">
                 <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="X"/>
                     <xsd:enumeration value="N"/>
                     <xsd:enumeration value="T"/>
                     <xsd:enumeration value="B"/>
                   </xsd:restriction>
                 </xsd:simpleType>
               </xsd:element>
               <xsd:element name="SKIPABLE" nillable="false">
                 <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="Y"/>
                     <xsd:enumeration value="N"/>
                   </xsd:restriction>
                 </xsd:simpleType>
               </xsd:element>
               <xsd:element minOccurs="0" nillable="true" name="ANSWER" type="xsd:string" />
               <xsd:element minOccurs="0" name="ITEMS">
                 <xsd:complexType>
                   <xsd:sequence>
                     <xsd:element maxOccurs="unbounded" name="ITEM" type="xsd:string" />
                   </xsd:sequence>
                 </xsd:complexType>
               </xsd:element>
             </xsd:sequence>
             <xsd:attribute name="ID">
               <xsd:simpleType>
                 <xsd:restriction base="xsd:string">
                   <xsd:maxLength value="10" />
                 </xsd:restriction>
               </xsd:simpleType>
             </xsd:attribute>
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
       <xsd:attribute name="FREQ" type="xsd:int" />
     </xsd:complexType>
   </xsd:element>
</xsd:schema>

This has been amended for UDF to: 

 <xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <xsd:element name="FORM">
     <xsd:complexType>
       <xsd:sequence>
         <xsd:element maxOccurs="unbounded" name="FIELD">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="TEXT" type="xsd:string" />
               <xsd:element name="TEXT2" type="xsd:string" />
               <xsd:element name="POST" type="xsd:string" />
               <xsd:element name="FORMAT" nillable="false">
                 <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="X"/>
                     <xsd:enumeration value="N"/>
                     <xsd:enumeration value="T"/>
                     <xsd:enumeration value="B"/>
                     <xsd:enumeration value="DDL"/>
                   </xsd:restriction>
                 </xsd:simpleType>
               </xsd:element>
               <xsd:element name="SKIPABLE" nillable="false">
                 <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="Y"/>
                     <xsd:enumeration value="N"/>
                   </xsd:restriction>
                 </xsd:simpleType>
               </xsd:element>
               <xsd:element minOccurs="0" nillable="true" name="VALUE" type="xsd:string" />
               <xsd:element minOccurs="0" name="ITEMS">
                 <xsd:complexType>
                   <xsd:sequence>
                     <xsd:element maxOccurs="unbounded" name="ITEM" type="xsd:string" />
                   </xsd:sequence>
                 </xsd:complexType>
               </xsd:element>
             </xsd:sequence>
             <xsd:attribute name="ID">
               <xsd:simpleType>
                 <xsd:restriction base="xsd:string">
                   <xsd:maxLength value="10" />
                 </xsd:restriction>
               </xsd:simpleType>
             </xsd:attribute>
           </xsd:complexType>
         </xsd:element>
         <xsd:element maxOccurs="unbounded" name="BUTTON">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="TYPE" nillable="false">
                 <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                     <xsd:enumeration value="C"/>
                     <xsd:enumeration value="R"/>
                     <xsd:enumeration value="X"/>
                   </xsd:restriction>
                 </xsd:simpleType>
               </xsd:element>
               <xsd:element name="TEXT" type="xsd:string" />
             </xsd:sequence>
             <xsd:attribute name="CONFIRM" type="xsd:string" />
           </xsd:complexType>
         </xsd:element>
       </xsd:sequence>
       <xsd:attribute name="NAME" type="xsd:string" />
       <xsd:attribute name="REQUIRED" type="xsd:string" />
       <xsd:attribute name="STATUS" type="xsd:string" />
     </xsd:complexType>
   </xsd:element>
</xsd:schema>

Note Note: Notes:

  • New elements have been added to the FIELD element:
  • TEXT if the main label. TEXT2 is a sub-label, that should be under the main label. Post is a small 'UOM' label that, if present, should be placed after the text entry item. As the current system allows for only one label and one item, this will require a restructure of the layout of the view containing these elements.
  • The new element BUTTON controls what buttons are on the form:
    • TEXT - the label on the button
    • TYPE - the type of button:
      • C - Confirm
      • R - Reject
      • X - Cancel
    • CONFIRM - if present, a confirmation message to be displayed, requiring the user to confirm that they confirm the action, with a Yes/No prompt.
  • NAME attribute - a label for any button calling this form, and for a label on the top of the form.
  • REQUIRED attribute - whether the user must confirm to be allowed to continue.
  • STATUS attribute - Set to the Status of the Button that was pressed. Note that this attribute should be a property of the new Object that is created, to allow easy checking of the status.

These new attribute items apply to the object that calls the UDF form, whereas the buttons apply to the object itself.

Note Note: See existing test code in Pre- and Post-work checks in Services for information as to how this object works in its original form, and guidance as to how this will change applying the changes in this specification.

Note Note: If a new UDF object is written, it should be written without the use of the Titanium tables, as these are notoriously memory-hungry - instead, use multiple Views in a vertical layout, as can be seen in Signature Container list.

The layout of the fields will change with the new labels, as follows:

  • The original label field will become height: 66%.
  • The original entry items will become height: 66%.
  • A new label item will be added at top: 67%, height: 33%, left: 1%, align: right for the Text2 text if it exists.
  • A new label item will be added at top: 67%, height: 33%, right: 1%, align: right for the Post text if it exists.

Warning Warning: Need to include Referenced item here - through ID, doesn't have to be unique. If ID is the same on two items after each other, omit the TEXT.

An example of how this may look for each combination is below:

FS 311636 1.PNG

Appendix A: TEST PLAN

Test Script / Scenario ReferenceUDF ModificationsCall Number(s): 311636 309371-1
Test Script / Scenario DescriptionTo test the entry and visibility of the additional check box fields in CALIDUS eSERVPASS / ISSUES / FAIL
Menu AccessServices 
Pre-requisitesNoneTested By:
 
Test ObjectiveTo test that: Services configured for Lanemark allow entry of additional checkboxes, labelled as required; existing Services functionality remains unaffected.Date:
 


Step Action Result Remarks P/F
1 Admin      
       
1.01 Check Site and Job Group screens, that the Lanemark option can be chosen against 'Diagnosis', saved and edited. The value can be selected, EPL_SERVICE_DIAGNOSIS is saved correctly and is editable.    


Step Action Result Remarks P/F
2 PDA Services      
  Ensure that the EPOD_JOB_GROUP flag EPL_SERVICE_DIAGNOSIS is set to "L". Create a service job and assign to a PDA user.      
2.01 Logon to the PDA start a service and move to the Diagnosis tab. The only fields available for entry are the three new fields and Diagnosis Narrative. The three new checkboxes are labelled as required.    
2.02 Set or unset the checkboxes and complete the service. The values are saved as Y or N in the EPOD database.    


Step Action Result Remarks P/F
3 Admin (post)      
       
3.01 Check the Job in Admin Services and Jobs screen, showing the details. The job should be completed. The details should show only the fields required by the set-up (i.e. the Diagnosis Narrative and the new Check Boxes). They should be labelled correctly.    


Step Action Result Remarks P/F
4 Regression tests      
       
4.01 Set the value of the EPOD_JOB_GROUP flag EPL_SERVICE_DIAGNOSIS is set to other values ("A", "N", "Y"). Repeat the tests above to ensure that the system operated as it should under the other configurations. As required by the other configurations.    


Appendix B: 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 3.00 0 £0.00
Technical Specification 0.00 0 £0.00
Development 10.75 0 £0.00
Testing and Release 2.00 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.

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


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


B.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_311636_UDF_Modifications&oldid=1181’