Desde 2018, el Banco Central de Rusia (como regulador) ha obligado a las instituciones financieras no crediticias (IFN), es decir todas las empresas del sector financiero de la economía, excepto bancos, a saber, seguros, fondos de pensiones, prof. Los participantes en el mercado de valores, las compañías de gestión, le informan en un nuevo formato, de acuerdo con la especificación XBRL (y no Excel o XML).
El alcance de los informes de supervisión (estadística) incluye información sobre fundadores y clientes, objetos de seguros, primas y pagos, depósitos e inversiones, contrapartes, etc. etc. - Realmente cientos de miles de hechos. En este sentido, para facilitar la burocracia y mantener la precisión del procedimiento, hablaremos sobre el proyecto de automatización de la presentación de informes en XBRL de un gran NFO, que se basó en la solución Fujitsu XBRL.
Además del regulador, los informes contables, que tienen potencialmente más destinatarios, así como los sitios de impuestos, intercambio y licitación, también se transfirieron al formato XBRL. Debe recordarse que el objetivo final del Banco Central es transferir bancos a XBRL para poder monitorear lo más rápido y profundamente posible.
Una breve introducción a XBRL
XBRL: el Lenguaje de informes comerciales extensible, o "Lenguaje de informes comerciales extensible", fue creado para modelar formularios de informes y como un formato para los indicadores de informes a las compañías de informes.
Tradicionalmente, algunas personas (metodólogos del regulador, el Banco Central) crearon formularios de informes, rellenados por otras personas (contadores de las organizaciones informantes) y verificados por terceros (expertos ordinarios del Banco Central).
El volumen de informes está aumentando: el número de indicadores ya ha aumentado a miles y, al mismo tiempo, han comenzado a enviarlo con más frecuencia. Por ejemplo, los bancos informan al regulador diariamente. En tales condiciones, llenar y procesar informes manualmente se vuelve más costoso, por lo que es aconsejable utilizar la automatización en estas condiciones.
La interfaz "hombre-hombre" se reemplaza por la interfaz "máquina-máquina", donde se necesita una especificación matemáticamente precisa del formato de los datos transmitidos, que se convirtió en XBRL.
La primera especificación XBRL fue creada hace unos 20 años por la Asociación Americana de Contadores Certificados. El formato es tan extensible (extensible) como el XML subyacente; pero si las extensiones XML son diferentes lenguajes de marcado, las extensiones XBRL son modelos de diferentes áreas temáticas ("dominios"). Por ejemplo, un modelo de estados financieros contables / de acuerdo con las NIIF o un modelo de formularios de impuestos.
La base del lenguaje XBRL, como cualquier idioma, es un diccionario, es decir una lista de palabras ("conceptos") escritas en latín y que tienen sus propios atributos (tipo de datos, pertenecientes a las categorías "en una fecha" / "por un período" y débito / crédito, la bandera de "resumen").
Luego, utilizando el vocabulario del área temática, se modelan todas las formas que componen los informes.
Un modelo XBRL es, en el caso más simple, una secuencia de conceptos de lenguaje, es decir, orden dado de su secuencia. Primero, activos, luego pasivos y capital; efectivo primero, luego depósitos. Solo asi. Sin espacios ni líneas adicionales.
Un modelo de formulario típico es una combinación de elementos y secciones analíticas a lo largo de ejes geométricos (X, Y e incluso Z) dados en un cierto orden.
La "superposición" de secciones analíticas y períodos de informes se "presenta" a lo largo de los ejes X e Y.
Antes del advenimiento de XBRL, los indicadores en los formularios no fueron nombrados, y cuando se agregó un nuevo indicador, se hizo difícil comparar el formulario para el período anterior y el nuevo.
Del mismo modo, los controles entre formularios se "atan" en el interior, se vinculan solo a los números de fila y columna. Con nuevas ediciones, la complejidad aumenta de forma no lineal. En XBRL, las fórmulas en los controles consisten en variables con nombre, por lo que no es necesario cambiar la relación de control cuando se cambian los diseños de los formularios.
Solución Fujitsu XBRL
El enfoque habitual del proveedor (la mayoría de las veces es franquiciado de 1C, es decir, empresas asociadas de 1C) para agregar exportaciones a XBRL es marcar las filas / columnas en los diseños de informes y producir una secuencia de conceptos de "hechos" al exportar. La instancia resultante (instancia: “instancia / informe XBRL”) se valida para el cumplimiento de XML, XBRL (más las relaciones de control se comparan con sus hechos) utilizando software gratuito o comercial (por ejemplo, Arelle o Altova).
La dificultad para un proveedor de este tipo es que al crear un documento XBRL (como un archivo de texto), se deben observar todas las reglas de la sintaxis XBRL: la ausencia de hechos y "contextos" duplicados y, lo más importante, la correspondencia de la taxonomía. Los hechos en el informe creado deben corresponder a la taxonomía por nombre y tipo, las tablas, de acuerdo con la presencia de secciones analíticas obligatorias. La imagen de los cambios en la taxonomía en sí, que debe ser respaldada junto con las versiones anteriores, agrava la imagen (el Banco Central puede solicitar en cualquier momento volver a tomar los informes del período anterior).
Y si las empresas rusas se enfrentaron a la necesidad de apoyar XBRL en 2017, entonces Fujitsu tiene una historia mucho más larga de competencias en XBRL. Tiene su origen en 2006, cuando todas las empresas que cotizan en la Bolsa de Tokio (Bolsa de Tokio) se vieron obligadas a revelar sus indicadores clave en XBRL.
Fujitsu tiene su propio procesador XBRL certificado, utilizado por los reguladores en muchos países europeos, que le permite cargar una taxonomía en la memoria y crear un informe XBRL no como un archivo de texto, sino como un tipo de modelo de objeto de documento (DOM).
En base a este procesador, se han creado herramientas que pueden ser utilizadas tanto por las compañías de informes como por los reguladores. El Banco Central de la Federación de Rusia también lo eligió para crear una taxonomía rusa.
Si estamos hablando de una integración más profunda con los sistemas de contabilidad (conversión automática de informes a XBRL), entonces aquí también usamos un enfoque de 3 niveles más flexible y potente.
No se requiere que los desarrolladores del sistema contable marquen cada informe y admitan dicho marcado. Por lo general, cualquier informe se puede guardar como un archivo de Excel, pero para nosotros es necesario guardarlo como un simple vector de "celdas" (valor de fila-col). Por ejemplo, la siguiente ilustración.
Una tabla de 4 columnas y 12 filas se convierte en 48 celdas. Este formato de presentación no relacional proporciona la máxima flexibilidad. Para cada diseño, también puede limitar el área de descarga para no incluir los encabezados de fila y columna de la tabla, el encabezado y el pie de página del informe, lo que además acelera la transferencia de datos en la solución de integración.
El segundo enlace de nuestra arquitectura es el marcado de las formas reales del cliente. Debido al hecho de que hay muchos sistemas de contabilidad diferentes (configuraciones estándar y diseños propietarios 1C, "no 1C" como SAP y Oracle), los diseños de informes son diferentes y las coordenadas también serán diferentes. En general, cada cliente tiene sus propios diseños (ejemplo a continuación).
El color marca las áreas del diseño que corresponden a diferentes elementos de la taxonomía. Tal marcado se formaliza de manera elemental: primero en la lengua del pájaro y luego en los conceptos de taxonomía:
Además, si las coordenadas de las regiones (las primeras 4 columnas) pueden cambiar de un cliente a otro, entonces los elementos de la taxonomía siguen siendo comunes a todos. Por lo tanto, el segundo enlace también es muy ligero y flexible.
Además, si hay cambios en los diseños o la taxonomía, cargamos las asignaciones como parte de la configuración (hay versiones), sin cambiar el código, o incluso sin reiniciar la solución.
La elección de dicho esquema de integración se inspiró en el mecanismo de codificación RC utilizado en algunas taxonomías europeas. Junto con los conceptos "humanos", cada fila y cada columna del informe también está marcada con códigos numéricos, es decir, Todos los rangos ya están numerados por los creadores de la taxonomía. En la taxonomía del Banco Central de la Federación de Rusia, esta capa también está presente, pero aún no está en todas las tablas.
Este mecanismo le permite marcar incluso aquellos formularios que no pueden modelarse usando Table LinkBase, la extensión más avanzada del estándar XBRL.
La intersección de hechos y mapeos es utilizada por el tercer enlace. Usando un procesador XBRL que contiene una taxonomía en la memoria, creamos un modelo de documento de informe; y sobre todos los errores en el proceso que escribimos en el registro y advertimos al usuario.
Si se trata de errores en los datos (falta de coincidencia de tipos o formatos, por ejemplo), el contador lo comprende; Si hay errores en el mapeo, el analista lo comprende. Por lo tanto, la validación ocurre en la etapa más temprana y al nivel de los formularios individuales (y no solo el informe completo). Por supuesto, el informe de la memoria en cualquier momento se puede guardar en el disco.
El núcleo del procesador XBRL está escrito en Java, mientras que nosotros escribimos en Java. De hecho, todos los métodos del núcleo están disponibles a través de la API para .NET.
Otras tecnologías son bastante estándar: la interfaz de usuario en React JS; por lo tanto, los contadores pueden trabajar con el sistema simplemente a través de un navegador (lo cual es importante en grandes empresas donde existen reglas estrictas de seguridad para las instalaciones de software).
Al mismo tiempo, hay integración con Active Directory. Anverso y reverso están conectados a través de REST API También se utiliza para la integración con sistemas contables. Los métodos se documentan automáticamente usando Swagger.
Para los usuarios, el proceso parece lo más simple posible. Después de cerrar el período en el sistema contable, el contador genera un informe. Con un solo clic, lo transfiere a XBRL, tal como puede imprimir. Después de eso, en la interfaz web, el contador ve un render html del mismo informe (basado en la capa TableLinkbase de la taxonomía para asegurarse de que los datos se hayan "establecido") y ve si hay algún error y, de ser así, cuáles.
Todo el volumen de informes (N tablas) se puede dividir por el jefe entre varios contadores responsables y especialistas. Si algunos formularios están ausentes en el sistema de contabilidad, los responsables pueden descargarlos de Excel, que son "cortados" por una herramienta de software especial en un vector de hechos similar a la ilustración No. 3. Cuando todas las tablas están "listas" sin errores críticos, el gerente descarga el informe final y lo carga en su cuenta personal en el sitio web del Banco Central.
En conclusión
Aquí hay una solución profundamente integrada. No requiere pasos de conversión adicionales y cubre todo el volumen de informes.
Muchos proveedores se vieron obligados a incluir el soporte de XBRL en sus decisiones lo antes posible, por lo que invito a analistas y programadores a discutir aquí temas delicados.