Desde 2018, o Banco Central da Rússia (como regulador) obrigou instituições financeiras sem crédito (NFIs), ou seja, todas as empresas do setor financeiro da economia, exceto bancos, nomeadamente seguros, fundos de pensões, prof. participantes do mercado de valores mobiliários, empresas de gestão, reportam a ele em um novo formato - de acordo com a especificação XBRL (e não com excelência ou xml).
O escopo dos relatórios de supervisão (estatísticos) inclui informações sobre fundadores e clientes, objetos de seguros, prêmios e pagamentos, depósitos e investimentos, contrapartes etc. etc. - Realmente centenas de milhares de fatos. Nesse sentido, para facilitar a burocracia e manter a precisão do procedimento, falaremos sobre o projeto de automação de relatórios em XBRL de um grande NFO, que foi baseado na solução Fujitsu XBRL.
Além do regulador, os relatórios contábeis, que têm potencialmente mais destinatários, bem como os sites de impostos, câmbio e licitações, também foram transferidos para o formato XBRL. Deve-se lembrar que o objetivo final do Banco Central é transferir bancos para o XBRL, a fim de poder monitorar o mais rápido e profundamente possível.
Uma breve introdução ao XBRL
O XBRL - eXtensible Business Reporting Language, ou “Extensible Business Reporting Language”, foi criado para modelar formulários de relatório e como um formato para relatórios de indicadores para empresas que relatam.
Tradicionalmente, os formulários de relatórios eram criados por algumas pessoas (metodologias do regulador - Banco Central), preenchidos por outras pessoas (contadores de organizações responsáveis) e verificados por terceiros (especialistas comuns do Banco Central).
O volume de relatórios está aumentando: o número de indicadores já aumentou para milhares e, ao mesmo tempo, começaram a enviá-lo com mais frequência. Por exemplo, os bancos reportam ao regulador diariamente. Nessas condições, o preenchimento e o processamento de relatórios manualmente se tornam mais caros, por isso é aconselhável usar a automação nessas condições.
A interface "homem-homem" é substituída pela interface "máquina-máquina", onde é necessária uma especificação matematicamente precisa do formato dos dados transmitidos, que se tornou XBRL.
A primeira especificação XBRL foi criada há cerca de 20 anos pela Associação Americana de Contadores Certificados. O formato é tão extensível (eXtensible) quanto o XML subjacente; mas se as extensões XML forem diferentes linguagens de marcação, as extensões XBRL serão modelos de diferentes áreas de assunto ("domínios"). Por exemplo, um modelo de Demonstrações Financeiras Contábeis / de acordo com o IFRS ou um modelo de formulários de imposto.
A base do idioma XBRL, como qualquer idioma, é um dicionário, ou seja, uma lista de palavras (“conceitos”) escritas em latim e com atributos próprios (tipo de dados, pertencentes às categorias “em uma data” / “por um período” e débito / crédito, bandeira de “resumo”).
Em seguida, usando o vocabulário da área de assunto, todas as formas que compõem o relatório são modeladas.
Um modelo XBRL é, no caso mais simples, uma sequência de conceitos de linguagem, ou seja, dada ordem de sua sequência. Primeiro, ativos, depois passivos e capital; primeiro dinheiro, depois depósitos. Assim mesmo. Sem lacunas e sem linhas extras.
Um modelo de formulário típico é uma combinação de elementos e seções analíticas ao longo de eixos geométricos (X, Y e até Z) dados em uma determinada ordem.
A "superposição" de seções analíticas e períodos de relatório é "definida" ao longo dos eixos X e Y.
Antes do advento do XBRL, os indicadores nos formulários não eram nomeados e, quando um novo indicador foi adicionado, tornou-se difícil comparar o formulário para o período antigo e o novo.
Da mesma forma, os controles entre formulários "amarram" no interior, vinculados apenas aos números de linhas e colunas. Com novas edições, a complexidade aumenta de maneira não linear. No XBRL, as fórmulas nos controles consistem em variáveis nomeadas; portanto, a taxa de controle não precisa ser alterada ao alterar layouts de formulários.
Solução Fujitsu XBRL
A abordagem usual do fornecedor (na maioria das vezes, é o franqueado 1C, ou seja, empresas parceiras 1C) para adicionar exportações ao XBRL é marcar as linhas / colunas nos layouts de relatório e produzir uma sequência de conceitos de "fatos" ao exportar. A instância resultante (instância - "instância / relatório XBRL") é então validada para conformidade com XML, XBRL (mais taxas de controle são verificadas com relação a seus fatos) usando software gratuito ou comercial (por exemplo, Arelle ou Altova).
A dificuldade para esse fornecedor é que, ao criar um documento XBRL (como um arquivo de texto), todas as regras da sintaxe XBRL devem ser observadas: a ausência de fatos e "contextos" duplicados e, mais importante, a correspondência da taxonomia. Os fatos no relatório criado devem corresponder à taxonomia por nome e tipo, as tabelas - de acordo com a presença de seções analíticas obrigatórias. A imagem das mudanças na taxonomia em si, que deve ser apoiada com as versões anteriores, agrava a imagem (o Banco Central pode, a qualquer momento, solicitar a retomada dos relatórios do período anterior).
E se as empresas russas foram confrontadas com a necessidade de oferecer suporte ao XBRL em 2017, a Fujitsu tem um histórico muito maior de competências no XBRL. Está enraizada em 2006, quando todas as empresas listadas na Bolsa de Tóquio (Tokyo Stock Exchange) foram obrigadas a divulgar seus principais indicadores no XBRL.
A Fujitsu possui seu próprio processador XBRL certificado, usado por reguladores em muitos países europeus, o que permite carregar uma taxonomia na memória e criar um relatório XBRL não como um arquivo de texto, mas como uma espécie de modelo de objeto de documento (DOM).
Com base nesse processador, foram criadas ferramentas que podem ser usadas pelas empresas relatoras e pelos reguladores. O Banco Central da Federação Russa também o escolheu para criar uma taxonomia russa.
Se estivermos falando de uma integração mais profunda com os sistemas de contabilidade (conversão automática de relatórios em XBRL), também aqui usaremos uma abordagem de três camadas mais flexível e poderosa.
Os desenvolvedores do sistema contábil não precisam marcar cada relatório e dar suporte a essa marcação. Geralmente, qualquer relatório pode ser salvo como um arquivo do Excel, mas para nós é necessário salvá-lo como um vetor simples de "células" (valor da linha-col). Por exemplo, a ilustração abaixo.
Uma tabela de 4 colunas e 12 linhas se transforma em 48 células. Este formato de apresentação não relacional fornece flexibilidade máxima. Para cada layout, é possível limitar adicionalmente a área de descarregamento para não incluir os títulos de linha e coluna da tabela, o cabeçalho e o rodapé do relatório, o que acelera adicionalmente a transferência de dados na solução de integração.
O segundo link de nossa arquitetura é a marcação das formas reais do cliente. Devido ao fato de existirem muitos sistemas de contabilidade diferentes (configurações padrão e designs proprietários 1C, “não-1C” como SAP e Oracle), os layouts de relatórios são diferentes e as coordenadas também serão diferentes. Em geral, cada cliente tem seus próprios layouts (exemplo abaixo).
A cor marca as áreas do layout que correspondem a diferentes elementos da taxonomia. Essa marcação é formalizada de maneira elementar - primeiro na língua do pássaro e depois nos conceitos de taxonomia:
Além disso, se as coordenadas das regiões (as 4 primeiras colunas) podem mudar de cliente para cliente, os elementos da taxonomia permanecem comuns a todos. Portanto, o segundo link também é muito leve e flexível.
Além disso, se houver alterações nos layouts ou na taxonomia, carregamos os mapeamentos como parte da configuração (existe versão), sem alterar o código ou mesmo sem reiniciar a solução.
A escolha desse esquema de integração foi inspirada no mecanismo de codificação RC usado em algumas taxonomias européias. Juntamente com os conceitos "humanos", cada linha e cada coluna do relatório também são marcadas com códigos numéricos, ou seja, todos os intervalos já estão numerados pelos criadores da taxonomia. Na taxonomia do Banco Central da Federação Russa, essa camada também está presente, mas ainda não está presente em todas as tabelas.
Esse mecanismo permite marcar até mesmo os formulários que não podem ser modelados usando o Table LinkBase, a extensão mais avançada do padrão XBRL.
A interseção de fatos e mapeamentos é usada pelo terceiro link. Usando um processador XBRL que possui uma taxonomia na memória, criamos um modelo de documento de relatório; e sobre todos os erros no processo que escrevemos no log e avisamos o usuário.
Se houver erros nos dados (incompatibilidade de tipos ou formatos, por exemplo) - o contador entende; se houver erros no mapeamento, o analista entenderá. Assim, a validação ocorre no estágio inicial e no nível de formulários individuais (e não apenas em todo o relatório). Obviamente, o relatório da memória a qualquer momento pode ser salvo no disco.
O núcleo do processador XBRL é escrito em Java, enquanto escrevemos em Java. De fato, todos os métodos do kernel estão disponíveis através da API para .NET.
Outras tecnologias são bastante padrão: a interface do usuário no React JS; portanto, os contadores podem trabalhar com o sistema simplesmente por meio de um navegador (o que é importante em grandes empresas onde existem regras estritas de segurança para instalações de software).
Ao mesmo tempo, há integração com o Active Directory. Frente e verso são conectados via API REST; Também é usado para integração com sistemas de contabilidade. Os métodos são documentados automaticamente usando o Swagger.
Para os usuários, o processo parece o mais simples possível. Após o encerramento do período no sistema contábil, o contador gera um relatório. Em um clique, ele o transfere para o XBRL, assim como pode ser impresso. Depois disso, na interface da web, o contador vê uma renderização html do mesmo relatório (com base na camada TableLinkbase da taxonomia para garantir que os dados foram "fornecidos") e verifica se há algum erro e, em caso afirmativo, quais.
Todo o volume de relatórios (N tabelas) pode ser dividido pela cabeça entre vários contadores e especialistas responsáveis. Se alguns formulários estiverem ausentes no sistema contábil, os responsáveis poderão baixá-los do Excel, que são "cortados" por uma ferramenta de software especial em um vetor de fatos semelhante à ilustração nº 3. Quando todas as tabelas estão "prontas" sem erros críticos, o gerente baixa o relatório final e o envia para sua conta pessoal no site do Banco Central.
Em conclusão
Aqui está uma solução profundamente integrada. Não requer etapas de conversão adicionais e abrange todo o volume de relatórios.
Muitos fornecedores foram forçados a incluir o suporte ao XBRL em suas decisões o mais rápido possível, por isso convido analistas e programadores para discutir questões delicadas aqui.