Объединить передовой IT-опыт и предоставить лучшие решения для каждого нашего клиента в отдельности

(495) 604-1882
Продукты
Quadrium ActiveData

Архитектура системы Quadrium ActiveData на примере автоматизации подготовки обязательной отчетности

 


Рис.1, Общие принципы построения системы подготовки обязательной отчётности

Централизованное построение обязательной отчётности в Хранилище на основании загруженных первичных учётных данных

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

  • Единообразие формируемых отчётных форм.
  • Возможность обеспечения межформенного контроля.
  • Согласованность отчётных данных филиалов и Головной конторы.
  • Минимальная трудоемкость обновления альбома отчетов для всех подразделений банка.
  • Высокая скорость подготовки отчетности, обеспечивающая своевременность получения отчетов.
  • Отсутствие негативного влияния на оперативные учетные системы банка. 
  1. Первичные данные загружаются в Хранилище из основной АБС, а также любых других необходимых источников (например, системы розничного банковского обслуживания, системы автоматизации учёта ценных бумаг и т.д.).
  2. Загрузка первичных данных в Хранилище, обеспечение их актуальности, проверка качества и обновление витрин реализуется ETL-процессом, спроектированным и выстроенным соответствующим образом (см. Общие принципы построения ETL-процесса и Архитектура и описание ETL-процесса).
  3. Состав и содержание форм обязательной отчётности, а также их параметры, подлежащие внутреннему и межформенному контролю, регламентируются соответствующими нормативными актами ЦБ РФ (302-П, 1376-У, 110-И, 342-П и т.д.). При наличии в Хранилище соответствующих первичных учётных данных возможна автоматизация подготовки любой формы обязательной отчётности. Формы обязательной отчётности можно подразделить на: 
  • Требующие для своего построения наличия только данных бухгалтерского учёта. Примерами могут являться Приложения 8 («Оборотная ведомость по счетам кредитной организации») и 9 («Баланс кредитной организации») к 302-П, формы 101 («Оборотная ведомость по счетам бухгалтерского учёта кредитной организации»), 102 («Отчёт о прибылях и убытках кредитной организации»).
  • Требующие наличия данных бухгалтерского учёта и некоторых признаков дополнительной «раскраски» по счетам и/или документам и/или клиентам банка. Примерами могут являться формы 202 («Отчёт о наличном денежном обороте») и 601 («Отчёт об операциях с наличной иностранной валютой и чеками в иностранной валюте»).
  • Требующие наличия данных бухгалтерского и сделочного учёта. В некоторых частных случаях данные сделочного учёта можно заменить дополнительными признаками раскраски данных бухгалтерского учёта. Примерами могут являться формы 128 («Данные о средневзвешенных процентных ставках по кредитам, предоставленным кредитной организацией»), 302 («Сведения о размещённых и привлечённых средствах кредитных организаций»).
  • Требующие, кроме наличия данных бухгалтерского и сделочного учёта, также рассчитанных показателей других отчётных форм. Примерами могут являться форма 806 («Бухгалтерский баланс (публикуемая форма)»), требующая наличия рассчитанных данных форм 101 и 110 («Расшифровки отдельных показателей деятельности кредитной организации»), и форма 807 («Отчёт о прибылях и убытках (публикуемая форма)»), требующая наличия рассчитанных данных форм 102 и 110.

Описание бизнес-процесса подготовки обязательной отчётности

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

  • Витрина используется для получения отчётов по срезу по нескольким формам. Примерами могут служить витрины показателей формы 101, которая используется для построения формы 806 и показателей формы 102, используемая для построения формы 807.
  • Расчёт отчёта в целом «с нуля» может занимать значительное время. В этом случае предварительный расчёт витрины позволяет ускорить получение отчёта для конечного бизнес-пользователя.
  • Витрина используется для межформенного контроля. Примером может служить та же витрина показателей формы 101, которая используется для согласования данных с другими формами, например, с формой 202.

Для расчёта или пересчёта витрин используется ETL-процесс, но при необходимости эта операция может производиться директивно перед формированием отчёта.

После формирования отчёта имеется возможность просматривать его, пользуясь браузером системы или осуществить его экспорт в формат офисных пакетов или программных комплексов надзора (PDF, MS-Word, MS-Excel, KliKO, OBVED, ПТК-ПСД и т.д.).

Следующим этапом является проверка корректности данных отчета или группы отчетов. В системе обеспечена возможность выполнения процедур по проверке корректности данных по правилам ЦБ отчета и групп отчетов, в том числе по критериям межформенного контроля и соответствия данных из отчетов, сформированных за различные отчетные периоды. При проверке реализована детализация показателей отчетной формы инструментальными средствами drill-down, до уровня первичного документа, проводки, счёта, сделки, операции. Обеспечена также возможность ручной корректировки (ручного ввода) данных в отчетах. При этом информация о ручной корректировке отчетной информации регистрируется и, при необходимости, пересылается пользователю в качестве напоминания о произведенных изменениях. Реализована возможность пересчета ранее сформированных отчетов с учетом обновленных данных (например, данные последнего дня отчетного периода, сторнирующие проводки). Пересчет отчета в общем случае происходит быстрее, нежели его формирование "с нуля".

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

По окончании формирования и корректировок отчётов производится «чистовой» экспорт отчётной информации в программные комплексы надзора (KliKO, OBVED, ПТК-ПСД и т.д.). Сформированные отчёты могут сохраняться в репозитории. Стратегия сохранения (все версии отчета, версии за указанный период, только последняя версия) определяется пользователем. Обеспечивается ведение журналов отправки и приема отчётов в территориальные органы ЦБ. По факту формирования соответствующих отчетов возможна автоматическая рассылка отчетов или уведомлений пользователям об их формировании по адресам электронной почты, в форматах и моменты времени, предусмотренные списком рассылки. При рассылке уведомлений в них содержится информация, однозначно определяющая место размещения отчета.

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

Имеется также возможность задания для определенных числовых полей отчета диапазона планируемых значений. В случае непопадания полученного реального значения в заданный диапазон, система производит цветовую индикацию данного поля, а также предоставляет дополнительную информацию, поясняющую несоответствие полученного значения запланированным.

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

Общая концепция интеграционного решения

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

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

Для получения дополнительной информации обратитесь в «Квадриум».

© 2004—2024 Quadrium LLC

Яндекс.Метрика