Artículos

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 2

6          Validación

La validación de datos se ha discutido a lo largo de este manual. Asegurar datos sólidos y precisos es un aspecto vital del desarrollo de la taxonomía, y en esta etapa del proceso de desarrollo, los desarrolladores deben sentar las bases para las reglas y pautas de validación. Las siguientes secciones describen algunos temas que los desarrolladores deberían explorar. También debe tenerse en cuenta que, si las reglas de validación se vuelven lo suficientemente grandes o complejas, la creación de un comité de calidad de datos puede resultar apropiada. En los Capítulos 8 y 9 se analiza más sobre cómo formar un comité de este tipo, documentar las reglas de validación de datos y mantener la gobernanza de la calidad de los datos.

Aunque es un tema complejo, la validación tiende a considerarse desde dos perspectivas: la de los preparadores que están interesados ​​en crear informes XBRL precisos y completos y la de los consumidores y agregadores de datos que desean tener confianza en la integridad de los datos que están consumiendo. Existen muchas herramientas y métodos para ayudar a estos grupos a lograr sus objetivos de calidad de datos, y algunos son aplicables a múltiples situaciones. Este capítulo intenta destacar las herramientas y enfoques de validación que se adaptan a las necesidades de los preparadores o consumidores y cómo los desarrolladores de taxonomía pueden hacer uso de estas herramientas para mejorar la información proporcionada por la taxonomía.

6.1         Validación Básica

Las siguientes secciones describen las facetas de XBRL en sí que pueden ayudar en la validación. Estas son características nativas del formato; los desarrolladores no necesitan agregar nada a una taxonomía para hacer uso de estos métodos de validación, y pueden beneficiar tanto a los preparadores como a los consumidores. Cabe mencionar nuevamente que XBRL no verifica de forma nativa su propia sintaxis o integridad de datos. Se requieren soluciones de software para proporcionar a los preparadores y otros usuarios herramientas de validación, que deben hacer uso de la estructura y las relaciones de XBRL.

6.1.1     Validación de sintaxis

Independientemente del método de transporte, existe cierta validación sintáctica inherente a la estructura de los datos. CSV proporciona la validación menos sólida, mientras que XBRL en JSON y XML puede ser analizado por la mayoría de las aplicaciones que analizan JSON y XML básicos. Como se indica en la Sección 5.4.1, esta es una ventaja de estos formatos, particularmente XBRL como XML.

El software de preparación, así como los sistemas de informes, pueden utilizar la validación de sintaxis para ayudar a los preparadores en particular. Como primer paso en la presentación a un sistema de informes, ese sistema puede verificar la sintaxis para asegurarse de que el documento XBRL tenga el formato adecuado. Para Inline XBRL, esto también puede incluir inspeccionar la sintaxis de las partes HTML del documento. Los informes con sintaxis incorrecta pueden rechazarse del sistema de informes como primera defensa contra la información incorrecta que llega a los consumidores.

6.1.2     Validación del tipo de datos

Nuevamente, la validación del tipo de datos, o asegurarse de que el tipo de datos del valor coincida con el tipo de datos de su dimensión central del concepto, es inherente a XBRL como XML. Este tipo de validación ayuda a garantizar que se represente el tipo correcto de datos de hechos en el informe. Los datos textuales no deben aparecer en un hecho numérico, por ejemplo. Cualquier analizador XML podrá validar estas relaciones, incluso para tipos de datos personalizados.

6.1.3     Validación basada en relaciones de conceptos

La naturaleza de XBRL ofrece validación a través de sus relaciones conceptuales. Estos incluyen, pero no se limitan a, relaciones definidas por bases de enlaces de cálculo, definición y presentación. Los arcos de relación que conectan conceptos pueden ayudar a los desarrolladores (y preparadores) a garantizar que tanto la lógica semántica de la relación como los conceptos involucrados se utilicen correctamente. Es posible que una aplicación de software XML básica no pueda verificar la coherencia de las relaciones, pero el software XBRL, como Arelle (que está disponible de forma gratuita), puede ayudar a los desarrolladores a trazar relaciones conceptuales para garantizar que no existan relaciones ilógicas o circulares.

Cualquier solución de software diseñada para una taxonomía debe hacer uso de al menos una validación basada en relaciones de conceptos básicos. Por ejemplo, un cálculo de una suma total a partir de sus valores constituyentes debe ser matemáticamente correcto (el valor de hecho para el total debe ser la suma de los demás hechos en el arco de cálculo). La implementación de este tipo de validación ayudará a los preparadores a evitar errores. Como otro ejemplo, si un El hipercubo está cerrado, el software puede alertar a los preparadores si falta una dimensión requerida en un hecho que pertenece al hipercubo.

6.2         Requisitos normativos e industriales

Los requisitos reglamentarios y / o los estándares de la industria, como las reglas comerciales específicas, se pueden aplicar a través de la validación personalizada creada para la taxonomía. Estos variarán de una situación a otra. La creación e incorporación de reglas comerciales automatizadas puede mejorar la calidad, precisión y coherencia de los datos producidos en los informes XBRL. Las reglas de validación deben estar bien documentadas y disponibles para los usuarios a lo largo de la cadena de suministro de información (consulte el Capítulo 8). Se debe alentar a los preparadores a que los utilicen para validar sus informes. Se pueden incorporar muchas reglas de validación en aplicaciones de software para que los preparadores puedan verificar el informe XBRL automáticamente para identificar errores.

Hay muchas formas de introducir la validación en el software XBRL, la mayoría de las cuales están fuera del alcance de este manual. Sin embargo, existen herramientas estandarizadas para ayudar a los desarrolladores a establecer requisitos específicos de la industria: fórmulas XBRL y XULE.

6.2.1      fórmulas XBRL

Las fórmulas XBRL proporcionan un método estandarizado para definir reglas de validación para informes XBRL que van más allá de lo que se proporciona a través de cálculos y otras relaciones de conceptos. Mediante fórmulas, las reglas de validación se pueden incrustar en la propia taxonomía. Esto permite que la taxonomía se difunda fácilmente con sus reglas de validación, lo que reduce la posibilidad de que los preparadores las malinterpreten o tengan dificultades para localizarlas. Las reglas de fórmula XBRL se colocan en su propia base de enlaces, a menudo denominada base de enlaces de aserción o fórmula. El software XBRL capaz de leer e interpretar esta base de enlaces puede aplicar las reglas y mostrar los resultados a los preparadores.

Las fórmulas XBRL pueden variar mucho y ser complejas. Para obtener más información, los lectores pueden consultar la Especificación de la fórmula XBRL . Los miembros de XBRL International también pueden acceder a sus artículos sobre fórmulas XBRL, incluido el «Tutorial de reglas de fórmulas XBRL» . Este manual proporcionará una breve introducción a qué son las fórmulas XBRL, cómo funcionan y cómo pueden mejorar la validación de informes XBRL. Tenga en cuenta que esta sección y los siguientes ejemplos muestran fórmulas escritas en el formato de fórmula XBRL basada en texto XF. Tradicionalmente, las fórmulas XBRL se expresan mediante XLink, pero el enfoque basado en texto XF es más fácil de leer e implementar. Para obtener más información sobre el formato XF, consulte la Especificación de la gramática para la fórmula XBRL basada en texto (XF) 1.0 .

6.2.1.1   Formato de regla

Una regla de fórmula XBRL generalmente tiene tres componentes: un nombre de regla, la expresión de prueba y variables. El nombre de la regla es un identificador de la regla que se puede usar para hacer referencia a la regla (por ejemplo, cuando el software XBRL muestra errores al usuario después de validar un informe XBRL). La expresión de prueba contiene la declaración lógica que se evalúa para determinar el resultado de la regla. Las variables sirven como entrada para la expresión de prueba. Una regla de fórmula XBRL puede contener otros componentes, como parámetros y condiciones previas.

6.2.1.2   La expresión de prueba: ejemplos comunes

La faceta central de la regla de la fórmula XBRL es su expresión de prueba. Nuevamente, esta expresión puede ser muy compleja con múltiples variables y otros componentes que afectan su evaluación. Para este ejemplo simple, suponga que los desarrolladores deseaban incluir una afirmación de que los conceptos WidgetSales menos WidgetExpenses equivalen al concepto Ingresos (consulte la Sección 5.3.3). Esto podría lograrse mediante un cálculo, pero el cálculo solo establece la relación entre los conceptos. No obliga a que los valores sumen correctamente.

Las fórmulas XBRL pueden probar muchos aspectos de los datos. El ejemplo 6-1 muestra una fórmula de ejemplo que evalúa una relación matemática.

Ejemplo 6-1. Una aserción de fórmula XBRL para validar matemáticamente los ingresos como una función de WidgetSales y WidgetExpenses

El ejemplo primero define el nombre de la regla con la declaración de aserción. Luego declara variables con la declaración de variable. En este caso, los valores del concepto WidgetSales (indicado por el espacio de nombres del widget; consulte el Capítulo 7 para obtener detalles sobre los espacios de nombres), el concepto WidgetExpenses y el concepto Revenue se declaran como variables $ ventas, $ gastos e $ ingresos, respectivamente. La declaración de prueba luego define la prueba lógica: los ingresos deben ser iguales a las ventas menos los gastos. La declaración se evalúa como un resultado booleano: la expresión es verdadera (satisfecho) o falso (insatisfecho). El software XBRL puede implementar esta afirmación, interpretar su resultado e informar esa información al usuario.

Las fórmulas también pueden asegurar la presencia de hechos particulares. Suponga que los ingresos son un hecho obligatorio. Considere el ejemplo 6-2:

Ejemplo 6-2. Una aserción de fórmula XBRL para un valor de hecho requerido (Ingresos)

En este caso, la afirmación se titula «RequiredRevenue». Nuevamente declara la variable $ ingresos usando el concepto de Ingresos de la taxonomía de widgets. A diferencia del ejemplo 6-1, se utiliza una declaración de prueba especializada: recuento de evaluación. Esto dará como resultado una expresión verdadera si el hecho está presente en el informe XBRL y falso si no lo está. La expresión es una abreviatura de lo siguiente: recuento-evaluación {. gt 0}. El «.» refleja el número de veces que se encuentra la variable. Debe ser mayor que cero para dar como resultado una afirmación verdadera. Esta sintaxis también podría cambiarse a: Evaluation-Count {. eq 1}. En este caso, prueba para asegurarse de que el hecho aparezca exactamente una vez en el informe XBRL.

Las fórmulas XBRL también pueden realizar comprobaciones de precisión en miembros dimensionales. Vuelva a tomar la taxonomía de widgets como se muestra en la Figura 5-3. Suponga que la taxonomía tiene una regla de validación que garantiza que las ventas totales de todos los tipos de widgets sean iguales a la suma de las ventas de todas las facturas.

Ejemplo 6-3. Una aserción de fórmula XBRL para comparar valores sumados (WidgetSaleIncome)
en una dimensión escrita (InvoiceAxis) con un valor total (WidgetSales)

En esta afirmación, la variable $ sales representa el hecho WidgetSales. Luego se declara una variable llamada $ invsales. Esto se puede considerar como un vector de valores de hechos (todas las ventas individuales). El concepto se especifica (WidgetSaleIncome) seguido de la instrucción bind-as-sequence . Esto dirige todos los valores de hechos a lo largo de la dimensión con tipo InvoiceAxis que tienen el nombre de concepto WidgetSaleIncome para que se coloquen en la variable $ components. La declaración de prueba luego compara la variable $ sales con la suma de la lista de valores de hechos almacenados en la variable $ invsales.

Tenga en cuenta que esta afirmación verifica todas las ventas de todos los tipos de widgets. Si hubo un error en las ventas informadas para un tipo de widget que se compensa con un error para otro tipo de widget, esta regla de validación no lo informará. Esto podría explicarse agregando reglas adicionales para cada tipo de widget, lo que se lograría agregando una dimensión explícita y su miembro a la prueba de aserción. Sin embargo, debido a la extensibilidad, es posible que no se verifiquen los tipos de widgets personalizados.

El ejemplo 6-3 también contiene la declaración mensaje-insatisfecho, que puede declarar una descripción útil del error para aquellos que usan las reglas de la fórmula. El mensaje insatisfecho se puede dar en varios idiomas. En este caso, es inglés (en).

Estos ejemplos representan solo algunas de las posibilidades de usar fórmulas XBRL para mejorar la calidad de los datos. Las fórmulas también pueden verificar la lógica de las fechas, la precisión de los hechos que abarcan múltiples dimensiones de período, situaciones en las que algunos hechos son opcionales o no están disponibles y otras operaciones matemáticas. Además, los desarrolladores pueden establecer la gravedad de las reglas para diferenciar entre advertencias y errores menos graves.

6.2.2     XULE

Desarrollado por XBRL US, XULE es una sintaxis de expresión que permite la consulta de informes y taxonomías XBRL utilizando un procesador XULE. El propósito principal de XULE es proporcionar una sintaxis fácil de usar para consultar y manipular datos XBRL. Esto puede ser útil de muchas maneras, incluida la ayuda a los consumidores a extraer rápidamente hechos específicos de los informes y el apoyo a los desarrolladores para consultar taxonomías XBRL para representarlas como esquemas API abiertos o como formularios iXBRL.

