Укрощение XBRL: заметки аналитика

    Начиная с 2018 года российский Центробанк (как регулятор) обязал некредитные финансовые организации (НФО), т.е. все предприятия финансового сектора экономики, кроме банков, а именно страховые, пенсионные фонды, проф. участники рынка ценных бумаг, управляющие компании, отчитываться перед ним в новом формате – согласно спецификации XBRL (а не excel или xml).

    В объем надзорной (статистической) отчетности входит информация об учредителях и клиентах, объектах страхования, премиях и выплатах, депозитах и инвестициях, о контрагентах и т.д. и т.п. — реально сотни тысяч фактов. В связи с этим, для облегчения бюрократизма и соблюдения точности процедуры, расскажем о проекте автоматизации формирования отчетности в XBRL одной крупной НФО, в основу которого легло решение Fujitsu XBRL.



    Помимо регулятора в формат XBRL перевели бухгалтерскую отчётность, как имеющую потенциально больше получателей, также налоговая, биржа и тендерные площадки. Следует помнить, что конечная цель Центробанка – перевести на XBRL и банки, чтобы иметь возможность проводить мониторинг максимально оперативно и глубоко.

    Краткое введение в XBRL


    XBRL — eXtensible Business Reporting Language, или «расширяемый язык деловой отчётности», – создан для моделирования форм отчётности и как формат для передачи регулятору показателей подотчётными компаниями.

    Традиционно формы отчётности создавались одними людьми (методологами регулятора – Центробанка), заполнялись другими людьми (бухгалтерами подотчётных организаций) и проверялись третьими людьми (рядовыми специалистами ЦБ).

    Объем отчетности увеличивается: количество показателей уже выросло до тысяч, вместе с этим подавать ее стали чаще. Например, банки отчитываются перед регулятором ежедневно. В таких условиях заполнять и обрабатывать отчетность вручную становится все затратнее, так что целесообразно в этих условиях использовать автоматизацию.

    Интерфейс «человек – человек» заменяется интерфейсом «машина – машина», где нужна математически точная спецификация формата передаваемых данных, которым и стал XBRL.

    Первая спецификация XBRL была создана около 20 лет назад американской ассоциацией сертифицированных бухгалтеров. Формат такой же расширяемый (eXtensible), как и лежащий в его основе XML; но если расширения XML –это различные языки разметки, то расширения XBRL –это модели различных предметных областей («доменов»). Например, модель Бухгалтерской Финансовой Отчётности / по МСФО или модель налоговых форм.

    В основе языка XBRL, как и любого языка, лежит словарь (dictionary), т.е. перечень слов («концептов»), записанных латиницей и имеющих свои атрибуты (тип данных, принадлежность к категориям «на дату» / «за период» и дебит/кредит, флаг «абстрактности»).

    Далее с помощью словаря предметной области моделируются все формы, составляющие отчётность.

    Модель на языке XBRL –это в простейшем случае последовательность концептов языка, т.е. заданный порядок их следования. Сначала – активы, потом обязательства и капитал; сначала наличность, потом депозиты. Только так. Без пропусков и без лишних строк.


    Типичная модель формы – это заданная в определённом порядке комбинация элементов и аналитических разрезов по геометрическим осям (X, Y и даже Z).


    «Суперпозиция» аналитических разрезов и отчётных периодов «разложена» по осям X и Y.

    До появления XBRL показатели в формах не были поименованы, и при добавлении нового показателя становилось сложно сравнить форму за старый период и новый.

    Таким же образом «разъезжались» внутри и межформенные контроли, завязанные только на номера строк и столбцов. С новыми правками сложность увеличивается нелинейно. В XBRL же формулы в контролях состоят из поименованных переменных, поэтому контрольные соотношение вообще не нужно менять при изменении макетов форм.

    Решение Fujitsu XBRL


    Обычный подход вендора (чаще всего это 1С франчайзи, т.е. компании-партнеры 1С) к добавлению экспорта в XBRL заключается в том, чтобы промаркировать строки/столбцы в макетах отчётов и при экспорте выдавать последовательность значений концептов – «фактов». Результирующий инстанс (instance – «экземпляр/ отчет XBRL») затем валидируется на соответствие XML, XBRL (плюс на его фактах проверяются контрольные соотношения) с использованием свободного или коммерческого ПО (например, Arelle или Altova).

    Сложность для такого вендора заключается в том, что при создании XBRL документа (как текстового файла) следует соблюсти все правила синтаксиса XBRL: отсутствие дубликатов фактов и «контекстов» и самое главное – соответствие таксономии. Факты в созданном отчете должны соответствовать таксономии по имени и типу, таблицы – по наличию обязательных аналитических разрезов. Усугубляют картину изменения в самой таксономии, которые обязательно нужно поддерживать наряду с прошлыми версиями (ЦБ может в любой момент попросить пересдать отчётность за прошлый период).

    И если российские компании столкнулись с необходимостью поддержки XBRL в 2017 году, то Fujitsu имеет гораздо более долгую историю компетенций в XBRL. Она уходит корнями в 2006 год, когда все компании, входящие в листинг Токийской фондовой биржи (Tokyo Stock Exchange) обязали раскрывать свои ключевые показатели в XBRL.

    Fujitsu имеет свой собственный, сертифицированный XBRL-процессор, используемый регуляторами многих европейских стран, который позволяет загружать таксономию в память и создавать отчёт XBRL не как текстовый файл, а как своеобразную объектную модель документа (DOM).

    На основе этого процессора создан инструментарий, который могут использовать как подотчётные компании, так и регуляторы. ЦБ РФ также выбрал его для создания российской таксономии.

    Если же речь идёт о более глубокой интеграции с учётными системами (автоматической конвертации отчётности в XBRL), то и здесь мы также используем более гибкий и мощный, 3-звенный подход.

    От разработчиков учётной системы не требуется размечать каждый отчёт и поддерживать такую разметку. Обычно любой отчёт можно сохранить как Excel-файл, а для нас требуется сохранить его как простой вектор «ячеек» (row-col-value). Для примера иллюстрация ниже.


    Таблица из 4 столбцов и 12 строк превращается в 48 ячеек. Такой нереляционный формат представления обеспечивает максимальную гибкость. Для каждого макета можно дополнительно ограничить область выгрузки, чтобы не включать заголовки строк и столбцов таблицы, шапку и подвал отчёта, что дополнительно ускоряет передачу данных в интеграционном решении.

    Второе звено нашей архитектуры – это разметка актуальных форм заказчика. Ввиду того, что есть много разных учётных систем (стандартных конфигураций и собственных разработок 1С, «не-1С» типа SAP и Oracle), отчётные макеты различаются и координаты также будут отличаться. В общем-то, у каждого заказчика свои макеты (пример ниже).


    Цветом выделены области макета, соответствующие разным элементам таксономии. Такая разметка формализуется элементарным образом – сначала на птичьем языке, а потом в концептах таксономии:


    Причём если от заказчика к заказчику могут меняться координаты областей (первые 4 столбца), то элементы таксономии остаются общими для всех. Поэтому второе звено также весьма легкое и гибкое.

    При этом если происходят изменения в макетах или таксономии, мы подгружаем маппинги как часть конфигурации (есть версионность), без изменения кода, и даже без перезапуска решения.

    Выбор такой схемы интеграции был навеян механизмом «RC-coding», применяемым в некоторых европейских таксономиях. Наряду с «человеческими» концептами каждая строка и каждый столбец отчёта помечены ещё и числовыми кодами, т.е. все диапазоны уже пронумерованы создателями таксономии. В таксономии ЦБ РФ этот слой также присутствует, но ещё не на всех таблицах.

    Такой механизм позволяет размечать даже те формы, которые нельзя смоделировать с помощью Table LinkBase –наиболее продвинутого расширения стандарта XBRL.

    Пересечение фактов и маппингов используется третьим звеном. C помощью XBRL-процессора, который держит в памяти таксономию, мы создаём модель документа отчёта; а обо всех ошибках в процессе пишем в лог и предупреждаем пользователя.

    Если это ошибки в данных (несовпадение типов или форматов, например) – разбирается бухгалтер; если ошибки в маппингах – разбирается аналитик. Таким образом, валидация происходит на самом раннем этапе и на уровне отдельных форм (а не только отчётности целиком). Разумеется, отчёт из памяти в любой момент может быть сохранён на диск.

    Ядро XBRL-процессора написано на Java, на Java же пишем и мы. А вообще-то все методы ядра доступны через API и для .NET.

    Прочие технологии достаточно стандартны: пользовательский интерфейс на React JS; поэтому бухгалтеры могут работать с системой просто через браузер (что актуально в крупных компаниях, где строгие правила безопасности к установкам ПО).

    При этом есть и интеграция с Active Directory. Фронт и бэк связаны через REST API; он же используется для интеграции с учётными системами. Методы автоматически документируются с использованием Swagger.

    Для пользователей процесс выглядит максимально просто. После закрытия периода в учётной системе бухгалтер формирует отчёт. В один клик он передаёт его в XBRL, также как может передать на печать. После этого в web-интерфейсе бухгалтер видит html-рендер того же отчёта (основанный на слое TableLinkbase таксономии, чтобы убедиться, что данные «легли») и видит, есть ли ошибки и если есть, то какие.

    Весь объём отчетности (N таблиц) может быть разделён руководителем между несколькими ответственными бухгалтерами и специалистами. Если какие-то формы отсутствуют в учётной системе, ответственные могут загрузить их из Excel, которые «разрезаются» специальным программным инструментом на вектор фактов аналогично иллюстрации №3. Когда все таблицы «готовы» без критичных ошибок, руководитель скачивает финальный отчёт и загружает его в личный кабинет на сайте ЦБ.

    В заключении


    Вот такое вот получилось глубоко интегрированное решение. Не требует дополнительных этапов конвертации и покрывает весь объем отчётности.

    Многие вендоры были вынуждены в кратчайшие сроки включать поддержку XBRL в своих решениях, так что приглашаю аналитиков и программистов обсудить здесь наболевшие вопросы.

    Fujitsu

    72,00

    Японская компания-лидер ICT-рынка

    Поделиться публикацией
    Комментарии 5
      0
      Подскажите, а вы уже стали поддерживать технические контроли в таксономии ЦБ и выдавать понятное описание ошибок?
        0
        Мы выдаём только те описания контролей, которые «зашиты» в самой таксономии.
        В ней действительно сообщения генерируются автоматически, что не идёт на пользу читаемости.
        Но т.к. формул тысячи, то переписывать их сообщения мы не стали, да и не было на это заказа.

        Дополнительно мы показываем все переменные, из которых состоит формула – с их названиями и значениями.
        А в режиме экспорта в excel есть переход с переменной на конкретную таблицу формы (там где это возможно).
        0

        Предложение компании Fujitsu. Помогу перевести Fujitsu XBRL на платформу 1С 8.3. За разумную цену.

          0
          Отличное предложение на самом деле, только помимо платформы есть ещё и конфигурации поверх неё. Каждую конфигурацию потенциально нужно переводить отдельно, верно? Т.к. модули отчётности (которые агрегируют первичные данные в показатели отчёта) — в каждой конфигурации отличаются… правильно я понимаю?
          С другой стороны конфигурации можно по пальцам одной руки пересчитать, вы о какой из них?
            0
            По пальцам одной руки — определённо нет, но по пальцам рук болельщиков на стадионе — определённо да. Если учитывать разнообразные кастомизации. Автоматизация на 1С — очень большая экосистема.

            Насколько я понимаю, Fujitsu XBRL — отдельное решение, которое интегрируется с учётной системой. В принципе, платформа 1С на редкость удобна для подобных задач, даже когда сама учётная система — не 1С. Единственное, что для решения за основу не надо брать типовые типа «Консолидация» или «Управление холдингом». Как бы оно ни было соблазнительно. Задача очень похожа на ту, которую лучше делать «с нуля».

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое