Modules

Section: Modules represents a hierarchical structure of reporting modules with table groups and tables as structural nodes. It is one of the three sections in the Modules view:

• Modules - sets of table groups and tables. One module typically represents a set of information requirements to be submitted in a single report;

• Table Groups - a reporting that groups sets of specific tables;

• Tables - a flat list of all tables in the framework version.

Open

Creating a module and a table group

The module structure can be created independently for each framework version in a model. One table can appear in more than one table group. Table groups can also be nested under other table groups.

To build a structure with modules, table groups and tables use the drag-and-drop function.

To create a new module click the 3 dots next to the MODULES and select Create. Each module requires a label and a code.

Open

Repeat the same steps to create a new table group. Click the 3 dots next to the TABLE GROUPS and select Create. Each table group also requires a label and a code.

In the TABLES you will see a list of tables for the chosen framework version. Tables can be added to TABLE GROUPS by using the drag-and-drop function. Table groups can be moved in the same manner.

To unpin a table group from a module or a table from a table group you must delete it from the structure. This action will not permanently remove an element. The table will still appear in the list of tables and table group in table groups.

Best practices using Table Groups

Table groups are often used to communicate to the users and processing mechanisms that certain set of tables are linked with each other. As an example, for both EBA and EIOPA data models, some tables had to be divided into smaller parts in order to properly apply DPM dictionary components for rows and columns while they still altogether represent a single tabular data request. For this reason you can see cases such as template C_07.00 from COREP split into 4 parts as highlighted on the picture below.

For most of the DPM models the best practice is to create table group for each table, even though it might not be divided into smaller chunks, in order to preserve consistency across entire model. As an example have a look at the case of C_07.00 which is divided vs. C_10.02 which is a standalone table and still is linked to upper level table group element:

In terms of filing indicators, the assumption is that a table group represents a single tabular data request, hence the filing indicator for a particular table should be indicated as a table group code.

There are few ways how the code of a table group/table can be applied and highly depends on the particular implementation. As an example, the EBA assumes that the technical split of table is represented by adding “.x” component at the end of the code, while in case of EIOPA models the entire table code follows a certain pattern e.g. S.06.01.01.01, where the last part of the code is a number of technical table, similarly like ‘.x’ in case of EBA.

There are no restrictions on indicating or skipping table groups. XBRL taxonomy/filing indicators/validations should work for both scenarios.