NOMBRE DEL DEPARTAMENTO DATA DICTIONARY Primary items One single schema Credit / debit attribute: to...

NOMBRE DEL DEPARTAMENTO

DATA DICTIONARY

Primary itemsOne single schemaCredit / debit attribute: to discuss with business users

To take into account IFRS-GP approachFormula patterns could benefit from this information

Data type: Light constrains (sign won’t be constrained)But still we want to have that information for

communication purposesSubstitution groups best of both worlds

Instant / Duration: no special requirements (duration for changes)Two different primary items in movement tables

Nillable attribute: no special requirementsCodification

1


DATA DICTIONARY

DimensionsA schema for each dimension and its domain members.

Domains => standard extended link roleSubdomains => additional extended link rolesHypercubes pointing to subdomains: try a proof of concept

Open hypercubes? => Most people against the use of open hypercubes

2


IFRS-GP COMPATIBILITY

Common conceptsCommon concepts with different signCommon concepts with different labelsCodification issues?

3


LABELS

Labels independent of the context?Statement specific labels?Both? FINREP network was receptive to use a unique label for each concept. Thou using two different labels is not a technical issue, it simplifies the maintenance and its clearer for credit institutionsUse of arc roles: beginning of period, …

4


REFERENCES

Template specific references: to be solved using template specific extended link roles

5


PRESENTATION

Connection between facts and layout in business templates

Presentation linkbase?

Rendering linkbase?

Should we just follow the normalized version proposed by BRAG? Marco will check

6


DATA SUBSETS

- Postpone until a clearer approach to rendering / dimensions

7


ADDITIONAL DATA / ADDITIONAL DIMENSIONS

Should scope of consolidation be a standard dimension?-Header of the instance document?-Dimensions?

-Open hypercubes or closed hypercubes? Complexity of dimensional information

Solo / Consolidated information

Additional information from DGI?

Impact on instance document reporting

FINREP network: do we want a consensus on auxiliary data?

8


CONSTRAINS ON DIMENSIONAL COMBINATIONS

Too many constrains on COREP?Light approach to the new taxonomy?Mix – modular approach (some countries already using dimensional constrains, but some countries wish to use formula and better error reporting)

We need more information on grey areas from FINREP network => already in templates: criss-crossed cells don’t have a business meaning; grey cells are just not required.

9


CONSTRAINS ON THE CONTENT

Modularity:-Pattern approach-Tree walk functions / filters (FWG)

-Bazaar model-Assertion sets-Assumptions about non-reported data

Error reporting:-Identification of the failed assertion-Error description-Identification of facts involved (reported values)-Expected value

10


EXTENSIONS

No extensions at all?

No content extensions…

11


VERSIONING

Versioning reportIt won’t be possible for the new versionCould be use to show differences between extensions

Identification of the versionFollow convention used in current COREP / FINREPTo be proposed to the best practices board / taxonomy architecture WG

Identification of the tool and its versionTo be proposed to the best practices board / taxonomy architecture WG

12


ATTRIBUTES AND DIMENSION

We should use a convention for attributes and dimensions to cover the lack in the standardFormulae could impose additional constrains according to the idea of attributeBut first, we should identify attributes in the model

13


TYPED VS EXPLICIT DIMENSIONS

Typed dimensions for enumerable dimensions that are likely to change. For instance, currency.

14


CODIFICATION

How data reported is identified in the instance document : Each concept / dimension / member has codeThis code is composed of two parts: a namespace and a local name

XBRL provides ways to express additional information. There’s no need to “overload” this code:

LabelsPresentation linkbase…

The most important requirements for this coding scheme are:UniqueStable

15


MULTIDIMENSIONAL VIEW OF XBRL FACTS

A value

A concept: Incomes

A set of dimensions

– Standard

• Entity

• Time

– User defined

• Titulizations

• Market

Additional properties: unit and precision

THE STATEMENT DOESN’T EXIST

XBRL IS NOT AN EXCEL SPREADSHEET

16

t

Credit institution

Concept

100 € (prec 3)

DexiaDec 2007

Incomes


CODIFICATION

Codification scheme cannot depend on the presentation (statements)

Foundations of data modellingStabilityRedundancy of dataAlignment with IFRS-GP and major taxonomies trendShould a change in the presentation have an impact on credit institutions?Compatibility with toolsEasier for (some) filers of the data

Codification should be based on the schema matrix and / or the normalized version of the statements

17


CODIFICATION

Is this just a technical issue?Shorter codes means smaller instance documentsEasier to read by technical staff

What about error messages?

18


FORMULA MESSAGE REPORTING

Implementation dependentError reporting:

-Identification of the failed assertion-Error description-Identification of facts involved (reported values)-Expected value

There is no common agreement to identify facts involvedTo check, from a technical point of view, the feasibility of having a standard way to implement different fact codifications

19


ERROR EXAMPLE

20

V133: Summation of the breakdown not equal to the total value reportedThe reported value for “Total assets” is 200,000 whereas the calculated value is 195,000Table 26

Dimension I (Instrument) : i0 (Derivatives held for trading)

Measure: i1200 (Assets)Reported value = 200,000 euros

Measure: i1201 (Cash)Reported value = 40,000 euros

Measure: i202 (Financial assets held for trading)Reported value = 75,000 euros

Measure: i203 (Available for sale financial assets)….


ERROR EXAMPLE

21

T26 – V133: The following check is not valid“i200 | s1” = “i201 | s1” + “i202 | s1” + “i203 | s1”I200 | s1 : Cash | CDR Scope of consolidationI201 | s1 : …

T2 V133: The following check is not valid“i200 | s1 | i1”: Cash | CRD Scope | Debt securities

“i201 | d1 | s1” + “i202 | d1 | s1” + “i203 | d1 | s1”

T1 – T2 – V400: The following check is not valid“i200 | s1” < “i201 | s2” + “i202 | s1” + “i203 | s1”


LOCAL NAME CODIFICATION

Approaches:-FRTA Approach (none seems to like it, but, do we have a better solution?)-Timestamp / hash: short, unique but doesn’t make sense from a business point of view-Short nemotechnical name: to be decided by business network; but still language problem-Codification derivated of a main hierarchy (1.1, 1.2, 1.3, 1.4, …)-Enumeration: 1, 2, 3, …

-No common approach accepted !!!

22

NOMBRE DEL DEPARTAMENTO DATA DICTIONARY Primary items One single schema Credit / debit attribute: to...

Documents

Transcript of NOMBRE DEL DEPARTAMENTO DATA DICTIONARY Primary items One single schema Credit / debit attribute: to...