3.4 Variable Row Tables

When a variable row table is selected, it will first appear without any data points:

The underlying XBRL will require not only values for the visible data points, but also one or more row dimensions for each row. To create the rows, a variable row table import template must be created, populated and processed.

See Excel Import Templates - Generating for information on creating an import template.

Populating an Import Template

The example below uses variable row tables from the CRD IV FINREP reporting module and compares the differences between the instructions given by the regulator with how the tables are displayed in DPM Authority, and what needs to be completed in the Excel import template:

Regulator Instructions

For tables, F 40.01 & F40.02, the regulator advised as follows:

F 40.01

F 40.02

Note that column 020 in F 40.01 & columns 010 & 040 in F 40.02 do not contain a data point ID, but instead are indicated to be a “<Key Value>”. These are not actual data points but are instead used to differentiate between the rows.

For F 40.01, each row will represent an entity and the Entity code will be the table’s key. This means that each row must have a unique Entity code.

For F 40.02, each row will represent a Holding company code and a security code. This means that each row must be assigned a unique combination of both Holding company code and Security code.

Interaction between F 40.01 & F40.02

As will see later in the import template, the entity code in F 40.01 is the same concept as Holding company code in F 40.02. This is because F 40.02 provides further information on the entity used in F 40.01, and the entity codes used must be consistent across these two tables.

Tables in DPM Authority

The initialised tables in DPM Authority look as follows

Note that the tables do not contain any row and automatable data points. The tables are populated through the creation of, completion and processing of variable row import templates.

Also, note that the columns which were marked with “<Key value>” in the EBA instructions are not visible on the face of the template.

Variable Row Excel Import Templates

The import templates generated by DPM Authority will contain the following:

The columns that contain the "<Key value>"s are displayed in grey in the leftmost columns.
The data points visible on the face of the report are represented by the blue cells.
The column headers that will be visible on the face of the report are represented in pink.

The values input in column 020 in F 40.01 & columns 010 & 040 in F 40.02 ("<Key value>") are not actual data points but instead used to differentiate between the rows. This is achieved by the creation of row dimension members that are assigned to every tag on the same row in the XBRL.

Each row will represent an entity and the Entity code will be the table’s key. This means that each row must have a unique Entity code.

Each row will represent a Holding company code and a security code. This means that each row must be assigned a unique combination of both Holding company code and Security code.

The Holding company code in F 40.02 is the same as the Entity code in F 40.01 and needs to be consistent across both sheets as the items detailed in F 40.02 are related to the entities detailed in F 40.01.

In the above example, entity 203459 is detailed in F 40.01 and security SC0083 which belongs to this entity is detailed in F 40.02.
Entity 468754 is also detailed in F 40.01 and it's securities, SC0084 & SC0085, are detailed in F 40.02.

Once you have completed the sheets in the Excel import template, you can process the template and the data will be displayed in the DPM Authority. (See Excel Import Templates - Generating for more information on processing Excel import templates).

Optionality of row dimension members

Not all row dimensions are mandatory and in some cases, no value needs to be provided in the Excel Import template. For example the Solvency II S.06.02 list of assets template:

Notice in this screenshot, the columns C0070 and C0080 are light grey. This indicates that they can be left blank. In this case, the values provided in the two dark grey columns must still create a unique combined key for each row.