Когда Accounting Engine нет

За 20–25 лет развития АБС сложилась традиционная для большинства из них архитектура. Это многофункциональная система, которая совмещает функции бэк-офиса, бухгалтерского и налогового учета, регуляторной и оперативной отчетности.

Что характерно для такой архитектуры?

• Единый баланс организации собирается из разнородных продуктовых систем на уровне Главной книги банка. Информация из внешних продуктовых систем на данном уровне недоступна, поэтому вся необходимая аналитика кодируется в номере лицевого счета.

• Продуктовые системы ведут свой собственный бухгалтерский учет, данные которого используются для продуктового учета. Например, в качестве остатка по депозитному договору используется остаток на соответствующем лицевом счете.

• В каждой продуктовой системе есть собственные встроенные механизмы формирования проводок и открытия счетов.

• Консолидированная отчетность организации формируется на уровне Главной книги. Дополнительные расшифровки стоят в продуктовых системах. Поэтому отчетность часто собирают вручную.

Аналогично развивались и бизнес-процессы кредитной организации, подстраиваясь и под особенности бизнеса, и под возможности АБС.

Распространено следующее распределение ролей и обязанностей пользователей системы:

• сотрудники операционного департамента кроме оформления и сопровождения операций отвечают за их бухгалтерское отражение, вносят «ручные» проводки и контролируют работу с лицевыми счетами;

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

• методология учета — это бумажный документ, который внедряет IT-служба банка, сами методологи не работают в системах, автоматизирующих правила учета;

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

Когда Accounting Engine есть

Альтернативное решение, которое было сформулировано BIAN (Banking Industry Architecture Network) и поддержано IBM, предполагает разделение сервисов на учетные слои. Почему важно отделять продуктовый учет от бухгалтерского и какую роль в этом подходе играет решение класса Accounting Engine?

При разделении на слои в продуктовых бэк-офисных системах отсутствуют объекты учетного слоя, такие как бухгалтерские синтетические и аналитические счета, документы, транзакции двойной записи (проводки) и прочие атрибуты бухгалтерской книги. Для поддержки своих операционных функций продуктовая система опирается на продуктовые регистры, спроектированные специально для решения задачи конкретного банковского продукта. Наполнение Главной книги бухгалтерскими данными и преобразование продуктовых событий в бухгалтерский учет осуществляет Accounting Engine

Характеристики АБС, построенной по принципу разделения продуктового и бухгалтерского учета:

• продуктовые системы ориентированы исключительно на основные функции бэк-офиса. Продуктовый учет сконцентрирован на продуктовых регистрах;

• взаимодействие между продуктовыми системами и Главной книгой организовано посредством обработки продуктовых событий Accounting Engine;

• продуктовые события отражают исключительно пошаговые бизнес-процессы бэк-офиса и содержат только операционные данные;

• Accounting Engine содержит сценарии обработки продуктовых событий, правила открытия лицевых счетов и формирования бухгалтерских документов.

Изменение архитектуры АБС влияет на бизнес-процессы, распределение ответственности между бэк-офисом и бухгалтерией и подходы к сопровождению АБС следующим образом:

• сотрудники операционного блока сосредоточены на своей непосредственной функции сопровождения операций;

• бухгалтерия, осуществляя последующий контроль, имеет доступ к просмотру продуктовых операций и событий на уровне Accounting Engine и контролирует все «ручные» корректировки;

• методолог может сопровождать и менять правила бухгалтерского учета через пользовательский интерфейс Accounting Engine без привлечения IT-службы;

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

Как мы сделали Accounting Engine

В 2008 году после поистине героического проекта по поддержке новых требований бухгалтерского учета, который вошел в историю как проект «302-П», мы, что называется, на собственной шкуре испытали всю сложность задачи и поняли, что разделение продуктового и бухгалтерского учета — жизненно важный принцип проектирования автоматизированных систем. Мы очень хотели выстоять и в следующих учетных революциях. Так что рекомендации BIAN по этому вопросу легли на уже подготовленную почву.

Начало пути

Создание линейки FLEXTERA началось в 2006 году. Что делать с большинством новых сервисов, мы понимали. Мы знали функциональные требования к продуктам бэк-офиса. За предыдущие годы мы накопили колоссальный прикладной опыт в этом направлении. А вот наше представление об Accounting Engine основывалось на поверхностных описаниях BIAN, элементах этого функционала в линейке Diasoft FA# и мечтах об идеальном продукте.