XULE es especialmente adecuado para la validación. Permite la extracción precisa y fácil de hechos particulares de un informe, verificando que existan según sea necesario y verificando potencialmente las relaciones matemáticas entre ellos. Por ejemplo, XULE se ha utilizado para validar las presentaciones de la SEC junto con las reglas desarrolladas por el Comité de Calidad de Datos de EE. UU. (DQC) de XBRL (para conocer las reglas de validación DQC aprobadas, visite https://xbrl.us/data-quality/rules-guidance / ).

6.2.2.1   Descripción general

XULE es independiente de la sintaxis y funcionará en informes XBRL publicados en formatos JSON, iXBRL, CSV y XML. El lenguaje opera en un modelo de datos XBRL e ignora la sintaxis XBRL particular, lo que facilita su aplicación a múltiples estándares de informes. Sin embargo, puede haber inconvenientes dependientes de la sintaxis, como la incapacidad de XULE para consultar todos los contextos XML en un informe XBRL en formato XML. Un contexto XML es una estructura inherente solo a XBRL basado en XML en lugar del propio modelo de datos XBRL y, por lo tanto, es inaccesible en XULE.

Los usuarios pueden acceder a XULE de varias formas. Se puede utilizar como un complemento en Arelle, el visor y editor de informes XBRL de taxonomía de código abierto y XBRL (para obtener más información sobre Arelle, consulte el Capítulo 7). En Arelle, un usuario debe proporcionar un archivo de texto con información particular: el archivo que contiene la lista de comandos XULE, el archivo XBRL en el que se deben ejecutar los comandos XULE y un archivo de registro resultante. Otras aplicaciones, como XML Spy, permiten al usuario interactuar con XULE directamente en el programa. En cualquier caso, el usuario puede proporcionar los comandos XULE y luego el procesador XULE los procesa. Al igual que un sistema de base de datos, los resultados de las consultas se informan al usuario.

XULE tiene dos componentes distintos para acceder a los datos XBRL: selección de conjuntos de hechos y navegación por taxonomía.

6.2.2.1.1              Conjunto de hechos

Un conjunto de hechos XULE contiene los hechos solicitados con su precisión decimal asociada, información de unidad, periodicidad y otra dimensionalidad central. Con esta información, se pueden consultar las propiedades de un hecho específico en un conjunto de hechos. Los conjuntos de hechos también contienen otra dimensionalidad relevante para los hechos, como otras dimensiones definidas por taxonomía que se cruzan. El filtrado de conjuntos de hechos (también llamado búsqueda de conjuntos de hechos) es la acción de extraer datos de un informe XBRL en función de las dimensiones del hecho.

El conjunto de hechos no contiene información sobre el conjunto de taxonomía detectable (DTS) asociado con el informe XBRL. Por ejemplo, un usuario no puede determinar los cálculos en los que participa algún hecho a partir del conjunto de hechos. Debería accederse a esta información a través de la DTS.

XULE permite al usuario poner estos valores en un conjunto, lista o diccionario y manipular los datos filtrados. Debido a que todos los datos se almacenan en conjuntos, la manipulación matemática básica del conjunto se puede realizar en los datos, como derivar una unión, intersección o complemento con otro conjunto. Una regla XULE puede buscar un conjunto de hechos no solo a través de las dimensiones definidas por la taxonomía de un hecho, sino también a través de las propiedades de su concepto central. Por ejemplo, un usuario puede devolver todos los hechos asociados con un concepto monetario particular en un informe XBRL, como todos los valores de hechos que reflejan un saldo deudor. XULE también permite la evaluación de expresiones entre conjuntos de hechos, como restar Activos Actuales de un hecho Activos para derivar Activos No Activos. Esto puede resultar particularmente útil en la validación.

6.2.2.1.2              Navegación de taxonomía

XULE permite la navegación de redes XBRL en muchas taxonomías. Esto significa que XULE puede comparar relaciones entre taxonomías combinando la navegación de taxonomías con características de manipulación de conjuntos. Por ejemplo, una regla puede comparar la estructura de la taxonomía de extensión de la empresa con la taxonomía US GAAP. Los conjuntos de relaciones de taxonomía resultantes se pueden combinar con un conjunto de hechos para determinar dónde se han utilizado los valores. Nuevamente, esto puede resultar útil en la validación.

6.2.2.2   Ejemplos de filtrado de conjuntos de datos

Como se dijo anteriormente, los datos derivados de un informe XBRL a través de XULE se pueden filtrar de muchas formas diferentes. El siguiente ejemplo muestra un filtrado básico que devuelve todos los datos dentro de un informe XBRL.

Ejemplo 6-4. Devolver un conjunto de hechos de XULE

La notación de corchetes en el ejemplo 6-4 se usa para definir explícitamente un conjunto de hechos. El símbolo «@» indica una dimensión. Los corchetes son opcionales y el símbolo @ puede sostenerse por sí mismo. Los tres métodos del ejemplo 6-4 devuelven todos los valores de hechos en un informe XBRL en un solo conjunto de hechos XULE.

También se puede acceder a hechos adimensionales en XULE. Para devolver un conjunto de hechos que no tiene información dimensional, se usa la notación entre corchetes (Ejemplo 6-5).

El comando XULE del ejemplo 6-8 devolvería todos los hechos con una dimensión central de período instantáneo de esa fecha. La sintaxis «date ()» solicita una conversión de tipos específica, que indica al procesador XULE que trate la siguiente fecha como un tipo de datos de fecha. También se puede solicitar una duración en el filtro utilizando la sintaxis indicada en la segunda línea. Los usuarios también pueden combinar filtros de propiedad con filtros dimensionales de período. Al especificar «@ period.start» y «@ period.end», se puede definir la duración de un período.

Los filtros de conjunto de hechos también se pueden combinar en una sola expresión XULE. Los filtros se analizan mediante el carácter «@».

Ejemplo 6-9. Varios filtros XULE combinados en una sola expresión

En el Ejemplo 6-9, se devuelven los hechos asociados con el concepto activos para cualquier entrada en el LegalEntityAxis con un período instantáneo específico y una unidad específica. En primer lugar, tenga en cuenta el uso de espacios de nombres para identificar elementos XBRL. En segundo lugar, en este ejemplo se emplea el símbolo comodín («*») para devolver todos los hechos con un valor a lo largo de esta dimensión. Tenga en cuenta que los filtros XULE se combinan lógicamente en una operación AND, en lugar de un OR. Por lo tanto, mientras que las expresiones pueden ser sintácticamente correctas, lógicamente pueden devolver un conjunto vacío. Por ejemplo, {@concept = Activos @concept = Pasivos} producirá un conjunto vacío, ya que ningún hecho en un informe XBRL puede tener dos dimensiones centrales comunes.

Esta sección estaba destinada a proporcionar una breve descripción general del filtrado de conjuntos de hechos con XULE. Hay muchos enfoques para buscar y filtrar en propiedades dimensionales. XULE admite sintaxis adicional que no se discute aquí, como las cláusulas where y la capacidad de filtrar los hechos mismos a través del operador «$». Para obtener más información sobre estos temas, vea Sintaxis del lenguaje XULE para XBRL.

6.2.2.3   Taxonomía Navegación

En XULE, la navegación es un método para atravesar las relaciones en una taxonomía. Una navegación devuelve un conjunto. Sin embargo, a diferencia de los conjuntos de hechos, la navegación produce conjuntos de conceptos a partir de la taxonomía misma. Dado que las relaciones conceptuales aplican un significado contextual importante a los hechos y otros conceptos, hay muchos casos en los que conocer la estructura de la relación puede ayudar en la validación del informe. Por ejemplo, si un informe XBRL utiliza conceptos de extensión en un balance, la navegación XULE puede ayudar a los usuarios a clasificar esos conceptos en función de sus relaciones, lo que a su vez puede ayudar a verificar la exactitud de los hechos asociados con ellos.

Los elementos de un conjunto devueltos por un conjunto de expresiones de navegación están determinados por lo que se proporciona en la expresión. En su forma más simple, una expresión de navegación requiere una dirección. Por ejemplo, la expresión del ejemplo 6-10 devolverá todos los conceptos descendientes en todas las construcciones de la taxonomía a la que hace referencia el informe XBRL.

Ejemplo 6-10. Navegación de taxonomía XULE simple

Para limitar los resultados a un tipo de relación específico, los usuarios pueden especificar el tipo de relación después de la palabra clave navigate. Esto puede ser una combinación de la dirección y un arco. El arco, como se explicó anteriormente en este manual, describe la relación en sí. La dirección guía a XULE en el recorrido de ese arco y devuelve los hechos asociados con la dirección.

Ejemplo 6-11. Navegación de taxonomía XULE utilizando un arco y una dirección

Con el filtrado de conjuntos de datos y la navegación por taxonomía, los usuarios pueden escribir consultas XULE complejas para validar informes XBRL. Para obtener más información sobre XULE, consulte el sitio web de XBRL US en https://xbrl.us/xbrl-reference/xule-syntax/.

6.2.3 Español Comités de Calidad de Datos

Este manual ha abordado el concepto de comités de calidad de datos en secciones anteriores. Aquí el propósito de la comisión está más desarrollado. Un comité de calidad de datos crea, mantiene y actualiza las reglas de calidad de datos para un entorno de informes. Estas reglas pueden ser simples, como indicar formalmente qué hechos se requieren en un informe XBRL, o pueden ser muy complicadas y extensas, como definir relaciones matemáticas mucho más allá de los simples cálculos o indicar situaciones particulares en las que el uso de ciertos conceptos o dimensiones definidas por la taxonomía es incorrecto. Tenga en cuenta, de nuevo, que estas reglas no son nativas de XBRL y XBRL en sí no tiene ningún método para aplicar ningún enfoque de validación. Más bien, corresponde al software de preparación de XBRL y al sistema de informes implementar adecuadamente estas reglas para evitar que se informen datos incorrectos e inexactos. Las fórmulas XBRL y XULE presentan dos métodos para implementar reglas de calidad de datos en una situación de informes.

Las reglas de calidad de datos pueden ser impulsadas en gran medida por la propia industria y los casos de uso y requisitos de la taxonomía. En una situación de informes pequeña o bastante simple, un comité de calidad de datos puede ser extraño o pequeño con un conjunto limitado de reglas. En una gran situación de informes con muchos preparadores o complejidades, el comité puede estar compuesto por múltiples expertos de la industria y arquitectos de datos. Es vital que los desarrolladores de taxonomía planifiquen la validación y la posible necesidad de reglas de calidad de datos.

Como ejemplo de un conjunto de reglas de un comité de calidad de datos y su implementación, los lectores pueden explorar los desarrollados por XBRL US para la Junta de Normas de Contabilidad Financiera (FASB). El FASB comenzó a incorporar reglas de calidad de datos en la Taxonomía de Informes Financieros US GAAP, a partir de la publicación de 2020. El proceso de desarrollo de reglas se puede ver en este gráfico: https://xbrl.us/data-quality/rules-guidance/rules-process/.

7             La mecánica del desarrollo de la taxonomía

Con el modelo de transporte ahora claramente definido, el enfoque se centra en el proceso de construcción de la taxonomía XBRL. Este capítulo describe este proceso a través de las herramientas gratuitas disponibles para los desarrolladores. También proporciona sugerencias para ayudar en el proceso de desarrollo físico de la taxonomía. Aunque este capítulo investiga la mecánica del desarrollo de taxonomía a través del software disponible sin compra, se alienta a los desarrolladores a explorar también las diversas herramientas comerciales que se pueden usar para crear, ver y validar una taxonomía XBRL. Las herramientas comerciales proporcionadas por los miembros de XBRL US y XBRL International se pueden encontrar en estos sitios: XBRL US Member Tools & Services y XBRL International Tools & Services. Incluso si los desarrolladores optan por utilizar herramientas comerciales u otros enfoques de software no descritos aquí, leer este capítulo puede ser útil, ya que proporcionará información sobre la metodología para generar una taxonomía.

7.1         Flujo de trabajo

Antes de comenzar a trabajar en taxonomía, los desarrolladores deben diseñar el flujo de trabajo (consulte la Figura 7-1 para ver un ejemplo). La creación de una taxonomía XBRL a menudo requiere que varias personas y organizaciones trabajen juntas en un único espacio de trabajo colaborativo, y cada una de estas partes puede realizar diferentes tareas y requerir diferentes niveles de acceso. Por ejemplo, algunos individuos o un grupo pueden tener la tarea de transformar el modelo de datos lógicos en una taxonomía beta. Otro puede supervisar la incorporación de cambios regulatorios / de gobernanza, tanto para la taxonomía inicial como a medida que ocurren cambios futuros. Un tercer grupo puede encargarse de leer los comentarios de los revisores y hacer recomendaciones para las modificaciones. Cada uno de estos grupos puede requerir diferentes niveles de acceso a la taxonomía en sí. Los responsables de agregar y revisar el contenido deben tener acceso de edición; a los que revisan el contenido solo se les puede dar acceso a la vista y al comentario para protegerse contra la corrupción inadvertida de los archivos de creación. Todos los miembros del grupo de trabajo deberían poder examinar la labor en curso.

Además, los desarrolladores de taxonomía pueden desear emplear software de control de versiones para realizar un seguimiento de los cambios en la taxonomía en su conjunto. Esto es particularmente importante si la taxonomía es grande o tiene muchos individuos o grupos que contribuyen a ella.

7.2         Preparación y generación de la taxonomía

En las secciones siguientes se describen los pasos para generar una taxonomía utilizando software disponible gratuitamente. Una vez más, los desarrolladores pueden optar por utilizar otras soluciones, aunque estos pasos generales se mantendrán constantes sin importar qué paquetes de software se empleen. Además, vale la pena mencionar que los archivos de esquema XBRL y linkbase son simplemente archivos de texto (ASCII), por lo que se pueden crear y editar en cualquier editor de texto o XML. Con un conocimiento suficiente de XML, uno puede crear estos documentos sin ayuda externa de una hoja de cálculo o aplicación de administración XBRL.

7.2.1 Introducción al desarrollo con Arelle

Arelle2,que se discutió brevemente en la Sección 1.4.3, es una solución de desarrollo y administración XBRL disponible gratuitamente. Arelle es de código abierto y tiene herramientas para ayudar a los desarrolladores a organizar, visualizar y crear esquemas de taxonomía y archivos de base de enlaces. Arelle también puede ayudar a los preparadores con la validación y visualización de informes XBRL.

En términos de desarrollo, Arelle ofrece un complemento que permite a los desarrolladores diseñar su taxonomía utilizando una hoja de cálculo XML de Open Office. Muchas aplicaciones de hojas de cálculo, incluidas Microsoft Excel y Google Sheets, admiten de forma nativa este formato. Además de facilitar la organización de la taxonomía, el uso de una hoja de cálculo también admite la colaboración, ya que muchas de estas plataformas de software tienen características de colaboración integradas en ellas. Arelle también permite exportar cualquier taxonomía a una hoja de cálculo, lo que brinda a los desarrolladores la oportunidad de ver cómo se ve una taxonomía completa en formato de hoja de cálculo. Los desarrolladores también pueden eliminar los conceptos y las relaciones, pero dejar la estructura general de la hoja de cálculo para crear su propia plantilla. Esta guía guiará a través del desarrollo de la taxonomía de widgets utilizando un formato de hoja de cálculo. Esta taxonomía se puede descargar de XBRL US aquí: https://files.xbrl.us/documents/TDH-Ch5-Widget-Taxonomy.xlsx. Los desarrolladores pueden modificar esta taxonomía para crear la suya propia siguiendo los pasos que se describen a continuación. Además, los desarrolladores pueden usar esta plantilla en Arelle para generar archivos de esquema y linkbase para examinar y cambiar como deseen.

El uso de Arelle puede hacer que el desarrollo de taxonomía sea más fácil y fácil de usar. Sin embargo, este enfoque no elimina la necesidad de tener un conocimiento práctico de XML para solucionar problemas que puedan surgir. Además, la plantilla descrita en este capítulo es simple y está destinada a demostrar los conceptos básicos del uso de hojas de cálculo para crear taxonomías. La taxonomía de widgets de ejemplo también es intencionalmente simple. Estos ejemplos deberían proporcionar una base sobre la cual los desarrolladores puedan aprender a construir taxonomías mucho más extensas con estructuras complejas y robustas. Se alienta a los desarrolladores a estudiar otras taxonomías para fomentar una comprensión más rica de cómo las hojas de cálculo pueden ayudar a organizar y visualizar los componentes de la taxonomía.

7.2.2      Uso de etiquetas

Antes de comenzar a construir la taxonomía en arelle, los desarrolladores deben considerar determinar completamente las etiquetas para los conceptos de taxonomía. Esto incluye no solo determinar qué etiquetas son necesarias, sino también cuál debe ser su contenido. Las etiquetas son cruciales para la legibilidad e interpretabilidad humana. Los conceptos pueden tener cualquier número de etiquetas según sea necesario. Algunas etiquetas, como una etiqueta estándar o una etiqueta concisa, deben incluirse con cada concepto. Otros son aplicables solo en situaciones particulares. Para obtener más información sobre las etiquetas, consulte las etiquetas genéricas y las especificaciones de etiquetas preferidas genéricas. Para los miembros de XBRL International interesados en usar etiquetas multilingües, «Etiquetas multilingües en una taxonomía» proporciona más orientación.

Los desarrolladores deben intentar utilizar las etiquetas más apropiadas disponibles para sus conceptos. En general, es una buena práctica comenzar con el papel de etiqueta estándar. Muy a menudo esto puede ser insuficiente y se necesitan roles de etiqueta adicionales. A continuación, los desarrolladores pueden consultar el Registro de roles de enlace de XBRL International para obtener un rol de etiqueta que satisfaga sus necesidades. Este registro contiene roles de etiqueta desarrollados y utilizados en otras taxonomías. También se pueden crear nuevos roles de etiqueta según sea necesario, aunque la selección de un rol de etiqueta previamente desarrollado puede aumentar la comparabilidad entre las taxonomías.

7.2.2.2   Etiquetas que afectan la presentación de los hechos

Estas etiquetas pueden afectar la forma en que aparece el hecho asociado de un concepto:

Etiqueta de inicio de período: una etiqueta para indicar un concepto representa el inicio de un valor de período.

Etiqueta de fin de período: una etiqueta para indicar un concepto representa el final de un valor de período.

Etiqueta total – Una etiqueta para indicar un concepto representa una suma de un conjunto de valores de hecho asociados con otros conceptos. Esto se ve comúnmente con los cálculos. Por ejemplo, en una serie de cálculos, el mismo concepto puede representar un total en un cálculo mientras que es un apéndice en un segundo cálculo. Esta etiqueta puede diferenciar las situaciones y agregar contexto semántico.

Etiqueta neta – Una etiqueta para indicar un concepto se presenta como una red de un conjunto de valores de hecho asociados con otros conceptos. Esto se ve comúnmente con los cálculos.

Etiqueta negada – Una etiqueta para indicar el hecho de un concepto debe mostrarse con el signo opuesto. Por ejemplo, una pérdida de capital en un contexto podría considerarse un número positivo, mientras que en otros debería interpretarse como negativa.

Etiqueta positiva – Una etiqueta para indicar el valor de hecho de un concepto debe ser reportada e interpretada como un valor positivo.

Etiqueta negativa – Una etiqueta para indicar el valor de hecho de un concepto debe ser reportada e interpretada como un valor negativo.

Etiqueta cero- Una etiqueta para indicar el valor de hecho de un concepto debe ser reportada e interpretada como cero.

7.2.2.3   Otros roles de etiqueta

Los siguientes roles de etiqueta son situacionales y se ven con menos frecuencia:

Etiqueta obsoleta – Una etiqueta para indicar que un concepto ha quedado obsoleto. Se pueden incluir más explicaciones. Esta etiqueta se puede combinar con la etiqueta de fecha obsoleta para indicar cuándo un concepto quedará obsoleto o la fecha en que el concepto quedó obsoleto dependiendo de la elección de uso del desarrollador.

Etiqueta de fecha obsoleta – La etiqueta de un concepto cuando el concepto ha sido o será obsoleto. Esta etiqueta se puede combinar con la etiqueta obsoleta para etiquetar conceptos obsoletos.

7.2.3      Español Creación de una taxonomía con una hoja de cálculo

La hoja de cálculo de taxonomía de widgets contiene la estructura necesaria para generar una taxonomía. Los datos de muestra se incluyen en la hoja de cálculo que debe ser reemplazada por el desarrollador. Las celdas naranjas representan encabezados de columna y no deben editarse.

La hoja de cálculo de desarrollo de taxonomía contiene dos hojas: una hoja titulada Conceptos y una hoja de conjunto de taxonomía detectable (DTS). El desarrollador personalizará cada una de estas hojas para reflejar la nueva taxonomía. Cada hoja se describe en las secciones siguientes. Tenga en cuenta que Arelle solo utiliza el contenido de las celdas para generar una taxonomía. Por lo tanto, se recomienda a los desarrolladores que utilicen el formato y la sangría para ayudar a que las hojas sean más claras, más organizadas y más fáciles de leer.

La presentación para el rendimiento de widgets tiene conceptos organizativos de contenedores agregados, como Rendimiento de widgets [Resumen] y Rendimiento de widgets [Tabla]. El primero es un concepto de contenedor para toda la presentación y el segundo es uno para esta tabla en particular (cada presentación puede contener cualquier número de tablas, aunque esta tiene solo una). También se requieren otros conceptos de contenedor, como Widget Type [Axis], que define la dimensión definida por la taxonomía, y Widget Type [Domain], que contiene los miembros permitidos para esta dimensión definida por la taxonomía. Finalmente, el Informe [Elementos de línea] contiene la dimensión central del concepto para esta tabla: Compras totales, Gastos de producción totales y Rendimiento del widget. Tenga en cuenta que esta tabla es una combinación de tres partes del modelo de datos físicos (Figura 5-3): Ventas totales, Gastos totales y Rendimiento del widget. Como se describe en la Sección 5.3.3, la taxonomía de widgets se presta a combinar estas partes del modelo de datos en una sola presentación, ya que no es necesario informar de los gastos individuales de los widgets.

La columna de profundidad de la figura 7-5 describe el nivel de anidamiento de conceptos para cada concepto. Tenga en cuenta que el nivel de profundidad corresponde a la sangría para cada concepto; esto se hizo para ayudar a los espectadores a ver la estructura jerárquica. Arelle solo hace uso de la columna de profundidad en la construcción de presentaciones.

La presentación de Widget Sales se definió de manera similar.

Como nota, el complemento Load From Excel de Arelle (que se describe más detalladamente en la siguiente sección) requiere que la hoja DTS importe US GAAP. Esta herramienta de libre acceso fue diseñada originalmente para ayudar a usar y visualizar US GAAP y, por lo tanto, mantiene este comportamiento incluso cuando se trabaja con taxonomías GAAP no estadounidenses. La importación de US GAAP a través de la hoja DTS en realidad no importa US GAAP en la taxonomía en sí a menos que se haga referencia a US GAAP en la hoja de conceptos. Los desarrolladores solo necesitan incluir una sola línea en la hoja DTS (como se muestra en la figura 7-6, fila 5).

Tenga en cuenta que esta referencia incluye y explica solo algunas de las opciones que se pueden usar en la hoja de cálculo junto con Arelle. Consulte la documentación de Arelle para obtener más información.

7.2.3.2.1              Archivos de nomenclatura

Los archivos y URI nombrados en la columna D de la hoja DTS deben ser sintácticamente correctos. Para los URI, se debe incluir todo el URI. Para los nombres de archivo, no es necesario que incluyan una ruta local o remota; Arelle generará eso durante el proceso de creación de la taxonomía. Tenga en cuenta que los nombres de archivo de linkbase deben terminar con una extensión de archivo .xml y los nombres de archivo de esquema deben terminar con una extensión de archivo .xsd.

Los desarrolladores pueden nombrar los archivos de taxonomía de salida como deseen. Sin embargo, el uso de un sufijo, como «_lab» para las bases de enlaces de etiquetas y «_cal» para las bases de enlaces de cálculo, puede ayudar en la organización (consulte la Figura 7-6).

7.2.3.2.2              Creación de puntos de entrada

Los desarrolladores pueden crear puntos de entrada en la hoja DTS creando una «subagrupación» en la taxonomía. Para ello, el documento de esquema de la taxonomía debe generarse de nuevo sólo con un nombre para el punto de entrada en la columna Archivo (columna D). Las presentaciones pertinentes a este punto de entrada deben enumerarse nuevamente debajo de él. Arelle utilizará esta información para crear otro archivo de esquema (.xsd) para el punto de entrada que solo contiene este subconjunto de presentaciones. Los desarrolladores siempre deben tener cuidado de crear un documento de esquema de toda la taxonomía, además de archivos de esquema separados para sus puntos de entrada.

Una vez que se completa la hoja de cálculo, se puede usar con Arelle para generar una taxonomía. La siguiente sección explorará los conceptos básicos del uso de Arelle.

7.3         Uso de Arelle

Una vez que los conceptos y estructuras han sido preparados en la hoja de cálculo, Arelle puede transformar esta información en una taxonomía. Tenga en cuenta de nuevo que Arelle requiere que el documento se guarde como una hoja de cálculo de Microsoft Excel; la mayoría de los programas de hojas de cálculo disponibles gratuitamente guardarán documentos en este formato.

Descarga Arelle en http://arelle.org/ y ábrelo. Arelle tiene una serie de complementos que se pueden ordenar e instalar yendo a Ayuda / Administrar complementos a través del menú. La carga del complemento desde Excel es necesaria para este proceso (Figura 7-7).

Una vez que se ha agregado el complemento correcto a Arelle, la taxonomía se puede generar yendo a Archivo / Abrir archivo y seleccionando la hoja de cálculo guardada localmente en la computadora. Arelle le pedirá al usuario que seleccione una carpeta local donde se colocarán los archivos de taxonomía generados.

Una vez creada la taxonomía, aparecerá en Arelle como se muestra en la Figura 7-8. Valide la taxonomía haciendo clic en el icono «escalas» en la barra de tareas (en un cuadro rojo en esta captura de pantalla).

Arelle incrustará la información de inclusión / importación como se especifica en la hoja DTS y generará documentos XML de esquema y base de enlaces según sea necesario. Como se indica en la discusión de la hoja DTS (Sección 7.2.3.2), los archivos linkbase son archivos ASCII con una extensión .xml, y los archivos de esquema son documentos ASCII con una extensión .xsd. Los nombres de archivo especificados en la hoja DTS deben aparecer aquí. Los desarrolladores pueden crear un archivo zip que contenga los archivos que componen la taxonomía como se muestra en la siguiente ilustración. Recuerde que estos archivos son guardados por Arelle en la carpeta seleccionada durante el proceso de generación de taxonomía.

Este archivo zip (Figura 7-9) contiene la taxonomía (que, en este caso, tiene dos puntos de entrada más bases de enlace). Los archivos zip facilitan el transporte y la difusión.

7.4         La importancia de la exposición pública

En este punto, los desarrolladores han creado esencialmente una taxonomía beta (Figura 7-1). Se deben realizar pruebas iniciales, como el desarrollo de documentos de instancias de prueba, un mejor refinamiento y/o implementación de reglas de calidad de datos, y el examen de las dificultades que pueden surgir en cualquier sistema de soporte. Una vez que la taxonomía ha pasado esta fase de prueba inicial, debe pasar a un borrador de taxonomía listo para su revisión pública.

La exposición pública es un paso vital en el proceso de desarrollo. Cabe señalar que el término «público» es relativo al tamaño y alcance de la taxonomía. Para una taxonomía grande que involucra a muchos preparadores, consumidores y potencialmente reguladores, la taxonomía debe someterse a una revisión pública significativa (donde cualquiera pueda ver y comentar sobre la taxonomía). Para una taxonomía pequeña cuyo uso puede limitarse a una herramienta interna en un

8.           Documentar una taxonomía

Una taxonomía XBRL es una herramienta poderosa para transportar datos de una manera estandarizada y predecible. Como cualquier herramienta, solo puede cumplir su propósito cuando quienes interactúan con ella entienden cómo usarla. Por lo tanto, la creación de documentación es un paso vital en el desarrollo de cualquier taxonomía XBRL. Todos los usuarios, desde los preparadores hasta los diseñadores de software, los reguladores y los consumidores, deben poder utilizar la taxonomía correctamente e interpretar los datos que representa. La documentación es una parte clave de ese proceso.

Al igual que con muchos otros pasos del proceso de desarrollo de la taxonomía, la cantidad y la amplitud de la documentación deben depender del alcance de la taxonomía y del número y variedad de usuarios que participarán en ella. Una taxonomía con alcance limitado, como una taxonomía destinada a informes internos dentro de una empresa, puede no requerir tanta documentación extensa. Una taxonomía que será relevante para muchas personas diferentes con diferentes niveles de familiaridad con XBRL puede requerir significativamente más apoyo y orientación del usuario. Además, una taxonomía que es simple con un número limitado de conceptos y que no es extensible puede no requerir una explicación tan profunda como una con miles de conceptos y múltiples formas de expresar los mismos datos. Esto último puede justificar una instrucción cuidadosa sobre qué enfoques son ideales en ciertas situaciones.

El proceso de redacción de la documentación debe estar en curso a través del desarrollo de la taxonomía. Además de otros documentos, los autores pueden considerar la publicación de un Libro Blanco de Taxonomía. Esto puede escribirse y hacerse público antes que los otros documentos, y debe presentar de manera concisa el problema de la industria, las regulaciones pertinentes, los requisitos y los casos de uso que afectan el proyecto, las opciones consideradas y la taxonomía como solución. Se debe explicar la justificación para seleccionar XBRL y las opciones generales de diseño. El Libro Blanco de Taxonomía puede considerarse como un anuncio de la taxonomía, con explicación de su propósito y justificación para su desarrollo. Este documento está destinado a presentar al público la taxonomía y sentar las bases para su eventual adopción. Una plantilla de ejemplo para el Libro Blanco de Taxonomía se puede encontrar en el Apéndice C.

Como mínimo, los desarrolladores también deben crear una Guíade taxonomía general, que ofrece una explicación en profundidad de la estructura y el contenido de la taxonomía, una Guía del preparador,para guiar a los preparadores en la creación de informes precisos y bien estructurados, y una Guía del consumidor de datos,para proporcionar ejemplos detallados sobre cómo usar la taxonomía para lograr casos de uso comunes. La creación de la Guía de Taxonomía se puede realizar en paralelo con el desarrollo de la taxonomía, mientras que la Guía del Preparador y la Guía del Consumidor de Datos pueden escribirse hacia el final del proceso.

Tenga en cuenta que estas tres guías se aplican a audiencias muy separadas, que se discutirán con mayor detalle en las secciones posteriores de este capítulo. El maquillaje y el conjunto de habilidades de la audiencia es una consideración clave al elaborar cualquier documento técnico. Como visión general, la Guía de Taxonomía tiene como objetivo explicar la taxonomía en sí en detalle, incluidas las opciones de diseño (como permitir la extensibilidad) y los fundamentos detrás de esas elecciones. Este documento está destinado a ser una especificación técnica y, por lo tanto, está dirigido a administradores de taxonomía y desarrolladores de software. Este documento puede servir como un modelo durante el desarrollo de la taxonomía y como una guía para los usuarios y desarrolladores después de que la taxonomía ha sido publicada. La Guía del preparador está destinada a proporcionar a los preparadores información útil sobre los conceptos y estructuras de la taxonomía según sea necesario para crear informes XBRL. Por último, la Guía del consumidor de datos tiene por objeto proporcionar información y casos de uso comunes para los consumidores de datos.

En la Figura 8-1 aparecen diferentes métodos para organizar la documentación de taxonomía. Si el desarrollador opta por no crear una Guía del preparador y/o una Guía del consumidor de datos separados, la única Guía de taxonomía debe cubrir estas áreas temáticas. Sin embargo, como regla general, un documento técnico no debe contener una gran cantidad de información que no sea pertinente o relevante para su público objetivo. Hacerlo hace que el documento sea difícil de navegar. Si entre un cuarto y un tercio del contenido del documento está dirigido a una audiencia diferente a la audiencia del resto del documento, se debe considerar la creación de guías separadas.

También es probable que diferentes lectores tengan diferentes niveles de experiencia en el estándar XBRL. Los autores de cualquier guía XBRL deben incluir una descripción general de XBRL para garantizar que todos los lectores tengan una comprensión básica de XBRL. La Descripción general de XBRL debe poner al día a los lectores novatos sobre las construcciones de XBRL, como los conceptos y el papel de las dimensiones definidas por la taxonomía, de modo que estén mejor equipados para trabajar con la taxonomía. El Apéndice D contiene un ejemplo de descripción general de XBRL.

Finalmente, a medida que las actualizaciones y versiones de taxonomía se introducen y difunden a sus usuarios, los desarrolladores deben tener cuidado de crear notas de la versión informativas y útiles. Esto se discute al final de este capítulo.

Toda la documentación de XBRL debe incluir información explicativa, diagramas, ilustraciones y referencias siempre que sea posible. Los ejemplos a menudo pueden ayudar a los lectores a relacionar ideas abstractas con instancias familiares del mundo real, y las ilustraciones ayudan a visualizar relaciones complejas. Como regla general, estas herramientas deben emplearse estratégicamente para ayudar a los lectores a digerir el documento.

8.1         Cómo utilizar este capítulo

Este capítulo proporciona un marco para la estructura y el contenido de una Guía de taxonomía, una Guía de preparación y una Guía del consumidor de datos. Los subtítulos dentro de cada sección abordan los temas generales que deben incluirse en cada tipo de documento. Los desarrolladores también pueden consultar el Apéndice E, el Apéndice F y el Apéndice G para obtener plantillas de estos documentos (que también están disponibles para su descarga como archivos de documentos de Microsoft Word desde https://xbrl.us/tdh-templates). Estas plantillas se pueden utilizar como base para construir documentación. Sus contornos coinciden exactamente con los contornos cubiertos en este capítulo. Además, siempre que sea posible, el texto «repetitivo» aparece en la plantilla para guiar a los autores a comenzar su discusión de los temas relevantes, además de los elementos de viñeta claramente marcados que deben reemplazarse con el contenido apropiado específico de la taxonomía que se está documentando. En otras palabras, el contenido que sigue en este capítulo proporciona consejos y orientación sobre cómo completar estas plantillas, y las plantillas correspondientes contienen texto genérico, así como breves recordatorios sobre qué tipo de información debe cubrirse. Los autores pueden optar por renunciar al uso de estas plantillas o crear su propio contenido basado en las plantillas; la orientación de este capítulo seguirá siendo útil para determinar qué tipo de información debe discutirse en las guías y cómo debe organizarse.

Las necesidades de documentación, por supuesto, variarán de una taxonomía a otra. Por lo tanto, este capítulo y las plantillas en los apéndices están destinados a establecer un esquema general de lo que estos documentos pueden contener para ayudar a los lectores a comprender XBRL y la taxonomía XBRL. Algunas de las siguientes secciones pueden no ser aplicables a todas las situaciones, y algunas pueden requerir una discusión más profunda de lo que se indica aquí. Depende de los desarrolladores y autores de la documentación determinar la naturaleza y profundidad del contenido de cada guía.

8.2         El Libro Blanco de taxonomía

El Libro Blanco de Taxonomía debe presentar la taxonomía a un lector promedio. Este breve documento está destinado a presentar el problema de la presentación de informes de datos en la industria o empresa (es decir, la razón por la que se desarrolló la taxonomía), otras soluciones potenciales y la taxonomía como respuesta a este dilema. Es posible que los autores deseen presentar una discusión superficial de los requisitos, regulaciones y casos de uso relevantes que influyen en el problema de la industria. Se puede presentar una descripción breve e imparcial de las soluciones alternativas, lo que lleva a la discusión de cómo la taxonomía XBRL es la solución óptima. Este documento no es técnico y no debe profundizar en detalles sobre la taxonomía. Más bien, está destinado a dar a un lector que tal vez no tiene educación con XBRL pero que entiende el dilema y las necesidades de la industria una base para comprender por qué la nueva taxonomía es necesaria. Más que otros documentos, el Libro Blanco de Taxonomía se puede escribir con un tono más persuasivo para indicar claramente a los lectores que la nueva taxonomía XBRL es una solución sólida a los problemas presentados.

En el apéndice C aparece una plantilla de ejemplo para un documento técnico sobre taxonomía.

8.3         La Guía de Taxonomía

La Guía de Taxonomía es el documento más básico e importante sobre la explicación de la taxonomía en sí. La audiencia de la Guía de Taxonomía es aquella que necesita tener una comprensión profunda de todos los aspectos de la taxonomía independientemente de cualquier caso de uso particular. Este documento explicará la estructura de la taxonomía, indicará la forma en que la taxonomía representa y valida los datos, y dilucidará cómo opera el modelo de transporte en sus niveles más fundamentales. Esta información es clave para aquellos que administrarán o supervisarán la taxonomía en sí, así como para los desarrolladores de software de terceros que deben diseñar soluciones de software sólidas que puedan emplear la taxonomía para proporcionar datos de alta calidad.

8.3.1      Metas

Esta sección describe claramente los objetivos generales de la Guía de Taxonomía para los lectores, que se establecieron en este manual en la sección anterior. La sección también debe incluir una descripción del público objetivo de la Guía de Taxonomía y puede indicar el nivel de familiaridad que estos lectores deben tener con la industria y las normas reglamentarias. Por ejemplo, para una taxonomía de informes financieros, los lectores objetivo de la Guía de Taxonomía pueden ser desarrolladores que estén familiarizados con la preparación de estados financieros US GAAP.

8.3.1.1   Historial de revisiones

Los autores deben mencionar que el documento está sujeto a revisión periódica además de describir su historial de revisiones. El proceso de gobernanza debe describirse brevemente en lo que respecta a las actualizaciones de taxonomía y documentación para que los lectores sepan que se pueden realizar cambios y cómo se implementarán esos cambios.

8.3.2      Español Introducción a la taxonomía y una visión general de XBRL

Los autores deben comenzar por introducir la taxonomía y su propósito a un nivel muy alto. Los lectores deben ser conscientes de por qué existe la taxonomía, los tipos de datos que se supone que representa y su lugar a lo largo de la cadena de suministro de información de la industria o los sectores comerciales para los que se ha desarrollado. Además, los autores deben incluir la Descripción general de XBRL (Apéndice D), para la cual XBRL US ha proporcionado una plantilla preconstruida. Esta sección es una introducción básica sobre XBRL para que los lectores que no estén familiarizados con el estándar puedan ponerse al día rápidamente con sus construcciones y usos básicos.

8.3.3      Alcance

Antes de describir la taxonomía, los autores y desarrolladores deben considerar delinear los factores que impulsaron cómo se desarrolló la taxonomía. Esta discusión puede describir los requisitos funcionales y no funcionales, los casos de uso que la taxonomía está diseñada para representar y otras consideraciones regulatorias y de desarrollo. La sección también puede explicar los documentos, bases de datos e informes subyacentes que respaldan los requisitos, así como las opciones de diseño relevantes para cumplir con esos requisitos. En resumen, esta sección debe abordar el alcance general del proyecto de desarrollo y las consideraciones que se analizan en el capítulo 4.

8.3.4      Características clave y estructura

Esta sección está destinada a resaltar características importantes de la taxonomía que los usuarios deben comprender al trabajar con la taxonomía. Algunas de estas cuestiones pueden tratarse con mayor detalle más adelante en la Guía de Taxonomía; esta sección debe proporcionar una breve introducción, no una discusión exhaustiva. Tenga en cuenta que la plantilla proporcionada en el Apéndice E divide algunos de estos temas en subsecciones; esta es una opción de documentación y los autores deben organizar la información de una manera adecuada para ellos.

8.3.5      El modelo de datos de transporte

La siguiente sección de la Guía de Taxonomía debe proporcionar una explicación detallada del dominio de presentación de informes y el flujo de información que la taxonomía está diseñada para capturar. Esto describe directamente el modelo de datos de transporte.

Como se indica en el capítulo 2.1.2, el modelo de datos de transporte define el significado de los datos en el contexto de sus interrelaciones con otros datos. Si bien este tema se ha discutido en profundidad en este documento, los lectores de la Guía de Taxonomía pueden no estar tan familiarizados con el propósito de un modelo de datos de transporte. Los autores deben explicar que el modelo de datos de transporte puede reflejar aspectos de los modelos de datos semánticos empresariales tanto en el lado de los preparadores como en el de los consumidores, pero el modelo de transporte es independiente de ambos y está diseñado para transmitir datos de los preparadores a los consumidores de una manera predecible, autodescriptiva y predeterminada. La naturaleza de este modelo de transporte y cómo la taxonomía expresa ese modelo debe explicarse aquí. Esto puede, una vez más, implicar una breve discusión de los requisitos, regulaciones y casos de uso pertinentes. La sección también puede presentar una descripción y posiblemente una representación gráfica de la cadena de suministro de datos específica de esta taxonomía.

8.3.6      Revisión detallada de la taxonomía

Esta sección de la Guía de taxonomía proporciona un recorrido detallado de la estructura y el contenido de la taxonomía. Esta sección debe formar la mayor parte de la Guía de Taxonomía.

8.3.6.1   Taxonomía Estructura fïsica

Con el modelo de datos de transporte entendido por los lectores, esta sección puede articular cómo la taxonomía representa ese modelo. Debido a que este tema es tan importante, los autores y desarrolladores deben tener cuidado de asegurarse de que sus explicaciones de las razones detrás de las opciones de diseño de la taxonomía sean claras. Una comprensión sólida de cómo la estructura general de la taxonomía encapsula el modelo de datos es clave para usar la taxonomía y desarrollar software para ayudar a los usuarios a interactuar con ella.

Utilizando tanto diagramas como texto, la sección debe describir la estructura de la taxonomía en detalle, incluidos los grupos de conceptos y las jerarquías. Los autores y desarrolladores pueden describir por qué se crearon estas agrupaciones, qué están diseñadas para capturar y quién es el público objetivo para cada una. Por ejemplo, si un formulario se utilizó ampliamente en un caso de uso respaldado por la taxonomía, un punto de entrada puede abarcar conceptos relacionados con ese formulario. Del mismo modo, si los datos representados por la taxonomía se derivan de bases de datos, los puntos de entrada pueden representar conceptos relacionados con las tablas de bases de datos. El enfoque, o múltiples enfoques, adoptados deben explicarse aquí en detalle para que los lectores puedan comprender cómo la estructura de la taxonomía presta servicios a los datos en sí.

Al igual que con la mayoría de los aspectos de la documentación, el tamaño y el alcance de la taxonomía deben dictar el nivel de detalle y explicación requerido para garantizar la comprensión. Las taxonomías grandes, como la Taxonomía del Botón Naranja, que tiene más de 4,000 conceptos, pueden necesitar ser explicadas agrupando el contenido en «secciones» lógicas y proporcionando una revisión en profundidad de cada sección. Las secciones lógicas pueden ser puntos de entrada, presentaciones, tablas o incluso conceptos abstractos si esta agrupación es lo suficientemente compleja como para merecer más detalles. Las taxonomías más pequeñas, como la Taxonomía de Trabajo en Proceso de Caución, que tiene aproximadamente 60 conceptos, pueden manejarse de manera diferente. En una taxonomía más pequeña, los autores pueden dedicar más tiempo a descripciones detalladas de cada categoría de datos, describiendo el significado de los conceptos y cómo funcionan dentro del número limitado de tablas.

8.3.6.2   Conceptos

Esta sección debe abordar los conceptos de la taxonomía y cómo se relacionan con la información común en el campo, la industria o el sector empresarial. Dependiendo del tamaño y el alcance de la taxonomía, la discusión podría ser profunda o superficial. Las relaciones que los conceptos tienen con los puntos de entrada, las presentaciones y los documentos o bases de datos de origen deben explorarse según sea necesario. Los autores deben explicar cómo algunos conceptos son dimensiones centrales del concepto (que se relacionan directamente con el hecho y dictan las propiedades del hecho) y cómo otros conceptos son abstractos y están destinados a agrupar datos. Además, los autores pueden desear explorar brevemente las propiedades del concepto, particularmente las etiquetas, ya que serán específicas de la taxonomía y la industria.

8.3.6.3   Dimensiones

La dimensionalidad de las tablas dentro de cada sección de la taxonomía debe describirse en detalle, incluidas las dimensiones XBRL principales (unidades permitidas, entidades, etc.), cómo usar las dimensiones definidas por la taxonomía que componen la tabla y si las dimensiones definidas por la taxonomía son tipadas o explícitas. Además, deben explicarse los fundamentos de las decisiones de diseño. ¿Por qué se eligió una dimensión mecanografiada o explícita? ¿Qué representan las dimensiones definidas por la taxonomía y sus miembros? Si hay varias dimensiones XBRL, ¿cómo usaría el preparador esos ejes? ¿Cómo deben representarse los elementos de línea de la tabla? Estas preguntas deben responderse adecuadamente para que los lectores puedan comprender cómo la taxonomía representa los datos dimensionales.

Una vez más, el tamaño de esta sección depende de la complejidad y el alcance de la taxonomía. Para una taxonomía muy grande, si muchas de las tablas contienen estructuras dimensionales similares, se puede explicar una tabla ejemplar con mayor detalle para ilustrar la estructura con una discusión más breve sobre cómo esta estructura se aplica en otros lugares. Las tablas también se pueden agrupar en la discusión si representan datos y dimensionalidad similares. El objetivo es, como siempre, explicar la información relevante con el menor material duplicado o redundante posible.

8.3.6.4   Cálculos (opcional)

Si la taxonomía contiene cálculos, esta sección debe incluir una explicación de las relaciones de cálculo entre conceptos. Debe explicarse cada cálculo y sus implicaciones en la validación de los valores de los hechos, así como la justificación para incluir los cálculos, si procede.

8.3.6.5   Fórmulas (Opcional)

Si la taxonomía contiene fórmulas, esta sección debe incluir una explicación de las relaciones de fórmula entre conceptos. Cada fórmula y sus implicaciones en la validación de los valores de los hechos deben ser explicadas. Además, los autores pueden explicar por qué se diseñaron e incluyeron las fórmulas.

8.3.6.6   Tipos de datos y unidades

La Guía de taxonomía debe incluir una lista de los tipos de datos estándar utilizados (por ejemplo, cadena, monetario, booleano, etc.) y por qué se seleccionaron para representar datos de hechos. Los desarrolladores y autores deben discutir en detalle cualquier tipo de datos no estándar o personalizado. Por ejemplo, en la taxonomía del botón naranja, se incluyen muchos tipos de datos no estándar relacionados con la electricidad, como energyItemType, powerItemType e insolationItemType. Esta taxonomía también contiene tipos de datos personalizados, como el tipo de datos «moduleItemType», que se creó para dar a los preparadores opciones para elegir de una lista de tecnologías de módulos. Estos tipos de datos y sus usos deben ser discutidos.

Consulte el Apéndice A para obtener una lista aceptada de tipos de datos y tipos de unidades.

Los autores también deben discutir las dimensiones del núcleo de la unidad, su uso y dónde se requieren.

8.3.6.7   Uso cruzado de conceptos (opcional)

Como se explica en la Sección 2.4.2, los conceptos pueden aparecer en más de una sección de una taxonomía porque pueden ser aplicables a múltiples situaciones de notificación. Esto debe explicarse en lo que respecta a la taxonomía que se está documentando.

8.3.6.8   Referencias de taxonomía (opcional)

En la sección Descripción general de XBRL (consulte la Sección 8.3.2), los autores habrán explicado qué estándares específicos del dominio se utilizan en la taxonomía, si los hay. En esta sección de la Guía de Taxonomía,los autores pueden aprovechar una segunda oportunidad para explorar más profundamente por qué se utilizaron esos estándares y cómo ayudan a proporcionar un mayor contexto a los conceptos individuales.

8.3.6.9   Tipos de Linkbase

Los autores deben discutir las bases de enlaces utilizadas dentro de la taxonomía en esta sección. En este punto, es posible que muchas de las presentaciones, definiciones, cálculos, etiquetas y tipos de referencia ya se hayan discutido. Aquellos que no han sido cubiertos deben describirse aquí como aplicables. Los autores también pueden desear mostrar cómo las bases de enlaces definen estas diversas relaciones a través de arcos.

8.3.7      Formato de transporte y preparación de instancias

El formato de transporte y cómo preparar documentos de instancia sólidos son temas que se exploran más adecuadamente en detalle en la Guía del preparador (consulte la Sección 8.4). Sin embargo, los autores deben proporcionar una visión general rápida del formato de transporte (si se ha elegido XML, JSON o CSV, por ejemplo, y el razonamiento detrás de la decisión), si es aplicable y relevante para el uso de la taxonomía. Los autores también deben analizar cómo se puede utilizar ese formato para preparar documentos de instancia. Cualquier consideración que surja del formato de transporte en términos de uso de la taxonomía o creación de informes debe ser discutida.

Finalmente, los autores deben describir cualquier sistema pertinente involucrado en la creación y / o transmisión de un informe XBRL construido con la taxonomía (por ejemplo, en el caso de informes financieros a la SEC, los autores de la Guía de Taxonomía pueden querer presentar el propósito y la mecánica del sistema EDGAR que los preparadores utilizan para enviar sus presentaciones XBRL a los reguladores).

8.3.8      Uso de la validación

La validación es clave para la integridad y usabilidad de los datos. Por lo tanto, esta parte de la Guía de Taxonomía debe tener una discusión extensa de cómo los administradores de taxonomía y otros desarrolladores pueden usar la estructura de taxonomía para ayudar a validar los datos que representa la taxonomía. El uso de la tipificación de datos adecuada se puede mencionar nuevamente. Los cálculos y las fórmulas se pueden revisar aquí y cómo se podrían implementar soluciones de software para garantizar que estas relaciones entre los conceptos sean ciertas para los valores informados. Esta discusión podría incluir otros enfoques de validación, como XULE. Los autores también deben explorar la validación externa y los marcos regulatorios y cómo se pueden aplicar. Las consideraciones específicas de la industria deben detallarse aquí para explicar cómo la taxonomía puede mantener la integridad de los datos a medida que se transmite de los preparadores a los consumidores.

8.3.9      Desarrollo de Software

Una audiencia clave de la Guía de Taxonomía puede ser los desarrolladores de software, dependiendo de si los desarrolladores de taxonomía y los reguladores permiten el desarrollo de software de terceros. Si la implementación de XBRL es pública y tiene numerosos usuarios y aplicaciones, probablemente dependerá de software de terceros para ayudar a los preparadores a crear informes XBRL. Cuantas más opciones de software haya disponibles para los preparadores, menos costoso y oneroso se vuelve el proceso de adopción de XBRL.

Si no se permite el desarrollo de software externo, los autores deben indicarlo aquí. Si es así, los autores deben cubrir la información pertinente para crear soluciones de software que vean la taxonomía, preparen documentos de instancia, utilicen información con formato XBRL en análisis de datos posteriores o ayuden a los usuarios a ampliar la taxonomía. Al igual que con muchos temas en la Guía de Taxonomía, la naturaleza de la industria y la taxonomía en sí misma deberían impulsar esta discusión. Por ejemplo, si es probable que ayudar a los preparadores a estructurar sus datos y crear informes XBRL sea una fuente importante de desarrollo de software, es posible que los autores deseen dedicar más discusión a los aspectos de la taxonomía que son relevantes para este tema (como cómo implementar la validación basada en cálculos y fórmulas o cómo guiar a los usuarios en la selección de los conceptos correctos para representar sus datos).

Además, es posible que los autores deseen indicar qué recursos están disponibles para ayudar a los desarrolladores a probar sus aplicaciones de software (acceso a los esquemas XML, documentos de instancia XBRL de prueba, etc.). Si corresponde, proporcionar un entorno propicio para el desarrollo de software de terceros puede ayudar enormemente a facilitar y alentar el uso de la taxonomía para crear informes XBRL sólidos, que es el objetivo de la mayoría de las partes interesadas en la cadena de suministro de información.

8.3.10    Referencias y otros recursos

En esta sección final, los autores deben explicar qué referencias se utilizaron para desarrollar y documentar la taxonomía. Los materiales de referencia que se pueden utilizar y pueden ser útiles para otros usuarios y desarrolladores incluyen la Guía de estilo de XBRL US, este Manual de desarrollo de taxonomía de XBRL US, las Especificaciones técnicas actuales de XBRL y los Modelos de información abierta, así como recursos específicos de la industria que pueden haber influido en la creación y el uso de la taxonomía.

Los autores también pueden considerar incluir otras formas en que los lectores pueden educarse sobre XBRL y la taxonomía, incluida la Guía del preparador y la Guía del consumidor de datos si estos documentos están separados de la Guía de taxonomía y disponibles. Los autores también deben incluir formas de ponerse en contacto con los desarrolladores de taxonomía y los comités de gobernanza, según corresponda, para que los usuarios puedan recibir respuestas a comentarios, preguntas e inquietudes.

8.4         La guía del Preparador

La Guía del preparador está destinada a ayudar a los preparadores en el proceso de creación de informes XBRL utilizando la taxonomía. A menudo, este documento es parte de la propia Guía de Taxonomía, pero debe separarse si es lo suficientemente largo y complicado como para que la información no sea aplicable tanto a las audiencias de desarrollo como de preparación.

8.4.1      Metas

Esta sección describe claramente los objetivos generales de la Guía del Preparador para los lectores. Además, los autores deben describir el público objetivo de la Guía del preparador y pueden indicar el nivel de familiaridad que estos lectores deben tener con la industria y los estándares regulatorios. Por ejemplo, para una taxonomía de informes financieros, los lectores objetivo de la Guía del Preparador pueden ser agentes de presentación y / o registrantes con agencias federales de informes que están familiarizados con la preparación de estados financieros de acuerdo con US GAAP.

8.4.1.1   Historial de revisiones

Los autores deben mencionar que el documento está sujeto a revisión periódica además de describir su historial de revisiones. El proceso de gobernanza debe describirse brevemente en lo que respecta a las actualizaciones de taxonomía y documentación para que los lectores sean conscientes de que se pueden realizar cambios y cómo se implementarán esos cambios.

8.4.2      Introducción a la taxonomía y una visión general de XBRL

Los autores deben comenzar por introducir la taxonomía y su propósito a un nivel muy alto. Los lectores deben ser conscientes de por qué existe la taxonomía, los tipos de datos que debe representar y su lugar a lo largo de la cadena de suministro de información para la industria o los sectores comerciales para los que se ha desarrollado. Además, en la Guía del preparador debe haber una discusión de los requisitos reglamentarios que pueden aplicarse a la taxonomía y los informes XBRL creados con ella. Finalmente, los autores deben indicar si el sistema de informes permite la extensibilidad y, de ser así, qué construcciones XBRL son extensibles. Esto debería ser en términos breves; recuerde a los lectores que una mayor discusión sobre la extensibilidad ocurre más adelante en el documento (según corresponda).

Los autores deben incluir la Descripción general de XBRL, para la cual XBRL US ha proporcionado una plantilla preconstruida (Apéndice D). Esta sección debe proporcionar una introducción básica sobre XBRL para que los lectores que no están familiarizados con el estándar puedan ponerse al día rápidamente con sus construcciones y usos básicos.

8.4.3.     Transformación de datos en XBRL

Un enfoque importante de la Guía del preparador es proporcionar orientación sobre el formato de los datos en XBRL con el fin de generar un informe XBRL bien estructurado. Por lo tanto, una parte significativa de la guía debe dedicarse a mapear los datos, ya que pueden haber sido estructurados previamente en la industria (como los formularios actualmente empleados en el proceso de presentación de informes) al nuevo modelo de datos de transporte XBRL. Si no existen datos previos de manera formalizada, la guía también debe instruir a los preparadores sobre cómo recopilar cualquier información que sea necesaria para la transformación en XBRL. Independientemente de cómo se generen los datos, es probable que el proceso de formato XBRL sea una de las fuentes fundamentales de confusión y preocupación para los preparadores que se enfrentan recientemente a la creación de informes XBRL fuera de su flujo de trabajo de datos normal, por lo que es una buena idea pasar parte de la documentación ofreciendo una explicación clara y concisa de cómo la taxonomía representa los datos con los que los preparadores ya pueden estar familiarizados.

8.4.3.1   Origen de datos, documentos y formularios

Como primer paso, los autores deben explicar qué información de origen está representada por la taxonomía. Esto incluye formularios de informes heredados, documentos, presentaciones, bases de datos y otras fuentes de información reportable. Esto sienta las bases para recopilar los datos necesarios para construir un informe XBRL. Tenga en cuenta que, en algunos casos, esta puede ser la primera vez que estos puntos de datos individuales o conjuntos de datos se han recopilado para este propósito de informe. Dependiendo de la situación, los autores pueden desear explicar qué son estos conjuntos de datos y cómo se relacionan entre sí, así como los informes resultantes. Además, si hay consideraciones regulatorias gubernamentales o no gubernamentales, esto debe discutirse para que los preparadores puedan estar al tanto de cualquier mandato que se aplique al informe XBRL.

8.4.3.2   Preparación de datos

Dados los datos de origen, los autores deben guiar a los preparadores a través de la preparación de los datos para la transformación a XBRL. Esto puede incluir temas como: transformación de documentos de un formato a otro (como organizar datos en un procesador de textos u hoja de cálculo o exportar conjuntos de datos de una base de datos a archivos de lista delimitados), realizar funciones de limpieza de los datos (como garantizar que toda la información se presente en el conjunto de caracteres adecuado para la transmisión XBRL y esté correctamente formateada), y garantizar que las opciones de estilo y presentación se ajusten a los estándares vigentes si se va a utilizar Inline XBRL.

Además, se debe hacer hincapié en la evaluación de la integridad de los datos en este nivel inicial. Es posible que los autores deseen recordar a los preparadores que, si bien el software XBRL y XBRL puede proporcionar algunas medidas de validación, no se puede monitorear la precisión completa de ningún conjunto de datos en particular. Depende de los preparadores asegurarse de que los hechos que se informan sean correctos. Por lo tanto, los preparadores pueden tomarse el tiempo en esta etapa para reducir el número de puntos de datos faltantes, verificar que las relaciones matemáticas sean correctas y significativas y, en general, garantizar que la información contextual sea precisa. Tomar estos pasos antes de transformar los datos a XBRL puede reducir la probabilidad de «basura dentro, basura fuera» y potencialmente disminuir la dificultad para detectar errores más adelante, cuando la legibilidad humana puede reducirse significativamente.

8.4.3.3   Software de preparación proporcionado (opcional)

Muchas implementaciones XBRL se basarán en numerosas aplicaciones de software disponibles en el mercado. Dependiendo de la situación, la Guía del preparador puede proporcionar una discusión genérica de la preparación del informe XBRL sin especificar o respaldar ciertas aplicaciones. Por ejemplo, el uso adecuado de dimensiones XBRL escritas y explícitas es una tarea que deberá seguirse cuando se trabaje con cualquier aplicación de software. El proceso puede ser ligeramente diferente de una solicitud a otra, pero las decisiones subyacentes serán las mismas. Por otro lado, si hay software de terceros u otro software que está respaldado, recomendado o desarrollado por los reguladores de taxonomía, los autores pueden querer mencionar las ventajas de usarlo. Una vez más, para el software genérico, los autores probablemente no deberían respaldar una solución sobre otra.

Si el software proporcionado existe, los autores pueden desear integrar una guía para usar ese software como parte de este documento. Vincular la discusión de los siguientes temas directamente al software aumentará la comprensión del lector de una manera práctica al tiempo que proporciona ejemplos prácticos de cómo realizar las tareas necesarias para crear un informe XBRL en el software.

8.4.4      El modelo de datos de transporte

Esta sección debe describir el modelo de transporte en términos de cómo se puede utilizar para estructurar los datos necesarios para los informes XBRL. Los preparadores ahora deben ser conscientes de los tipos de datos que necesitan recopilar para crear el informe, y deben saber cómo debe formatearse y prepararse para transformarse en XBRL. Los autores ahora pueden explicar la taxonomía y sus construcciones para ayudar a guiar a los preparadores a interactuar con ella a medida que transforman sus datos en XBRL.

8.4.4.1   Puntos de entrada y presentaciones

Los autores deben comenzar describiendo los puntos de entrada de la taxonomía, particularmente si estos puntos de entrada están definidos por formularios preexistentes o casos de uso pertinentes para la preparación del informe XBRL. Por ejemplo, si un punto de entrada contiene tablas relevantes para la información que una vez se informó a través de formato tabular en forma legible por humanos (como un documento PDF o HTML), esto debe cubrirse en detalle. Las presentaciones particulares dentro de los puntos de entrada también deben discutirse, ya que son relevantes para este tema. El objetivo de esta sección debe ser orientar a los lectores que pueden estar familiarizados con los formularios, documentos, bases de datos y sistemas preexistentes sobre cómo la taxonomía XBRL organiza esos datos. Las presentaciones deben relacionarse lógicamente con los puntos de entrada y pueden discutirse en el contexto del propósito del punto de entrada. La conversación puede progresar naturalmente a conceptos y cómo XBRL los usa para representar los datos y la dimensionalidad de los datos.

8.4.4.2   Conceptos y cómo seleccionarlos

Esta sección debe abordar los conceptos de la taxonomía y cómo se relacionan con la información común en el campo, la industria o el sector empresarial. Dependiendo del tamaño y el alcance de la taxonomía, esta discusión podría ser profunda o superficial. La relación que tienen los conceptos con los puntos de entrada, las presentaciones y los documentos o bases de datos de origen debe explorarse según sea necesario. Los autores deben explicar cómo algunos conceptos están destinados a ser dimensiones centrales del concepto (que se relacionan directamente con el hecho y dictan las propiedades del hecho) y cómo otros conceptos son abstractos y están destinados a agrupar datos. Al igual que con otras secciones de la Guía del preparador, los autores deben agrupar el contenido para explicar la información más relevante sin texto redundante.

En la medida de lo posible, los autores también deben proporcionar alguna orientación sobre cómo seleccionar conceptos para representar hechos. En una taxonomía suficientemente grande, los preparadores pueden sentirse abrumados por la cantidad de conceptos, por lo que puede ser útil explicar cualquier diferencia entre conceptos similares y proporcionar pautas generales sobre cómo elegir los conceptos que son los más apropiados (examinar las etiquetas de conceptos, por ejemplo, para determinar la mejor opción). Esto puede implicar vincular nuevamente la taxonomía a formularios, documentos y bases de datos preexistentes. Si el sistema de informes permite la extensibilidad, los autores deben explorar lo que eso significa y cómo puede ser utilizado por los preparadores para agregar conceptos personalizados, en caso de que el concepto con el significado apropiado para un punto de datos no esté disponible para ellos. También puede ser prudente advertir a los preparadores sobre la adición de demasiados conceptos personalizados y proporcionar orientación sobre cuándo es mejor crear un concepto en lugar de usar uno preexistente.

8.4.4.3   Tipos de datos y unidades

La Guía del preparador debe incluir una lista de los tipos de datos estándar utilizados en la taxonomía (por ejemplo, cadena, monetario, booleano, etc.). Los autores también pueden discutir cualquier tipo de datos no estándar o definido por taxonomía y cómo deben ser utilizados por los preparadores. Se pueden mencionar los conceptos (o tipos de conceptos) que utilizan estos tipos de datos.

Los autores también deben explorar las dimensiones centrales de la unidad, su uso y dónde se requieren. Si la dimensión central del lenguaje es relevante para todo o parte del informe XBRL, también debe cubrirse aquí.

8.4.4.4   Identificadores

Los autores deben discutir en detalle qué tipos de identificadores están permitidos en los informes XBRL creados utilizando la taxonomía. Los identificadores se pueden utilizar con conceptos particulares (que pueden estar limitados por el tipo de datos del concepto) o con una dimensión central de entidad. Los identificadores permitidos varían de una taxonomía a otra. Por ejemplo, los informes XBRL relacionados con la información financiera pueden utilizar identificadores de personas jurídicas (IPJ) u otros códigos o identificadores asociados con las transacciones financieras. Un informe XBRL que utilice una taxonomía diseñada para realizar un seguimiento de la producción de widgets podría emplear identificadores específicos de los tipos de widgets. Aquí se debe proporcionar orientación sobre qué identificadores están permitidos y las normas subyacentes a ellos (como ISO 17442 para IPJ, por ejemplo).

8.4.4.5   Cuándo y cómo usar dimensiones definidas por taxonomías

Puede ser muy desalentador tanto para el usuario XBRL novato como para el experimentado determinar la mejor manera de estructurar sus datos en un informe XBRL. Crear dimensionalidad puede ser una perspectiva difícil, particularmente en datos muy complejos. Los autores de la Guía del Preparador deben dedicar tiempo en esta sección a describir la dimensionalidad de las tablas en la taxonomía y cómo esas tablas representan los datos con los que los lectores pueden estar familiarizados. Esto será clave en la comprensión de los lectores de cómo traducir sus datos tal como se almacenan y formatean actualmente en XBRL, tal vez no mecánicamente, sino en términos de cómo los conceptos y dimensiones de XBRL se relacionan con la estructura de su modelo de datos. Una vez más, los autores deben presentar la información más pertinente y reducir la redundancia agrupando tablas similares tanto como sea posible.

8.4.4.6   Cálculos, fórmulas y definiciones (opcional)

Todas las demás relaciones conceptuales relevantes deben discutirse en esta sección. Esto debe incluir, pero no puede limitarse a, cálculos, fórmulas y definiciones. Según corresponda, se debe describir cada tipo de relación, con los autores teniendo cuidado de explicar el razonamiento detrás de la relación y cómo la estructura de la taxonomía y las bases de enlaces definen y respaldan la relación. Si la relación de concepto confiere validación (como el concepto A y el concepto B deben sumar a través de un arco de cálculo al concepto C), esto también debe cubrirse.

8.4.4.7   Etiquetas y notas al pie

Las etiquetas conceptuales deben cubrirse en detalle. En general, los estándares de la industria dictarán lo que es apropiado para ser utilizado como una etiqueta conceptual. Se debe aconsejar a los preparadores que usen etiquetas para ayudar en la selección de conceptos. Además, si el sistema de presentación de informes permite conceptos extensibles, se debe proporcionar a los preparadores alguna orientación sobre cómo seleccionar información significativa y relevante para las etiquetas.

Según corresponda, se debe guiar a los preparadores sobre cómo usar adecuadamente las notas al pie y la dimensión DE ID del núcleo de la nota. Las reglas de la industria y los formatos aceptados pueden dictar qué tipo de información se puede representar como una nota al pie, y los autores pueden desear recordar a los preparadores de estos estándares o dirigir a los lectores a dónde pueden obtener más información.

8.4.5      Extensibilidad

Si el sistema de informes está abierto, los autores deben incluir esta importante sección para indicar a los preparadores cómo pueden extender la taxonomía y en qué condiciones. Por ejemplo, ¿se les permite a los preparadores desarrollar sus propios conceptos personalizados en caso de que el concepto exacto que necesitan no esté disponible en la taxonomía? Si es así, ¿qué tipo de documentación de respaldo y etiquetas se requieren? ¿Se les permite a los preparadores crear sus propias dimensiones definidas por taxonomía para representar la nueva dimensionalidad? La extensibilidad también puede permitir a los preparadores crear sus propias presentaciones o incluso sus propios tipos de datos. Dependiendo de las restricciones establecidas por los desarrolladores de taxonomía, puede haber una gran cantidad de opciones para que los preparadores ajusten la taxonomía para abordar sus necesidades específicas de informes.

Debido a que la extensibilidad puede reducir la comparabilidad y la integridad de los datos, los autores deben proporcionar una guía clara sobre cómo y cuándo extender la taxonomía. Esta discusión debe adaptarse y ser específica a las formas en que se puede extender la taxonomía (es decir, agregar conceptos personalizados o crear nuevas presentaciones que agrupen conceptos preexistentes).

8.4.6      Formato de transporte y preparación de instancias

Este tema es de particular importancia para los preparadores. En esta sección, los autores deben proporcionar instrucciones muy claras sobre la creación del informe XBRL en sí. Esto debería incluir una discusión en profundidad de la taxonomía de formato de transporte que los desarrolladores han elegido, ya sea XBRL como XML, XBRL en línea, JSON o CSV. Alternativamente, es posible que no haya un requisito de que el informe XBRL se prepare en un tipo específico de formato. Esto también debe indicarse en esta sección. La plantilla proporcionada en el Apéndice F contiene descripciones repetitivas de cada uno de estos formatos en relación con XBRL.

Se debe discutir cualquier otra consideración al crear documentos de instancia XBRL con la taxonomía. Por ejemplo, si la situación de presentación de informes requiere documentos adicionales (como portadas u otra información expositiva que no se etiquetará con XBRL), esto debe explicarse. Si existen requisitos regulatorios y / o de otro tipo que impulsan la situación de los informes, es posible que los autores deseen explorar cómo esos requisitos afectan tanto el contenido como la estructura del informe XBRL. Si los informes se van a presentar en Inline XBRL, por ejemplo, ¿se les permite a los preparadores usar imágenes, hipervínculos y otros elementos HTML para explicar o embellecer aún más sus documentos? Preguntas y cuestiones como estas deben discutirse completamente para que los preparadores tengan muy claro lo que debe contener el informe y cómo se debe presentar esa información.

8.4.7      Validación

La validación de los datos incluidos en un informe XBRL es un paso extremadamente importante en el proceso de creación y generación de informes. Los autores deben enfatizar que los preparadores deben tener cuidado al validar la exactitud de la información que están reportando, y se deben proporcionar herramientas para guiar a los preparadores a través de este proceso. Según corresponda, deben cubrirse las siguientes secciones. Dependiendo de la disponibilidad y aceptación de software de terceros por parte de los desarrolladores de taxonomía, los autores también pueden desear dirigir a los preparadores a soluciones de software que implementen la validación de datos.

8.4.7.1   Calidad de los datos

La producción de datos de alta calidad es un objetivo clave en la implementación de una taxonomía de informes estructurados. Los autores deben indicar lo que define los datos de alta calidad para la industria o la situación de los informes (es decir, la exactitud de la información numérica, lo que debe proporcionarse en las secciones textuales y los estándares de precisión y exactitud empleados dentro de la taxonomía). Muy a menudo, los grupos de desarrollo de taxonomía y / o gobernanza pueden tener un comité de calidad de datos. Si corresponde, los autores deben explorar qué reglas tiene este comité y cómo acceder a ellas y seguirlas. Si hay demasiadas reglas o recomendaciones de calidad de datos para discutir individualmente, los autores deben dirigir a los preparadores a recursos externos para ayudarlos.

8.4.7.2   Requisitos reglamentarios (opcional)

Si el cumplimiento de los requisitos reglamentarios es una parte importante del propósito de la taxonomía, su influencia en la calidad y precisión de los datos debe discutirse aquí. Además, los autores deben asesorar a los preparadores sobre qué tipo de información puede ser necesaria para cumplir con algunos de esos requisitos. Una vez más, si los requisitos son demasiado numerosos o complicados de explicar en esta sección, los autores deben indicar a los lectores dónde pueden obtener más información.

8.4.7.3   Uso de tipos de datos y relaciones de concepto para validar hechos

XBRL tiene construcciones inherentes a él que ayudan a validar los datos. Los autores de la Guía del preparador deben asesorar a los preparadores de esas protecciones, como los tipos de datos y las relaciones conceptuales. Esto último se puede vincular a la discusión anterior de cálculos, fórmulas y definiciones, pero debe mencionarse aquí como una forma de validar los datos. Se debe recordar a los preparadores que XBRL solo define las relaciones; depende del preparador o de una solución de software verificar la precisión de los valores involucrados en la relación.

8.4.7.4   Comité de Calidad de Datos (Opcional)

Si corresponde, los autores deben discutir un comité de calidad de datos y cualquier negocio existente u otras reglas de validación que el comité (o cualquier grupo similar a él) produzca. Se debe explorar el razonamiento detrás de estas reglas, así como la forma en que se actualizan o amplían periódicamente. Según sea necesario o relevante, los autores también pueden indicar cómo se implementan estas reglas (a través de fórmulas XBRL, XULE o soluciones de software de propiedad, por ejemplo). Cualquier responsabilidad de validación que recaiga en los preparadores debe estar bien establecida y documentada.

8.4.8      El sistema de informes (opcional)

El paso final de la preparación de un informe XBRL probablemente radique en transmitir los datos XBRL en sí mismos y potencialmente enviar esos datos a los consumidores. Dependiendo del escenario de presentación de informes, el sistema de informes puede ser parte de un auditor interno de la empresa o de la industria, un regulador gubernamental o no gubernamental, o estar generalmente disponible para el público. Muy comúnmente habrá un sistema formal de presentación y / o difusión en su lugar. Los autores deben describir qué es este sistema y sus componentes. Si es apropiado, se puede proporcionar una guía paso a paso para usar el sistema.

8.4.9      Ejemplos

Este contenido puede incluirse como una sección propia o entrelazarse con otras secciones según corresponda. Si la taxonomía es compleja con muchas presentaciones y puntos de entrada, es posible que los autores deseen incluir ejemplos detallados de preparación de instancias XBRL. Por ejemplo, la taxonomía de informes financieros US GAAP tiene numerosos ejemplos que muestran la forma adecuada de codificar varias notas complejas a las finanzas en XBRL. Es posible que los autores deseen presentar sus ejemplos como guías paso a paso utilizando datos ficticios o disponibles públicamente. Una vez más, si hay un software de preparación proporcionado o aprobado, vincular el ejemplo a los procedimientos dentro del software (con capturas de pantalla de diálogos u otras imágenes) puede ser particularmente útil para los preparadores.

8.4.10    Escollos comunes y solución de problemas

En esta sección, los autores pueden cubrir algunos problemas comunes y cómo superarlos. Con cualquier proceso suficientemente complejo, puede haber muchos pasos que pueden plantear desafíos. Además, los preparadores pueden cometer algunos errores obvios. Por ejemplo, escalar incorrectamente los datos en Inline XBRL para que la información mostrada coincida con los valores correctos es un error muy común. Esta parte de la guía debe describir cómo evitar problemas como estos. Los temas cubiertos deben ser breves e instructivos, e idealmente deben derivarse de la experiencia del mundo real, la retroalimentación y los ejemplos con el proceso de tomar los datos actuales en el campo, formatearlos como XBRL, validarlos y transmitirlos.

8.4.11    Referencias y otros recursos

En esta sección final, los autores deben explicar qué referencias se utilizaron al escribir la Guía del preparador, que puede incluir la Guía de taxonomía de la taxonomía (si reside en un documento diferente), las especificaciones técnicas actuales de XBRL, así como los recursos y regulaciones específicos de la industria que son relevantes para la preparación del informe XBRL. Los autores también deben incluir formas de ponerse en contacto con los desarrolladores de taxonomía y los comités de gobernanza, según corresponda, para que los preparadores puedan recibir respuestas a comentarios, preguntas e inquietudes.

8.5         La Guía del consumidor de datos

La Guía del consumidor de datos presenta casos de uso comunes para los datos representados por la taxonomía. A menudo, este documento es parte de la propia Guía de Taxonomía, pero debe separarse si es lo suficientemente largo y complicado como para que la información no sea aplicable tanto a las audiencias de desarrollo como a las de consumidores de datos.

8.5.1      Metas

Esta sección describe claramente los objetivos generales de la Guía del consumidor de datos para los lectores. Además, los autores deben describir el público objetivo de la Guía del consumidor de datos y pueden indicar el nivel de familiaridad que estos lectores deben tener con los datos en cuestión. Por ejemplo, para una taxonomía de informes financieros, los lectores objetivo de la Guía del consumidor de datos pueden ser reguladores, analistas de inversiones, proveedores de bases de datos y otros profesionales financieros que estén familiarizados con las normas de contabilidad US GAAP.

8.5.1.1   Historial de revisiones

Los autores deben mencionar que el documento está sujeto a revisión periódica además de describir su historial de revisiones. El proceso de gobernanza debe describirse brevemente en lo que respecta a las actualizaciones de taxonomía y documentación para que los lectores sean conscientes de que se pueden realizar cambios y cómo se implementarán esos cambios.

8.5.2      Por qué los casos de uso son importantes

Los autores deben utilizar esta sección para definir casos de uso en términos amplios y explicar su utilidad en el análisis de datos, así como su relación con la taxonomía. Se proporciona una descripción general en la plantilla Guía del consumidor de datos en el Apéndice G. Los tipos de casos de uso que se cubrirán en el documento se pueden mencionar y describir brevemente.

8.5.3      Introducción a la taxonomía y una visión general de XBRL

Los autores deben comenzar por introducir la taxonomía y su propósito a un nivel muy alto. Los lectores deben ser conscientes de por qué existe la taxonomía, los tipos de datos que debe representar y su lugar a lo largo de la cadena de suministro de información para la industria o los sectores comerciales para los que se ha desarrollado. Además, en la Guía del consumidor de datos debe haber una breve descripción de las regulaciones y requisitos que influyeron en cómo se diseñó la taxonomía para representar los datos. Estas regulaciones pueden no necesariamente alinearse con el caso de uso en el que el lector está interesado, pero son importantes para comprender el propósito de la taxonomía. La discusión también puede presentar una exploración y posiblemente una representación gráfica de la cadena de suministro de datos específica de esta taxonomía.

Los autores deben incluir la Descripción general de XBRL (Apéndice D), para la cual XBRL US ha proporcionado una plantilla preconstruida. Esta sección debe proporcionar una introducción básica sobre XBRL para que los lectores que no están familiarizados con el estándar puedan ponerse al día rápidamente con sus construcciones y usos básicos.

8.5.4      Revisión de la taxonomía

Esta sección de la Guía del consumidor de datos proporciona un tutorial de la estructura y el contenido de la taxonomía.

8.5.4.1   Taxonomía Estructura física

Con el modelo de datos de transporte entendido por los lectores, esta sección puede articular cómo la taxonomía representa ese modelo. Debido a que este tema es tan importante, los autores deben tener cuidado de asegurarse de que sus explicaciones de las razones detrás de las opciones de diseño de la taxonomía sean claras.

Utilizando tanto diagramas como texto, la sección debe describir la estructura de la taxonomía en detalle, incluidos los grupos de conceptos y las jerarquías. Los autores pueden describir por qué se crearon estas agrupaciones, qué están diseñadas para capturar y quién es el público objetivo para los diversos puntos de entrada y presentaciones. Esta información puede ser de gran interés para los consumidores de datos, especialmente si las presentaciones y los puntos de entrada están diseñados para agrupar datos relevantes para ciertos casos de uso.

Al igual que con la mayoría de los aspectos de la documentación, el tamaño y el alcance de la taxonomía deben dictar el nivel de detalle y explicación requerido para garantizar la comprensión. Las taxonomías grandes, como la Taxonomía del Botón Naranja, que tiene más de 4,000 conceptos, pueden necesitar ser explicadas agrupando el contenido en «secciones» lógicas y proporcionando una revisión en profundidad de cada sección. Las secciones lógicas pueden ser puntos de entrada, presentaciones, tablas o incluso conceptos abstractos si esta agrupación es lo suficientemente compleja como para merecer más detalles. Las taxonomías más pequeñas, como la Taxonomía de Trabajo en Proceso de Caución, que tiene aproximadamente 60 conceptos, pueden manejarse de manera diferente. En una taxonomía más pequeña, los autores pueden dedicar más tiempo a descripciones detalladas de cada categoría de datos, describiendo el significado de los conceptos y cómo funcionan dentro del número limitado de tablas.

8.5.4.2   Concepto

Esta sección debe abordar los conceptos de la taxonomía y cómo se relacionan con la información común en el campo, la industria o el sector empresarial. Dependiendo del tamaño y el alcance de la taxonomía, la discusión podría ser profunda o superficial. La relación que tienen los conceptos con los puntos de entrada, las presentaciones y los documentos o bases de datos de origen debe explorarse según sea necesario. Los autores deben explicar cómo algunos conceptos están destinados a ser dimensiones centrales del concepto (que se relacionan directamente con el hecho y dictan las propiedades del hecho) y cómo otros conceptos son abstractos y están destinados a agrupar y dimensionalizar datos. Al igual que con otras secciones de la Guía del consumidor de datos, los autores deben agrupar el contenido para explicar la información más relevante sin texto redundante.

8.5.4.3   Dimensiones

La dimensionalidad de las tablas dentro de cada sección de la taxonomía debe describirse en detalle, incluidas las dimensiones centrales (unidades permitidas, entidades, etc.) y cómo usar las dimensiones definidas por la taxonomía que componen la tabla. Comprender la dimensionalidad de los datos dentro de la taxonomía es importante cuando se traduce el modelo de transporte de la taxonomía a modelos de consumo de datos. ¿Cómo se relacionan las dimensiones definidas por la taxonomía con las dimensiones de datos en el caso de uso? ¿Cómo coinciden las dimensiones centrales del concepto con los puntos de datos en el modelo de consumo? Estas relaciones son esenciales para interpretar útilmente la taxonomía.

Una vez más, el tamaño de esta sección depende de la complejidad y el alcance de la taxonomía. Para una taxonomía muy grande, si muchas de las tablas contienen estructuras dimensionales similares, se puede explicar una tabla ejemplar con mayor detalle para ilustrar la estructura con una discusión más breve sobre cómo esta estructura se aplica en otros lugares. Las tablas también se pueden agrupar en la discusión si representan datos y dimensionalidad similares. El objetivo es, como siempre, explicar la información relevante con el menor material duplicado o redundante posible.

8.5.4.4   Cálculos (opcional)

Si la taxonomía contiene cálculos, esta sección debe incluir una breve explicación de las relaciones de cálculo entre conceptos.

8.5.4.5   Fórmulas (opcional)

Si la taxonomía contiene fórmulas, esta sección debe incluir una breve explicación de las relaciones de fórmula entre conceptos.

8.5.4.6   Tipos de datos y unidades

La Guía del consumidor de datos debe incluir una lista de los tipos de datos estándar utilizados (por ejemplo, cadena, monetario, booleano, etc.) y cualquier tipo de datos no estándar o personalizado. Los tipos de datos no estándar y personalizados son particularmente importantes de describir, ya que no es probable que se incluyan automáticamente en un modelo de consumo de datos o software de análisis.

Los autores también deben discutir las dimensiones centrales de la unidad y el contexto matemático, científico o financiero que confieren a los datos.

8.5.4.7   Validación y medición de la integridad de los datos

Las reglas y procedimientos de validación brindan una oportunidad para que el consumidor tenga un mayor nivel de confianza en los datos entrantes. Si se han desarrollado modelos de validación estándar para la taxonomía, los autores deben discutirlos aquí.

8.5.5      Extracción de datos de un informe XBRL

Los autores pueden usar esta sección para explorar la mecánica de recopilación de datos de un informe XBRL, lo que los consumidores deben hacer para analizar e interpretar esos datos en sus casos de uso. Según corresponda, los autores tal vez deseen describir los métodos para extraer la información de los documentos de instancia. Esto puede involucrar paquetes de software propietarios de terceros que pueden ser personalizados para transferir datos de documentos XBRL a sistemas de análisis.

8.5.5.1   Formato de transporte

Los autores deben proporcionar una descripción de los datos de formato de transporte que los consumidores encontrarán en los informes XBRL, ya sea XBRL como XML, XBRL en línea, JSON o CSV. La plantilla proporcionada en el Apéndice G contiene descripciones repetitivas de cada uno de estos formatos en relación con XBRL.

8.5.5.2   Herramientas de software de datos y otros sistemas de apoyo

En esta sección, los autores pueden describir el sistema de informes en lo que respecta a dónde se almacenarán los informes XBRL generados con la taxonomía y cómo se puede acceder a ellos. Por ejemplo, ¿la información estará disponible públicamente? Si no es así, ¿qué tipo de credenciales serán necesarias para acceder a él? ¿Se almacenarán varios informes XBRL en un único repositorio y cómo se puede obtener esa información? ¿Cómo se organiza la información?

Los autores deben revisar cualquier herramienta y sistema de software que pueda ayudar a los consumidores a extraer y analizar datos XBRL. Estos sistemas pueden ser propietarios o estar disponibles a través de proveedores de software de terceros. Si una solución de software no está específicamente respaldada por los desarrolladores de taxonomía y / o grupos de gobierno, los autores deben tener cuidado al discutirla.

En particular, es posible que los autores deseen cubrir la API XBRL, que está disponible gratuitamente en XBRL US. Como se describe brevemente en la Sección 1.4.3, la API XBRL ofrece una interfaz de programación que puede conectar un backend de base de datos con un frontend de recopilación/análisis de datos (como una interfaz web) para permitir a los usuarios crear sus propias bases de datos con información XBRL de un repositorio. Se puede advertir a los consumidores de datos que pueden usar esta API para crear su propio sistema de recopilación de datos XBRL si actualmente no existe uno.

8.5.6      Casos de uso comunes

Esto debe comprender la mayor parte de la Guía del consumidor de datos, y el contenido variará ampliamente dependiendo de la taxonomía y la industria en sí. Los autores querrán crear secciones separadas para cada caso de uso que deseen describir. Obviamente, esta lista de casos de uso no puede ser exhaustiva; los autores deben decidir qué casos de uso son los más comunes y/o más importantes para que los consumidores los entiendan en detalle.

Para cada caso de uso, los autores pueden comenzar describiendo el objetivo del caso de uso. Los objetivos de casos de uso de ejemplo pueden ser comparar la producción de widgets entre empresas competidoras o generar datos agregados sobre los activos de las empresas mineras en toda la industria minera. Cualquiera que sea el objetivo del caso de uso, los autores deben describirlo en detalle. Después, los autores deben indicar cómo la taxonomía representa los datos relevantes para ese objetivo. Para algunos casos de uso, particularmente aquellos que la taxonomía puede haber sido diseñada para apoyar, esta discusión puede ser larga, ya que una gran cantidad de los datos (y por lo tanto la taxonomía) pueden estar involucrados en el caso de uso. Para otros, la situación puede ser más simple y limitarse a un solo punto de entrada, presentación o tabla.

Independientemente del alcance de la discusión, los autores deben explicar cómo los conceptos y las dimensiones definidas por la taxonomía se asignan a los datos necesarios para el caso de uso. Usando el ejemplo de widget nuevamente, si el caso de uso implica monitorear la producción de widgets para un trimestre específico, la guía puede indicar qué conceptos y dimensiones son necesarios para extraer esos datos de la taxonomía. Los casos de uso más complejos pueden requerir una discusión significativa para que los lectores entiendan este paso clave.

8.5.7.     Consideraciones especiales y extensibilidad (opcional)

Si hay alguna consideración especial con respecto a la recopilación de los datos de la taxonomía, también debe discutirse como relevante para cada caso de uso. Por ejemplo, si el sistema de informes permite la extensibilidad, puede haber conceptos, dimensiones y tipos de datos personalizados involucrados en los informes XBRL, y estos pueden variar de un preparador a otro. Es posible que los autores deseen proporcionar orientación a los consumidores sobre cómo manejar estas situaciones.

8.5.8      Referencias y otros recursos

En esta sección final, los autores deben explicar qué referencias se utilizaron al escribir la Guía del consumidor de datos, que puede incluir la Guía de taxonomía de la taxonomía (si reside en un documento diferente), las especificaciones técnicas actuales de XBRL, así como los recursos y regulaciones específicos de la industria que son relevantes para el consumo de datos XBRL. Los autores también deben incluir formas de ponerse en contacto con los desarrolladores de taxonomía y comités de gobernanza, según corresponda, para que los consumidores de datos puedan recibir respuestas a comentarios, preguntas e inquietudes.

8.6         Actualizaciones y notas de la versión

Cuando se publica la taxonomía y luego se actualiza, la información sobre los cambios debe documentarse y difundirse a través de revisiones y notas de la versión. Las notas de la versión son generalmente concisas y escritas para una audiencia técnica. Para la versión inicial, estas notas pueden describir el propósito general y la estructura de la taxonomía, lo que podría enviar a los lectores a la Guía de taxonomía u otras especificaciones XBRL según sea necesario. Para las revisiones posteriores, las notas de la versión deben cubrir completamente el cambio (que puede ser una adición, alteración o eliminación de construcciones taxonómicas o una nueva interpretación de los elementos de la taxonomía), explicando potencialmente el razonamiento detrás del cambio y aconsejando a los usuarios de otras consideraciones relevantes según sea necesario. Si el cambio es impulsado por regulaciones nuevas o diferentes o por modificaciones de otro órgano rector, las notas de liberación deben citar directamente la razón de cada cambio.

Cualquier versión beta o preliminar de la taxonomía también debe contener notas de la versión. Puede encontrar más información sobre cómo estructurar y publicar cambios en una taxonomía en el Capítulo 9.

9             Gobernanza de la taxonomía

Al igual que con cualquier proyecto, el ciclo de vida y el flujo de trabajo de una taxonomía incluirán naturalmente el desarrollo, la implementación y, finalmente, la revisión y el soporte. Estos aspectos posteriores del ciclo de vida a veces se investigan o enfatizan menos, pero pueden ser de vital importancia para el éxito de cualquier proyecto, incluida una taxonomía XBRL. Este capítulo ofrece algunos métodos de supervisión y gestión para guiar todo el proceso de desarrollo, implementación y mantenimiento de la taxonomía. Estas son solo sugerencias; los desarrolladores y otros administradores deben crear e instalar una estructura de administración que tenga sentido para ellos.

El gobierno de la taxonomía se refiere a las políticas, los procesos y la documentación necesarios para administrar las taxonomías, no solo en la etapa de construcción inicial, sino también a lo largo del soporte y mantenimiento continuos. Una taxonomía rara vez está «terminada» porque los requisitos de informes regulatorios, las necesidades de la industria y la empresa, y las tecnologías del mercado cambian continuamente. La taxonomía debe evolucionar para satisfacer las necesidades del dominio de presentación de informes y adoptar nuevas tecnologías que puedan ofrecer mejoras a la cadena de suministro de información.

El objetivo general de la gobernanza de la taxonomía es establecer un proceso repetible y predecible para gestionar los cambios en la taxonomía de una manera que sea responsable y transparente para todas las partes interesadas. Este capítulo describe brevemente el ciclo de desarrollo de una taxonomía. También describe el equipo de personal que podría participar en las tareas de gobernanza, así como sus funciones y responsabilidades. Vale la pena mencionar nuevamente que el tamaño y el alcance de la gobernanza y los grupos involucrados en ella deben ser dictados por el tamaño y el alcance del propio proyecto de taxonomía. Para una taxonomía grande y compleja con múltiples partes interesadas en la regulación, la gobernanza puede requerir muchas personas diferentes con diferentes experiencias. Para una taxonomía pequeña con una cadena de suministro de información más contenida, los propios desarrolladores de taxonomía pueden ser todo lo que se necesita para mantener una gobernanza sólida.

9,1         El ciclo de vida de la taxonomía

Como la mayoría de los sistemas estructurados, las taxonomías tienen un ciclo de vida general: construcción, piloto, implementación y soporte y mantenimiento. La estructura de gobierno y los objetivos deben adaptarse a la etapa de desarrollo y mantenimiento de la taxonomía (Figura 9-1).

Tenga en cuenta que estas fases se corresponden con el diagrama de flujo de trabajo de desarrollo representado en la Figura 7-1. Los ciclos de desarrollo y revisión de ese diagrama coinciden con las fases enumeradas en este capítulo. Las siguientes secciones describen los objetivos de cada fase y los tipos de estructuras de gobierno necesarias para alcanzarlos.

9.1.1      Fase 1 – Construcción

La mayor parte de este manual se ha centrado hasta ahora en la fase de construcción, que obviamente se centra en definir los objetivos del proyecto, los requisitos de la taxonomía, construir y validar el modelo de transporte de datos XBRL y documentar los resultados. El objetivo de la fase de construcción es producir una taxonomía piloto para su revisión pública. Durante esta construcción inicial de la taxonomía, la gobernanza debe proporcionar supervisión para definir roles, documentar la taxonomía, preparar informes y casos de uso. También debe guiar la practicidad y el valor de la taxonomía para aquellos involucrados en la industria o la cadena de suministro de información, así como ayudar a identificar métricas de éxito. Los tipos de órganos rectores y personal que suelen participar se describen a continuación, con un ejemplo de estructura de gobierno que aparece en la Figura 9-2.

9.1.1.1   El Patrocinador

El patrocinador de la taxonomía defiende el proyecto de desarrollo. Para grandes taxonomías con un amplio impacto en la cadena de suministro de información, un regulador, una organización de estándares o un organismo de la industria sin fines de lucro pueden actuar como patrocinadores para reunir a las partes interesadas con éxito. En estos casos, las entidades comerciales generalmente no asumen este papel porque sus propios intereses financieros o comerciales pueden entrar en conflicto con las necesidades de otras partes interesadas y pueden causar obstáculos a la colaboración competitiva. Sin embargo, un grupo de empresas con un interés común podría unirse en una alianza y actuar como patrocinador.

En situaciones de informes más pequeñas y contenidas, el patrocinador de la taxonomía puede estar dentro de la estructura de gestión de una empresa. Una vez más, el tamaño del proyecto dicta el nivel de supervisión necesario.

9.1.1.2   El Grupo de Trabajo

Todas las partes interesadas deben estar representadas en el grupo de trabajo de taxonomía. Esto puede incluir preparadores, intermediarios de datos y consumidores de datos, así como proveedores de software y bases de datos y expertos técnicos y en la materia. Los propios desarrolladores también deberían formar parte de este grupo. Se pedirá al grupo de trabajo que realice las tareas de elaboración de los resultados de la taxonomía. Incluso en entornos pequeños, el grupo de trabajo probablemente comprenderá a más de una persona, y la colaboración entre todas las partes necesarias para diseñar, desarrollar y entregar la taxonomía es esencial.

En la práctica, los miembros del grupo de trabajo pueden trabajar de forma independiente en las secciones de la taxonomía, pero el grupo de trabajo completo de taxonomía debe reunirse periódicamente para evaluar el progreso del desarrollo e informar a los órganos de supervisión, incluido el comité directivo.

9.1.1.3  El Comité Directivo de Taxonomía

Por lo general, dirigido por el patrocinador, un comité directivo de taxonomía evalúa los principales hitos, revisa y aprueba los entregables, y sirve como «desempate» en las principales decisiones relacionadas con la taxonomía. Este es el órgano que proporciona la principal supervisión del proceso de desarrollo. El comité directivo de taxonomía generalmente puede reunirse con menos frecuencia. Al igual que el grupo de trabajo, debe estar compuesto por expertos técnicos y en la materia que representen a las diversas partes interesadas en el proyecto. Los reguladores, legisladores y expertos de la industria también pueden servir como observadores importantes para garantizar que los requisitos legislativos y los objetivos regulatorios se implementen correctamente.

En situaciones de presentación de informes pequeños, un comité directivo de taxonomía puede no ser necesario, ya que las funciones en este grupo pueden ser redundantes con el grupo de trabajo de taxonomía.

9.1.1.4   Gerente de Taxonomías

El administrador de taxonomía mantiene un conocimiento detallado de la taxonomía y del proyecto en su conjunto y proporciona apoyo diario al personal para el grupo de trabajo de taxonomía. El administrador de taxonomía también recibe, revisa y clasifica los comentarios presentados y las solicitudes de cambio, evalúa el impacto de estas solicitudes e informa al grupo de trabajo de taxonomía y al comité directivo. Este individuo también se coordina con reguladores, organizaciones de la industria y expertos en calidad de datos, si están involucrados.

Además de estas responsabilidades, el administrador de taxonomía acusa recibo de todos los comentarios a los remitentes y mantiene y publica todos los registros relacionados con las solicitudes de cambio. Esta persona también implementa y prueba los cambios aprobados, realiza pruebas de versiones y publicación, coordina la aprobación de todos los cambios propuestos y supervisa todas las tareas involucradas.

Se deben evaluar todos los aspectos de la taxonomía, incluido qué tan bien sirve el formato de transporte en los documentos de instancia. El grupo de trabajo debe garantizar que los desarrolladores, los evaluadores y el personal de control de calidad tengan las herramientas necesarias (software, documentos de muestra y conjuntos de datos) para completar estas pruebas. Las revisiones internas deben ser documentadas y supervisadas por el administrador de taxonomía.

En este punto, otro grupo de gobierno, el comité de calidad de datos, puede ser necesario. Los comités de calidad de los datos se han discutido anteriormente, particularmente en el Capítulo 6. Este grupo, probablemente compuesto por expertos en datos y de la industria, supervisa el establecimiento de reglas de calidad de datos para la taxonomía. En colaboración con el grupo de trabajo sobre taxonomía, deberían elaborarse puntos de referencia sobre la integridad de los datos. Pueden ser una mezcla de reglas de cumplimiento normativo y preceptos particulares para datos precisos, dependiendo de la taxonomía. Estas reglas suelen estar en capas sobre la validación inherente de XBRL. Se debe tener cuidado de incorporar reglas de calidad de datos tanto en la documentación como en los sistemas y software de soporte/presentación de informes. Tenga en cuenta que, aunque garantizar la calidad de los datos es un paso clave en el proceso de desarrollo de la taxonomía, es posible que no sea necesario un comité de calidad de datos separado en entornos de informes pequeños.

Una vez que este período de prueba interna haya terminado y la taxonomía piloto tenga sus principales problemas y deficiencias resueltos, la taxonomía candidata / piloto puede ser publicada para su revisión pública. Una vez más, la amplitud de «público» varía ampliamente dependiendo del tamaño y el alcance de la taxonomía en sí y la cadena de suministro de información. La duración del período de examen también debe estar dictada por la necesidad de comentarios públicos. La exposición externa es un paso importante, en primer lugar, para garantizar que la taxonomía realmente satisfaga las necesidades de las partes interesadas a las que sirve, y en segundo lugar, para aumentar el esfuerzo de adopción. Estos dos objetivos suelen ir de la mano para un gran panorama de informes.

Esta será la primera oportunidad que muchos usuarios de taxonomía podrán evaluar, estudiar, probar y «jugar» con la taxonomía. A pesar de todos los mejores esfuerzos, es muy poco probable, especialmente si la taxonomía es grande y está diseñada para cubrir múltiples casos de uso, que sea perfecta para todas las partes interesadas y aplicaciones. También puede haber «errores» persistentes en la taxonomía que no se detectaron durante las primeras rondas de revisión, como inconsistencia de las etiquetas o incluso errores tipográficos. Es importante contar con un proceso para capturar las adiciones y revisiones necesarias a la taxonomía, así como los errores, a medida que las personas comienzan a usarla.

Después de la revisión pública, los comentarios recibidos deben ser evaluados por el administrador de taxonomía. Se pueden incorporar correcciones (se recomienda la versión y el software de seguimiento de la fuente). Una vez que el grupo de trabajo de taxonomía y el comité directivo están convencidos de que se han implementado y validado los cambios necesarios, la taxonomía candidata se convierte en un borrador de taxonomía y puede pasar a la siguiente etapa de su ciclo de vida: la implementación.

9.1.3      Fase 3 – Implementación

Una vez que se completa la revisión (pública o interna, según corresponda), se incorporan todos los cambios apropiados y se publica la versión inicial, el borrador de la taxonomía pasa a la fase de implementación y se convierte en una taxonomía publicada formalmente.

Como la mayor parte del diseño, desarrollo y pruebas se ha terminado, el grupo de trabajo de taxonomía y el comité directivo de taxonomía se pueden consolidar y racionalizar en un comité de taxonomía. Este comité puede comenzar a centrarse en el éxito a largo plazo de la taxonomía. En consecuencia, gran parte de la gobernanza en la fase de implementación se refiere a garantizar que el despliegue sea fluido y que haya soporte disponible para los adoptantes. Se debe determinar un cronograma de implementación al principio de la fase de implementación. Este cronograma debe anticipar las necesidades de la comunidad informante y entregar recursos de una manera lógica. Si el software de soporte es necesario y está en desarrollo, pero aún no está listo, ¿pueden los usuarios acceder a la taxonomía sin él? Por el contrario, ¿debería retrasarse la versión de la taxonomía hasta que el software y la taxonomía puedan publicarse como un paquete?

La fase de implementación también brinda la oportunidad de continuar evaluando el sistema en su totalidad: la taxonomía, el software de soporte, los sistemas de informes, la documentación y la educación. Las expectativas de la comunidad informante deben abordarse como parte de las iniciativas de adopción y educación. Incluso el régimen de pruebas más robusto no puede anticipar todas las dificultades, especialmente cuando una implementación es grande y compleja con múltiples tipos de usuarios que interactúan con un sistema. La estructura de gobernanza debe estar preparada para adaptarse rápidamente a las situaciones de emergencia. Si procede, los órganos de gobernanza, en particular el administrador de taxonomía, tal vez deseen desarrollar formas fáciles para que los adoptantes (en particular los preparadores) interactúen con documentación útil y apoyo técnico, así como seguir permitiendo que estos usuarios proporcionen comentarios. Solicitar activamente la opinión de los primeros usuarios ayuda a garantizar que permanezcan positivamente comprometidos en el trabajo con los desarrolladores y la mejora de la taxonomía.

Además, la adopción no es un concepto de «todo o nada». Los comités de gobernanza deben tener en cuenta un nivel de adopción aceptable en la métrica del éxito. En algunas situaciones de denuncia, la adopción puede no ser opcional. En otros, particularmente con grandes taxonomías que afectan a muchos preparadores, un método escalonado de adopción puede ser beneficioso.

9.1.4      Fase 4 – Soporte y mantenimiento

Una vez que se ha adoptado la taxonomía, se debe establecer un programa integral de soporte y mantenimiento. El objetivo de esta fase de soporte y mantenimiento es establecer un ciclo de soporte a largo plazo (Figura 7-1), que implica un vehículo para recibir y reaccionar a los cambios solicitados y requeridos, determinar categorías de cambio (alto versus bajo impacto, y quién tiene autoridad para diferentes tipos de cambios) y crear un proceso de implementación de revisión (taxonomía candidata inicial revisada a un borrador de taxonomía y luego publicada como taxonomía final). Se debe tener cuidado de minimizar el número de nuevas versiones y garantizar que sean sustanciales o importantes, ya que cada una puede requerir que los proveedores de software realicen ajustes. El comité de taxonomía debe establecer un proceso para revisar y publicar actualizaciones de taxonomía, incluida la forma en que se anunciarán, implementarán y probarán esas revisiones.

Al evaluar los cambios, es importante que el comité de taxonomía considere su necesidad e impacto. Naturalmente, si la taxonomía incluye requisitos reglamentarios, los cambios en los requisitos requerirán alteraciones proporcionales a la taxonomía. De lo contrario, el comité de taxonomía debe sopesar la ganancia frente a la carga de cada cambio. Algunos cambios, como la corrección de etiquetas conceptuales o la reestructuración de relaciones, pueden no requerir mucha implementación. Otros pueden tener repercusiones más graves. Los cambios que tendrán el mayor impacto y pueden afectar a los documentos de instancia que ya se han preparado incluyen:

Una de las mayores ventajas de XBRL es su extensibilidad. Esto permite que la taxonomía evolucione con los cambiantes requisitos y entornos de informes. El comité de taxonomía puede evaluar periódicamente los objetivos de la taxonomía en comparación con los estándares de informes actuales para la industria y los de industrias similares. Puede haber mejoras que se pueden hacer. En caso de que sea necesario un trabajo de desarrollo sustancial, el comité de taxonomía puede reformar un grupo de trabajo para explorar y potencialmente crear nuevas soluciones de presentación de informes.

10          Historias de éxito

El estándar de datos XBRL se ha implementado de manera efectiva en todo el mundo, lo que resulta en ahorros de costos, mayor responsabilidad y mayor eficiencia. A continuación, se presentan algunos estudios de casos breves para demostrar estos éxitos.

10.1       Banca en los Estados Unidos

El Consejo Federal de Examen de Instituciones Financieras (FFIEC) coordina las actividades regulatorias de la Reserva Federal de los Estados Unidos, la Comisión Federal de Depósitos de Seguros (FDIC) y la Oficina del Contralor de la Moneda (OCC). Las instituciones bancarias están obligadas a reportar información financiera al FFIEC en formularios estandarizados llamados «informes de llamadas». Los informes de llamadas, que deben presentarse a más tardar treinta días después del final del trimestre, contienen datos financieros importantes, incluido el estado de resultados del banco, el balance general, la información sobre préstamos, depósitos e inversiones, los cambios en el capital del banco y la información de venta de activos. Los informes son examinados por analistas federales en busca de errores y cualquier otro problema relacionado con la auditoría. Los datos de informes de llamadas son una fuente crítica de información sobre la industria bancaria y son utilizados por las agencias reguladoras bancarias para monitorear las actividades bancarias. También es utilizado por el público, el Congreso, las autoridades bancarias estatales, los investigadores, las agencias de calificación, los inversores y la academia. La FDIC es responsable de mantener una base de datos de informes de llamadas precisa y actualizada.

Los informes de llamadas, como se muestra en la Figura 10-1, están altamente estructurados, con los datos requeridos bien definidos. Desde 1998, los bancos han tenido que presentar los datos de los informes de llamadas electrónicamente a las Agencias de Llamadas de FFIEC. Todos los bancos deben comprar uno de los nueve paquetes de software de proveedores aprobados para preparar sus datos de informes de llamadas.

10.1.1    Antes de los estándares de datos: sistema heredado

Antes de que se estandarizaran los informes de llamadas, las instrucciones y los requisitos técnicos sobre cómo preparar el informe de llamadas se distribuían a través de una colección de documentos PDF, Microsoft Word y Microsoft Excel.

La manipulación manual por parte de los proveedores de programas informáticos y las instituciones financieras era necesaria para utilizar la información sobre los requisitos proporcionada.

Un proveedor del sector privado recopiló los datos y los puso a disposición de las agencias de FFIEC para que los procesaran. El Sistema de la Reserva Federal y la FDIC revisaron y realizaron comprobaciones de validación para detectar errores matemáticos y de calidad. Las excepciones fueron resueltas por el personal de FFIEC contactando a los encuestados del banco por teléfono e ingresando manualmente las correcciones. En algunos casos, se exigió a los bancos que corrigieran y volvieran a enviar los datos.

El proceso heredado no era flexible ni escalable, implicaba el uso de múltiples formatos de archivo, requería preparación y validación manuales, y era laborioso, propenso a errores y lento. Las mejoras en el sistema y los cambios en los requisitos de presentación de informes también se completaron poco a poco, creando un sistema que se beneficiaría de la presentación de informes estructurados.

10.1.2    Incorporación de estándares de datos

Los reguladores bancarios aprovecharon ciertos factores de los sistemas heredados para construir el nuevo sistema modernizado. En primer lugar, estos reguladores trabajaron en estrecha colaboración con los proveedores de software de informes de llamadas existentes para revisar sus aplicaciones y generar datos estandarizados de informes de llamadas. Debido a la naturaleza estructurada de los datos estandarizados, pudieron incorporar comprobaciones de error y calidad de los datos en el software para que los bancos pudieran editar y tener confianza en sus datos antes de la presentación. La validación mejoró la puntualidad y la calidad de los informes y redujo la necesidad de una investigación manual por parte del personal del banco. En segundo lugar, debido a la naturaleza altamente estructurada y «basada en formularios» de los datos reportados, los reguladores podrían implementar un sistema cerrado de informes que no permitiera extensiones.

Los proveedores de software de preparación de informes de llamadas ya eran una parte crítica del entorno de informes, por lo que, naturalmente, trabajar con estos proveedores durante el proceso de desarrollo de la taxonomía durante una serie de mesas redondas (dirigidas por los reguladores bancarios) fue importante para construir un proceso de informes y recopilación de datos que funcionara para todas las partes interesadas: reguladores, proveedores de software, preparadores y consumidores de datos. Los preparadores utilizaron las mismas aplicaciones de software que siempre habían utilizado como interfaz a través de la cual accedían a la taxonomía para determinar qué información informar y completar. Esto significaba que no había una curva de aprendizaje significativa para los preparadores; simplemente estaban replicando un proceso existente. Por lo tanto, no hubo interrupción en el proceso para los miles de bancos que están obligados a presentar informes de llamadas.

10.1.4   Conclusiones

La historia de éxito de XBRL en la presentación de informes financieros bancarios representa una situación en la que el régimen actual de presentación de informes influyó en gran medida en el desarrollo y la implementación de la taxonomía XBRL. Debido a que los proveedores de software ya estaban involucrados en el proceso de generación de informes, involucrarlos durante el desarrollo produjo un resultado valioso para los preparadores: poder continuar utilizando el front-end de los sistemas existentes para desarrollar informes sin tener que aprender las complejidades del nuevo back-end (XBRL). Además, involucrar a los desarrolladores de esta manera les permite comprender e implementar completamente la taxonomía según corresponda. Además, la extensibilidad de la taxonomía y del sistema de presentación de informes debe ser claramente limitada; El rígido entorno de informes dicta esta elección de diseño. La estructura de los datos proporcionados por los preparadores está muy bien definida, sin necesidad de personalización.

Para obtener más información, vea Proceso de negocio mejorado a través de XBRL: un caso de uso para informes empresariales:

10.2       Informes de empresa a gobierno

En muchos países, XBRL se ha implementado para estandarizar los informes financieros comerciales al tiempo que reduce la carga del preparador. Australia, los Países Bajos, Finlandia y Ucrania han desarrollado programas basados en el estándar XBRL llamado Standard Business Reporting (SBR) que armoniza las definiciones utilizadas en la presentación de informes, reduciendo el costo de obtener información en diferentes agencias gubernamentales. Los hechos reportados en SBR son legibles por máquina, consistentes, claramente definidos y acordados por todos los miembros de la cadena de suministro. Como resultado, la información es inequívoca para el preparador, los reguladores y otros usuarios de los datos.

10.2.1    Cómo funciona SBR en Australia

En 2010, Australia implementó un programa SBR. Hoy en día, nueve agencias gubernamentales confían en SBR para obtener información financiera de entidades reguladas, lo que significa que existe un estándar de informes uniforme en todos estos grupos regulatorios. Las entidades informantes deben utilizar una de las varias herramientas de software aprobadas que pueden generar datos con formato XBRL. El gobierno proporciona recursos a los desarrolladores de software que desean certificarse como «habilitados para SBR». Las empresas que utilizan software habilitado para SBR pueden informar utilizando información ya registrada como parte de la gestión de su negocio.

Cuando se requiere un informe, el software habilitado para SBR sabe qué información se necesita para ese informe y completa las divulgaciones necesarias. Estos paquetes de software habilitados para SBR les dicen a los preparadores lo que necesitan informar aprovechando la taxonomía XBRL proporcionada por el gobierno. El software también utiliza reglas específicas de la agencia para validar los informes de errores antes de enviarlos a las agencias gubernamentales. Una vez que se envían los datos, se ponen a disposición de las agencias gubernamentales participantes. Las empresas ya no necesitan reportar información a múltiples agencias a través de diferentes formularios o portales.

10.2.1.1 La taxonomía SBR AU

El programa SBR se basa en la Taxonomía SBR AU, una colección de conceptos de datos que pueden ser requeridos para ser reportados por las empresas a las agencias gubernamentales. La Taxonomía SBR AU es un estándar reconocido en el Marco de Estándares Nacionales de Australia para la interacción entre agencias. Los elementos de datos acordados y sus definiciones asociadas se utilizan en la creación de informes legibles por máquina para ser presentados por una empresa a las agencias que utilizan SBR. Los elementos de datos se definen una vez y se reutilizan en múltiples formularios y múltiples agencias.

Al desarrollar la taxonomía, cada agencia SBR identificó y definió los elementos de datos requeridos para sus formularios en el alcance. Los puntos de datos se sometieron a un proceso para acordar el conjunto mínimo para la taxonomía SBR AU, y los puntos de datos se identificaron y nombraron de forma única como conceptos XBRL. Las duplicaciones se consolidaron bajo un solo nombre.

10.2.1.2 Gobernanza

La actualización de los elementos de datos existentes o la adición de nuevos se basa en un proceso de cambio y gobierno de SBR para su aprobación por todas las agencias de SBR. El programa es administrado por la Junta del Registro Mercantil Australiano (ABR), que proporciona una amplia supervisión estratégica del programa SBR junto con su papel más amplio en el avance del ABR como la fuente de información comercial registrada para el gobierno y las empresas. Los miembros de la ABR incluyen representantes de alto nivel de cada una de las agencias involucradas en el programa, tres representantes de los estados y territorios, un representante del gobierno local y cuatro representantes comerciales, incluidos los proveedores de servicios digitales. El Grupo Directivo de SBR guía el desarrollo de iniciativas de SBR para garantizar una gestión efectiva y receptiva tanto para las operaciones en curso como para el desarrollo de nuevas iniciativas para su consideración por la Junta de ABR. El Grupo Directivo del SBR también proporciona respaldo, garantía y orientación sobre las propuestas, supervisa el desempeño en relación con las expectativas de beneficios y resuelve problemas interinstitucionales.

10.2.2    Resultados

Como resultado de la implementación de SBR, las empresas pasan menos tiempo recopilando datos, completando formularios y enviando informes a las agencias gubernamentales. SBR reduce los costos y fomenta una mayor eficiencia para las agencias gubernamentales. SBR también ayuda a los proveedores de servicios digitales y a los intermediarios de datos al aumentar la productividad y reducir la entrada manual de datos, lo que elimina el riesgo de traducción y aumenta la certeza en la precisión de los datos. El resultado para las empresas es menos tiempo dedicado a recopilar información, completar formularios y enviar informes a las agencias gubernamentales participantes. El único costo para las empresas es la inversión en software habilitado para SBR.

En el informe anual de la Autoridad Tributaria Australiana para 2017-2018, los ahorros anuales (recurrentes) se estimaron en $ 1.45 mil millones de AUD de SBR. Esto se traduce en aproximadamente $ 980 millones en dólares estadounidenses.

10.2.3    Conclusiones

Esta historia de éxito ilustra cómo XBRL se puede utilizar para implementar requisitos de informes uniformes y agilizar el cumplimiento normativo. Antes de la implementación de SBR, había procedimientos de presentación de informes dispares para las agencias gubernamentales que requerían la información. A través de la taxonomía SBR, estos requisitos y procedimientos podrían armonizarse. Al igual que el ejemplo bancario de la sección anterior, la participación de desarrolladores y proveedores de software permitió la implementación de la validación específica de la agencia, además de simplificar que los preparadores determinen qué información debe informarse. Los preparadores pueden aprovechar una sola taxonomía para enviar toda la información necesaria a múltiples agencias gubernamentales; y que la información pueda transportarse de manera estructurada y previsible a uno o más de los organismos interesados.

Para obtener más información sobre los beneficios, visite:
https://www.sbr.gov.au/about-sbr/benefits-sbr#BenefitstoGovernment

10.3       Informes de trabajo en proceso para la suscripción de garantías

La taxonomía de informes de trabajo en proceso es una implementación de estándares que está impulsada únicamente por el apoyo de la industria para mejorar la eficiencia y reducir los costos innecesarios. No hay un impulsor de cumplimiento normativo.

El proceso de suscripción de garantías requiere la evaluación de los datos financieros recopilados de los contratistas para identificar los riesgos y determinar la elegibilidad para las fianzas de garantía. Los datos reportados incluyen estados financieros e informes de trabajo en proceso (WIP) (Figura 10-2) que describen el desempeño financiero y el estado de los proyectos de construcción individuales de un contratista. Los informes DE WIP contienen datos sobre ingresos, costos y ganancias para cada contrato o trabajo. Pueden prepararse para contratos terminados o para contratos en proceso y pueden presentarse trimestral o anualmente.

Los informes de WIP tienen múltiples casos de uso, que incluyen: 1) monitorear el estado de una fianza escrita por una fianza para un contrato específico; 2) para el procesamiento de reclamos de garantía; y 3) para la entrega a la Administración de Pequeñas Empresas (SBA) para monitorear la salud financiera del contratista para participar en el programa de garantía de fianzas de la SBA. Esta sección se centrará en el primer ejemplo, el uso de los informes WIP para monitorear la salud continua de un contratista como parte del proceso de suscripción.

