F3913 - Complex Summing and Validations for EBA
Introduction
The summing and validation requirements for the EBA product go beyond what is currently available in
Reporter. The complex version of both goes most of the way to providing the required functionality, with a
syntax already in place to handle conditions and table joins. However, it does not handle grids or joins
between grids.
Summary of Summing Requirements
1. Grid column totalling into a static cell
2. Grid column totalling into a static cell with an expression clause
3. Grid row summing (one or more columns) into a column in the same grid
4. Grid column (one or more) summing into another grid column based on a join between the grids on
one or more columns. (Master –detail type of grid arrangement)
5. Grid column (one or more) summing into another grid column based on a join between the grids on
one or more columns depending on an expression. (Master –detail type of grid arrangement)
6. Single Grid Complex column assignment
7. Validations
8. Grid summary page
Summary of Validations Requirements
Validations are in effect running the same as a summing rule, but rather than applying a result to a cell, it
checks the result against what is in the target cell. Hence:
1. all the above summing actions must also replicate themselves as validations and cross validations.
2. The target cell value and summed values must be available for display in the error message if the
validation fails.
Suggested Approach
The approach to be taken is to enhance the ‘complex’ summing and validations functionality. Below are
examples of summing and the proposed syntax.
Prerequisites
1. All cell names within a return MUST be unique, whether in a grid or static.
Rules for using Complex Summing
1. This is where the datasets to be operated on are defined. Knowledge of the M tables and their
structure is required.
2. The [Set Definition] section should list all the fields being used in the [Expression] section, unless the
expression is a simple assignment, such as A:=B+C, or A:=SUM(B)
3. Any WHERE clause should be in the [Set Definition] section as it defines the dataset or subset of data
to be operated on.
4. The [Expression] section is for defining the update expression. It can be a conditional update based
on the dataset
1|Page
Page Instances
1. If a cell on a particular instance needs to be addressed, use square brackets containing the instance
id, such as CellA[23].
2. If no page instance is specified, then operations are carried out on the same instance or all instances,
depending on the settings of summing rule – for each or for all instances.
Eg: CellA := CellX+CellZ
will sum CellX with CellZ into CellA on each page instance
3. If matching page instance doesn’t exist, the value for the cell should be returned as zero (0).
Eg: CellA := CellX+CellZ[23]
will return CellA as 10 if CellX is 10 and there is no page instance 23
on which Cell Z is positioned.
Key for examples
Item
Description
ACOMPLEX
Return name for these examples
CUSTID
GRID A key field
CUSTID2
GRID B key field
Grid A and Grid B have separate M tables.
2|Page
1. Grid column totalling into a static cell
Syntax:
This currently works, but the syntax is wrong.
This is the preferred syntax.
Example:
Explanation
As all cell names in a return should be unique, it is possible for the parser to realise that ‘TOTAMOUNT’ is a
static cell and that ‘AMOUNT’ is a column in this grid. Hence the assumption is that the whole column should
be summed into the static cell. This syntax already works in the simple and complex summing rules.
3|Page
2. Grid column totalling into a static cell with an expression clause
Syntax:
Example:
+
+
TOTAMOUNT:
42
Explanation
[Set Definition] is where the used cells are listed and the subset expression in the ‘where’ clause.
[Expression] is where the operation is defined. Here the static cell TOTAMOUNT is updated with the
sum/total of the AMOUNT column, but only where the subset condition is met (BRANCH=’X’).
4|Page
3. Grid row summing (one or more columns) into a column in the same grid
Syntax:
Example:
+
Explanation
[Expression] is saying add the value of COL1 plus COL2 into the AMOUNT column, and do this for each row.
5|Page
4. Single Grid Complex column assignment Grid row summing (one or more columns) into
a column in the same grid depending on an expression
Syntax:
Example:
X2
X2
Explanation
[Set Definition] is used to define to list the required columns from the return and set an alias name to (‘A’ in
this case)
[Expression] Here it considers each row at a time, and depending on the value of CustID2, it sets the value of
AMOUNT to twice COL1 or COL2.
6|Page
5. Grid column (one or more) summing into another grid column based on a join between
the grids on one or more columns
Syntax:
Example:
Explanation
[Set Definition] is used to define the join between the grids. Although M table names cannot be selected in
the UI, it should be possible for the parser to establish which physical tables to join based on the cell name.
[Expression] is where the operation is defined. Here the column CUST_TOT is updated with the sum/total of
the AMOUNT column from Grid B where the customer IDs match.
In the example above Grid A can be considered the master and Grid B the detail. So here Grid A is the driver
on which the ‘for each’ loop works.
7|Page
NOTE: Where there is not a unique single column key, it should be possible to expand the ‘where’ clause to
include other join fields using the AND operator.
8|Page
6. Grid column (one or more) summing into another grid column based on a join between
the grids on one or more columns depending on an expression.
Syntax:
Example:
Explanation
[Set Definition] is used to define the join between the grids. Although M table names cannot be selected in
the UI, it should be possible for the parser to establish which physical tables to join based on the cell name.
[Expression] is where the operation is defined. Here the column CUST_TOT is updated with the sum/total of
the AMOUNT column from Grid B where the customer IDs match, but only where the subset condition is met
(BRANCH=’X’).
In the example above Grid A can be considered the master and Grid B the detail. So here Grid A is the driver
on which the ‘for each’ loop works.
9|Page
If no Grid B record exists that matches the join conditions of the summing rule, then the value assigned to
the target cell is NULL.
Validations
Example:
Explanation
In the example above, firstly the two datasets are defined. ‘A’ is the static cell dataset, and ‘B’ is the grid
dataset.
The validation test is to ensure that the static cell value in TOTAMOUNT equals the sum of columns 1 and 2
in the grid.
The error message was auto-created. It might need manual editing to make is user friendly.
As can be seen, and should be the case, the validation rules are an almost exact copy of the summing rule.
But points to note are:
1. The expression uses ‘=’ and not ‘:=’ as it is checking equality and not assigning.
2. There is an error message.
10 | P a g e
EBA Case:
Notes:


Irrelevant columns in the grids are removed for convenience (very wide grid in original form);
The validation rule above (provided by product team/regulator?) is using column name of numbers,
whilst in product we should use different naming which should be unique.
Similar to summing type 6, we can use the following complex validation rule:
[Set Definition]
A: LEXP.LE1C020,LEXP.LE1C030,LEXP.LE1C340,LEXP.LE2C005,LEXP.LE2C340
where LEXP.LE1C020 = LEXP.LE2C005
and LEXP.LE1C030 = '2';
11 | P a g e
[Expression]
Foreach (A.LE1C020) {
LEXP.LE1C340 = SUM (LEXP.LE2C340)
}
[Error]
ErrorMsg = 'For group (' + A.LE1C020 + ') is not equal to sum of details: (' + LEXP.LE2C340... +')'
Issues:
1. There could be multiple error messages as there are actually multiple runs/loops. The challenge is
how to show them in the current validation failure window. Business for sure is requiring to show all
not just first loop failure.
2. Business also requires to show failures on mismatches, including :
a. a)master without detail and
b. b) detail without master (however per our solution we are not to test orphan detail…).
3. There could be errors raised from other reason, eg unexpected data type – alphanumeric shows up
in the values to sum?
4. Handling of null or zero values?
5. Will the matching column(s) have to be the defined grid key column(s)?
6. Do we need this validation rule to involve instancing, eg for each/for all instancing?
Future Enhancements
1. Consideration should also be given during the low level design to enabling cross return summing.
2. Where there is not a unique single column key, it should be possible to expand the ‘where’ clause to
include other join fields using the AND operator.
3. Often a page will have many instances. Another page might be a summary page. For example each
page might be a currency and the summary page a list of currencies with a final value for each. See
example below.
4. We may be able/needed to implement cross grid validation not limited to master and detail, but
include detail and detail (validation of summing from different grouping)
5. May consider function support (or we already support in complex rule?) like average, max, min etc?
8. Grid summary page
This is not a current requirement for the EBA project, but is something asked for before. Although it is
possible to create a summary page’s data during a Compute with Translation, it is not possible to update the
summary grid during manual editing. The idea is if a user updates a value (makes an adjustment) on a detail
12 | P a g e
page, then the total value for that group should be updated on the summary page. Equally, if the user inserts
a new row into a detail grid, then a new row needs to be inserted into the summary grid for this key value if
it doesn’t already exist.
New summary record auto-inserted
New detail record inserted
Issue: (Understand this is not EBA requirement for the moment, but still want to know:)
1. Would we expect the master grid to have the same column names to auto populate? If not how
would we know which column to sum to which destination column? Guess you mean cross grids
summing here.
2. And you are requiring not just summing, but the ability to insert new (or even delete!) in the master
grid based on user edit type in the detail grid (do we allow user to delete a row in a grid?).
13 | P a g e