Publicado el 11 de noviembre de 2023 por Editor
UBPartner ofrece interesantes elementos de reflexión en un artículo reciente sobre la mejora de XBRL para el modelado de datos, preguntando cómo podemos ayudar a los autores de taxonomía a desarrollar y gestionar grandes sistemas de informes.
El artículo considera el enfoque adoptado por la Autoridad Bancaria Europea (EBA) y la Autoridad Europea de Seguros y Pensiones de Jubilación (EIOPA) de generar taxonomías XBRL a partir de otro formato, en lugar de utilizar una taxonomía XBRL como punto de partida. Utiliza las cuestiones planteadas por la EBA, la EIOPA y las autoridades nacionales competentes (NCA) como lente para considerar los requisitos clave de los grandes marcos de presentación de informes, el estado de las especificaciones XBRL y los avances para cumplirlas, y las mejoras necesarias para garantizar que XBRL puede modelar más fácilmente sistemas de recolección a gran escala.
Los autores sostienen que la mayoría de las características buscadas por la EBA y la EIOPA están o estarán disponibles bajo el Modelo de Información Abierto (OIM), la iniciativa internacional XBRL para modernizar el estándar XBRL y desacoplarlo de cualquier sintaxis específica, permitiendo el desarrollo de múltiples formatos intercambiables, incluido xBRL-CSV, que está diseñado para manejar de manera eficiente grandes conjuntos de datos. También discuten en profundidad los principales desarrollos en curso en el estándar XBRL relacionados con la validación de la calidad de los datos, una fortaleza particular de XBRL.
Sin embargo, encuentran que aún quedan ciertas preocupaciones por abordar, por ejemplo, en torno a los requisitos de versiones. También sugieren que la comunidad XBRL necesita reflexionar más sobre cómo las dimensiones, las tablas, los cálculos y las fórmulas pueden trabajar juntos para ayudar a ofrecer mejores modelos XBRL. Otra idea clave es que los proveedores de software parecen carecer de incentivos para crear el tipo de herramientas de modelado de datos que necesitan los grandes autores de taxonomías XBRL.
«El verdadero problema que la EBA revela para la comunidad XBRL es que definir marcos de informes a gran escala en XBRL es un proceso en gran medida manual y complejo”, argumentan los autores. “OIM es un paso crucial para garantizar el futuro al admitir formatos alternativos; sin embargo, el XSB [XBRL Standards Board] también debe centrarse en recomendaciones que simplifiquen y requieran menos recursos para diseñar y desarrollar una taxonomía XBRL que sea consistente y eficiente”, concluyen.
Esta es una contribución reflexiva y considerada a una discusión compleja; vale la pena leerla, ya sea que compartas o no las perspectivas de los autores. ¡Gracias!
Encuentre el artículo completo aquí.
MODELADO DE DATOS EBA EIOPA OIM
Mejora de XBRL para el modelado de datos
¿Cómo se puede mejorar XBRL para ayudar a los autores de taxonomías para grandes sistemas de informes?
Un artículo reciente identificó el potencial de conflicto entre los enfoques de modelización de XBRL y la metodología de puntos de datos (DPM). Sin embargo, ningún debate estaría completo sin revisar por qué la Autoridad Bancaria Europea (EBA, por sus siglas en inglés) y la Autoridad Europea de Seguros y Pensiones de Jubilación (EIOPA, por sus siglas en inglés) eligieron usar DPM y luego traducirlo a una taxonomía XBRL, en lugar de comenzar con XBRL en primer lugar.
¿Fue la falta de características en XBRL, la falta de comprensión o simplemente la falta de herramientas? Este artículo argumenta que todavía faltan algunas características, muchas de las cuales están en el plan de trabajo del Modelo de Información Abierta (OIM) de XBRL International. Pero algunos, como el «control de versiones», aún no se han abordado.
La otra idea clave es que no parece haber ningún incentivo para que los proveedores de software construyan el tipo de herramientas de modelado de datos que necesitan los grandes autores de taxonomía XBRL.
Al revisar los requisitos clave de los grandes marcos de presentación de informes, como los de EBA CRD y EIOPA Solvency, este documento evalúa el estado de las especificaciones XBRL para cumplirlas y permitir que XBRL proporcione capacidades de gestión de datos maestros para los marcos de presentación de informes.
Ventajas y problemas de XBRL
Las especificaciones XBRL están diseñadas para dar soporte a un conjunto diverso de aplicaciones de informes de información empresarial en todo el mundo. En la actualidad hay más de doscientos marcos de informes XBRL importantes construidos en torno a este estándar abierto, existe una gran comunidad de expertos y una gama cada vez mayor de proveedores de software.
Uno de los puntos fuertes de los estándares XBRL, además del tronco común, es su independencia entre sí, lo que permite a los diseñadores de taxonomías XBRL elegir las especificaciones que desean utilizar. Sin embargo, su debilidad es que el desarrollo como especificaciones independientes hace que exista poca interoperabilidad entre ellas.
Esto es particularmente notable para los desarrolladores de grandes marcos de informes. Para ayudar a comprender cuáles son los problemas específicos, vale la pena revisar los comentarios de la EBA durante sus recientes presentaciones sobre DPM 2.0, también conocido como ‘DPM Refit’. La EBA presentó argumentos a favor de profundizar en el uso de DPM frente a un enfoque XBRL más estandarizado. La siguiente diapositiva es un ejemplo de cómo comparan su DPM con XBRL.
Creemos que muchas de las observaciones de la EBA están sesgadas debido a su decisión de basar su sistema interno de almacenamiento de datos en DPM. En nombre de la comunidad XBRL, respondemos que:
· La taxonomía XBRL producida por las herramientas DPM no proporciona una guía semántica obvia para las definiciones, ya que se compone de pocos conceptos de alto nivel y se desglosa por numerosas dimensiones, por ejemplo, existe globalmente un concepto para «activos», mientras que la taxonomía IFRS tiene muchos tipos de activos que son subconjuntos del concepto más amplio. La taxonomía de la Directiva sobre el riesgo de crédito (DRC) de la ABE es un «modelo altamente dimensional». Bueno para los ordenadores, pero pobre para ayudar a la comprensión del lector, lo cual es importante para transmitir los requisitos en los sistemas de información heterogéneos.
· El proceso DPM también genera numerosas reglas de bajo nivel para comprobar la calidad de los datos, en lugar de una regla semántica de alto nivel, como «todos los totales deben sumarse». Comprobar la coherencia de un volumen tan grande de reglas DPM de bajo nivel (alrededor de 8.000) de forma automatizada es algo dudoso.
· Muchas de las diferencias citadas en la diapositiva de la EBA están relacionadas con la implementación específica, por lo que cuestiones como la integración y los identificadores invariantes solo existen en el ojo del espectador.
Sin embargo, el problema del «control de versiones» es real. XBRL incluye una versión superficial y directrices de prácticas recomendadas para documentar las diferencias entre versiones, pero nada más. Frente a esto, la afirmación de la ABE de que DPM apoya la «historización» de conceptos se basa en su implementación patentada de DPM. If XBRL is to provide some form of ‘master data management’ for large reporting frameworks, then versioning is a critical feature. However, it is worth noting that data exchange has different versioning requirements to those of data analysis systems, as discussed in more detail later, but the requirement is important for all XBRL systems.
La EBA también tiene previsto adoptar el nuevo Modelo de Información Abierta (OIM) de XBRL y, en particular, el formato xBRL-CSV para las presentaciones, con el fin de reducir el tamaño de los archivos de los informes. Sin embargo, una vez más, en lugar de centrarse en mejorar el diseño y el potencial de rendimiento de XBRL, ha optado por utilizar una estructura CSV que utiliza explícitamente el «DPM-ID», una construcción del sistema de almacenamiento de datos de la EBA que está semánticamente «vacante» y no proporciona ninguna ayuda para optimizar el procesamiento XBRL. Para obtener más información sobre este enfoque y por qué creemos que es una mala idea, consulte el artículo anterior «DPM y XBRL».
Así que hoy en día, si la EBA empezara de nuevo, la gran pregunta sería: «¿Seguirían utilizando DPM para definir el modelo de los datos que se van a recopilar o utilizarían XBRL?».
Nuestra opinión es que la EBA seguiría encontrando una falta de herramientas de «desarrollo de taxonomía» con las que construir un «buen» modelo semántico que sea fácil de mantener. Creemos que la iniciativa de la OIM es un gran paso en la dirección correcta, pero las especificaciones XBRL independientes siguen obstaculizando el proceso. En las siguientes secciones se revisan los detalles de OIM y hacia dónde se dirigen, además de algunas recomendaciones para mejorar las capacidades de modelado XBRL.
Por ahora, DPM funciona para la EBA y la AESPJ como un mecanismo útil para sus sistemas internos (… podrían usar mejor XBRL, pero eso es para más adelante). El verdadero problema que la EBA revela a la comunidad XBRL es que la definición de marcos de información a gran escala en XBRL es un proceso en gran medida manual y complejo. Otros grandes marcos, como la taxonomía IFRS, experimentan problemas similares. Entonces, ¿qué hay que mejorar?
OIM y los estándares xBRL futuros
El Modelo de Información Abierta (u OIM, por sus siglas en inglés) es el esfuerzo estratégico de XBRL International para simplificar y modernizar aspectos importantes del estándar XBRL mediante la definición de un modelo que represente el significado del estándar, sin referencia a una sintaxis específica, es decir, que elimine la dependencia de XML. OIM define formatos múltiples e intercambiables, que se pueden agregar con el tiempo.
· xBRL-CSV: condensa los datos en una forma tabular muy compacta para permitir la recopilación de grandes cantidades de datos.
· xBRL-JSON: proporciona datos XBRL en un formato que es más sencillo de procesar y presentar.
· xBRL-XML: sigue siendo compatible con una amplia gama de requisitos de presentación de informes
Las habilidades y el esfuerzo para desarrollar reglas con las que validar los datos (fórmulas XBRL) han demostrado ser otra área de preocupación para los autores de taxonomía. El XBRL Standards Board (XSB) ha proporcionado recientemente un camino a seguir para las fórmulas XBRL en un mundo OIM:
· Empezando por la Fórmula 2.0, que eliminará la sintaxis XPath y formalizará la especificación de XF, o la Fórmula basada en texto, que proporciona la misma funcionalidad que la Fórmula XBRL pero es más rápida de escribir y más fácil de leer.
· Eventualmente, el plan es desarrollar una nueva especificación que abarque reglas tanto para la instancia XBRL como para la taxonomía, basadas en las nuevas especificaciones de la taxonomía de la OIM. También significa un cambio de nombre a «Reglas XBRL 3.0» para reconocer su importancia.
Para confusión de algunos, en XBRL hay otra forma de comprobar las relaciones simples de los datos suministrados mediante la especificación de cálculo. Idealmente, esto debería proporcionar un mecanismo más simple para definir los principales «controles de calidad» que se encuentran en los modelos de información financiera, por ejemplo, roll-ups, roll forward y agregaciones. La especificación de cálculo se está actualizando y el plan para la versión 2.0 incluye capacidades de agregación dimensional. La fórmula XBRL solo se utilizaría para reglas más complejas, así como para validaciones estructurales
La OIM mantendrá esta flexibilidad para los autores de taxonomías, pero seguirá dejando preguntas como «¿Debería utilizar fórmulas o cálculos XBRL?»:
· La EBA desarrolla la fórmula XBRL a partir de su notación DPM, que es definida por los usuarios empresariales como parte de sus plantillas de hojas de cálculo, pero no describe las relaciones inherentes a las tablas ni utiliza cálculos para sumar jerarquías básicas.
· La taxonomía NIIF en la que se basa el FEUE de la Autoridad Europea de Gestión de Valores (AEVM) utiliza tanto cálculos como fórmulas, pero no utiliza tablas. En los marcos de «informes abiertos» como ESEF, el emisor desarrolla sus propias estructuras de tablas. Un modelado deficiente de estos significa que los cálculos a menudo se pierden o solo se incluyen parcialmente en la taxonomía, lo que resulta en numerosos problemas de calidad de los datos.
Entonces, ¿la OIM va lo suficientemente lejos? Creemos firmemente que la comunidad XBRL debe reflexionar sobre cómo los hipercubos, las tablas, los cálculos y las fórmulas pueden trabajar juntos para ayudar a ofrecer mejores modelos XBRL.
Gestión de grandes marcos de informes
Si se va a utilizar XBRL para modelar sistemas de cobro a gran escala, tenemos que volver a algunas de las cuestiones subyacentes planteadas por la ABE, la AESPJ y las ANC europeas, que no solo aplican la recopilación de informes de la ABE y la AESPJ de miles de bancos y compañías de seguros europeos, sino que también los amplían a los requisitos de información locales.
Es un área grande para cubrir, por lo que es mejor comenzar dividiendo los problemas en subáreas más pequeñas:
· Desarrollo y mantenimiento de taxonomías
· Control de versiones
· Archivos de gran tamaño
· Numerosas y complejas fórmulas XBRL
Desarrollo y mantenimiento de taxonomías
Podría decirse que el modelado de datos es la decisión más impactante para un equipo de informes de datos. Determina su arquitectura y el camino que seguirá el proyecto. El modelado de conjuntos de datos grandes y complejos siempre ha planteado a los diseñadores decisiones y problemas.
Las taxonomías XBRL grandes (diccionarios de datos) pueden hacer referencia a otras taxonomías XBRL (extensibles) como bloques de construcción, y se pueden separar en numerosos puntos de entrada, cada uno de los cuales contiene varias definiciones de tabla o ELR, que facilitan el modelado de las partes individuales. Esto ayuda, pero no va lo suficientemente lejos como para ayudar realmente a los diseñadores a desarrollar un modelo semántico «bueno» y de alto rendimiento y gestionarlo a lo largo del tiempo, ni incentiva a los desarrolladores a construir el tipo de herramientas que apoyarían a los diseñadores en este proceso, como, por ejemplo.
· La especificación XBRL Dimensions se utiliza para definir hipercubos, mientras que las bases de enlaces de tabla pueden usar las dimensiones y se pueden vincular a hipercubos, sin embargo, cada base de enlaces de tabla debe especificarse de forma independiente, es decir, codificarse. Más código equivale a más desarrollo y más mantenimiento. ¿Por qué no hay capacidad para generar una especificación de Table Linkbase directamente desde el hipercubo de informes? Esto animaría a los diseñadores de taxonomía a pensar detenidamente en la estructura del hipercubo y en las tablas.
· La especificación Table Linkbase define una capa de presentación tabular para la representación. Sin embargo, no proporciona ninguna «aritmética tabular» simple, como totales de filas, totales de columnas o subtotales. Esta idea de «agregación dimensional» ha sido propuesta antes y ha resurgido en Cálculos 2.0. El diseñador podría usar el código de fórmula hoy en día, como lo muestra la EBA, pero si el proceso está automatizado y forma parte del modelo subyacente, entonces se reduce el código y los diseñadores de taxonomía estarán más estructurados en sus diseños de tablas.
· Los diseñadores están claramente interesados en los formatos xBRL-CSV y xBRL-JSON. Al agregar algunas ideas sencillas para ayudar a crear y administrar definiciones a lo largo del tiempo, se reduce el código y se centra en el modelo:
o Método para la generación directa de xBRL-CSV a partir de definiciones de tablas e hipercubos.
o Vinculación bidireccional de las definiciones de Table Linkbase y xBRL-CSV.
o Representación directa de datos xBRL-CSV en tablas definidas por Table Linkbase.
Creemos que la adición de características tan sencillas garantiza que las especificaciones XBRL se vinculen entre sí de una manera más coherente y solidaria, lo que «reunifica» los módulos de especificaciones individuales. A esto se le podría llamar «gestión maestra de informes», que sugiere una forma más estructurada y metódica de desarrollar una taxonomía, en lugar de utilizar una «mezcolanza» de diferentes herramientas.
Control de las versiones
Con el tiempo, todos los marcos de presentación de informes se desarrollarán y cambiarán a medida que sea necesario actualizar los elementos, la arquitectura, las reglas y las especificaciones utilizadas. Desde el punto de vista de XBRL, el Grupo de Trabajo sobre Mejores Prácticas XBRL se ha centrado en dos áreas:
· Cómo comunicar los cambios entre versiones de taxonomía: más detalles en https://www.xbrl.org/guidance/communicate-taxonomy-changes/
· Cómo administrar el control de versiones de taxonomía: más detalles en https://www.xbrl.org/guidance/communicate-taxonomy-changes/
Para la mayoría de los proyectos XBRL que tratan sobre el intercambio de información empresarial, estos son suficientes. Aunque no existe ninguna especificación técnica que permita que el software actualice automáticamente los sistemas de la versión antigua a la nueva versión de la taxonomía.
La visión de la EBA sobre el «control de versiones» es mucho más profunda. Quieren revisar cuándo se hizo referencia a un «concepto» (punto de datos) por primera vez, cuándo se modificó y cuándo quedó obsoleto, además de capturar quién realizó el cambio y por qué. Por lo tanto, su visión está mucho más cerca de la «Gestión de Datos Maestros», donde se recopilan metadatos sobre el modelo para que el modelo en sí pueda ser revisado.
Nótese que la EBA confunde las cosas cuando afirma que «… (XBRL) no pueden manejar la evolución de un punto de datos entre versiones, lo que los hace inadecuados para análisis de series temporales. Esto, creemos, confunde los sistemas de recolección con los sistemas de análisis. Los sistemas de análisis requieren un enfoque diferente, ya que los datos de origen vienen en muchas canalizaciones diferentes, deben transformarse y almacenarse de una manera específica para que sean eficientes para el análisis, como las series temporales. En los sistemas de recopilación, la cuestión es cómo facilitar que los remitentes sepan qué datos recopilar, cómo comprobar que son válidos y cómo hacer que el proceso de transferencia sea eficiente. Estas dos metas y objetivos pueden entrar en conflicto, por lo que la mayoría de las organizaciones dividen los dos sistemas.
Las ventajas para XBRL de un modelo de taxonomía y un control de versiones de elementos más detallados son las siguientes:
· Proporcionar un método estandarizado para que los proveedores de XBRL actualicen los materiales asociados con una versión más reciente de la taxonomía ayudaría significativamente y reduciría los costes para los proveedores y, por lo tanto, para los usuarios.
· Comprender cómo han cambiado las definiciones y las reglas de datos a lo largo del tiempo proporciona información básica importante.
· para la analítica y la toma de decisiones operativas.
Es cuestionable la importancia de esto para la mayoría de los proyectos XBRL, pero para marcos de informes más grandes y complejos, claramente ayudaría a su gestión. Una advertencia es que agregar «versiones» a XBRL es una tarea grande y algo que necesitaría un «caso de uso» de la vida real como guía.
Rendimiento de validación de grandes conjuntos de datos
Las preocupaciones sobre el tiempo de procesamiento de los informes grandes siempre han estado presentes, es solo que el tamaño de lo que se define como un archivo de datos «grande» ha aumentado exponencialmente. Cualquier prueba de rendimiento dependerá del entorno en el que se ejecute, es decir, le dará a un programa más memoria y más rendimiento de la CPU y debería ejecutarse más rápido. Por lo tanto, la pregunta debe reformularse a ‘¿Está funcionando de manera eficiente?’ para que se amplíe
Cuando se analiza el rendimiento en grandes marcos de presentación de informes, como la DRC de la ABE y la Solvencia de la AESPJ, los problemas aparecen principalmente en los conjuntos de datos basados en registros, expresados como tablas «abiertas». Una tabla abierta es aquella en la que hay un número ilimitado de filas, columnas u hojas. El formato de registro o los datos transaccionales a menudo se organizan en una fila por registro, es decir, varios hechos relacionados se agrupan en una fila. En otras tablas, que contienen relativamente pocos puntos de datos agregados, el rendimiento siempre ha sido bueno para la mayoría de los procesadores XBRL.
La especificación xBRL-CSV se desarrolló específicamente para manejar los problemas resultantes de grandes conjuntos de datos basados en registros. En primer lugar, comprime los datos, por lo que los archivos de informe son más pequeños y fáciles de transmitir. En segundo lugar, si la estructura CSV sigue el diseño de la tabla, es decir, de acuerdo con su «formato de registro», los datos podrían leerse como filas, lo que proporciona una agrupación «natural» de datos asociados, lo que mejora significativamente el rendimiento de las fórmulas XBRL en grandes tablas abiertas.
Esto proporciona una enorme mejora del rendimiento con respecto a xBRL-XML, donde estas tablas se expresan como un solo hecho por fila y un procesador XBRL debe «reagrupar» las filas individuales, lo que obliga a procesadores como XPE de UBPartner a emplear un «optimizador» para determinar la mejor manera de agrupar y filtrar los datos de una fórmula determinada.
Tenga en cuenta que, cuando se combinan grandes conjuntos de datos con numerosas comprobaciones de calidad de datos de bajo nivel, como se crea con el DPM de la EBA, se observa un aumento de los tiempos de procesamiento. Desafortunadamente, el enfoque propuesto por la EBA para la recopilación de datos CRD en xBRL-CSV no ayuda, ya que ha decidido por primera vez introducir completamente la notación DPM directamente en el modelo XBRL seleccionando la siguiente forma fija xBRL-CSV
DPM_ID, Valor, Unidad
Esto es como el modelo xBRL-XML de un hecho por línea y, a continuación, agregar una búsqueda adicional mediante el uso del ‘DPM-ID’ semánticamente vacante como clave en el archivo CSV. Un direccionamiento indirecto que, desde el punto de vista de las ANC locales y de los remitentes, no ofrece ninguna ventaja. En cambio, restringe el rendimiento de la validación y dificulta la conversión entre otros formatos.
La incorporación de capacidades semánticas, como la aritmética tabular, en el modelo subyacente ayuda a los procesadores XBRL a comprender la estructura de los datos con los que están trabajando y, a continuación, se pueden formalizar «optimizadores» para mejorar el rendimiento en función de los datos y su estructura.
Lo anterior también debe vincularse a la especificación XBRL Filing Indicator, que también proporciona un mecanismo para ayudar a dividir grandes conjuntos de datos en secciones lógicas más pequeñas. Estas secciones lógicas se pueden vincular tanto a tablas como a conjuntos de fórmulas. Ser capaz de identificar las subsecciones apropiadas de los datos y sus construcciones taxonómicas asociadas permite a los procesadores XBRL:
· Reducción del alcance de la fórmula y los cálculos, que actualmente se dirigen al conjunto completo de datos.
· Oportunidad de dividir el procesamiento en operaciones más pequeñas, que utilizan un subconjunto del modelo y los datos y tienen el potencial de procesarse de forma independiente.
Mejoras en las fórmulas XBRL
La capacidad de incrustar reglas de validación en una taxonomía es una de las características más potentes de XBRL para el intercambio de datos y la fuente de mejora de la calidad de los datos. Hoy en día, como se ha comentado, tenemos dos métodos: cálculos y fórmula XBRL. La primera es simple y fácil de implementar, pero limitada, mientras que las fórmulas XBRL proporcionan mucho más, pero son difíciles de desarrollar, ya que están vinculadas a XML. Además, un diseñador de una taxonomía ‘abierta’, como ESMA ESEF o para US GAAP, actualmente no puede escribir reglas para verificar la extensión Taxonomy creada por el emisor.
En respuesta al último problema, XBRL US ha creado su propio sistema de reglas (DQR) en una tecnología diferente, XULE. Si bien esto proporciona una solución inmediata, no ayuda a la estandarización en toda la comunidad XBRL.
Como se destacó anteriormente, la XSB anunció recientemente que la Fórmula 2.0, eliminando la dependencia XML y formalizando el uso de XF (fórmula basada en texto). XBRL Rules 3.0 planea hacer una ruptura clara con las especificaciones existentes y se espera que se base en gran medida en la experiencia adquirida por XBRL US. Lo anterior debería ayudar significativamente a los diseñadores de taxonomía y permitir una definición más fácil de las reglas de negocio de calidad con las que comprobar el documento de instancia y cualquier extensión de taxonomía.
Además, XBRL Europe ha reconocido que la arquitectura DPM de la EBA y la AESPJ tiene ciertas características específicas con tres modelos en uno: puntos de datos, plantillas y dimensiones semánticas que necesitan un «puente» para ayudar a pasar a las nuevas características XBRL. Ha creado un grupo de trabajo para revisar ‘XF-DPM’, lo que ayudaría a traducir entre las reglas DPM y las fórmulas XBRL, pero también mejoraría el rendimiento de las fórmulas XBRL resultantes. Sin embargo, seguiría sufriendo la definición de «comprobaciones de calidad de datos» a nivel de punto de datos, por lo que produciría muchas de ellas, en lugar de utilizar la semántica integrada en un modelo XBRL dimensional.
Conclusiones
XBRL sigue creciendo y es compatible con una gama cada vez más amplia de marcos de presentación de informes. La OIM es un paso crucial para garantizar el futuro mediante el soporte de formatos alternativos, sin embargo, la XSB también debe centrarse en recomendaciones que hagan que sea más sencillo y menos intensivo en recursos diseñar y desarrollar una taxonomía XBRL que sea coherente y eficaz.
Cuando la EBA y la AESPJ iniciaron sus viajes XBRL, XBRL proporcionó un método basado en estándares para recopilar los datos que necesitaban para supervisar su mercado. Sin embargo, XBRL no tenía las características que les permitieran modelar los datos en XBRL, y en su lugar utilizaron DPM como herramienta de modelado. Ahora hay pocos incentivos para cambiar esta configuración y, de hecho, la propuesta de reacondicionamiento de DPM de la EBA es mover el marco de informes más hacia la arquitectura DPM.
La comunidad XBRL debe ofrecer un incentivo de este tipo. La XSB ha entregado OIM y el formato XBRL-CSV y ha hecho propuestas significativas sobre la actualización de las fórmulas. Sin embargo, esto no satisface la necesidad de utilizar XBRL como base para un sistema de «gestión maestra de informes». También significa que hay pocos incentivos para que los proveedores proporcionen las herramientas necesarias para ayudar a las ANC, de la misma manera que la ABE y la AESPJ están desarrollando sus propios sistemas de gestión de datos patentados utilizando DPM.
Creemos que la visión de la OIM debe extenderse a:
· Reunificar el conjunto de especificaciones.
· Armonización de dimensiones/tablas/especificaciones de colección.
· Agregue la capacidad de control de versiones.
Desafortunadamente, la especificación de estándares toma tiempo para obtener consenso y luego desarrollar las especificaciones. La comunidad XBRL se basa en voluntarios que contribuyen a este proceso, por lo que es importante que el trabajo sea relevante y prioritario si queremos ver beneficios tangibles en un plazo realista. Los autores sugieren que se empiece por ampliar la hoja de ruta de la OIM para que los usuarios y desarrolladores tengan una imagen más clara de los desarrollos futuros y dar instrucciones a autores como la EBA y la EIOPA.
Los autores son David Bell, Kapil Verma y Martin DeVille de UBPartner. Por favor, envíe comentarios, correcciones y cualquier idea alternativa a info@ubpartner.com
Publicado originalmente: https://www.xbrl.org/news/how-should-the-xbrl-standard-grow-to-support-large-scale-data-collection/