10.3.1    Fondos

La garantía es una línea especializada de seguros que requiere que la información financiera oportuna se comparta entre múltiples partes. Debido a que no hay un organismo regulador involucrado, la industria requiere un método para estandarizar el formato y el contenido de esta información.

La garantía involucra al menos a tres partes: 1) el principal (contratista), que es la parte que asume la obligación; 2) el transportista de garantía, que garantiza que se cumplirá la obligación (trabajo); y 3) el obligado, que es el propietario del proyecto y que recibe el beneficio de la obra y la protección de la fianza. Por lo general, hay una cuarta parte llamada productor de bonos (también llamado agente de garantía), que es un productor con licencia que sirve como intermediario entre el contratista y el fiador. Los contratistas trabajan con productores de bonos que identifican garantías que serán una buena combinación para un contratista, según el tamaño, la industria y otros factores. Una vez que la relación entre el contratista y la fianza está en su lugar, el productor de bonos continúa asesorando a las dos partes. El productor de bonos a menudo recibe finanzas y otros materiales del contratista para su revisión antes de que se compartan con el fiador.

Para solicitar una fianza, el contratista presenta, a través de su productor de bonos, documentos financieros y otros documentos de respaldo. Una sola garantía generalmente proporciona todas las fianzas que necesita un contratista para todos sus proyectos aduaneros.

