Создание программы для автоматизации фронт-офиса банка

Размещено на http://www.allbest.ru/

Создание программы для автоматизации фронт-офиса банка

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

Современные АБС в большинстве своем имеют встроенные скриптовые языки программирования, которые позволяют программистам банка создавать собственные процедуры и отчеты. Возможности этих языков достаточно большие, но, конечно, уступают таким языкам, как Delphi или C, что налагает некоторые ограничения на разрабатываемые программы.

Необходимость автоматизации новых банковских продуктов приводит к проблеме выбора: либо писать под каждый процесс свою программу, либо создать некую универсальную программную оболочку. В результате возникла идея концепции «программного конструктора» -- универсальной программной среды, в которой можно реализовать различные бизнес-процессы. Первыми в этой технологии появились CreditFrontOffice (CFO) и DepozitFrontOffice (DFO), далее -- другие проекты.

Рис. 1. Архитектура проекта CFO

Краткое описание элементов схемы и работа в системе

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

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

Метаданные отчетов -- подсистема справочников для описания правил и алгоритмов формирования отчетов по клиентам и заявкам. Отчеты формируются на основе Word- или Excel-шаблонов или через вызов процедур из DLL.

Настроечные справочники предназначены для классификации клиентов, заявок и организации работы с ними.

Архив финансовых показателей -- наборы данных, предназначенные для хранения групп числовых значений, которые характеризуют клиента или заявку, позиционированных на определенную дату. Группа финансовых показателей представляет собой совокупность таблиц с показателями и их параметрами. Например, группа финансовых показателей -- «Агрегированный баланс», показатели -- «Касса», «Расчетный счет в рублях» и т. д., параметр -- «Остаток».

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

Работа с клиентами. В карточке клиента заполняются его основные атрибуты, определяется его принадлежность к одному или нескольким классификаторам. Затем по клиенту вводятся финансовые показатели по имеющимся данным на каждую отчетную дату. Далее планируются мероприятия, доступные для данного типа клиента. Планирование осуществляется в досье клиента, при этом указывается дата планового начала и окончания, ответственный исполнитель, имена внешних исполнителей, комментарии и т. д. Мероприятие получает состояние «Запланировано». При наступлении даты начала исполнения, если его состояние не изменилось, ответственный исполнитель получает сообщение по электронной почте о том, что наступил срок исполнения такого-то мероприятия по такому-то клиенту. автоматизированный модуль скриптовый программист

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

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

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

Рис. 2. Архитектура проекта DFO

Краткое описание элементов схемы

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

Метаданные отчетов -- подсистема справочников для описания правил и алгоритмов формирования отчетов по операциям. Отчеты формируются на основе Word- или Excel-шаблонов или через вызов процедур из DLL (печать справок строгой отчетности, посылка задания на печать в ККМ и т. д.).

Настроечные справочники -- таблицы, в которых хранятся глобальные настройки, диалоги, настройки печати справок строгой отчетности, настройки принтеров и т. д.

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

Подсистема проверок -- набор SQL-запросов для проверки правильности ввода информации исполнителем.

Журнал операций хранит данные о проведенных операциях и некоторых их атрибутов, например:

· дата операционного дня;

· код пользователя;

· уникальный код операции;

· код клиента в БД АБС и т. д.

Все используемые функции написаны преимущественно на PL/SQL и хранятся либо как строки SQL-запросов в БД, либо как хранящиеся на сервере процедуры.

При выборе пользователем конкретного продукта программа создает универсальную форму со списком полей, подлежащих вводу. После ввода автоматически запускается подсистема проверок, которая исключает возможность ввода неправильных данных. Введенные параметры передаются запускаемой на сервере головной процедуре, а она в свою очередь создает в БД АБС все необходимые для данного продукта банковские объекты: кассовые ордера, мемориальные ордера, депозитные договора и т. д. При этом она широко использует существующую серверную логику АБС. Головная процедура всегда возвращает результат своего выполнения. При успешном выполнении создается запись в журнале операций с уникальным кодом и заполняется журнал квитанций порожденных объектов, который схематически можно представить в виде следующей таблицы:

Этот журнал используется процедурами отката и процедурами подготовки отчетов. После удачного исполнения основной процедуры выполняется печать всех необходимых документов, печать справок строгой отчетности и печать на ККМ. Для использования справок строгой отчетности из программы обменного пункта обеспечена возможность интеграции с ним.

Архитектура проекта DFO существует в двух вариантах: для работы в онлайне и офлайне.

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

Размещено на Allbest.ru