1. Oracle Fusion Field Service Questions and Answers
  2. What are the examples of validation rules in Oracle Fusion Field Service?

What are the examples of validation rules in Oracle Fusion Field Service?

Scenario 1: Report Gas Consumption

Let's say an activity contains information about gas consumption. There are three of types of consumption: predicted, actual, and removed. The 'predicted' amount of consumed gas is saved in the activity. When a Mobile Worker chooses to report the actual information about the consumed gas, then the difference between 'actual' and 'predicted' data must be calculated automatically. If the actual consumption exceeds the predicted consumption by more than 20 cubic meters and the conditions of the gas counter are good, then the 'Reporting notes' property is displayed.

Prerequisites: Let us assume that 'Predicted gas consumption', 'Actual gas consumption', 'Difference', 'Counter is not broken' and 'Reporting notes' string-type properties are configured in the application. And, there is the 'Counter is not broken' integer property with a check box on the GUI.

Configuration: Configure the expressions in the 'Default' field for the 'Difference' property. For example: activity.real_consumption-activity.predicted_consumption

Visibility: Set the visibility for 'Reporting notes' as Read/Write with the same formula as the condition: (activity.real_consumption-activity.predicted_consumption) >20 AND activity.counter_conditions=1

Scenario 2: Checking Ratio

A Mobile Worker has to enter the Upstream Signal-to-Noise ratio to complete an activity (it is mandatory). The range must not be seen and it has to be anywhere between +32 to 52 dBmV. When the Mobile Worker enters a value of 55dBmV, which is not in the range then the Mobile Worker must know that is not the range and has to try again. The Mobile Worker measures again and enters 51dBmV, which is in the range allowing to complete the activity.

Prerequisites: Let's assume that the Upstream Signal-to-Noise' property is configured in the application. The 'Upstream Signal-to-Noise' property is configured on the 'Complete activity' page as mandatory.

Configuration: Configure the expression in the 'Validation' field for the 'Upstream Signal-to-Noise' property. For example: this BETWEEN (32,52).

Configure the custom error message in the corresponding field to be displayed to the technician.

Scenario 3. Set Current Datetime

Each inventory contains a custom property that identifies its status. The list of statuses is different from those present in OFSC. The field worker selects a status from the list when working on the activity. The date and time when the status change has been performed is filled automatically.

Pre-conditions: Let's assume that "Protection type" and "Date of action" properties configured in the system. By default "Protection type" is not selected and technician should choose any of statuses from below when installing inventory:

  • Protection aluminum
  • Protection plastic
  • Protection fibro cement

Configuration: Configure the expression in the "Default" field for the "Date of action" property. For example:

if(NOT empty(inventory.protection_type), now("dd/MM/yyyyy HH:mm:ss"), "Status is not set, date is not collected")

Scenario 4. Report removed Counter Data

The activity contains information about gas counters. There are three of them: predicted, real and removed. By default only predicted counter information is shown. When a field worker selects a checkbox "Report removed counter data?" then the section with the property for removed counter data is shown and the property is pre-filled from predicted counter section.

Pre-conditions: Let's assume that "Predicted gas consumption", "Real gas consumption","Removed gas consumption" and "Report removed counter data?" properties exist in the system. The "Report removed counter data?" is the integer type property represented as checkbox.

Configuration: Configure the expression in the "Default" field for the "Removed gas consumption" property. For example:

if(activity.report_removed_counter_data=1,activity.predicted_gas_consumption,"")

Scenario 5. Cost Calculation

Technician has to examine electricity counter and fill in usage of electricity for previous month. Then tech should present to the customer the value of used electricity and cost. Tech could charge the customer for additional services but that price cannot be more then 30% of electricity cost. If tech tries charge incorrect price for services it cannot continue and has to re-enter the value. The customer should be presented with the total price of electricity and services.

Pre-conditions: Let's assume that "Prior Meter Read", "Current Meter Read", "Usage (kWh)", "kWh cost", "Electricity cost", "Services cost" and "Total price" properties configured in the system.

"Usage (kWh)" calculation is based on [‘current - previous’]

"Electricity cost" calculation is based on [Usage * Kwh Cost]

Configuration: For that case formulas are required for several properties.

Default value for the "Usage (kWh)": activity.current_meter_read-activity.previous_meter_read

Default value for the "Electricity cost": activity.usage*activity.kwh_cost

Validation rule for the "Services cost": this <= activity.electricity_cost / 100 * 30

Default value for the "Total price": activity.electricity_cost+activity.services_cost

The "Services cost" should be set with Mandatory visibility and custom error message should be configured to let tech know that entered value doesn't fall into the validation conditions.