El Manual de Desarrollo de Taxonomía (TDH) es una guía completa que dirige a los reguladores, expertos de la industria y empresas a través de una hoja de ruta práctica y consistente para construir estándares de datos de alta calidad utilizando XBRL.
PARTE 1
Prefacio
En 2016, XBRL US me preguntó: «¿Podemos hacer una guía para ayudar a las personas y organizaciones a construir taxonomías XBRL?» Este manual es esa guía, y es el resultado de los esfuerzos de muchas personas y organizaciones como parte del Comité Directivo de Dominio de XBRL US en los últimos años.
Hasta ahora, la información disponible de XBRL International y XBRL US sobre XBRL era altamente técnica. Si bien satisfacen la necesidad de especificaciones, estos documentos no proporcionan una fuente de información fácil y «todo en uno» sobre el desarrollo utilizando la plataforma XBRL. En pocas palabras: había una gran cantidad de información sobre lo que es XBRL, pero había una gran falta de una explicación sobre cómo usarlo de manera efectiva para transportar y organizar datos. Por lo tanto, el objetivo principal del Manual de Desarrollo de Taxonomía es cerrar esta brecha entre la descripción técnica y la aplicación práctica. Lo hace al tiempo que proporciona una introducción fácil de entender a XBRL y sus capacidades, con un gran enfoque en cómo construir y mantener una taxonomía. Idealmente, usando este manual, los no iniciados pueden obtener una comprensión del modelo y la terminología XBRL con solo unas pocas horas de estudio. Además, cubrimos los puntos culminantes de cómo iniciar un proyecto de desarrollo XBRL, los requisitos básicos de documentación de taxonomía, cómo supervisar la implementación de estándares y las formas de administrar el mantenimiento continuo de una taxonomía.
XBRL es especialmente adecuado para representar datos estructurados con fines de informes, y la información que expresa es comparable a través de diferentes informes e históricamente estable. No existe ningún otro formato o especificación que proporcione soporte para la identificación única de puntos de datos, la estructura del dominio de tiempo y la expresión de la multidimensionalidad, todo mientras se describe un modelo de datos semántico. Además, un sistema de consumo de datos puede examinar un hecho XBRL y tener una comprensión bien definida de su significado y propósito de divulgación sin mirar más allá de la taxonomía en sí, que es eficiente tanto en tiempo como en costo.
Creo que XBRL está en una posición única para abordar las necesidades de muchos proveedores de datos, reguladores, analistas, agregadores y consumidores. Se utiliza en todo el mundo de diversas formas para responder a los requisitos regulatorios y de intercambio de datos del sector privado. Como Campbell Pryde, presidente y CEO de XBRL, declaró, «hasta ahora, XBRL es el secreto mejor guardado» al abordar el volumen de necesidades y oportunidades de datos estructurados. Creemos que ya es hora de que este secreto se haga abierto y obvio para las comunidades de datos. Con este documento, creemos que XBRL está listo para ser descubierto como una herramienta de transporte de datos robusta, potente y flexible.
Como se establece en la misión para el Comité Directivo de Dominio, nuestro objetivo es apoyar los esfuerzos de tecnología y desarrollo de XBRL US necesarios para satisfacer las necesidades de informes comerciales de los mercados clave en los Estados Unidos. Esto incluye aprobar el trabajo de desarrollo de taxonomía, realizar controles de calidad, proporcionar retroalimentación a los grupos de trabajo y guiar a los desarrolladores de taxonomía en el diseño de sus propias soluciones XBRL. Esperemos que este documento sea su primer paso para un proyecto exitoso. XBRL US y el Comité Directivo del Dominio están listos para ayudarlo en sus esfuerzos.
Scott A. Theis
Presidente, Comité Directivo de Dominio, XBRL US
Presidente / CEO, Novaworks, LLC
1 INTRODUCCIÓN
1.1 Visión General
1.1.1 Alcance y Objetivo
El propósito de este documento es proporcionar una referencia básica y pautas útiles para el desarrollo, implementación y mantenimiento de la taxonomía XBRL. Las secciones de este documento discuten XBRL, por qué se creó, sus ventajas como herramienta de transporte de datos y cómo se compara con otros sistemas. Otras partes se centran en la creación adecuada de taxonomías, cubriendo la importancia de cómo se diseña, controla e implementa una taxonomía para mantener la usabilidad y la integridad de los datos. Dado que XBRL es más que un simple mecanismo de transporte de datos, una estructura de datos bien definida es fundamental para una implementación exitosa. Como tal, esta guía también revisará ciertos aspectos del desarrollo del sistema, incluido el modelado de datos, la mecánica del desarrollo de taxonomía y la definición de pautas para el resultado final. Finalmente, cualquier taxonomía XBRL es tan poderosa como lo bien que se gobierna. Se discuten los métodos para mantener una taxonomía una vez que ha sido diseñada e implementada para garantizar la validación, transmisión, recepción e interpretación adecuadas.
En total, se espera que este documento proporcione instrucciones y orientación útiles para que los desarrolladores de taxonomía puedan tener éxito en la creación e implementación de su propia taxonomía XBRL, sin importar las circunstancias, restricciones y requisitos de su proyecto. Aunque este documento procede de una manera lineal, similar a la «narración de historias», los lectores deben sentirse libres de omitir partes o cualquier sección que no sea relevante para sus necesidades o si el contenido ya les es familiar.
1.1.2 Audiencia
Este documento ha sido escrito para proporcionar al lector información básica para comenzar en el desarrollo de una taxonomía XBRL. Se supone que el lector tiene cierta familiaridad con los modelos de datos comerciales, y se supone que el lector está investigando, o se le ha encomendado la tarea de construir un sistema para transportar y redistribuir datos comerciales o similares a los negocios. No se requiere una familiaridad con XBRL; Las construcciones XBRL se explicarán en detalle para que los lectores inexpertos puedan conocer las ideas necesarias a medida que avanzan en el proceso de desarrollo de la taxonomía. Tampoco se requiere experiencia en XML, ya que esta guía volverá a instruir a los lectores en los detalles pertinentes y los dirigirá a recursos externos para obtener más información.
Al final del viaje, los lectores deben tener el conocimiento para implementar un sistema de informes de datos que responda a todos sus requisitos especificados y sea fácil de entender, fácil de implementar y extensible según sea necesario y deseado.
1.1.3 Terminología
Debido a que XBRL es una entidad de código abierto en evolución, existen múltiples formas de documentarla y describirla. Los lectores que están familiarizados con XBRL / XML pueden sorprenderse por parte de la terminología nueva y diferente utilizada en esta guía. Estas elecciones de vocabulario son el resultado de una combinación de cosas. En primer lugar, para estar alineados con el Modelo de Información Abierta XBRL propuesto, ciertos términos como «contexto» se han refinado a una situación particular. En su lugar, se han seleccionado términos más flexibles, como «dimensión». Se tomaron decisiones como estas para garantizar que los términos utilizados en este documento estén alineados con el vocabulario actual de modelado de negocios y sistemas de información, al tiempo que se mantienen fieles al significado y las capacidades subyacentes de XBRL. En segundo lugar, a través del conocimiento y la experiencia, los autores de este documento han tratado de limpiar y hacer consistente parte de la terminología utilizada en el pasado y evitar el uso general de varias palabras ambiguas como «propiedades», «metadatos» o «atributos». En tercer lugar, si bien XBRL se ha implementado comúnmente para expresar información contable, la contabilidad es solo un subconjunto de las capacidades generales de informes de XBRL. Por lo tanto, en este documento se han empleado ejemplos y terminología para representar una gama general y más amplia de entornos y circunstancias de presentación de informes.
Los lectores también deben tener en cuenta que en los siguientes capítulos el término dimensión puede referirse tanto a la dimensionalidad del modelo de datos como a la dimensión de construcción XBRL. A veces estos son verdaderamente intercambiables, ya que la dimensionalidad del modelo de datos se representa en XBRL con dimensiones XBRL y construcciones dimensionales. Sin embargo, si el texto se refiere específicamente a la dimensionalidad del modelo de datos, se denominará dimensión de datos. Si el texto describe una construcción XBRL, se denominará dimensión XBRL.
En una línea similar, para distinguir entre los modelos de datos de origen y las representaciones XBRL de ellos, los elementos de línea o columnas del modelo de datos se escriben en mayúsculas en el texto y coinciden con los ejemplos que normalmente se proporcionan en tablas o figuras. Los nombres de concepto XBRL siguen las pautas de la Guía de estilo XBRL US y se presentan en mayúsculas y minúsculas. Los valores (como los valores de hecho o los valores de propiedad) se muestran entre comillas (como «12.5» o «true»).
1.1.4 El resultado final
No importa la industria, los requisitos específicos o las necesidades de informes, el objetivo final al final del proceso de desarrollo de la taxonomía es crear datos que sean significativos para los consumidores. Esto es cierto independientemente de cuáles sean esos datos y si se consumen en tiempo real o se recopilan en análisis fuera de línea. La precisión, la usabilidad y la previsibilidad para el consumidor son de vital importancia, y el producto final del desarrollo debe ser lo suficientemente robusto como para ofrecer resultados consistentes en todos estos frentes. Sin embargo, en equilibrio con esto, la carga impuesta a los preparadores debe ser razonable. No debe haber requisitos significativos para los preparadores que parezcan demasiado complicados o bizantinos, y la cantidad de tiempo y costo asociados con la preparación y validación de informes no puede ser prohibitiva. La solución, sea lo que sea, debe ser mantenible y abierta a futuros cambios, lo que también significa que debe ser autodescriptiva, para que esos cambios no causen interrupciones tanto para los consumidores como para los preparadores de datos.
XBRL logra estos objetivos y puede producir este importante resultado final: datos utilizables y significativos. XBRL es un método de transporte de datos de una manera que es autodescriptiva y autónoma. Una taxonomía XBRL puede servir como el centro de cualquier cadena de suministro de información, conectando a los preparadores con los consumidores de una manera estructurada y lógica.
XBRL US es el consorcio sin fines de lucro para los estándares de informes comerciales XBRL en los Estados Unidos. Es la jurisdicción estadounidense de XBRL International (XII). Mientras que XII es responsable de mantener la especificación técnica XBRL, XBRL US se centra en la educación, la creación de conciencia, la promoción y el trabajo de desarrollo en el mercado de los Estados Unidos. XBRL US es una organización de membresía, y su membresía representa muchos eslabones dentro de la cadena de suministro de información comercial, incluidas firmas de contabilidad, empresas, proveedores de datos, consumidores de datos, proveedores de software, proveedores de bases de datos y herramientas analíticas, así como otras organizaciones sin fines de lucro. La misión de XBRL US es apoyar la implementación de estándares de informes comerciales a través del desarrollo de taxonomías para su uso por los sectores público y privado dentro de los Estados Unidos, con el objetivo de la interoperabilidad entre sectores, y promoviendo la adopción de XBRL a través de la colaboración en el mercado.
XBRL US ha desarrollado taxonomías para la contabilidad financiera, así como la calificación crediticia y la presentación de informes de fondos mutuos bajo contrato con la Comisión de Bolsa y Valores de los Estados Unidos. También ha desarrollado taxonomías específicas de la industria para acciones corporativas, financiamiento solar, procesamiento de garantías e informes financieros municipales.
El sitio web de XBRL US ofrece acceso a una base de datos de repositorio para información XBRL y una interfaz de programación de aplicaciones (API) para el desarrollo de software. El código subyacente para el repositorio y la API está disponible para que los miembros puedan configurar bases de datos privadas. Esta es una parte importante de la misión general de XBRL US: proporcionar una estructura consistente, herramientas útiles y pautas para la integridad de los datos para los consumidores actuales y eventuales de XBRL.
Este documento es solo uno de los muchos esfuerzos educativos y de divulgación de XBRL USpara promover informes estables y estandarizados de información comercial. Para obtener más información y otros recursos, visite el sitio web de XBRL US en https://xbrl.us/.
1.3 XBRL: el lenguaje de informes empresariales extensible
1.3.1 XBRL proporciona una plataforma para dar significado a los datos
Esta es la era del big data, y la gente tiene la expectativa de que cualquier pieza de información debe estar fácilmente disponible a su alcance. Además, no solo esa información debe ser accesible, sino que la forma exacta en que se presenta debe adaptarse a las necesidades específicas de un individuo o de una organización. Si la información se recopila utilizando un motor de búsqueda diario o un software especializado (que puede analizar todo, desde los movimientos de los vehículos hasta los hábitos de los teléfonos inteligentes), tener los datos correctos en el formato correcto es clave. La falta de profundidad, contexto y consistencia reduce significativamente la utilidad de los datos y la capacidad de los consumidores para interpretar la información. A pesar de los avances en la ciencia de datos, transmitir el significado más profundo de la información es una lucha continua. La consistencia e integridad de los datos en sí es importante, pero ¿cómo se pueden interpretar esos datos de manera significativa sin contexto? Por ejemplo, algunos puntos de datos pueden ser muy simples: «encendido / apagado» (o 1 y 0). Sin embargo, esta representación binaria de la información dice muy poco. ¿Qué está activado o desactivado? ¿Cuándo está encendido o apagado? Para saber más, hay que añadir un concepto: la «luz» está «encendida». Se puede agregar aún más información a través de conceptos adicionales. Se puede especificar una ubicación: el «porche» «luz» está «encendido». También se puede indicar una hora, lo que lleva a una declaración de datos más interpretable: el «porche» «luz» está «encendido» a las «18:05 UTC».
Sin la capacidad de proporcionar este tipo de información significativa sobre un punto de datos, la mayoría de las personas estarían de acuerdo en que el valor de los datos disminuye. Los estándares de datos que se centran en el intercambio de puntos de datos están diseñados para proporcionar un contexto adicional sobre los datos para que los sistemas y analistas puedan administrar y utilizar esos datos de manera adecuada. Además, este tipo de estándares de datos también deben proporcionar un marco semántico para que ese significado sea interpretado adecuadamente por un sistema informático o persona externa.
Antes de examinar estándares como estos, el proceso de asignar significado a los datos debe examinarse un poco más de cerca. Qué significado debe incluirse con un punto de datos para asegurarse de que se entienda claramente entre los sistemas y las personas será la primera parte de determinar cómo deben estructurarse esos datos y su información contextual relevante.
Figura 1-1. Posibles tipos de información que podrían acompañar a un punto de datos numérico simple
En el lado izquierdo de la Figura 1-1, hay una pieza de datos numéricos primitivos: «1234». Por sí solo, ese punto de datos solo transmite información a un lector si ese destinatario ya está familiarizado con su contexto y propósito. A los efectos de esta discusión, ese punto de datos puede denominarse un hecho. En las capas, se puede agregar significado al hecho definiendo precisión, escala, unidades y otra información similar. El significado contextual también se puede proporcionar a través de otra capa que contiene información como la hora y la ubicación. Finalmente, el hecho se puede identificar con un concepto. Dependiendo del componente semántico del estándar que se utiliza para representar los datos, esta información conceptual podría ser bastante detallada e incluir una gran cantidad de significado adicional. Como se mencionó anteriormente, los estándares de datos estructurados ofrecen sistemas definidos para representar datos de esta manera, agregando capas de contexto significativo que proporcionan formas útiles y predeterminadas de interpretar esos datos. XBRL es uno de esos estándares.
1.3.2 Fondo
A principios de siglo, se emprendió un esfuerzo para representar eficazmente la información empresarial para transmitir y presentar datos a los organismos gubernamentales. XBRL nació para abordar la idea de intercambiar globalmente información comercial en un formato estándar. A partir de 1998, numerosos contadores y otros especialistas en negocios, incluido el Instituto Americano de Contadores Públicos Certificados (AICPA), trabajaron juntos para desarrollar las primeras especificaciones de XBRL y formar lo que eventualmente se convertiría en XBRL International. La primera especificación XBRL se publicó en julio de 2000. La especificación XBRL, que ha sido estable desde su lanzamiento, se introdujo en diciembre de 2003. Desde entonces, XBRL se ha utilizado ampliamente como un estándar de transmisión de información empresarial estructurada.
1.3.3 Transmisión de información
Las empresas reportan datos a reguladores y otras entidades utilizando una multitud de formatos sintácticos, como PDF, Excel, CSV, XML, JSON o a través de la entrada directa de bases de datos en sistemas personalizados. Cada uno de estos formatos fue diseñado y seleccionado teniendo en cuenta los principales requisitos. Por ejemplo, para PDF, o Formato de documento portátil, el nombre se explica por sí mismo; si bien el formato puede emplearse para otros fines, está destinado principalmente a intercambiar documentos de manera confiable entre computadoras. Los datos en los documentos PDF no siempre están destinados a ser extraídos como hechos individuales. Muy a menudo, los requisitos de presentación de informes o intercambio de datos en una situación dictan el formato de datos y los sistemas involucrados.
Desafortunadamente, muchas organizaciones y agencias hoy en día no utilizan un formato de datos consistente, ya sea entre agencias o incluso dentro de una sola organización. Un consumidor de datos que recibe información en diferentes formatos debe utilizar diferentes métodos para extraerla y utilizarla, lo que puede confundir aún más la falta de coherencia. Además, no todos los formatos pueden ser procesados por igual por computadoras. Por ejemplo, un documento PDF, aunque generalmente es legible por las personas, no se garantiza que contenga información textual que pueda ser analizada e interpretada por una computadora. Esto dificulta el uso de datos en un informe PDF y otros formatos. La falta de estructura entre formatos y sistemas tiende a conducir a una incapacidad para recopilar, analizar y recopilar información de manera sistematizada. Uno podría tomar dos informes PDF y anotar y comparar sus datos, pero esta tarea se vuelve significativamente más ardua cuando hay cientos o miles de informes para comparar. Además, la forma en que una entidad informante expresa un punto de datos puede no ser coherente con la forma en que otras entidades representan la misma información. ¿Cómo puede un consumidor de datos relacionar la información presentada de maneras tan dispares?
Los reguladores corporativos han abordado este problema mediante la introducción de mandatos que requieren que las entidades informantes produzcan datos utilizando XBRL. Tales mandatos proporcionan a los funcionarios gubernamentales e inversores datos bien estructurados y bien definidos que se pueden utilizar de diversas maneras sin la pérdida de significado que generalmente se encuentra cuando la información se mueve de un sistema a otro.
XBRL ofrece una gran cantidad de información sobre los datos sin saturar cada punto de datos con propiedades innecesarias mediante el uso de taxonomías, que son documentos estandarizados que describen conceptos y sus relaciones. Las taxonomías pueden contener información tan simple como ubicaciones geográficas o tan compleja como los estándares financieros de los Principios de Contabilidad Generalmente Aceptados de los Estados Unidos (US GAAP). Los datos XBRL también pueden emplear múltiples taxonomías para unir datos a través de múltiples sectores o industrias. La capacidad de XBRL para «etiquetar» datos no estructurados, así como datos tradicionales, lo hace ideal para intercambiar una amplia variedad de información rica entre sistemas. Cuando los datos se etiquetan en XBRL, el sistema de destino sabe a qué se aplican los datos, a qué se refieren, qué marco de tiempo se informa, la unidad o el lenguaje de los datos numéricos o textuales respectivamente, el tipo y la precisión de los datos y, finalmente, qué estándar o regla se utiliza para generar el punto de datos. Además, debido a que el formato XBRL es autodescriptivo, el software XBRL puede proporcionar funcionalidad adicional, como validación y comparaciones matemáticas, con poco o ningún desarrollo adicional cuando ese formato cambia.
Si bien XBRL comenzó siendo utilizado para fines relacionados con el cumplimiento, es un estándar de datos extremadamente versátil con aplicaciones solo limitadas por la imaginación de los arquitectos de taxonomía.
| 1.3.3.1 | XBRL y formatos de datos |
La especificación XBRL define actualmente cómo se capturan y representan los datos en un formato originalmente basado en XML. XML fue seleccionado como el punto de partida para XBRL porque es una excelente plataforma (con una amplia gama de herramientas y soporte) para transportar datos complejos. XML es un «lenguaje de marcado» que utiliza elementos para etiquetar e identificar puntos de datos para que una computadora pueda procesar fácilmente los datos. Además, XML inherentemente permite que los datos contextuales y de otro tipo se incluyan en cada una de esas etiquetas mediante el uso de atributos. Curiosamente, debido a que XBRL es un estándar de datos que establece preceptos en lugar de formato, el vehículo para comunicar los datos podría basarse en otros formatos de datos como JSON. Los beneficios y desventajas de los formatos de datos distintos de XML se describen en la Sección 5.4.3. El hecho de que XBRL tenga flexibilidad en su formato de transmisión lo hace aún más versátil como estándar de informes.
Debido a que las taxonomías XBRL están basadas en XML, pero se extienden sobre esa base, cambiar la información en una taxonomía no requiere que el sistema lea y consuma los datos XBRL para actualizarse a un nuevo estándar con el fin de comprender su significado. Un sistema que lee XBRL puede simplemente «conectar» nuevas taxonomías a medida que están disponibles sin la necesidad de cambiar mediante programación. Esta flexibilidad no tiene paralelo en un estándar de intercambio de datos. Cuando un cambio en el mundo real requeriría un cambio conceptual en el significado de los datos, se puede crear y publicar una nueva versión de la taxonomía en respuesta. Los consumidores de datos tendrían acceso a la nueva información en el mismo instante en que la taxonomía esté disponible.
| 1.3.3.2 | Aplicaciones prácticas e historias de éxito |
El estándar XBRL es ampliamente utilizado para la presentación de informes en todo el mundo. Las implementaciones incluyen informes de empresas públicas y privadas, así como informes de agencias gubernamentales. Existen numerosos programas gubernamentales para reportar información financiera empresarial en XBRL a nivel mundial (Tabla 1-1). Una de las implementaciones más grandes de XBRL como método de transporte de datos que implica regulación es la presentación periódica de informes financieros a la Comisión de Bolsa y Valores de los Estados Unidos (SEC). En este caso, las normas de contabilidad de uso común se incorporaron a las taxonomías de información financiera. Ahora, utilizando esas taxonomías, las empresas públicas informan la información financiera requerida a través del Sistema Electrónico de Recopilación, Análisis y Recuperación de Datos (EDGAR). Con XBRL, los datos financieros están disponibles públicamente para el análisis y el consumo impulsados por máquinas con muy poco retraso o sobrecarga una vez que se presentan los informes. Los bancos que reportan a la Corporación Federal de Seguros de Depósitos (FDIC) representan otra industria donde XBRL sirve como una estructura de transmisión exitosa. Aquí, la taxonomía está muy estrictamente regulada y es utilizada por múltiples bancos para reportar información regulatoria a la FDIC. Estos son solo dos ejemplos de implementaciones exitosas de XBRL en los campos de la regulación gubernamental.
XBRL proporciona una gran ventaja para los informes regulatorios, pero sus usos se extienden más allá del alcance de este tipo de divulgación. Quizás uno de los mejores casos de negocios que se pueden hacer para XBRL es en entornos de colaboración. XBRL es una excelente solución para situaciones que requieren una interfaz común entre diversas empresas. Un ejemplo es el desarrollo de la taxonomía Work in Process (WIP) para proyectos de construcción con horizontes de largos tiempos. Las compañías de seguros de garantía que proporcionan bonos para estos proyectos requieren informes periódicos para que puedan juzgar si el proyecto se completará a tiempo y dentro del presupuesto. Los agentes de fianzas, las compañías de seguros de fianzas, los contratistas y sus auditores están involucrados en este entorno de colaboración. El desarrollo de una taxonomía XBRL en una situación como esta permite que las necesidades comunes de información de los contratistas, agentes de fianzas y fianzas se estandaricen y procesen sin intervención humana.
XBRL agrega un valor significativo en casos de negocios donde los participantes comparten un conjunto común de requisitos de información entre un subconjunto de sus necesidades de procesamiento de negocios.
Tabla 1-1. Ejemplos de implementaciones exitosas de XBRL en todo el mundo
Las taxonomías XBRL pueden servir a grandes industrias, proyectos y conjuntos de datos, pero también pueden resultar útiles en entornos más pequeños. Los departamentos dentro de una empresa o universidad pueden necesitar informarse entre sí de una manera estructurada y predecible, por ejemplo. XBRL es muy adecuado para datos comerciales y financieros, pero no necesita limitarse a esta aplicación. Las taxonomías se pueden construir para reflejar cualquier tipo de información, y las fortalezas de XBRL en informes estructurados pueden beneficiar cualquier situación en la que la integridad de los datos y la interpretabilidad semántica sean esenciales. Para una exploración en profundidad del éxito en la implementación de XBRL como estándar de datos, consulte el Capítulo 10.
Este documento contiene información que ayuda a los lectores a comprender XBRL y sus posibles aplicaciones. Guiará a los lectores a través de la construcción de una taxonomía XBRL. El manual comienza con información para ayudar a los lectores a comprender el modelado de datos (y cómo el modelado de datos se traduce a XBRL) y definir las necesidades del proyecto. Continúa discutiendo la mecánica de construcción e implementación de la taxonomía. Por último, este documento explora el gobierno del sistema de presentación de informes posteriormente. El manual construye una historia que es la creación de una taxonomía XBRL de principio a fin, pero las secciones o capítulos se pueden omitir o leer selectivamente sin pérdida de continuidad.
Capítulo 1 – Introducción – Una sinopsis del Manual de Desarrollo de Taxonomía y XBRL.
Capítulo 2 – Una introducción a XBRL – Una visión general de XBRL, sus principios y sus convenciones. Dentro de esta introducción hay una discusión general de cómo XBRL es diferente de otros estándares de intercambio de datos como XML básico, JSON o CSV.
Capítulo 3 – Estructuración de datos – Una discusión de los métodos para organizar los datos dentro de una instancia y las opciones para estructurar los datos dimensionales.
Capítulo 4 – Evaluación del alcance general del proyecto – Una discusión de cómo las partes interesadas y los casos de uso afectan el modelo de datos.
Capítulo 5 – Creación de un modelo de datos de transporte – Una revisión en profundidad de la toma de un modelo de datos y la aplicación de las partes interesadas debe crear un modelo de transporte XBRL.
Capítulo 6 – Validación – Establece varios métodos para validar datos XBRL.
Capítulo 7 – La mecánica del desarrollo de taxonomía – Instrucciones detalladas sobre la construcción de una taxonomía en XML.
Capítulo 8 – Documentar una taxonomía – Una discusión sobre cómo documentar una taxonomía para su uso por preparadores, desarrolladores y consumidores de información.
Capítulo 9 – Gobernanza de la taxonomía – Instrucciones para el mantenimiento continuo de una taxonomía implementada.
Capítulo 10 – Historias de éxito – Una revisión de las implementaciones del mundo real de XBRL.
Apéndice A – Información de apoyo de XBRL y XML – Una colección de información técnica para ayudar a comprender y utilizar XBRL.
Apéndice B – Lista de verificación de creación de taxonomía – Una lista de verificación básica de elementos «por hacer» para crear una taxonomía.
Apéndice C – Esquema y plantilla del libro blanco de taxonomía – Información para ayudar en la creación de un proyecto «libro blanco» para describir el proceso de desarrollo de una taxonomía.
Apéndice D – Plantilla de descripción general de XBRL – Una sección de descripción general de XBRL de ejemplo que se incluirá en la documentación de taxonomía.
Apéndice E – Esquema y plantilla de la Guía de taxonomía – Un esquema para una Guía de taxonomía consolidada que debe ser utilizada por los usuarios de una taxonomía, incluidos los preparadores, los consumidores y los desarrolladores de software.
Apéndice F – Esquema y plantilla de la Guía del preparador – Un esquema para una Guía del preparador separada destinada a ayudar a los preparadores a utilizar la taxonomía desarrollada.
Apéndice G – Esquema y plantilla de la Guía del consumidor de datos – Un esquema para una Guía del consumidor de datos separada destinada a demostrar a los consumidores de datos cómo la información en la taxonomía se puede aplicar a casos de uso comunes.
Apéndice H – XBRL US Taxonomy Approval Metrics – Información sobre cómo una taxonomía puede ser revisada y aprobada por XBRL US.
Apéndice I – Situación de la propiedad intelectual – Una visión general de las consideraciones relativas a la propiedad intelectual y una declaración de P.I. de ejemplo.
Apéndice J – Estado de la revisión del documento – Una discusión del estado del Manual de Desarrollo de Taxonomía, incluidas las revisiones pertinentes.
Apéndice K – Revisiones y comentarios públicos – Una discusión de los comentarios públicos y las revisiones relevantes.
Glosario – Un glosario de términos utilizados para XBRL y dentro de este documento.
1.4.1 Especificaciones de soporte
Este documento no es una especificación, sino más bien una guía para ayudar en el desarrollo de taxonomías bien formadas, así como para establecer las mejores prácticas en el desarrollo y la gestión.
Durante el desarrollo de esta guía se confió en la siguiente documentación. Se anima a los lectores a familiarizarse y cumplir con los siguientes documentos:
Extensible Business Reporting Language (XBRL) Specification – La Extensible Business Reporting Language Specification,de XBRL International (XII), contiene la información sin procesar sobre la implementación de XBRL en XML. Define elementos y atributos XML que se pueden usar para expresar la información utilizada en las tareas de creación, intercambio y comparación de informes empresariales. Tenga en cuenta que la terminología de la especificación XBRL está centrada en XML.
Modelo de información abierta XBRL: el modelo de información abierta (OIM) describe los métodos para transmitir información XBRL de una manera independiente de la sintaxis. Explora tanto JSON (JavaScript Object Notation) como CSV (Comma Separated Values) mientras revisa parte de la terminología para trabajar en tales entornos. La especificación OIM se suministra con ejemplos y documentos complementarios.
Especificación de dimensiones XBRL: la especificación de dimensiones XBRL proporciona un mecanismo generalizado para definir metadatos dimensionales y hacer referencia a ellos en instancias XBRL. Define una arquitectura tal que cualquier documento XBRL (instancias y sus conjuntos de taxonomía detectables) que se ajuste a la especificación puede ser analizado sin error por cualquier procesador que sea capaz de procesar correctamente XBRL, incluso si esos procesadores desconocen la extensión modular.
Registro de tipos de datos XBRL: el Registro de tipos de datos XBRL (DTR) contiene los tipos de datos definidos por XBRL. Estos son adicionales a los tipos de datos XML estándar. Además, hay dos especificaciones proporcionadas, la Especificación del proceso y la Especificación de la estructura, que describen más a fondo la estructura del DTR y los pasos a través de los cuales se le puede agregar un nuevo tipo de datos.
Especificación de precisión, decimales y unidades XBRL: la especificación XBRL Precision, Decimals and Units especifica más información relacionada con la precisión numérica, la expresión decimal y las unidades de los hechos XBRL (los atributos de hecho @precision y @decimals). Este documento amplía la información proporcionada en la Especificación XBRL y también ofrece más ejemplos de convenciones utilizadas en la práctica.
Especificación de fórmula XBRL: la especificación de fórmula XBRL describe métodos para proporcionar validación adicional que no proporciona la especificación XBRL base a través de fórmulas XBRL. La especificación explica los métodos de uso de fórmulas y otros enfoques para probar rigurosamente las relaciones de datos dentro de un documento de instancia.
Registro de unidades XBRL: similar al Registro de tipos de datos XBRL, el Registro de unidades XBRL (UTR) define las unidades permitidas por XBRL para hechos numéricos. Hay más documentación sobre la estructura y la sintaxis del registro, así como información sobre el proceso mediante el cual se pueden agregar nuevas unidades.
Registro de transformación XBRL: el Registro de transformación XBRL contiene las reglas y métricas mediante las cuales se realizan las transformaciones en XBRL en línea. Estas reglas describen cómo el texto descriptivo en documentos XBRL en línea se puede representar como tipos de datos XBRL.
1.4.2 Documentos de apoyo
Otros documentos importantes para el desarrollo de la taxonomía incluyen:
XBRL US Style Guide – La XBRL US Style Guide ayuda a mantener la coherencia en todos los aspectos de XBRL, incluido el estilo, como un componente crítico para la implementación exitosa de las taxonomías XBRL. En la guía se establecen objetivos para: a) proporcionar una base para el desarrollo y mantenimiento coherentes de las taxonomías; b) aumentar la eficiencia y la eficacia de las taxonomías; c) mejorar la extensibilidad de la taxonomía para los usuarios finales y los desarrolladores de taxonomías; d) maximizar la comparabilidad de los datos, reducir la ambigüedad de los datos y promover la normalización de los datos; e) aumentar la compatibilidad de las taxonomías; f) mejorar la fiabilidad y la coherencia de los conceptos, las etiquetas y la documentación; y g) reducir el costo de la aplicación de la taxonomía.
XBRL US Taxonomy Approval Metrics – El documento Taxonomy Approval Metrics (TAM) establece estándares para la revisión y aprobación de la taxonomía XBRL por parte del XBRL US Domain Steering Committee (DSC) con los siguientes objetivos: (a) permitir un intercambio significativo de información entre diferentes sistemas comerciales; b) evitar confusiones y dificultades en la configuración inicial de los sistemas de preparación y consumo de información basada en XBRL; (c) proporcionar a los desarrolladores de taxonomía una comprensión clara de las expectativas de los requisitos del Proceso de Aprobación de Taxonomía del Comité Directivo de Dominios (DSC) de XBRL US.
1.4.3 Software y herramientas de soporte
Hay varios paquetes de software y herramientas disponibles gratuitamente que pueden ayudar en el desarrollo de taxonomía y la preparación de documentos de instancia XBRL o la extracción de datos. Son los siguientes:
Arelle – Arelle es una plataforma de código abierto para XBRL que puede ser utilizada como una aplicación de escritorio e integrada con otras aplicaciones y lenguajes a través de su servicio web. Existen numerosos complementos para permitir la interfaz con Excel, Java, Oracle, fuentes RSS, documentos XBRL individuales y SQL y otras bases de datos. Arelle se cubre con más detalle en el Capítulo 6 como un medio para visualizar y facilitar el desarrollo de la taxonomía.
API XBRL – Desarrollada por XBRL US, la API XBRL (Application Program Interface) ayuda a los usuarios a acceder a datos XBRL oportunos y estructurados con alta resolución. La API estandarizada permite a los desarrolladores y utilidades de datos emplear una única interfaz para recopilar datos de un repositorio/instancia XBRL. Los desarrolladores pueden usar la API para conectar una base de datos personalizada a un front-end de software. La API ayuda a rellenar automáticamente esa base de datos y permitir que los usuarios la recopilen para su análisis.
Más información sobre la API de XBRL está disponible en el sitio web de XBRL US y en la documentación de la API (http://files.xbrl.us/documents/XBRL-API-V1.4.pdf).
Aplicaciones de hoja de cálculo / procesamiento de textos – Hay numerosos paquetes de software gratuitos que ofrecen capacidades de hoja de cálculo y procesamiento de textos. Estas utilidades básicas pueden ayudar a redactar planes y documentación del proyecto, así como a crear la taxonomía en sí. Junto con Arelle, las hojas de cálculo se pueden utilizar para diseñar los elementos de la taxonomía de una manera legible por humanos y bien organizada. Las aplicaciones gratuitas se ofrecen en:
| • | Google Docs (http://docs.google.com/ ) |
| • | LibreOffice (http://www.libreoffice.org/ ) |
| • | Microsoft Office Online (http://www.office.com/ ) |
Tenga en cuenta que XBRL US no respalda ninguno de estos productos, y algunos pueden requerir cuentas válidas con el proveedor para su uso. Además, algunas funcionalidades pueden requerir la compra. XBRL US tiene una lista de algunos proveedores de software XBRL en su sitio web en https://xbrl.us/.
2.1.1 Por qué XBRL
XBRL fue desarrollado para automatizar el proceso de intercambio de información. El intercambio de información podría ocurrir dentro de una organización o con grupos externos, como otras entidades de una industria, reguladores, mercados y organizaciones no gubernamentales. Los requisitos conceptuales para el desarrollo de XBRL incluyeron la creación de un sistema que sea extensible, definible y que permita comparaciones entre sus puntos de datos. XBRL también tenía que poseer la capacidad de mantener o transportar una amplia variedad de datos, admitir representaciones de datos estandarizadas y ser independiente del software de tal manera que los estándares se puedan usar a través de muchas aplicaciones de software diferentes.
XBRL sirve principalmente como un método que transmite simultáneamente datos legibles por máquina con información sobre cómo interpretar y contextualizar esos datos. Esto contrasta con otros métodos de transmisión de datos, donde un solo punto de datos a menudo carece de información adicional para mejorarla o dilucidarla. El uso de XBRL como estructura de datos garantiza que los puntos de datos correctamente formateados serán interpretados por el sistema receptor con todo el significado requerido para interpretar esos datos, independientemente del sistema de origen, el momento de interpretación o el método de transmisión. En la arquitectura de datos, esto se conoce como interoperabilidad semántica. La interoperabilidad semántica se logra mediante la adición de información que vincula cada elemento de datos a un vocabulario bien definido y compartido entre los sistemas involucrados en la creación, transmisión, almacenamiento y uso de esos datos. Esto permite un paquete de información que es autodescriptivo y, por lo tanto, independiente de su sistema de información de origen y capaz de ser leído por cualquier sistema de destino. La interoperabilidad semántica subyacente es la interoperabilidad sintáctica, que es la sintaxis por la cual dos o más sistemas se comunican entre sí, junto con una ontología definida que debe ser capaz de adaptarse a términos nuevos y cambiantes. XBRL proporciona la base para estas dos facetas importantes de la transmisión de datos: una especificación sintáctica que se basa en estándares comunes para transmitir información y un medio para proporcionar una ontología (una taxonomía XBRL) para identificar el significado de esa información dentro de un marco semántico bien definido (Figura 2-1).
Hay muchos estándares para formatear, transmitir, almacenar y presentar información, y cada uno está diseñado para un propósito específico. A diferencia de muchos otros estándares de datos, XBRL permite el transporte simultáneo de estructura y significado, y su ontología se puede adaptar para adaptarse a una amplia gama de propósitos e industrias. Este manual examina cómo XBRL puede convertirse en una parte integral de una solución de arquitectura de datos.
| 2.1.2 | El modelo de datos de transporte |
La tarea de un desarrollador de taxonomía XBRL es tomar un modelo de datos semánticos que represente datos comerciales u otros datos y crear un modelo de transporte para propagar esos datos a los consumidores de datos. Un modelo de transporte sirve como estructura organizativa al mover datos de una fuente a un consumidor (Figura 2-2). XBRL es un ejemplo de un modelo de transporte. Los modelos de transporte pueden ser complejos y dinámicos, como XBRL, o pueden ser simples. En cierto sentido, el acto de rellenar un formulario en papel o electrónico que contiene campos para conjuntos de información crea un modelo de transporte. El formulario toma datos de un preparador de manera organizada y luego permite a los consumidores usar esos datos según sea necesario. Por supuesto, puede haber limitaciones muy obvias para un modelo de transporte basado en formularios, como el hecho de que el formulario puede no ser legible por máquina, pero esto ilustra el concepto de que el modelo es el formato que permite que los datos se muevan de una fuente a un consumidor de una manera significativa.
En un entorno del mundo real, una entidad de informes puede usar una variedad de aplicaciones para administrar y almacenar datos empresariales. Dichos datos pueden contener información del cliente / cliente, productos, inventario, investigación, contabilidad e información de modelado. Desde el punto de vista de la tecnología de la información, los puntos de datos deben encajar en un modelo semánticoideal, donde la dimensionalidad de ese modelo proporciona un conjunto de datos autodescriptivo a pesar de que los segmentos pueden existir en sistemas separados en plataformas separadas. En la mayoría de los casos, no toda la información del modelo semántico se coloca en el modelo de transporte por una variedad de razones que van desde la confidencialidad, la profundidad o el historial de la información, o simplemente no se requieren los datos. Además, es posible que sea necesario crear o calcular algunos puntos de datos en el modelo de transporte a partir de puntos dentro del modelo semántico. Como resultado, los datos del modelo semántico deben filtrarse o prepararse.
Los modelos de transporte también pueden considerarse como un eslabón de una cadena de suministro de información. La cadena de suministro se refiere a los sistemas de las organizaciones, las personas, los recursos y los procesos para mover datos de una fuente (un modelo de datos empresariales o semánticos) a un consumidor. Las cadenas de suministro pueden ser muy complicadas, involucrando a múltiples partes y modelos de información, o pueden ser simples. También es importante tener en cuenta que en la figura 2-2, los datos profesionales y el modelo semántico variarán de una entidad informante a otra, mientras que el modelo de transporte seguirá siendo el mismo para todas las entidades informantes. Además, el modelo de transporte puede o no coincidir con el modelo de negocio de origen o el modelo de consumidor. El desafío para los desarrolladores es crear un modelo de transporte que esté estrechamente alineado con todos los requisitos de las partes interesadas y que sea fácil de entender y expandir para adaptarse a los requisitos futuros.
XBRL proporciona el formato del modelo de transporte y un informe XBRL contiene la información que se intercambia entre los sistemas que utilizan ese modelo de transporte. La fuerza definitoria y unificadora detrás del modelo de transporte XBRL estructurado es la taxonomía. Con una taxonomía bien definida, cualquier consumidor de datos dentro de un informe XBRL debería poder leer e interpretar adecuadamente esos datos.
El lado derecho de la Figura 2-2 es el modelo de consumidor. Los consumidores pueden adoptar diversas formas y pueden tener requisitos muy diversos. Cada uno tendrá sus propios modelos específicos y puede combinar datos de otras fuentes para respaldar su producto de trabajo final. Los consumidores representan partes interesadas importantes en el proceso de desarrollo, y se deben considerar sus necesidades con respecto a la forma en que se organizan los datos informados.
Tenga en cuenta que la Figura 2-2 guarda silencio sobre la mecánica real de transmisión y almacenamiento de datos. En muchas arquitecturas, existe un sistema de informes que recibe, valida, acepta, almacena y potencialmente distribuye datos. En algunos casos, el sistema de informes puede ser una transacción segura y privada, mientras que en otros, como el sistema EDGAR de la SEC, los datos son privados hasta que son aceptados por un sistema regulatorio y luego se almacenan en un archivo disponible públicamente. Los sistemas de notificación pueden adoptar la forma de una sola entidad a otra única entidad de transmisión, o pueden ser tan grandes y complejos como un repositorio de múltiples entidades.
Muchos detalles del sistema de informes (que los desarrolladores de taxonomía aún pueden tener la tarea de diseñar) están más allá del alcance de este documento. Sin embargo, hay aspectos del sistema de informes que pueden afectar al proceso de diseño del modelo de transporte. La naturaleza del formato de transporte de datos elegido (estos formatos se introducen en la siguiente sección) puede influir en las decisiones sobre cómo se estructura la taxonomía. Es importante destacar que si un sistema de informes se considera abierto o cerrado puede tener profundas ramificaciones de diseño en la taxonomía. En un sistema de informes abierto, los preparadores pueden ampliar la taxonomía XBRL para incluir construcciones XBRL de otras taxonomías o de su propio diseño. Esto permite la generación de informes específicos dela entidad, donde los preparadores pueden crear o utilizar sus propios métodos de representación de sus datos. En un sistema de informes cerrado,la taxonomía XBRL no puede ser extendida por los preparadores, lo que requiere que utilicen la taxonomía tal como la publican los desarrolladores de la taxonomía. Si bien esto es más limitante en términos de datos específicos de la entidad, mejora la facilidad de análisis y la usabilidad de los informes XBRL, ya que los informes de diferentes preparadores deben estructurarse exactamente de la misma manera. Permitir la extensibilidad en un sistema de informes es una decisión compleja que equilibra la comparabilidad (la medida en que uno o más informes XBRL se pueden comparar directamente) con la personalización. Tampoco es una solución «de todo o ninguno»; hay muchos casos en los que los desarrolladores permiten una extensibilidad muy específica, pero por lo demás estructuran una taxonomía estrictamente. La extensibilidad y sus implicaciones se discuten a lo largo de este manual.
| 2.1.2.1 | XBRL como modelo de transporte |
XBRL proporciona un conjunto estándar de reglas que definen cómo se pueden transportar los datos (que pueden ser una amplia gama de tipos, incluidos monetarios, enteros, de texto y booleanos). Como se mencionó anteriormente, un informe XBRL (también llamado documento de instancia) sirve como vehículo de transmisión o almacenamiento para los datos informados. Una taxonomía XBRL dicta cómo se deben organizar los datos de ese informe. La taxonomía solo se puede crear en XML, pero la taxonomía se puede usar para generar documentos de instancia XBRL en formato XML, JSON, HTML (XBRL en línea) o CSV. XBRL International, que dirige el desarrollo continuo de la especificación XBRL,ha creado versiones XBRL de estos formatos que son capaces de transportar intrínsecamente información semántica junto con los valores informados.
Las cuatro opciones de formato para un documento de instancia XBRL son las siguientes:
XBRL como XML: en este modo, los datos de instancia se almacenan en formato XML según lo dictado por la especificación XBRL. XML proporciona la construcción de esquemas personalizados para expresar una amplia gama de tipos de datos utilizando elementos para delinear y «marcar» (o etiquetar,como se le llama coloquialmente) datos. XBRL se basa en XML al agregar relaciones más allá de la simple herencia padre-hijo, así como información contextual adicional. Se pueden proporcionar bases de enlaces adicionales para definiciones, referencias, etiquetas, cálculos y presentaciones.
XBRL en línea: XBRL en línea (iXBRL) permite incrustar los datos de la instancia en un documento XHTML. Esta es la principal ventaja de iXBRL, que los datos legibles por máquina se encuentran justo dentro del informe legible por humanos. Los requisitos de esquema y base de enlaces son los mismos que con XML.
JSON – JSON, o JavaScript Object Notation, es un formato de texto que proporciona la expresión de datos estructurados complejos. Varios lenguajes de programación crearán y leerán JSON de forma nativa. Para XBRL, el modelo de información abierta, que es un modelo independiente de la sintaxis de datos XBRL desarrollado por XBRL International, proporciona una especificación para almacenar información de instancia en un informe XBRL-JSON. JSON solo permite el transporte de información de instancia. Si las extensiones son permitidas en el documento de instancia y se utiliza JSON, se debe crear un esquema (taxonomía de extensiones) en XML para acompañar al archivo JSON.
CSV – CSV (Valores separados por comas o delimitados por comas) es otra opción para el transporte. Sin embargo, dada la estructura limitada de CSV, los archivos deben tener un formato específico con información complementaria para conectar datos estructurales XBRL clave. CSV puede ser una buena opción para reportar información altamente estructurada donde solo los hechos cambian de un informe a otro. El modelo de información abierta también proporciona una especificación para almacenar información de instancia en un informe XBRL-CSV. Al igual que con JSON, si se necesitan extensiones, se debe crear un esquema (taxonomía de extensiones) en XML para acompañar al archivo CSV.
El formato utilizado para el documento de instancia depende del preparador de la información y/o del sistema de informes. En este momento, otros formatos de datos no tienen la estructura para transportar información semántica, sin la cual los valores informados no pueden entenderse y consumirse automáticamente.
2.1.3 Dando significado a los puntos de datos
La información se puede recopilar y organizar en texto, tablas, variables con nombre, matrices y a través de otros métodos. Sin embargo, con muchos de estos métodos, cada valor reportado carece de características de identificación adicionales. Además, dependiendo del idioma y la plataforma, puede haber diferentes tipos de datos o convenciones de nomenclatura. Todo esto puede conducir a comparaciones confusas entre diferentes conjuntos de datos y a dificultades para transmitir la información de un sistema a otro.
El objetivo de XBRL es transportar datos que estén organizados de manera significativa. Los datos se pueden organizar en un patrón apropiado dependiendo de la aplicación, como tablas, cubos, o tal vez en una estructura jerárquica,por ejemplo (Figura 2-3). Cada punto de datos en un modelo de datos semántico de origen puede tener una relación (a veces llamada arco)con otros puntos de datos que es demostrativa de su significado semántico. XBRL agrega profundidad a los puntos de datos al agregarles dimensiones XBRL. Las dimensiones XBRL definen el significado semántico de los datos, su periodicidad, su entidad de informe y otra información descriptiva. En conjunto, las dimensiones de un conjunto de datos representan información semántica significativa y ayudan a los consumidores a comprender no solo lo que significa cada punto individual, sino también cómo todos los puntos dentro del conjunto se relacionan entre sí.
Más allá de la representación de datos estructurados, XBRL también ofrece varias características importantes. En primer lugar, los datos se pueden representar en una forma legible por humanos, ya sea como una presentación estructurada o como parte de un texto de documento HTML como Inline XBRL o iXBRL. En segundo lugar, se puede transmitir información adicional tanto para puntos de datos específicos como para relaciones. Por ejemplo, un punto de datos puede transmitir información sobre el tipo de datos, su precisión o puede tener una nota textual adjunta. Además, XBRL es autodescriptivo, lo que significa que la taxonomía en sí misma instruye a los sistemas receptores cómo leer e interpretar la estructura de datos. No hay necesidad de bibliotecas, documentos o formatos adicionales. XBRL también es extensible, lo que permite tanto a los desarrolladores construir sobre taxonomías preexistentes como a los preparadores crear sus propias construcciones XBRL para reflejar sus circunstancias específicas de informes (si lo permiten los desarrolladores). Finalmente, XBRL tiene múltiples métodos para hacer cumplir y fomentar la integridad y validación de los datos. Estos temas se abordarán a lo largo de este manual para permitir a los desarrolladores aprovechar las muchas fortalezas de XBRL en sus soluciones de informes.
A la izquierda de la Figura 2-4, hay categorías de gastos (Columna A, convencionalmente considerada como partidas). Las categorías de gastos incluyen comida, entretenimiento, combustible, alquiler, etc. Los tipos de gastos se informan por el mes en que se produjo el gasto (Columnas B-E). Los puntos de datos aparecen en la intersección de la categoría y el mes. Por sí mismos, los valores de estos valores tienen muy poco significado, pero cuando se toman en relación con la orientación de filas y columnas, cada punto de datos gana contexto semántico. Esta es una representación muy típica, simple y tabular de datos, donde los puntos de datos están definidos por una idea conceptual y un marco de tiempo contextual al que pertenece ese valor. En XBRL, esta combinación de un punto de datos y un conjunto de dimensiones XBRL pertenecientes a ese punto de datos se denomina hecho.
2.2.2 El hecho (una intersección de dimensiones y datos)
En XBRL, un hecho es la intersección única de un conjunto de dimensiones XBRL con un punto de datos. La figura 2-5 ilustra la estructura básica de un hecho. La información arbitraria, como un número o un nombre o incluso una sección corta de texto, no tiene información semántica o contextual en sí misma. Una vez que las dimensiones XBRL, que agregan información semántica, se cruzan con ese punto de datos, ahora se convierte en un hecho XBRL.
El valor de los datos puede ser de casi cualquier forma. Por ejemplo, si la referencia pertenece al número de widgets producidos por una empresa de fabricación de widgets, sería un valor numérico. Si el dato es una descripción narrativa de los desafíos de producción de widgets, sería textual.
En el ejemplo de gastos simples (Figura 2-4), el gasto para Ropa en el contexto de enero, que tiene un valor de 180, sería un hecho XBRL. También hay dimensiones implícitas, algunas de las cuales aparecen en la Figura 2-6.
La Figura 2-7 ilustra la intersección de la dimensión central del concepto y otra dimensión XBRL. Una vez más, en relación con el ejemplo de gastos, la dimensión es la dimensión del período enero y la dimensión central del concepto es RopaExgastos.
Múltiples conceptos a lo largo de la dimensión del concepto pueden cruzarse con la misma dimensión secundaria (como se muestra en la Figura 2-8). Mirando hacia atrás al ejemplo de gastos, incluir múltiples conceptos de partidas agrega un nivel simple de dimensionalidad a los datos. Un conjunto de conceptos (como FoodExpenses, RentExpenses, RopaGastos y utilidadesGastos) que se cruzan con una sola dimensión de período (enero) se pueden visualizar de la siguiente manera:
Una vez más, esto es análogo a los elementos de línea en una tabla u hoja de cálculo con la dimensionalidad de los datos expresada como el encabezado de la columna. Cuando hay varios períodos de informes (por ejemplo, para los dos primeros meses de gastos), se definen varias dimensiones XBRL, como en la Figura 2-9.
En este caso, los conceptos serían las partidas de la Figura 2-4 (como Gastos de alimentos, Gastos de alquiler y Gastos de servicios públicos). Los períodos estarían representados por las columnas (enero, febrero, etc.). Una vez más, cada lugar donde una dimensión conceptual y una dimensión de período se cruzan es un hecho (en este caso, una cantidad monetaria ubicada en la celda), y la combinación de la información contextual proporcionada por el concepto y otras dimensiones (el período) crean las dimensiones XBRL de ese hecho.
2.2.3 Dimensiones
Como se mencionó anteriormente, una dimensión XBRL es información que sirve para identificar de forma única un hecho (Figura 2-5). Una dimensión puede ser una dimensión central (que incluye el concepto dimensión central, dimensión núcleo del período, dimensión central de la entidad informante y dimensión núcleo unitaria) o una dimensión definida por la taxonomía. Estos se discuten con mayor detalle más adelante en este capítulo.
Cada dimensión XBRL agrega información contextual única a un punto de datos. La dimensión central del concepto confiere un significado semántico básico a un punto de datos, como FoodExpenses o FuelExpenses como se muestra en los ejemplos anteriores. Dentro de una instancia, dimensiones similares cruzan hechos para formar tablas, cubos o estructuras más complejas. Cada hecho que se cruza es siempre único.
También puede haber, y a menudo hay, múltiples dimensiones asociadas con un hecho. Por ejemplo, en el conjunto de datos de gastos, las columnas representan dimensiones de período y, como se indicó anteriormente, las filas podrían considerarse dimensiones básicas del concepto. Juntas, estas son las dimensiones de cualquier hecho dado.
Los hechos pueden tener una o más de las siguientes dimensiones: la dimensión central del concepto, la dimensión central de la entidad, la dimensión del núcleo del período, la dimensión del núcleo de la unidad, la dimensión del núcleo del lenguaje, la dimensión del núcleo del ID de la nota y las dimensiones definidas por la taxonomía.
| 2.2.3.1 | Dimensión central del concepto |
Cada hecho debe tener una dimensión básica del concepto tal como se define en la Sección 2.2.5. La dimensión central del concepto proporciona un significado semántico para un hecho. También define ciertas propiedades sobre los hechos asociados con él, incluido el tipo de datos de un hecho. Puede encontrar más información sobre los tipos de datos en la Sección 2.3.1.
| 2.2.3.2 | Dimensión central de la entidad |
La dimensión central de la entidad define la entidad para la que se informa del hecho. La entidad debe notificarse utilizando un identificador común que sea único para la entidad y que no cambie. Por ejemplo, un identificador de persona jurídica (IPJ), un número del IRS o un número del Comité de Procedimientos Uniformes de Identificación de Valores (CUSIP) es un identificador estático que se puede vincular a una entidad específica en un informe financiero. Del mismo modo, un número de seguro social identifica de manera única a una persona que trabaja en los Estados Unidos y no cambia con el tiempo. Los desarrolladores deben evitar el uso de identificadores que cambien o sean ambiguos. Además, dado que los informes pueden ser públicos, el uso de identificadores que contienen información privada, como números de seguro social, puede no ser aconsejable.
Una dimensión central del período define el período de tiempo relevante para el hecho. El período puede ser uno de dos tipos: un instante o una duración. Considere de nuevo el ejemplo del informe de gastos. Los gastos totales del mes se consideran una duración porque los datos se miden desde el comienzo del mes hasta el final del mes. Un período instantáneo representa una medición que ocurre en un punto específico en el tiempo. Por ejemplo, el dinero en una cuenta bancaria en un día determinado es una medida instantánea, el dinero disponible en ese momento.
La periodicidad de los datos debe ser de una resolución que tenga sentido para los datos en sí. Una vez más, para un informe de gastos, una dimensión de período mensual es lógica. Sin embargo, el crecimiento a largo plazo de un fondo de mercado puede dictar el uso de una dimensión de período para representar un año o incluso más. Por el contrario, los totales de lluvia podrían representarse en días. Las dimensiones del núcleo del período instantáneo se expresan utilizando una sola fecha. Las dimensiones del período de duración se expresan utilizando una fecha de inicio y una fecha de finalización que marcan el comienzo y el final del período, respectivamente.
Al igual que la dimensión central del concepto, la dimensión central del período es necesaria para todos los hechos. Si el punto de datos describe información que no cambia con el tiempo, como datos genéticos, fechas de nacimiento o una constante como pi, un período se puede definir como «para siempre». La dimensión central del período debe estar de acuerdo con las propiedades de la dimensión central del concepto. Si la propiedad de tipo de período del concepto se define como «instantánea», solo una dimensión central de período instantáneo puede cruzarse con hechos que tienen ese concepto. Del mismo modo, si el tipo de período del concepto es «duración», solo una dimensión central del período de duración puede cruzarse con esos hechos. Para obtener más información sobre las propiedades del concepto, consulte la Sección 2.2.6.2.
| 2.2.3.4 | Dimensión del núcleo de la unidad |
La dimensión del núcleo unitario indica la unidad de medida de un hecho. Una unidad de medida es una magnitud de una cantidad, definida y adoptada por convención o por ley. Una unidad de ejemplo sería «USD» (dólares estadounidenses) para los valores monetarios o «metros» para la longitud. Las unidades se expresan como una lista de unidades numeradoras con una lista opcional de unidades denominadoras. Esto permite unidades compuestas, como «dólares/acción» o «millas/hora». También permite unidades que son un cuadrado algebraico, como los metros2 especificando múltiplo de la unidad en el numerador.
La dimensión del núcleo de la unidad está dictada por la propiedad de tipo de datos de la dimensión del núcleo del concepto. Por ejemplo, «kilovatio-hora» o «megavatio-hora» sería una unidad apropiada para los hechos con un concepto llamado EnergyProduced, que expresa la cantidad de electricidad total creada por una planta de energía. La dimensión del núcleo unitario solo se aplica a las dimensiones del núcleo del concepto que tienen tipos de datos numéricos.
XBRL da la flexibilidad de expresar hechos en diferentes unidades en el mismo plano como un concepto de intersección y dimensión de unidad. La unidad añade significado a un valor numérico. Por ejemplo, «3» es un valor escalar sin significado intrínseco. Cuando se asocia con un concepto, se puede saber que el valor es monetario. Sin embargo, el tipo específico de unidad monetaria aún no está claro. Agregar una unidad «USD» indicaría dólares estadounidenses, mientras que «CAD» sería dólares canadienses. Se puede expresar más de una unidad, lo que permite valores USD y CAD para el mismo punto de datos con una diferenciación unitaria adicional.
Un conjunto de unidades estándar se define en el Registro de Unidades XBRL. El Registro de Unidades XBRL tiene cientos de unidades definidas para calificar datos que van desde la moneda hasta las mediciones, como medidores, voltios y hectáreas (ver Registro de Unidades XBRL).
Al expresar un hecho numérico, debe contener una referencia unitaria (véase XBRL 2.1, §4.6.2 El atributo @unitRef). Los hechos con un tipo de datos de «cadena» no tendrán ninguna referencia de unidad asociada.
| 2.2.3.5 | Dimensión central del lenguaje |
La dimensión central del idioma especifica el idioma en el que se informa de un hecho no numérico. Los valores de idioma deben representarse con un código de idioma BCP 47 válido (para obtener más información, consulte IETF BCP 47). Las dimensiones básicas del lenguaje solo deben estar presentes en las dimensiones básicas del concepto que permiten la información textual y son opcionales en este caso.
Si se espera que los datos se utilicen en un entorno multilingüe, se recomienda encarecidamente que se emplee la dimensión central del idioma. Tenga en cuenta que para los informes que se consumirán en un entorno principalmente de habla inglesa (o un entorno en el que solo se espera un idioma), generalmente se puede omitir la dimensión central del idioma.
| 2.2.3.6 | Nota Dimensión del ID del núcleo |
La dimensión ID principal de la nota vincula una nota al pie o un conjunto de notas al pie a uno o más hechos. En la sección 2.2.9 se describe más información sobre la dimensión id del núcleo de la nota y las notas al pie de página XBRL.
| 2.2.3.7 | Dimensiones definidas por taxonomía |
Una dimensión definida por la taxonomía es un concepto que existe con el propósito de agrupar hechos que deben interpretarse de manera similar. Las dimensiones definidas por la taxonomía se explorarán con mayor detalle en secciones posteriores. Por ahora, considere las dimensiones definidas por la taxonomía como conceptos que no definen directamente un hecho, sino que se cruzan con un hecho para agregar más información contextual o semántica más allá de lo que se agrega por las dimensiones centrales ya discutidas.
2.2.4 Detalles de la dimensión XBRL
Mirando hacia atrás en el ejemplo de gastos, las dimensiones XBRL deben definirse para que cada hecho se represente en XBRL. Por ahora, un enfoque simplista que haga uso de los conceptos discutidos anteriormente puede ser beneficioso para comprender cómo definir y usar las dimensiones XBRL. Debido al tipo de datos en el informe de gastos, algunas de las dimensiones XBRL serán las mismas para todos los hechos.
Las dimensiones básicas relevantes para el ejemplo de gasto utilizado se enumeran en la Tabla 2-1:
La naturaleza de los datos dicta cómo se aplican estas dimensiones XBRL. Por ejemplo, en el ejemplo anterior, los gastos son valores monetarios medidos en dólares estadounidenses, lo que sugiere utilizar una dimensión básica unitaria de «USD». La entidad en el ejemplo es «Bob’s Household» (que no es un identificador ideal, pero es suficiente para un ejemplo simple). La dimensión central del lenguaje no se aplica en este caso porque los datos no contienen hechos textuales. De lo contrario, estas dimensiones son aplicables a todos los datos de la tabla de gastos.
La dimensión central del período, sin embargo, cambia de una columna a otra. Para la primera columna, la dimensión de período representa el mes de enero. La siguiente dimensión representa febrero y así sucesivamente. Con todas estas dimensiones definidas, los conceptos y las dimensiones centrales, cada celda de datos en la tabla se puede representar como un hecho XBRL.
Hay varias formas de organizar los datos y las relaciones. Además, hay casos en los que es necesario desglosar datos similares. Por ejemplo, Bob puede querer desglosar sus gastos por parte de sus dependientes. Las dimensiones centrales anteriores seguirán siendo las mismas, pero ahora el hecho puede calificarse o dimensionarse aún más mediante relaciones de datos adicionales. Esto se explora en la Sección 2.2.8. Por ahora, las dimensiones del núcleo XBRL se explorarán como un medio para agregar un significado semántico especificado a los datos.
| 2.2.5 | Conceptos |
Un concepto es un identificador semántico tal como lo define la taxonomía. Los conceptos son los bloques de construcción básicos de una taxonomía, y todas las dimensiones de datos dentro de esa taxonomía se refieren a las relaciones entre conceptos. El término dimensión central del concepto se refiere solo a aquellos conceptos que definen la idea semántica que un valor de datos está destinado a representar. Se pueden utilizar otros tipos de conceptos como contenedores organizativos para dimensiones básicas de conceptos que están relacionadas semánticamente. Estos se denominan conceptos de agrupación,y definen estructuras dentro de una taxonomía, como una estructura de tabla XBRL o un dominio de valores posibles. Otros conceptos pueden organizarse a lo largo de una dimensión definida por la taxonomía para especificar ejes a lo largo de los cuales varían los hechos.
Debido a que los conceptos son la unidad básica de información semántica y estructural en XBRL, los conceptos tendrán una posición relacional con respecto a otros conceptos dentro de la taxonomía. La combinación de dimensiones básicas de conceptos con conceptos de agrupación y los conceptos que componen las dimensiones definidas por taxonomía se puede utilizar para crear estructuras complejas con significado semántico autodescriptivo. Por ejemplo, un hecho puede tener una dimensión central del concepto de SalesRevenue, y esto podría cruzarse con la dimensión definida por la taxonomía Región, que puede tener miembros de concepto más diferenciadores como EasternRegion y WesternRegion. Todo esto puede estar contenido por un concepto que defina una tabla de SalesByRegion.
Como se ilustra en la Figura 2-10, las dimensiones centrales del concepto definen un valor de hecho. Los conceptos de agrupación se utilizan para agrupar conceptos que están relacionados semánticamente. Las dimensiones definidas por taxonomía organizan los conceptos para definir la dimensionalidad adicional. Las dimensiones definidas por taxonomía pueden o no tener conceptos miembros. Una vez más, se analiza más información sobre las dimensiones definidas por la taxonomía y cómo agregan dimensionalidad a los hechos de XBRL en las Secciones 2.2.8 y El Capítulo 3.
Los conceptos tienen propiedades que definen su uso y los tipos de datos que pueden describir, lo que se analiza con mayor detalle en la siguiente sección. Las propiedades de un concepto también dictan los otros tipos de dimensiones XBRL que pueden cruzarse con los datos.
| 2.2.6 | Detalles del concepto |
| 2.2.6.1 | Visión general |
Los identificadores de concepto definen los hechos en el nivel semántico más básico. ¿Cómo se implementa el significado semántico detrás de estos puntos de datos numéricos en XBRL?
Un examen más profundo del ejemplo de gastos arroja algunas respuestas. Considere nuevamente la Figura 2-4, donde las categorías de gastos son filas (partidas) y las columnas representan los meses en los que ocurrieron esos gastos. Debido a que este ejemplo es tan simple, los elementos de línea de la tabla (Columna A) se prestan naturalmente para convertirse en las dimensiones centrales del concepto. Cada uno de estos conceptos, como FoodExpenses, EntertainmentExpenses, etc., está vinculado a un valor numérico en las columnas B-E, produciendo los comienzos de un hecho XBRL. La definición de conceptos no solo define los identificadores discretos y semánticos en la taxonomía, sino que también permite que las propiedades de los conceptos agreguen más información cualitativa a los puntos de datos.
Además de definir la información semántica asociada a un hecho, los conceptos mismos tienen propiedades. Estas propiedades pueden considerarse como formas de caracterizar los datos a los que se puede vincular el concepto. Esto puede incluir el tipo de datos (numéricos, textuales), si los datos pueden ser nulos o indefinidos, o si el concepto en sí mismo puede asociarse con los datos en absoluto.
En el ejemplo presentado anteriormente, estos conceptos son todos gastos, por lo que pueden tener las mismas propiedades. Una vez más, este es un enfoque simplista; para los datos reales, las propiedades de los conceptos deben variar con la información que están destinados a representar. Por ahora, una vista simplista puede ayudar a ilustrar los tipos básicos de propiedades que los conceptos pueden poseer y cómo se asignan a un conjunto de datos del mundo real. La Tabla 2-2 define las posibles propiedades de un concepto y cómo se representan en el ejemplo de gastos.
Una vez más, la naturaleza de los datos conduce a estas opciones de propiedad. Por ejemplo, los gastos son siempre valores monetarios expresados durante un mes. Además, debido a que estos gastos siempre deben tener un valor, no son nillables.
Los valores de estas propiedades para cada concepto se almacenan en la propia taxonomía. El esquema de taxonomía se define mediante la especificación XBRL y está en formato XML. El ejemplo 2-1 es un extracto de un esquema de taxonomía XBRL que muestra la definición del concepto de uno de los conceptos de ejemplo:
La etiqueta de elemento describe el concepto XBRL mediante la sintaxis XML. La sintaxis XML es la misma sintaxis que los documentos de esquema XML. Para obtener más información sobre el esquema XML, consulte el Apéndice A. Los atributos del elemento XML representan las propiedades del concepto como se ha descrito anteriormente. Los atributos con el espacio de nombres «xbrli» se definen en el esquema de instancia XBRL. Para obtener más información sobre el esquema de instancia XBRL, consulte el Apéndice A.
| 2.2.6.3 | Denominación del concepto |
Como uno podría imaginar, una taxonomía con muchos conceptos exige una buena organización y nombres de conceptos consistentes. La Guía de estilo de XBRL US define métodos de nomenclatura y restricciones para evitar problemas en la creación y el mantenimiento de una taxonomía. Para estar de acuerdo con ese documento y reflejar la coherencia, los nombres de concepto en este Manual usarán nombres en mayúsculas (FoodExpense en lugar de foodExpense).
La cantidad de texto descriptivo a incluir en un nombre de concepto también puede ser difícil de determinar. Como ejemplo, ¿cómo se debe nombrar un concepto utilizado para los hechos que expresan la máxima disipación de calor de los componentes eléctricos? Las siguientes son todas las posibilidades:
ElectricalComponentHeatDissipation
ComponentHeatDissipation
MaximumElectricalComponentHeatDissipation
MaximumElectricalComponentHeatDissipationInWatts
TotalMaximumElectricalComponentHeatDissipationInWatts
Hay muchas opciones, pero se deben tener en cuenta ciertas reglas al crear nombres de conceptos. Por ejemplo, agregar «vatios» al nombre se considera una mala práctica porque «vatios» es una unidad (que debe ser dictada por la dimensión del núcleo de la unidad). Los nombres de concepto deben contener un sustantivo. Si hay ambigüedad en torno al uso de un sustantivo en un nombre conceptual, se deben agregar adjetivos para indicar claramente el tipo de sustantivo. En general, los nombres de conceptos deben reflejar mejor el significado semántico del concepto, al tiempo que son concisos, evitan un lenguaje descriptivo excesivo y siguen la terminología comúnmente utilizada en la industria. Por ejemplo, el nombre conceptual PropertyPlantAndEquipmentNet es conciso y apropiadamente descriptivo en lugar de PropertyPlantAndAccumulatedDepreciation. InventoryAllocated es preferible a InvestoryForUseInWorkOrdersAndForUseInSalesOrder. Los nombres de concepto también deben evitar hacer referencia a otros nombres de conceptos para determinar su significado.
Antes de definir los nombres de concepto, se debe revisar la Guía de estilo de XBRL US.
| 2.2.6.4 | Etiquetas conceptuales |
XBRL define un complemento de conceptos llamados etiquetas o roles de etiqueta. Dado un uso específico, las etiquetas y los roles de etiqueta proporcionan más información y documentación asociada con un concepto. Por ejemplo, el rol de etiqueta predeterminado para el concepto descrito en la sección anterior podría ser «Disipación de calor continua máxima en un entorno operativo normal», mientras que el rol de etiqueta de documentación podría especificar información más detallada.
Los roles de etiqueta también se pueden usar para ayudar a los preparadores a comprender cómo se debe usar o no un concepto. Por ejemplo, si no se define un rol total, los preparadores pueden asumir que el concepto no debe usarse como un total.
2.2.7 Propiedades de los hechos
Los hechos heredan propiedades de su dimensión central del concepto. Estos incluyen el tipo de datos y si el hecho es o no nillable. Como se dijo en la sección anterior, estas propiedades se determinan a través de la dimensión central del concepto, en lugar del hecho en sí. Sin embargo, los hechos poseen propiedades con respecto a la precisión y la escala que son específicas del hecho. Por ejemplo, el concepto EmployeeTurnoverRate puede tener un tipo de datos que requiere un número decimal, y esto se aplicaría a todos los hechos asociados con este concepto. Sin embargo, un hecho con este concepto puede tener una propiedad decimal especificada que indicaría la precisión de ese hecho en particular y solo ese hecho.
Los nombres y tipos de propiedades que se pueden especificar hecho por hecho cambian, dependiendo del formato de transporte. Consulte la especificación del formato de transporte específico para obtener más información.
Como se indicó anteriormente, hay muchas dimensiones XBRL para organizar los hechos. Hasta ahora, las dimensiones que se definen en la especificación XBRL han sido el foco de este capítulo. Estas dimensiones centrales, como la dimensión central del concepto y la dimensión central del período, pueden proporcionar un significado y una estructura adicionales útiles a los datos. Sin embargo, a menudo habrá una necesidad de organizar los hechos mediante una estructura personalizada. También hay ocasiones en que un modelo de datos simple con una o dos dimensiones de datos no puede representar con precisión la complejidad de las relaciones entre los puntos de datos. En estos casos, agregar más dimensionalidad es un paso clave para construir un modelo de datos XBRL. Por ejemplo, una cadena minorista puede querer informar sus ganancias por región y tiempo, o una industria agrícola podría necesitar indicar el crecimiento de los cultivos tanto por tipo de cultivo como por los tipos de fertilizantes utilizados. En XBRL, esto se puede lograr agregando capas de dimensionalidad personalizada a través de dimensiones definidas por taxonomía.
Una dimensión definida por la taxonomía es una agrupación de conceptos que se utiliza para agregar estructura organizativa a los hechos. Estos conceptos dimensionales no deben asociarse directamente con un punto de datos, sino que se emplean para indicar información contextual adicional más allá del simple identificador semántico o lo que se proporciona a través de cualquiera de las otras dimensiones centrales. Ampliar el ejemplo de gastos atribuyendo los gastos mensuales a dos personas en el mismo hogar crea un nivel de complejidad que no se puede representar fácilmente con solo conceptos. Anteriormente, solo había dos dimensiones: gastos (como filas) y meses (como columnas). Si el conjunto de datos rastreara los gastos de los hijos de Bob, Jared y Allyson, se agregarían más columnas de la siguiente manera:
Dentro de la Figura 2-11, se expresan dos dimensiones de «persona» en los datos, Jared y Allyson, para cada mes, haciendo un total de tres dimensiones para el modelo de datos resultante: conceptos (elementos de línea o filas), puntos (columnas) y persona (subcolumnas). ¿Cómo se puede adaptar la taxonomía XBRL para mostrar esta capa añadida de dimensionalidad? Se podrían agregar conceptos adicionales como parte de la dimensión central del concepto, tales como FoodExpensesForJared y FoodExpensesForAllyson, pero esto podría volverse rápidamente engorroso y tedioso una vez que el conjunto de datos se vuelva lo suficientemente grande y complejo.
Una dimensión definida por la taxonomía proporciona una respuesta a esta situación al desagregar los gastos del hogar de Bob. Esta nueva dimensión XBRL está definida por un concepto que representa la naturaleza de un eje en el conjunto de datos. En el ejemplo, se agregaría un concepto llamado Persona a la taxonomía. Las buenas prácticas también dictarían que se adjunte un sufijo al nombre de este concepto para indicar que se trata de una dimensión definida por la taxonomía y que no debe utilizarse como dimensión básica del concepto. En otras palabras, este nuevo concepto no debe usarse directamente con ningún hecho. Para obtener más información sobre los sufijos, consulte la Guía de estilo XBRL. Esto haría que el concepto se llamara PersonAxis.
Ahora que hay un concepto para describir la dimensión definida por la taxonomía, se deben describir los componentes, o miembros,de esta dimensión. En el ejemplo, estos serían Jared y Allyson, las dos personas que pertenecen a la entidad informante, «Bob’s Household». Por lo tanto, pertenecen al nuevo PersonAxis. XBRL ofrece numerosas formas de expresar estos componentes, pero para este ejemplo, se utilizarán conceptos llamados Jared y Allyson. Una vez más, las buenas prácticas de estilo y la claridad sugieren agregar un sufijo a estos nombres de concepto para indicar que no deben usarse como dimensiones centrales del concepto. Por lo tanto, se llamarán JaredMember y AllysonMember. Para un análisis más profundo sobre las otras opciones para expresar los componentes de una dimensión definida por la taxonomía, véase la Sección 3.4.2.
Las dimensiones definidas por taxonomía permiten una flexibilidad aún mayor en los datos, ya que se puede agregar cualquier número de ejes adicionales al modelo de datos. En este ejemplo, se usaron para desagregar datos compuestos en dimensiones de datos adicionales, pero las dimensiones definidas por taxonomía se pueden usar para representar muchos otros tipos de escenarios de arquitectura de datos. El diseño de las dimensiones XBRL se describe en el Capítulo 3.
| 2.2.8.1 | Contextos en XML y XBRL en línea |
Al preparar XBRL en XML o XBRL en línea, los preparadores pueden proporcionar referencias únicas que definen la dimensión del núcleo de la entidad, la dimensión del núcleo del período y, si está disponible, las dimensiones definidas por la taxonomía. Esta agrupación de referencias, que se denominan contextos,permite al preparador crear una sola agrupación una vez y aplicarla a múltiples hechos. Por ejemplo, en el ejemplo de gastos, se podría crear un contexto para representar el período enero más la entidad Bob’s Household más el componente Jared de la dimensión person definida por la taxonomía. A este contexto, que se muestra en el Ejemplo 2-2, se le ha dado el nombre de JanuaryForJared. Se puede utilizar para identificar múltiples hechos en la tabla de gastos. La ventaja de usar contextos es que la combinación de dimensiones definidas por período/entidad/taxonomía solo debe crearse una vez y se puede usar varias veces. Son un identificador abreviado para un conjunto complejo pero constante de información que se aplica a numerosos hechos. Usar contextos es similar a usar pronombres (él, ella, ellos, él) en lugar de usar un nombre propio una y otra vez. Con el contexto definido, es más fácil referirse a él en lugar de decir o «deletrear» la información nuevamente.
Con el contexto definido, el ejemplo XBRL se puede actualizar para usarlo. Recuerde, para XBRL en XML y XBRL en línea, estas dimensiones se agregan al elemento de contexto XBRL, así que primero examine la definición de contexto actualizada:
Ahora hay un segmento para el contexto. Un segmento es una forma de agregar dimensiones definidas por taxonomía. Este segmento utiliza la dimensión example:PersonAxis y el componente para esa dimensión example:JaredMember. El identificador del contexto también cambió para reflejar esta dimensión XBRL. Tenga en cuenta que los identificadores de contexto se utilizan para vincular hechos a contextos y no tienen ningún significado por sí solos. El hecho ahora usa este identificador para el contexto. Los segmentos se analizan con más detalle en la Sección 3.5.5.
La figura 2-12 ilustra cómo se utilizaría el contexto JanuaryForJared en el ejemplo de gastos. Este contexto se puede utilizar para los diez hechos reportados como se muestra a continuación. Diferentes dimensiones básicas del concepto (para gastos de alimentos, gastos de combustible, etc.) se cruzarían con el contexto de JanuaryForJared para representar hechos separados.
| 2.2.8.2 | Representación de dimensiones en otros formatos de transporte |
JSON y CSV no admiten el uso de contextos. Estos enfoques manejan la adición de dimensiones definidas por taxonomía de manera diferente. La sintaxis JSON para este cambio aparece en el ejemplo 2-4.
En JSON, se ha agregado la dimensión XBRL adicional al hecho, que utiliza la dimensión definida por la taxonomía como clave y el concepto miembro como valor. De esta manera, se pueden incluir dimensiones adicionales definidas por la taxonomía.
Para obtener un ejemplo más completo de cómo representar un informe XBRL en JSON, XML y XBRL en línea, consulte la Sección A.6.
Tradicionalmente, una nota a pie de página agrega más información explicativa a una declaración o hecho. En XBRL, las notas al pie se crean a través de relaciones entre el texto de la nota y los hechos utilizando las relaciones de nota al pie. Una instancia del texto de la nota al pie de página se puede vincular a múltiples hechos. La dimensión ID del núcleo de la nota es la dimensión sobre el hecho que asocia el hecho con uno o más arcos de notas al pie. Obsérvese que, dado que más de un hecho puede hacer referencia a la misma nota al pie, la dimensión central del ID de la nota no confiere ninguna singularidad al hecho.
Con una mejor comprensión de lo que implica un hecho XBRL, queda claro que el hecho es la unidad básica del modelo de transporte XBRL. Con sus dimensiones XBRL, el hecho representa de forma única los puntos de datos dentro del modelo de datos semántico y se vuelve autodescriptivo. Los consumidores de datos pueden interpretar el hecho según sea necesario con la información proporcionada a través de la dimensión XBRL, las relaciones con otros hechos y el contenido del hecho en sí.
Sin embargo, una faceta clave de esta interpretación, y una de las fortalezas y propósitos de XBRL como modelo de datos, es mantener la legibilidad de la máquina. Si bien XBRL ofrece los medios para conectar formatos legibles por humanos con legibilidad por máquina, su propósito es permitir que un sistema consumidor tome sus hechos y los realinee adecuadamente a los modelos de datos del consumidor y las estructuras de informes. El sistema que recibe el informe XBRL debe ser capaz de interpretar correctamente el modelo de transporte y todos sus hechos. Por lo tanto, es el trabajo del desarrollador de taxonomía XBRL garantizar que los hechos XBRL sean consistentes y aparezcan de una manera predecible y anticipada.
XBRL describe un formato para el almacenamiento, la organización y el transporte de datos. La mayoría del software XBRL puede proporcionar funcionalidad adicional, como validación y comparaciones matemáticas. Debido a que XBRL describe su propio modelo de datos, el software puede realizar estas tareas adicionales con poco o ningún desarrollo adicional.
Una faceta clave del mantenimiento de una estructura consistente y predecible relacionada con un hecho XBRL es definir claramente el tipo de datos del hecho. Los tipos de datos se han discutido brevemente, pero esta sección tiene como objetivo profundizar en explicar cómo los tipos de datos en XBRL permiten la legibilidad de la máquina. Para que un sistema de consumo pueda traducir adecuadamente los hechos XBRL entrantes, esos hechos deben ajustarse a las expectativas de ese sistema con respecto a los tipos de datos. La selección del tipo de datos también es fundamental para ayudar en la validación y documentación del contenido del hecho según lo intersectado por el concepto. Por ejemplo, si un tipo de datos especifica que el valor de un hecho debe ser positivo y distinto de cero, entonces se convierte en una cuestión simple para el software XBRL indicar una entrada errónea o informar un error de hecho.
En un nivel básico, un tipo de datos define el conjunto de valores posibles para un hecho. Los tipos de datos pueden ser simples, como un entero, o pueden tener restricciones adicionales, como un entero no negativo. Los tipos de datos generalmente se pueden agrupar como numéricos o no numéricos. Los tipos de datos numéricos se pueden utilizar en operaciones matemáticas. No pueden contener texto. Los tipos de datos no numéricos no están destinados a ser utilizados matemáticamente. Por ejemplo, un punto de datos que expresa un número de identificación fiscal puede expresarse solo en dígitos. Sin embargo, el tipo de datos para ese hecho no debe ser numérico, ya que no hay ninguna razón lógica para realizar operaciones matemáticas en este identificador.
Como se indicó anteriormente, el tipo de datos de un hecho está determinado por la propiedad de tipo de datos de su dimensión central del concepto. En consecuencia, el tipo de datos del concepto debe estar dictado por la naturaleza de los datos que se pretende representar. Un concepto que representa la producción total de energía de una planta de energía, por ejemplo, sugiere un tipo de datos que permite la precisión decimal. Del mismo modo, un concepto que describa el número de personas que responden a una encuesta debe dictar un tipo de datos enteros.
XBRL deriva sus tipos de datos de los tipos de datos XML estándar. La Tabla 2-3 contiene una muestra de tipos de datos XBRL comunes.
Muchas taxonomías estándar contienen tipos de datos adicionales. Los desarrolladores también pueden crear sus propios tipos de datos. La extensibilidad del tipo de datos se describe en la Sección 3.6.1.1. Debido a que los tipos de datos están integrados en XML, cualquier programa que pueda comprender XML podrá validarlos a un nivel básico, incluso tipos de datos personalizados que se extiendan correctamente desde los tipos de datos estándar. Consulte el Apéndice A para obtener más información sobre los tipos de datos XML.
2.3.2 Consistencia matemática
Los hechos con un tipo de datos numéricos deben tener una propiedad decimal o de precisión que indique cuán matemáticamente preciso es el valor del hecho. Debido a que todos los hechos numéricos deben tener precisión, el software XBRL puede mantener la precisión al realizar cálculos matemáticos. Dado esto, al comparar un valor calculado versus un valor de hecho, el software XBRL puede acomodar automáticamente los errores de redondeo.
2.3.3 Transformación e interpretación
Existen varios formatos para expresar valores para tipos de datos, como números y fechas. XBRL utiliza formatos específicos para estos tipos de datos según lo regulado por la especificación XML. Sin embargo, Inline XBRL ofrece instrucciones adicionales para que el software XBRL convierta expresiones legibles por humanos de esta información en el formato de tipo de datos apropiado. Por ejemplo, una fecha XBRL debe estar en formato ISO 8601, pero muchas fechas textuales están escritas en lenguaje descriptivo. Una transformación XBRL describe cómo se puede convertir el lenguaje descriptivo al formato adecuado. Para obtener una lista de reglas y más información, consulte el Registro de transformación XBRL.
Inline XBRL también ofrece una propiedad de escalado en hechos individuales para indicar al software XBRL que el valor del hecho debe escalarse antes de ser interpretado. Por ejemplo, una tabla de hechos puede expresarse en millones sin los ceros finales para ayudar en la legibilidad humana, pero Inline XBRL debe tener una escala adecuada para que el valor de 123 se interprete como 123000000.
Con una comprensión de alto nivel de las construcciones básicas de XBRL y cómo esas construcciones se cruzan para representar un hecho, los desarrolladores de XBRL ahora pueden explorar la estructura y los componentes de una taxonomía de XBRL. Como se mencionó anteriormente, las taxonomías XBRL definen un modelo de datos semánticos utilizado para el transporte entre los preparadores de origen y los consumidores, quienes potencialmente tienen modelos de datos semánticos propios para almacenar, analizar e informar datos. Una taxonomía XBRL puede representar relaciones semánticas dentro del modelo de origen o del modelo de consumidor, y también puede definir sus propias relaciones dependiendo de lo que se requiera. Hasta ahora, la discusión en este documento se ha centrado en cómo se representan los hechos de XBRL en un informe XBRL con sus dimensiones asociadas, pero sin la taxonomía y su hoja de ruta de cómo las dimensiones se relacionan entre sí, el informe XBRL carece de significado.
Aunque las taxonomías XBRL pueden diferir mucho en cuanto a la naturaleza de los datos que pretenden representar, todas las taxonomías emplean las mismas estructuras, herramientas y reglas XBRL para funcionar como un modelo de transporte.
| 2.4.1 | Características de la taxonomía |
El propósito básico de una taxonomía es organizar los conceptos en una jerarquía. Una jerarquía define cómo los conceptos se relacionan entre sí. A menudo se visualiza como una estructura de árbol (Figura 2-13).
Hay tres estructuras básicas que se pueden visualizar dentro de una taxonomía: cálculos, presentacionesy definiciones. Los tres están presentes en la Figura 2-13. Más adelante en esta sección y en el Capítulo 3 se examinan más sobre estos temas. Las taxonomías suelen poseer uno o más puntos de entrada. Un punto de entrada es una colección de grupos de conceptos que se han unido para un uso específico. Por ejemplo, un punto de entrada puede consistir en todas las presentaciones, cálculos y definiciones que son relevantes para la banca dentro de una taxonomía de informes financieros. Los puntos de entrada ayudan a organizar los conceptos por su uso y pueden ayudar a los preparadores a navegar por una taxonomía y localizar las secciones que se aplican a sus necesidades de informes. Solo los conceptos del punto de entrada deben utilizarse para describir los datos expresados por ese punto de entrada, aunque pueden existir otros conceptos para otros puntos de entrada. En otras palabras, el punto de entrada debe contener todos los conceptos necesarios para expresar completamente los datos representados por ese punto de entrada.
Tenga en cuenta que cada elemento en la estructura de la taxonomía es de hecho un concepto, aunque sólo los conceptos que caen directamente debajo de una tabla en la Figura 2-13 son conceptos que pueden cruzarse con hechos; estas son dimensiones centrales del concepto. Los otros conceptos son conceptos miembros u otros contenedores estructurales, como tablas y ejes. Esto representa la agrupación de conceptos,que es una forma de definir relaciones jerárquicas dentro de la taxonomía. Los grupos de conceptos pueden contener cualquier número de otros conceptos y grupos de conceptos, al igual que una rama de un árbol puede conectarse a muchas ramas más pequeñas, algunas de las cuales también conducen a muchas otras ramas, y así sucesivamente. Esta estructura jerárquica y los nombres de concepto representan el modelo de datos de transporte.
Para un modelo jerárquico XBRL, cada nodo (o elemento del árbol) se considera un concepto. De esta manera, un concepto identifica una posición única dentro de la taxonomía para un elemento de datos específico, una dimensión XBRL o una agrupación de dimensiones. El concepto raíz (o nodo) está en la parte superior del árbol y puede representar un punto de entrada o una presentación.
Por ejemplo, la Figura 2-14 refleja una estructura jerárquica para representar tipos de aeronaves.
La primera columna especifica el nombre del concepto. La segunda columna representa la etiqueta estándar para el concepto. Por ejemplo, CommonDomainMembersAbstract tiene una etiqueta que indica que es un resumen (que se analiza con más detalle en la siguiente sección). La etiqueta del concepto CommonTable indica que es un contenedor de tabla. Esto puede parecer redundante, pero es importante ya que cada concepto puede tener múltiples etiquetas asociadas para diferentes roles. En la siguiente sección se explica más sobre cómo los nombres de concepto y las propiedades influyen en sus roles.
Los hijos del concepto tienen sangría en este caso. Esta es una forma común de expresar la relación padre/hijo. El padre de un concepto es un nodo un paso más arriba en la jerarquía. Los hermanos de un concepto comparten el mismo concepto de padre. Cabe señalar que si bien XBRL utiliza una estructura jerárquica para organizar conceptos, la relación padre/hijo dentro de XBRL no implica ni permite la herencia de propiedades. Por ejemplo, si bien los conceptos que se muestran en la Figura 2-13 y la Figura 2-14 son hijos de los conceptos de tabla y eje, no heredan las propiedades de esos conceptos de tabla o eje padre. También debe tenerse en cuenta que, si bien los conceptos pueden tener diferentes roles y existir dentro de múltiples presentaciones diferentes, existen relaciones específicas definidas entre conceptos dentro de al menos uno de estos tipos de estructuras de relación. El concepto A no puede ser un padre del concepto B si los conceptos A y B no están dentro de la misma estructura jerárquica en algún punto de entrada de la taxonomía. Más sobre las relaciones entre padres e hijos se discute en la Sección 3.4.4.
Una taxonomía no tiene que ser una organización única y autónoma. Las taxonomías pueden hacer referencia y contener otras taxonomías. Las taxonomías externas a las que se hace referencia de esta manera se conocen como un conjunto de taxonomía detectable (DTS) para la taxonomía principal. Las taxonomías externas pueden hacer referencia a taxonomías adicionales. Todas las taxonomías de esta cadena son necesarias para entender la taxonomía principal. Emplear un DTS es muy útil, ya que permite a los desarrolladores basarse en los estándares existentes para aplicaciones específicas.
2.4.2 Propiedades del concepto y cómo relacionan los conceptos entre sí
La organización, selección y denominación de los conceptos son fundamentales para crear una taxonomía bien formada que coincida con la aplicación de datos del mundo real. Cada concepto tiene propiedades asociadas, como se discutió anteriormente. En términos de estructura y organización de la taxonomía, el nombre del concepto, la propiedad abstracta y la propiedad del grupo de sustitución pueden expresar el uso del concepto dentro de la taxonomía. A menudo, los tres deben abordarse adecuadamente para indicar el papel de un concepto.
La primera de estas propiedades es el nombre del concepto, que, como se discutió anteriormente, es un nombre legible por máquina creado para describir el concepto de manera consistente. Las convenciones de nomenclatura deben emplearse siguiendo ciertas reglas de estilo (consulte la Guía de estilo de XBRL US para conocer los estilos de lenguaje y referencia). Cabe destacar en este caso el uso de sufijos específicos para indicar el papel de un concepto. Los sufijos deben agregarse a ciertos nombres de conceptos para ayudar a los usuarios a distinguir entre sus usos (por ejemplo, «Resumen» para un concepto abstracto, «Miembro» para un concepto que es un miembro del eje o «Eje» para el contenedor de conceptos para un eje). Estos sufijos se introdujeron brevemente en la Sección 2.2.8, donde se definieron conceptos de ejemplo pertenecientes a dimensiones definidas por taxonomía en XBRL.
La segunda propiedad es la propiedad abstracta. Los conceptos que en realidad no se cruzan con los hechos a menudo tienen su propiedad abstracta establecida en «verdadero». Esto indica específicamente que un concepto no es una dimensión central del concepto, sino más bien un elemento organizativo. Los conceptos de agrupación deben tener la propiedad abstracta establecida en «true».
Por último, está la propiedad de grupo de sustitución. La propiedad de grupo de sustitución puede ayudar a definir el papel de un concepto más específicamente agrupándolo con otros conceptos similares. Los conceptos con el mismo grupo de sustitución tienen usos similares. Los grupos de sustitución de ejemplo incluyen dimensión, elemento o hipercubo.
Estas ideas se discutirán con mayor detalle en los capítulos 3 y 5. En este punto, es importante entender que las propiedades del concepto son vitales para definir el papel del concepto en la taxonomía y cómo cada concepto se relaciona con otros conceptos dentro de la taxonomía.
| 2.4.3 | Componentes de una taxonomía |
Prácticamente, una taxonomía se compone de dos componentes principales: documentos de esquema y una o más bases de enlaces. La combinación de las bases de enlaces y el esquema es lo que hace que la taxonomía sea autodescriptiva. Cada uno de los componentes de una taxonomía se describe en las siguientes secciones. Todas las taxonomías XBRL deben definirse en XML utilizando construcciones XML, independientemente de si los datos que se van a informar se transportan realmente en XML.
| 2.4.3.1 | Esquema |
Un esquema hace referencia a una descripción de un documento XML. El esquema suele expresar restricciones sobre la estructura y el contenido de un documento XML por encima de las restricciones sintácticas simples del propio lenguaje XML. Para usar una analogía, XML se puede considerar como un alfabeto para un lenguaje escrito. El esquema XML es como un diccionario que contiene todas las palabras permitidas, sus definiciones y sus usos gramaticales. Con estos componentes combinados, el lenguaje se puede utilizar para escribir una historia. Con un esquema XML, se pueden definir las construcciones de la taxonomía y su uso.
XBRL también requiere el uso del formato de definición de esquema XML (XSD) para describir los elementos del esquema. Los esquemas suelen incluir información como declaraciones de elementos (conceptos), declaraciones de atributos y definiciones de propiedades para conceptos. También pueden incluir tipos de datos personalizados. Más información sobre el desarrollo de la parte del esquema de una taxonomía está disponible en el Capítulo 5.
| 2.4.3.2 | Bases de enlaces |
Si el esquema XML es el diccionario de la taxonomía, la base de enlaces es un esquema de la historia y una introducción sobre cómo organizar sus muchos capítulos. Una base de enlaces muestra cómo los conceptos de la taxonomía se relacionan entre sí. Las bases de enlaces logran esto a través de la declaración de los arcos,que pueden considerarse como un origen, un destino y la naturaleza de la relación entre ellos. Existen arcos entre conceptos o entre conceptos y otros recursos, algunos de los cuales pueden ser externos a la taxonomía misma.
Al igual que el documento de esquema, las bases de enlaces deben definirse con construcciones y estándares XML y cumplir con ellos. Existen múltiples tipos de bases de enlaces. Uno o más de cada tipo pueden existir en una taxonomía. Si el sistema de informes permite la extensibilidad, los preparadores pueden definir versiones personalizadas de uno o más de estos tipos de bases de enlaces.
| 2.4.3.2.1 | Relaciones de presentación |
La base de enlaces de presentación define una o más estructuras jerárquicas de los conceptos. Esto permite que la taxonomía se organice correctamente, y permite que el software de renderizado XBRL cree representaciones visuales de la taxonomía que sean legibles por humanos y fácilmente navegables. Los preparadores que utilizan la taxonomía pueden ver la jerarquía de conceptos, lo que proporciona un significado adicional más allá de las dimensiones XBRL (Figura 2-15).
Las etiquetas conceptuales (discutidas en la Sección 2.2.6.4) son particularmente importantes dentro de una presentación. Las etiquetas instruyen al software de renderizado (como Arelle) sobre cómo mostrar la presentación y qué etiquetas asociar con los conceptos de la jerarquía de presentación. También pueden dictar cómo se interpreta el concepto dentro de una presentación específica. Los conceptos pueden tener varias etiquetas diferentes definidas (como etiquetas de presentación, etiquetas concisas y etiquetas detalladas). Cada uno está diseñado para diferentes propósitos de visualización o interpretación. Por ejemplo, los elementos de línea de presentación pueden tener ciertas características, como si un hecho numérico debe mostrarse en su forma negada. La presentación de datos para «Ingresos (pérdidas)» puede ser una situación en la que un hecho negativo representa esa pérdida, pero ese hecho puede presentarse como positivo para una presentación específica legible por humanos. Esto se lograría con una etiqueta negada. Encontrará más información sobre la definición de etiquetas conceptuales en la Sección 7.2.3.1.
Además, las bases de enlaces de presentación ayudan aún más en la representación jerárquica al especificar los niveles de sangría (profundidad) de los conceptos involucrados en esa presentación. Esto es lo que crea la representación visual de «árbol» de la presentación y su jerarquía de conceptos.
Las presentaciones también están estrechamente relacionadas con la base de enlaces de definiciones (descrita posteriormente). Junto con las definiciones linkbase, las presentaciones describen la inclusión o exclusión de dimensiones particulares definidas por la taxonomía en la representación de la presentación.
| 2.4.3.2.2 | Relaciones de cálculo |
Las bases de enlaces de cálculo definen relaciones matemáticas entre conceptos. Esto permite que el software XBRL compruebe la coherencia de los valores que aparecen en los documentos de instancia XBRL. De esta manera, una base de vínculos de cálculo proporciona reglas de validación básicas para documentos de instancia creados utilizando la taxonomía a la que está asociada la base de vínculos de cálculo. Al igual que la base de enlaces de presentación, las relaciones de cálculo son jerárquicas de modo que todos los conceptos que pertenecen a un arco de cálculo se suman o se restan entre sí. De esta manera, un concepto de nivel superior puede convertirse en el resultado de un cálculo matemático predefinido (Figura 2-16).
| 2.4.3.2.3 | Relaciones de definición |
Las bases de enlaces de definición proporcionan otra forma de definir las relaciones entre conceptos. Se puede incluir una variedad de arcos en una base de enlaces de definición, como arcos para indicar que un concepto es una versión especializada de otro o para requerir el uso de un concepto en caso de que se use otro. Estos arcos pueden ser definidos a medida o de uso común. Las relaciones estándar definidas por una base de enlaces de definición se describen en la Sección 3.4.4.3.
Las bases de enlaces de definición están estrechamente relacionadas con las bases de enlaces de presentación. Las definiciones definen las dimensiones definidas por taxonomía que se permiten dentro de una presentación a través de sus definiciones de hipercubo. Los hipercubos que son estructuras de datos multidimensionales, pueden incluir o excluir dimensiones particulares o ser abiertos o cerrados. En la sección 3.5.5.5 se ofrece más información sobre los hipercubos.
| 2.4.3.2.4 | Relaciones de etiquetas |
La base de enlaces de etiquetas asocia texto legible por humanos con nombres de concepto legibles por máquina. Este documento XML contiene varias etiquetas para los conceptos dentro de la taxonomía y explica cómo usar e interpretar estas etiquetas. El uso de estas etiquetas se define vinculando conceptos a ellas a través del arco concepto-etiqueta.
| 2.4.3.2.5 | Relaciones de referencia |
La base de vínculos de referencia crea arcos a través del vínculo concepto-referencia que asocia un concepto con información adicional. Esta información adicional puede derivarse de un organismo autorizado (como referencia autorizada) y proporciona una mayor comprensión de lo que un concepto debe representar. Las referencias a menudo funcionan vinculando conceptos con regulaciones y estándares externos o proporcionando documentación significativa adicional.
| 2.4.3.2.6 | Relaciones de fórmula |
La base de enlaces de fórmula crea arcos entre conceptos que especifican relaciones matemáticas más allá de una relación de cálculo. Para obtener más información sobre el uso de fórmulas XBRL, consulte la sección 6.2.1.
| 2.4.4 | Documentos de instancia XBRL |
El documento de instancia XBRL, también denominado informe XBRL, contiene los datos estructurados que se van a transportar e informar. Además, contiene las definiciones para las dimensiones centrales, excepto el concepto dimensiones centrales (que se definen en la propia taxonomía). Debido a que lo que estas dimensiones de núcleo XBRL están destinadas a representar se incluyen en la especificación XBRL, se incluyen en el documento de instancia.
Además, es probable que estas dimensiones cambien de un informe a otro. No son inherentes a la taxonomía en sí, sino más bien al conjunto de datos particular que se informa en XBRL. Por ejemplo, aunque todos los documentos de instancia XBRL que utilizan una taxonomía para informar de activos financieros pueden utilizar una dimensión básica del concepto denominada ReportedAssets, el período de informe y la entidad variarán. Por lo tanto, estas dimensiones XBRL se definen en el documento de instancia, ya que pertenecen al informe, no a la taxonomía (Figura 2-17).
La taxonomía debe contener las construcciones necesarias para los preparadores que utilizan esa taxonomía, que incluye todas las dimensiones básicas del concepto, todas las dimensiones definidas por la taxonomía, todos los tipos de datos personalizados y todas las relaciones basadas en conceptos requeridas. El siguiente capítulo describirá las construcciones básicas de XBRL utilizadas en una taxonomía y cómo se asignan a un modelo de datos de ejemplo antes de explorar cómo representar ese modelo de datos en XBRL.
| 3 | Estructuración de datos |
| 3.1 | Introducción |
Los datos se pueden estructurar de varias maneras, desde simples hojas de cálculo, listas y formatos tabulares que pueden tener un puñado de puntos de datos hasta redes complejas y bases de datos relacionales que podrían contener miles de bits discretos de información. Cada modelo de datos, desde el más simplista hasta el más complicado, tiene una estructura que proporciona reglas para comprender sus datos y cómo los puntos de datos se relacionan entre sí. Esa estructura, que debe ser dictada por la naturaleza de los datos en sí, sirve como guía para aprovechar las construcciones de XBRL para organizar adecuadamente los datos para el transporte y el consumo.
Un modelo de datos es una estructura abstracta que organiza elementos de datos y estandariza cómo se relacionan entre sí, así como con entidades del mundo real. Un modelo de datos robusto debe ser capaz de identificar de forma única los puntos de datos independientemente del contenido del punto de datos, y una implementación XBRL requiere que los puntos de datos se identifiquen de forma única. En esta sección se describe cómo tomar un modelo de datos y expresarlo mediante construcciones XBRL. Primero, se examinan varios modelos de datos para que los lectores puedan familiarizarse con la identificación de la dimensionalidad de los datos y cómo los puntos de datos se ven afectados por las diferentes formas de expresar esa dimensionalidad. Después de explorar estos ejemplos, el capítulo se centra en cómo se pueden expresar esos modelos de datos en XBRL.
Es importante tener en cuenta que la intención de XBRL es proporcionar un formato de datos estructurado y predecible. Este es su principal objetivo, permitir una fácil comparabilidad de los datos entre las entidades informantes. Por lo tanto, si bien siempre hay múltiples formas de construir un modelo de transporte de datos, ese modelo debe representar adecuadamente una multitud de modelos de datos empresariales entrantes. Esto puede ser un desafío, por lo que esta sección también proporciona una discusión de los múltiples enfoques para modelar datos, algunas ventajas y desventajas inherentes a cada uno, y explora cuándo y por qué ciertas situaciones justifican un método de modelado en particular.
| 3.2 | Datos típicos |
En un conjunto de datos típico, los puntos de datos son únicos, pero la unicidad puede ser a través de dimensiones de modelo de datos implícitas. La mayoría de los informes tienen al menos un período de tiempo implícito, por ejemplo. Como primer paso en el diseño de una taxonomía XBRL, los desarrolladores deben examinar su conjunto de datos y determinar si todos los puntos de datos pertinentes se pueden expresar de forma única.
¿Qué significa ser único? En un modelo de datos relacional, un conjunto de valores, a veces llamado clave,en una combinación de dimensiones de datos sirve para identificar de forma única un punto de datos. No hay dos puntos de datos en el modelo que puedan tener la misma combinación de valores clave. En modelos más complejos, las dimensiones de los datos en sí mismas pueden tener más información identificativa o relacional que se especifica en otro lugar. Por ejemplo, el nombre de una empresa puede ser una dimensión que ayuda a agregar información contextual a los números de ventas, pero la empresa puede tener un identificador emitido por el gobierno relacionado con ellos.
En las siguientes secciones se examinan diversas complejidades de los modelos de datos y sus implicaciones para el desarrollo de XBRL. La primera sección explora una serie de puntos de datos simples con una complejidad creciente en las relaciones, junto con métodos para organizar los datos dentro de construcciones dimensionales XBRL.
Los datos no relacionales se refieren a puntos de datos que no tienen relaciones semánticas más allá de una agrupación que está implícita en el propio conjunto de datos, como una entidad informadora o un período de tiempo. Por ejemplo, los nombres de clientes reunidos en una lista no tienen relación entre sí más allá de la lista en sí. Al quitar el contenedor de lista de estos elementos, se elimina el significado semántico que tienen entre sí.
En un conjunto de datos no relacionales (Tabla 3-1), cada elemento es único simplemente en virtud del hecho de que es diferente de todos los demás elementos. No puede haber elementos duplicados. En este ejemplo, si dos clientes tuvieran el mismo nombre, se podría agregar una dimensión de datos para diferenciarlos, probablemente mediante el uso de un identificador único, como un número de identificación fiscal u otro número de identificación.
3.2.2 Datos relacionales simples
Un conjunto de datos relacionales simple (Tabla 3-2) es aquel en el que los puntos de datos tienen una relación significativa entre sí. Sobre la base de la lista de clientes no relacionales, si se agrega una dimensión de datos, como la cantidad de widgets que compró cada cliente, los puntos de datos ahora tienen un contexto semántico adicional. Cada punto de datos ahora se define de forma única tanto por el nombre del cliente como por la cantidad de widgets vendidos.
Tabla 3-2. Conjunto de datos de widget (datos relacionales simples con dimensiones independientes)
| 3.2.2.1 | Dimensiones independientes |
Dos dimensiones de datos se consideran independientes cuando no tienen relación semántica entre sí. En otras palabras, el significado de una dimensión de datos no influye en el significado de la otra dimensión. En este caso, el nombre del cliente no tiene relación semántica con los widgets vendidos. La tabla representa una estructura bidimensional simple, una que podría visualizarse usando los ejes X e Y para representar las dimensiones Nombre del cliente y Widgets vendidos, respectivamente. Las dimensiones independientes también se denominan a veces ortogonales entre sí.
3.2.3 Relaciones de datos complejas
Las relaciones de datos complejas añaden aún más dimensionalidad al modelo de datos. En el ejemplo de la lista de clientes, si se agrega una tercera dimensión de datos para expresar el tipo de widget comprado, cada punto de datos ahora está definido por tres dimensiones: Nombre del cliente, Widgets vendidos y Tipo de widget (Tabla 3-3).
Tabla 3-3. Conjunto de datos de widget (datos complejos con dimensiones independientes en una relación uno a uno)
Es importante destacar que cada una de las dimensiones de datos en el ejemplo es independiente de las otras dimensiones. En el ejemplo anterior, el nombre del cliente no influye en la interpretación de los widgets vendidos y el tipo de widget. Cualquier cliente puede comprar cualquier número de widgets de cualquier tipo. Además, la cantidad de widgets vendidos también es independiente del tipo de widget. Cabe señalar que si se requieren múltiples dimensiones para expresar un punto de datos de forma única, esto no implica necesariamente que esas dimensiones de datos sean dependientes entre sí. De hecho, las dimensiones clave independientes pueden ser una situación menos compleja y, por tanto, deseable.
Al observar los datos, cada cliente tiene solo un tipo de widget comprado. Esta es una relación uno a uno , pero los datos pueden no estar limitados a una relación tan simple. Por ejemplo, suponga que Bob Green también compró 100 Widgets circulares. La tabla aparecería como aparece en la Tabla 3-4.
Tabla 3-4. Conjunto de datos de widget (datos complejos con dimensiones independientes en una relación de uno a muchos)
Los puntos de datos «750» y «100» requerir tanto el nombre del cliente y las dimensiones de widgets tipo con el fin de ser único. Esta se convierte en la clave única del punto de datos. El tipo de widget debe estar presente con el nombre del cliente para crear puntos de datos únicos en el ejemplo. Esta es ahora una relación de uno a muchos, en la que cada cliente puede haber comprado varios tipos diferentes de widgets. Existe una relación de uno a muchos entre el cliente y la combinación de los widgets vendidos y el tipo de widget.
La eliminación de la dimensión Tipo de widget produce dos filas identificadas solo con «Bob Green» y, por lo tanto, no son únicas y semánticamente indistinguibles. Para valores numéricos, la combinación matemática de un conjunto de puntos de datos puede simular la unicidad si se ha eliminado una dimensión clave necesaria. Por ejemplo, Bob Green podría aparecer en la lista con 850 widgets vendidos. Esto restaura la unicidad con la pérdida de cierta información (cuántos de cada tipo de widget comprenden la suma).
| 3.2.3.1 | Dimensiones dependientes |
Las dimensiones de un modelo de datos dependen unas de otras cuando el valor de una dimensión influye en los valores de otra. Entonces, las dos dimensiones se relacionan semánticamente. Suponga que se agrega una dimensión para reflejar el precio por widget para cada tipo de widget, como lo hace en la Tabla 3-5.
Tabla 3-5. Conjunto de datos de widget (datos complejos con dimensiones independientes y dependientes)
La nueva dimensión de datos Precio por widget depende del tipo de widget. Los widgets circulares siempre tienen un precio de $ 5, los rectangulares a $ 10 y los triangulares a $ 20 por widget, independientemente del cliente. Por lo tanto, la dimensión de datos Precio por widget depende únicamente del tipo de widget. Para definir correctamente un punto de datos para los widgets vendidos, se requieren tres dimensiones: nombre del cliente, tipo de widget y widgets vendidos. Price Per Widget no es necesario (y, de hecho, no debe usarse) para hacer que el punto de datos sea único.
Sin embargo, si los clientes tienen precios especiales, el precio por widget depende de la combinación del nombre del cliente y el tipo de widget. Este ejemplo no indica esto explícitamente, pero se deben considerar posibilidades como estas al diseñar un modelo de datos. En este caso, los widgets vendidos todavía se identifican de forma única por las mismas tres dimensiones que las anteriores. Sin embargo, el precio cambia según el cliente.
Si el precio varía para cualquier compra individual, el modelo gana una relación de varios a varios. Considere la Tabla 3-6 como sigue:
Tabla 3-6. Conjunto de datos de widget (datos complejos con dimensiones independientes y dependientes en una relación de muchos a muchos)
Ahora, el punto de datos de Widgets vendidos requiere cuatro dimensiones para tener una clave única. Jane Doe ha comprado un total de 550 widgets triangulares, pero 350 de ellos fueron descontados. Por lo tanto, el punto de datos para los widgets vendidos requiere una combinación del nombre del cliente, los widgets vendidos, el tipo de widget y ahora el precio por widget. Sin embargo, el precio por widget aún puede depender del tipo de widget, el nombre del cliente o ambos.
Las dimensiones dependientes ocurren comúnmente en los modelos de datos, pero pueden hacer que las claves únicas sean muy difíciles de obtener con solo examinar los datos. Estas relaciones deben pensarse cuidadosamente durante el diseño de cualquier modelo de datos relacionales complejo.
| 3.3 | Crear un modelo de datos XBRL |
La construcción básica en XBRL para expresar relaciones de datos en un conjunto de datos es la dimensión XBRL. En un nivel fundamental, un hecho XBRL debe tener una dimensión central del concepto, una dimensión central del período, una dimensión central de la entidad y puede tener una dimensión central de la unidad o del lenguaje, según corresponda. A medida que el modelo de datos aumenta en complejidad, se pueden agregar dimensiones definidas por taxonomía para expresar las relaciones adicionales relativas al hecho. No hay límite para el número de dimensiones definidas por taxonomía que pueden cruzarse con un hecho XBRL. Sin embargo, una buena práctica de desarrollo de modelos de datos y taxonomía debería guiar al desarrollador a producir el menor número de dimensiones XBRL para representar con precisión la información semántica relevante.
Las siguientes secciones explorarán cómo representar los ejemplos de widgets anteriores en XBRL usando dimensiones XBRL. Tenga en cuenta que, en aras de la simplicidad y la brevedad, los nombres de dimensión definidos por concepto y taxonomía en este capítulo no están completamente completos ni son suficientes para su uso en una taxonomía XBRL real. Muy a menudo se ha omitido el sufijo. Para obtener un ejemplo más completo de cómo nombrar correctamente conceptos y dimensiones XBRL, consulte los Capítulos 5 y 7.
El primer paso para expresar un conjunto de datos en XBRL es identificar las dimensiones de ese conjunto de datos y cómo esas dimensiones se traducen al núcleo XBRL y dimensiones definidas por taxonomía. Es importante tener en cuenta que todos los informes pueden tener dimensiones XBRL implícitas asociadas que pueden no estar representadas directamente en un conjunto de datos. Esto puede incluir la dimensión central de la entidad, la dimensión central del período y las dimensiones centrales de la unidad o del idioma. Estos deben estar representados en XBRL, incluso si no son explícitos en el conjunto de datos de origen. En los ejemplos siguientes, las dimensiones de entidad, período y unidad se combinan y representan mediante una dimensión de informe. Esto se hace para simplificar los ejemplos, ya que estas dimensiones son constantes para cada hecho en los datos.
| 3.3.1 | Representar datos no relacionales |
A primera vista, puede parecer que representar datos no relacionales, como la lista de nombres de clientes en la Sección 3.2.1, debería ser una tarea simple en XBRL. Sin embargo, rápidamente se vuelve obvio que mantener la singularidad de los hechos XBRL en esta situación se vuelve complicado dada la falta de otras dimensiones para ayudar a identificar los hechos y las múltiples opciones de diseño para superar esto.
Una vez más, considere el conjunto de datos no relacionales de la Tabla 3-1. Hay una única dimensión: Nombre del cliente. La implementación de XBRL podría verse como en la Figura 3-1.
Figura 3-1. Un modelo de datos XBRL para datos no relacionales con hechos no únicos 1
La dimensión única está representada por la dimensión central del concepto CustomerName. Sin embargo, esto da como resultados hechos no únicos para cada nombre de cliente. No hay variación semántica para diferenciar un hecho de otro, ya que la dimensión central del concepto y la dimensión del informe son constantes para cada hecho. Ésta es una implementación XBRL deficiente del conjunto de datos.
Hay dos posibles soluciones a este problema. La primera sería cambiar la dimensión central del concepto de CustomerName a CustomerNameList y cambiar su tipo de datos para que sea la lista completa de nombres. Entonces, el hecho se convierte en la lista en sí, y solo hay un hecho único en lugar de una serie de hechos no únicos. Dependiendo del propósito del modelo de datos, esta puede ser una solución adecuada con baja complejidad. Sin embargo, no permite identificar de forma única a cada uno de los clientes.
El segundo enfoque es más complicado, pero proporciona un mayor acceso a los datos dentro del modelo. En lugar de expresar los datos con solo una dimensión central del concepto, se puede utilizar una dimensión definida por taxonomía para desagregar la lista de nombres de clientes. Considere la Figura 3-2:
La dimensión central del concepto es CustomerName, y ahora se ha agregado una dimensión definida por taxonomía CustomerIdentifier. La dimensión CustomerIdentifier podría contener un identificador único significativo para cada cliente si estos datos existen y son relevantes, o puede contener simplemente el nombre del cliente nuevamente (lo que agrega redundancia, pero es un enfoque fácil), o, finalmente, puede contener un nombre arbitrario identificador. Identificadores arbitrarios son análogos a las claves generadas automáticamente en el diseño de bases de datos o en el modelado de datos. Este tema se discutirá con mayor detalle en una sección posterior.
Ahora, con este diseño, cada punto de datos se puede expresar de forma única como un hecho XBRL.
| 3.3.1.1 | Representar datos relacionales |
La creación de datos relacionales en XBRL es simple una vez que se han definido las dimensiones de datos adecuadas. El ejemplo de la Tabla 3-3 proporciona un modelo simple. Hay dimensiones para esta tabla: el nombre del cliente y los widgets vendidos. Cada una de estas dimensiones describe diferentes tipos de información, pero ambas están relacionadas con el Cliente. Como se indicó anteriormente, estas dimensiones de datos son independientes entre sí.
El modelo (Figura 3-3) usa CustomerName como una dimensión definida por taxonomía y WidgetsSold como una dimensión central del concepto. Se pueden agregar fácilmente a este modelo dimensiones XBRL más independientes. Por ejemplo, la dimensión WidgetType se puede agregar como una dimensión central del concepto o una dimensión definida por taxonomía. Implementarlo como una dimensión central del concepto impone una relación uno a uno con las otras dimensiones centrales del concepto, que en este caso incluye WidgetsSold.
La dimensión WidgetType se ha agregado como dimensión central del concepto (Figura 3-4). Debido a este enfoque, la relación entre WidgetType y CustomerName ahora es uno a uno. Un cliente solo puede tener un tipo de widget comprado en el informe. Este diseño es adecuado para el conjunto de datos actual, pero no puede dar cuenta de todos los conjuntos de datos posibles en el modelo. Para hacer eso, la implementación de XBRL debe poder para tener en cuenta la relación uno a varios entre WidgetsSold y las otras dimensiones de datos. Al hacer de WidgetType una dimensión definida por taxonomía, un cliente ahora puede tener más de un tipo de widget comprado en un solo informe (Figura 3-5).
De esta manera, el modelo XBRL puede representar los dos conjuntos de datos siguientes en la Tabla 3-3 y la Tabla 3-4: para cada valor de la dimensión central del concepto WidgetsSold, existe una combinación única de las dimensiones definidas por taxonomía CustomerName y WidgetType .
XBRL no distingue estrictamente entre dimensiones independientes y dependientes. De hecho, XBRL no tiene ningún mecanismo de ejecución; todas las dimensiones XBRL son independientes por su naturaleza. Una dimensión dependiente, al igual que una dimensión independiente, puede representarse mediante una dimensión central del concepto o una dimensión definida por taxonomía. Sin embargo, existen ramificaciones para cada elección de diseño. Desde el punto de vista del uso, qué dimensiones definidas por taxonomía se combinan con otras dimensiones definidas por taxonomía y las relaciones entre ellas es extremadamente importante. Los desarrolladores de taxonomía deben proporcionar orientación a los preparadores sobre qué dimensiones definidas por taxonomía deben usarse para modelar dimensiones dependientes.
Considere nuevamente el ejemplo con la dimensión de datos Precio por widget y un precio único por tipo de widget en la Tabla 3-5. La dimensión Precio por widget depende del tipo de widget. Esta situación se presta a representar el precio por widget como una dimensión central del concepto. El razonamiento detrás de esto es simple: para cada valor de la dimensión Tipo de widget, solo hay un valor para Precio por widget. Por lo tanto, en el modelo XBRL, cada combinación de los valores de las dimensiones CustomerName y WidgetType debe estar vinculada a un solo valor en PricePerWidget. Esto mantiene la singularidad. La implementación de XBRL aparecería como en la Figura 3-6:
Cabe destacar que la dimensión del informe se ha convertido en una simplificación excesiva, ya que el concepto WidgetsSold y el concepto PricePerWidget no tienen la misma dimensión central de la unidad (ya que la primera es un recuento de elementos y la segunda es un valor monetario). Sin embargo, este es un detalle trivial, y la Dimensión de informe única se seguirá utilizando para mantener el ejemplo gráficamente simple.
Esta implementación de XBRL con una segunda dimensión central del concepto para representar PricePerWidget presenta problemas cuando la dimensión dependiente depende de más de otra dimensión, como es el caso en la Tabla 3-6. Aquí, como se mencionó anteriormente, la dimensión de datos Precio por widget depende tanto del tipo de widget como del cliente. Desde el punto de vista del modelado de datos, se debe crear una dimensión definida por taxonomía para representar PricePerWidget como se ilustra en la Figura 3-7.
El modelo de la Figura 3-7 mantiene la singularidad pero permite valores distintos para PricePerWidget con cualquier tipo de cliente o widget. Aunque en el ejemplo la dimensión Precio por widget depende del tipo de widget y del nombre del cliente, en la implementación de XBRL se representa como una dimensión definida por taxonomía que, como cualquier otra dimensión definida por taxonomía, es operativamente independiente en XBRL.
Si bien este enfoque está bien desde el punto de vista del modelado de datos, para el uso práctico puede haber otras consideraciones. Las instancias XBRL son colecciones de puntos de datos con un significado semántico agregado a través de dimensiones XBRL para convertirse en hechos. En este ejemplo, el hecho es la cantidad de widgets vendidos, identificados a través de la dimensión central del concepto WidgetsSold, con la diferenciación semántica agregada a través de WidgetType, CustomerName y las otras dimensiones XBRL mencionadas. Tratar PricePerWidget como una dimensión definida por taxonomía mantiene la unicidad dentro del conjunto de datos y agrega más significado semántico a WidgetsSold. Sin embargo, PricePerWidget podría consumirse mejor como un hecho en sí mismo. El modelo de datos tal como está no puede gestionar esta representación, ya que los valores de PricePerWidget son parte de la dimensión definida por taxonomía. Si estos valores se van a consumir de manera significativa, este no es un enfoque ideal.
Como antes, cuando se necesitaba la unicidad, la solución es crear una dimensión arbitraria. Esta es una dimensión que no está presente en el conjunto de datos de origen, pero es necesaria para la implementación de XBRL. El siguiente modelo de datos de ejemplo emplea una nueva dimensión definida por taxonomía denominada Factura (Figura 3-8). Como consecuencia, PricePerWidget ahora puede volver a convertirse en una dimensión central del concepto, lo que permite que los hechos que contienen la información del precio por widget se representen directamente en la instancia XBRL. La dimensión definida por taxonomía de factura es arbitraria para el propósito del informe. En este caso, tiene un valor de 1, pero podría tener cualquier valor único. También puede ser representativo de un número de factura real; esto tiene el mismo propósito para este ejemplo.
3.3.2 Proceso general
A partir de los ejemplos anteriores, el proceso general de creación de una implementación XBRL a partir de un modelo de datos preexistente se puede resumir de la siguiente manera:
| 1. | Identificar dimensiones en el conjunto de datos / modelo de datos preexistentes: en la mayoría de los casos, la dimensionalidad de un conjunto de datos o modelo de datos que está bien diseñado debería ser obvia. De lo contrario, tome medidas para garantizar que cada punto de datos se pueda identificar de forma única a través de una o más dimensiones de datos. Nuevamente, esta es una propiedad fundamental de XBRL, que cada hecho en el documento de instancia es único. |
| 2. | Identifique los datos que se van a representar en XBRL: los datos que se consumirán deben convertirse en hechos XBRL. Saber qué puntos de datos son consumibles y cuáles contextuales ayudará a delinear las dimensiones centrales del concepto y las dimensiones definidas por la taxonomía. |
| 3. | Determine el número mínimo de dimensiones XBRL para mantener la singularidad: aunque XBRL no lo exige, el modelo de datos más parsimonioso debería ser un objetivo de desarrollo. Lograr puntos de datos únicos a través del menor número de dimensiones XBRL reduce la complejidad del modelo de datos y aumenta la interpretabilidad tanto para los preparadores como para los consumidores. |
| 4. | Identificar dónde son necesarias dimensiones XBRL arbitrarias para mantener la unicidad: si hay dimensiones dependientes dentro del modelo de datos, se deben agregar dimensiones arbitrarias para mantener la unicidad en XBRL. Los valores de estas dimensiones pueden derivarse de los datos o de fuentes externas. Este paso puede incluir reevaluar el modelo de datos para incluir más dimensiones de datos que no sean arbitrarias para adaptarse a esta situación. No siempre es necesario cambiar el modelo existente; a veces, los números arbitrarios proporcionan una solución más parsimoniosa que agregar datos innecesarios e irrelevantes. Realmente depende de los objetivos del modelo de datos en sí. |
Estos son los pasos básicos para crear el modelo para la implementación de XBRL. Se requerirán decisiones adicionales con respecto a los nombres de los conceptos, los tipos de datos, la extensibilidad y otras características fundamentales de la taxonomía, y estas se discutirán en secciones posteriores.
En esta etapa, el modelo de datos debe contener dimensiones centrales del concepto y dimensiones definidas por taxonomía que pueden o no estar relacionadas entre sí. Dado esto, ¿cómo se representa ese modelo mediante una taxonomía XBRL?
| 3.4.1 | Dimensiones del núcleo del concepto |
Como parte de la definición de las dimensiones centrales del concepto, se deben definir las propiedades del concepto. Cada concepto en el modelo debe tener sus propiedades definidas, pero las propiedades de las dimensiones centrales del concepto se relacionan más directamente con los hechos XBRL mismos. Las propiedades del concepto se discutieron previamente en la Sección 2.2.6.2.
Al principio del proceso de creación de la dimensión central del concepto, se debe determinar el tipo de datos para cada concepto. Los tipos de datos se pueden definir en la especificación XBRL, o pueden definirse en la propia taxonomía. Los conceptos deben utilizar el tipo de datos más restrictivo posible para el tipo de información que se representa. Por ejemplo, la dimensión central del concepto PricePerWidget debe tener un tipo de datos monetario por unidad, en lugar de un tipo decimal. El tipo de datos también tiene una relación cercana con la dimensión central de la unidad (o la dimensión central del idioma, si los datos son textuales). Nuevamente, un tipo de datos monetarios debe usar una unidad monetaria, como un identificador de moneda ISO4217. XBRL no proporciona ninguna restricción sobre la coincidencia de tipos de datos con tipos de unidades. Sin embargo, XBRL proporciona una verificación básica del tipo de datos en busca de hechos para garantizar que los datos coincidan con el tipo de datos del concepto. Por ejemplo, crear un hecho con el valor de «9» utilizando un concepto con un floatItemType es válido, pero crear un hecho con el valor de «9.5»
La Figura 3-9 muestra una selección de tipos de datos XBRL, cómo se relacionan entre sí y las dimensiones del núcleo de la unidad aplicable. XBRL tiene más tipos de datos disponibles; ver el Apéndice A.
Los tipos de datos también se pueden definir dentro de la taxonomía utilizando un tipo de datos base XML o XBRL con restricciones. Por ejemplo, se puede crear una dimensión central del concepto que se limita a una enumeración de valores extendiendo el tipo de cadena base XML con una restricción a valores específicos. Los tipos de datos XBRL se rigen por la especificación XML y el Registro de tipos de datos XBRL
3.4.2 Dimensiones definidas por taxonomía
Fundamentalmente, las dimensiones definidas por taxonomía son simplemente grupos de conceptos relacionados semánticamente. A diferencia de las dimensiones centrales del concepto, estos conceptos no pueden contener un hecho XBRL y, por lo tanto, deben tener la propiedad abstracta. XBRL admite dos tipos diferentes de dimensiones definidas por taxonomía: escritas y explícitas. Para ambos tipos, existe un concepto que describe la dimensión. Por ejemplo, el concepto abstracto CustomerName describe la dimensión XBRL de los nombres de clientes, que se ha utilizado en los ejemplos de widgets. En XBRL, estos se denominan comúnmente ejes (ya que se pueden considerar como ejes o dimensiones dentro del conjunto de datos).
Cuando se utiliza una dimensión definida por taxonomía, se debe proporcionar un eje y un valor para ese eje. Para el ejemplo de CustomerName, el concepto de CustomerName es el eje y el valor podría ser JaneDoe. Las dimensiones definidas por taxonomía explícita y tipificada representan el valor de diferentes formas. Hay situaciones en las que un enfoque tiene ventajas sobre el otro.
| 3.4.2.1 | Dimensiones definidas por taxonomía explícita |
Las dimensiones definidas por taxonomía explícita utilizan conceptos abstractos adicionales para cada valor del eje. En el ejemplo del widget, el concepto abstracto CircularWidgets representa un tipo de widget en la dimensión definida por taxonomía WidgetType. De esta manera, los valores permitidos para el dominio del eje son «explícitos» (definidos en la taxonomía o en una extensión de la taxonomía). Los conceptos utilizados para indicar valores permitidos para dimensiones explícitas definidas por taxonomía se denominan comúnmente miembros porque son miembros del conjunto o dominio de valores que representan las dimensiones definidas por taxonomía. La taxonomía debe expresar la relación entre una dimensión definida por taxonomía explícita y sus conceptos de miembro.
Dado que la taxonomía define todos los conceptos disponibles, también define los valores disponibles para una dimensión explícita. Se pueden crear más conceptos para representar subgrupos de miembros del dominio. En el ejemplo del widget, se podría crear un concepto RoundedWidgets para contener CircularWidgets, y un concepto AngularWidgets podría crearse para contener TriangularWidgets y RectangularWidgets. Tanto RoundedWidgets como AngularWidgets serían conceptos de agrupación, y CircularWidgets, TriangularWidgets y RectangularWidgets serían conceptos de miembros. Además, se puede crear un concepto que represente la totalidad de los valores de una dimensión. Esto se conoce como un concepto de dominio (que normalmente tiene el sufijo «Dominio»).
Si el sistema de informes permite conceptos de extensión, entonces, de forma predeterminada, todas las dimensiones explícitas definidas por taxonomía permiten conceptos de extensión. Un desarrollador puede agregar validación adicional en cualquier sistema que use XBRL para hacer cumplir el uso de la extensión.
Las dimensiones definidas por taxonomía con tipo no utilizan conceptos como miembros para indicar valores permitidos. En cambio, las dimensiones escritas utilizan un tipo de datos para determinar los valores permitidos del eje (de ahí el nombre dimensiones «escritas»). El tipo de datos utilizado para una dimensión escrita puede ser simple o complejo. Usando el ejemplo del widget, la dimensión de datos Precio por widget podría representarse usando una dimensión definida por taxonomía escrita cuyo tipo de datos es monetario. Asimismo, la dimensión Nombre del cliente podría ser una dimensión definida por taxonomía escrita con un tipo de datos de cadena.
En lugar de especificar una dimensión definida por taxonomía y un miembro de concepto como parte de un contexto XBRL, el contexto XBRL designaría una dimensión definida por taxonomía y un valor permitido por el tipo de datos de esa dimensión.
Dependiendo del tipo, las dimensiones definidas por taxonomía tipificada pueden permitir un gran número de valores posibles o un número muy limitado. Un tipo de cadena podría tener efectivamente infinitos valores permitidos. Un tipo de datos que es una enumeración de valores, por otro lado, está restringido. Por ejemplo, una taxonomía definida dimensión con un tipo que especifica una enumeración con los valores de los tipos de widget, como «circular», «triangular» y «rectangular», permitiría solo estos tres valores (tenga en cuenta que estos valores no son conceptos; más bien, son datos especificado dentro del contexto XBRL). Este enfoque permite un mayor control sobre los tipos de valores permitidos para el eje, pero también limita la extensibilidad del usuario. La misma dimensión definida por taxonomía, pero con un tipo de datos de cadena permitiría tipos de widget ilimitados, aunque quizás con una comparabilidad reducida.
Los desarrolladores deben tener en cuenta que confiar en demasiadas dimensiones definidas por taxonomía escrita para especificar valores puede hacer que los informes sean demasiado complejos, lo que a su vez puede dificultar el consumo de datos. Las dimensiones definidas por taxonomía solo deben agregar dimensionalidad a los puntos de datos y no deben usarse para expresar datos. Además, como es una buena práctica para seleccionar tipos de datos en general, los desarrolladores deben elegir el tipo de datos más restrictivo para una dimensión definida por taxonomía escrita que satisfaga las necesidades de esa dimensión.
Para obtener más información sobre las ramificaciones del diseño del uso de dimensiones definidas por taxonomía tipificada versus explícita, consulte la Sección 5.3.2.2.
| 3.4.3 | Tuplas |
Las tuplas son un método para agrupar elementos de datos cuando no existe una relación dimensional clara entre los elementos en sí. Por ejemplo, una dirección postal podría estar representada por una tupla donde los componentes individuales de esa dirección (la dirección de la calle, la ciudad, el estado o provincia, etc.) generalmente se enumeran juntos. Los componentes en sí mismos no tienen ninguna relación semántica entre sí más allá de esta agrupación. Dentro de una taxonomía XBRL, normalmente no se hace referencia a los miembros de la tupla individualmente porque rara vez tiene sentido hacerlo. Los datos se informan como una unidad y no se requiere comprensión de los datos multidimensionales para su interpretación.
Las tuplas se utilizan con menos frecuencia que las dimensiones definidas por taxonomía para representar datos. Primero, generalmente la información dentro de un informe XBRL es de naturaleza jerárquica y / o dimensional, lo que una tupla no puede expresar bien. En segundo lugar, debido a que una tupla se interpreta como un grupo de información, existen métodos muy limitados para identificar las partes constituyentes de la tupla. Los desarrolladores pueden agrupar tuplas para formar estructuras jerárquicas, pero este método de modelado a menudo se logra mejor a través de dimensiones. Finalmente, las tuplas no se pueden extender.
Aun así, puede haber ocasiones en las que las tuplas pueden reducir el tamaño y la complejidad del informe XBRL. Debido a que las tuplas no se usan comúnmente y generalmente no son un método preferido de modelado, este manual no las explora más allá de esta breve introducción. Los desarrolladores deben ser conscientes de que las tuplas existen como un medio para agrupar datos no dimensionales y que pueden ser otra opción de desarrollo en las circunstancias adecuadas. Para obtener más información, consulte la Especificación XBRL
Una taxonomía XBRL contiene no solo la definición de todos los conceptos y tipos de datos, sino también las relaciones entre los conceptos. XBRL permite varios tipos de relaciones. Las presentaciones describen cómo se organiza cada concepto en un formato jerárquico en forma de árbol. Los cálculos describen cómo los conceptos se relacionan matemáticamente entre sí (si existe una relación matemática). Por último, las definiciones indican directamente la relación entre conceptos y dimensiones definidas por taxonomía (incluidas las relaciones jerárquicas, pero también más allá de esta estructura).
XBRL usa XML y XLink para representar sus relaciones. La mayoría de las relaciones XBRL existen entre dos conceptos, que pueden ser dimensiones centrales del concepto o dimensiones definidas por taxonomía. Las relaciones se pueden refinar o expandir aún más agregando más relaciones de pares a los mismos conceptos, lo que puede construir jerarquías complejas. El número de relaciones puede ser muy grande en una taxonomía grande, por lo que, para ver la taxonomía en un formato más amigable para los humanos, a menudo se requiere software.
| 3.4.4.1 | Presentaciones |
Las presentaciones son la representación gráfica del árbol jerárquico de conceptos de taxonomía y dictan cómo el software que consume XBRL debe representar o representar los conceptos en relación entre sí. La Figura 3-10 contiene un subconjunto de una presentación derivada de la taxonomía contable US GAAP 2017.
En la Figura 3-10, las relaciones jerárquicas entre los conceptos son fáciles de visualizar. Las presentaciones XBRL describen lo que se llama relaciones entre padres e hijos . Un concepto que es hijo de otro concepto no hereda ninguna propiedad o característica; más bien, esta relación representa una relación de composición. El concepto padre está compuesto por sus hijos. En otras palabras, el concepto padre aplica un significado u organización semántica adicional a sus conceptos hijos. Tenga en cuenta que la mayoría de las taxonomías deben seguir la Guía de estilo de XBRL US y deben usar sufijos para indicar qué conceptos son estructurales y, por lo tanto, abstractos.
Los nombres de las presentaciones contienen un código numérico para fines de clasificación, seguido de un tipo y un nombre (consulte la Sección 7.2.3.1.1 para obtener más información). Los conceptos abstractos se indican en esta figura con un icono «A». Esta presentación se denomina «Estados de resultados (incluido el margen bruto)». El concepto raíz IncomeStatementAbstract tiene un concepto hijo único StatementTable, que representa la relación entre las dimensiones definidas por taxonomía y las dimensiones centrales del concepto. El primer hijo de StatementTable es StatementScenarioAxis (que es una dimensión definida por taxonomía). El concepto StatementScenarioAxis (que es una dimensión explícita definida por taxonomía) tiene tres hijos en total: ScenarioUnspecifiedDomain, ScenarioPreviouslyReportedMember y RestatementAdjustmentMember.
El concepto StatementLineItems contiene conceptos abstractos que ayudan a organizar las dimensiones centrales del concepto. Por ejemplo, la dimensión central del concepto IncomeLossFromContinuingOperations es parte del concepto IncomeLossFromContinuingOperationsAttributableToParentAbstract, que indica que la pérdida de ingresos de las operaciones continuas es atribuible a la entidad matriz.
Los desarrolladores deben proporcionar información de presentación para ayudar a los preparadores a crear informes. Los desarrolladores también pueden permitir que los preparadores creen presentaciones personalizadas, lo que les permite reorganizar los conceptos para describir relaciones nuevas y diferentes que se adapten mejor a sus necesidades de informes.
| 3.4.4.2 | Cálculos |
Un cálculo es una agrupación de dimensiones centrales del concepto que define una relación matemática específica entre ellas. Los cálculos se organizan en una estructura en forma de árbol utilizando una relación de suma en la que el elemento de nivel más alto se compone de la suma de los elementos constituyentes. Los elementos constitutivos también pueden estar compuestos por otros elementos. Los cálculos solo deben definirse entre conceptos con tipos de datos numéricos. En XBRL, los cálculos siempre se representan con esta relación de suma. Sin embargo, la ponderación se puede aplicar para representar la resta y la multiplicación.
Los cálculos XBRL representan relaciones entre conceptos que el desarrollador puede crear para representar una variedad de relaciones matemáticas. Sin embargo, el software XBRL solo puede verificar los cálculos con condiciones específicas. Primero, los hechos involucrados en un cálculo deben tener las mismas dimensiones definidas por taxonomía, dimensión de núcleo de unidad y dimensión de núcleo de período. En otras palabras, los hechos deben existir en el mismo período de tiempo con la misma dimensionalidad semántica. En segundo lugar, la precisión del valor calculado depende de la precisión de sus componentes. La verificación puede fallar debido a un redondeo inconsistente o imprevisto en los hechos de los componentes.
Las definiciones describen relaciones entre conceptos. A diferencia de las relaciones de presentación, las definiciones no están limitadas por una relación padre / hijo entre conceptos. Más bien, XBRL permite cuatro tipos estándar de relaciones de definición:
| 1. | General-especial: esta relación indica que un concepto de un par es una forma más especializada de otro concepto. Por ejemplo, en el ejemplo del widget, el tipo de widget AngularWidgets puede ser general (refiriéndose a cualquier tipo de widget que tenga ángulos), mientras que el tipo de widget TriangularWidgets es más específico. |
| 2. | Esencia-alias: esta relación indica que un concepto de un par tiene esencialmente el mismo significado que el otro concepto. Por ejemplo, una entidad que reporta puede usar el concepto Widgets para referirse a su producto, y otra puede preferir el concepto Gizmos, pero el significado subyacente, que estos conceptos son productos, es el mismo. La definición de esencia-alias refleja un cambio en la terminología más que en el significado semántico. |
| 3. | Requiere-elemento – Esta relación indica que el valor de un concepto es requerido cuando el valor del otro concepto en el par está presente. Por ejemplo, en el informe de widgets con las dos dimensiones principales del concepto WidgetsSold y PricePerWidget, PricePerWidget requiere un valor para WidgetsSold. |
| 4. | Similar – tuplas: esta relación es operativamente la misma que la definición de esencia-alias, pero reservada para su uso con tuplas. Las tuplas no se usan comúnmente. |
Además, la especificación de dimensiones XBRL permite más tipos de definición. Estos tipos se utilizan para definir las relaciones que pertenecen a los componentes de una dimensión en XBRL. Las definiciones existen entre un concepto y una dimensión definida por taxonomía para definir la relación jerárquica entre ellos. Se pueden ver ejemplos de cada uno en la Figura 3-10.
| 1. | Dimensión-predeterminada: esta relación indica que el concepto es el valor predeterminado para la dimensión definida por taxonomía. |
| 2. | Dimensión-dominio: esta relación indica que el concepto representa el dominio de la dimensión definida por taxonomía. |
| 3. | Miembro de dominio: esta relación indica que un concepto es miembro del dominio del otro concepto que es parte de una dimensión definida por taxonomía. Esta relación puede existir entre muchos conceptos. Por ejemplo, un miembro del noreste puede pertenecer a un eje de ubicación geográfica, pero este miembro del noreste comprende un grupo de estados del noreste de los EE. UU. Cada uno de ellos tiene la relación dominio-miembro con el concepto del noreste. |
Las siguientes secciones usarán el ejemplo de widget modificado para contener datos adicionales y complejidad para demostrar el uso de XBRL con un modelo de datos subyacente complejo. El conjunto de datos es el siguiente:
Para los propósitos de este ejemplo (Tabla 3-7), se supone que el conjunto de datos está completo (el conjunto de datos mínimo; consulte el Capítulo 5 para obtener más información). En otras palabras, se tienen en cuenta todas las posibles situaciones de notificación. Siguiendo este ejemplo, se explorarán las ramificaciones de esta suposición. Esta tabla describe las compras individuales que ocurrieron durante un período de tiempo.
| 3.5.1 | El modelo de datos |
Seguir los pasos generales del proceso descritos en la Sección 3.3.2 podría producir un modelo de datos para este conjunto de datos de la siguiente manera:
Las columnas Cliente, Tipo y Fecha de la Tabla 3-7 están representadas por las dimensiones definidas por taxonomía CustomerName, WidgetType y OrderDate (Figura 3-11). Las columnas Cantidad, Precio por e Ingresos por venta de widgets están representadas por las dimensiones centrales del concepto WidgetsSold, PricePerWidget y WidgetSaleIncome. Estos puntos de datos específicos se representan mejor como dimensiones centrales del concepto solo porque son los datos que probablemente serán el foco de atención de los consumidores. Las dimensiones definidas por taxonomía agregan significado semántico a estos puntos de datos al mismo tiempo que crean unicidad.
Como se dijo en secciones anteriores, es importante crear nombres de conceptos que se autodescriban. En otras palabras, el nombre del concepto debe indicar lo que el concepto representa semánticamente sin información de apoyo de otros conceptos. Por lo tanto, en este ejemplo, Client se ha ajustado a CustomerName y así sucesivamente. Para obtener más información sobre la denominación adecuada de conceptos, consulte la Guía de estilo de XBRL US .
También tenga en cuenta que este ejemplo contiene una fecha de pedido (que se muestra como la columna Fecha en la Tabla 3-7) y una fecha del informe (que se menciona arriba de la tabla en el encabezado «al 1 de junio de 2019»). Generalmente, el informe la fecha es la dimensión central del período. Desde una perspectiva de modelado de datos, es preferible basar la dimensión central del período en el informe en sí en lugar de puntos de datos individuales dentro del informe.
Con un modelo de datos diseñado, la implementación de XBRL puede comenzar a tomar forma.
| 3.5.2 | Conceptos |
Dado el conjunto de conceptos básicos de dimensiones y conceptos que pertenecen a dimensiones definidas por taxonomía, los desarrolladores deben definir sus respectivas propiedades. Todos los conceptos, sin importar su uso, deben tener propiedades bien definidas.
| 3.5.2.1 | Dimensiones del núcleo del concepto |
En el ejemplo del widget (Tabla 3-7), hay tres dimensiones principales del concepto: WidgetsSold, WidgetSaleIncome y PricePerWidget. Sus propiedades aparecen en la Tabla 3-8.
| Propiedad | Widgets vendidos | WidgetSaleIncome | PricePerWidget |
| Tipo de período | «instante» | «instante» | «instante» |
| Abstracto | «falso» | «falso» | «falso» |
| Nillable | «falso» | «falso» | «falso» |
| Grupo de sustitución | «ít» | «ít» | «ít» |
| Tipo de datos | «entero positivo» | «monetario positivo» | «positivo por widget» |
| Tipo de saldo | N / A | N / A | N / A |
Tabla 3-8. Propiedades de las dimensiones del núcleo del concepto en el ejemplo del widget
Para las propiedades que deben definirse, estos tres conceptos tienen una propiedad de tipo de período de «instantáneo», ya que estos valores de datos describen información en un momento particular. Aunque la tabla muestra un informe durante un período de tiempo, cada punto de datos individual se produjo en un momento específico. Esta es una distinción importante que hacer porque considerar estos puntos de datos como relacionados con una duración de tiempo, que puede tener sentido desde una perspectiva humana, los tergiversa al nivel del modelo de datos. Esto también significa que estos conceptos deben cruzarse con una dimensión central del período que también se define por un instante, en lugar de una duración.
Todos estos conceptos también deben tener la definición de «falso» como su propiedad abstracta, ya que son dimensiones centrales del concepto. Los tres conceptos tienen un valor de «falso» para nillable , ya que este modelo de datos no permite valores perdidos. Si el modelo permite valores perdidos, algunos conceptos podrían tener un valor de «verdadero» para nillable. Los conceptos nillables permiten una gran flexibilidad, ya que diferencian entre un punto de datos que está vacío y uno que no se aplica. Finalmente, todas las dimensiones del núcleo del concepto deben tener «elemento» como valor para su propiedad de grupo de sustitución. Esto indica qué tipo de concepto es.
Las propiedades discutidas anteriormente son las mismas para estas tres dimensiones centrales del concepto. Sin embargo, para algunas propiedades, existen diferencias importantes, sobre todo el tipo de datos. WidgetsSold tiene un tipo de datos de «entero positivo». Esto tiene sentido, ya que ningún cliente tiene o debería tener un número negativo o un total de cero widgets comprados. WidgetSaleIncome tiene un tipo de datos monetario, ya que es una cantidad monetaria. Puede ser útil tener en cuenta que este tipo de datos permite cantidades monetarias negativas. En el caso de este ejemplo, los importes monetarios negativos no son posibles, por lo que para dar cuenta de esto correctamente, sería necesario emplear un tipo de datos definido por taxonomía. Por lo general, es una buena idea restringir los tipos de datos al conjunto de valores permitidos tanto como sea posible, sin dejar de tener en cuenta la extensibilidad según sea necesario. Nuevamente, la extensibilidad y sus ramificaciones se discutirán más adelante. Por ahora, se agregará un tipo de datos de «monetario positivo» a la taxonomía para reflejar valores monetarios que no pueden ser negativos.
Finalmente, el tipo de datos para el concepto PricePerWidget es algo complicado. Como es un valor monetario por artículo, simplemente podría expresarse como un decimal. Sin embargo, un tipo de datos definido de forma personalizada brinda una mejor interpretación y claridad para los consumidores, incluso si ese tipo de datos no es en realidad más restrictivo que el decimal.
Nuevamente, los valores para este concepto no pueden ser negativos en este conjunto de datos, por lo que una restricción en ese tipo personalizado de valores positivos solo tiene sentido. Este tipo de datos personalizados se denominará «positivo por widget».
La última propiedad a abordar es el tipo de saldo. Esta propiedad se relaciona con los principios contables de débitos y créditos. Para este ejemplo, esta propiedad se puede ignorar.
| 3.5.2.2 | Dimensiones definidas por taxonomía derivadas directamente del modelo de datos |
En el ejemplo del widget, hay tres dimensiones definidas por taxonomía: WidgetType, OrderDate y CustomerName. Tenga en cuenta que estas no son las únicas dimensiones definidas por taxonomía necesarias para representar nuestro modelo de datos, pero son las que son inmediatamente evidentes en las columnas de la Tabla 3-7. En XBRL, es mejor nombrar conceptos como estos con la palabra «eje» como sufijo del nombre. WidgetTypeAxis, OrderDateAxis y CustomerNameAxis se convierten en conceptos que representan una dimensión XBRL de datos, por lo que sus propiedades son todas iguales. Debido a que son conceptos que representan dimensiones definidas por taxonomía, todos son abstractos. Estos conceptos simbolizan una dimensión o eje de datos; por lo tanto, su propiedad de grupo de sustitución es «dimensión».
Todas las dimensiones definidas por taxonomía representan una dimensión del modelo de datos. Sin embargo, es posible que se requieran múltiples conceptos de apoyo para dimensiones explícitas definidas por taxonomía. Por ejemplo, el concepto WidgetTypeAxis representa la dimensión de los tipos de widget. Es necesario otro concepto para representar cada tipo individual de widget. Agregar RectangularMember, TriangularMember y CircularMember como conceptos de apoyo de la dimensión definida por taxonomía WidgetTypeAxis aumenta el número de dimensiones definidas por taxonomía en el modelo a seis. Estos nuevos conceptos tienen el tipo de dominio para su tipo de datos, lo que indica que son parte de un dominio de datos. Su propiedad de grupo de sustitución es «elemento» y, como todos los conceptos derivados de una dimensión definida por taxonomía, son abstractos.
A diferencia de WidgetTypeAxis que tiene miembros, OrderDateAxis y CustomerNameAxis son dimensiones definidas por taxonomía escritas. Esta elección de desarrollo se hizo porque WidgetTypeAxis ha establecido valores prescritos por la naturaleza de los datos, ya que presumiblemente Widgets, Inc. tiene un conjunto limitado y bien definido de posibles tipos de widgets, lo que sugiere que WidgetTypeAxis sea una dimensión explícita. OrderDate A xis y CustomerNameAxis, por otro lado, son más abiertos. Si se tratara de dimensiones explícitas definidas por taxonomía, requerirían extensibilidad para representar todos los datos posibles (como un cliente o la fecha de compra que aún no están incluidos en este conjunto de datos). La extensibilidad se analiza en la Sección 3.6.
| 3.5.2.3 | Apoyar dimensiones definidas por taxonomía |
Con el fin de representar la colección de las dimensiones con la taxonomía definida aplicados a esta presentación, un hipercubo se requiere concepto (hipercubos a veces se hará referencia simplemente como cubos). Este concepto, WidgetsSoldByCustomerTable, representa la relación de alto nivel entre las diferentes dimensiones de los datos. Esto se considera un hipercubo ya que es una dimensión de dimensiones. Esta construcción XBRL cumple el importante propósito de organizar las dimensiones definidas por taxonomía de una manera significativa. La propiedad de grupo de sustitución de este concepto es «hipercubo».
Además, todas las presentaciones deben provenir de un concepto raíz que represente la totalidad de la presentación. Para este ejemplo, ese concepto se llamará WidgetsSoldAbstract. La propiedad del grupo de sustitución del concepto es «elemento» y, dado que este concepto representa el concepto contenedor de toda la presentación, es abstracto.
Se pueden agregar otras dimensiones de apoyo definidas por taxonomía según sea necesario para agregar y organizar lógicamente las dimensiones XBRL. Estos pueden ayudar a agregar interpretabilidad semántica y usabilidad. Por ejemplo, en esta presentación, se puede agregar una dimensión de informe definida por taxonomía de apoyo para agrupar los elementos de línea (dimensiones centrales del concepto). Este concepto abstracto del Informe no es obligatorio, pero sirve para delinear claramente las dimensiones centrales del concepto a partir de las dimensiones definidas por la taxonomía. Finalmente, cuando se utilizan dimensiones definidas por taxonomía, se requieren conceptos adicionales para representar los dominios de las dimensiones. Esto es cierto para las dimensiones explícitas y escritas. Para este ejemplo, ese concepto es WidgetTypeDomain para la dimensión explícita, y los conceptos son CustomerNameDomain y OrderDateDomain para las dimensiones mecanografiadas (tenga en cuenta que estos especifican el tipo de datos restrictivo para las dimensiones mecanografiadas). Para cualquier dimensión explícita, las propiedades del concepto de dominio coinciden con las de los conceptos de miembro de la dimensión.
| 3.5.3 | La presentación XBRL |
Dados los conceptos definidos anteriormente, ahora se puede definir la presentación XBRL (Figura 3-12). La presentación hace obvias las relaciones jerárquicas entre los ejes y los conceptos de los miembros. También agrupa y define las líneas de pedido (dimensiones básicas del concepto) en el informe.
Figura 3-12. Un ejemplo de presentación XBRL para widgets vendidos
Si bien este modelo de datos XBRL puede parecer complicado para una tabla simple, las ventajas obtenidas de más conceptos superan la complejidad. Las relaciones que proporciona XBRL, junto con las propiedades de los conceptos, crean un modelo de datos que se describe a sí mismo.
| 3.5.4 | Cálculos XBRL |
El ejemplo de widget en su forma actual no tiene ningún cálculo XBRL que se pueda definir. Aunque los ingresos por venta de widgets son una función matemática del precio por widgets y widgets vendidos, los cálculos de XBRL no permiten que la ponderación dentro de una suma se derive de un hecho. Por lo tanto, el precio por widgets no se puede simplemente multiplicar por los widgets vendidos para verificar los hechos en los ingresos por venta de widgets.
Sin embargo, XBRL ofrece fórmulas XBRL que pueden agregar este nivel de validación. Consulte la Sección 6.2.1 y la Especificación XBRL Formula 1.0 para obtener más información sobre este tema.
Las definiciones XBRL para las dimensiones definidas por taxonomía aparecen en la Figura 3-13. Como recordatorio, las dimensiones centrales del concepto (WidgetsSold, WidgetSaleIncome y PricePerWidget) no tienen definiciones.
El arco describe el papel del arco, o conexión, entre los conceptos. La conexión entre los conceptos es muy similar a la presentación (Figura 3-12). Las definiciones de XBRL describen más claramente las relaciones jerárquicas de las dimensiones, incluidas las funciones de los conceptos constituyentes. En este ejemplo, las dimensiones tienen un contexto en el que se pueden utilizar (la columna «Contexto»), que puede ser un segmento o un escenario. Marcar una dimensión definida por taxonomía como un segmento indica que contiene información parcial de una pieza más grande. Por ejemplo, cada valor de la dimensión definida por taxonomía CustomerName es una parte de la dimensión de datos total (un cliente). Etiquetar una dimensión definida por taxonomía como un escenario indica que contiene información de estado sobre la naturaleza de los datos. Por ejemplo, los hechos comerciales se pueden informar como reales, presupuestados, reexpresados, pro forma, etc. El uso de escenarios permite un contexto semántico adicional sobre la naturaleza de los datos que se informan. En el ejemplo del widget, no hay dimensiones de escenario.
Dentro de la definición de XBRL, la propiedad cerrada del hipercubo especifica que todas las dimensiones definidas por taxonomía en este hipercubo deben cruzarse en un hecho para que ese hecho sea parte de este hipercubo. Si se omite una dimensión definida por taxonomía, se supone que el valor predeterminado para esa dimensión se cruza en el hecho. Si no hay un valor predeterminado, esa dimensión definida por taxonomía no puede cruzarse, lo que evitará que el hipercubo incluya el hecho. Un abiertoHypercube elimina esta restricción. En el ejemplo del widget, cada hecho debe tener las dimensiones definidas por taxonomía CustomerNameAxis, WidgetTypeAxis y OrderDateAxis que se cruzan sobre él. Para una dimensión explícita definida por taxonomía, un arco de dimensión predeterminada permite que un concepto sea el valor predeterminado de la dimensión, lo que significa que los hechos que no se cruzan explícitamente con esa dimensión definida por taxonomía están implícitos en cruzarse con el valor predeterminado al representar el hipercubo. La dimensión predeterminada generalmente se establece en el concepto de dominio, lo que implica que los hechos que no se cruzan con la dimensión son un total de esa dimensión.
La propiedad utilizable simplemente significa que este valor de dominio está permitido en el hipercubo. Si la propiedad utilizable se establece en «falso», el valor del dominio se excluirá del dominio de miembros válidos para el hipercubo. El ejemplo del widget es sencillo y no tiene por qué excluir datos del hipercubo. Una presentación que solo se aplica a un tipo de widget específico podría usar esta propiedad para excluir los tipos de widget no relacionados estableciendo la propiedad utilizable para esos conceptos de miembro en «falso». Cuando se trata de extensibilidad, esta propiedad también es importante. Cabe señalar que esto es diferente de establecer la propiedad cerrada del hipercubo en verdadero. Un hipercubo cerrado todavía es extensible.
Todos los miembros predeterminados de una dimensión deben tener su propiedad utilizable establecida en true.
3.5.6 Otra información necesaria para la taxonomía
XBRL requiere que se defina otra información al desarrollar una taxonomía, como etiquetas de concepto y referencias. Sin embargo, al desarrollar el modelo de datos, estas características no son particularmente relevantes. Los preparadores de XBRL utilizarán esta información para ayudar en la interpretación del modelo de datos, por lo que dicha información representa una parte importante del desarrollo de la taxonomía. Consulte la Sección 7.2.3 para obtener más información sobre estos tipos de características.
3.5.7 Ramificaciones de un sistema de informes cerrado
El ejemplo de widget discutido hasta ahora ha llevado al desarrollo de un sistema de reporte cerrado (uno que no permite extender la taxonomía). Como se mencionó anteriormente, esto significa que un informe XBRL que utiliza esta taxonomía no puede hacer referencia a conceptos adicionales o reorganizar conceptos en estructuras jerárquicas nuevas o diferentes. La taxonomía debe emplearse para representar e informar datos tal como están.
Un diseño de informes cerrado maximiza la comparabilidad de los datos. Cada informe debe contener los mismos conceptos utilizados con la misma dimensionalidad. Esto hace que contrastar un informe con otro sea más sencillo para los consumidores. Sin embargo, limita la capacidad de los preparadores para ajustar la taxonomía a sus propias necesidades de informes. Por ejemplo, la taxonomía de widgets tal como se desarrolló puede cumplir con todos los casos de uso de Widgets, Inc. Si Widgets Co. desarrollara y vendiera diferentes tipos de widgets, por ejemplo, widgets hexagonales, esta taxonomía no podría abordar sus necesidades de informes sin cambiar el modelo de datos. Widgets Co. no puede representar su información de forma tan completa como Widgets, Inc.
| 3.6 | Extensibilidad |
Un sistema de informes abierto y extensible puede proporcionar formas de abordar el problema de que los preparadores no puedan representar sus conjuntos de datos por completo. Permitir el uso de conceptos de extensión y la reorganización de los conceptos significa que un preparador podría crear las estructuras necesarias para expresar todos sus puntos de datos. Como se menciona en el ejemplo de widget, Widget Co., con su tipo de widget hexagonal que no se puede expresar en la taxonomía de widget cerrada actual, podría crear un miembro hexagonal del dominio WidgetType. Debido a que XBRL describe el modelo de datos, así como las extensiones permitidas, los informes de Widgets, Inc. y Widget Co. siguen siendo bastante comparables.
La extensibilidad permite a los preparadores «extender» la taxonomía para que se adapte a sus propias necesidades de informes. La extensibilidad generalmente se refiere a dos aspectos principales: la capacidad de los preparadores para crear sus propios conceptos y la capacidad de los preparadores para crear sus propias relaciones entre los conceptos ya definidos en la taxonomía y / o en otros lugares. Esto puede llegar a ser tan complejo como importar una taxonomía secundaria para utilizarla junto con una taxonomía primaria.
La extensibilidad puede ser una especie de arma de doble filo. Por un lado, una mayor extensibilidad permite a los preparadores crear informes que pueden reflejar mejor sus conjuntos de datos específicos. Por otro lado, si los informes difieren significativamente, puede disminuir la comparabilidad e interpretabilidad de cada uno, lo que reduce un poco la utilidad de XBRL en general. Equilibrar las necesidades de los preparadores para crear conceptos y relaciones personalizados con las necesidades de los consumidores para poder comparar conjuntos de datos estandarizados y uniformes puede ser un tema complejo.
Las ventajas, desventajas y otras consideraciones relativas a la extensibilidad de la taxonomía se discutirán en las siguientes secciones. Generalmente, en XBRL, no hay disposiciones para prevenir o permitir la extensibilidad. Los desarrolladores de taxonomía determinan la extensibilidad durante el proceso de desarrollo y en cómo se implementa el sistema de informes. Un preparador puede extender la taxonomía de la forma deseada, pero si el sistema que debe interpretar esa taxonomía no reconoce los cambios, el uso de conceptos extensibles se vuelve erróneo. El desarrollo adecuado de la taxonomía debe incluir una guía para los preparadores sobre cómo extender una taxonomía (consulte la Sección 8.4.5).
Existen algunos métodos dentro de XBRL para dar prioridad a relaciones particulares, y esos también se tratarán en el Capítulo 5. Este capítulo también proporciona un análisis más profundo de los medios para proporcionar extensibilidad y sus impactos en la comparabilidad.
| 3.6.1 | Ampliación de conceptos |
La creación de nuevos conceptos, ya sean dimensiones centrales del concepto o conceptos pertenecientes a dimensiones definidas por taxonomía, requiere necesariamente definir las relaciones que el nuevo concepto tiene con los otros conceptos dentro de la taxonomía. Esto significa que cuando se permiten conceptos de extensión, también se deben permitir jerarquías extendidas.
Los preparadores no deben crear conceptos más allá del alcance del modelo de datos. El documento de orientación debe especificar esto.
Como se mencionó anteriormente, XBRL permite tipos de datos extendidos que se basan en tipos de datos XML y XBRL. Se debe desalentar a los preparadores de crear tipos de datos extendidos, ya que el modelo de datos debe diseñarse para contener tipos de datos para representar todos los datos posibles. Debido a que los preparadores no deben crear conceptos fuera del alcance del modelo de datos, es probable que no se necesiten tipos de datos extendidos. Por supuesto, los desarrolladores pueden crear tipos de datos personalizados para la taxonomía.
| 3.6.1.2 | Ampliación de dimensiones |
Otro método para permitir la extensibilidad se deriva de la naturaleza de las dimensiones explícitas frente a las escritas. Una dimensión escrita tiene un conjunto específico de valores permitidos, mientras que una dimensión explícita se basa en las relaciones entre conceptos para dictar sus valores. Compare, por ejemplo, las dimensiones definidas por taxonomía de WidgetTypeAxis y CustomerNameAxis como se define en el ejemplo del widget (Figura 3-12 y Figura 3-13). La dimensión definida por taxonomía WidgetTypeAxis requiere conceptos extendidos para abarcar tipos de widget fuera de los conceptos de miembro (Triangular, Circular y Rectangular). Por el contrario, los valores de la dimensión definida por taxonomía CustomerNameAxis están limitados solo por su tipo de datos. Como se indicó anteriormente, esta elección de diseño tiene sentido para este conjunto de datos, donde hay solo un número pequeño y limitado de tipos de widgets que son específicos y bien definidos, pero puede haber cualquier número de nombres de clientes. Debido a que los valores de las dimensiones con tipo están restringidos por un tipo de datos, el único método para extender los datos de una dimensión con tipo más allá de su tipo de datos es crear una dimensión similar para reemplazarla.
Los desarrolladores deben tener en cuenta qué dimensiones del modelo de datos pueden necesitar extensibilidad en función de posibles casos de uso. Si los valores están claramente limitados a un conjunto en particular, una dimensión escrita puede proporcionar una forma de expresar todos los datos al tiempo que se evita la extensibilidad no deseada. Sin embargo, una dimensión escrita con un tipo de datos que es demasiado restrictivo puede hacer que los preparadores reemplacen la dimensión que reduce la comparabilidad de los datos. Del mismo modo, una dimensión escrita con un tipo de datos que no es lo suficientemente restrictivo puede tener el mismo resultado final.
Sin embargo, una dimensión explícita brinda a los preparadores la capacidad de crear conceptos extendidos que son subconjuntos de dimensiones definidas por taxonomía. Esto significa que los preparadores pueden desglosar aún más sus datos según sea necesario al tiempo que indican cómo esos datos se ajustan a la taxonomía estándar.
| 3.6.1.3 | Ampliación mediante roles de etiqueta |
Los conceptos deben tener ciertos roles de etiqueta definidos creados por los desarrolladores de taxonomía. Los significados de los conceptos se pueden ampliar al permitir que los preparadores declaren otros roles de etiqueta. La extensión de etiquetas puede ayudar a la legibilidad humana y a los consumidores a desarrollar mejores modelos analíticos. Sin embargo, para permitir etiquetas extensibles, se requiere una cierta cantidad de extensibilidad adicional. Consulte la Sección 5.4.2.2 para obtener más información.
| 3.6.2 | Otras taxonomías desarrolladas |
XBRL permite importar cualquier taxonomía en cualquier informe. Por lo tanto, los desarrolladores deben decidir qué taxonomías, si las hay, pueden utilizar los preparadores. Además, la taxonomía desarrollada puede incluir otras taxonomías por defecto. Toda la información del modelo de datos de la taxonomía importada está disponible para su uso, incluidos los tipos de datos. Sin embargo, cualquier relación entre conceptos en cada taxonomía separada debe ser definida por el desarrollador o el preparador. También debe tenerse en cuenta que no es necesario importar la jerarquía de una taxonomía conocida (o cualquier taxonomía) si el desarrollador desea proporcionar solo nuevas relaciones.
| 3.6.3 | Taxonomías personalizadas |
Como una extensión de la importación de taxonomías conocidas, los preparadores también pueden importar taxonomías personalizadas a discreción del desarrollador. Esto debe permitirse con precaución ya que el desarrollador no mantendrá ningún control sobre la taxonomía en ese momento. Por lo tanto, las elecciones de diseño deficientes u otros problemas pueden integrarse en la taxonomía sin el conocimiento o consentimiento del desarrollador. Este no es un enfoque recomendado.
Este proceso de examinar conjuntos de datos, determinar la dimensionalidad de ese conjunto de datos y traducir la dimensionalidad a un modelo de datos XBRL debe repetirse para todos los datos pertinentes al proyecto. Una vez que se completa este proceso y el desarrollador tiene una idea inicial de las necesidades dictadas por los datos en sí, se puede examinar en profundidad el impacto de los requisitos de las partes interesadas. El próximo capítulo explora estas consideraciones.
| 4 | Evaluación del alcance general del proyecto |
Como paso inicial para cualquier proyecto importante, los desarrolladores deben determinar el alcance del proyecto, es decir, el trabajo que se debe realizar para entregar un producto con un conjunto predeterminado de características y funciones. El alcance proporciona una base esencial que impulsa el proceso de desarrollo. Como parte del alcance, hay otras consideraciones clave. ¿Cuál es el propósito del proyecto? ¿Qué tan grande y complejo es el proyecto? ¿Cómo interactuarán los usuarios y otras partes interesadas con el proyecto? ¿Qué recursos, habilidades, información y personal se requieren para cumplir con éxito el propósito del proyecto? Una vez que se completa el proyecto, ¿cómo se documentan, difunden y mantienen sus productos de trabajo relevantes? Si es necesario realizar cambios, ¿quién decide cuándo y de qué manera implementarlos?
Preguntas clave como estas deben investigarse cuidadosamente y responderse antes de comenzar el trabajo. En este capítulo, se discutirán los factores subyacentes a estos problemas críticos para guiar a los desarrolladores en la evaluación de sus propias necesidades de proyectos. Debido a que los proyectos XBRL pueden ser muy diferentes de muchas maneras, no existe una respuesta única para algunas de estas preguntas. Sin embargo, una serie general de pasos puede ayudar a los desarrolladores a enfocar su proceso y evitar problemas.
Al investigar y responder a estas preguntas, los desarrolladores pueden documentar su propio proceso de desarrollo y la taxonomía en sí a medida que se crea. Además de mantener una comprensión coherente de la taxonomía y su desarrollo, mantener la documentación del proceso de desarrollo puede conducir a la redacción paralela de la documentación de cara al público para la taxonomía (como la Guía de taxonomía ), lo que ahorra tiempo y trabajo. Puede encontrar más información sobre la Guía de taxonomía y otra documentación de taxonomía en el Capítulo 8.
XBRL presenta una perspectiva de proyecto única. Debido a que está diseñado como un modelo de transporte de datos, habrá múltiples partes, múltiples sistemas y posiblemente incluso múltiples modelos de datos involucrados. Por lo menos, hay preparadores, con sus modelos comerciales de datos, y consumidores, que usan esos datos para sus propios fines y pueden poseer sus propios modelos de datos. El modelo de datos de origen puede o no compartir ninguna similitud con el modelo de consumidor. Además, dependiendo del alcance del proyecto, puede haber muchos preparadores independientes y muchos consumidores, y cada entidad puede tener métodos y necesidades completamente diferentes con respecto a sus datos. Además, con bastante frecuencia existen requisitos reglamentarios que afectan el proceso de presentación de informes. Estos requisitos pueden estipular que se notifiquen ciertos tipos de datos, quizás en formatos estándar.
El objetivo de la taxonomía XBRL es facilitar el informe estructurado de datos del preparador al consumidor. Más allá de eso, las necesidades de cualquier sistema de informes y taxonomía en particular pueden variar mucho. Las taxonomías pueden ser:
- Creado para datos públicos o privados
- Diseñado para cumplir con los requisitos de cumplimiento normativo o para adaptarse a los requisitos de la industria (no obligatorios)
- Extensible por los preparadores o el patrocinador de la taxonomía puede optar por no permitir extensiones
- Construido sobre un estándar codificado o basado libremente en un proceso de reporte existente
Antes de comenzar el desarrollo, los desarrolladores deben tomar decisiones de política que sean más apropiadas para la taxonomía. Estas diversas políticas afectarán la estructura, el contenido y el uso de los datos producidos por la taxonomía. Las políticas se pueden cambiar más adelante, pero algunas decisiones fundamentales deben tomarse por adelantado para ayudar a dar forma al trabajo que se va a realizar. Los temas que deben explorarse incluyen:
- Extensibilidad
- Incorporación de estándares de la industria
- Requisitos de validación
- Requisitos estructurales (por ejemplo, cuándo y cuándo no usar dimensiones definidas por taxonomía versus dimensiones centrales del concepto)
- Fases de desarrollo (por ejemplo, inicialmente la taxonomía cubrirá un cierto conjunto de elementos, pero puede expandirse en una fecha posterior)
- Cómo se recopilan, almacenan y / o informan los datos actualmente y el impacto que esos sistemas pueden tener en la taxonomía
- Cómo los consumidores utilizan los datos, incluidos los tipos y estructuras de datos requeridos
Debido a que las políticas y los objetivos pueden crear consecuencias sutiles en términos de la estructura de la taxonomía o los aspectos del plan de desarrollo o mantenimiento, es de vital importancia que los desarrolladores comiencen su proceso identificando y calificando los requisitos funcionales y los casos de uso.
| 4.1.1 | Definición de requisitos funcionales |
En el núcleo de cualquier sistema, los requisitos funcionales especificar las operaciones de ese sistema o sus componentes como un avance de lo que ese sistema debe lograr. Los requisitos funcionales pueden incluir detalles técnicos, manipulación y procesamiento de datos, cálculos y modelado de datos. La comprensión de los requisitos funcionales, lo que se supone que debe hacer una taxonomía a un nivel directo y funcional, guiará el proceso de desarrollo inicial. Las taxonomías XBRL están destinadas a transportar datos de los preparadores a los consumidores, pero ¿para qué sirve este proceso de transporte? ¿La taxonomía está destinada a presentar datos estructurados para facilitar las comparaciones entre múltiples entidades informantes? ¿Tiene la intención de garantizar el cumplimiento de las pautas reglamentarias? ¿La taxonomía está destinada a organizar los datos de una manera específica para cumplir con los criterios de sistemas de análisis particulares? En algunos casos,
También puede ser importante en esta etapa temprana diferenciar entre requisitos funcionales y requisitos no funcionales. Un requisito funcional define para qué está diseñado el sistema, mientras que un requisito no funcional (a veces también llamado requisito de calidad) impone una restricción en el diseño o la implementación del sistema. Los requisitos no funcionales pueden plantearse como solicitudes / recomendaciones y deben sopesarse cuidadosamente en términos de su costo frente a su beneficio y su impacto en la taxonomía general o sus componentes.
| 4.1.2 | Comprender los casos de uso |
En general, un caso de usoes un tipo de especificación de requisitos para un sistema que representa una lista de acciones o pasos. Esta lista define las interacciones entre los usuarios (a veces llamados actores) y el sistema, para lograr un objetivo específico. Los casos de uso pueden ayudar a definir requisitos tanto funcionales como no funcionales. En términos de XBRL, los casos de uso se refieren a las formas en que los datos representados y transportados por XBRL deben prepararse o usarse. Por ejemplo, un caso de uso puede ser un preparador que emplea la taxonomía para representar una tabla de información financiera para una empresa. Para un consumidor, un caso de uso podría implicar el uso de esa información financiera en un modelo de datos para determinar la solvencia de esa empresa. Los casos de uso pueden ser simples o complejos, y pueden relacionarse directamente con cómo la taxonomía misma estructura los datos o cómo se transmiten esos datos.
Los casos de uso bien definidos generalmente capturan todas las formas posibles en que el usuario y el sistema pueden interactuar entre sí para que el usuario alcance su objetivo. También capturan los desafíos que pueden ocurrir en el camino que pueden impedir que el usuario logre el objetivo. Un simple ejemplo de esto es la cuestión de la extensibilidad. La extensibilidad se discutió en la Sección 3.6. Si los casos de uso de los consumidores exigen que los datos sean estrictamente comparables entre informes, permitir conceptos de extensión y tipos de datos en el sistema de informes puede ser contrario a esta necesidad, ya que la extensibilidad tiende a reducir la uniformidad en los conjuntos de datos. Debido a que los casos de uso pueden guiar a los desarrolladores a comprender el sistema que deben representar con la taxonomía XBRL, los casos de uso que se aplican a la taxonomía deben identificarse a fondo antes de que pueda comenzar el trabajo de desarrollo.
| 4.1.3 | Identificación de los datos a transportar |
Vinculado al desarrollo y la comprensión de los casos de uso está tener un buen manejo de qué datos deben ser representados por XBRL y transportados desde un modelo de datos de preparador a un modelo de datos de consumidores. Obviamente, representar datos dimensionales de forma precisa y parsimoniosa es el objetivo principal de cualquier proyecto de desarrollo XBRL.
Debido a que XBRL representa un modelo de transporte de datos como parte de una cadena de suministro de información, se deben analizar los modelos de datos y los conjuntos de datos involucrados en esa cadena de suministro antes y después de que se emplee la taxonomía XBRL (Figura 4-1).
El proceso de identificación y comprensión de los conjuntos de datos relevantes puede involucrar:
- Explorar bases de datos, la naturaleza de los datos que contienen y sus estructuras relacionales.
- Comprender el diseño y el propósito de los formularios actuales y relevantes, como los formularios utilizados para informar información a las agencias reguladoras u otros funcionarios de la industria.
- Comprender los medios de presentación de informes actuales (informes basados en documentos o hojas de cálculo y los sistemas subyacentes utilizados para desarrollarlos)
- Identificar información crucial para el informe (por ejemplo, un informe financiero probablemente se centrará en datos monetarios con otra información que se volverá contextual, mientras que un informe sobre procesos de fabricación puede presentar otra información con datos monetarios que se volverán contextuales)
- Revisar e incorporar instrucciones y / u orientación sobre cómo preparar las divulgaciones requeridas.
- Identificación de información potencialmente sensible
Es importante señalar que los desarrolladores de taxonomía no necesitan ser expertos de la industria o expertos en los tipos de datos que la taxonomía debe representar. Además, es posible que no necesiten tener un conocimiento profundo de la arquitectura o la ingeniería de datos. Sin embargo, incluso si no tienen este conocimiento y estas habilidades, estos aspectos siguen siendo importantes para incorporar al proceso de desarrollo. Por lo tanto, para comprender completamente tanto el rango de posibles casos de uso para la taxonomía XBRL como el propósito que debe cumplir la taxonomía, los desarrolladores deberán buscar la información y la información de múltiples expertos y partes interesadas.
Un interesado se refiere a una entidad con interés o preocupación en el proyecto. Un interesado puede estar compuesto por una sola persona, un grupo de personas o una organización completa. Las partes interesadas suelen ofrecer opiniones clave, conocimientos y experiencia sobre la naturaleza de los datos que se informarán y cómo debería funcionar ese proceso de presentación de informes. Es probable que ninguna de las partes interesadas tenga el conocimiento, la perspectiva y la comprensión suficientes para dar forma a la taxonomía; por lo tanto, es de vital importancia involucrar a todas las partes relevantes durante el proceso de desarrollo (Figura 4-2).
Para XBRL, las partes interesadas suelen ser participantes a lo largo de la cadena de suministro de información. Los preparadores que deben usar la taxonomía para crear informes, los reguladores que emplean la taxonomía para controlar y monitorear los informes estructurados, los intermediarios de datos que recopilan información y los consumidores de los datos que se reportan, todos representan partes interesadas en un proceso de desarrollo típico de XBRL. Los expertos de la industria y los analistas de datos también pueden ofrecer información clave sobre cómo una taxonomía puede estructurar mejor los datos pertinentes. En el caso de los informes US GAAP, por ejemplo, contadores que están involucrados en informar a la Comisión de Bolsa y Valores de los Estados Unidos tanto de firmas contables como de compañías públicas, agentes de archivo que trabajan con compañías públicas que preparan sus estados financieros para la presentación de la SEC, inversionistas y reguladores. que utilizan datos reportados por la SEC.
Las partes interesadas suelen ser las partes que proporcionan casos de uso. Sus necesidades y deseos con respecto a su propia interacción con la taxonomía y su sistema de presentación de informes deben tenerse en cuenta al decidir cómo deben funcionar esa taxonomía y ese sistema. Esto ayuda a mantener la taxonomía fiel a su propósito. Cuando la taxonomía es pequeña y quizás de alcance limitado o patentada, involucrar a las partes interesadas puede ser una tarea sencilla. Sin embargo, si el proyecto es grande y complejo con la capacidad de afectar a múltiples secciones diferentes de la industria, identificar opiniones y puntos de vista pertinentes puede ser más desafiante. Aún así, identificar a las partes interesadas antes de comenzar el proceso de desarrollo es fundamental, independientemente del tamaño y la complejidad del proyecto.
Particularmente durante las primeras etapas del desarrollo de la taxonomía, los desarrolladores deben tener cuidado de involucrar a las partes interesadas de todas las áreas relevantes de interés en el proceso. Esto podría significar que al menos una parte interesada de cada eslabón de la cadena de suministro de datos (preparación y consumo de datos, por ejemplo) debería estar representada al determinar los casos de uso iniciales de la taxonomía. Posteriormente, dependiendo del tamaño y el impacto potencial del proyecto, se requerirá una encuesta mucho más amplia de partes interesadas y partes interesadas para obtener un número aún mayor de puntos de vista para asegurar que la taxonomía capte todas las situaciones posibles.
Claramente, el tamaño y la complejidad de la taxonomía también es un tema clave para explorar en las primeras etapas de desarrollo. Para las taxonomías que solo pueden afectar a unas pocas partes interesadas (como una taxonomía que se usa internamente en una empresa o entre varias empresas dentro de una pequeña industria), el proceso de desarrollo puede ser menos complejo. Menos partes interesadas podrían indicar menos casos de uso. Además, si los datos que se reportarán son limitados y / o simples, la cantidad de casos de uso potenciales también podría ser pequeña.
Las taxonomías con grandes conjuntos de datos o cuya influencia puede llegar a una gran industria o múltiples industrias pueden enfrentar un proceso de desarrollo significativamente más complejo. En estos casos, es bastante común que se involucren muchas partes interesadas y casos de uso. De ello se deduce lógicamente que un proyecto grande también requerirá más recursos y un esfuerzo a mayor escala, incluida una mayor organización, planificación y coordinación. Por lo tanto, determinar el tamaño de la taxonomía al principio del proceso es increíblemente importante.
| 4.4 | Identificación de sistemas relevantes |
Muy a menudo, otras tecnologías y sistemas tecnológicos están involucrados en la cadena de suministro de información. Estos pueden ser sistemas para almacenar datos, analizar o interpretar los datos, compartir los datos o recibir los datos. La forma en que XBRL encaja en los sistemas ya instalados debe explorarse al principio del proceso de diseño. Por ejemplo, las empresas públicas que envían información financiera a la SEC pueden estar obligadas a hacerlo en XBRL utilizando el sistema de recopilación, análisis y recuperación de datos electrónicos (EDGAR) de la SEC. Los informes XBRL transmitidos de esta manera deben cumplir tanto con la taxonomía de informes financieros XBRL requerida como con el sistema de transmisión en sí. Como otro ejemplo, podría existir un sistema de informes para los estudios en una universidad para compartir datos con otras universidades o dentro de la universidad, como entre sus grupos y departamentos internos.
Además de considerar los sistemas involucrados en la transmisión de datos de los preparadores a los consumidores, los desarrolladores también deben examinar las fuentes de datos por sí mismos. Los datos pueden originarse en una amplia gama de sistemas y formatos según los entornos de los preparadores. Al examinar los informes financieros de las empresas públicas una vez más, la información pertinente para enviar informes financieros a la SEC puede provenir de Microsoft Word, Excel, Google Docs, bases de datos internas, sistemas de gestión de datos y muchas otras fuentes. Los datos de múltiples fuentes y sistemas se pueden combinar en un informe XBRL. Por lo tanto, los desarrolladores de XBRL pueden querer considerar de dónde provienen los datos al decidir cómo modelarlos mejor con XBRL.
Si no existe un sistema formalizado, los desarrolladores de taxonomía también deben considerar qué sistemas pueden ser necesarios para respaldar el proceso estructurado de presentación de informes. Esto puede extenderse a soluciones de software que pueden ayudar a los preparadores y consumidores a usar la taxonomía XBRL, que se analiza más en la Sección 4.6.3.
La naturaleza de cualquier sistema relevante también puede guiar a los desarrolladores a determinar el método de transporte XBRL, ya sea XML, JSON o CSV. Por ejemplo, si los informes están destinados a ser legibles por humanos después de su envío (por ejemplo, si se van a publicar en un espacio público, como el sitio web de una empresa), Inline XBRL podría ser la mejor opción para un método de transporte.
Otra faceta importante a considerar al principio del proceso de desarrollo son los requisitos reglamentarios, si corresponde. Los requisitos reglamentarios, que pueden provenir de agencias gubernamentales, organizaciones no gubernamentales, grupos de la industria o supervisión interna dentro de la industria, son a menudo una gran fuerza impulsora para determinar los requisitos funcionales de la taxonomía. Además, no es raro que la agencia reguladora patrocine el desarrollo de la taxonomía para asegurar la inclusión de las reglas y regulaciones pertinentes dentro de la taxonomía misma. Si este no es el caso, los miembros de las agencias reguladoras suelen ser partes interesadas y deben ser consultados durante el proceso de desarrollo.
Dependiendo del número de agencias que supervisan el contenido de los datos y los objetivos de la taxonomía en sí, el modelo de taxonomía puede ser impulsado en gran medida por estas partes interesadas en lugar de preparadores y consumidores. Esta es otra razón por la que es de vital importancia determinar los objetivos generales e involucrar a las partes interesadas en las primeras etapas del proceso de desarrollo, como se indica en las Secciones 4.1 y 4.2.
Los reguladores también pueden tener reglas comerciales o industriales que se pueden incorporar a la taxonomía para ayudar a producir datos de mejor calidad. Las reglas de validación pueden especificar que ciertos valores reportados siempre deben ser positivos o negativos, que ciertos conceptos deben ser reportados, o que ciertos conceptos siempre deben, o nunca deben, reportarse juntos. Las reglas comerciales pueden ser una herramienta poderosa para garantizar que los datos producidos se preparen de manera consistente y precisa.
Una vez que las partes interesadas se han involucrado y se han establecido los requisitos funcionales, no funcionales y reglamentarios, se pueden considerar otros requisitos. Estos incluyen recursos, software, personal y personal esencial para garantizar un proceso de desarrollo integral y exitoso. Dependiendo de la naturaleza de la taxonomía que se está creando y la amplitud del proyecto, cumplir con otros requisitos puede ser una tarea compleja y requerir una planificación significativa.
| 4.6.1 | Requerimientos de recursos |
Los requisitos de recursos necesarios en la construcción de una taxonomía XBRL pueden estar compuestos por personal, financiamiento, software, planes de prueba y validación y otras herramientas que pueden ayudar en el proceso de desarrollo. Nuevamente, según el alcance de la taxonomía y el tamaño del proyecto, los requisitos de recursos pueden ser grandes y complicados. El personal con experiencia en arquitectura de datos, experiencia en la industria, especialistas en gestión de datos e ingenieros de software con conocimientos de XML pueden proporcionar información útil. Los gerentes de proyecto y los desarrolladores de taxonomía deben identificar los recursos necesarios al principio del proceso de desarrollo para garantizar la programación, disponibilidad y optimización adecuadas de los recursos.
La creación de una taxonomía XBRL es realmente solo el primer paso para usar XBRL como modelo de transporte. Una vez que la taxonomía ha sido empleada por la población de la industria, debe mantenerse y monitorearse. Esto es cierto sin importar el alcance de la taxonomía. Como ocurre con la mayoría de los modelos de información, las taxonomías XBRL rara vez permanecen estáticas; las nuevas regulaciones, la aplicación de diferentes modelos a los datos y los cambios en los estándares de la industria o los datos en sí pueden requerir alteraciones en la taxonomía. Además, el uso de la taxonomía ayudará a los desarrolladores a identificar formas de mejorarla.
Por lo tanto, las taxonomías XBRL requieren soporte y gobernanza. Los requisitos de soporte pueden incluir abordar la facilidad de implementación de la taxonomía y administrar la extensibilidad. También dictan qué tipo de sistemas son necesarios para implementar cambios futuros y están estrechamente relacionados con la gobernanza. La gobernanza se refiere a las reglas, procedimientos y entidades de control mediante las cuales se administra una taxonomía. La gobernanza de la taxonomía no puede pasarse por alto; Debe existir un sistema para mantener la supervisión que garantice la integridad, la validación y el uso adecuado de los datos.
La gobernanza es un tema importante que se trata en el Capítulo 9.
Como se discutió en la Sección 4.4, diferentes sistemas de software pueden estar involucrados en el manejo de datos a través de la preparación, transmisión y consumo. Estos sistemas deben analizarse por su impacto potencial en la taxonomía. Además, el software XBRL en sí puede considerarse parte del proceso de desarrollo.
Una taxonomía XBRL por sí sola es una especificación XML; no tiene una funcionalidad inherente para visualizar presentaciones o definiciones, importar datos o exportar datos de informes XBRL o garantizar una validación adecuada. Debido a que XBRL se adhiere a los estándares XML, existe cierta validación sintáctica y visualización disponible en cualquier paquete de software que pueda analizar y representar XML. Sin embargo, no será específico de la taxonomía en sí. Si existe la necesidad de este tipo de características, los desarrolladores de taxonomía pueden necesitar buscar sistemas de software que admitan dicha funcionalidad.
En grandes industrias y dominios, como las empresas públicas que informan información financiera en XBRL a la SEC, los proveedores de software ya existen y deben cumplir con los estándares y requisitos de informes como parte de su modelo de negocio. Por lo tanto, en este caso, el apoyo al desarrollo de software está en manos de proveedores externos que deben adherirse a las taxonomías permitidas por la SEC. La difusión de los cambios de manera predecible, regular y ordenada es fundamental. En otras situaciones, como los bancos que informan a la Corporación Federal de Seguros de Depósitos (FDIC), el software para guiar a los preparadores en la creación de su informe XBRL se supervisa y regula de manera más estricta. En un caso como este, los desarrolladores de taxonomía y los grupos de gobernanza deben mantener una relación estrecha con desarrolladores de terceros para garantizar una comprensión precisa de la taxonomía. Estos son dos ejemplos en una amplia variedad de formas en las que los desarrolladores de software pueden interactuar con los desarrolladores de taxonomía. Por supuesto, en un entorno de informes pequeño donde el alcance de la taxonomía es más limitado, los desarrolladores de taxonomía también pueden enfrentarse al desarrollo de sus propias soluciones si se necesitan visores de presentación personalizados, procesamiento de datos personalizado y validación específica. Una vez más, sin embargo, el costo / beneficio de este tipo de soluciones debe evaluarse a fondo.
Generalmente, el desarrollo de software de soporte queda fuera del alcance de este documento. Sin embargo, es vital que los desarrolladores de taxonomía consideren qué tipo de paquetes de software podrían ayudar a los preparadores, consumidores y otros a comprender cómo funciona la taxonomía y cómo usarla. Una taxonomía XBRL solo es útil si existen medios para crear y acceder a datos de instancia XBRL, especialmente soluciones de software para guiar a los preparadores en la producción de informes XBRL sólidos y sólidos. Además, el sistema de informes en sí es vital para transmitir, almacenar y potencialmente liberar datos XBRL a los consumidores. Desde una etapa de desarrollo muy temprana, los desarrolladores deben considerar identificar qué soluciones de software serían beneficiosas para los usuarios de taxonomía y comprometerse con los desarrolladores de software o emprender la tarea ellos mismos para garantizar que estas soluciones estén o estarán disponibles.
| 4.6.4 | Documentación y comunicación |
Una vez que se ha desarrollado una taxonomía, debe estar debidamente documentada. Las taxonomías pueden ser extremadamente complejas, con cientos, si no miles, de conceptos, y el uso de esos conceptos debe estar claramente definido. Idealmente, una taxonomía XBRL es autodescriptiva; nada más que su esquema, sus bases de enlaces y las taxonomías referenciadas deben ser requeridas para usar y comprender la taxonomía. Dicho esto, los roles de las etiquetas (ver Sección 2.2.6.4) para cada concepto ayudan a definir sus usos, y estos deben ser correctos y estar debidamente documentados. Además, para las taxonomías que tienen un gran alcance y que son lo suficientemente complejas, es importante tener en cuenta los documentos de orientación, como las guías del preparador y otra información de apoyo. Estas son herramientas útiles para preparadores, consumidores y otras partes interesadas en la comprensión de la taxonomía, sus tipos de datos, y la forma en que representa la información dimensional. Tener la documentación adecuada puede ayudar a las personas de todos los conocimientos y niveles de habilidad a medida que comienzan a usar XBRL y la taxonomía recién desarrollada.
Los cambios en la taxonomía también deben comunicarse claramente a los usuarios de la taxonomía y, en algunos casos, a la comunidad en general. Este proceso de difusión debe estar predeterminado y generalmente se enmarca en una discusión sobre la gobernanza de la taxonomía, que se ha discutido brevemente en la Sección 4.6.2 y se explorará a fondo en el Capítulo 9.
| 4.6.5 | Propiedad intelectual |
Dependiendo del tamaño y el propósito de la taxonomía, puede haber consideraciones legales sobre las herramientas y la información necesarias para desarrollarla. En estos casos, los desarrolladores deben salvaguardar la taxonomía contra cualquier problema futuro al exigir a todos los participantes en el proceso de desarrollo que firmen acuerdos de propiedad intelectual (PI) , indicando que estos participantes están contribuyendo libremente con todos los productos de trabajo y comentarios. Por ejemplo, cuando XBRL US tiene grupos de trabajo donde se lleva a cabo el desarrollo, se lee una declaración de IP al comienzo de cada llamada o reunión para que los contribuyentes estén al tanto de los límites en los que se utilizarán sus contribuciones. El Apéndice I muestra un ejemplo de acuerdo de propiedad intelectual que se puede utilizar para este propósito y para la revisión pública que se analiza más adelante en este capítulo.
| 4.6.6 | Requisitos de equilibrio |
En la creación de cualquier sistema complejo, seguramente habrá desacuerdos sobre las metas que deben alcanzarse y la importancia de los resultados relativos. Las partes interesadas, que pueden incluir preparadores de datos, consumidores de datos, agencias reguladoras y otras partes interesadas, pueden tener perspectivas únicas sobre la naturaleza de la taxonomía que se desarrollará. Sin embargo, como se discutió anteriormente, es probable que ninguna de las partes interesadas posea la amplitud de conocimientos y experiencia para dar forma a la taxonomía en su totalidad.
Una vez que se identifican todos los casos de uso, los requisitos funcionales y los requisitos no funcionales, se debe resolver cualquier conflicto que surja del proceso de investigación. Por ejemplo, puede darse el caso de que los preparadores se enfrenten a una carga de tiempo y / o monetaria significativa en la preparación de informes utilizando la taxonomía y, por lo tanto, agradecerían una estructura de informes simple. Los consumidores o reguladores pueden desear más información, lo que sugiere una estructura de informes más avanzada. Estas opiniones entran en conflicto directo. Se debe lograr un equilibrio entre los intereses de los preparadores y los consumidores, al mismo tiempo que se cumplen todos los requisitos y regulaciones funcionales (Figura 4-3).
Para resolver este tipo de situaciones, los requisitos pueden ponderarse por su importancia, como los elementos que «hacen o deshacen» el proyecto frente a los elementos que sería «bueno tener» o proporcionar un beneficio moderado. Algunas partes interesadas pueden ver algunos objetivos como muy importantes, mientras que otros los ven como no necesarios o ligeramente interesantes. Además, cada requisito agregará un nivel de esfuerzo de preparación e implementación, que también debe equilibrarse con el valor de los datos o del sistema que se está creando.
Es el trabajo de los desarrolladores de taxonomía tener en cuenta todos los requisitos funcionales y no funcionales durante el proceso de diseño y determinar cuáles son esenciales o importantes para el éxito de la taxonomía, que se pueden completar para reforzar o facilitar la facilidad de uso o intereses particulares. y que no son relevantes o alcanzables. En el ejemplo anterior, la carga para los preparadores puede equilibrarse con las necesidades de los consumidores / reguladores de tal manera que la taxonomía permita una inversión mínima de tiempo y aprendizaje por parte de los preparadores a medida que crean informes y abordan todos los aspectos. puntos que exigen los reguladores y consumidores. Los análisis de costo-beneficio, tanto en términos de costos de preparación de informes como en costos de desarrollo de la taxonomía en sí, pueden ayudar en estas decisiones. Al marcar los requisitos más importantes y / o clasificar los requisitos para determinar su prioridad, se puede organizar mejor un proceso de desarrollo complejo y los requisitos críticos pueden recibir la mayor atención. También puede ayudar a los gerentes y desarrolladores de proyectos a asignar el personal, el esfuerzo y el énfasis adecuados para cada requisito, al mismo tiempo que guía la creación y supervisión de la lista de tareas. Los desarrolladores también deben considerar las trampas de la «elegancia progresiva», donde las soluciones simples se vuelven cada vez más complicadas para lograr una funcionalidad que es «agradable de tener», ordenada o elegante, pero no estrictamente necesaria. En estos casos, el costo y la complejidad superan rápidamente las ganancias de la solución. y los requisitos críticos pueden recibir la mayor atención. También puede ayudar a los gerentes y desarrolladores de proyectos a asignar el personal, el esfuerzo y el énfasis adecuados para cada requisito, al mismo tiempo que guía la creación y supervisión de la lista de tareas. Los desarrolladores también deben considerar las trampas de la «elegancia progresiva», donde las soluciones simples se vuelven cada vez más complicadas para lograr una funcionalidad que es «agradable de tener», ordenada o elegante, pero no estrictamente necesaria. En estos casos, el costo y la complejidad superan rápidamente las ganancias de la solución. y los requisitos críticos pueden recibir la mayor atención. También puede ayudar a los gerentes y desarrolladores de proyectos a asignar el personal, el esfuerzo y el énfasis adecuados para cada requisito, al mismo tiempo que guía la creación y supervisión de la lista de tareas. Los desarrolladores también deben considerar las trampas de la «elegancia progresiva», donde las soluciones simples se vuelven cada vez más complicadas para lograr una funcionalidad que es «agradable de tener», ordenada o elegante, pero no estrictamente necesaria. En estos casos, el costo y la complejidad superan rápidamente las ganancias de la solución. donde las soluciones simples se vuelven cada vez más complicadas para lograr una funcionalidad que es «agradable de tener», ordenada o elegante, pero no estrictamente necesaria. En estos casos, el costo y la complejidad superan rápidamente las ganancias de la solución. donde las soluciones simples se vuelven cada vez más complicadas para lograr una funcionalidad que es «agradable de tener», ordenada o elegante, pero no estrictamente necesaria. En estos casos, el costo y la complejidad superan rápidamente las ganancias de la solución.
Como regla general, los desarrolladores siempre deben tener en cuenta que una taxonomía no puede ser «todo para todas las personas», lo que significa que no puede lograr todos los casos de uso o solicitudes / recomendaciones por igual o en absoluto. Los requisitos más importantes deben tener prioridad.
Una vez que se ha desarrollado la taxonomía, la atención se centra en las pruebas y la validación. ¿Cómo pueden saber los desarrolladores que la taxonomía está funcionando como se anticipó? ¿Qué modelos y métodos serán útiles para probar la taxonomía? ¿Cómo pueden las partes interesadas (consumidores, reguladores, auditores y otras personas relevantes) estar seguras de que los datos son correctos y válidos? ¿Cómo se puede validar la calidad de los datos de los informes XBRL, incluida su precisión e integridad?
Dependiendo del alcance de la taxonomía, medir el éxito del modelo de transporte puede ser un proceso bastante complejo. Además, el «éxito» de algunas partes interesadas puede no equivaler a «éxito» de otras. Por ejemplo, es posible que un consumidor solo se preocupe por los datos numéricos que forman parte de un cálculo, por lo que un arco de cálculo que utilice esos datos que representan una suma precisa puede no importar. Otro consumidor solo puede estar interesado en el resultado del cálculo, por lo que en este caso la definición del cálculo es vital. La prueba de la taxonomía debe abordar ambos casos. Al igual que con la definición y clasificación de requisitos y la exploración de casos de uso, puede resultar útil determinar cuáles son las medidas de éxito y cómo se evaluarán antes del desarrollo.
Al final, validar una taxonomía puede resultar casi tan importante como diseñarla. Existen múltiples enfoques para verificar los errores de una taxonomía, como establecer un comité de gobernanza de la calidad de los datos que pueda diseñar reglas de calidad de los datos y garantizar una representación adecuada de la información. Como se indicó anteriormente, XBRL tiene algunas disposiciones para garantizar la integridad de los datos, como tipos de datos de concepto y cálculos, definiciones y otras relaciones que el software XBRL puede usar para verificar errores. Como nota al margen, las reglas del Comité de Calidad de Datos de XBRL de EE. UU. Están disponibles gratuitamente y pueden usarse para verificar la consistencia y precisión de la información con formato XBRL.
Más allá de la calidad de los datos, también existe la cuestión de determinar si la taxonomía realmente cumple con sus requisitos y objetivos funcionales. ¿El modelo de transporte ofrece suficientes tipos de datos adecuados para que los consumidores los utilicen? Una vez más, esto vuelve a identificar y comprender los requisitos y los casos de uso; esto ayudará a generar puntos finales en el proceso de desarrollo y dictará medidas de éxito. Para taxonomías a gran escala con muchos casos de uso, partes interesadas y una gran variedad de personas que usan la taxonomía, involucrar a más usuarios a través de comentarios públicos y revisión de esquemas candidatos, modelos de información y documentación puede ser extremadamente útil. Es posible que las etapas iniciales de desarrollo solo hayan involucrado las perspectivas y opiniones de algunas partes interesadas clave, por lo que una revisión pública puede abrir la puerta a conocimientos adicionales. Los desarrolladores también pueden crear documentos de instancia de muestra utilizando la taxonomía como un medio para probar y medir el éxito general de la taxonomía. La creación de muestras resaltará las áreas donde faltan conceptos o donde la estructura de la taxonomía puede ser complicada para la preparación. Estas instancias de muestra validadas y refinadas se pueden difundir a los proveedores de software para que puedan anticipar cómo necesitarán adaptarse a la taxonomía, lo que a su vez puede proporcionar retroalimentación sobre cómo funciona la taxonomía con los datos en sí. Estos ciclos de revisión ayudan a guiar a los desarrolladores de taxonomía a determinar las medidas de éxito y cómo examinarlas adecuadamente para asegurarse de que la taxonomía esté funcionando exactamente como debería. La creación de muestras resaltará las áreas donde faltan conceptos o donde la estructura de la taxonomía puede ser complicada para la preparación. Estas instancias de muestra validadas y refinadas se pueden difundir a los proveedores de software para que puedan anticipar cómo necesitarán adaptarse a la taxonomía, lo que a su vez puede proporcionar retroalimentación sobre cómo funciona la taxonomía con los datos en sí. Estos ciclos de revisión ayudan a guiar a los desarrolladores de taxonomía a determinar las medidas de éxito y cómo examinarlas adecuadamente para asegurarse de que la taxonomía esté funcionando exactamente como debería. La creación de muestras resaltará las áreas donde faltan conceptos o donde la estructura de la taxonomía puede ser complicada para la preparación. Estas instancias de muestra validadas y refinadas se pueden difundir a los proveedores de software para que puedan anticipar cómo necesitarán adaptarse a la taxonomía, lo que a su vez puede proporcionar retroalimentación sobre cómo funciona la taxonomía con los datos en sí. Estos ciclos de revisión ayudan a guiar a los desarrolladores de taxonomía a determinar las medidas de éxito y cómo examinarlas adecuadamente para asegurarse de que la taxonomía esté funcionando exactamente como debería. lo que a su vez puede proporcionar retroalimentación sobre cómo funciona la taxonomía con los datos en sí. Estos ciclos de revisión ayudan a guiar a los desarrolladores de taxonomía a determinar las medidas de éxito y cómo examinarlas adecuadamente para asegurarse de que la taxonomía esté funcionando exactamente como debería. lo que a su vez puede proporcionar retroalimentación sobre cómo funciona la taxonomía con los datos en sí. Estos ciclos de revisión ayudan a guiar a los desarrolladores de taxonomía a determinar las medidas de éxito y cómo examinarlas adecuadamente para asegurarse de que la taxonomía esté funcionando exactamente como debería.
La Tabla 4-1 presenta una métrica general de éxito que puede usarse como base para métricas individualizadas para un proyecto de desarrollo de taxonomía. Una vez más, evaluar qué tan bien una taxonomía satisface las necesidades de información del grupo o industria puede variar de una situación a otra. Estos puntos y cómo se pueden evaluar deberían guiar a los desarrolladores a determinar cómo medir el éxito de su propia taxonomía.
| Métrico | Evaluación |
| Propósito | La taxonomía cumple con los requisitos funcionales y no funcionales. Los informes XBRL se evalúan para determinar su utilidad por caso de uso. |
| Calidad | Los datos son correctos y precisos, tanto en su expresión como en su interpretación. Existen reglas de validación y calidad de datos. |
| Lo completo | Todos los datos necesarios para cumplir con los requisitos de taxonomía se expresan en la taxonomía. |
| Concisión | La información innecesaria no está presente en la taxonomía. Se consolida la información redundante. |
| Unicidad | Los datos se pueden identificar de forma única con la taxonomía sin información duplicada. |
| Usabilidad | La documentación sobre la taxonomía, su sistema de informes y cómo crear / usar informes está disponible. El software de apoyo está disponible si es necesario. |
Tabla 4-1. Métricas de ejemplo para el éxito de la taxonomía
| 5 | Creación de un modelo de datos de transporte |
| 5.1 | Empezando |
Antes de que se pueda construir una taxonomía, los desarrolladores deben crear el modelo de datos de transporte. Como se puede imaginar de los capítulos anteriores, este modelo de transporte, dependiendo de los casos de uso y requisitos del proyecto, puede ser simple o complejo. El modelo en sí tiene un gran impacto en las opciones de diseño y el desarrollo de la taxonomía, así como en la eventual facilidad de uso para los preparadores y consumidores. Por supuesto, la calidad de los datos que se van a transportar y divulgar es de suma importancia, y el modelo de datos debe ser lo suficientemente sólido y estar bien diseñado para mantener la integridad de los datos y promover la validación de los datos.
Al definir el modelo, los desarrolladores primero deben comprender su conjunto mínimo de datos, es decir, la cantidad de datos necesarios para cumplir con todos los casos de uso, requisitos y regulaciones involucradas sin incluir información redundante o extraña. La definición de este conjunto de datos guiará el desarrollo. Después de este paso crucial, se pueden considerar otros temas, como la extensibilidad, el formato del documento de instancia XBRL e incluir información de otras taxonomías. Este capítulo proporciona una guía para definir el conjunto de datos, construir el modelo de transporte, tomar decisiones de diseño sólidas y luego diseñar la taxonomía en sí.
Para este capítulo, se utilizará el ejemplo de ventas de widgets del Capítulo 3 para demostrar las opciones de diseño de taxonomía. Se realizan algunos cambios en el ejemplo para mostrar diferentes estructuras taxonómicas. Si bien la discusión en el Capítulo 3 exploró ampliamente los tipos de modelos de datos y construcciones XBRL análogas, este capítulo presenta una discusión más enfocada basada en modelar un solo conjunto de datos desde las etapas iniciales hasta un modelo de datos de transporte completo.
Una vez que el equipo de desarrollo ha determinado los parámetros del proyecto como se describe en el Capítulo 4, se puede comenzar a trabajar en la definición del modelo de transporte. Con los objetivos en mente, los desarrolladores deben traducir los conjuntos de datos que se encuentran actualmente en uno o más modelos comerciales originales a la taxonomía XBRL. Para hacerlo, primero deben describir esos conjuntos de datos de origen, su dimensionalidad y qué partes de ellos se incluirán en la taxonomía.
Considere el ejemplo del widget. Este es un conjunto de datos de muestra que debe representar el modelo de transporte desarrollado (Tabla 5-1 y Tabla 5-2).
Siendo realistas, una taxonomía contendrá varios informes y muchos más datos, y las interacciones entre las diferentes presentaciones y tablas dentro de la taxonomía pueden ser complejas. Este ejemplo más simple explorará algunas de estas interacciones a medida que avanza el capítulo.
5.2.1 Requisitos funcionales y no funcionales de la taxonomía
En esta coyuntura, los desarrolladores deben tener los requisitos funcionales y no funcionales del modelo de datos descrito (Sección 4.1). Con estos requisitos en mente, los desarrolladores pueden comenzar a asignar los requisitos a los datos. Si ya existen conjuntos de datos de sistemas actuales o heredados, los desarrolladores deben examinar cómo se alinean los requisitos con la estructura de estos conjuntos de datos. De lo contrario, los desarrolladores pueden comenzar a diseñar nuevos conjuntos de datos.
En el ejemplo del widget, el objetivo es determinar los ingresos de cada tipo de widget individual. Por lo tanto, la taxonomía puede modelarse separando los costos de producción de los widgets de los de las ventas de widgets. Este es el requisito funcional e implicaría informar las compras totales de widgets y el costo total para producirlos. Los datos disponibles, tal como se definen en la Tabla 5-1 y la Tabla 5-2, incluyen componentes de estos valores, pero no los valores en sí mismos, aunque esos valores pueden derivarse.
Supongamos, sin embargo, que existen requisitos no funcionales. Estos podrían incluir informes de información más específica, incluido el informe de ventas individuales de widgets. Quizás un caso de uso particular requiera esta información o los informes actualmente contienen esta información y cambiar esto afectaría el flujo de trabajo. Este es un requisito no funcional porque esta información no es necesaria para determinar los ingresos por tipo de widget. El ejemplo de widget asumirá que la información sobre las ventas de widgets individuales es un requisito no funcional y se incluirá en el proceso de modelado.
| 5.2.2 | Determinación del conjunto mínimo de datos |
Como paso inicial, el desarrollador debe determinar qué constituye un conjunto de datos completo para una instancia. Este conjunto mínimo de datos debe estar libre de información redundante o superflua y al mismo tiempo representar todos los datos necesarios. Un modelo de datos parsimonioso se prestará a una taxonomía bien estructurada, fácilmente comprensible y lógicamente organizada.
Dependiendo de la amplitud y el alcance de la taxonomía que se está desarrollando, el conjunto mínimo de datos puede no ser un conjunto de datos único sino múltiples conjuntos de datos de múltiples fuentes. Por ejemplo, una taxonomía para informes de fabricación puede incluir numerosas tablas de información relacionada pero semánticamente independiente (como una tabla de inventario de materias primas para un conjunto de productos y una tabla de costos de fabricación asociados con los mismos productos). Cada uno de ellos puede pasar a formar parte del conjunto mínimo de datos. Estos múltiples conjuntos de datos pueden derivarse de múltiples fuentes, como formularios en papel o bases de datos de software preexistentes.
Para el ejemplo del widget, el conjunto mínimo de datos se alinea directamente con los requisitos de informes. Los preparadores deben informar las ventas de unidades de widgets por tipo, precio y cliente, las compras totales de widgets en dólares estadounidenses y la fecha de cada compra. Además, deben informar el costo total para producir cada tipo de widget. Finalmente, deben informar los ingresos totales por tipo de widget. Los preparadores también deben informar el período al que pertenecen los datos y el nombre de la empresa informante. Esto, por lo tanto, forma el conjunto mínimo de datos para esta taxonomía simple.
| 5.2.2.1 | Sistemas actuales y heredados |
Los sistemas actuales y heredados pueden proporcionar una buena base para determinar el conjunto mínimo de datos. Si bien los sistemas actuales son un buen punto de partida para determinar el conjunto mínimo de datos, los desarrolladores deben considerar si estos requisitos siguen siendo apropiados. A menudo, cuando los requisitos de generación de informes evolucionan a lo largo de los años o incluso décadas, los sistemas de recopilación de datos que no son óptimos se adaptan mediante «soluciones alternativas» para evitar una reingeniería completa del sistema. Estos métodos alternativos pueden «hacer el trabajo», pero pueden no ser ideales, y un cambio a XBRL brinda una buena oportunidad para volver a examinar estos problemas.
Los tipos de sistemas o formatos de datos que pueden ayudar a describir el conjunto de datos de origen pueden ser:
| • | formularios en papel / PDF |
| • | hojas de cálculo o archivos CSV |
| • | otras formas XML |
| • | bases de datos |
| • | sitios web |
Cada uno de estos sistemas tiene un formato y una estructura inherentes a él. Es el trabajo del desarrollador determinar cómo esos formatos y sistemas «encajan» con la taxonomía. Como se dijo anteriormente, los desarrolladores deben recopilar estos sistemas e identificar los datos necesarios mientras eliminan la información redundante o irrelevante para crear un conjunto de datos mínimo y parsimonioso sobre el cual se puede construir la taxonomía.
| 5.2.3 | Creación de un modelo de datos conceptual |
Con el conjunto mínimo de datos y los requisitos claramente definidos, la tarea pasa a ser realmente realizar esos requisitos a través de la taxonomía misma, es decir, definir un modelo de datos conceptual. Este es el modelado inicial de la taxonomía, que se centra en los requisitos y casos de uso estáticos y generales, y en cómo los cumple el conjunto mínimo de datos.
Este paso conduce a una parte importante de la definición del modelo de datos: los desarrolladores deben esforzarse por reducir la información repetitiva, eliminándola toda si es posible. Si, como se mencionó anteriormente, los datos subyacentes a varios formularios se unen en una taxonomía XBRL, puede haber información duplicada (como el nombre de la empresa, por ejemplo, o el tipo de widget en el ejemplo del widget). Del mismo modo, los desarrolladores deben identificar la información que es la misma en múltiples conjuntos de datos, incluso si es el foco en un conjunto de datos y solo es contextual en otro. Tener en cuenta estas situaciones durante el proceso de diseño puede reducir la creación de conceptos redundantes y la dimensionalidad inadecuada. Además, puede haber conceptos que parecen ser los mismos en múltiples conjuntos de datos, pero en realidad no lo son, y estos deben identificarse, separarse y definirse sin ambigüedades en la taxonomía.
| 5.2.4 | Arquitectura de datos |
Una vez que se definen los requisitos en el modelo de datos conceptual, los desarrolladores pueden comenzar a redactar un modelo de datos lógico, que explora los puntos de datos en el modelo de datos conceptual y, lo que es más importante, cómo se relacionan entre sí y con otras construcciones de datos. Debido a que el ejemplo del widget no contiene muchas relaciones de datos complejas, el modelo de datos lógicos es muy similar al modelo de datos conceptual. El objetivo es informar los ingresos de los widgets por tipo, que es un valor derivado compuesto por las ventas de widgets y los costos de producción de widgets. Los costos de ventas y producción de los widgets están en el conjunto de datos suministrado, pero los ingresos no. Si el objetivo es informar el valor X, pero X se compone de puntos de datos A, B, C (todos con información contextual diferente), se requiere conocimiento de A, B, C si X no es parte del conjunto de datos actual (como en el ejemplo del widget). Este no es necesariamente siempre el caso. La arquitectura de datos debe poder representar todo el conjunto mínimo de datos, incluyendo cualquier valor derivado requerido según lo establecido por los requisitos fundamentales. En todos los casos, el modelo de datos conceptual debe impulsar el modelo de datos lógicos.
Nuevamente, el conjunto mínimo de datos y, por lo tanto, los modelos de datos conceptuales y lógicos, deben ser parsimoniosos. Evite información innecesaria o datos redundantes.
| 5.2.4.1 | Relaciones de datos estándar |
El Capítulo 3 introdujo brevemente algunas relaciones de datos estándar comunes a un modelo de datos relacionales. La relación uno a uno existe o puede existir entre un punto de datos y otro punto de datos. Son muy comunes en muchos entornos de informes. La relación de uno a muchos existe o puede existir entre un punto de datos y muchos otros puntos de datos. Por ejemplo, los ingresos totales del punto de datos de ventas de widgets se componen de una o más ventas individuales de tipos de widgets; por lo tanto, existe una relación de uno a muchos entre las ventas totales y las ventas de tipos individuales. Una relación de varios a varios define una relación que existe o puede existir entre muchos puntos de datos. Si el requisito fundamental es reportar todos ventas de widgets, esta situación puede producir relaciones de muchos a muchos, como se ve en la Sección 3.2.3.
También puede haber relaciones de cero a uno, donde un punto de datos de un par puede existir con o sin el otro punto de datos. Este concepto se extiende a las relaciones de cero a muchos. Estas relaciones se ven más comúnmente como la construcción: si el punto de datos X existe, el punto de datos Y puede o no existir. Esto no debe confundirse con las relaciones de exclusión, por ejemplo, si el punto de datos X existe, el punto de datos Y no puede existir.
Los desarrolladores deben examinar el conjunto mínimo de datos y trazar estas relaciones entre sus puntos de datos a medida que desarrollan su modelo de datos lógicos. Se puede emplear cualquier metodología de modelado siempre que sea apropiada para los datos, pero la metodología debe usarse de manera consistente para crear modelos coherentes.
Para comenzar a definir las relaciones de datos, los desarrolladores deben determinar primero el punto o los puntos de datos primarios necesarios para cumplir con los requisitos. En el ejemplo del widget, esto sería el total de ventas y gastos totales por tipo de widget. Esto significa que el identificador semántico del tipo de widget definirá las relaciones de datos. Sobre la base de esto, se pueden determinar relaciones adicionales. Las ventas totales y los gastos totales se componen de una o más ventas y gastos individuales, respectivamente. Estas son relaciones de uno a muchos. Hay relaciones uno a uno para cada componente de las ventas y los gastos. Una venta individual tiene solo un tipo de widget, un cliente, una fecha, etc., y cada gasto individual se compone de un tipo, cantidad y precio de widget por widget.
Tenga en cuenta que debido a que los requisitos fundamentales estipulan que solo se informarán las ventas por tipo de widget, las ventas que incluyan más de un tipo de widget deben separarse por tipo para ajustarse al modelo de datos. Esto puede no coincidir con la forma en que los datos de ventas se registran típicamente en la industria (si se realiza un seguimiento por cliente y fecha o un número de factura, por ejemplo). Los desarrolladores deben decidir si esta elección de diseño es una carga para los preparadores o si el modelo de datos debe ajustarse. Para este ejemplo, el modelo de datos no se ajustará para tener en cuenta esto.
Este borrador de un posible modelo de datos lógicos para la taxonomía de widgets aparece en la Figura 5-1.
Los elementos en naranja son los mismos para cada sección del modelo. El significado del tipo de widget no cambia a pesar de su contexto. Sin embargo, la cantidad adquiere un significado diferente según su contexto (por ejemplo, venta versus gasto). Se podría considerar que el tipo de widget es una clave para las tablas que no solo vincula lógicamente los componentes del modelo de datos, sino que también confiere unicidad al punto de datos. Se discute más sobre la singularidad en la siguiente sección.
Los elementos en azul también son los mismos, pero pertenecen al informe individual, no al modelo de datos lógicos. Si bien es importante tener en cuenta esta información en el proceso de planificación, estos puntos de datos no pertenecen a la taxonomía XBRL, sino que se definen en un informe XBRL. Debido a que son constantes dentro del informe, no es necesario un conocimiento contextual de esta información.
| 5.2.4.2 | Definición de unicidad |
A medida que los desarrolladores mapean y definen las relaciones de datos, la singularidad debería hacerse evidente a través de esas relaciones. El mismo punto de datos puede aparecer en varios lugares dentro del modelo de datos lógicos, pero cada apariencia debe ser única a través de su contexto (relaciones con otros puntos de datos) o ser exactamente el mismo punto de datos (interpretado de la misma manera). Este es un paso importante en la creación del modelo. Si los desarrolladores descubren que no pueden representar la unicidad con las relaciones que han diseñado, es posible que se necesiten más datos (y por lo tanto más información contextual).
En el modelo de datos lógicos del widget, el tipo de widget define datos que son únicos a través de su contexto, mientras que la empresa y la fecha del informe son ejemplos de puntos de datos que son exactamente iguales. Cabe señalar que, en el modelo de datos actual, si el mismo cliente realiza dos ventas individuales el mismo día de las mismas cantidades del mismo tipo de widget, los datos no serán únicos. En este caso, las ventas deben ser sumadas por el preparador o se debe agregar una dimensión arbitraria adicional para mantener la singularidad. Puede ser una factura o un número de pedido. Consulte la Sección 3.3.1.2 para obtener más información.
Con un modelo de datos lógicos definido, los desarrolladores pueden crear un modelo de datos físicos , que representa el modelo tal como aparecerá en formato XBRL. El modelo de datos físicos debe indicar a) todos los conceptos de la taxonomía, incluidas sus propiedades, yb) las relaciones entre los conceptos (como arcos o mediante una estructura jerárquica abstracta, por ejemplo). Este modelo físico se convierte entonces en el modelo de transporte.
| 5.3.1 | Tipos de datos |
Cada punto de datos en el modelo de datos lógicos debe examinarse y etiquetarse con su tipo de datos correspondiente. Como regla general, se debe utilizar el tipo de datos más restrictivo siempre que sea posible. Por ejemplo, un valor numérico debe tener un tipo de datos numérico que permita la precisión matemática que requieren los datos. Si el punto de datos contiene una cantidad monetaria que nunca será más precisa que dos lugares decimales, se puede elegir o crear un tipo de datos que imponga esta restricción. Los desarrolladores también deben tener en cuenta que las relaciones entre los puntos de datos pueden influir en las limitaciones del tipo de datos. Por ejemplo, un punto de datos que normalmente representa solo valores positivos puede volverse negativo en un contexto específico dentro del modelo de datos, como un contexto de ajustes. El inventario perdido normalmente sería un valor positivo, excepto en el caso de que se pueda encontrar o restaurar inventario. En este caso, se volvería negativo.
Todos los tipos de datos deben extraerse de los tipos de datos estándar XBRL (consulte la Sección 2.3.1 y el Apéndice A). Si no existe un tipo de datos estándar que pueda representar con precisión un punto de datos, los desarrolladores pueden crear un tipo de datos personalizado.
Para una discusión de los posibles tipos de datos para la taxonomía de widgets y las razones detrás de su selección, consulte 3.4.1.1.
| 5.3.1.1 | Definición de valores mediante enumeración |
Puede haber situaciones en las que el hecho informado para un concepto específico deba limitarse a un determinado conjunto de valores. Por ejemplo, en la taxonomía del botón naranja, el concepto ApprovalStatus tiene un conjunto definido de valores de hechos que son: «NoEnviado «,» Enviado «,» Aprobación condicional «,» Aprobación final «y» Rechazado «. Los desarrolladores de taxonomía pueden crear enumeraciones específicas para su taxonomía como un medio para limitar lo que los preparadores pueden ingresar como valor, lo que puede mejorar la coherencia y comparabilidad de los datos reportados. Las listas enumeradas también pueden estar compuestas por un conjunto finito de valores (como códigos de área de EE. UU.), que no se enumeran en la taxonomía porque no sería práctico incluirlos. Los desarrolladores de taxonomía pueden agregar metadatos asociados con las enumeraciones en una lista para ayudar a los preparadores a comprender mejor lo que significan. También pueden dar a los preparadores la capacidad de agregar elementos a la lista enumerada, aunque esto puede reducir la coherencia y comparabilidad de los datos notificados. Según la Especificación XBRL , las enumeraciones se pueden crear a través de tipos de datos de esquema XML.
La Especificación de enumeraciones extensibles amplía esto y permite que las etiquetas y referencias se asocien con enumeraciones. También permite el uso de enumeraciones como dimensiones. Puede haber situaciones en las que se deba utilizar una lista enumerada como calificador dimensional para dimensiones definidas por taxonomía tipificada (como se analiza en la Sección 3.4.2.2). Por ejemplo, es posible que una taxonomía deba poder informar ventas por un conjunto definido de productos: A, B y C.Una lista enumerada de productos (A, B, C) se puede definir como una dimensión de producto mecanografiada y se puede informar con las ventas como dimensión central del concepto. La especificación de enumeraciones extensibles también explica cómo se pueden ampliar las enumeraciones y cómo indicar que no se puede informar una enumeración en particular. Los miembros de XBRL International pueden obtener más información sobre cómo aprovechar el poder de las enumeraciones a través de los artículos técnicos «Enumeraciones en XBRL» y «Cómo definir una lista de valores permitidos» . Para obtener información sobre cómo convertirse en miembro y obtener acceso a estos y otros temas, envíe un correo electrónico a info@xbrl.us .
| 5.3.2 | Creación de dimensiones XBRL |
Cada punto de datos en el modelo de datos lógicos debe estar representado por una dimensión central del concepto y otras dimensiones centrales o definidas por taxonomía. La dimensión central del concepto debe pertenecer al significado semántico de ese punto de datos. Dada la relación de ese punto de datos con otros puntos de datos, se pueden usar diferentes conjuntos de dimensiones definidas por taxonomía con la dimensión central del concepto. Por ejemplo, una tabla puede contener datos para las ventas totales por región y otra puede contener datos para las ventas totales por tipo de producto, pero la dimensión central del concepto para ambas tablas son las ventas y, por lo tanto, debe contener el mismo valor para el total. Al utilizar la misma dimensión central del concepto, se refuerza esta relación entre los totales. El conjunto de otras dimensiones XBRL difiere, lo que también confiere singularidad.
Solo las dimensiones del núcleo del concepto y las definidas por taxonomía forman parte de la taxonomía XBRL; otras dimensiones centrales las define el preparador en el documento de instancia. Esto se debe a que el significado semántico de estas dimensiones centrales es estático y está definido en la Especificación XBRL ; solo los valores cambian de un informe a otro. Las dimensiones definidas por taxonomía y las dimensiones centrales del concepto no deben crearse para la información contextual que representan las otras dimensiones centrales XBRL, como las unidades o el período del informe. Consulte la Figura 2-17 para obtener más información sobre qué definiciones están contenidas en la taxonomía frente al documento de instancia.
Tenga en cuenta que los puntos de datos pueden tener el mismo nombre en lenguaje natural (como «costo» o «cantidad»), pero semántica o contextualmente significan cosas diferentes. Los desarrolladores deben esforzarse por identificar estas situaciones y asegurarse de que los nombres de los conceptos sean únicos e inequívocos.
A medida que se definen los conceptos, los desarrolladores también deben describir sus propiedades, etiquetas, documentación y referencias relevantes. Esto comienza a construir la biblioteca de información que se convertirá en el modelo de transporte. El modelo de datos lógicos para la taxonomía de widgets, con sus nombres de concepto y tipos de datos definidos, ahora aparece como:
El modelo de transporte de la Figura 5-2 aún no está completo porque no se han modelado las relaciones entre los conceptos. Para hacer esto, se deben crear dimensiones definidas por taxonomía.
| 5.3.2.1 | Definición de las dimensiones fundamentales del concepto |
Este es un paso crucial en el diseño del modelo de transporte de taxonomía. Las dimensiones centrales del concepto se relacionan directamente con los datos que deben informarse según los requisitos fundamentales. Por lo tanto, estos deben definirse primero, y el resto de la información contextual se convierte en dimensiones definidas por la taxonomía.
En general, comprender los datos se vuelve más complicado a medida que aumenta la información contextual. Por lo tanto, a menudo es deseable representar tanta información relevante como sea posible con las dimensiones centrales del concepto. En la Sección 3.3.1.2, hay una discusión sobre las implicaciones de representar datos con el núcleo del concepto versus las dimensiones definidas por la taxonomía. En la taxonomía de widgets, los requisitos solo dictan que los widgets vendidos y los gastos de los widgets estén representados por las dimensiones del núcleo del concepto; estos son los valores clave de los informes. Sin embargo, más información se presta a la representación de la dimensión central del concepto para hacer que el modelo sea más simplificado y más fácil de entender.
El modelo de datos para las ventas en la taxonomía de widgets podría tener la siguiente progresión de diseño:
| Diseño inicial | Añadiendo singularidad | Modelo final | |||
| Nombre del cliente | TDD | Nombre del cliente | CCD | Nombre del cliente | CCD |
| Fecha de orden | TDD | Fecha de orden | CCD | Fecha de orden | CCD |
| PricePerWidget | TDD | PricePerWidget | CCD | PricePerWidget | CCD |
| WidgetSaleIncome | CCD | WidgetSaleIncome | CCD | WidgetSaleIncome | CCD |
| WidgetType | TDD | WidgetType | CCD | WidgetType | TDD |
| Widgets vendidos | TDD | Widgets vendidos | CCD | Widgets vendidos | CCD |
| Factura | TDD | Factura | TDD | ||
| CCD = Dimensión central del concepto TDD = Dimensión definida por taxonomía |
Tabla 5-3. El proceso de diseño de taxonomía de widgets para la tabla de ventas de widgets individual
En la Tabla 5-3, el proceso de diseño puede comenzar con un conjunto de datos mínimo inicial, en el que, según los requisitos, solo el concepto WidgetSaleIncome es una dimensión central del concepto. Todos los demás conceptos son dimensiones definidas por taxonomía, que agregan datos contextuales y unicidad a cada punto de datos. Este modelo es bastante complejo para datos tan simples cuando se organiza de esta manera; se informa un único punto de datos utilizando cinco dimensiones definidas por la taxonomía para garantizar que el valor sea único y se comprenda sin ambigüedades. La singularidad se puede obtener agregando una dimensión XBRL arbitraria, en este caso Factura. Agregar esta dimensión reduce significativamente la complejidad del modelo como se ve en la segunda columna. Esto se debe a que Factura es la única información contextual necesaria para crear datos únicos (ya que cada venta debe tener su propio número de factura).
Sin embargo, el requisito de la taxonomía es comparar las ventas de widgets por tipo de widget. Por lo tanto, el tipo de widget debe ser contextual y esto se representa en la columna final devolviéndolo a una dimensión definida por taxonomía. Esta elección se basa estrictamente en los requisitos de la taxonomía. Si el objetivo es comparar las ventas por cliente, Customer Name se convertiría en una dimensión definida por taxonomía. Los desarrolladores deben ajustar el modelo para cumplir con los requisitos de la manera más sucinta y clara posible.
También es posible modelar Widget Type como una dimensión central del concepto y una dimensión definida por taxonomía, lo que permite a los preparadores decidir cómo implementar esta dimensión. Como suele ser el caso, esto proporciona una mayor flexibilidad, pero reduce la comparabilidad. Este enfoque es ventajoso para información opcional.
Este proceso de diferenciación entre el núcleo del concepto y las dimensiones XBRL definidas por taxonomía debe completarse para cada tabla u otro conjunto de datos relevantes que ingresen a la taxonomía. Las mismas dimensiones pueden, y potencialmente deberían, aparecer en varias tablas si su significado semántico es constante. También es posible que una dimensión central del concepto se convierta en una dimensión definida por taxonomía entre diferentes tablas y viceversa, dependiendo de las necesidades del modelo de datos. Si este es el caso, los desarrolladores deben asesorar a los preparadores sobre qué conceptos se aplican a qué tablas.
Una vez que los desarrolladores han identificado las dimensiones definidas por taxonomía en el modelo de datos, deben decidir si esas dimensiones serán escritas o explícitas. La sección 3.4.2 discutió brevemente la diferencia entre dimensiones definidas por taxonomía explícita y tipificada. Dependiendo de la naturaleza de las relaciones y la necesidad de extensibilidad, los desarrolladores deben decidir qué tipo de dimensión definida por taxonomía usar. Independientemente del tipo de relación (uno a muchos o muchos a muchos, por ejemplo), se puede aplicar cualquiera de estos tipos de dimensiones. El dominio de los datos a representar debe dictar la elección.
| 5.3.2.2.1 | Dimensiones definidas por taxonomía explícita |
Las dimensiones definidas por taxonomía explícita permiten al preparador especificar el dominio y los valores para ese dominio. También se pueden utilizar cuando la dimensión XBRL permite conceptos que pueden ser de naturaleza jerárquica.
Este es el único método de expresar dimensiones definidas por taxonomía que admite un dominio jerárquico. No es necesario que se utilicen únicamente para este fin; también pueden representar relaciones planas.
Como ejemplo, una dimensión definida por taxonomía para representar tipos de widget podría implementarse como una dimensión definida por taxonomía explícita. Si hay un número determinado de tipos de widgets (circular, rectangular, triangular), el dominio incluiría todos estos tipos de widgets y solo estos tipos. Las dimensiones definidas por taxonomía explícita se adaptan bien a estas situaciones en las que hay un conjunto predefinido de miembros para una dimensión. Si los desarrolladores permiten la extensibilidad, los preparadores podrían agregar sus propios elementos miembros para representar tipos de widgets personalizados e incluirlos dentro de este dominio. Además, con la extensibilidad, los preparadores podrían reducir el dominio de este eje. Si una empresa produce solo variaciones de widgets circulares, el preparador de este informe podría crear una dimensión XBRL de dominio explícitamente para widgets circulares y conceptos de miembros para los tipos circulares específicos. Debido a que el preparador definiría las relaciones entre estos conceptos y esta dimensión definida por taxonomía, la comparabilidad aún se mantiene con la adición de su información específica. Para obtener más información sobre la extensibilidad, consulte la Sección 5.4.2.
| 5.3.2.2.2 | Dimensiones definidas por taxonomía con tipo |
Una dimensión definida por taxonomía con tipo limita el dominio de valores potenciales al tipo de datos especificado. Dependiendo del tipo de datos, esto puede ser muy amplio o extremadamente limitado. Es importante destacar que limita la extensibilidad porque ningún valor fuera de ese tipo de datos puede formar parte del dominio. Además, no existen métodos para representar relaciones jerárquicas entre miembros.
Por ejemplo, si la dimensión definida por taxonomía de tipo de widget se implementa como una dimensión escrita con un tipo de datos de cadena, los preparadores podrían ingresar casi cualquier información como un tipo de widget. Tenga en cuenta que esto puede reducir en gran medida la comparabilidad, pero aumenta la flexibilidad del preparador sin necesidad de extensibilidad. Sin embargo, si el tipo de datos se limita a una enumeración de tipos de cadenas, los preparadores no tendrían más opciones que las establecidas por los desarrolladores en esa lista, a menos que la enumeración en sí pueda extenderse.
| 5.3.2.2.3 | Elección del mejor tipo de dimensión definida por taxonomía |
La naturaleza de los datos y los requisitos de presentación de informes deberían ayudar a determinar cómo seleccionar el tipo apropiado de dimensión definida por taxonomía. En general, las dimensiones definidas por taxonomía tipificada deben emplearse cuando el dominio del eje es fijo o cuando los valores individuales del eje no son relevantes para el modelo de datos. Por ejemplo, en la tabla de ventas de taxonomía de widgets, la dimensión de la factura tiene valores que no son necesariamente relevantes para el modelo de datos o los requisitos fundamentales de la taxonomía, sino que mantienen la unicidad entre los hechos. Por lo tanto, esta dimensión es más adecuada como una dimensión definida por taxonomía con tipo, potencialmente con un tipo de datos entero o de cadena, dependiendo de cómo se represente el identificador de orden.
Por el contrario, el tipo de widget se puede manejar como una dimensión definida por taxonomía explícita o escrita. Las secciones anteriores exploran las ramificaciones de ambas decisiones. En la taxonomía de widgets, WidgetType se tratará como una dimensión explícita definida por taxonomía.
| 5.3.2.3 | Completando el modelo de datos |
En esta etapa, los desarrolladores pueden comenzar a recopilar su biblioteca de conceptos. Además, algunas propiedades del concepto, como sus nombres, tipos de datos y etiquetas, pueden comenzar a definirse. También se puede definir cualquier gobernanza regulatoria relevante. Junto con este proceso, los desarrolladores pueden optar por comenzar a documentar su taxonomía. Tenga en cuenta que es posible que la biblioteca de conceptos no esté completa en este momento, ya que es posible que se requieran conceptos abstractos necesarios para representar relaciones adicionales.
Este también es un momento ideal, con la mayor parte del modelo de datos físicos desarrollado, para verificar dos veces que los requisitos originales de la taxonomía aún se están implementando y que todos los datos incluidos en el modelo son necesarios o relevantes.
Volviendo a la taxonomía de widgets, los requisitos descritos en este capítulo en realidad no requieren que se informe el desglose de los gastos por tipo de widget (Sección 5.2.1). La cantidad de widgets producidos y el costo de producción por widget no son necesarios para cumplir con los requisitos funcionales. Por lo tanto, no es necesario realizar un seguimiento de esta información dentro de la taxonomía. El modelo final puede aparecer así (Figura 5-3):
Las dimensiones definidas por taxonomía aparecen en texto naranja. Las dimensiones centrales del concepto están debajo de ellas en texto negro. Se ha eliminado la información que se incluye solo en el informe XBRL (la empresa informante y la fecha del informe). Tenga en cuenta que se ha agregado una cuarta tabla para el rendimiento del widget. Este es un valor derivado y representativo del requisito funcional de la taxonomía: informar cómo se desempeña cada widget en función de los costos de ventas y producción. Agregar esta tabla asegura que la taxonomía cumpla con sus objetivos.
Debido a que los requisitos y el conjunto mínimo de datos permitieron la eliminación de CostsPerWidget y WidgetsProduced y para que ProductionExpense se incorporara a WidgetExpenses, la Tabla 5-2 no se puede generar a partir de este modelo de datos. Dado que esto no formaba parte de los requisitos, no es motivo de preocupación. En este caso, es posible eliminar esta información de los modelos de datos lógicos y conceptuales y, por lo tanto, no modelar estos puntos de datos en absoluto. En taxonomías simples donde las relaciones son más obvias, este puede ser un enfoque más sencillo.
5.3.3 Relaciones representadas
Los documentos de base de enlaces XBRL definen las relaciones entre los conceptos. Estas relaciones se han discutido a lo largo de este manual, pero con mayor frecuencia incluyen presentaciones, cálculos y definiciones. Las relaciones entre los puntos de datos y, por lo tanto, los conceptos relacionados con esos puntos de datos, deben quedar claras a partir del modelo de datos físicos (Figura 5-3).
Las relaciones dentro del modelo de datos lógicos se convierten en documentos de base de enlaces para la taxonomía. Cada núcleo de concepto y dimensión definida por taxonomía debería aparecer en estas relaciones, a menos que en versiones posteriores de la taxonomía, la dimensión haya quedado obsoleta. Además de las presentaciones, los desarrolladores deben definir cálculos y definiciones cuando sea posible para ayudar tanto en la interpretación como en la validación de los datos. Finalmente, los desarrolladores podrían usar documentos de base de enlaces para indicar a los preparadores qué información se requiere para el conjunto mínimo de datos si hay más conceptos disponibles de los necesarios para preparar un tipo particular de informe.
El ejemplo de widget se presta a dos presentaciones: ventas de widgets individuales por tipo de widget y rendimiento de widget por tipo. Puede haber hasta cuatro presentaciones, pero incluir estas presentaciones adicionales agrega poca información única o relevante. La presentación del rendimiento del widget incluiría tanto la tabla de ventas totales como la tabla de gastos totales. Además, los ingresos por concepto de tipo de widget se pueden derivar mediante un cálculo entre los conceptos WidgetSales y WidgetExpenses para cada tipo de widget. Esto representa un valor imputado.
Sin embargo, WidgetSales no se puede derivar a través de un cálculo con la forma en que el modelo está estructurado actualmente. Esto se debe a que los cálculos no pueden hacer un puente entre los ejes, y WidgetSales es la suma de todos los conceptos de WidgetSaleIncome en el eje de la factura.
Las bases de enlaces de definición y presentación son muy similares para esta taxonomía. Además, los desarrolladores deben considerar otras bases de enlaces pertinentes, como etiquetas y referencias. Estos no son relevantes desde el punto de vista del modelado de datos y se analizan en la Sección 7.2.2.
| 5.3.4 | Relaciones intrínsecas |
Además de las relaciones definidas directamente, los modelos de datos lógicos a menudo contienen relaciones intrínsecas y otras relaciones lógicas que XBRL puede no representar directamente. Las relaciones intrínsecas incluyen puntos de datos que deben tener el mismo valor, puntos de datos que requieren la presencia de otros puntos de datos y puntos de datos que no pueden existir con otro punto de datos definido. Estas relaciones pueden depender en gran medida de la naturaleza de la información que representa el modelo. Si no hay forma de representar fácilmente esta información en el modelo de datos de transporte a través de una definición u otro arco conceptual, los desarrolladores pueden considerar agregar reglas de validación de datos para garantizar que se mantengan estas relaciones intrínsecas.
En la sección anterior, no había forma de garantizar que WidgetSales sea la suma de todos los conceptos de WidgetSaleIncome en todos los ejes de Factura. Esto no se puede lograr con un cálculo XBRL. Sin embargo, esta relación se puede lograr con una relación intrínseca. Para hacerlo, existen múltiples opciones. El primero sería agregar validación como se mencionó anteriormente. Esto está fuera del alcance de la taxonomía en sí, sino que pertenece a las reglas de calidad de los datos (consulte el Capítulo 6). La segunda opción implica reestructurar ligeramente el modelo de datos. WidgetSaleIncome y WidgetSales podrían representarse como una dimensión central de un solo concepto y, por lo tanto, convertirse en un hecho XBRL. Cuando la dimensión central del concepto no se cruza con una dimensión definida por taxonomía de factura (como en la tabla Ventas totales), el valor de este hecho es representativo del dominio de la dimensión definida por la taxonomía de la factura (es decir, una suma de todas las compras). Esto se representaría con relaciones de definición. Como efecto secundario, el total de la compra aparecerá no solo en la tabla de ventas totales sino también en la tabla de ventas individuales, aunque el valor solo se informa una vez. Tenga en cuenta que XBRL exige que los valores sean los mismos en ambas tablas porque se convierten en el mismo hecho, no necesariamente porque la suma de cada compra de widget individual sea realmente igual a la compra total.
La discusión sobre la creación de la taxonomía de widgets continúa en el Capítulo 7. Las siguientes secciones discuten otros aspectos importantes del desarrollo de la taxonomía no relacionados con el modelo de datos.
Muy a menudo, el modelo de transporte será parte de un sistema de informes más amplio. Este sistema de informes puede estar compuesto por varios componentes y puede realizar una multitud de tareas, incluida la recepción de informes XBRL, su validación, su almacenamiento y su posible difusión a los consumidores de datos. Los sistemas de informes pueden ser muy grandes, como el sistema EDGAR de la SEC, que recibe y publica públicamente informes financieros estructurados en XBRL de empresas en los Estados Unidos y en el extranjero. Este repositorio centralizado tiene muchos preparadores y consumidores de datos involucrados en su cadena de suministro de información. Por el contrario, los sistemas de informes pueden ser mucho más contenidos. Por ejemplo, en la industria del trabajo en proceso, las aseguradoras independientes tienen clientes que proporcionan directamente información XBRL. Estos clientes pueden, a su vez, suministrar esa información a múltiples aseguradoras,
El tamaño y la naturaleza del sistema de informes es una consideración para las etapas de diseño del proyecto (ver Capítulo 4). Este sistema debe cumplir con los requisitos funcionales del proyecto de informes y respaldar el uso exitoso de la taxonomía. Muchas opciones de diseño relacionadas con el sistema de informes, incluidos los requisitos particulares de software y hardware de la computadora, están fuera del alcance de este documento. Sin embargo, los desarrolladores de taxonomía querrán examinar cómo este sistema de informes interactuará e impactará el modelo de datos de transporte de la taxonomía. La naturaleza del sistema de informes puede influir en la taxonomía y viceversa. Las siguientes secciones examinan algunas opciones de diseño de sistemas de informes y cómo se relacionan con la taxonomía.
| 5.4.1 | Formato de transporte |
Si bien el formato de transporte tiene una influencia menor en el proceso de desarrollo de la taxonomía, tiene importantes implicaciones tanto para los preparadores de informes XBRL como para los consumidores de datos. Tenga en cuenta nuevamente que el esquema de taxonomía y los documentos de la base de enlaces deben proporcionarse en XML. Cuando se permite la extensibilidad, los usuarios pueden proporcionar documentos de esquema y bases de enlaces adicionales; de lo contrario, se puede hacer referencia a ellos desde una ubicación común. Los formatos de transporte se han analizado brevemente en los capítulos 1 y 2 y se analizan a continuación con mayor detalle. Los desarrolladores pueden permitir múltiples formatos de transporte o elegir no especificar un formato en absoluto. La decisión depende de los objetivos de la taxonomía, la propia cadena de suministro de información y las necesidades de la industria, independientemente de la selección final.
| 5.4.1.1 | XBRL como XML |
Los datos de instancia se pueden almacenar en formato XML (dictado por la Especificación XBRL ), que es el formato de transporte tradicional para datos XBRL. XML etiqueta los datos con elementos definidos en uno o más esquemas, que pueden expresar una amplia gama de tipos de datos. Una ventaja de utilizar XML como formato de transporte es que los desarrolladores no necesitan trabajar con varios tipos y formatos de archivos, ya que todos los documentos y bases de enlaces de apoyo están en XML. Además, cualquier validador XML puede validar la sintaxis del archivo, así como los tipos de datos básicos. Finalmente, XBRL que se basa en XML puede manejar mejor el contenido mixto (como la inclusión de datos en formato JSON o CSV o datos binarios), como se encuentra comúnmente en los informes comerciales y financieros.
La codificación predeterminada para XML es UTF-8, aunque algunos sistemas solo aceptan ASCII utilizando entidades de caracteres para caracteres especiales. Una recomendación para el mapeo XBRL-XML está disponible con el modelo de información abierta XBRL .
| 5.4.1.2 | XBRL en línea |
Inline XBRL (iXBRL) permite incrustar los datos de la instancia en un documento XHTML. Esta es la principal ventaja de iXBRL, que los datos legibles por máquina se encuentran dentro del informe legible por humanos. Otra ventaja es que cuando los usuarios editan el documento HTML, están editando los datos XBRL al mismo tiempo.
Los caracteres en XBRL en línea se pueden codificar como entidades de caracteres XML legales. Dependiendo de la plataforma utilizada, puede aceptar ASCII o UTF-8. La codificación predeterminada para XML y XHTML es UTF-8.
| 5.4.1.3 | JSON |
JSON, o JavaScript Object Notation , es un formato de texto que permite la expresión de datos estructurados complejos. Varios lenguajes de programación crearán y leerán JSON de forma nativa. Una ventaja de usar JSON para el documento de instancia es que muchos lenguajes de desarrollo web pueden analizar y escribir JSON de forma nativa, lo que lleva a un ciclo de desarrollo rápido de una página web habilitada para XBRL.
El texto dentro de los objetos JSON suele estar codificado en Unicode como UTF-8. Una recomendación para el mapeo XBRL-JSON está disponible con el modelo de información abierta XBRL .
| 5.4.1.4 | CSV |
CSV (valores separados por comas o delimitados por comas) es otra opción para el transporte. Una ventaja de usar CSV es que es muy fácil de analizar, leer en muchos lenguajes de computadora y paquetes de software, y es muy compacto. Sin embargo, debido a que CSV es una estructura plana, es más difícil representar muchas construcciones XBRL y, por lo tanto, es difícil de leer. CSV puede ser una buena opción para reportar información donde la estructura de datos es bastante constante y solo los valores de hechos cambian de un reporte a otro. Además, es posible que los preparadores ya estén familiarizados con CSV, ya que es común en el uso de hojas de cálculo.
Además de comenzar con un formato simple, CSV tiene la ventaja de tener muy poca sobrecarga de codificación cuando representa grandes volúmenes de datos.
El texto dentro de CSV no tiene una codificación de caracteres predeterminada para los datos XBRL, se asume como UTF-8 incluso sin el encabezado UTF-8.
Una recomendación para el mapeo XBRL-CSV está disponible con el modelo de información abierta XBRL .
Una pregunta de diseño fundamental para cualquier entorno de informes XBRL es si los usuarios pueden ampliar la taxonomía y en qué medida. La extensibilidad se ha discutido en la Sección 3.6, pero como revisión, los desarrolladores pueden optar por permitir a los usuarios extender un sistema de informes abierto agregando conceptos personalizados, tipos de datos, etiquetas, presentaciones, cálculos, notas al pie y taxonomías adicionales. Permitir la extensibilidad es una opción de diseño importante con numerosas implicaciones. Si bien permite a los preparadores representar sus datos quizás con mayor precisión a través de sus propias construcciones, puede reducir significativamente la comparabilidad entre los documentos de instancia XBRL.
Al decidir permitir la extensibilidad, los desarrolladores deben considerar primero las razones por las que el sistema de informes debe estar abierto. Las razones guiarán la determinación de los métodos a través de los cuales los preparadores pueden extender la taxonomía. Los desarrolladores también deben comprender lo siguiente al considerar un entorno de informes extensible:
| • | La taxonomía XBRL en sí no permite ni no permite la extensibilidad. Es el sistema de informes el que define qué taxonomías o conjuntos de taxonomías están permitidas. El software XBRL involucrado en la recepción y procesamiento de informes XBRL debe hacer cumplir las reglas de extensibilidad validando esos informes con la calidad de los datos y otras reglas y, si las construcciones de taxonomía extensible se utilizan incorrectamente, emitir errores. Tenga en cuenta que en un sistema de informes descentralizado, moderar la extensibilidad puede resultar muy difícil. |
| • | Si los desarrolladores optan por permitir la extensibilidad en su régimen de informes, debe estar bien documentado. Debe quedar claro para los preparadores cómo y en qué medida se les permite extender la taxonomía para satisfacer sus necesidades individuales de presentación de informes. |
| • | Para crear un proceso de generación de informes claro y coherente, cualquier software XBRL diseñado para guiar a los preparadores y consumidores en la interfaz con la taxonomía debe respetar las reglas de extensibilidad. Estas reglas deben cumplir con las reglas de validación utilizadas por el software de recepción de informes XBRL. |
| • | Cabe señalar que la extensibilidad no reemplaza la actualización y el mantenimiento de la taxonomía. Los desarrolladores deben examinar periódicamente si la taxonomía debe cambiarse para incluir conceptos personalizados de uso común o si la documentación poco clara está dando lugar a un uso excesivo de la extensibilidad. |
| • | Puede haber casos en los que la extensibilidad sea la solución óptima, y la taxonomía XBRL y el sistema de informes deben diseñarse para alentar a los preparadores a crear construcciones personalizadas según sea necesario. Por ejemplo, en la taxonomía US GAAP, ciertas dimensiones definidas por taxonomía explícita no tienen miembros predefinidos. Los nombres de los miembros para la dimensión OtherOwnershipInterestsByNameAxis variarán según la entidad informante y deben ser definidos por los preparadores de forma individualizada. En estas situaciones, el sistema de informes y la documentación deben ajustarse para expresar que este es el enfoque deseado. |
| • | Tenga en cuenta que la extensibilidad existe en equilibrio con la comparabilidad. Puede haber casos en los que la extensibilidad sea inevitable o incluso deseable, pero también puede haber una compensación significativa con la facilidad de comparación entre informes XBRL cuando la taxonomía es altamente extensible. Los conceptos personalizados presentes en un informe, por ejemplo, pueden no tener un análogo en un informe similar, lo que dificulta el análisis de los datos en un marco estructurado. Las siguientes secciones analizan algunos escenarios relacionados con las decisiones de extensibilidad y su impacto en la comparabilidad. | |
| 5.4.2.1 | Permitir notas a pie de página personalizadas |
Con este método, los preparadores pueden vincular el texto de su propia nota a pie de página con hechos utilizando la dimensión de identificación del núcleo de la nota. Agregar notas a pie de página de esta manera tiene muy poco impacto en la comparabilidad de los datos.
Impacto en la comparabilidad: bajo
Requiere: Ninguno
A los preparadores se les permitirá crear y usar etiquetas personalizadas para los conceptos ya incluidos en la taxonomía. Nuevamente, el impacto de esto en la comparabilidad es muy bajo porque esto solo cambia la documentación legible por humanos asociada con los conceptos.
Impacto en la comparabilidad: bajo
Requiere: Ninguno
| 5.4.2.3 | Permitir cálculos, definiciones y presentaciones |
En este caso, a los preparadores se les permite esencialmente reorganizar las relaciones de conceptos para adaptarse mejor a sus necesidades de presentación de informes. Estos conceptos ya existen en la taxonomía y la extensibilidad no los modifica; más bien, el cambio aparece en cómo los conceptos se relacionan entre sí. Debido a que los conceptos en sí mismos permanecen estables y las relaciones definidas por taxonomía permanecen disponibles, el impacto en la comparabilidad es bajo.
Impacto en la comparabilidad: bajo
Requiere: Ninguno
| 5.4.2.4 | Permitir dimensiones definidas por taxonomía personalizada |
Si la taxonomía hace uso de una dimensión con miembros explícitos, puede ser razonable permitir que los preparadores creen sus propios miembros para esta dimensión. Por ejemplo, si varias empresas necesitan informar su producción de widgets por tipo, permitirles crear sus propias dimensiones definidas por taxonomía para los tipos de widgets crea una mayor precisión en el informe.
Dependiendo de la dimensión explícita, la extensibilidad puede no ser necesaria en absoluto porque el conjunto de valores permitidos no cambia muy a menudo de un informador a otro. Por ejemplo, si todas las empresas de informes de una taxonomía están ubicadas dentro de los Estados Unidos, no hay razón para permitir la extensibilidad de una dimensión definida por taxonomía que represente una ubicación geográfica.
Impacto en la comparabilidad: medio
Requiere: etiquetas personalizadas, definiciones, presentaciones
| 5.4.2.5 | Permitir dimensiones básicas de conceptos personalizados |
Este tipo de extensibilidad permite a los preparadores crear sus propias dimensiones centrales del concepto, lo que requiere que los preparadores definan las propiedades y etiquetas de esos conceptos, así como la forma en que el concepto personalizado se relaciona con otros conceptos dentro de la taxonomía. Esto puede ser apropiado para una taxonomía muy abierta o en desarrollo, donde los desarrolladores pueden estar interesados o depender de los preparadores para agregar conceptos para desarrollar más completamente el entorno de informes o agregar profundidad a la taxonomía.
Impacto en la comparabilidad: alto
Requiere: etiquetas personalizadas, cálculos, definiciones, presentaciones
| 5.4.2.6 | Permitir tipos de datos personalizados |
Con este tipo de extensibilidad, los preparadores pueden crear sus propios tipos de datos que pueden ser necesarios para representar conceptos personalizados recién creados. Esto puede ser apropiado para una taxonomía muy abierta o en desarrollo, donde los desarrolladores pueden estar interesados o depender de los preparadores para agregar conceptos para desarrollar más completamente el entorno de informes o agregar profundidad a la taxonomía.
Tenga en cuenta que, debido a que las propiedades de los conceptos de otro esquema no se pueden cambiar, los preparadores no pueden vincular tipos de datos personalizados a conceptos preexistentes. Estos solo se pueden aplicar a conceptos personalizados. Por lo tanto, esto reduce el impacto en la comparabilidad a un nivel similar al uso de conceptos personalizados.
Impacto en la comparabilidad: alto
Requiere: Dimensiones del núcleo del concepto personalizado
| 5.4.2.7 | Agregar otras taxonomías |
Con el mayor impacto en la comparabilidad, se puede permitir que los preparadores incluyan otras taxonomías en sus informes. Esto abre otras taxonomías (sus conceptos, tipos de datos y relaciones de conceptos) para su uso dentro de un solo informe XBRL. Si bien esto otorga a los preparadores un gran poder, ya que incluyen taxonomías adicionales según lo consideren oportuno o necesario para expresar sus datos, también puede reducir drásticamente la comparabilidad. Los desarrolladores deberían permitir taxonomías extensibles con extrema precaución.
Si son necesarias otras taxonomías, los desarrolladores pueden incluirlas a título oficial o permitir que los preparadores incluyan conceptos muy estrictamente de estas taxonomías específicas. Este enfoque reduce en gran medida el impacto en la comparabilidad, ya que la inclusión de estas otras taxonomías se convierte en una parte estructurada de la propia taxonomía.
Impacto en la comparabilidad: alto
Requiere: cálculos personalizados, definiciones, presentaciones
Con el modelo de transporte definido, los desarrolladores pueden centrar su atención en los sistemas de soporte. Estos pueden incluir sistemas para ayudar a los preparadores a crear informes XBRL, sistemas para ver y almacenar datos XBRL y sistemas para extraer la información de uno o más informes para su análisis. Las necesidades de desarrollo de estos sistemas variarán enormemente según la taxonomía y la industria. Sin embargo, es importante ubicar la taxonomía en la cadena de suministro de información y determinar cómo llegarán los datos a cada etapa y cómo se utilizarán en esa etapa y en las etapas posteriores.
También vale la pena repetir que la participación de desarrolladores de software de terceros, si se va a permitir el software de terceros para la taxonomía, es esencial tanto durante el proceso de desarrollo de la taxonomía como posteriormente (consulte la Sección 4.6.3). Los sistemas de soporte robustos y bien diseñados son clave para la usabilidad de la taxonomía.
| 5.4.3.1 | API XBRL de EE. UU. |
XBRL US desarrolló la API XBRL (Application Program Interface) para ayudar a los usuarios y desarrolladores a crear sistemas de datos robustos basados en XBRL. Para los consumidores de datos, la API puede ayudar a acceder a datos XBRL estructurados y oportunos con alta resolución. Para los desarrolladores, la API estandarizada y las utilidades de datos proporcionan una única interfaz para recopilar datos de un repositorio / instancia XBRL. Los desarrolladores pueden usar la API para conectar una base de datos personalizada a una interfaz de software, lo que puede mejorar en gran medida la utilidad de un sistema de informes para los consumidores de datos y los reguladores.
Más información sobre la API XBRL está disponible en el sitio web de XBRL US y en la documentación de la API ( http://files.xbrl.us/documents/XBRL-API-V1.4.pdf ).
Los desarrolladores deben esforzarse por crear un modelo de datos que encapsule sus requisitos de informes y el conjunto mínimo de datos de la manera más completa y parsimoniosa posible. Sin embargo, puede que no sea posible prever todas las consideraciones y circunstancias antes de que se ponga en práctica un modelo de datos. Las siguientes secciones describen algunas de las complicaciones más comunes que pueden surgir y los posibles métodos para manejarlas.
| 5.5.1 | Divulgación específica de la entidad |
Como se mencionó anteriormente, puede haber situaciones en las que una entidad en particular tenga necesidades de presentación de informes que la taxonomía puede no abordar. Muy a menudo, estas son necesidades que simplemente no son anticipadas por los desarrolladores de taxonomía, particularmente cuando la taxonomía puede ser utilizada por muchos preparadores en múltiples industrias. La extensibilidad es una posible solución a este tipo de problemas. Sin embargo, los desarrolladores deben tener cuidado de permitir que la personalización se convierta en una muleta. Si los preparadores suelen crear una gran cantidad de componentes personalizados para expresar sus datos, los desarrolladores deben reevaluar qué tan bien la taxonomía (y su modelo de datos subyacente) se ajusta a los requisitos de informes. El conjunto mínimo de datos y los modelos lógicos y conceptuales resultantes pueden ser insuficientes. También es posible que la taxonomía sea demasiado general o, a la inversa, demasiado específica. Cuando una taxonomía es demasiado general, los preparadores pueden no darse cuenta de que los conceptos generales pueden aplicarse a sus datos particulares. Cuando una taxonomía es demasiado específica, los conceptos que son aplicables a algunos casos pueden no serlo para la mayoría de los casos o se puede poner demasiado énfasis en situaciones específicas de informes que no abordan ampliamente las necesidades de la mayoría de los preparadores. Todas estas son situaciones que pueden remediarse reexaminando el proceso de desarrollo. Una revisión pública exhaustiva y un ciclo de pruebas (consulte la Sección 9.1.2) pueden ayudar a los desarrolladores a identificar déficits como estos antes de que se implemente la taxonomía.
Los desarrolladores también deben ser conscientes de la posibilidad de que los preparadores estén ampliando una taxonomía porque la documentación sobre el uso de la taxonomía y la preparación de informes no es clara, completa o tal vez ni siquiera esté disponible. La falta de comprensión de cuándo es apropiado extender la taxonomía versus cuándo es mejor usar las construcciones taxonómicas existentes puede llevar a demasiada extensión y divulgaciones que son más específicas de la entidad de lo necesario.
Sin embargo, existen situaciones en las que la divulgación específica de la entidad puede ser inevitable o incluso un resultado deseado. Estos casos de informes pueden requerir modelos particulares y enfoques de análisis de casos de uso. XBRL International recomienda «anclar» las divulgaciones específicas de la entidad mediante el establecimiento de una relación con los elementos de la taxonomía base y el uso de una relación de cálculo siempre que sea aplicable y posible. Los miembros de XBRL International pueden obtener más información sobre la divulgación específica de la entidad y cómo manejarlos a través de artículos técnicos disponibles en el sitio web de XBRL International en la sección de Orientación , que incluyen «Cómo abordar las divulgaciones específicas de la entidad» , «Requisitos de los inversores y usuarios de datos para entidades específicas divulgaciones « , y«Análisis de casos de uso de ESD y ESD» . Para obtener información sobre cómo convertirse en miembro y obtener acceso a este tema y otros, envíe un correo electrónico a info@xbrl.us .
| 5.5.2 | Más de una entidad por informe |
Es posible que un solo informe deba incluir información perteneciente a más de la información de una entidad. Esto puede ocurrir cuando una empresa también debe reportar información sobre sus subsidiarias o firma de auditoría, por ejemplo. Tenga en cuenta que esta es una situación diferente a la de presentar información que se relaciona con una sola entidad, pero que puede abarcar datos sobre otras entidades, como una empresa que divulga información sobre sus clientes. En la primera situación, hay entidades separadas y cada una es una entidad que informa; cada uno debe reportar su propia información distinta pero relacionada en un reporte XBRL. En el segundo, una entidad que reporta está reportando su información sobre otras entidades en el contexto de su relación con ellas; las otras entidades no son entidades informantes.
Los desarrolladores deben tratar de anticipar la necesidad de reportar información de múltiples entidades dentro de un solo reporte tanto como sea posible. Hay varios enfoques de modelado que se pueden tomar:
| • | Conceptos específicos de la entidad, que pueden indicar la relación entre entidades en su nombre. Este es un enfoque más adecuado para situaciones en las que hay como máximo una entidad informante adicional (como una empresa y su contador que presentan un solo informe XBRL). Bajo este enfoque, se podrían crear conceptos como ParentIdentifier y AuditorIdentifier. Cuando hay más entidades involucradas, tener un método basado en conceptos para representarlas se vuelve demasiado complejo. |
| • | Dimensiones definidas por taxonomía específica de la entidad, que pueden indicar la relación entre entidades a través de la estructura dimensional. Estas dimensiones pueden ser escritas o explícitas dependiendo del número de entidades informantes adicionales anticipadas. Este enfoque es más adecuado cuando hay un número conocido pero limitado de entidades (como una empresa, su contador y su auditor). |
| • | Taxonomías de extensión adicionales. Cuando el número de conceptos y dimensiones necesarios para cubrir la amplitud de la información es muy grande, una taxonomía de extensión puede ser un buen método de organización. Esto separa las estructuras de taxonomía necesarias para la presentación de informes de múltiples entidades y permite a los preparadores la opción de usar la taxonomía si corresponde. Este enfoque se adapta bien a situaciones en las que puede haber muchas o un número desconocido de entidades adicionales (como una empresa y sus subsidiarias). |
Para obtener más información y orientación sobre este tema, los miembros de XBRL International pueden acceder a «Cómo modelar información relacionada con múltiples entidades» . Para obtener información sobre cómo convertirse en miembro y obtener acceso a este tema y otros, envíe un correo electrónico a info@xbrl.us.
| 5.5.3 | Hechos dimensionalmente inválidos |
Los hechos dimensionalmente inválidos ocurren con mayor frecuencia cuando un preparador intenta usar un miembro de dimensión explícito en un eje donde no debería ocurrir. Esto también se conoce como usar el miembro fuera de su hipercubo. Cuando un sistema de informes no permite la extensibilidad, los hechos dimensionalmente inválidos no pueden ocurrir; la estructura de la taxonomía la establece el sistema de informes y sus hipercubos están cerrados. Los preparadores no pueden crear sus propios miembros ni utilizar miembros fuera de sus hipercubos.
Cuando un sistema de informes permite conceptos extensibles y dimensiones definidas por taxonomía, es posible que los preparadores puedan crear sus propios ejes dimensionales o utilizar otros miembros del eje en dimensiones definidas por taxonomía más allá de las presentaciones predeterminadas incluidas en la taxonomía. Por ejemplo, una dimensión definida por taxonomía explícita llamada GeographicLocation puede contener el miembro New York. Un preparador puede querer utilizar este miembro en su dimensión City definida por taxonomía. Los hipercubos predefinidos de la taxonomía pueden no permitir o prohibir explícitamente este uso cuando la extensibilidad está permitida y dicho uso puede ser correcto o no, dado el significado previsto por los desarrolladores para ese miembro como ciudad o estado.
En estos casos, es de vital importancia que los desarrolladores de taxonomía proporcionen documentación clara para guiar a los preparadores sobre cómo y dónde se pueden usar los miembros dimensionales. Además, las pautas de extensibilidad deben indicarse claramente para evitar que ocurran hechos dimensionalmente inválidos y reducir la precisión y comparabilidad de los datos. La calidad de los datos y otras reglas de validación también serían beneficiosas para guiar a los preparadores en la creación de informes dimensionalmente válidos.
La especificación XBRL tiene mecanismos que pueden ayudar a los desarrolladores de taxonomía a prohibir a los preparadores reportar información que no está permitida. Pueden ocurrir situaciones en las que el desarrollador de taxonomía desee evitar que los preparadores informen sobre ciertos hechos que no están permitidos para ciertas combinaciones de miembros dentro de una dimensión. Por ejemplo, una empresa puede vender los productos A, B y C a los países 1 y 2, pero solo vender los productos A y C al país 3. La creación de un único hipercubo para representar estos datos podría provocar que los preparadores informaran incorrectamente un hecho para las ventas del producto. B al país 3, que no está permitido. Los desarrolladores de taxonomías tienen varias opciones para garantizar que los preparadores informen de manera adecuada utilizando la taxonomía. Se puede emplear una combinación de hipercubos de inclusión y exclusión para especificar qué está permitido y qué no. Alternativamente, se pueden incorporar reglas de validación para producir un mensaje de error si se usa una combinación incorrecta de miembros.