Brief Overview:

Business rules within Framework force users to enter pertinent information before certain fields can be completed/filled.

For example, “Admin complete cannot be entered unless build contract has been received”. In this scenario, we would assume that Admin cannot be complete before we receive a signed Build Contract. Therefore, we say that we cannot enter an admin complete date unless this field has been filled. Furthermore, we may also link build contract signed to Build Contract Received, which may sound like “Build contract received cannot be entered unless the building contract has been signed”. This is an example of the way business rules can be tied to any given field, and how more than zero rules can be applied to certain fields.

Business rules can be made up of various clauses and logical operators, each allowing the user to manipulate the rule to suit the needs of the business. Rules can be tied to the entire business, or just to a specific region/division. They can also be used to exclude / include only specific region/divisions.

It is recommended that the rule in question is tested adequately to check that it: a) works as it should, or b) does not work as it should. If b), then the string will need to be evaluated and retested to get the desired result.

Introduction

• Any field in Framework can have zero or more rules associated with it. For a new value to be accepted by that field, all rules for this field must evaluate to true.
• Rules are unique to RMS Fields and Region Divisions, allowing separate divisions of an organisation to specify their own local rules. Business Rules may be switched on/off at the rule level, division level and global level.
• All rules are stored in the database as text strings representing the conditions that as a whole, must logically evaluate to true for the rule to hold. In essence, if Framework accepts the syntax string of the rule, it does not necessarily equate to the rule holding in production. I.e. it will not trigger when you violate the rule.
• A rule is either empty, or a combination of clauses and logical operators (non-empty).
• The empty rule (no rule) is an empty string:
  Eg: “”
• A non-empty rule is either a single clause, or any number of sub-strings, containing 2 clauses and an operator, separated by any amount of whitespace and enclosed in round brackets “( )”

Empty Rules / Clauses and Logical Operators

Eg: “[X <= Y]”                                                      - rule with 1 clause
Eg: “([x <= Y] AND [Y <= Z])”                              - rule with 1 operator
Eg: “([x <= Y] AND ([A = B] OR [Y <= Z]))”         - rule with 2 operators

• An operator is any of the following: 
  AND, OR, NAND, NOR, XOR, XNOR
• A clause is 2 operands separated by a comparator, enclosed in square brackets.

 Eg:  [X <= Y]

Where there is any amount of whitespace between the comparator and operands.

• A comparator is any of the following:

 <, >, <=, >=, =, !=

In order: Less than, greater then, less than or equal to, greater than or equal to, equal to, not equal to.

An operand is either a database field’s context id (rmsFieldCtxPKID), or a literal value preceded by a ‘

Eg: 49882        - field context ID (long)

      ‘2/4/99       - literal value (date)

      ‘$4,500      - literal value (currency)

      ‘Hooper     - literal value (string)

      ‘1:00 PM   - literal value (time)

NOTE: if operands are of different types, an error will be generated

If the value of the left operand is null (missing, empty, “”, whitespace, unknown, undefined), the clause is False.
If the value of the right operand is null (missing, empty, “”, whitespace, unknown, undefined), the clause is True.

A clause may also be a null test of a single field, using the following syntax:

• Eg: [isNull<1234>]     - Clause is true when field 1234 is null
• [notNull<1234>]         - Clause is true when field 1234 is not null

In addition to the above, a clause operand may include a mathematical manipulation of the field’s value. For example, you may wish to specify that one field be compared to 5% of another field, or one field be compared to another field minus 2 weeks. This is achieved by prefixing the field’s context ID with the operation and its parameter, followed by the operation again, as follows:

• Example:

[86 > %5.5%91]         -field 86 must be greater than 5.5% of field 91
[86 > *10*91]              -field 86 must be greater than 10 times field 91

[86 > -2-91]                 -field 86 must be greater than field 91 minus 2

[86 = +12+91]             -field 86 must equal field 91 plus 12

[86 != /4.0/91]             -field 86 must not equal field 91 divided by 4

Note: the units of the parameter in the operation depend on the operation or the field value’s type. For all *,/ and % operations, the parameter is converted to a floating point double beforehand. For + and – operations, the parameter is converted to the same type as the field value’s. This may be numerical, date (days), time (minutes), currency (dollars), etc. So, if field 91 is a date, the third above example says: ‘field 86 must be greater than field 91 minus 2 days. 

• A clause operand may also be the sum of 2 or more Field Values. This is achieved by the use of the ‘s’ character, and the list of fields to be summed enclosed in curly braces:

Example: [86 < s{20, 30, 40}]   - field 86 must be less than the sum of fields 20,30 and 40

Framework In-Practice Examples:

Rule for Admin Complete:

([86 <= 91] AND [64 < 91])

Building Permit Received Date (86) must be less than or equal to Admin Complete Date (91)

AND

Ordering Received Date (64) must be less than Admin Complete Date (91)

Rule for Frame Complete:

[2118 <= 2135]

Base Start Date (2118) must be less than or equal to Frame Complete (2135)

Rule Control  

A rule belonging to a particular field can be found in the rms_ctxBRule table, indexed by the Field Context ID (l_rms_fieldCtx_id) and the Region Context ID (l_context_id)  - the Region Division to which the rule belongs.

• Individual rules can be switched on and off via f_customRule
• The message displayed to the user when a rule is violated is stored in m_notes
• The ID of the context the rule belongs to is stored in l_context_id
• Rule enforcement is enabled for a particular context (Region Division) via l_rDiv_id in the rDiv table, and changes at log on/off

NOTE: When a rule has been violated in Framework, the user is kept in edit mode to change the offending fields to valid values. If the user cancels at this point, ALL CHANGES WILL BE LOST, including changed fields that satisfied their business rules. Ensuring that the appropriate action is taken to correct the business rules will allow users to not lose any of the changes they have made.