FS 311636 UDF Modifications: Difference between revisions

From Calidus HUB
VisualWikitext
(Added sample UDF XML file.)
(v0.2 - Added Admin section and how the UDF details are to fit in the Service process.)
Line 4: Line 4:
{{#vardefine:System|''CALIDUS'' eSERV}}
{{#vardefine:System|''CALIDUS'' eSERV}}
{{#vardefine:Doc_Title|UDF Modifications}}
{{#vardefine:Doc_Title|UDF Modifications}}
{{#vardefine:Version|0.1}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|2nd September 2013}}
{{#vardefine:Date|4th September 2013}}
{{#vardefine:Reference|311636 309371-1}}
{{#vardefine:Reference|311636 309371-1}}
{{#vardefine:Year|2013}}
{{#vardefine:Year|2013}}
Line 149: Line 149:
{{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.
{{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}} Screen designed here.
A new menu item will be added to the main menu, on sub-menu ''Administration'', labelled as ''UDF Config''.
 
This screen will allow a user to add, search for and edit UDF configurations in the system.
 
This screen will work in all ways like the rest of the Admin screens in that:
* The screen will start empty.
* A '''Find''' and '''New''' button will be provided.
* Clicking the '''Find''' button will display a search criteria box, allowing the user to:
** Enter search criteria of Description and/or Type.
** A '''Clear''' button (to clear search criteria) and a '''Search''' button (to execute the search).
* Clicking the '''New''' button will display a pop-up window to enter new config details.
* Clicking the '''Search''' button will find all matching records, which will be displayed in a grid showing:
** Description
** Key Type
** Key Value
** A '''Select''' button.
* Clicking the '''Select''' button will display a pop-up window to exit the configuration.
 
The pop-up window will allow the user to enter:
* UDF Config section - all items required entry:
** Description - A required description of the configuration being created.
** Key Type - the level at which this is being created. Currently one of:
*** Site
*** Job Group
*** Product Group
** Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.
{{Note}} Changing the Key Type should blank the Key Value and require the value to be entered again.
 
* Form section:
** Name - The title of the form or button that calls the form.
** Required - future development.
 
* Field List:
** Field List - A list of all fields created on the form, in sequence, showing the ID and the Label.
** Top/Up/Down/Bottom Buttons - to change the selected field's sequence.
** '''Add Field''' button - to add a new field.
 
* Field Detail - shown when a field is selected from a list, or a new field is requested through the '''Add Field''' button, showing:
** ID - An ID for the field. This is required entry. Up to 30 characters may be entered, using only alphanumeric and the underscore character only.
** Label - A label displayed against the field when it is being entered on the device. There is no limit to the number of characters, but users should be made aware that excessively long labels will result in less-than-usable data entry on the device.
** Sub-Label - A smaller-font label under the main label when this field is being entered on the device.
** Post Text - a 6-character UOM to be displayed under the data being entered, in a small font.
** Required - whether the field must be entered on the device.
** Type - a field type, which defines how data can be entered, and what Field Type Content must be defined. Can be:
*** Text - a free-text entry field.
*** Numeric - Numeric-only data
*** Options - a series of options grouped together, that may be checked or unchecked.
*** Check - a single-option check.
*** Drop-Down List - a list of options that drop down when it is clicked on - only one may be selected.
** '''Delete Field''' button - if clicked, this will delete the field from the list and blank the Field Detail section.
 
* Buttons section - there can be up to 2 buttons defined for a form, one shown on each tab, allowing the user to enter:
** Label - The label of the button displayed
** Type - The button type, one of:
*** Confirm - saves the data
*** Ignore - a back-out option
*** Cancel - A Postpone-style option
** Confirmation Dialogue - If this is entered, this will make the device display a confirmation dialogue with this text and Yes/No buttons, when the button is clicked.
 
* Field Type Content section - This section differs depending on the different Field Type:
** Text/Numeric/Check - this section should not be displayed.
** Options - a table of options (of name only) to be selected will be shown, allowing the user to add or delete options.
** Drop-down List - a table of options (with columns for Text, Value and a Default check box)) to be selected will be shown, allowing the user to add or delete options.
 
{{Note}} All options should have hover-help and appropriate validators attached to them.
 
The following is a prototype screen-shot of how the pop-up screen should look and act:
 
[[file:FS_311636_2.PNG|border|600px]]


== Android Client ==
== Android Client ==
Line 211: Line 279:


The existing configuration conforms to the following XSD (for vehicle checks):
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:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="VEHICLE_CHECK">
  <xsd:element name="FORM">
      <xsd:complexType>
    <xsd:complexType>
        <xsd:sequence>
      <xsd:sequence>
          <xsd:element maxOccurs="unbounded" name="QUESTION">
        <xsd:element maxOccurs="unbounded" name="FIELD">
            <xsd:complexType>
          <xsd:complexType>
              <xsd:sequence>
            <xsd:sequence>
                <xsd:element name="TEXT" type="xsd:string" />
              <xsd:element name="TEXT" type="xsd:string" minOccurs="0" maxOccurs="1" />
                <xsd:element name="FORMAT" nillable="false">
              <xsd:element name="SUBTEXT" type="xsd:string" minOccurs="0" maxOccurs="1"/>
                  <xsd:simpleType>
              <xsd:element name="POST" type="xsd:string" minOccurs="0" maxOccurs="1" />
                    <xsd:restriction base="xsd:string">
              <xsd:element name="FORMAT" nillable="false">
                      <xsd:enumeration value="X"/>
                <xsd:simpleType>
                      <xsd:enumeration value="N"/>
                  <xsd:restriction base="xsd:string">
                      <xsd:enumeration value="T"/>
                    <xsd:enumeration value="X"/>
                      <xsd:enumeration value="B"/>
                    <xsd:enumeration value="N"/>
                    </xsd:restriction>
                    <xsd:enumeration value="T"/>
                  </xsd:simpleType>
                    <xsd:enumeration value="B"/>
                </xsd:element>
                    <xsd:enumeration value="DDL"/>
                <xsd:element name="SKIPABLE" nillable="false">
                  </xsd:restriction>
                  <xsd:simpleType>
                </xsd:simpleType>
                    <xsd:restriction base="xsd:string">
              </xsd:element>
                      <xsd:enumeration value="Y"/>
              <xsd:element name="SKIPABLE" nillable="false">
                      <xsd:enumeration value="N"/>
                <xsd:simpleType>
                    </xsd:restriction>
                  <xsd:restriction base="xsd:string">
                  </xsd:simpleType>
                    <xsd:enumeration value="Y"/>
                </xsd:element>
                    <xsd:enumeration value="N"/>
                <xsd:element minOccurs="0" nillable="true" name="ANSWER" type="xsd:string" />
                  </xsd:restriction>
                <xsd:element minOccurs="0" name="ITEMS">
                </xsd:simpleType>
                  <xsd:complexType>
              </xsd:element>
                    <xsd:sequence>
              <xsd:element minOccurs="0" nillable="true" name="VALUE" type="xsd:string" />
                      <xsd:element maxOccurs="unbounded" name="ITEM" type="xsd:string" />
              <xsd:element minOccurs="0" name="ITEMS">
                    </xsd:sequence>
                <xsd:complexType>
                  </xsd:complexType>
                  <xsd:sequence>
                </xsd:element>
                    <xsd:element name="ITEM" maxOccurs="unbounded" minOccurs="0">
              </xsd:sequence>
                      <xsd:complexType>
              <xsd:attribute name="ID">
                        <xsd:simpleContent>
                <xsd:simpleType>
                          <xsd:extension base="xsd:string">
                  <xsd:restriction base="xsd:string">
                            <xsd:attribute type="xsd:string" name="CODE" use="optional"/>
                    <xsd:maxLength value="10" />
                            <xsd:attribute type="xsd:string" name="DEFAULT" use="optional"/>
                  </xsd:restriction>
                          </xsd:extension>
                </xsd:simpleType>
                        </xsd:simpleContent>
              </xsd:attribute>
                      </xsd:complexType>
            </xsd:complexType>
                     </xsd:element>
          </xsd:element>
                  </xsd:sequence>
        </xsd:sequence>
                </xsd:complexType>
        <xsd:attribute name="FREQ" type="xsd:int" />
              </xsd:element>
      </xsd:complexType>
            </xsd:sequence>
    </xsd:element>
            <xsd:attribute name="ID" use="required">
</xsd:schema>
              <xsd:simpleType>
This has been amended for UDF to:
                <xsd:restriction base="xsd:string">
  <xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
                  <xsd:maxLength value="10" />
    <xsd:element name="FORM">
                </xsd:restriction>
      <xsd:complexType>
              </xsd:simpleType>
        <xsd:sequence>
            </xsd:attribute>
          <xsd:element maxOccurs="unbounded" name="FIELD">
          </xsd:complexType>
            <xsd:complexType>
        </xsd:element>
              <xsd:sequence>
        <xsd:element maxOccurs="unbounded" name="BUTTON">
                <xsd:element name="TEXT" type="xsd:string" />
          <xsd:complexType>
                <xsd:element name="TEXT2" type="xsd:string" />
            <xsd:sequence>
                <xsd:element name="POST" type="xsd:string" />
              <xsd:element name="TYPE" nillable="false">
                <xsd:element name="FORMAT" nillable="false">
                <xsd:simpleType>
                  <xsd:simpleType>
                  <xsd:restriction base="xsd:string">
                    <xsd:restriction base="xsd:string">
                    <xsd:enumeration value="C"/>
                      <xsd:enumeration value="X"/>
                    <xsd:enumeration value="I"/>
                      <xsd:enumeration value="N"/>
                    <xsd:enumeration value="X"/>
                      <xsd:enumeration value="T"/>
                  </xsd:restriction>
                      <xsd:enumeration value="B"/>
                </xsd:simpleType>
                      <xsd:enumeration value="DDL"/>
              </xsd:element>
                    </xsd:restriction>
              <xsd:element name="TEXT" type="xsd:string" />
                  </xsd:simpleType>
            </xsd:sequence>
                </xsd:element>
            <xsd:attribute name="CONFIRM" type="xsd:string" use="optional" />
                <xsd:element name="SKIPABLE" nillable="false">
          </xsd:complexType>
                  <xsd:simpleType>
        </xsd:element>
                    <xsd:restriction base="xsd:string">
      </xsd:sequence>
                      <xsd:enumeration value="Y"/>
      <xsd:attribute name="NAME" type="xsd:string" use="optional" />
                      <xsd:enumeration value="N"/>
      <xsd:attribute name="REQUIRED" type="xsd:string" use="optional" />
                    </xsd:restriction>
      <xsd:attribute name="STATUS" type="xsd:string" use="optional" />
                  </xsd:simpleType>
    </xsd:complexType>
                </xsd:element>
  </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>
  </xsd:schema>


{{Note}} Notes:
{{Note}} Notes:
* New elements have been added to the FIELD element:
* 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.
* TEXT if the main label. SUBTEXT 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:
* The new element BUTTON controls what buttons are on the form:
** TEXT - the label on the button
** TEXT - the label on the button
** TYPE - the type of button:
** TYPE - the type of button:
*** C - Confirm
*** C - Confirm
*** R - Reject
*** I - Ignore
*** X - Cancel
*** 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.
** CONFIRM - if present, a confirmation message to be displayed, requiring the user to confirm that they confirm the action, with a Yes/No prompt.
Line 356: Line 383:
* The original label field will become height: 66%.
* The original label field will become height: 66%.
* The original entry items 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%, left: 1%, align: right for the Subtext 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.
* A new label item will be added at top: 67%, height: 33%, right: 1%, align: right for the Post text if it exists.


For Check-box fields, the values in TEXT2 and POST does not apply and should not be added.
For Check-box fields, the values in SUBTEXT and POST does not apply and should not be added.


Items which have the same ID as the previous item in the list are considered linked - in this instance, the TEXT field need not be displayed, but TEXT2 and POST should be.
Items which have the same ID as the previous item in the list are considered linked - in this instance, the TEXT field need not be displayed, but SUBTEXT and POST should be.


A sample text XML file is provided in [[#Appendix B: TEST UDF FILE|Appendix B]].
A sample test XML file is provided in [[#Appendix B: TEST UDF FILE|Appendix B]].


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


[[file:FS_311636_1.PNG|border]]
[[file:FS_311636_1.PNG|border]]
The Services module (in SM_Services.js) will be modified to create UDF views, if required, in certain sections, as follows:
* Pre-work Checks
* Post-work Checks
* Info
* Diagnosis
The Services function will create a PDA_UDF object for each section, named appropriately, passing in the Site, Job Group and Service Group parameters, and the name of each section. This will result with any UDF configuration retrieved for each section. Naming conventions would be:
* PDA_UDF_INFO
* PDA_UDF_PREWORK
* PDA_UDF_POSTWORK
* PDA_UDF_DIAGNOSIS
In the Diagnosis section, A fixed-size, vertical-layout UDF form will be added to the view under any existing fields. This will be created with the passed-configuration, if the configuration is not null.
In the Info section, the section will be modified to be contained within a scrolling vertical-layout view. {{Note}} This is similar to how the existing Diagnosis tab is structured now, so this code should be used as source. A fixed-size, vertical-layout UDF form will be added to the view under any existing fields, if the configuration is not null.
{{Note}} If the Service Group is being entered on the Info screen, PDA_UDF_POSTWORK configuration item should be refreshed, as this will affect the UDF fields configuration.
The Info section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The PostWork pop-up should be triggered from this, passing in the configuration setting.
The PostWork pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_POSTWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.
When exiting the PreWork pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.
The Diagnosis section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The PreWork pop-up should be triggered from this, passing in the configuration setting.
The PreWork pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.
When exiting the PostWork pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.
The validation against the OK button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:
* If PDA_UDF_PREWORK is not null and the Confirm property of the PreWork pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the PreWork checks, referred to by the Name element of the PreWork configuration. The device should return the user to the services screen on clearing this message.
* If PDA_UDF_POSTWORK is not null and the Confirm property of the PreWork pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the PostWork checks, referred to by the Name element of the PostWork configuration. The device should return the user to the services screen on clearing this message.
* If PDA_UDF_INFO is not null, the validation procedure of the Info UDF object should be called. If this does not pass, a message should be displayed requiring the user to enter the Info details, referred to by the Name element of the Info configuration. The device should return the user to the services screen on clearing this message.
* If PDA_UDF_DIAGNOSIS is not null, the validation procedure of the Diagnosis UDF object should be called. If this does not pass, a message should be displayed requiring the user to enter the Diagnosis details, referred to by the Name element of the Diagnosis configuration. The device should return the user to the services screen on clearing this message.
If the user's entry passes this validation, the saveService function should be called. This should be modified as follows:
* If PDA_UDF_PREWORK is not null, save the resulting XML from the PreWork UDF object into the new Service field EPL_UDF_PREWORK.
* If PDA_UDF_POSTWORK is not null, save the resulting XML from the PostWork UDF object into the new Service field EPL_UDF_POSTWORK.
* If PDA_UDF_INFO is not null, save the resulting XML from the Info UDF object into the new Service field EPL_UDF_INFO.
* If PDA_UDF_DIAGNOSIS is not null, save the resulting XML from the Diagnosis UDF object into the new Service field EPL_UDF_DIAGNOSIS.


<!-- MEDIA LANDSCAPE YES -->  
<!-- MEDIA LANDSCAPE YES -->  
Line 377: Line 454:
|Description=To test the entry and visibility of the additional check box fields in {{#var:System}}
|Description=To test the entry and visibility of the additional check box fields in {{#var:System}}
|MenuAccess=Services
|MenuAccess=Services
|Prerequisites=None
|Prerequisites=Set up a configuration for the chosen Site and Job Group for Prework checks, using the same set-up as is shown in [[#Appendix B: TEST UDF FILE|Appendix B]]
|Objective=To test that: Services configured for Lanemark allow entry of additional checkboxes, labelled as required; existing Services functionality remains unaffected.
|Objective=To test that: Services configured for Lanemark allow entry of additional checkboxes, labelled as required; existing Services functionality remains unaffected.
}}  
}}  
Line 455: Line 532:
         <SKIPABLE>N</SKIPABLE>
         <SKIPABLE>N</SKIPABLE>
         <ITEMS>
         <ITEMS>
             <ITEM code="0" default="Y">0</ITEM>
             <ITEM CODE="0" DEFAULT="Y">0</ITEM>
             <ITEM code="9">9</ITEM>
             <ITEM CODE="9">9</ITEM>
         </ITEMS>
         </ITEMS>
     </FIELD>
     </FIELD>
Line 479: Line 556:
     <FIELD ID="0006">
     <FIELD ID="0006">
         <TEXT>Process Temperature</TEXT>
         <TEXT>Process Temperature</TEXT>
         <SUBTEXT>(All Systems) &deg;C</SUBTEXT>
         <SUBTEXT>(All Systems) deg C</SUBTEXT>
         <POST>Min</POST>
         <POST>Min</POST>
         <FORMAT>N</FORMAT>
         <FORMAT>N</FORMAT>
Line 486: Line 563:
     <FIELD ID="0006">
     <FIELD ID="0006">
         <TEXT>Process Temperature</TEXT>
         <TEXT>Process Temperature</TEXT>
         <SUBTEXT>(All Systems) &deg;C</SUBTEXT>
         <SUBTEXT>(All Systems) deg C</SUBTEXT>
         <POST>Max</POST>
         <POST>Max</POST>
         <FORMAT>N</FORMAT>
         <FORMAT>N</FORMAT>
Line 521: Line 598:
|ST=2.0
|ST=2.0
|IMP=0
|IMP=0
|FOC=Y
|Client={{#var:Client}}
|Client={{#var:Client}}
|Year={{#var:Year}}
|Year={{#var:Year}}

Revision as of 15:51, 4 September 2013





Aptean Logo.png







Lanemark

UDF Modifications

CALIDUS eSERV

4th September 2013 - 0.2
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.

A new menu item will be added to the main menu, on sub-menu Administration, labelled as UDF Config.

This screen will allow a user to add, search for and edit UDF configurations in the system.

This screen will work in all ways like the rest of the Admin screens in that:

  • The screen will start empty.
  • A Find and New button will be provided.
  • Clicking the Find button will display a search criteria box, allowing the user to:
    • Enter search criteria of Description and/or Type.
    • A Clear button (to clear search criteria) and a Search button (to execute the search).
  • Clicking the New button will display a pop-up window to enter new config details.
  • Clicking the Search button will find all matching records, which will be displayed in a grid showing:
    • Description
    • Key Type
    • Key Value
    • A Select button.
  • Clicking the Select button will display a pop-up window to exit the configuration.

The pop-up window will allow the user to enter:

  • UDF Config section - all items required entry:
    • Description - A required description of the configuration being created.
    • Key Type - the level at which this is being created. Currently one of:
      • Site
      • Job Group
      • Product Group
    • Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.

Note Note: Changing the Key Type should blank the Key Value and require the value to be entered again.

  • Form section:
    • Name - The title of the form or button that calls the form.
    • Required - future development.
  • Field List:
    • Field List - A list of all fields created on the form, in sequence, showing the ID and the Label.
    • Top/Up/Down/Bottom Buttons - to change the selected field's sequence.
    • Add Field button - to add a new field.
  • Field Detail - shown when a field is selected from a list, or a new field is requested through the Add Field button, showing:
    • ID - An ID for the field. This is required entry. Up to 30 characters may be entered, using only alphanumeric and the underscore character only.
    • Label - A label displayed against the field when it is being entered on the device. There is no limit to the number of characters, but users should be made aware that excessively long labels will result in less-than-usable data entry on the device.
    • Sub-Label - A smaller-font label under the main label when this field is being entered on the device.
    • Post Text - a 6-character UOM to be displayed under the data being entered, in a small font.
    • Required - whether the field must be entered on the device.
    • Type - a field type, which defines how data can be entered, and what Field Type Content must be defined. Can be:
      • Text - a free-text entry field.
      • Numeric - Numeric-only data
      • Options - a series of options grouped together, that may be checked or unchecked.
      • Check - a single-option check.
      • Drop-Down List - a list of options that drop down when it is clicked on - only one may be selected.
    • Delete Field button - if clicked, this will delete the field from the list and blank the Field Detail section.
  • Buttons section - there can be up to 2 buttons defined for a form, one shown on each tab, allowing the user to enter:
    • Label - The label of the button displayed
    • Type - The button type, one of:
      • Confirm - saves the data
      • Ignore - a back-out option
      • Cancel - A Postpone-style option
    • Confirmation Dialogue - If this is entered, this will make the device display a confirmation dialogue with this text and Yes/No buttons, when the button is clicked.
  • Field Type Content section - This section differs depending on the different Field Type:
    • Text/Numeric/Check - this section should not be displayed.
    • Options - a table of options (of name only) to be selected will be shown, allowing the user to add or delete options.
    • Drop-down List - a table of options (with columns for Text, Value and a Default check box)) to be selected will be shown, allowing the user to add or delete options.

Note Note: All options should have hover-help and appropriate validators attached to them.

The following is a prototype screen-shot of how the pop-up screen should look and act:

FS 311636 2.PNG

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 attributeFormDefault="unqualified" elementFormDefault="qualified" 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" minOccurs="0" maxOccurs="1" />
              <xsd:element name="SUBTEXT" type="xsd:string" minOccurs="0" maxOccurs="1"/>
              <xsd:element name="POST" type="xsd:string" minOccurs="0" maxOccurs="1" />
              <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 name="ITEM" maxOccurs="unbounded" minOccurs="0">
                     <xsd:complexType>
                       <xsd:simpleContent>
                         <xsd:extension base="xsd:string">
                           <xsd:attribute type="xsd:string" name="CODE" use="optional"/>
                           <xsd:attribute type="xsd:string" name="DEFAULT" use="optional"/>
                         </xsd:extension>
                       </xsd:simpleContent>
                     </xsd:complexType>
                   </xsd:element>
                  </xsd:sequence>
                </xsd:complexType>
              </xsd:element>
            </xsd:sequence>
            <xsd:attribute name="ID" use="required">
              <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="I"/>
                    <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" use="optional" />
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="NAME" type="xsd:string" use="optional" />
      <xsd:attribute name="REQUIRED" type="xsd:string" use="optional" />
      <xsd:attribute name="STATUS" type="xsd:string" use="optional" />
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Note Note: Notes:

  • New elements have been added to the FIELD element:
  • TEXT if the main label. SUBTEXT 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
      • I - Ignore
      • 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 Subtext 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.

For Check-box fields, the values in SUBTEXT and POST does not apply and should not be added.

Items which have the same ID as the previous item in the list are considered linked - in this instance, the TEXT field need not be displayed, but SUBTEXT and POST should be.

A sample test XML file is provided in Appendix B.

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

FS 311636 1.PNG


The Services module (in SM_Services.js) will be modified to create UDF views, if required, in certain sections, as follows:

  • Pre-work Checks
  • Post-work Checks
  • Info
  • Diagnosis

The Services function will create a PDA_UDF object for each section, named appropriately, passing in the Site, Job Group and Service Group parameters, and the name of each section. This will result with any UDF configuration retrieved for each section. Naming conventions would be:

  • PDA_UDF_INFO
  • PDA_UDF_PREWORK
  • PDA_UDF_POSTWORK
  • PDA_UDF_DIAGNOSIS

In the Diagnosis section, A fixed-size, vertical-layout UDF form will be added to the view under any existing fields. This will be created with the passed-configuration, if the configuration is not null.

In the Info section, the section will be modified to be contained within a scrolling vertical-layout view. Note Note: This is similar to how the existing Diagnosis tab is structured now, so this code should be used as source. A fixed-size, vertical-layout UDF form will be added to the view under any existing fields, if the configuration is not null.

Note Note: If the Service Group is being entered on the Info screen, PDA_UDF_POSTWORK configuration item should be refreshed, as this will affect the UDF fields configuration.

The Info section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The PostWork pop-up should be triggered from this, passing in the configuration setting.

The PostWork pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_POSTWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:

  • If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
  • If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
  • If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.

In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

When exiting the PreWork pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

The Diagnosis section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The PreWork pop-up should be triggered from this, passing in the configuration setting.

The PreWork pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:

  • If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
  • If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
  • If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.

In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

When exiting the PostWork pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

The validation against the OK button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:

  • If PDA_UDF_PREWORK is not null and the Confirm property of the PreWork pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the PreWork checks, referred to by the Name element of the PreWork configuration. The device should return the user to the services screen on clearing this message.
  • If PDA_UDF_POSTWORK is not null and the Confirm property of the PreWork pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the PostWork checks, referred to by the Name element of the PostWork configuration. The device should return the user to the services screen on clearing this message.
  • If PDA_UDF_INFO is not null, the validation procedure of the Info UDF object should be called. If this does not pass, a message should be displayed requiring the user to enter the Info details, referred to by the Name element of the Info configuration. The device should return the user to the services screen on clearing this message.
  • If PDA_UDF_DIAGNOSIS is not null, the validation procedure of the Diagnosis UDF object should be called. If this does not pass, a message should be displayed requiring the user to enter the Diagnosis details, referred to by the Name element of the Diagnosis configuration. The device should return the user to the services screen on clearing this message.

If the user's entry passes this validation, the saveService function should be called. This should be modified as follows:

  • If PDA_UDF_PREWORK is not null, save the resulting XML from the PreWork UDF object into the new Service field EPL_UDF_PREWORK.
  • If PDA_UDF_POSTWORK is not null, save the resulting XML from the PostWork UDF object into the new Service field EPL_UDF_POSTWORK.
  • If PDA_UDF_INFO is not null, save the resulting XML from the Info UDF object into the new Service field EPL_UDF_INFO.
  • If PDA_UDF_DIAGNOSIS is not null, save the resulting XML from the Diagnosis UDF object into the new Service field EPL_UDF_DIAGNOSIS.

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-requisitesSet up a configuration for the chosen Site and Job Group for Prework checks, using the same set-up as is shown in Appendix BTested 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: TEST UDF FILE

<FORM NAME="PRECHECK TEST" REQUIRED="Y">
   <FIELD ID="0001">
       <TEXT>Please enter any comments.</TEXT>
       <FORMAT>T</FORMAT>
       <SKIPABLE>Y</SKIPABLE>
   </FIELD>
   <FIELD ID="0002">
       <TEXT>Please enter Mileage</TEXT>
       <SUBTEXT>Not distance</SUBTEXT>
       <FORMAT>N</FORMAT>
       <SKIPABLE>Y</SKIPABLE>
   </FIELD>
   <FIELD ID="0003">
       <TEXT>Please enter pressure</TEXT>
       <SUBTEXT>Read from gauge</SUBTEXT>
       <POST>mBar</POST>
       <FORMAT>DDL</FORMAT>
       <SKIPABLE>N</SKIPABLE>
       <ITEMS>
           <ITEM CODE="0" DEFAULT="Y">0</ITEM>
           <ITEM CODE="9">9</ITEM>
       </ITEMS>
   </FIELD>
   <FIELD ID="0004">
       <TEXT>Have you checked?</TEXT>
       <SUBTEXT>Really?</SUBTEXT>
       <POST>:-)</POST>
       <FORMAT>B</FORMAT>
       <SKIPABLE>N</SKIPABLE>
   </FIELD>
   <FIELD ID="0005">
       <TEXT>Please check the following items.</TEXT>
       <SUBTEXT>Check them all to continue</SUBTEXT>
       <POST>OK</POST>
       <FORMAT>X</FORMAT>
       <SKIPABLE>N</SKIPABLE>
       <ITEMS>
           <ITEM>Oil Level</ITEM>
           <ITEM>Water</ITEM>
       </ITEMS>
   </FIELD>
   <FIELD ID="0006">
       <TEXT>Process Temperature</TEXT>
       <SUBTEXT>(All Systems) deg C</SUBTEXT>
       <POST>Min</POST>
       <FORMAT>N</FORMAT>
       <SKIPABLE>Y</SKIPABLE>
   </FIELD>
   <FIELD ID="0006">
       <TEXT>Process Temperature</TEXT>
       <SUBTEXT>(All Systems) deg C</SUBTEXT>
       <POST>Max</POST>
       <FORMAT>N</FORMAT>
       <SKIPABLE>Y</SKIPABLE>
   </FIELD>
   <BUTTON>
       <TYPE>C</TYPE>
       <TEXT>Confirm</TEXT>
   </BUTTON>
   <BUTTON CONFIRM="Please confirm that Risk Assessments have been pre-completed.">
       <TYPE>X</TYPE>
       <TEXT>Pre-completed</TEXT>
   </BUTTON>
</FORM>

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=1183’