La Autoridad Bancaria Europea (EBA) ha publicado una versión actualizada de sus Reglas de Presentación XBRL, llevándola a la versión 5.2. Introduce cambios relativamente limitados, en particular en relación con la forma en que deben utilizarse los códigos de entidad para indicar el tema informante, incluidos los informes agregados.
EBA – Reglas de presentación XBRL
EBA/XBRL/2022/08
01 agosto 2022
Reglas de presentación versión 5.2
EBA – Reglas de presentación XBRL
Abreviaturas
UML Lenguaje Modelado Unificado
W3C Consorcio World Wide Web
XBRL Lenguaje de Informes Empresariales eXtensible
XML Lenguaje de Marcado eXtensible
Referencias normativas
Los siguientes documentos referenciados son indispensables para la aplicación de este documento. Para referencias fechadas, solo se aplica la edición citada. Para las referencias sin fecha, se aplica la última edición del documento al que se hace referencia (incluidas las modificaciones).
XBRL 2.1
XBRL Dimensions 1.0
XBRL Registry specification 1.0
XBRL Formula specification 1.0
xBRL-CSV: mapping from Open Information Model 1.0
CWA European Filing Rules
Términos y definiciones
A los efectos de este documento, se aplican los siguientes términos y definiciones.
NOTA XBRL términos específicos como contexto, unidad, período, entidad, s-igual, v-igual ver XBRL 2.1
taxonomía aplicable
una taxonomía XBRL reconocida para su uso como base para las presentaciones en un sistema de archivo determinado
marca de orden de bytes
En los documentos UTF-8, una secuencia de caracteres (0xEF, 0xBB, 0xEF) que pueden usarse para indicar que los caracteres están codificados usando UTF-8 pero, en este caso particular, su uso no es requerido ni recomendado por el consorcio Unicode.
autoridad competente (AC)
autoridad legalmente responsable
punto de datos
Un punto de datos es un componente de información definido por un supervisor para enviarlo en un informe XBRL
Nota: En XBRL, un punto de datos está representado por un hecho y combinaciones dimensionales relacionadas
Dimensión
a Dimension es un elemento xs:en el substitutionGroup de xbrldt:dimensionItem; se relaciona con la capacidad de expresar información multidimensional
punto de entrada
el punto de partida para el descubrimiento de los requisitos de presentación a los que se hace referencia en un informe XBRL. Los puntos de entrada vienen en dos sabores: como esquema XML (XSD) y como archivo JSON. Cuando es necesario, se utiliza un término específico para identificar a qué tecnología se hace referencia. Los términos utilizados son «punto de entrada XSD» para el esquema XML y «punto de entrada JSON» para el archivo JSON. Cuando se utiliza el término general «punto de entrada», se hace referencia a ambas formas.
hecho
Un hecho es un valor notificado con respecto a un punto de datos en un informe XBRL
Un hecho de negocio es un hecho que transmite un valor de negocio. Los hechos de los indicadores de presentación no son hechos comerciales
Filer
una entidad responsable de la presentación de una presentación
limado
una presentación es la unidad fundamental de información que se transmite a un sistema de archivo para su recepción, validación y aceptación.
Nota: una presentación se transmite en un informe XBRL o en una serie de informes XBRL
indicadores de presentación
indicar las unidades de informe (normalmente plantillas) notificadas en el informe
Nota: Los indicadores de presentación son hechos, de acuerdo con las definiciones de XBRL, pero tienen características especiales y no están sujetos a las reglas definidas en este documento que cubren todos los demás tipos de hechos, llamados hechos comerciales.
sistema de archivo
un sistema en el que los informes XBRL se archivan, reciben, comprueban, almacenan, analizan y redistribuyen el punto de entrada json ver punto de entrada.
Reportero
una entidad informante: descrita por el informe o informes
unidad de presentación de informes
conjunto de hechos en una presentación que conceptualmente se informan o no se informan juntos como una unidad
plantilla
una representación visible (generalmente tabular) de un conjunto de hechos, típicamente identificados con/como una sola unidad de notificación XSD punto de entrada ver punto de entrada.
Introducción
La especificación eXtensible Business Reporting Language (XBRL) proporciona un alto grado de flexibilidad en la creación de informes XBRL. Parte de esta flexibilidad se deriva de la naturaleza de la sintaxis y parte se deriva de la propia especificación XBRL.
Ámbito de aplicación
El proceso europeo de presentación de informes de supervisión es conceptualmente un proceso de varias etapas, en primer lugar, las entidades preparan, validan y remiten datos de supervisión a sus autoridades nacionales pertinentes («informes de primer nivel»), cuando procede, algunos datos se envían a una autoridad supranacional y, posteriormente, dichas autoridades remiten datos a la Autoridad Bancaria Europea («informes de segundo nivel»).
Estas normas de presentación representan una recopilación de normas y orientaciones adicionales específicamente aplicables al envío de informes XBRL para entidades informantes en el ámbito de aplicación de las regulaciones pertinentes de la ABE (por ejemplo, bancos) presentaciones regulatorias de las autoridades nacionales y supranacionales pertinentes a la Autoridad Bancaria Europea.
Centradas en la preparación de informes XBRL, en lugar de detalles de la mecánica de la presentación de informes / recopilación de datos, estas reglas restringen la flexibilidad total de XBRL, para permitir una interacción efectiva entre el transmisor y el receptor / consumidor de las presentaciones regulatorias.
Las reglas de presentación enumeradas están influenciadas por la Arquitectura de Taxonomía de la ABE en los casos en que la creación del informe se ve afectada.
Este documento fue revisado por un grupo de expertos nacionales con el fin de aclarar cualquier formulación engañosa de normas y contribuir a la armonización paneuropea de las normas de presentación. Las normas establecidas en este documento son las que se aplican en el segundo nivel de presentación de informes (a la ABE). En el caso de que las autoridades de supervisión adopten estas normas, pero con adaptaciones, por ejemplo, cambiar las preferencias u orientaciones expresadas por la ABE en lugar de en obligaciones en el primer nivel de notificación, el supervisor respectivo comunicará al informante dichas variaciones.
Nota: estas normas no son necesariamente las que son aplicables a nivel de presentación de informes por parte de instituciones individuales o grupos de instituciones, ni abordan todo el alcance del proceso de presentación de informes. Debe solicitarse orientación a la autoridad competente del informante en cuanto a su formato de presentación de informes y los requisitos para esa presentación de informes.
Tenga en cuenta también: por su naturaleza, no todas estas reglas serán posibles / prácticas de determinar, implementar y hacer cumplir de manera automática, y en varios casos simplemente declarar o explicar la práctica esperada en nombre de los reporteros.
Base en la orientación armonizada de las «Normas Europeas de Presentación»
Con el fin de promover y mejorar la interoperabilidad, estas normas se extraen en gran medida del documento CWA 16744-4:2014 European Filing Rules, promulgado por el Centro Europeo de Normalización (CEN), que «representan una colección de recomendaciones que deben considerarse como una guía que debe implementarse en el proceso europeo de presentación de informes de supervisión». Este documento debe leerse en conjunción/comparación con ese documento del CEN.
Numeración de reglas
Tenga en cuenta que las reglas no están necesariamente numeradas en orden secuencial. Para facilitar la comparación, las reglas se numeraron originalmente según su numeración en el documento CEN, por lo tanto, se omitieron algunos números cuando la regla CEN correspondiente no era aplicable / no se incluía. Para facilitar la identificación y la comparación entre las revisiones de este documento, siempre que sea posible, se mantiene la numeración inicial de reglas específicas, por lo tanto, las reglas pueden estar fuera de orden, o en secciones diferentes de las implícitas en su numeración.
A muchas reglas se les han dado etiquetas o nombres de identificación específicos, por ejemplo, «DuplicateFact». Esto es con el fin de ayudar a la identificación.
Público objetivo
Aunque se dirigen principalmente a aquellos (en su mayoría personal técnico) dentro de las autoridades nacionales y supranacionales responsables de la preparación o presentación de informes XBRL directamente a la Autoridad Bancaria Europea, estas normas de presentación también serán de valor para los informantes individuales (es decir, instituciones financieras o grupos de instituciones) que informen a aquellas autoridades que puedan utilizar las normas de presentación de la ABE o el formato XBRL. o derivados de los mismos.
Este documento está destinado a un público técnico y asume que el lector tiene un conocimiento práctico de la especificación XBRL 2.1 y otras especificaciones como XBRL Dimensions 1.0 y XBRL Open Information Model 1.0, junto con una comprensión básica de XML, espacios de nombres y esquema XML.
Para los lectores con conocimientos de XML, muchas de las directrices de este documento les resultarán familiares. Sin embargo, otros se originan a partir de características que son específicas de XBRL y, por lo tanto, el razonamiento detrás de ellas puede ser menos obvio.
Relación con otros trabajos
Este documento debe leerse junto con la Arquitectura de Taxonomía de la ABE. [CEBA14]
Las directrices de este documento se refieren a los informes XBRL. Partes de este documento reiteran para mayor claridad expositiva ciertas restricciones sintácticas y semánticas impuestas por XBRL, pero este documento no modifica XBRL. En caso de conflicto entre este documento y XBRL, XBRL prevalecerá. Este documento impone restricciones adicionales más allá de las prescritas por XBRL.
Las normas se basan estrechamente en las recomendaciones del Acuerdo de Taller del CEN sobre normas europeas de presentación de solicitudes desarrollado por el proyecto CEN WS/XBRL (http://cen.eurofiling.info/).
Para facilitar la comprensión por parte de los desarrolladores de software que implementan estas directrices en su sistema de informes, se incluye un modelo UML para mostrar las relaciones entre los diferentes objetos XBRL mencionados en este documento.
A efectos de armonización y explicación, cuando se utilizan normas de presentación similares en otras jurisdicciones, se indican las referencias.
Uso del lenguaje
El uso del lenguaje en este documento sigue al especificado en [RFC 2119], en resumen:
El uso de «MUST» implica una obligación, y la preparación de informes XBRL que no sigan estas reglas generalmente resultará en el rechazo del informe.
El uso de «DEBERÍA» implica una indicación de preferencia o mejores prácticas, pero también un grado de tolerancia, siguiendo el principio de «cumplir o explicar». La norma debe respetarse a menos que haya buenas razones para no hacerlo. El incumplimiento de la regla no dará lugar al rechazo de un informe XBRL por parte de la ABE.
El uso de «MAY» implica permiso, y describe acciones que se pueden tomar o construcciones que se pueden usar, pero que no son necesarias. La utilización de estas opciones no dará lugar al rechazo de un informe XBRL.
Los nombres de atributos XML van precedidos del carácter «@» de este documento, como en la sintaxis de XPath.
Acerca de la estructura de reglas de presentación.
Además, en este documento, las reglas de presentación especifican restricciones que se aplican en general a los informes XBRL. Si no se menciona xBRL-CSV o xBRL-XML 1, la regla no se aplica a esa sintaxis.
1. Reglas de sintaxis de archivo
1.1 — Denominación de la presentación
Informes xBRL-XML
La práctica común es utilizar la extensión .xbrl para los informes xBRL-XML. Los requisitos detallados de nomenclatura de archivos deben confirmarse con el destinatario previsto de un informe XBRL. Las entidades de crédito deben confirmar la presentación de informes con su supervisor pertinente. La convención de nomenclatura de archivos que utilizarán las AUTORIDADES para el envío a la ABE se puede encontrar en la sección de ejemplos.
Informes xBRL-CSV
La práctica común es agrupar el conjunto de archivos en un contenedor zip. Los requisitos detallados de nomenclatura de archivos deben confirmarse con el destinatario previsto del informe XBRL. Las entidades deben confirmar la presentación de informes con su supervisor pertinente. La estructura de este contenedor zip y la convención de nomenclatura de archivos que utilizarán las AUTORIDADES para el envío a la ABE se pueden encontrar en la sección de ejemplos.
1.4 — Codificación de caracteres de informes XBRL
Regla
Todos los informes XBRL deben utilizar la codificación de caracteres UTF-8 (independientemente de con o sin BOM) para garantizar que el receptor pueda procesarlo.
Implementación para informes xBRL-XML y xBRL-CSV
Tenga en cuenta que, según https://www.w3.org/TR/xml/#charencoding, los nombres de codificación de caracteres deben coincidir de una manera que no distinga entre mayúsculas y minúsculas, por lo que UTF-8 y utf-8 son igualmente aceptables.
encodingNotUtf8: Los informes XBRL DEBEN usar codificación UTF-8. [GFM11, p. 11]
1.5 — Selección del punto de entrada de la taxonomía
Regla
Una taxonomía se carga a través de una referencia a una o más URL. Aunque técnicamente un usuario puede hacer referencia a cualquier archivo de la taxonomía, un editor de taxonomía normalmente nominará URL específicas que están destinadas a ser referenciadas por los usuarios de la taxonomía. Estas URL se denominan puntos de entrada y permiten a los usuarios importar los módulos correctos de la taxonomía, con diferentes módulos que incluyen diferentes plantillas y diferentes reglas de validación asociadas.
La taxonomía de la ABE define múltiples puntos de entrada específicos («módulos»), adecuados para diferentes informes.
Implementación para informes xBRL-XML
La selección del módulo específico cuando se utiliza xBRL-XML se realiza a través del elemento schemaRef. Este schemaRef debe contener el esquema XML definido por la ABE para ese módulo. La taxonomía también contiene otros esquemas XML, que no deben usarse como puntos de entrada xsd.
Implementación para informes xBRL-CSV
La selección del módulo específico cuando se utiliza xBRL-CSV se realiza a través del elemento «extends». Este elemento debe contener el archivo de punto de entrada JSON definido por la ABE para ese módulo. La taxonomía también contiene otros archivos JSON, estos no deben tratarse como puntos de entrada.
(a) multipleTaxonomyRefs: Las entidades informantes NO DEBEN rellenar el elemento documentInfo \ taxonomy. La referencia a la taxonomía se realiza a través del punto de entrada json («documentInfo», elemento «extends»).
(b) inappropriateTaxonomyRef: El elemento documentInfo \ extends DEBE contener una sola referencia a la URL apropiada para el módulo y la fecha de referencia de un informe, extraída de la lista de puntos de entrada json publicada por la EBA2. [CEBA14]
1.6 — Indicadores de presentación
Regla
Cada hecho reportado en una presentación se asigna a una o más unidades de informe (típicamente «plantillas») del dominio específico de presentación de informes.
Un elemento indicador de presentación que contiene un código asociado a una determinada unidad de notificación se utiliza para indicar la intención de un informante de informar de esa unidad de notificación, o para indicar la intención de no informar de esa unidad de notificación (véase el ejemplo bajo el epígrafe «Ejemplos de uso de indicadores de presentación» para ilustración). Los indicadores de presentación también activan las comprobaciones apropiadas de las fórmulas taxonómicas. La falta de indicadores de presentación puede dar lugar a incoherencias porque es posible que no se validen los hechos de las unidades informantes no indicadas.
Implementación para informes xBRL-XML
El elemento indicador de presentación se denomina filingIndicator y se agrupa (potencialmente con otros elementos similares) dentro de un elemento que contiene fIndicators.
1.6.1 — Múltiples indicadores de presentación de solicitudes para la misma unidad de notificación
Regla
No hay ningún beneficio en la presentación de varios indicadores de presentación para la misma unidad de presentación de informes. Pueden ocurrir ocurrencias inconsistentes.
Implementación para informes xBRL-XML y xBRL-CSV
duplicateFilingIndicator: Los informes XBRL DEBEN contener solo un elemento indicador de presentación para una unidad de informe determinada («plantilla»).
1.6.2 —Presentación de indicadores en varias tuplas
Regla
La presentación de informes de elementos indicadores de presentación de documentos distribuidos en varias tuplas fIndicadoras separadas es un enfoque más complejo que el uso de un solo elemento de contención, y es probable que sea más complejo de manejar por los receptores.
Sin embargo, esta construcción puede ser útil para generar informes de gran tamaño (generación en una sola pasada o streaming), al permitir, por ejemplo, que una tupla que contiene un único indicador de archivo preceda inmediatamente (o siga) a los elementos de datos para cada unidad de informe.
Implementación para informes xBRL-XML
filingIndicatorInMultipleTuples: Para mayor flexibilidad, los informes XBRL informados PUEDEN incluir diferentes indicadores de presentación en varios elementos de tupla fIndicadores separados, para simplificar esto DEBE evitarse en general cuando no sea necesario.
1.6.3 – Presentación de códigos indicadores
Regla
Como se indica en la Arquitectura de Taxonomía de la ABE, los valores de los indicadores de presentación que se utilizarán se indican mediante recursos de etiquetas asociados con las tablas de la taxonomía XBRL. El valor utilizado debe ser exactamente como se indica.
Implementación para informes xBRL-XML y xBRL-CSV
invalidFilingIndicatorValue: Los valores de los indicadores de presentación DEBEN ser solo los dados por los recursos de etiqueta con el rol aplicado a las tablas relevantes en la taxonomía XBRL4 para ese módulo de informes (punto de entrada). Los valores de los indicadores de archivo deben tener el formato correcto (por ejemplo, incluir cualquier carácter de subrayado).
1.7 — Implicación de ningún hecho para una plantilla indicada
Regla
Si en el informe XBRL se presenta un indicador de presentación positivo, el sistema de notificación de los destinatarios podrá procesar las comprobaciones de coherencia adecuadas. Si no aparecen hechos para una plantilla indicada, la presentación puede ser rechazada porque el sistema requiere un conjunto apropiado y coherente de valores de hechos para las comprobaciones.
Si no se informan hechos que coincidan con una plantilla indicada con un indicador de presentación positivo, esto transmite que la plantilla está destinada a ser informada explícitamente y que cada celda de esa plantilla puede considerarse (es decir, cuando se aplican comprobaciones de validación) como equivalente a cero (para el valor numérico) o en blanco (para el no numérico), no que la plantilla en su conjunto está destinada a no ser reportada. En la práctica, es poco probable que esta sea la intención de un declarante, y puede indicar un error en la preparación del informe.
Implementación para informes xBRL-XML y xBRL-CSV
(a) missingPositiveFilingIndicator: Los informes XBRL DEBEN incluir elementos indicadores de presentación positivos apropiados para expresar qué unidades de notificación («plantillas») están destinadas a ser reportadas en el informe
(b) positiveFilingIndicatorForNonReportedUnit: Los informes XBRL NO DEBEN incluir elementos indicadores de presentación positivos que indiquen que se ha presentado una unidad de notificación para las unidades de notificación que NO están destinadas a ser reportadas en el informe.
1. 9 — XBRL válido
Para aumentar la probabilidad de que los informes XBRL pasen la validación, los solicitantes deben validar su cumplimiento con las especificaciones XBRL relevantes antes de la presentación.
Implementación para informes xBRL-XML
notValidXbrlDocument: los informes xBRL-XML DEBEN ser válidos XBRL 2.1 y XBRL Dimensions 1.0. [EFM11, págs. 6-8]
Implementación para informes xBRL-CSV
notValidXbrlDocument: los informes xBRL-CSV DEBEN ser válidos xBRL-CSV 1.0.
2. Reglas de sintaxis del informe XBRL
2.1 — No se permite la existencia de xml:base
Regla
El atributo xml:base se puede insertar en documentos XML para especificar un URI base distinto del URI base del documento o entidad externa. Los procesadores XBRL interpretan este atributo de manera diferente, y no hay necesidad semántica de este atributo.
Implementación para informes xBRL-XML xmlBaseUsed: El atributo @xml:base NO DEBE aparecer en ningún documento de informe. [EFM13, págs. 6-7]
2.2 — La URL absoluta debe indicarse para el elemento de referencia de taxonomía
Regla
La taxonomía que se utiliza para un informe XBRL se identifica mediante una dirección URL. Aunque a menudo es conveniente trabajar con copias locales de las taxonomías relevantes, es importante que estos elementos de referencia de la taxonomía se resuelvan en las ubicaciones de los puntos de entrada publicados. Nota: El software XBRL normalmente proporciona funcionalidad para «reasignar» referencias a URL de puntos de entrada publicados a copias locales de la taxonomía.
Implementación para informes xBRL-XML
inappropriateSchemaRef: El elemento link:schemaRef en los informes enviados DEBE resolverse en la URL del punto de entrada xsd publicada completa (URL absoluta).
Implementación para informes xBRL-CSV
InappropriateTaxonomyRef: El elemento extends en los informes enviados DEBE resolverse en la URL del punto de entrada JSON publicada completa (URL absoluta).
2.3 — Sólo se permite una referencia taxonómica por informe
Regla
Bajo el estándar XBRL, un informe puede hacer referencia a una o más taxonomías. Sin embargo, cuando se utiliza la taxonomía de la ABE, en cualquier informe solo se debe hacer referencia a un único punto de entrada. Este punto de entrada especificará todos los puntos de datos necesarios y se utiliza para hacer referencia a un tipo de informe en particular.
Implementación para informes xBRL-XML multipleSchemaRefs: Cualquier informe xBRL-XML DEBE contener solo un elemento xbrli:xbrl/link:schemaRef.
Implementación para informes xBRL-CSV multipleTaxonomyRefs: Cualquier informe xBRL-CSV DEBE contener solo un elemento documentInfo/extends.
2.4 —No se permite el uso de elementos link:linkbaseRef
Regla
Los puntos de entrada para los informes xBRL-XML se definirán mediante un esquema. No hay uso para los elementos link:linkbaseRef.
Implementación para informes xBRL-XML
linkbaseRefUsed: La referencia de un informe a la taxonomía DEBE ser solo por medio del elemento link:schemaRef. El elemento link:linkbaseRef NO debe utilizarse en ningún documento de informe.
2.5 —Los comentarios y la documentación XML son ignorados por la ABE
Regla
Los comentarios pueden estar presentes en los informes enviados a la ABE, pero su contenido será ignorado. Cualquier información dentro del informe que no se informe como un hecho será ignorada por la EBA.
Implementación para informes xBRL-XML
CommentsAreIgnored: Los datos empresariales relevantes SOLO DEBEN estar contenidos en contextos, unidades, schemaRef y hechos.
CommentsAreIgnored: Un comentario NO DEBE tener ningún impacto en el contenido de un informe.
2.25 — La ABE ignora las notas a pie de página XBRL
Regla
Las notas a pie de página pueden estar presentes en los informes enviados a la ABE, pero su contenido será ignorado.
Implementación para informes xBRL-XML
xbrlFootnotesAreIgnored: Los datos empresariales relevantes SOLO DEBEN estar contenidos en contextos, unidades, schemaRef y hechos. xbrlFootnotesAreIgnored: Una nota al pie NO DEBE tener ningún impacto en el contenido regulatorio de un informe.
Implementación para informes xBRL-CSV
xbrlFootnotesAreIgnored: Los datos empresariales relevantes SOLO DEBEN estar contenidos en hechos, unidades y documentInfo/extends. xbrlFootnotesAreIgnored: Una nota al pie NO DEBE tener ningún impacto en el contenido regulatorio de un informe.
Reglas relacionadas con el contexto
2.6 — La longitud del atributo @id debe limitarse a los caracteres necesarios
Regla
El atributo @id se entiende como una clave técnica única dentro de un documento XML. La transmisión de la semántica en el atributo @id probablemente se perderá cuando se procese el contenido XML, por ejemplo, almacenado en una base de datos (que generalmente funciona con claves sustitutas específicas de la base de datos), es poco probable que cualquier semántica esté disponible para un consumidor (humano) de los datos del informe. Aunque no hay limitación en la longitud de un atributo id, se recomienda mantenerlo lo más corto posible.
Implementación para informes xBRL-XML
noSemanticsinID: La semántica NO DEBE expresarse en el atributo xbrli:context/@id.
longXmlIdAttribute: Los valores de cada atributo @id NO DEBEN ser excesivamente largos.
2.7 — No hay nodos xbrli:context no utilizados o duplicados
Regla
Los contextos no utilizados (contextos a los que no se hace referencia por los hechos) abarrotan el informe y no agregan ningún valor ni al supervisor ni al reportero [GFM11, p. 12].
Implementación para informes xBRL-XML
(a) unusedContext: Los nodos xbrli:context no utilizados NO DEBEN estar presentes en el informe.
(b) duplicateContext: Un documento de informe NO DEBE contener contexto duplicado, a menos que sea necesario por razones técnicas, por ejemplo, para admitir la transmisión XBRL.
2.8 — Identificación del objeto del informe
Regla
Debe identificarse el objeto del informe.
Implementación para informes xBRL-XML
El elemento xbrli:identifier (valor combinado con el atributo @scheme permite la identificación del sujeto de un informe6 por parte del receptor. El @scheme proporciona un URI que identifica de forma única el tipo de identificador utilizado en el nodo xbrli:identifier (consulte la sección 3.6 ).
2.9 — Tema único por informe
Regla
Sólo puede haber un tema conceptual de un informe XBRL. Si el contenido del informe se refiere a un grupo de empresas, ese «grupo» (cualquiera que sea su definición) es el objeto conceptual del informe.
Implementación para informes xBRL-XML
multipleIdentifiers: Todo el contenido de xbrli:identifier y los atributos @scheme de un informe DEBEN ser idénticos. [EFM13, págs. 6-8]
2.10 — Los elementos de la fecha de referencia notificados deben ser válidos
Regla
Todos los elementos utilizados en los informes XBRL para identificar el período al que se refieren (período de referencia) tienen un tipo de datos que es una unión de los tipos xs:date y xs:dateTime. La ABE solo permitirá que los períodos se identifiquen utilizando días enteros y se especifiquen sin una zona horaria.
Implementación para informes xBRL-XML
periodWithTimeContent: Todos los elementos de fecha xbrli:period DEBEN ser válidos contra el tipo de datos xs:date y periodWithTimezone: informados sin una zona horaria. [GFM11, p. 16]
Implementación para informes xBRL-CSV
periodWithTimeContent: el parámetro de período de referencia DEBE ser válido contra el tipo de datos xs:date y periodWithTimezone: informado sin una zona horaria. [GFM11, p. 16]
Reglas relacionadas con hechos
2.16 — Hechos duplicados (redundantes/inconsistentes)
Regla
Los hechos son duplicados comerciales entre sí en el sentido de los informes si teóricamente transmiten respuestas a la misma pregunta. Los duplicados pueden ser copias completas (donde son verdaderamente equivalentes semánticamente), copias inconsistentes o copias contradictorias.
Implementación para informes xBRL-XML
Los hechos duplicados son válidos para la sintaxis XML-XBRL. Sin embargo (ya sea que sus valores sean diferentes o no) el significado semántico puede no estar claro.
El punto X y el punto Y son «hechos duplicados» si y sólo si se aplican todas las condiciones siguientes:
1. X no es idéntico a Y (no es exactamente el mismo nodo XML), y
2. El nombre local del elemento de X es S-Igual al nombre local del elemento de Y, y
3. X e Y se definen en el mismo espacio de nombres, y
4. X es P-Igual a Y, y
6. X es U-igual a Y, y
7. X e Y son dimensionalmente equivalentes (d-iguales en todas las dimensiones de cada uno de X e Y), y
8. Si X e Y son elementos de cadena, también tienen atributos xml:lang de S-Equal.
Los hechos inconsistentes son duplicados que no son V iguales.
Los hechos duplicados son válidos para la sintaxis XML-XBRL. Sin embargo (ya sea que sus valores sean diferentes o no) el significado semántico puede no estar claro.
Un informe XBRL-XML no debe tener elementos de hechos empresariales duplicados.
duplicateFactXBRL-XML: Los informes XBRL-XML NO DEBEN contener datos empresariales duplicados. [EFM13, págs. 6-10]
Implementación para informes xBRL-CSV
xBRL-CSV tiene una característica llamada «duplicados permitidos». A través de esta característica, el autor de la taxonomía puede especificar qué tipo de duplicados se permiten12. EBA ha optado por utilizar esta función y permitir solo duplicados completos.
2.16.1 — Ausencia de conjuntos de datos de varias unidades
Regla
Dos hechos que difieren sólo por unidad no son técnicamente duplicados. De hecho, puede haber situaciones en las que, por ejemplo, la respuesta natural a una pregunta sea un conjunto de valores en varias monedas (por ejemplo, £ 4, $ 3, € 3). Sin embargo, existe claramente un potencial significativo de confusión con tales informes, por ejemplo, se supone que los diferentes hechos son alternativas ($ 4 o £ 3), equivalentes ($ 4 = £ 3), que deben tomarse como un conjunto ($ 4 y £ 3), o simplemente un error.
A fin de evitar tales dudas o confusiones, no se permite la notificación de «el mismo hecho»13 en más de una unidad en los informes de la ABE.
Implementación para informes xBRL-XML y xBRL-CSV
factsDifferingOnlyByUnit: Los informes XBRL NO DEBEN contener hechos comerciales que serían duplicados si sus unidades no fueran diferentes.
2.17 — No se permite el uso del atributo @precision
Regla
El estándar XBRL proporciona dos métodos para comunicar la precisión de un hecho numérico: @precision y @decimals atributos. Los seres humanos parecen tener más facilidad para leer un documento que utiliza el atributo decimal, probablemente porque en la mayoría de los usos es probable que el valor decimal sea uno de un conjunto limitado, por ejemplo, 2, 0, -3, -6, -9 o INF (y a menudo lo mismo para todos / muchos hechos). Además, dado un valor decimal, la precisión siempre se puede calcular, pero esto no es simétrico.
Implementación para informes xBRL-XML
precisionUsed: @decimals DEBE usarse como el único medio para expresar precisión sobre un hecho. [EFM13, págs. 6-12]
2.18 — Interpretación de la configuración de decimales
Regla
La configuración de decimales indica la precisión del valor de hecho informado. Un hecho numérico que tiene una propiedad decimal con el valor n se considera «correcto a n decimales». Los ceros iniciales y los dígitos finales deben ser compactos y apropiados para el valor informado.
La ABE interpretará la configuración de decimales en los datos reportados como especificando que la diferencia absoluta entre el valor verdadero del número conocido por el informante y su representación léxica reportada (conocida como el «error absoluto» de la representación – eabs) es menor o igual a 0.5 x 10-n. Los reporteros deben preparar los informes presentados de manera consistente con esta interpretación.
Las reglas de validación XBRL de EBA utilizan aritmética de intervalos para la validación. Para permitir que los cálculos de la fórmula XBRL se realicen mejor sobre los valores notificados con fines de validación, preferiblemente no se deben aplicar truncamientos ni redondeo ni ningún otro tipo de cambio a la representación léxica notificada de los hechos numéricos en el informe XBRL.
Sin embargo, tenga en cuenta que si los números se redondean por cualquier motivo, DEBEN redondearse según la especificación XBRL 2.1 (es decir, [IEEE-754] 4.3.1 Atributos de dirección de redondeo a los atributos de dirección de redondeo más cercanos, roundTiesToEven), y como se indica arriba, la configuración de decimales debe representar con precisión la relación entre los valores informados y no redondeados.
2.19 —Orientaciones sobre el uso de ceros y datos no notificados
Regla
Los datos podrían notificarse con un valor distinto de cero, como cero o no notificados. No se permiten valores vacíos.
Implementación para informes xBRL-XML
nilUsed: El atributo @xsi:nil NO DEBE usarse para los hechos del informe. emptyUsed: Para la métrica de tipo de cadena, la cadena vacía NO DEBE ser reportada.
Implementación para informes xBRL-CSV
nilUsed: Un hecho NO DEBE ser reportado como nulo. Por lo tanto, el valor especial #nil NO DEBE usarse para los hechos en el informe. emptyUsed: Un hecho NO DEBE estar vacío. Por lo tanto, el valor especial #empty NO DEBE usarse para los hechos en el informe.
3. Orientación adicional
3.4 Prefijos de espacio de nombres no utilizados
Regla
Declarar espacios de nombres no utilizados no es necesario y desordena el informe XBRL.
Implementación para informes xBRL-XML
unusedNamespacePrefix: Los prefijos de espacio de nombres que no se utilizan NO DEBEN declararse en el documento de informe XBRL.
3.5 Reutilización de prefijos de espacio de nombres canónicos
Regla
La mayoría de los autores de esquemas proporcionan un prefijo de espacio de nombres para su espacio de nombres de destino. Es una práctica común volver a utilizar estos prefijos en otros documentos XML cuando sea necesario. Puede llevar a confusión a los lectores humanos ver prefijos comúnmente entendidos utilizados en un espacio de nombres diferente, o prefijos novedosos utilizados para un espacio de nombres común. Por ejemplo, el prefijo ‘xs’ utilizado para el espacio de nombres http://xbrl.org/2003/xbrl-instance-2033-12-31. Tenga en cuenta que esto no afecta al uso de un atributo de espacio de nombres predeterminado en un elemento para evitar la necesidad de usar un prefijo de espacio de nombres en el elemento y sus elementos secundarios por completo.
Implementación para informes xBRL-XML
notRecommendedNamespacePrefix: Los prefijos de espacio de nombres, cuando se usan en informes XBRL, DEBEN reflejar los prefijos de espacio de nombres definidos por sus autores de esquema.
3.6 Tema de presentación de informes
Para las remesas de segundo nivel a la ABE, el sujeto informante y el esquema utilizado deben ser acordados y pre-registrados en la ABE por la autoridad competente.
Antes de la fecha de referencia 31/12/2022 o para el módulo que tiene _con/_ind en su nombre de módulo:
• Para el informe de consolidación individual y de más alto nivel, el sujeto informante DEBE ser el IPJ de la entidad individual / matriz / informante (es decir, este será el código requerido y acordado por la ABE para dichos informes en todas las circunstancias, excepto en circunstancias muy excepcionales).
• Para el informe del subgrupo de liquidez, el sujeto informante DEBE ser el IPJ del subgrupo matriz + «. CRDLIQSUBGRP».
3.7 — Atributo @id no utilizado en los hechos
Regla
Los atributos @id no utilizados en los hechos no agregan valor al supervisor y no deben incluirse en el informe XBRL a menos que sean valiosos para el reportero.
Implementación para informes xBRL-XML
unusedFactId: El informe XBRL NO DEBE incluir atributos @id no utilizados en los hechos.
3.8 — Longitud de las cadenas en los informes XBRL
Regla
Aunque no hay limitación en la longitud de una cadena informada en un informe XBRL, es probable que las cadenas excesivamente largas causen problemas en los sistemas involucrados en el proceso de informes, muchos de los cuales tendrán algunas restricciones prácticas en la longitud de la cadena que pueden manejar. Por esta razón, se recomienda limitar la cadena notificada a solo los caracteres necesarios.
Implementación para informes xBRL-XML y xBRL-CSV
excessiveStringLength: Los valores de cada cadena DEBEN ser lo más cortos posible.