Наше первое вИдение исходило из постулата, что Accounting Engine — это простая и быстрая «молотилка» для продуктовых событий. Сам сервис не должен быть мастер-системой для операционных данных — только для правил и настроек. Мы представляли его как своеобразное интеграционное приложение. С этого начался наш путь «по дороге из желтого кирпича» — к Accounting Engine, с которым можно будет построить архитектуру нового поколения.

Первый поворот

В первом пилотном проекте мы столкнулись с обстоятельствами, которые заставили нас пересмотреть предыдущий подход к решению задачи. Продуктовая система, являющаяся для нас источником событий, депозитный бэк-офис французского производства, не имела функционала для связи лицевых счетов и проводок с договорами и операциями. Кроме того, она не формировала набор событий с необходимым для российского учета атрибутным составом. Например, в событии заключения депозитного договора продуктовая система передавала идентификатор клиента, но не передавала форму собственности и резидентство. Такой поворот на нашем пути привел к тому, что в сервисе Accounting Engine появились новые функции: полное сохранение связей между продуктовыми объектами, событиями и объектами учета, а также обогащение события необходимыми для учета атрибутами.

Второй поворот

Особенностью следующего проекта стала задача поддержки учета по РПБУ в некредитной финансовой организации. С одной стороны, процесс настройки был простым — в этом стандарте отсутствуют лицевые счета. С другой стороны, нужен был аналитический учет на уровне субконто. На этом отрезке пути мы поняли, что спроектированный ранее механизм настройки справился с задачей без существенных доработок. Accounting Engine сформировал проводки для выгрузки в NAVISION AXAPTA, а мы зафиксировали функциональную возможность поддержки правил и механизмов формирования проводок в разрезе субконто.

Серьезное испытание

Следующий проект стал серьезным испытанием для Accounting Engine. «Дорога из желтого кирпича» наконец привела нас к задаче поддержки требований бухгалтерского учета операций на финансовых рынках по требованиям IFRS. Требования проекта задали высокую планку: нужны были очень гибкие механизмы настройки, потому что учет операций на финансовых рынках крайне сложен. В результате мы доработали механизмы настройки и обработки событий, полностью изменили правила открытия лицевых счетов и настройки схем счетов и получили решение на более высоком уровне зрелости.

Кроме того, важным компонентом преобразования учета операций на финансовых рынках стал новый аналитический сервис «Инструментарий вычислений». В 90% случаев по операциям на финансовых рынках невозможно сформировать полноценный бухгалтерский учет только на базе продуктовых событий. Универсальная продуктовая система ничего не знает о расчете финансового результата, об особенностях применения метода начислений, о правилах переоценки по справедливой стоимости, амортизации затрат и т.п. Эти алгоритмы являются частью учетных стандартов, а значит, входят в платформу преобразования учета и поддерживаются в специальном сервисе — FLEXTERA «Инструментарий вычислений».

Новые вызовы

Наш текущий проект — это поддержка перехода на отраслевые стандарты бухгалтерского учета Банка России для НФО. Наконец идея Accounting Engine развернулась в полный рост. Источником продуктовых событий являются сразу несколько систем: Calypso, Diasoft FА#, 1C Казначейство. Чтобы не строить отдельное интеграционное решение для каждой системы, мы разработали стандарт продуктовых событий в формате XML для всех операций на финансовых рынках и спроектировали события, исходя из реального бизнес-процесса, без учета специфики реализации продуктовых систем. Этот подход позволяет получить интерфейс, независимый от системы источника.

Какой Accounting Engine действительно работает

В результате эволюции развития Accounting Engine получилась система, функциональные блоки которой представлены на рис.

Мы прошли большой путь и понимаем, что Accounting Engine — это не просто «молотилка», не просто интеграционная функция. Для «честного» разделения продуктового и бухгалтерского учета такого «просто» недостаточно. Мы еще идем «по дороге из желтого кирпича», но уже точно знаем, что такое Accounting Engine, который действительно работает. Мы видим новые функциональны возможности, готовы к новым вызовам и испытаниям. Уже видны башни Изумрудного города, и впереди нас ждет самое интересное.

Реклама