10.3.2.   Antes de los estándares de datos

El contratista proporcionó actualizaciones financieras periódicas a la fianza, incluidos los estados financieros y el informe WIP, que posiblemente se generaron a partir del sistema financiero interno del contratista o a través de una aplicación de hoja de cálculo.

Cuando el fiador recibió el informe WIP, se volvió a introducir en los sistemas financieros del fiador, una tarea que probablemente fue realizada por el personal de entrada de datos, los suscriptores de nivel de entrada o por un asistente del asegurador. Se verificó la exactitud de los datos. Los datos de WIP se utilizaron para evaluar la salud del contratista y la capacidad del contactor para completar con éxito el contrato.

El tiempo dedicado a volver a introducir la información dependía de la longitud del informe de trabajo en curso. Por ejemplo, una cuenta con diez trabajos podría tardar de 25 a 40 minutos en ingresarse, se estima que una con 25 trabajos tomaría aproximadamente una hora, y un informe de TRABAJO en curso con cientos de proyectos podría tardar horas en completarse. No era raro que las fianzas manejaran miles de informes wip cada año, lo que equivale a miles de horas de tiempo de procesamiento ineficiente.

10.3.3    Incorporación de estándares de datos

XBRL US fue contactado por un pequeño grupo de compañías de seguros de garantía que estaban interesadas en aprender cómo los estándares de datos podrían mejorar la eficiencia en la parte de recopilación de datos de su proceso de suscripción. Habían estado investigando la estandarización durante algún tiempo y sabían que podían reducir costos y establecer mejores procesos, pero hasta que aprendieron sobre XBRL, no habían identificado como operacionalizarlo. Se formó un pequeño grupo de trabajo, compuesto por profesionales de contabilidad, fianzas, agentes de bonos y compañías de software, para comenzar a desarrollar una pequeña taxonomía para representar el informe Work in Process. Si bien el grupo de la industria finalmente quería que todas las finanzas de los contratistas estuvieran en una forma estandarizada y legible por máquina, el informe Work in Process fue visto como una buena oportunidad para un piloto. En este estudio de caso, el patrocinador fue la industria de fianzas, en lugar de un regulador. La propia industria vio los estándares de datos como una herramienta que podría mejorar sus procesos. Las partes interesadas incluyeron compañías de seguros de garantía, agentes de fianzas, contratistas, contadores y proveedores de software que sirvieron a los contratistas. Eventualmente, otras partes interesadas se involucraron, incluida la Administración de Pequeñas Empresas, que opera un programa de Garantía de Garantía de la SBA donde también recopila informes de Trabajo en Proceso para medir la salud financiera de los contratistas a los que proporciona garantías de garantía.

