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.