Depuis 2018, la Banque centrale russe (en tant que régulateur) a obligé les institutions financières non financières (IFN), c'est-à-dire toutes les entreprises du secteur financier de l'économie, à l'exception des banques, à savoir l'assurance, les fonds de pension, le prof. les acteurs du marché des valeurs mobilières, les sociétés de gestion, lui rendent compte dans un nouveau format - selon la spécification XBRL (et non Excel ou XML).
Le champ d'application des rapports de surveillance (statistiques) comprend des informations sur les fondateurs et les clients, les objets d'assurance, les primes et paiements, les dépôts et investissements, les contreparties, etc. etc. - Vraiment des centaines de milliers de faits. À cet égard, afin de faciliter les formalités administratives et de maintenir la précision de la procédure, nous parlerons du projet d'automatisation du reporting en XBRL d'un grand NFO, qui était basé sur la solution Fujitsu XBRL.
Outre le régulateur, les rapports comptables, qui ont potentiellement plus de destinataires, ainsi que les sites fiscaux, d'échange et d'appel d'offres, ont également été transférés au format XBRL. Il convient de rappeler que l'objectif ultime de la Banque centrale est de transférer les banques vers XBRL afin de pouvoir effectuer un suivi le plus rapidement et le plus profondément possible.
Une brève introduction à XBRL
XBRL - eXtensible Business Reporting Language, ou «Extensible Business Reporting Language», a été créé pour modéliser les formulaires de déclaration et comme format de déclaration des indicateurs aux sociétés déclarantes.
Traditionnellement, les formulaires de déclaration étaient créés par certaines personnes (méthodologistes du régulateur - la Banque centrale), remplis par d'autres personnes (comptables des organisations déclarantes) et vérifiés par des tiers (spécialistes ordinaires de la Banque centrale).
Le volume de rapports augmente: le nombre d'indicateurs est déjà passé à des milliers et, en même temps, ils ont commencé à le soumettre plus souvent. Par exemple, les banques font quotidiennement rapport au régulateur. Dans de telles conditions, le remplissage et le traitement des rapports manuellement deviennent plus coûteux, il est donc conseillé d'utiliser l'automatisation dans ces conditions.
L'interface «homme-homme» est remplacée par l'interface «machine-machine», où une spécification mathématiquement précise du format des données transmises est devenue XBRL.
La première spécification XBRL a été créée il y a environ 20 ans par l'American Association of Certified Accountants. Le format est aussi extensible (extensible) que le XML sous-jacent; mais si les extensions XML sont des langages de balisage différents, les extensions XBRL sont des modèles de différents domaines («domaines»). Par exemple, un modèle d'états financiers comptables / conforme aux IFRS ou un modèle de formulaires fiscaux.
La base de la langue XBRL, comme toute langue, est un dictionnaire, c'est-à-dire une liste de mots («concepts») écrits en latin et ayant leurs propres attributs (type de données, appartenant aux catégories «par date» / «pour la période» et débit / crédit, drapeau «abstrait»).
Ensuite, en utilisant le vocabulaire du domaine, tous les formulaires qui composent le rapport sont modélisés.
Un modèle XBRL est dans le cas le plus simple une séquence de concepts de langage, c'est-à-dire étant donné l'ordre de leur séquence. Tout d'abord, l'actif, puis le passif et le capital; l'argent d'abord, puis les dépôts. Comme ça. Pas d'écarts et pas de lignes supplémentaires.
Un modèle de formulaire typique est une combinaison d'éléments et de sections analytiques le long d'axes géométriques (X, Y et même Z) donnés dans un certain ordre.
La «superposition» des sections analytiques et des périodes de rapport est «disposée» le long des axes X et Y.
Avant l'avènement de XBRL, les indicateurs dans les formulaires n'étaient pas nommés et lorsqu'un nouvel indicateur était ajouté, il devenait difficile de comparer le formulaire pour l'ancienne période et la nouvelle.
De la même manière, les contrôles inter-formulaires «liés» à l'intérieur, liés uniquement aux numéros de ligne et de colonne. Avec les nouvelles modifications, la complexité augmente de façon non linéaire. Dans XBRL, les formules dans les contrôles sont constituées de variables nommées, de sorte que le rapport de contrôle n'a pas du tout besoin d'être modifié lors de la modification des dispositions de formulaires.
Fujitsu XBRL Solution
L'approche habituelle du fournisseur (le plus souvent, c'est un franchisé 1C, c'est-à-dire des sociétés partenaires 1C) pour ajouter des exportations à XBRL consiste à marquer des lignes / colonnes dans les présentations de rapport et à produire une séquence de concepts de «faits» lors de l'exportation. L'instance résultante (instance - «instance / rapport XBRL») est ensuite validée pour la conformité XML, XBRL (plus les ratios de contrôle sont vérifiés par rapport à ses faits) à l'aide d'un logiciel gratuit ou commercial (par exemple, Arelle ou Altova).
La difficulté pour un tel fournisseur est que lors de la création d'un document XBRL (sous forme de fichier texte), toutes les règles de la syntaxe XBRL doivent être respectées: l'absence de faits et de "contextes" en double et, surtout, la correspondance de la taxonomie. Les faits dans le rapport créé doivent correspondre à la taxonomie par nom et type, aux tableaux - selon la présence de sections analytiques obligatoires. L'image des changements dans la taxonomie elle-même, qui doit être prise en charge avec les versions précédentes, aggrave l'image (la Banque centrale peut à tout moment demander à reprendre les rapports de la période écoulée).
Et si les entreprises russes étaient confrontées à la nécessité de prendre en charge XBRL en 2017, Fujitsu a un historique de compétences beaucoup plus long en XBRL. Il est enraciné en 2006, lorsque toutes les sociétés cotées à la Bourse de Tokyo (Tokyo Stock Exchange) ont été obligées de divulguer leurs indicateurs clés dans XBRL.
Fujitsu possède son propre processeur XBRL certifié, utilisé par les régulateurs de nombreux pays européens, qui vous permet de charger une taxonomie en mémoire et de créer un rapport XBRL non pas comme un fichier texte, mais comme une sorte de modèle d'objet de document (DOM).
Sur la base de ce processeur, des outils ont été créés qui peuvent être utilisés à la fois par les sociétés déclarantes et les régulateurs. La Banque centrale de la Fédération de Russie l'a également choisie pour créer une taxonomie russe.
Si nous parlons d'une intégration plus approfondie avec les systèmes comptables (conversion automatique des rapports en XBRL), nous utilisons ici également une approche à trois niveaux plus flexible et puissante.
Les développeurs du système comptable ne sont pas tenus de baliser chaque rapport et de prendre en charge un tel balisage. Habituellement, tout rapport peut être enregistré sous forme de fichier Excel, mais pour nous, il est nécessaire de l'enregistrer comme un simple vecteur de "cellules" (valeur de ligne-col). Par exemple, l'illustration ci-dessous.
Un tableau de 4 colonnes et 12 lignes se transforme en 48 cellules. Ce format de présentation non relationnel offre une flexibilité maximale. Pour chaque présentation, vous pouvez en outre limiter la zone de déchargement afin de ne pas inclure les en-têtes de ligne et de colonne du tableau, l'en-tête et le pied de page du rapport, ce qui accélère en outre le transfert de données dans la solution d'intégration.
Le deuxième maillon de notre architecture est le marquage des formes réelles du client. En raison du fait qu'il existe de nombreux systèmes comptables différents (configurations standard et conceptions propriétaires 1C, «non 1C» comme SAP et Oracle), les dispositions de rapport sont différentes et les coordonnées seront également différentes. En général, chaque client a ses propres dispositions (exemple ci-dessous).
La couleur marque les zones de la mise en page qui correspondent aux différents éléments de la taxonomie. Un tel balisage est formalisé de manière élémentaire - d'abord dans la langue de l'oiseau, puis dans les concepts de taxonomie:
De plus, si les coordonnées des régions (les 4 premières colonnes) peuvent changer de client en client, alors les éléments de la taxonomie restent communs à tous. Par conséquent, le deuxième lien est également très léger et flexible.
De plus, s'il y a des changements de mise en page ou de taxonomie, on charge les mappages dans le cadre de la configuration (il y a du versioning), sans changer le code, ni même sans redémarrer la solution.
Le choix d'un tel schéma d'intégration s'est inspiré du mécanisme de codage RC utilisé dans certaines taxonomies européennes. Parallèlement aux concepts «humains», chaque ligne et chaque colonne du rapport est également marquée par des codes numériques, c'est-à-dire toutes les gammes sont déjà numérotées par les créateurs de la taxonomie. Dans la taxonomie de la Banque centrale de la Fédération de Russie, cette couche est également présente, mais pas encore dans tous les tableaux.
Ce mécanisme vous permet de marquer même les formulaires qui ne peuvent pas être modélisés à l'aide de Table LinkBase, l'extension la plus avancée de la norme XBRL.
L'intersection des faits et des mappages est utilisée par le troisième lien. À l'aide d'un processeur XBRL qui contient une taxonomie en mémoire, nous créons un modèle de document de rapport; et sur toutes les erreurs dans le processus, nous écrivons dans le journal et avertissons l'utilisateur.
S'il s'agit d'erreurs dans les données (incompatibilité de types ou de formats, par exemple) - le comptable comprend; s'il y a des erreurs dans le mappage, l'analyste comprend. Ainsi, la validation intervient au stade le plus précoce et au niveau des formulaires individuels (et pas seulement de l'ensemble du reporting). Bien sûr, le rapport de la mémoire à tout moment peut être enregistré sur le disque.
Le cœur du processeur XBRL est écrit en Java, tandis que nous écrivons en Java. En fait, toutes les méthodes du noyau sont disponibles via l'API pour .NET.
D'autres technologies sont assez standard: l'interface utilisateur sur React JS; par conséquent, les comptables peuvent travailler avec le système simplement via un navigateur (ce qui est important dans les grandes entreprises où il existe des règles de sécurité strictes pour les installations de logiciels).
Dans le même temps, il y a intégration avec Active Directory. L'avant et l'arrière sont connectés via l'API REST; Il est également utilisé pour l'intégration avec les systèmes comptables. Les méthodes sont automatiquement documentées à l'aide de Swagger.
Pour les utilisateurs, le processus semble aussi simple que possible. Après avoir clôturé la période dans le système comptable, le comptable génère un rapport. En un clic, il le transfère vers XBRL, tout comme il peut imprimer. Après cela, dans l'interface Web, le comptable voit un rendu html du même rapport (basé sur la couche TableLinkbase de la taxonomie pour s'assurer que les données ont "établi") et voit s'il y a des erreurs et si oui, lesquelles.
L'ensemble du volume de reporting (N tableaux) peut être réparti à la tête entre plusieurs comptables et spécialistes responsables. Si certains formulaires sont absents du système comptable, les responsables peuvent les télécharger depuis Excel, qui sont «coupés» par un outil logiciel spécial en un vecteur de faits similaire à l'illustration n ° 3. Lorsque tous les tableaux sont «prêts» sans erreurs critiques, le gestionnaire télécharge le rapport final et le télécharge sur votre compte personnel sur le site Web de la Banque centrale.
En conclusion
Voici une solution profondément intégrée. Il ne nécessite pas d'étapes de conversion supplémentaires et couvre l'intégralité du volume de rapports.
De nombreux fournisseurs ont été obligés d'inclure le support XBRL dans leurs décisions dès que possible, donc j'invite les analystes et les programmeurs à discuter des questions sensibles ici.