La primera garantía en adoptar el estándar XBRL internamente para consumir informes WIP con formato XBRL fue el Hartford. Para implementar la taxonomía, hartford mapeó las 70 etiquetas de campo de datos en la taxonomía a las etiquetas de campo en su sistema financiero interno. Los detalles disponibles para cada campo de datos en la taxonomía hicieron que fuera relativamente fácil realizar el mapeo debido a las definiciones claras. El proceso de implementación para que los Hartford mapearan sus sistemas internos a la taxonomía tomó a un individuo aproximadamente ocho horas con aproximadamente cincuenta horas requeridas para las pruebas. Con el nuevo proceso estandarizado, cuando Hartford recibe un informe WIP en formato XBRL, el suscriptor puede rellenar automáticamente la base de datos con cifras de este informe con una sola pulsación de tecla.

El mayor desafío para el proceso de adopción ha sido involucrar a los contratistas para preparar sus informes y finanzas wip en formato XBRL. Se han desarrollado varias herramientas para ayudar en ese proceso. Altova ha creado una herramienta de complementos de Excel. Crowe LLP, una firma de contabilidad que también construye aplicaciones de software, desarrolló una herramienta que transforma cualquier tipo de documento en formato XBRL. Crowe LLP ha tenido éxito trabajando con fianzas que utilizan la aplicación para traducir los documentos que reciben de los contratistas a XBRL, que luego pueden incorporar automáticamente a sus sistemas financieros. XBRL US se ha asociado con la Asociación Nacional de Productores de Bonos de Garantía (NASBP) para crear una plantilla de hoja de cálculo de Excel que los contratistas o sus proveedores de servicios (agentes de bonos o contadores) pueden usar para crear un informe WIP y luego exportar una versión XBRL de ese informe. Esta aplicación ha sido adaptada para un programa piloto que se utilizará con la SBA.

