Seit 2018 hat die russische Zentralbank (als Regulierungsbehörde) Nicht-Kredit-Finanzinstitute (NFIs) verpflichtet, d. H. alle Unternehmen des Finanzsektors der Wirtschaft mit Ausnahme der Banken, nämlich Versicherungen, Pensionskassen, prof. Wertpapiermarktteilnehmer, Verwaltungsgesellschaften, berichten in einem neuen Format - gemäß der XBRL-Spezifikation (und nicht Excel oder XML).
Der Umfang der aufsichtsrechtlichen (statistischen) Berichterstattung umfasst Informationen zu Gründern und Kunden, Versicherungsobjekten, Prämien und Zahlungen, Einlagen und Investitionen, zu Gegenparteien usw. usw. - Wirklich hunderttausende Fakten. In diesem Zusammenhang werden wir zur Erleichterung des bürokratischen Aufwands und zur Aufrechterhaltung der Genauigkeit des Verfahrens über das Projekt der Automatisierung der Berichterstellung in XBRL eines großen NFO sprechen, das auf Fujitsu XBRL basiert.
Neben der Regulierungsbehörde wurden auch die Buchhaltungsberichte, die möglicherweise mehr Empfänger haben, sowie die Steuer-, Börsen- und Ausschreibungsstellen in das XBRL-Format übertragen. Es sei daran erinnert, dass das ultimative Ziel der Zentralbank darin besteht, Banken an XBRL zu überweisen, um so schnell und tief wie möglich überwachen zu können.
Eine kurze Einführung in XBRL
XBRL - eXtensible Business Reporting Language oder „Extensible Business Reporting Language“ wurde erstellt, um Berichtsformulare zu modellieren und als Format für die Berichterstattung von Indikatoren an berichtende Unternehmen.
Traditionell wurden Berichtsformulare von einigen Personen (Regulierungsmethoden - die Zentralbank) erstellt, von anderen Personen (Buchhalter von rechenschaftspflichtigen Organisationen) ausgefüllt und von Dritten (gewöhnlichen Spezialisten der Zentralbank) geprüft.
Das Berichtsvolumen nimmt zu: Die Anzahl der Indikatoren ist bereits auf Tausende angewachsen, und gleichzeitig haben sie begonnen, sie häufiger einzureichen. Zum Beispiel berichten Banken täglich an die Aufsichtsbehörde. Unter solchen Bedingungen wird das manuelle Ausfüllen und Verarbeiten von Berichten teurer. Daher ist es ratsam, unter diesen Bedingungen die Automatisierung zu verwenden.
Die "Mann-Mann" -Schnittstelle wird durch die "Maschine-Maschine" -Schnittstelle ersetzt, bei der eine mathematisch genaue Angabe des Formats der übertragenen Daten erforderlich ist, die zu XBRL wurde.
Die erste XBRL-Spezifikation wurde vor etwa 20 Jahren von der American Association of Certified Accountants erstellt. Das Format ist so erweiterbar (eXtensible) wie das zugrunde liegende XML. Wenn XML-Erweiterungen jedoch unterschiedliche Auszeichnungssprachen sind, sind XBRL-Erweiterungen Modelle verschiedener Themenbereiche („Domänen“). Zum Beispiel ein Modell des Rechnungslegungsabschlusses / nach IFRS oder ein Modell von Steuerformularen.
Die Basis der XBRL-Sprache ist wie jede Sprache ein Wörterbuch, d.h. eine Liste von Wörtern („Konzepten“), die in lateinischer Sprache verfasst sind und ihre eigenen Attribute haben (Datentyp, der zu den Kategorien „an einem Datum“ / „für einen Zeitraum“ gehört, und Lastschrift / Gutschrift, die Flagge von „abstrakt“).
Anschließend werden anhand des Vokabulars des Themenbereichs alle Formulare modelliert, aus denen sich die Berichterstattung zusammensetzt.
Ein XBRL-Modell ist im einfachsten Fall eine Folge von Sprachkonzepten, d.h. gegebene Reihenfolge ihrer Reihenfolge. Zuerst Vermögenswerte, dann Verbindlichkeiten und Kapital; zuerst Bargeld, dann Einzahlungen. Der einzige Weg. Keine Lücken und keine zusätzlichen Linien.
Ein typisches Formmodell ist eine Kombination von Elementen und analytischen Abschnitten entlang geometrischer Achsen (X, Y und sogar Z) in einer bestimmten Reihenfolge.
Die „Überlagerung“ von analytischen Abschnitten und Berichtsperioden ist entlang der X- und Y-Achse „angeordnet“.
Vor dem Aufkommen von XBRL wurden Indikatoren in Formularen nicht benannt, und als ein neuer Indikator hinzugefügt wurde, wurde es schwierig, das Formular für den alten und den neuen Zeitraum zu vergleichen.
Auf die gleiche Weise werden Inter-Form-Steuerelemente im Inneren „gebunden“ und nur an Zeilen- und Spaltennummern gebunden. Mit neuen Änderungen steigt die Komplexität nicht linear an. In XBRL bestehen die Formeln in den Steuerelementen aus benannten Variablen, sodass das Steuerungsverhältnis beim Ändern von Formularlayouts überhaupt nicht geändert werden muss.
Fujitsu XBRL-Lösung
Der übliche Ansatz des Anbieters (meistens 1C-Franchisenehmer, dh 1C-Partnerunternehmen) zum Hinzufügen von Exporten zu XBRL besteht darin, Zeilen / Spalten in Berichtslayouts zu markieren und beim Exportieren eine Folge von „Fakten“ -Konzepten zu erstellen. Die resultierende Instanz (Instanz - „XBRL-Instanz / Bericht“) wird dann mit freier oder kommerzieller Software (z. B. Arelle oder Altova) auf XML, XBRL-Konformität (plus Kontrollverhältnisse werden anhand ihrer Fakten überprüft) validiert.
Die Schwierigkeit für einen solchen Anbieter besteht darin, dass beim Erstellen eines XBRL-Dokuments (als Textdatei) alle Regeln der XBRL-Syntax beachtet werden sollten: das Fehlen doppelter Fakten und "Kontexte" und vor allem die Entsprechung der Taxonomie. Die Fakten im erstellten Bericht sollten der Taxonomie nach Name und Typ, den Tabellen entsprechen - entsprechend dem Vorhandensein obligatorischer analytischer Abschnitte. Das Bild von Änderungen in der Taxonomie selbst, das zusammen mit früheren Versionen unterstützt werden muss, verschärft das Bild (die Zentralbank kann jederzeit darum bitten, Berichte für den vergangenen Zeitraum erneut zu erstellen).
Und wenn russische Unternehmen 2017 mit der Notwendigkeit konfrontiert waren, XBRL zu unterstützen, hat Fujitsu eine viel längere Kompetenzgeschichte in XBRL. Es basiert auf dem Jahr 2006, als alle an der Tokyo Stock Exchange (Tokyo Stock Exchange) notierten Unternehmen verpflichtet waren, ihre Schlüsselindikatoren in XBRL offenzulegen.
Fujitsu verfügt über einen eigenen, zertifizierten XBRL-Prozessor, der von Regulierungsbehörden in vielen europäischen Ländern verwendet wird. Mit diesem Tool können Sie eine Taxonomie in den Speicher laden und einen XBRL-Bericht nicht als Textdatei, sondern als eine Art Dokumentobjektmodell (DOM) erstellen.
Basierend auf diesem Prozessor wurden Tools erstellt, die sowohl von berichtenden Unternehmen als auch von Aufsichtsbehörden verwendet werden können. Die Zentralbank der Russischen Föderation hat sich auch dafür entschieden, eine russische Taxonomie zu schaffen.
Wenn wir über eine tiefere Integration in Buchhaltungssysteme sprechen (automatische Konvertierung von Berichten in XBRL), verwenden wir hier auch einen flexibleren und leistungsfähigeren dreistufigen Ansatz.
Entwickler des Buchhaltungssystems müssen nicht jeden Bericht markieren und ein solches Markup unterstützen. Normalerweise kann jeder Bericht als Excel-Datei gespeichert werden, aber für uns ist es erforderlich, ihn als einfachen Vektor von "Zellen" (Zeilen-Spalten-Wert) zu speichern. Zum Beispiel die folgende Abbildung.
Eine Tabelle mit 4 Spalten und 12 Zeilen wird zu 48 Zellen. Dieses nicht relationale Präsentationsformat bietet maximale Flexibilität. Für jedes Layout können Sie den Entladebereich zusätzlich einschränken, um die Zeilen- und Spaltenüberschriften der Tabelle, die Kopf- und Fußzeile des Berichts nicht einzuschließen, was die Datenübertragung in der Integrationslösung zusätzlich beschleunigt.
Das zweite Glied unserer Architektur ist die Kennzeichnung der tatsächlichen Formen des Kunden. Aufgrund der Tatsache, dass es viele verschiedene Buchhaltungssysteme gibt (Standardkonfigurationen und proprietäre Designs 1C, „Nicht-1C“ wie SAP und Oracle), unterscheiden sich die Berichtslayouts und die Koordinaten. Im Allgemeinen hat jeder Kunde seine eigenen Layouts (Beispiel unten).
Die Farbe markiert die Bereiche des Layouts, die verschiedenen Elementen der Taxonomie entsprechen. Ein solches Markup wird auf elementare Weise formalisiert - zuerst in der Sprache des Vogels und dann in den Konzepten der Taxonomie:
Wenn sich außerdem die Koordinaten der Regionen (die ersten 4 Spalten) von Kunde zu Kunde ändern können, bleiben die Elemente der Taxonomie allen gemeinsam. Daher ist auch die zweite Verbindung sehr leicht und flexibel.
Darüber hinaus laden wir bei Änderungen in Layouts oder Taxonomie die Zuordnungen als Teil der Konfiguration (es gibt eine Versionierung), ohne den Code zu ändern oder sogar ohne die Lösung neu zu starten.
Die Wahl eines solchen Integrationsschemas wurde durch den in einigen europäischen Taxonomien verwendeten RC-Kodierungsmechanismus inspiriert. Zusammen mit den "menschlichen" Konzepten ist jede Zeile und jede Spalte des Berichts auch mit numerischen Codes gekennzeichnet, d. H. Alle Bereiche sind bereits von den Erstellern der Taxonomie nummeriert. In der Taxonomie der Zentralbank der Russischen Föderation ist diese Schicht ebenfalls vorhanden, jedoch noch nicht in allen Tabellen.
Mit diesem Mechanismus können Sie auch Formulare markieren, die mit Table LinkBase, der fortschrittlichsten Erweiterung des XBRL-Standards, nicht modelliert werden können.
Der Schnittpunkt von Fakten und Zuordnungen wird vom dritten Link verwendet. Mit einem XBRL-Prozessor, der eine Taxonomie im Speicher hält, erstellen wir ein Modell eines Berichtsdokuments. und über alle Fehler im Prozess schreiben wir in das Protokoll und warnen den Benutzer.
Wenn dies Fehler in den Daten sind (z. B. Nichtübereinstimmung von Typen oder Formaten) - versteht der Buchhalter; Wenn das Mapping Fehler enthält, versteht der Analyst. Die Validierung erfolgt daher zum frühesten Zeitpunkt und auf der Ebene einzelner Formulare (und nicht nur der gesamten Berichterstattung). Natürlich kann der Bericht aus dem Speicher jederzeit auf der Festplatte gespeichert werden.
Der Kern des XBRL-Prozessors ist in Java geschrieben, während wir in Java schreiben. Tatsächlich sind alle Kernelmethoden über die API für .NET verfügbar.
Andere Technologien sind ziemlich Standard: die Benutzeroberfläche von React JS; Daher können Buchhalter einfach über einen Browser mit dem System arbeiten (was in großen Unternehmen wichtig ist, in denen strenge Sicherheitsregeln für Softwareinstallationen gelten).
Gleichzeitig erfolgt eine Integration in Active Directory. Vorder- und Rückseite sind über die REST-API verbunden. Es wird auch zur Integration in Buchhaltungssysteme verwendet. Methoden werden automatisch mit Swagger dokumentiert.
Für Benutzer sieht der Prozess so einfach wie möglich aus. Nach Abschluss der Periode im Buchhaltungssystem erstellt der Buchhalter einen Bericht. Mit einem Klick wird es an XBRL übertragen, so wie es gedruckt werden kann. Danach sieht der Buchhalter in der Weboberfläche ein HTML-Rendering desselben Berichts (basierend auf der TableLinkbase-Ebene der Taxonomie, um sicherzustellen, dass die Daten "festgelegt" wurden) und prüft, ob und welche Fehler vorliegen.
Das gesamte Berichtsvolumen (N Tabellen) kann vom Leiter auf mehrere verantwortliche Buchhalter und Spezialisten aufgeteilt werden. Wenn einige Formulare im Buchhaltungssystem nicht vorhanden sind, können die Verantwortlichen sie aus Excel herunterladen, die von einem speziellen Softwaretool in einen Vektor von Fakten „geschnitten“ werden, ähnlich wie in Abbildung 3 dargestellt. Wenn alle Tabellen ohne kritische Fehler „fertig“ sind, lädt der Manager den Abschlussbericht herunter und lädt ihn auf Ihr persönliches Konto auf der Website der Zentralbank hoch.
Abschließend
Hier ist eine tief integrierte Lösung. Es sind keine zusätzlichen Konvertierungsschritte erforderlich und es wird das gesamte Berichtsvolumen abgedeckt.
Viele Anbieter waren gezwungen, die XBRL-Unterstützung so schnell wie möglich in ihre Entscheidungen einzubeziehen. Daher lade ich Analysten und Programmierer ein, hier sensible Themen zu diskutieren.