System Business Rules

What is a System Business Rule?

The System Business Rules specify a specific action that the system must take to verify and/or modify data that is entered into the database.

Аccording to their аction, there are two main types of business rules:

  • rules that validate the data that has been entered - e.g. if a particular field has a value, if the value is valid, if the value interferes with the values of the other fields, settings, or business logics.
  • rules that modify something - e.g. sets a value in a particular field, triggers an event for another entity, and others.

Documentation

Each System Business Rule whose code is with the format 'R' + 'digit number', e.g. R27179, has a documentation topic.

The topic is available in the Business Rules section of the Model Documentation for the particular Entity e.g. Sales Orders's Business Rules.

Every topic includes a standardized table that contains detailed information about the rule. The standardized table allows us to organize data in a structured way and helps the reader to navigate through the info quickly.

The Table Columns and Content Explained

Column Name Column Description
Code Unique System Business Rule code. Always starts with "R" and continues with a digit number.
Entity The entity for which the Action of the System Business Rule is executed.
Name The name of the System Business Rule. The name is unique per entity.
Usually, the name is simply the name of the attribute for which the rule is created.
Attribute This is the attribute (field) of the entity object to which the rule applies. There may be rules that do not apply to any particular field.
Layer The layer where the System Business Rule is executed. Possible values are:
- Front-End - the rule is executed on the client-side of the application i.e. in the user interface while the data is being modified by the user.
- Back-End - the rule is executed on the server side of the application, regardless of whether the information is entered through a user interface or through the API
Events The events that will trigger the execution of the rule. Possible events are:
- Commit - occurs when the data is saved into the database.
- Planning + - occurs during the document state change to 'Planned' or higher. (applies only to documents)
- Planned + - occurs after the document state change to 'Planned' or higher. It occurs after all other validations on Planning + (applies only to documents)
- FirmPlanning + - occurs during the document state change to 'FirmPlanned' or higher. (applies only to documents)
- FirmPlanned + - occurs after the document state changes to 'FirmPlanned' or higher. It occurs after all other validations on FirmPlanning + (applies only to documents)
- Releasing + - occurs during the document state change to 'Released' or higher. (applies only to documents)
- Released + - occurs after the document state changes to 'Released' or higher. It occurs after all other validations on Releasing + (applies only to documents)
- Completing + - occurs during the document state change to 'Completed' or higher. (applies only to documents)
- Compleated + - occurs after the document state changes to 'Completed' or higher. It occurs after all other validations on Completing + (applies only to documents)
- Closed - occurs when the document state is changed to 'Closed'. (applies only to documents)
- Voiding - occurs when a document is being voided. (applies only to documents)
- ClientCommit - occurs when the data is saved into the database, nut only when the saving is initiated by a client application. If the object is modified by the EnterpriseOne server, then this event is not triggered EnterpriseOne Server.
- AttributeChanged (TheAttribute) - occurs when an attribute/field value is changed. The attribute/s whose value is being changed is/are specified in the brackets.
Priority Possible values are Early, Normal, or Late.
The priority is taken into account in the execution order. The rules with an Early priority are executed first, followed by those with Normal priority, and rules with a Late priority are executed last.
Modify Shows explicitly whether the rule modifies the entity's data. Possible values are YES and NO.
If the rule only checks if a particular field is filled in or not, then Modify = NO. But if the rule checks if a particular field is filled in and if it is not - sets a value in it, then Modify = YES.
Applicable Legislations Specifies whether the rule has to be executed according to the particular party's applicable legislation. Possible values are:
- 'ALL // no condition needed' - There is no condition and the rule will be executed regardless of the legislation of the related parties.
- The legislation abbreviation (the conditional Party) e.g. BG (EnterpriseCompany.Company) - The rule will be executed only if in the Applicable Legislations child table of the particular Party there is a record with the specified Legislation.
Action Technical description of the conditions and the operation of the rule.
Description Text description of the rule - conditions, operation, the business logic behind it, related topics, and oth.
Message The message that is shown in the client application if the conditions of the business rule are not met. Applicable only for validation rules.

May contain additional information about "Sort Messages By Attribute:" - Тhe attribute by whose value the message appearance is ordered - if the message is repeated more than once.
If we are editing a document, for example, and the message has to be thrown for a couple of its lines, then it will probably be far easier for the user to follow them if they are sorted by the "Line Number" of the document lines.
Version A list with all versions in which the Business Rule has been somehow changed. Usually contains two types of records:
- 'Introduced: 2xxx.x' - the version since which the Business Rule type is available;
- 'Updated: 2xxx.x' - the version in which the Business Rule has been changed plus a short description of the changes. There could be non or multiple records of this type.
Revocable Shows whether the rule can be revoked for a particular database or not. In order to be revoked - the rule's code has to be specified in the list of the registry key 'RevokedBusinessRules'. (for more information, see key number 41 in the todo:(Config Options Reference topic))