El proceso de adopción en la industria de la fianza aún está en curso. Sin embargo, varios transportistas de fianzas han adaptado sus sistemas internos para poder consumir documentos con formato XBRL, y están llegando al mercado más herramientas que pueden preparar documentos XBRL para contratistas.

10.3.4    Resultados

Antes de los estándares, la entrada manual de un informe WIP que contenía trece filas de datos habría sido un ejercicio de 30 minutos. Con los estándares, el proceso ahora toma alrededor de tres segundos. Para el Hartford, los datos están inmediatamente activos, almacenados en su base de datos y listos para ser utilizados en modelos de crédito. Un informe WIP que contenga cientos de filas adicionales de datos tomaría el mismo período de tres segundos para incorporarse a la base de datos de Hartford. Entre el costo de tecnología anticipado para la implementación completa y las ganancias de eficiencia anticipadas, Hartford espera cubrir los costos de implementación después de que se procesen aproximadamente 110 WIP a través del nuevo método.

10.3.5    Conclusiones

La taxonomía Surety Work-In-Process es un gran ejemplo de una industria que identifica la falta de estándares de datos y trabaja en conjunto para implementar una solución XBRL sólida. Con la ayuda de XBRL US, los miembros de la industria de fianzas pudieron abordar un problema que estaba obstaculizando tanto la comparabilidad como la eficiencia mediante la creación de un estándar de informes mejor y más uniforme. El patrocinador fue la propia industria, y los grupos de trabajo y comités de taxonomía estaban formados por partes interesadas de la industria. No había necesidad de una regulación general. Esto ilustra la capacidad de una industria para organizar los objetivos y requisitos de la taxonomía XBRL y diseñar e implementar con éxito una. A medida que más miembros de la comunidad de fianzas adopten la taxonomía XBRL, aumentarán las ganancias en el desarrollo e implementación de un nuevo estándar de datos.

