informe sobre la arquitectura de la taxonomía siconfi y ... · informação, a modularização da...
TRANSCRIPT
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Informe Sobre la Arquitectura de la Taxonomía SICONFI y los Patrones y
Procesos Para Colectar los Datos Necesarios Para Su Creación Proyecto XBRL y XBRL GL BRA/04/016 – Términos de Referencia, Producto no. 2-
3, Actividades n. 5.2-5.3
1 - Introducción Los Términos de Referencia de Junio 2012 para la contratación de un consultor individual para apoyar el
equipo de la Secretaria do Tesouro Nacional (STN) en la construcción de la Taxonomía XBRL que
representará la información del Sistema de Informações Contábeis e Fiscais do Setor Público Brasileiro
(SICONFI), detallan las distintas actividades requeridas del consultor y los varios productos relacionados
con cada actividad.
Este documento describe el segundo y tercer producto, descritos en los Términos de Referencia como
sigue:
Produto 2:
“Documento contendo definição da arquitetura e modelagem da Taxonomia da STN em linguagem
XBRL, de acordo com abordagem definida pela STN, a partir do produto anterior e conforme descrição
do item 5.2”
La actividad (Item) 5.2 está descrita en los mismos Términos de Referencia como sigue:
“Definição da arquitetura e modelagem da Taxonomia da STN em linguagem XBRL:
a) Características básicas que definem a arquitetura da taxonomia, como o sistema de classificação da informação, a modularização da taxonomia, as convenções de nomenclatura, a definição e o uso de artefatos XBRL, como funções e outros princípios arquitetônicos adaptados sobre os requisitos específicos; e
b) Definição de regras de contextualização, que dêem suporte ao tratamento consistente das informações representadas na taxonomia: orientações sobre como identificar conceitos de dados em sua forma atômica, independentemente de como essa informação é representada nos documentos de origem a fim de melhorar a reutilização, onde possível, e como escolher a estrutura de contextualização adequada para ser aplicada a cada item definido na arquitetura.”
Produto 3:
“Documento contendo templates e processos de apoio à coleta de dados / atividades de modelagem,
harmonização e contextualização dos dados, conforme item 5.3.”
La actividad (Item) 5.3 está descrita en los mismos Términos de Referencia como sigue:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl “Criação de templates e processos de apoio à coleta, atividades de modelagem, harmonização e
contextualização dos dados de: MSC, QDCC, DCASP, DEFP, MEF-Mercosul 2010, RREO, RGF, COC e
demais formulários de dados.”
Este informe incluye dos anexos que han sido estructurados para ser utilizados como documentos
independientes del informe mismo:
Anexo 1 – Arquitectura de la Taxonomía SICONFI: El documento describe en detalle la arquitectura de la Taxonomía, creada en conformidad con la decisión adoptada el 18 de Septiembre 2012 por el Comité Técnico y el Comité Estratégico del Proyecto SICONFI, para la adopción de una arquitectura que incluye la Taxonomía XBRL Global Ledger (XBRL GL), y según los resultados del prototipo descrito en el “Informe Sobre el Prototipo de Representación de la Matriz de Saldos Contables y de Reportes Derivados con XBRL y XBRL Global Ledger” del 15 de Septiembre 2012;
Anexo 2 – Patrones y Procesos para la Creación de la Taxonomía SICONFI: De acuerdo con los resultados de las reuniones celebradas en Brasilia en la semana desde el 22 al 26 de Octubre de 2012, el documento describe los procesos que el Equipo de Desarrollo de la Taxonomía (EDT) utilizará para la colección de información contenida en los reportes que la Taxonomía SICONFI tendrá que representar, e incluye patrones en Microsoft Excel diseñados para soportar la colección y la armonización de la información y la subsecuente creación de archivo que puedan ser importados en Fujitsu XWand, la herramienta seleccionada por el Proyecto SICONFI para crear y mantener la Taxonomía. Los procesos son diseñados para permitir al EDT desarrollar una parte significativa del trabajo – en particular la creación de elementos, etiquetas y referencias - en Excel, y luego completar el trabajo con la creación de los Presentation, Definition and Calculation Linkbases en XWand, ya que esta forma de organizar el trabajo es percibida como una ventaja debido a la mayor facilidad de utilización de Excel con respecto a XWand, siempre según los resultados de las discusiones mantenidas en Brasilia.
En este documento, los términos técnicos relativos a las especificaciones XML y XBRL aparecen en inglés
y entre comillas.
2 – Absorción de Conocimientos y Trasferencia de Tecnología La finalidad principal de este informe es de proveer los productos 3 y 4, necesarios para empezar las
actividades de desarrollo de la Taxonomía. Sin embargo las actividades realizadas para llegar a la
definición de los productos, también produjeron resultados importantes en términos de transferencia
de conocimientos entre los miembros del equipo del Proyecto SICONFI que participaron en las
reuniones preparatorias en la semana del 22 de Octubre 2012.
Aprovechando también de las discusiones que ocurrieron en relación al primer producto en la semana
del 27 de Agosto y construyendo sobre los conocimientos ya adquiridos, la semana del 22 de Octubre
fue estructurada de forma parecida a un curso de entrenamiento en temáticas específicas de
arquitectura y desarrollo de Taxonomías XBRL.
También se aplicó una metodología similar a la que tuvo éxito por el primer producto:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
1. Las varias consideraciones relativas a la arquitectura y a los procesos de creación de la Taxonomía fueron presentadas en términos generales en el primer día de reunión, para colectar las primeras reacciones y discutir los varios comentarios;
2. En el segundo y tercer día el equipo tuvo tiempo para considerar los materiales presentados y proveer contestaciones a las preguntas dejadas abiertas en la discusión del primer día, mientras se trabajaba a una presentación mas detallada y técnica, al igual que en la incorporación de las reacciones del equipo a la primera presentación;
3. En el cuarto día hubo otra reunión plenaria en el curso de la cual se reafirmaron los puntos discutidos anteriormente y se realizo una discusión detallada de los varios tópicos desde un punto de vista practico y entrando también en detalles técnicos.
Este método, al igual que la vez pasada, produjo resultados satisfactorios. El nivel de interacción, como
era de esperarse, fue elevado así como la calidad de las preguntas por parte del equipo, especialmente
en la segunda reunión plenaria.
Además, estoy convencido que la discusión técnica sucedió a un nivel suficientemente elevado como
para dejar listo el terreno para la próxima actividad – el actual desarrollo de la Taxonomía. Los
conocimientos adquiridos, en particular por los miembros del EDT, junto a los materiales de referencia
adjuntados a este informe, constituirán una base importante para el trabajo de desarrollo que se va a
empezar en la semana del 26 de Noviembre.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Anexo 1 – Arquitectura de la Taxonomía SICONFI
1 – Introducción El propósito de este documento es la definición de la arquitectura de la Taxonomía XBRL SICONFI.
Primordialmente la arquitectura apoyará el Equipo de Desarrollo de la Taxonomía (EDT) en la
construcción inicial y en el mantenimiento de la Taxonomía en sí misma, así como los varios equipos que
efectuarán su revisión interna y las actividades de control de calidad. Después de la publicación de la
Taxonomía, el documento proveerá los materiales de base para crear documentos adicionales que
apoyarán a:
1. Creadores de software en la implementación de soporte a la utilización de la Taxonomía en sus productos;
2. Usuarios de la Taxonomía para generar los reportes en XBRL
Se espera que este documento evolucione en el transcurso de desarrollo de la primera edición de la
Taxonomía SICONFI, en base a la experiencia de desarrollo y a las características especificas en la
información representada. Una segunda versión del documento, que incluirá las modificaciones
necesarias, será publicada junto a la primera edición de la Taxonomía.
Tener familiaridad con la especificación XBRL y con las especificaciones relacionadas, tales como XBRL
Dimensions 1.0 así como con la terminología y los conceptos de XBRL, es un pre-requisito para leer y
entender completamente este documento.
2 – Naturaleza y Alcance Los principios fundamentales de la arquitectura están diseñados para apoyar los requerimientos básicos
del Proyecto SICONFI. En particular la Taxonomía tiene que:
Ser adecuada para representar toda la información en el ámbito del proyecto:
o Reportes agregados;
o Información de detalle – Matriz de Saldos Contables (MSC), PCASP, COC (Operaciones) y otra información de detalle que se identificará en el curso del desarrollo de la Taxonomía;
o Reglas de agregación para derivar los reportes agregados desde la información de detalle;
Permitir a los Estados y Municipios y otras entidades de Gobiernos Subnacionales y Federal, que utilizarán la Taxonomía para crear y enviar sus reportes al Gobierno Federal (en este documento y en los materiales identificados como “Nacionales y Subnacionales”), optar por presentar el detalle subyacente a partir del cual los reportes agregados serán generados automáticamente , o alternativamente sólo los reportes agregados;
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Ser optimizada para el tipo de datos que debe representar y para apoyar en la forma más eficiente los procesos relacionados a la creación, mantenimiento y utilización de la Taxonomía. Este requisito se debe trasladar en
o Facilidad de uso de la Taxonomía para crear reportes XBRL por parte de los Nacionales y Subnacionales;
o Facilidad de creación/mantenimiento de la Taxonomía por parte del Programa;
Facilitar la armonización de la información representada en la Taxonomía misma.
La Figura 1 muestra los varios tipos de información que la Taxonomía SICONFI representa, identificando
también la forma técnica de representación de cada componente en XBRL:
1. XBRL Global Ledger (XBRL GL) para la información de detalle y las reglas de agregación;
2. Una Taxonomía XBRL desarrollada por el Proyecto SICONFI de acuerdo a los principios comúnmente aplicados para desarrollar Taxonomías XBRL para reporting financiero (XBRL FR) para los reportes agregados;
3. XBRL Formula para validaciones, reconciliaciones y otras reglas aplicadas a la información que no es posible implementar con las herramientas básicas definidas en la Especificación XBRL - XML Schema, Definition Linkbase, Calculation Linkbase.
Figura 1
Los reportes y la información que la Taxonomía representa incluyen: MSC, QDCC, DCASP, PCASP, DEFP,
MEF-Mercosul 2010, RREO, RGF, COC. La arquitectura de la Taxonomía esta sin embargo diseñada para
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl soportar la futura inclusión de reportes adicionales en la forma más eficaz y sin perjudicar su estructura
y funcionamiento.
3 – Gobernanza y Gestión de Cambios en la Arquitectura La publicación de la primera edición de este documento será autorizada por el Comité Tecnico Gestor
(CTG) y el Comité Estrategico (CE) del Proyecto SICONFI.
Cambios sucesivos que sean necesarios en este documento, por ejemplo para añadir o cambiar sus
provisiones, para corregir errores o para actualizarlo en ocasión de la publicación de una nueva edición
de la Taxonomía, el documento será publicado otra vez en su totalidad, siempre bajo autorización del
CTG y del CE.
Cambios al documento, y en consecuencia a la arquitectura de la Taxonomía, tienen que ser iniciados a
través de una solicitud formal (Solicitud de Cambio – SC) y aprobados por el CTG y el CE.
4- Principios Fundamentales Los requerimientos detallados en Sección 2 son alcanzados en la Arquitectura de la Taxonomía SICONFI
a través de tres principios fundamentales.
4.1 – Separación de la Información de Detalle y de los Reportes Agregados
El alcance de la Taxonomía incluye tanto información de detalle – la MSC más otras informaciones de
detalle y transaccionales – e información agregada derivada desde los datos detallados.
La información de detalle y la información agregada son claramente separadas en el ámbito de la
arquitectura de la Taxonomía, y modeladas de forma distinta, reconociendo:
Las diferencias estructurales entre las dos clases de información;
La necesidad de representar las relaciones entre las dos clases de información de forma eficiente;
El requerimiento de facilitar cuanto más posible la creación y el envío de la MSC por parte de los Nacionales y Subnacionales.
En conformidad con las conclusiones del informe “Prototipo de Representación de la Matriz de Saldos
Contables y de Reportes Derivados con XBRL y XBRL Global Ledger”, la Taxonomía SICONFI utiliza:
1. La Taxonomía XBRL GL para representar la información de detalle desde la cual los reportes agregados son derivados, así como las reglas que se aplican para derivar reportes agregados desde la misma información de detalle;
2. Una Taxonomía XBRL FR diseñada específicamente, y modelada según los principios y las reglas detalladas en este documento, para representar los reportes agregados.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl 4.2 – Estructura de la Taxonomía
La estructura de las carpetas que componen la Taxonomía y la asignación de los archivo a esas carpetas
son coherentes con la arquitectura en dos camadas característica de la Taxonomía publicada por el
programa Standard Business Reporting (SBR) del Gobierno Australiano:
1. Camada “de definición”, donde todos los elementos utilizados el los varios reportes son definidos – en un esquema XML único, o utilizando distintos esquemas modularizados de acuerdo con un sistema de clasificación de la información predefinido;
2. Camada “de reportes”, donde todos los elementos definidos en la camada de definición son utilizados dentro de reportes específicos, organizados en “entry points” (esquemas XML que identifican los elementos y los recursos necesarios para representar un reporte especifico) – un punto de entrada por cada reporte, contenido en una carpeta que lleva el nombre del reporte. Varias carpetas que contienen reportes que pertenecen a un mismo grupo pueden ser contenidas en una carpeta que identifica el grupo.
Más información sobre el Programa SBR se puede encontrar en la página web del Programa
http://www.sbr.gov.au.
La Figura 2 muestra la estructura de la Taxonomía SICONFI, con sólo las carpetas principales en la
camada de definición y con ejemplos de grupos de reportes (DCASP, RGF, RREO…) y en el grupo DCASP
ejemplos de reportes (Balance Patrimonial, Balance Orçamentario – Despesas…).
Figura 2
Cabe destacar la localización de la Taxonomía XBRL GL en la Figura 2:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
En la camada de definición se encuentra una carpeta “ext” (externa), que contiene taxonomías que son utilizadas por la Taxonomía SICONFI pero son creadas y mantenidas por entidades externas. El primer ejemplo de taxonomía guardada en esta carpeta es XBRL GL (carpeta “gl”);
Dentro de la carpeta “gl” se encuentra, entre otras, la carpeta “ids” donde se guardan los documentos de instancia XBRL GL que representan la información de detalle y las reglas de asignación/agregación para derivar los reportes agregados desde la información de detalle, así como otros documentos de instancia XBRL GL accesorios.
Más información sobre el contenido de las varias carpetas en las dos camadas se encuentra en la
Sección 6 de este documento.
4.3 - Procesos de Creación y Mantenimiento de la Taxonomía
Cualquier nuevo elemento que se añade a la Taxonomía tiene que ser creado en conformidad con los
principios definidos en este documento y aprobados por el CTG y el CE:
1. Cualquier nuevo elemento “reportable” (o sea, que puede tener un valor en un documento de instancia), primario o dimensional, tiene que ser creado en un esquema XML contenido en la carpeta “ic” en la camada de definición. Ningún elemento reportable puede ser creado en la camada de reportes;
2. Antes de añadir un nuevo elemento reportable, se necesita asegurar la inexistencia de un elemento reportable con el mismo significado, o un significado similar. Si un elemento reportable con estas características ya existe, el elemento existente tiene que ser utilizado para el propósito por el cual la creación de un nuevo elemento fue inicialmente considerada.
5 – Normas y Directrices Generales 1. La Taxonomía SICONFI es una Taxonomía “cerrada”. Esto significa que extensiones y
modificaciones no son permitidas cuando la Taxonomía es utilizada por los Nacionales y Subnacionales para enviar la MSC o los reportes en el ámbito del Proyecto SICONFI. Como todas las Taxonomías XBRL, la Taxonomía SICONFI puede ser extendida/modificada si es utilizada para otras finalidades.
2. Algunos recursos y constructos definidos en la especificación XBRL son identificados en este documento con la descripción “Debe evitarse”. Ejemplos incluyen “typed dimensions” y “tuples”. Por cada uno de estos constructos se indicará también criterios prácticos que el EDP puede utilizar para identificar alternativas o decidir se su utilización es absolutamente necesaria. Esta identificación se utilizara solamente en esta primera edición de la Arquitectura – en cuanto la primera edición de la Taxonomía sea completada, los constructos por los cuales no se habrá encontrado ninguna fuerte motivación para su uso se identificaran como prohibidos, y por los que no se podrán evitar la indicación “Debe evitarse” será cancelada, así como esta provisión.
3. Provisiones relacionadas con el uso de “context”:
a. El valor por defecto del atributo “periodType” en la definición de elementos en la Taxonomía SICONFI es “duration”, a menos que haya un claro requerimiento de utilizar en el mismo documento de instancia múltiples valores del mismo elemento que representan snapshots de la misma información en distintos instantes en el tiempo;
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
b. Las dimensiones creadas en la Taxonomía serán contenidas en “segment”. La utilización de “scenario” como contenedor dimensional o de otra información es prohibida;
c. La utilización de hypercubes abiertos – en otras palabras, la practica de añadir otra información en “segment” que no sea definida como una dimensión se acuerdo a la especificación XBRL Dimensions 1.0 - esta prohibida;
4. Los elementos abstractos deben definirse con los siguientes atributos:
a. type=”stringItemType”
b. periodType=”duration”
6 – Estructura de la Taxonomía – Análisis y Asignación de Archivos y Recursos En esta sección se detalla la estructura de la Taxonomía, carpeta por carpeta en las dos camadas, y la
asignación de archivos y recursos en cada carpeta.
6.1 – Camada de Definición
La Figura 3 muestra la estructura completa de la carpeta “cor” (core), que representa la camada de
definición.
Figura 3
6.1.1 – Carpeta “ic”
Archivos contenidos en la carpeta:
1. Esquema(s) XML donde se definen los elementos primarios;
2. “Label linkbase(s)” donde se definen las etiquetas genéricas de los elementos primarios, que serán visibles en todos los reportes donde los elementos primarios están utilizados;
3. “Reference linkbases(s)” donde se definen las referencias genéricas de los elementos primarios, que serán visibles en todos los reportes donde los elementos primarios están utilizados.
Provisiones específicas:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
1. Inicialmente todos los elementos primarios serán definidos en un esquema único. Si en el transcurso del desarrollo de la primera edición de la Taxonomía, se identificara un sistema de clasificación de la información que se traslada en beneficios prácticos en la utilización de la Taxonomía, se crearán múltiples esquemas XML, modulados de acuerdo a la articulación en clases del sistema de clasificación identificado.
2. Por cada elemento primario es posible definir 2 clases de etiquetas en cada idioma soportado por la Taxonomía:
a. La primera identificada con “role” “nome”, obligatoria. Esta etiqueta contiene la descripción sintética del elemento primario y se utiliza también para derivar el nombre del elemento;
b. La segunda identificada con “role” “funcao”, opcional para todos los elementos primarios con la excepción de los elementos que representan una cuenta PCASP, por los cuales la etiqueta es obligatoria. Esta etiqueta contiene una descripción mas detallada del elemento;
En el curso del desarrollo de la primera edición de la Taxonomía se evaluará si, limitadamente a
los elementos que representan una cuenta PCASP, se necesita una tercera clase de etiqueta
(opcional) con una descripción adicional de la cuenta, ya que por estos elementos la etiqueta
“nome” se utilizará para el código de la cuenta y la etiqueta “funcao” para la descripción de la
cuenta.
Los dos tipos de etiqueta son definidos en el mismo “label linkbase”.
3. Las etiquetas definidas por cada elemento primario, según las reglas detalladas en el punto precedente, son provistas en Portugués (idioma obligatorio). Opcionalmente las etiquetas se pueden proveer en Español e Inglés (opcionales). Las etiquetas en cada idioma soportado son definidas en “label linkbases” definidos en archivo XML separados.
4. Por cada elemento primario es posible definir 3 clases de referencias:
a. La primera identificada con “role” “lei”, opcional;
b. La segunda identificada con “role” “norma1”, opcional;
c. La tercera identificada con “role” “norma2”, opcional;
Cada clase de referencia utilizará las mismas “parts”: “nome”, “numero”, “data”, “versao”,
“secao”, todas opcionales.
6.1.2 – Carpeta “fd”
Archivo contenidos en la carpeta:
1. Esquemas XML donde se definen “data types” específicos utilizados en la Taxonomía SICONFI;
2. Esquemas XML donde se definen “roles” específicos utilizados en la Taxonomía SICONFI.
6.1.3 – Carpeta “dim”
Archivo contenidos en la carpeta:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
1. Esquemas XML donde se definen los elementos relativos a la utilización de la especificación XBRL Dimensions 1.0, como “dimensions” and “domain members”;
2. “Label linkbase(s)” donde se definen las etiquetas genéricas de los elementos dimensionales, que serán visibles en todos los reportes donde los elementos dimensionales están utilizados;
3. “Reference linkbases(s)” donde se definen las referencias genéricas de los elementos dimensionales, que serán visibles en todos los reportes donde los elementos dimensionales están utilizados.
Provisiones especificas:
1. Los elementos dimensionales son solamente definidos en la camada de definición; su montaje en “hypercubes” y la aplicación del “hypercube” a un conjunto de elementos primarios se define en la camada de reportes. Si en el transcurso del desarrollo de la primera edición de la Taxonomía se encontrara la oportunidad de definir “hypercubes” en la camada definicional, en consecuencia de su re-uso en múltiples reportes, se creará una carpeta “cmn” (“common”) en la camada de definición, y esa carpeta contendrá los esquemas XML donde se definen los “hypercubes” comunes a múltiples reportes;
2. Por cada elemento dimensional es posible definir una etiqueta con “role” “nome”, opcional;
3. Las etiquetas definidas por cada elemento dimensional son provistas en Portugués (idioma obligatorio). Opcionalmente las etiquetas se pueden proveer en Español e Inglés (opcionales). Las etiquetas en cada idioma soportado son definidas en “label linkbases” definidos en archivo XML separados;
4. Por cada elemento dimensional es posible definir una referencia con “role” “lei”, opcional.
6.1.4 – Carpeta “ext”
Esta carpeta contiene taxonomías que son utilizadas por la Taxonomía SICONFI pero son creadas y
mantenidas por entidades externas. Inicialmente la única Taxonomía externa es XBRL GL, contenida el la
carpeta “gl”.
6.1.5 – Carpeta “gl”
Esta carpeta contiene los perfiles de XBRL GL utilizados para representar los varios tipos de información
de detalle en la Taxonomía SICONFI.
Archivo contenidos en la carpeta:
1. Un esquema XML por cada perfil utilizado, derivado de los esquemas definidos en la versión completa de la Taxonomía XBRL GL;
2. Un “label linkbase” por cada perfil utilizado y por cada idioma soportado, derivado de los “label linkbases” definidos en la versión completa de la Taxonomía XBRL GL;
3. Un “presentation linkbase” por cada perfil utilizado, derivado de los “label linkbases” definidos en la versión completa de la Taxonomía XBRL GL.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
4. Un “formula linkbase” por cada perfil utilizado, definido en base a las validaciones necesarias para asegurar la calidad de los documentos de instancia XBRL GL sometidos por los Nacionales y Subnacionales.
La carpeta “gl” contiene también la carpeta “ids” (“instance documents”), que contiene los documentos
de instancia XBRL GL que representan la información de detalle y las reglas de asignación/agregación
para derivar los reportes agregados desde la información de detalle, así como otros documentos de
instancia XBRL GL accesorios.
6.2 – Camada de Reportes
La Figura 4 muestra la estructura completa de la carpeta “rep” (reportes), que representa la camada de
reportes.
Figure 4
6.2.1 – Carpetas de Grupos de Reportes
En la carpeta “rep” se pueden crear tantos niveles de agrupación de reportes como se necesiten. Por
cada grupo se crea una carpeta en la carpeta “rep” – la Figura 4 muestra tres grupos de reportes
(DCASP, RGF, RREO) simplemente como ejemplo. En la Figura 4 solo se utiliza un nivel de agrupación,
sin embargo los niveles de agrupación pueden ser múltiples y se representan creando carpetas por cada
sub-nivel dentro de la carpeta de agrupación del nivel superior correspondiente. El único efecto
negativo de la creación de múltiples niveles de agrupación es que, como el nombre de algunos de los
constructos que se utilizan el la Taxonomía reproduce la secuencia de carpetas (por ejemplo los
identificadores de “namespaces”) tener niveles múltiples se traslada en nombres mas largos. En
consecuencia, la decisión de definir agrupaciones adicionales tiene que basarse sobre un requerimiento
real de clasificación.
Archivo contenidos en cada carpeta:
Las carpetas de agrupación contienen principalmente las carpetas que identifican los reportes que
pertenecen al grupo que cada carpeta representa. Opcionalmente, estas carpetas pueden contener
“entry points” que dan acceso a todos los recursos utilizados en los reportes que pertenecen a ese
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl grupo. En el curso del desarrollo de la primera edición de la Taxonomía se decidirá si estos “entry
points” de grupo pueden ser beneficiosos a la Taxonomía SICONFI.
6.2.2 – Carpetas de Reporte
En cada carpeta que representa un grupo de reportes se crea una carpeta que representa cada reporte
que pertenece a ese grupo. En la Figura 4 se utilizan como ejemplos los reportes Balanço Patrimonial
(“bp”) y Balanço Orçamentário Despesas (“bod”) en el grupo DCASP (“dcasp”).
Archivo contenidos en cada carpeta:
1. Un esquema XML que representa el “entry point” por el reporte representado por la carpeta (obligatorio). El “entry point” da acceso a elementos primarios, elementos dimensionales, etiquetas y referencias y otros recursos definidos en la camada de definición y utilizados en el reporte, más los recursos específicos del reporte definidos en el mismo “entry point” en otros archivo localizados en la misma carpeta;
2. “Label linkbase(s)” (opcionales) donde se definen las etiquetas de los elementos primarios y dimensionales especificas del reporte, que serán visibles solo en el mismo reporte;
3. “Reference linkbases(s)” (opcionales) donde se definen las referencias de los elementos primarios y dimensionales especificas del reporte, que serán visibles solo en el mismo reporte;
4. “Presentation linkbase(s)” (obligatorios) donde se define la presentación de los elementos primarios y dimensionales utilizados en el reporte;
5. “Definition linkbase(s)” (opcionales) donde se define la representación dimensional utilizada en el reporte;
6. “Calculation linkbase(s)” (opcionales) donde se definen las validaciones de calculaciones aplicadas a los elementos utilizados en el reporte;
7. “Formula linkbase(s)” (opcionales) donde se definen validaciones y otras reglas aplicadas a la información contenida en el reporte.
Provisiones especificas:
1. En los “entry points” se define la aplicación de los “hypercubes” al set de elementos primarios correspondiente, y los elementos abstractos utilizados en el reporte mismo;
2. Por cada elemento primario y dimensional es posible definir una clase de etiquetas en cada idioma soportado en la Taxonomía, identificada con “role” “funcao”, opcional. Esta etiqueta contiene una descripción del elemento especifica para el reporte que se añade a las etiquetas genéricas definidas en la camada de definición, y no es visible en ningún otro reporte;
3. Las etiquetas definidas por cada elemento primario y dimensional, según las reglas detalladas en el punto precedente, son provistas en Portugués (idioma obligatorio). Opcionalmente las etiquetas se pueden proveer en Español e Inglés (opcionales). Las etiquetas en cada idioma soportado son definidas en “label linkbases” definidos en archivo XML separados.
4. Por cada elemento primario es posible definir 2 clases de referencias:
a. La primera identificada con “role” “norma1”, opcional;
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
b. La segunda identificada con “role” “norma2”, opcional;
5. Cada clase de referencia utilizará las mismas “parts”: “nome”, “numero”, “data”, “versao”, “secao”, todas opcionales;
6. El “presentation linkbase” se provee con el único propósito de facilitar la legibilidad de la taxonomia y su revisión por parte de humanos. Si un “definition linkbase” existe para el reporte, el “presentation linkbase” incluye la representación de los elementos dimensionales.
7 - Convenciones de Nomenclatura Los nombres de los varios recursos definidos en la Taxonomía se deben crear según el modelo
especificado en esta sección por cada recurso. Nuevos recursos serán añadidos en cuanto se manifieste
la necesidad en el curso del desarrollo de la primera edición de la Taxonomía. En algún tiempo esta
sección podrá convertirse en un documento separado de la arquitectura de la taxonomía.
7.1 – Variables Utilizadas
Variable Descripción
[yyyy] Año
[mm] Mes
[dd] Día
[HH] Hora (exprimida en 24 horas)
[MM] Minuto
[id] Idioma
[per] Identificativo del perfil XBRL GL utilizado
[gru] Identificativo del grupo de reportes
[rep] Identificativo del reporte
[igl] Identificativo del documento de instancia XBRL GL fundacional
[path] Ruta de un archivo a partir de la carpeta “sic” (incluida)
[filename] Nombre de un archivo sin extensión
7.2 – Archivos Comprimidos
En cualquier ocasión en la cual la Taxonomía tiene que ser distribuida, internamente o externamente, se
debe compactarla en un archivo comprimido aplicando la convención de nomenclatura siguiente:
sic_[yyyy][mm][dd][hh][mm].zip
7.3- Carpetas
7.3.1 – Camada de Definición
La nomenclatura de las carpetas en la camada de definición es la detallada en la Sección 6.1.
7.3.2 – Camada de Reportes
Tanto para las carpetas que representan grupos de reportes como para las que representan reportes
individuales el nombre tiene que ser un acrónimo sintético (3/4 letras) que representa el nombre del
grupo o del reporte.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl 7.4 - Archivos
Nombre Descripción Carpeta
sic-cor_[yyyy]-[mm]-[dd].xsd Esquemas XML de definición de elementos Carpeta “ic”
lab-sic-cor-[id]_[yyyy]-[mm]-[dd].xml
“Label linkbase” – Etiquetas genéricas Carpeta “ic”
ref-sic-cor_[yyyy]-[mm]-[dd].xml “Reference linkbase” – Referencias genéricas Carpeta “ic”
sic-dty_[yyyy]-[mm]-[dd].xsd Esquemas XML de definición de “data types” Carpeta “fd”
sic-fdn_[yyyy]-[mm]-[dd].xsd Esquemas XML de definición de “roles” y otros recursos fundacionales
Carpeta “fd”
sic-dim_[yyyy]-[mm]-[dd].xsd Esquemas XML de definición de información dimensional
Carpeta “dim”
lab-sic-dim-[id]_[yyyy]-[mm]-[dd].xml
“Label linkbase” – Etiquetas genéricas para información dimensional
Carpeta “dim”
ref-sic-dim_[yyyy]-[mm]-[dd].xml “Reference linkbase” – Referencias genéricas para información dimensional
Carpeta “dim”
sic-gl-[per]_[yyyy]-[mm]-[dd].xsd Esquema XML que define los elementos utilizados en el perfil XBRL GL
Carpeta “gl”
lab-sic-gl-[per]-[id]_[yyyy]-[mm]-[dd].xml
“Label linkbase” – Etiquetas de los elementos del perfil XBRL GL
Carpeta “gl”
pre-sic-gl-[per]_[yyyy]-[mm]-[dd].xml
“Presentation linkbase” del perfil XBRL GL Carpeta “gl”
for-sic-gl-[per]_[yyyy]-[mm]-[dd].xml
“Formula linkbase” del perfil XBRL GL Carpeta “gl”
sic-gl-[igl]_[yyyy]-[mm]-[dd].xml Documento de instancia XBRL GL fundacional Carpeta “ids”
sic-[rep]_[yyyy]-[mm]-[dd].xsd “Entry point” de un reporte Carpeta de reporte
lab-sic-[rep]-[id]_[yyyy]-[mm]-[dd].xml
“Label linkbase” de un reporte Carpeta de reporte
ref-sic-[rep]_[yyyy]-[mm]-[dd].xsd “Reference linkbase” de un reporte Carpeta de reporte
pre-sic-[rep]_[yyyy]-[mm]-[dd].xsd “Presentation linkbase” de un reporte Carpeta de reporte
def-sic-[rep]_[yyyy]-[mm]-[dd].xsd “Definition linkbase” de un reporte Carpeta de reporte
cal-sic-[rep]_[yyyy]-[mm]-[dd].xsd “Calculation linkbase” de un reporte Carpeta de reporte
for=sic-[rep]_[yyyy]-[mm]-[dd].xsd “Formula linkbase” de un reporte Carpeta de reporte
7.5 - Namespaces
El nombre de un “namespace” es derivado por la siguiente concatenación:
http://fazenda.gov.br/ + [path] + [filename]
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl 7.6 - Namespace prefixes
Nombre abreviado del archivo precedido por “sic-“. Por ejemplo “sic-cor”, “sic-[rep]”.
7.7 - Element names and IDs - Concepts, Dimensions, Domain Members, HCs
Tipo de Elemento Nombre ID
Elemento primario Derivado de la etiqueta con “role” “nome” en idioma Portugués eliminando los espacios entre palabras, capitalizando cada palabra y convirtiendo expresiones que contienen caracteres prohibidos en XML según las indicaciones contenidas en la “Guía de estilo”
Concatenación del “namespace prefix” correspondiente al “namespace” donde el elemento esta definido y del nombre del elemento separados por “_”
Dimensión Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Axis” al final
Concatenación del “namespace prefix” correspondiente al “namespace” donde el elemento esta definido y del nombre del elemento separados por “_”
Domain member Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Member” al final
Concatenación del “namespace prefix” correspondiente al “namespace” donde el elemento esta definido y del nombre del elemento separados por “_”
Hypercube Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Table” al final
Concatenación del “namespace prefix” correspondiente al “namespace” donde el elemento esta definido y del nombre del elemento separados por “_”
Abstract Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Abstract” al final
Concatenación del “namespace prefix” correspondiente al “namespace” donde el elemento esta definido y del nombre del elemento separados por “_”
7.8 – Locators y Resources
Tipo Nombre
“Locator label” Nombre del elemento que el “locator” identifica
“Resource label” Concatenación del tipo de “link” y del nombre del elemento
“Resource ID” Concatenación del tipo de “link” y del nombre del elemento
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl 7.9 - Extended Link Roles
ELR relativos a un reporte: Concatenación de “sic-“ + [rep] + Descripción sintética del “extended link
role”;
ELR comunes: Concatenación de “sic-fd” + Descripción sintética del “extended link role” o
Concatenación de “sic-cmn” + Descripción sintética del “extended link role” (si se creará la carpeta
“cmn” en la camada de definición) dependiendo de en cual carpeta en la camada de definición el ELR es
definido.
8 – Procesos de Contextualización “Contextualización” es el proceso con el cual se define la información accesoria necesaria para describir
completamente el significado de un elemento primario definido en una Taxonomía XBRL, de manera
que no sea necesario considerar el elemento en el marco del reporte en el cual es utilizado para
entender su significado.
Hay tres formas posibles para contextualizar un elemento:
1. Calificación completa (“full qualification”): El significado del elemento es descrito completamente por la definición del elemento mismo, y no se necesita definir ninguna contextualización adicional en la Taxonomía. En otras palabras, al elemento no se aplica información dimensional y no es parte de un “tuple” – simplemente se le aplica el “XBRL context” sin información dimensional al momento de crear un documento de instancia;
2. Dimensionalización: El significado del elemento es descrito por la definición del elemento mismo junto a la información dimensional aplicada. Las directrices siguientes se aplican a los elementos dimensionalizados:
a. El uso de “typed dimensions” debe evitarse. La razón es que además de que la mayor complejidad de las Taxonomías altamente dimensionales, mencionada en el punto precedente, la presencia de este constructo resulta en la creación y el mantenimiento de los mapeos para crear documentos de instancia mas compleja;
b. El uso de “negative hypercubes” debe evitarse. Estos constructos se utilizan para definir una tabla dimensional en la cual no todas las combinaciones “primary element”/”domain member” son permitidas. Las alternativas que se pueden considerar son: la definición de múltiples “positive hypercubes” que representen la misma información (matemáticamente siempre posible) o la definición de un único “positive hypercube”, y la utilización de XBRL Formula para negar las combinaciones prohibidas. La motivación es la mayor complejidad que la utilización extendida de este constructo introduce en la Taxonomía;
c. La utilización de “dimensions defaults” será considerada a lo largo de la creación de la primera edición de la Taxonomía en cuanto casos específicos irán emergiendo;
3. “Tuple”: Debe evitarse. Las mejores prácticas internacionales para el desarrollo de Taxonomías XBRL FR indican que el uso de “XBRL Dimensions” es preferido al uso de “tuples” por los problemas en la extensibilidad de la Taxonomía que introducen. Además, en el caso de la Taxonomía SICONFI, la utilización de XBRL GL para modelar información de detalle cubrirá la
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
mayoría de las necesidades para la utilización de este método de contextualización, ya que como descrito en los principios de guía que siguen, la necesidad de modelar información de detalle es una de las motivaciones principales para la utilización de “tuples”,. En caso que en el curso del desarrollo de la primera edición de la Taxonomía se identifiquen motivaciones claras para la utilización de “tuples”, la arquitectura será modificada para permitir su utilización sin perjudicar la extensibilidad de la Taxonomía.
Los principios que guían la decisión sobre la forma de contextualización que debe ser aplicada a cada
elemento son los siguientes:
La contextualización por defecto es la calificación completa del elemento;
La dimensionalización es utilizada cuando hay un claro requerimiento en el reporte de analizar el
elemento de acuerdo a varios criterios, dentro del mismo documento de instancia, en distintos
documentos de instancia del mismo reporte, o en distintos reportes. Una de las señales típicas,
aunque no automática, de la oportunidad de definir dimensiones, es la organización de la
información en tablas en el reporte;
Sin embargo, la dimensionalización debería limitarse a situaciones en las cuales la separación de un
elemento completamente calificado en un elemento primario e información dimensional determina
una mayor re-usabilidad del elemento primario y de las dimensiones resultantes en el reporte o en
distintos reportes. La motivación es que Taxonomías altamente dimensionales son más complicadas
de crear, mantener y utilizar, y por lo tanto los beneficios de crear una dimensión tienen que ser
claros y documentados. Otra motivación para crear dimensiones es evitar la utilización de un “tuple”
en casos donde ambas contextualizaciones podrían ser aplicadas;
La utilización de “typed dimensions” debe limitarse a situaciones donde hay un claro requerimiento
– como por ejemplo una tabla dimensional con un número de líneas desconocido, y donde una de
las columnas (“domain members”) es un claro candidato para ser una clave única;
El uso de “tuples” debe limitarse a las situaciones en las cuales hay una clara necesidad – como por ejemplo si hay información:
o Claramente separada del resto de la información en el reporte, similar a un record en una tabla de una base de datos y que tiene mas significado si es considerada en conjunto;
o Representada por una tabla con un número desconocido de líneas y donde ninguna de las columnas es un claro candidato para ser una clave única.
El uso de “nested tuples” (un “tuple” contenido dentro de otro “tuple”) debe evitarse;
La aplicación de dimensiones a elementos contenidos en “tuples”, técnicamente posible, debe evitarse.
9 – Definición de XBRL Roles XBRL “roles” que se utilizan en todos los reportes son definidos en la camada de definición, en un
esquema XML localizado en la carpeta “fd”. Ejemplos incluyen los “roles” “nome” y “funcao” utilizados
por las etiquetas, o los “roles” “lei”, “norma1” y “norma2” utilizados para las referencias.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl Otros “roles” son específicos de cada reporte, y son definidos en el “entry point” del reporte
correspondiente. Ejemplos incluyen los “roles” utilizados en el “definition linkbase” para la aplicación en
cada reporte de los “hypercubes” a los elementos primarios.
10 – Utilización de XBRL GL
10.1 – Perfiles XBRL GL
La Taxonomía XBRL GL incluye aproximadamente 400 elementos, que permiten representar una amplia
gama de información – por ejemplo facturas, asientos contables, inventarios, información de
sostenibilidad, indicadores estadísticos, y más. Solo una parte de estos elementos son necesarios para
representar la información de detalle en el ámbito de la Taxonomía SICONFI.
Para evitar el incluir en la Taxonomía información que no es necesaria, la utilización de XBRL GL en la
Taxonomía SICONFI se efectuará a través de “perfiles XBRL GL” optimizados para las necesidades
especificas. Un perfil XBRL GL es un subconjunto de elementos y recursos definidos en XBRL GL
necesarios para representar un tipo de información específico.
Solamente a titulo de ejemplo, la Figura 5 muestra el contenido completo de la estructura “account” de
XBRL GL, que se utiliza para representar una cuenta contable:
Figura 5
La Figura 6 muestra el posible subconjunto de elementos en la estructura “account” que se necesitan
para representar la MSC:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Figura 6
Es posible definir un perfil XBRL GL único para soportar la representación de toda la información de
detalle necesaria en el Proyecto SICONFI, o distintos perfiles por cada tipo de información de detalle –
por ejemplo un perfil para representar la MSC, otro perfil para las operaciones COC, etc. La decisión será
tomada en base a la experiencia de desarrollo a lo largo de la creación de la primera edición de la
Taxonomía.
10.2 - Tipos de Documentos de Instancia XBRL GL
Los documentos de instancia XBRL GL que se necesitan definir para soportar los requerimientos de la
Taxonomía SICONFI son de dos tipos distintos:
1. Documentos de instancia XBRL GL fundacionales: Son parte integrante de la arquitectura de la Taxonomía y son distribuidos junto a la Taxonomía misma y guardados en la carpeta “ids” dentro de la carpeta “gl”;
2. Reportes XBRL GL: Son los documentos de instancia que los Nacionales y Subnacionales generan y envían al Proyecto SICONFI, y no son parte de la Taxonomía SICONFI. Un típico ejemplo son los reportes que contienen la MSC.
Los documentos de instancia XBRL GL fundacionales definidos en la Taxonomía son de dos tipos:
1. Master files
a. Listas de códigos utilizados en las cuentas PCASP y en las cuentas corrientes
b. Lista de las cuentas PCASP;
c. MSC;
2. Mapeos
a. Entre la MSC y los elementos en los reportes;
b. Entre distintas versiones de la MSC.
Se prevé que otros documentos se añadirán en el curso del desarrollo de la primera edición de la
Taxonomía, en consecuencia de la análisis de otra información de detalle distinta de la MSC – por
ejemplo las operaciones COC.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
11 – Gobernanza y Gestión de Cambios en la Taxonomía Cualquier cambio propuesto en la Taxonomía desde una edición a la otra tiene que ser iniciado a través
de una solicitud formal (Solicitud de Cambio – SC) que tiene que ser aprobada por el CTG y el CE. Una
vez aprobada, la SC será implementada de acuerdo a las provisiones de este documento.
12 – Versionamiento Inicialmente, la estrategia de versionamiento aplicada a la Taxonomía SICONFI será de versionamiento
completo. Cada nueva edición será publicada enteramente con una nueva versión de cada elemento,
componente y recurso definido en la Taxonomía, tanto los que se han añadido o han cambiado con
respecto a la versión anterior cuanto los que no han subido ninguna variación.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Anexo 2 –Procesos para la Creación de la Taxonomía SICONFI
1 – Introducción Este documento describe los procesos que se aplicarán a la creación de la Taxonomía SICONFI. Las
actividades específicas soportadas por estos procesos son:
1. Colección de la información contenida en los reportes soportados por que la taxonomía SICONFI, y de información adicional necesaria para su representación de acuerdo con la especificación XBRL y con los principios establecidos en la Arquitectura de la Taxonomía SICONFI;
2. Armonización y contextualización de la información de acuerdo con los mismos principios;
Para soportar estas actividades, además de los procesos detallados en este documento, se utilizaran un
patrón representados en el archivo Excel “Fields Inventory”, adjuntado a este documento y
estructurado para optimizar las actividades mismas en función de los requerimientos.
Los requerimientos básicos considerados en la definición de los procesos son:
1. Soportar la creación de la Taxonomía SICONFI utilizando Fujitsu XWand como herramienta primaria de desarrollo;
2. Facilitar en lo más posible el trabajo colaborativo del Equipo de Desarrollo de la Taxonomía (EDT) para permitir el trabajo paralelo en distintas partes de la taxonomía (distintos reportes) manteniendo al mismo tiempo el control sobre la coherencia del resultado final;
3. Automatizar, en cuanto sea posible, las operaciones manuales de creación inicial de elementos, etiquetas, referencias y otros componentes de la taxonomía utilizando una interfaz de usuario simple y familiar, como hojas de calculo Excel.
En la primera fase de creación de la Taxonomía los procesos descritos en este documento se aplicarán
sin disponer de una infraestructura informática colaborativa. La armonización del trabajo hecho en
distintos archivos Excel se efectuará manualmente, y se definirá una etapa adicional del proceso con
esta finalidad. Se espera que, el hecho de que los reportes a ser representados en la Taxonomía han
pasado previamente por una fase de armonización antes de ser convertidos a XBRL, contribuirá a
minimizar el posible impacto negativo de la falta de un ambiente colaborativo en la armonización de la
información dentro de la Taxonomía.
En la segunda fase se piensa introducir una infraestructura colaborativa, basada por ejemplo en
SharePoint, limitada a la gestión de los archivos Excel, especialmente en previsión de la mayor necesidad
de colaboración después de la publicación de la primera edición de la Taxonomía, cuando se entrará en
la fase de mantenimiento. Los procesos detallados en este documento no cambiarán de forma
significativa – simplemente se eliminará la etapa adicional de armonización de la información entre
distintos archivos Excel mencionada en el párrafo precedente.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
2 – Colección de la Información en los Reportes Esta actividad se basa en el patrón de archivo Excel “Fields Inventory”. Los reportes que tienen que ser
considerados son solamente los derivados de la MSC. Aquellos reportes que simplemente exponen
balances de las cuentas PCASP no necesitan de armonización y contextualización, y por lo tanto serán
añadidos a la Taxonomía con un proceso automatizado y utilizados solamente a partir de la actividad de
finalización de la Taxonomía en Fujitsu XWand.
Las dos actividades “Colección de la Información en los Reportes” y “Armonización y Contextualización”
son descritas separadamente para claridad de exposición. Sin embargo están relacionadas la una con la
otra y en parte son conducidas al mismo tiempo, y en cuanto el EDT adquiera más experiencia en el
proceso la separación entre las dos tenderá a desaparecer.
Análisis del proceso para completar la actividad y de las columnas utilizadas en el patrón “Fields
Inventory”:
1. Cada campo que se analiza en el reporte se traslada a una línea en el archivo;
2. Columna A – “Group”: Nombre de la carpeta en la estructura de la Taxonomía que representa el grupo al cual el reporte pertenece;
3. Columna B – “Form/Document”: Nombre del archivo Excel (u otro tipo de archivo) de origen que representa el reporte;
4. Columna C – “Worksheet”: Nombre de la sección donde se encuentra el campo analizado (si es que el archivo Excel indicado en el punto anterior tiene múltiples secciones);
5. Columna D – “Cell”: la célula en el archivo Excel de origen donde que corresponde al campo analizado. Las columnas B, C y D permitirán relacionar cada elemento en la Taxonomía con el campo del reporte que el elemento representa;
6. Columna E – “Calculated Total/Net”: Indicar “T” si el campo es calculado como total de otros campos en el reporte, “N” si es calculado como neto de otros campos en el reporte;
7. Columna G – “Name”: El nombre del elemento primario que representa el campo analizado, derivado desde la descripción del campo analizado en el reporte (que se indicará en la columna W) y formado según los principios establecidos en la Arquitectura de la Taxonomía SICONFI. Particular atención se debe poner en el evitar caracteres prohibidos en nombres de elementos de acuerdo a la especificación XML;
8. Columna H e I – “Data Type Namespace” and “Data Type Local Name”: El “data type” más apropiado por el elemento entre los definidos en las especificaciones XML y XBRL, o los definidos en la Taxonomía, y el “namespace” donde el “data type” está definido. La Tabla 1 muestra los “data types” XML y XBRL y los “namespaces” relativos:
Tabla 1
XBRL Item Type Base type unitRef
attribute
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
XBRL Item Type Base type unitRef
attribute
decimalItemType Decimal yes
floatItemType Float yes
doubleItemType Double yes
The following numeric types are all based on the XML Schema built-in types that are
derived by restriction from decimal.
integerItemType Integer yes
nonPositiveIntegerItemType nonPositiveInteger yes
negativeIntegerItemType negativeInteger yes
longItemType Long yes
intItemType Int yes
shortItemType Short yes
byteItemType Byte yes
nonNegativeIntegerItemType nonNegativeInteger yes
unsignedLongItemType unsignedLong yes
unsignedIntItemType unsignedInt yes
unsignedShortItemType unsignedShort yes
unsignedByteItemType unsignedByte yes
positiveIntegerItemType positiveInteger yes
The following numeric types are all types that have been identified as having particular
relevance to the domain space addressed by XBRL and are hence included in addition to
the built-in types from XML Schema.
monetaryItemType xbrli:monetary yes
sharesItemType xbrli:shares yes
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
XBRL Item Type Base type unitRef
attribute
pureItemType xbrli:pure yes
fractionItemType complex type with the numerator
being a decimal and the denominator
being a non-zero, decimal
(xbrli:nonZeroDecimal)
yes
The following non-numeric types are all based on XML Schema built-in types that are
not derived from either decimal or string.
stringItemType String no
booleanItemType Boolean no
hexBinaryItemType hexBinary no
base64BinaryItemType base64Binary no
anyURIItemType anyURI no
QNameItemType QName no
durationItemType Duration no
dateTimeItemType xbrli:dateUnion (union of date and
dateTime)
no
timeItemType Time no
dateItemType Date no
gYearMonthItemType gYearMonth no
gYearItemType gYear no
gMonthDayItemType gMonthDay no
gDayItemType gDay no
gMonthItemType gMonth no
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
XBRL Item Type Base type unitRef
attribute
The following non-numeric types are all based on the XML Schema built-in types that
are derived by restriction (and/or list) from string.
normalizedStringItemType normalizedString no
tokenItemType Token no
languageItemType Language no
NameItemType Name no
NCNameItemType NCName no
“Data types” específicos de la Taxonomia tienen que ser definidos previamente en la Taxonomía
misma, y su nombre y “namespace” de definición tienen que ser indicados el Columna H e I;
9. Columna M – “Enumerations”: Lista de los valores posibles por el campo analizado, si existen, separados por una coma. Nota: la presencia de una lista de valores enumerados no determina necesariamente el uso de “enumerations”, en cuanto la misma información se puede generalmente representar definiendo una dimensión, que es, en general, la solución preferida;
10. Columna N – “Optionality”: Indicar “M” si el campo analizado es mandatorio en el reporte; 11. Columna O – “periodType”: Indicar “instant” o “duration” de acuerdo a los principios detallados
en la Arquitectura de la Taxonomía; 12. Columna P – “Balance”: Indicar “debit” o “credit” si el campo analizado tiene un signo contable
identificable; 13. Columna Q – “Label”: Descripción del campo analizado en el reporte (utilizada para derivar el
nombre del elemento en Columna G). Se utilizará para derivar la etiqueta genérica del elemento en la camada de definición;
14. Columna R – “Guidance”: Descripción más detallada del campo analizado en el reporte. Las columnas W y V se duplicaran por cada idioma soportado en la Taxonomía. Se utilizará para derivar la etiqueta genérica del elemento en la camada de definición;
15. Columna S – “Reference”: Indicar la información necesaria para identificar las referencias. Se creará el numero de columnas necesario para representar las varias partes de cada referencia, y el numero de referencias establecido en la Arquitectura de la Taxonomía. Se utilizará para derivar la referencia genérica del elemento en la camada de definición;
16. Columnas T, U y V – “Report label”, “Report Guidance” y “Report Reference”: Valen las mismas consideraciones descritas por las columnas 13, 14 y 15 por lo que se refiere a la duplicación de las etiquetas por idioma y a la representación de las partes por las referencias. Estas columnas proveen la información necesaria para derivar las etiquetas y referencias específicas en cada reporte;
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
17. Columna W – “Comments”: Cualquier comentario relativo al campo del reporte, al elemento que lo representa, o a su armonización y contextualización.
3 – Armonizacion y Contextualizacion
3.1 – Definición
La armonización de elementos definidos en la Taxonomía es el proceso por el cual se identifican campos
en los reportes analizados que tienen un significado idéntico o similar, y se les asigna el mismo elemento
para su representación en la taxonomía.
La contextualización de elementos definidos en la Taxonomía es el proceso por el cual se decide que
contextualización aplicar a cada elemento de acuerdo a los principios establecidos en la Arquitectura de
la Taxonomía.
Las dos actividades son conceptualmente distintas pero son interconectadas, en el sentido que
elementos que no han sido armonizados antes de su contextualización, especialmente si se les aplica
una contextualización dimensional, pueden ser armonizados como resultado de su contextualización. En
este sentido armonización y contextualización constituyen un proceso iterativo.
3.2 – Proceso Iterativo de Armonización y Contextualización
La armonización de dos líneas en el archivo “Fields Inventory” (correspondientes a dos campos en
reportes analizados en la actividad de colección de información) se obtiene indicando la misma
información en las columnas utilizadas para definir el elemento correspondiente en el esquema XML de
la Taxonomía. Esas columnas son:
Columna G – “Name”;
Columna H e I – “Data Type Namespace” and “Data Type Local Name”;
Columna M – “Enumerations”;
Columna O – “periodType”;
Columna P – “Balance”;
Todas las columnas utilizadas para derivar las etiquetas y referencias generales definidas en la camada de definición de la Taxonomía: Columna Q – “Label”, Columna R – “Guidance”, Columna S – “Reference” y todas las columnas derivadas de estas por duplicación.
Cuando se identifica un campo en un reporte que puede ser armonizado con otro que ya ha sido
representado en el archivo “Fields Inventory”, se copian y aplican los mismos valores indicados en esas
columnas por el primer campo. Los valores en las demás columnas identifican información específica del
reporte y por lo tanto serán diferentes por cada campo.
La armonización puede pasar en momentos distintos:
1. En el curso del desenvolvimiento de la actividad de colección de la información contenida en los reportes:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
a. En casos obvios, cuando el campo es evidentemente idéntico a otro ya analizado dentro del mismo reporte (y posiblemente la única diferencia es el instante de tiempo al cual la información en el reporte se refiere, como en el caso de Saldo Inicial/Saldo Final) o en otros reportes. El conocimiento especifico de los varios reportes facilita la identificación de estas situaciones, así como la análisis de requerimientos específicos de los reportes analizados, como por ejemplo la existencia de reconciliaciones entre valores de campos en distintos reportes –esto no significa necesariamente que los dos campos son semánticamente idénticos, pero es aconsejable averiguar;
b. En casos mas dudosos se puede hacer una nota en la columna “Comments” con el nombre del posible elemento ya existente, y revisar antes de la generación de la Taxonomía;
2. En general, se aconseja efectuar búsquedas en las columnas “Name” y “Label” del archivo en base a palabras clave que aparecerían en el nombre del nuevo elemento, para identificar posibles candidatos para la armonización;
3. Después de la aplicación de una contextualización dimensional a un elemento, si esto pasa en un momento sucesivo a la creación de la línea en el archivo que representa el elemento. La motivación es que la aplicación de dimensiones a un elemento anteriormente definido con calificación completa determina una mayor re-usabilidad del elemento mismo, y por lo tanto mayores posibilidades de armonización;
4. Después de la agregación de distintos archivos “Fields Inventory” relativos a distintos reportes y antes de importar los archivos agregados en Fujitsu XWand para la creación de la Taxonomía. Para facilitar la búsqueda de candidatos para la armonización se pueden utilizar recursos como el ordenamiento de las líneas en el archivo de acuerdo a las columnas “Name” o “Label”, o la búsqueda por palabras clave. Esta etapa del proceso es necesaria si no hay la posibilidad de trabajar colaborativamente en el mismo archivo “Fields Inventory”, pero es aconsejable también en caso de trabajo colaborativo, dependiendo del soporte facilitado por el ambiente colaborativo.
La actividad de contextualización consiste en indicar un valor en la Columna J – “Context Type” del
archivo “Fields Inventory”. Los valores posibles son:
S – “Simple” o “Fully Qualified”
DE - “Dimension – Explicit”
DT - “Dimension – Typed”
T - “Tuple”
La selección del valor debe ser consistente con los principios indicados en la Arquitectura de la
Taxonomía, en particular con la Sección 8 – Procesos de Contextualización.
Las Columnas K – “Context Name” y L – “Context Value” permiten indicar las características básicas de
los elementos de contextualización aplicables a un elemento primario, definidas por un par “Context
Name”/”Context Value”. Para indicar los elementos de contextualización se deben aplicar las reglas
siguientes, en función del valor indicado en la Columna J – “Context Type”:
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
1. Si el valor es “S”, ningún elemento de contextualización es necesario, siempre y cuando el elemento sea completamente calificado;
2. Si el valor es “DE”:
a. En la Columna K - “Context Name” se debe indicar el nombre de la dimensión definida;
b. En la Columna L – “Context Value” se debe indicar el nombre del “domain member” que corresponde al campo en el reporte representado por la línea en el fichero “Fields Inventory”;
c. Si al mismo campo se aplican otras dimensiones, se duplican las tres Columnas “Context Type”, “Context Name” y “Context Value” y se repite el punto 2.a hasta cuando todas las dimensiones son representadas. Si una o más de las dimensiones son de tipo “DT” se aplicaran los criterios definidos en el siguiente punto 3;
d. El resultado de este proceso es una serie de líneas en el fichero “Fields Inventory” que tienen los mismos valores en las columnas que definen el elemento primario, y distintos valores en las columnas que definen información dimensional;
3. Si el valor es “DT”:
a. En la Columna K - “Context Name” se debe indicar el nombre de la dimensión definida;
b. En la Columna L – “Context Value” se debe indicar el nombre del “domain declaration” correspondiente;
4. Si el valor es “T”:
a. En la Columna K - “Context Name” se debe indicar el nombre del “tuple” que contiene el elemento.
En particular cuando se aplica la contextualización “DE” o “DT” es posible que se modifique el nombre
del elemento, especialmente si la contextualización se aplica después de haber colectado todos los
campos del reporte en el fichero “Fields Inventory” como aparecen en el reporte mismo, implícitamente
aplicando una contextualización de tipo “S” a todos los elementos. Si este es el caso, después de haber
completado la contextualización – o en el mismo momento en el cual se aplica la contextualización a
cada elemento – se debe considerar si los cambios pueden tener consecuencias en términos de
armonización, y repetir el proceso relativo.
Gianluca Garbellotto 4207 Stanby Court Alexandria VA 22312 USA
Tel. +1 212 6574142 Email: [email protected]
Twitter: iphixbrl
Anexo 3 – Actividades Realizadas para el Desarrollo del Producto Actividad Día/Periodo
Definición de las características básicas de la arquitectura de la Taxonomía para discusión en la semana del 22-26 de Octubre
2/10-9/10/2012
Definición de las utilización de XBRL GL en la arquitectura de la Taxonomía: perfil utilizado, número y tipo de instancias XBRL GL necesarias, estructura de las instancias
11/10-16/10/2012
Presentación del material en la reunión plenaria 22/10/2012
Reuniones sobre varios asuntos – reportes estadísticos, nueva representación de la MSC, infraestructura informática
23/10/2012
Trabajo off-line en la arquitectura basado sobre los resultados de la discusión plenaria
23-24/10/2012
Presentación de la arquitectura, discusión sobre los procesos para crear la Taxonomía
25/10/2012
Discusión sobre la utilización de hojas de calculo Excel como patrones para el desarrollo de la Taxonomía y de varios problemas relativos a la infraestructura informática
26/10/2012
Preparación del documento final de arquitectura, de los patrones Excel y procesos para su utilización y del informe relativo
27/10-7/11/2012