Sejak 2018, Bank Sentral Rusia (sebagai regulator) telah mewajibkan lembaga keuangan non-kredit (NFI), yaitu semua perusahaan dari sektor keuangan ekonomi, kecuali bank, yaitu asuransi, dana pensiun, prof. peserta pasar sekuritas, perusahaan manajemen, melaporkannya dalam format baru - sesuai dengan spesifikasi XBRL (dan tidak unggul atau xml).
Ruang lingkup pelaporan pengawasan (statistik) meliputi informasi tentang pendiri dan pelanggan, objek asuransi, premi dan pembayaran, deposito dan investasi, tentang rekanan, dll. dll. - Benar-benar ratusan ribu fakta. Dalam hal ini, untuk memfasilitasi birokrasi dan menjaga keakuratan prosedur, kita akan berbicara tentang proyek otomatisasi pelaporan dalam XBRL satu NFO besar, yang didasarkan pada solusi Fujitsu XBRL.
Selain regulator, laporan akuntansi, yang memiliki potensi lebih banyak penerima, serta pajak, pertukaran dan situs tender, juga ditransfer ke format XBRL. Harus diingat bahwa tujuan akhir Bank Sentral adalah mentransfer bank ke XBRL agar dapat memantau secepat dan sedalam mungkin.
Pengantar singkat untuk XBRL
XBRL - Bahasa Pelaporan Bisnis eXtensible, atau “Bahasa Pelaporan Bisnis yang Diperluas”, dibuat untuk memodelkan formulir pelaporan dan sebagai format untuk indikator pelaporan ke perusahaan pelaporan.
Secara tradisional, formulir pelaporan dibuat oleh beberapa orang (metodologi regulator - Bank Sentral), diisi oleh orang lain (akuntan organisasi yang bertanggung jawab) dan diperiksa oleh orang ketiga (spesialis biasa dari Bank Sentral).
Volume pelaporan meningkat: jumlah indikator telah bertambah menjadi ribuan, dan pada saat yang sama mereka mulai mengirimkannya lebih sering. Sebagai contoh, bank melapor kepada regulator setiap hari. Dalam kondisi seperti itu, mengisi dan memproses laporan secara manual menjadi lebih mahal, sehingga disarankan untuk menggunakan otomasi dalam kondisi ini.
Antarmuka "manusia-manusia" digantikan oleh antarmuka "mesin-mesin", di mana spesifikasi matematis yang akurat dari format data yang dikirimkan diperlukan, yang menjadi XBRL.
Spesifikasi XBRL pertama dibuat sekitar 20 tahun yang lalu oleh American Association of Certified Accountants. Formatnya extensible (eXtensible) seperti XML yang mendasarinya; tetapi jika ekstensi XML adalah bahasa markup yang berbeda, maka ekstensi XBRL adalah model area subjek yang berbeda ("domain"). Misalnya, model Laporan Keuangan Akuntansi / sesuai dengan IFRS atau model formulir pajak.
Basis bahasa XBRL, seperti bahasa apa pun, adalah kamus, mis. daftar kata-kata ("konsep") yang ditulis dalam bahasa Latin dan memiliki atribut sendiri (tipe data, milik kategori "pada tanggal" / "untuk suatu periode" dan debit / kredit, bendera "abstrak").
Kemudian, dengan menggunakan kosa kata dari bidang subjek, semua formulir yang membentuk pelaporan dimodelkan.
Model XBRL dalam kasus paling sederhana adalah urutan konsep bahasa, yaitu diberi urutan urutannya. Pertama, aset, lalu liabilitas dan modal; uang tunai dulu, baru setoran. Seperti itu saja. Tidak ada celah dan tidak ada garis tambahan.
Model bentuk khas adalah kombinasi elemen dan bagian analitik sepanjang sumbu geometris (X, Y, dan bahkan Z) yang diberikan dalam urutan tertentu.
"Superposisi" bagian analitik dan periode pelaporan "diletakkan" di sepanjang sumbu X dan Y.
Sebelum munculnya XBRL, indikator dalam bentuk tidak disebutkan, dan ketika indikator baru ditambahkan, menjadi sulit untuk membandingkan formulir untuk periode lama dan yang baru.
Dengan cara yang sama, antar-bentuk mengontrol "terikat" di dalam, hanya diikat ke nomor baris dan kolom. Dengan pengeditan baru, kompleksitas meningkat secara non-linear. Dalam XBRL, rumus dalam kontrol terdiri dari variabel bernama, sehingga rasio kontrol tidak perlu diubah sama sekali saat mengubah tata letak formulir.
Solusi Fujitsu XBRL
Pendekatan yang biasa digunakan vendor (paling sering adalah franchisee 1C, yaitu, perusahaan mitra 1C) untuk menambahkan ekspor ke XBRL adalah dengan menandai baris / kolom dalam tata letak laporan dan untuk menghasilkan serangkaian konsep "fakta" ketika mengekspor. Contoh yang dihasilkan (contoh - "instance / laporan XBRL") kemudian divalidasi untuk XML, kepatuhan XBRL (ditambah rasio kontrol diperiksa berdasarkan fakta-faktanya) menggunakan perangkat lunak gratis atau komersial (misalnya, Arelle atau Altova).
Kesulitan untuk vendor semacam itu adalah ketika membuat dokumen XBRL (sebagai file teks), semua aturan sintaks XBRL harus diperhatikan: tidak adanya duplikat fakta dan "konteks" dan, yang paling penting, korespondensi taksonomi. Fakta-fakta dalam laporan yang dibuat harus sesuai dengan taksonomi berdasarkan nama dan jenis, tabel - sesuai dengan keberadaan bagian analitis wajib. Gambar perubahan dalam taksonomi itu sendiri, yang harus didukung bersama dengan versi sebelumnya, memperburuk gambar (Bank Sentral kapan saja dapat meminta untuk mengambil kembali laporan untuk periode terakhir).
Dan jika perusahaan Rusia dihadapkan dengan kebutuhan untuk mendukung XBRL pada 2017, maka Fujitsu memiliki sejarah kompetensi yang jauh lebih lama di XBRL. Ini berakar pada 2006, ketika semua perusahaan yang terdaftar di Bursa Efek Tokyo (Bursa Saham Tokyo) diwajibkan untuk mengungkapkan indikator utama mereka di XBRL.
Fujitsu memiliki prosesor XBRL bersertifikatnya sendiri, yang digunakan oleh regulator di banyak negara Eropa, yang memungkinkan Anda memuat taksonomi ke dalam memori dan membuat laporan XBRL bukan sebagai file teks, tetapi sebagai semacam model objek dokumen (DOM).
Berdasarkan prosesor ini, alat telah dibuat yang dapat digunakan oleh perusahaan pelapor dan regulator. Bank Sentral Federasi Rusia juga memilihnya untuk menciptakan taksonomi Rusia.
Jika kita berbicara tentang integrasi yang lebih dalam dengan sistem akuntansi (konversi otomatis laporan ke XBRL), maka di sini kita juga menggunakan pendekatan 3-tier yang lebih fleksibel dan kuat.
Pengembang sistem akuntansi tidak diharuskan untuk menandai setiap laporan dan mendukung peningkatan tersebut. Biasanya, laporan apa pun dapat disimpan sebagai file Excel, tetapi bagi kami diperlukan untuk menyimpannya sebagai vektor sederhana "sel" (nilai baris-col). Misalnya ilustrasi di bawah ini.
Tabel 4 kolom dan 12 baris berubah menjadi 48 sel. Format presentasi non-relasional ini memberikan fleksibilitas maksimum. Untuk setiap tata letak, Anda juga dapat membatasi area pembongkaran agar tidak menyertakan judul baris dan kolom pada tabel, header dan footer laporan, yang juga mempercepat transfer data dalam solusi integrasi.
Tautan kedua dari arsitektur kami adalah penandaan bentuk pelanggan yang sebenarnya. Karena kenyataan bahwa ada banyak sistem akuntansi yang berbeda (konfigurasi standar dan desain eksklusif 1C, "non-1C" seperti SAP dan Oracle), tata letak pelaporan berbeda dan koordinatnya juga akan berbeda. Secara umum, setiap pelanggan memiliki tata letak sendiri (contoh di bawah).
Warna menandai area tata letak yang sesuai dengan berbagai elemen taksonomi. Markup seperti itu diformalkan secara elementer - pertama di lidah burung, dan kemudian dalam konsep taksonomi:
Selain itu, jika koordinat wilayah (4 kolom pertama) dapat berubah dari pelanggan ke pelanggan, maka unsur-unsur taksonomi tetap umum untuk semua. Karena itu, tautan kedua juga sangat ringan dan fleksibel.
Selain itu, jika ada perubahan dalam tata letak atau taksonomi, kami memuat pemetaan sebagai bagian dari konfigurasi (ada versi), tanpa mengubah kode, atau bahkan tanpa memulai ulang solusi.
Pilihan skema integrasi tersebut diilhami oleh mekanisme pengkodean RC yang digunakan dalam beberapa taksonomi Eropa. Seiring dengan konsep "manusia", setiap baris dan setiap kolom laporan juga ditandai dengan kode numerik, yaitu semua rentang sudah diberi nomor oleh pencipta taksonomi. Dalam taksonomi Bank Sentral Federasi Rusia, lapisan ini juga ada, tetapi belum ada di semua tabel.
Mekanisme ini memungkinkan Anda untuk menandai bahkan bentuk-bentuk yang tidak dapat dimodelkan menggunakan Table LinkBase, ekstensi paling maju dari standar XBRL.
Persimpangan fakta dan pemetaan digunakan oleh tautan ketiga. Menggunakan prosesor XBRL yang menyimpan taksonomi dalam memori, kami membuat model dokumen laporan; dan tentang semua kesalahan dalam proses kami menulis ke log dan memperingatkan pengguna.
Jika ini adalah kesalahan dalam data (ketidakcocokan jenis atau format, misalnya) - akuntan mengerti; jika ada kesalahan dalam pemetaan, analis mengerti. Dengan demikian, validasi terjadi pada tahap paling awal dan pada tingkat bentuk individu (dan bukan hanya seluruh pelaporan). Tentu saja, laporan dari memori kapan saja dapat disimpan ke disk.
Inti dari prosesor XBRL ditulis dalam Java, sementara kami menulis dalam Java. Faktanya, semua metode kernel tersedia melalui API untuk .NET.
Teknologi lain cukup standar: antarmuka pengguna di React JS; Oleh karena itu, akuntan dapat bekerja dengan sistem hanya melalui browser (yang penting di perusahaan besar di mana ada aturan keamanan yang ketat untuk instalasi perangkat lunak).
Pada saat yang sama, ada integrasi dengan Active Directory. Depan dan belakang terhubung melalui REST API; Ini juga digunakan untuk integrasi dengan sistem akuntansi. Metode didokumentasikan secara otomatis menggunakan Swagger.
Untuk pengguna, prosesnya terlihat sesederhana mungkin. Setelah menutup periode dalam sistem akuntansi, akuntan menghasilkan laporan. Dalam satu klik, itu mentransfernya ke XBRL, sama seperti ia dapat mencetak. Setelah itu, dalam antarmuka web, akuntan melihat html-render dari laporan yang sama (berdasarkan lapisan TableLinkbase dari taksonomi untuk memastikan bahwa data telah "diletakkan") dan melihat apakah ada kesalahan dan jika demikian, yang mana.
Seluruh volume pelaporan (tabel N) dapat dibagi oleh kepala antara beberapa akuntan yang bertanggung jawab dan spesialis. Jika beberapa bentuk tidak ada dalam sistem akuntansi, mereka yang bertanggung jawab dapat mengunduhnya dari Excel, yang "dipotong" oleh alat perangkat lunak khusus ke dalam vektor fakta yang serupa dengan ilustrasi No. 3. Ketika semua tabel “siap” tanpa kesalahan kritis, manajer mengunduh laporan akhir dan mengunggahnya ke akun pribadi Anda di situs web Bank Sentral.
Kesimpulannya
Berikut ini adalah solusi terintegrasi. Itu tidak memerlukan langkah-langkah konversi tambahan dan mencakup seluruh volume pelaporan.
Banyak vendor dipaksa untuk memasukkan dukungan XBRL dalam keputusan mereka sesegera mungkin, jadi saya mengundang analis dan programmer untuk membahas masalah sensitif di sini.