10.4       Informes de empresas públicas en los Estados Unidos

La misión de la Comisión de Bolsa y Valores de los Estados Unidos (SEC) es proteger a los inversores, mantener mercados justos, ordenados y eficientes, y facilitar la formación de capital. Los requisitos de divulgación financiera son fundamentales para lograr esos objetivos.

El 30 de enero de 2009, la SEC adoptó una regla titulada Datos interactivos para mejorar los informes financieros3. El texto de la regla señaló: «Las nuevas reglas están destinadas no solo a facilitar el análisis de la información financiera para los inversores, sino también a ayudar a automatizar las presentaciones regulatorias y el procesamiento de la información comercial. Los datos interactivos tienen el potencial de aumentar la velocidad, la precisión y la usabilidad de la divulgación financiera y, finalmente, reducir los costos». La regla requería que las empresas públicas en los Estados Unidos, los emisores privados extranjeros que preparan sus estados financieros de acuerdo con los Principios de Contabilidad Generalmente Aceptados de los Estados Unidos (US GAAP) y los emisores privados extranjeros que preparan sus estados financieros utilizando las Normas Internacionales de Información Financiera (NIIF) presenten divulgaciones financieras y de notas al pie en formato XBRL.

Para construir los nuevos estándares de datos, se creó la taxonomía financiera US GAAP a solicitud de la SEC. Esta taxonomía es ahora mantenida activamente por la Junta de Normas de Contabilidad Financiera (FASB). Al comienzo de la implementación de los requisitos de la SEC, las empresas debían hacer dos presentaciones: su presentación tradicional en HTML o texto y el nuevo requisito para la presentación del informe XBRL. También se les pidió que publicaran su informe XBRL en su sitio web corporativo. La norma se introdujo gradualmente durante un período de tres años. Los emisores privados extranjeros que prepararon sus declaraciones en LAS NIIF debían comenzar a presentar en XBRL en el tercer año de la introducción gradual, cuando la taxonomía de las NIIF, creada por la Junta de Normas Internacionales de Contabilidad (IASB), fue aceptada por la SEC en 2017.

