Decision Table Expression 
A decision table expression is used to compare a given input against a list of predefined combinations of conditions. Each combination has an individual result assigned which is returned as the expression result when the input data matches the particular combination.
Structure
The decision table is built up as a table with the following elements and settings:
One or more columns representing the different conditions against which the input data is compared
One or more columns used to hold the result that is returned by the expression if all the conditions in a row are satisfied
One or more rows that are unique in terms of their combined conditions
Features
General Concept
A decision table expression sequentially processes business rules based on a set of inputs. At runtime, the input data that is supplied to the decision table is compared against the defined conditions, starting with the first row. All cells are evaluated by checking the column value against a number of range comparisons. For each cell, a boolean result is returned. If all cells in a row are evaluated as true, the evaluation stops and the expression returns the result associated with the current conditions. Otherwise, processing continues with the next table row until either a matching set of conditions is found or the end of the table is reached.
Note
Due to the sequential processing of the rules defined in the table from top to bottom, we recommend that you define the rules starting with the most specific condition in the first row, followed by rules with a decreasingly specific set of conditions assigned. Otherwise, situations could occur where a given input that satisfies an unspecific condition would lead to the expression result defined for that condition, without giving the system a chance to test whether there is a more specific condition that would match the input data even better.
The check functions of BRFplus can detect many of this kind of sequential arrangement errors and make you aware of the problem.
Example
A decision table consists of two condition columns, Region and Country, and a result column Payment Target. For region Europe alone, the payment target is defined as 60 days, while for region Europe and country Germany the payment target is 30 days. The input data is Region = Europe and Country = Germany. If the condition for region only is evaluated before the combination of region and country, then the unspecific region check would already yield a result, and the more specific condition for country and region would never be tested. That is, the payment target for the input with Country = Germany would be erroneously evaluated as 60 days although it should be 30 days.
The decision table data consists of a set of nested expressions for each table cell. With the cells in condition columns, the nested expressions are typically of type range and use the corresponding column data object as a test parameter. Normally, a condition column is defined by assigning a data object to it. However, condition columns can also be derived from nested expressions. Each cell in a row can be a single value or a range of values against which the inputs are checked.
The data structure of the result column is derived from the result data object. A decision table can also have multiple result columns. This can be achieved either by assigning a structure data object as the result data object, or simply by providing several elementary data objects as result columns.
Single vs. Multiple Match Mode
A decision table can be run in two different modes of operation, depending on the setting of the Return all matches found indicator:
Single match mode
In single match mode, the input data is tested against the conditions defined in a table row. If the input satisfies all the conditions, the associated result is returned and processing of the decision table stops.
Multiple match mode
In multiple match mode, the input data is tested against the conditions defined in all of the table rows. All matching results are collected in the result data object and returned as the result of the evaluation.
NoteSince multiple match mode is designed for delivering more than one value as the expression's result, the result data object for a decision table in multiple match mode must always be a data element of type table.
End of the note.
Initial Value
If no matching condition is found for a given input, the decision table raises an exception instead of returning a result. You can override this default behavior by setting the Return initial value if no match is found indicator. If this indicator is set, the decision table returns an initial value as a result. With this setting, it is possible for you to consider the unsuccessful processing as a defined result rather than an error and continue with processing.
Note
If you use this option, it may be necessary to take additional measures in order to make sure that further processing steps do not confuse an initial value with a well-defined result. For example, the initial value for a result data object of type number is 0, which could of course be the intended result for a satisfied condition as well.
Additional Table Settings
You can influence the system behavior for some of the checks that the system carries out to ensure that the decision table definition is error-free and yields the expected results. The following checks can be influenced:
Table Overlap Check
With the table overlap check, the system detects whether the value ranges assigned to the condition columns are distinct and free of overlappings. With overlapping ranges, the system would not be able to handle correctly an input value that falls into the overlapping zone.
ExampleA decision table has an Invoice Total condition column with value ranges defined as 500...1000 in one row and 750...1500 in another row. With an invoice total of 900 as input, it would be impossible for the decision table to determine which of the two rows would be the correct one. The system would simply choose the first matching row, regardless of whether this is, from a business point of view, the intended decision or not.
End of the example.Table Gap Check
With the table gap check, the system verifies that the values of a particular condition column are defined as a continuous sequence of values with no gaps in between. With gaps in the sequence of values, it could happen that an input value could not be processed although, from a business point of view, all possible values within a given range must be processed by the decision table.
The checks described above is always carried out by the system when you explicitly force the system to do the check, or as an implicit check when you activate the decision table. However, you can decide how the system shall behave if one of the checks detects a problem. You can choose from the following options:
Show Messages as Error
This forces you to solve the problem in the table definition. Otherwise, the decision table cannot be activated.
Show Messages as Warning
The system makes you aware of the problem but still lets you activate the decision table.
Do not show any messages
Although the problem was detected, the system does not make you aware of it. Activation of the decision table is possible.
Default
In case of a problem, the system sends the corresponding message with the message type as defined in the backend system (in most cases, message type 'warning' is used).
Optional vs. Mandatory Entry of Condition Data
The default behavior for evaluating a decision table is as follows:
The value of an input data field is compared to the value in the corresponding condition column of the table.
If the two values match, the condition cell is evaluated as true.
This process is repeated for each condition in the table row until either all the conditions are satisfied (row is a match) or until a condition is not satisfied (processing continues with the next table row).
If this default behavior does not fulfill your needs, you can modify it for each condition column individually in the following way:
Column inputs optional for processing
With this indicator set, the system skips the evaluation of a condition at runtime if the input data does not contain a value for that column. The processing then continues with the evaluation of the next condition. With this indicator not set, the evaluation of an empty input to a defined condition value would yield false, and processing of the row would be stopped.
Data input is mandatory
With this indicator set, the system forces you to provide a condition value at design time for the respective column in each row that you enter in the table definition. Such a condition can therefore not be used for providing an unspecific empty condition that would be evaluated as true regardless of the input data.
ExampleIn the example outlined above with the two condition columns Region and Country, the Region column would be defined as a mandatory entry to make sure that an input must at least match one of the regions provided by the decision table to be further evaluated. As opposed to this, the Country column is not mandatory so that an input with a matching region but an unknown country can still be processed.
End of the example.
Table Data Export And Import
You can exchange the condition and result data of a decision table with Microsoft Excel. This enables you to share your table data with people who may not have access to BRFplus but might give input from a business perspective. The necessary steps for exporting and importing data are described in Exchanging Decision Table Data With Microsoft Excel.
Example
The following table illustrates the decision table example given above to determine the payment target for a customer invoice:
Region * |
Country |
Company |
Payment Target (Days) |
|---|---|---|---|
Americas |
USA |
Miller Inc. |
90 |
Americas |
USA |
75 |
|
Europe |
Germany |
30 |
|
Europe |
France |
45 |
|
Europe |
60 |
In this table, you see a list of different payment targets being defined to match the different business habits in different places in the world. The Region, Country, and Company columns represent the condition criteria (context data) while the Payment Target (Days) column holds the resulting value to be returned for each of the conditions (result data object). The table reflects the common experience that in Germany customers usually pay their invoices in relatively short time upon invoice receipt, while in other regions or countries this time can be longer. It may also be useful to define special payment targets for individual customers, depending on their assumed financial strength or on your company's experiences with these customers in the past.
Note that the entries in the table are sorted by the amount of specific information available, starting with the most specific entry for an individual company in the USA and ending with a generic entry for all customers based in Europe who do not satisfy the conditions in the more specific rows.
Note
Do not confuse this sort order with the alphanumeric sort function known from most table controls. Rather, sorting the entries of a decision table means that you have to manually arrange the entries such that they best match the business case you want to cover. So this is a semantic sort order based on business decisions, not an alphanumeric sorting based on names.
The asterisk (“*”) in the Region * column header indicates that an entry in this column is always required — in other words, at least the customer's region information is needed for the decision table to determine a payment target for a customer.
The decision table entries for the Americas region define only payment targets for customers based in the USA. If, for example, you would supply a customer from Canada or Brazil as input data, the decision table would raise an exception because neither a specific condition for these countries nor a generic condition for all countries in the Americas region (except USA) has been defined.