Informe Sobre la Arquitectura de la Taxonomía SICONFI y ... · informação, a modularização da taxonomia, as convenções de nomenclatura, a definição e o uso de ... Los principios

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:



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:



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.



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;



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



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.



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:

http://www.sbr.gov.au/



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;



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:



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”




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.


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.



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



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;



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.



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]



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


Domain member Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Member” al final


Hypercube Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Table” al final


Abstract Derivado aplicando las mismas reglas detalladas por los elementos primarios y añadiendo “Abstract” al final


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



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



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.



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:



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.



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.



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.



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



Twitter: iphixbrl


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



Twitter: iphixbrl


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



Twitter: iphixbrl


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;



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:



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”:



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.



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

Documents

Informe Sobre la Arquitectura de la Taxonomía SICONFI y ... · informação, a modularização da taxonomia, as convenções de nomenclatura, a definição e o uso de ... Los principios