Para reducir aún más la carga del preparador durante este proceso de implementación, se pidió a las empresas que proporcionaran niveles crecientes de detalle en sus presentaciones a lo largo del tiempo. Inicialmente, ciertos datos financieros aparecían únicamente como un bloque de texto. En los años siguientes, también se requirió etiquetar puntos de datos discretos dentro de los bloques de texto. Se proporcionaron otras adaptaciones y apoyo para facilitar a los preparadores estos nuevos procesos.

10.4.1     Antes de los estándares de datos

Antes de que se implementara XBRL, los informes corporativos requerían que los declarantes de la SEC prepararan los estados financieros en HTML o texto y los enviaran al Sistema Electrónico de Recopilación y Recuperación de Datos (EDGAR) de la SEC. Luego, la SEC puso los archivos HTML / texto a disposición del público a los pocos minutos de su presentación. Los proveedores de bases de datos, analistas e inversores podrían acceder a los datos a través de la parte de presentaciones de la compañía del sitio web de la SEC buscando el nombre de la compañía, el tipo de presentación de presentación o simplemente mirando las últimas presentaciones. Los proveedores de datos podrían obtener una fuente de presentaciones corporativas y luego analizar los datos para extraer información en sus bases de datos, que luego se revendió a inversores, analistas, medios de comunicación, investigadores, académicos, otros reguladores y otros consumidores de datos.

El sistema EDGAR, que se puso en marcha en 1983, fue un gran paso adelante para la divulgación. Por primera vez, los documentos electrónicos en texto, y más tarde en formato HTML, estaban disponibles públicamente para cualquier persona con acceso a Internet. Antes del Sistema EDGAR, las presentaciones corporativas estaban disponibles directamente desde la compañía o visitando las oficinas de la SEC. Además, EDGAR hizo que estas presentaciones electrónicas estuvieran fácilmente disponibles para que los inversores u otros usuarios de datos pudieran descargar documentos completos electrónicamente. Aun así, los datos quedaron atrapados en los documentos de presentación y requirieron un análisis manual antes de que pudieran usarse para el análisis.

---

---

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.

1.2

XBRL US y su misión

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.

1.4

Qué hay en este documento

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

Una introducción a XBRL

2.1

Lenguaje de informes de negocios extensible

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.

2.2.3.3

Dimensión del núcleo del período

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 metros² 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.

2.2.6.2

Propiedades del concepto

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.

2.2.8

Agregar dimensiones definidas por taxonomía

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.

2.2.9

Adjuntar notas a pie de página a los hechos

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.

2.3

Legibilidad de la máquina

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.

2.3.1

Tipos de datos

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.

2.4

La taxonomía

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.

3.2.1

Datos no relacionales

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 .

3.3.1.2

Dimensiones dependientes en XBRL

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.

3.4

Componentes de un modelo de datos XBRL

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.

3.4.1.1

Seleccionar el tipo de datos correcto

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.

3.4.2.2

Dimensiones definidas por taxonomía con tipo

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

3.4.4     Relaciones jerárquicas

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.

3.4.4.3

Definiciones

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.

3,5

Implementación del modelo de datos XBRL

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.

3.5.5     Definiciones de XBRL

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.

3.6.1.1

Ampliación de tipos de datos

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.

3,7

Avanzando

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.

4.1

Definir los objetivos del proyecto

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.

4.2

Identificación y participación de las 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.

4.3

Definir el alcance de la taxonomía

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.

4.5

Identificación de requisitos regulatorios o de ONG

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.

4.6

Otros requisitos y consideraciones

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.

4.6.2

Requisitos de soporte y gobernanza

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.

4.6.3

Desarrolladores y desarrollo de software

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.

4,7

Midiendo el éxito

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.

5.2

Desarrollar un modelo

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.

5.3

Transformar un modelo de datos en un modelo de transporte

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.

5.3.2.2

Ya sea para utilizar dimensiones definidas por taxonomía explícita o por tipo

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.

5.4

Diseño del sistema de informes

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 .

5.4.2

Extensibilidad

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

5.4.2.2

Permitir etiquetas personalizadas

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

5.4.3

Métodos para visualizar y consumir los datos

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 ).

5.5

Otras consideraciones de modelado y errores comunes

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.

---

---