Система спроектирована по принципу Open System, что позволяет использовать созданный в ней инструментарий, как разработчиками компании, так и нашими клиентам. Мы сделали доступными все механизмы настроек, начиная от сегментации аналитических счетов под произвольный план счетов, до создания новых и модификации существующих банковских продуктов, отчетов, маршрутов, статусов, операций, а также программных механизмов интеграции нашей АБС с другими системами, расширения ее функциональных возможностей и адаптации к индивидуальным особенностям банка.

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

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

Этот подход имеет большое преимущество перед «коробочными» продуктами, т.к. позволяет получить индивидуальное решение, которое настраивается для конкретного клиента и не усложняет систему в целом. При этом данное решение, не ставит банк в полную зависимость перед разработчиками, с точки зрения цены и сроков разработки новых продуктов и отчетов.

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

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

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

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

Другим очень важным принципом является объектная ориентированность всей функциональности, которой обладает АБС. Это означает, что для каждой технологической сущности (клиент, счет, документ, сделка, операция и т.п.) в АБС предусмотрен единый набор свойств и методов, который доступен, как на уровне хранимых процедур Oracle, так и дорабатывается сейчас на уровне WEB сервисов на сервере приложений Oracle WebLogic.

Как правило,  второй вариант API используется, для доступа из/в других подсистем. Этот механизм является полностью открытым и описан в технической документации к системе. Благодаря этому, при подключении к АБС внешних модулей на все действия с внутренними объектами системы распространяются те же правила, что и при выполнении стандартных операций внутри АБС.

Пользовательский интерфейс, реализованный в технологии клиент-сервер, не имеет бизнес логики на уровне клиентского приложения. Абсолютно все механизмы, реализующие бизнес-логику АБС, реализованы на сервере базы данных Oracle, либо сервере приложений, что позволяет выполнять простую миграцию на более новые версии самой базы данных, а также на новые варианты исполнения пользовательского интерфейса, в том числе и с использованием WEB-технологий. Это также позволяет более гибко проводить замену версий АБС в связи с выходом нового функционала.

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

Условно всю техническую структуру АБС можно разделить на две части см. Рис. 1 – серверную, расположенную в базе данных и сетевую клиентскую. Соответственно серверная часть отвечает за все технологические процессы, хранение и защиту информации, настройку и модернизацию АБС.

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

Логически все сущности внутри АБС можно разделить на четыре уровня:

• Первый уровень – клиенты (контрагенты) банка и их группы;
• Второй уровень – сделки и их параметры;
• Третий уровень – операции над сделками;
• Четвертый уровень – счета и первичные документы бухгалтерского учета — отражение операций в главной книге (General Ledger) в проводках и остатках по счетам.

Иерархия логических сущностей АБС.

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

Логическая структура, иерархия объектов

Основной принцип ведения учета банковских операций в АБС следующий – изначально производится идентификация клиента (существуют операции где этот шаг отсутствует). Если клиента нет, вводится учетная карточка, с перечнем необходимой информации, если есть осуществляется переход в соответствующий тип сделочной подсистемы, где будет выполняться обслуживание клиента. Далее два варианта развития событий, либо это может быть новая сделка, либо обслуживание текущей. В случае новой сделки, система предлагает выбрать банковский продукт и ввести всю необходимую информацию, с контролем заполнения. После чего цепочка обслуживания клиента становится общей для всех типов сделок. Дальнейший механизм называется «принципом одной кнопки», в результате нажатия которой предлагается список доступных операций, который зависит, как минимум, от прав пользователя, типа сделки и состояния(статуса) документа.

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

Операции второго вида – платежные – автоматически порождают документы бухгалтерского учета (проводки) – от одного до произвольного количества на операцию, любых видов – от мемориального ордера, до SWIFT-сообщения, которые далее следуют по своему маршруту исполнения и контроля.

Существует три способа выполнения операций в АБС «SRBank»:

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

Все операции настраиваются на соответствующие типы банковских продуктов. Технологические механизмы настройки типов сделок(банковских продуктов), операций над ними, настройки маршрутизации и  контроля  — являются продуктовым ядром системы .

При работе в АБС пользователь выполняет действия, взаимодействуя, в основном, с объектами второго и третьего уровней – сделками и операциями. За некоторыми исключениями, в частности заведение информации по контрагенту банка. Объекты четвертого уровня – бухгалтерские документы и счета формируются автоматически при выполнении соответствующих операций.

Аналогичный операционному ядру системы принцип настройки и автоматизации учета применяется для основных объектов финансового учета, к основным из них относятся – клиенты, счета и остатки, документы бухгалтерского учета(проводки). Совокупность этих объектов является ядром бухгалтерского учета, главной бухгалтерской книгой АБС (General Leadger), которая включает в себя описание типов и параметров этих объектов, механизмы их создания и контроль, а также выполнение платежных и неплатежных операций над ними (аналогично сделкам), а также маршрутов изменения состояний в течение жизненного цикла.  Благодаря разделению учета на два основных слоя, т.к. продуктовый и бухгалтерский, нашу систему легко использовать с иностранными АБС, в том случае, если продуктовый уровень будет частично или полностью заменен. В таком случае достаточно настроить соответствие операций и типов продуктов, а функции локализации под украинское законодательство будет выполнять наша главная книга.