Документооборот в АБС «Ва-Банк ХL»: межмодульные взаимодействия

Содержание

 

Документооборот в АБС «Ва-Банк ХL»: межмодульные взаимодействия           3           

Банки и электронное взаимодействие организаций-контрагентов                         4

Технологии взаимодействия                                                                                      7

Коммуникации                                                                                                             9

Реализация нового сервиса в RS Audio                                                                   10

Библиография                                                                                                             11

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Документооборот в АБС «Ва-Банк ХL»: межмодульные взаимодействия

 

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

   В автоматизированной банковской системе компании «ФОРС» «Ва-Банк ХL», разработанной в среде Огасlе, организован единый настраиваемый внутрисистемный канал передачи данных, получивший название интерфейса межмодульных сообщений (ММС). Его функция — поддержка всего внутреннего документооборота, включая генерацию документов (в том числе служебных), их последовательную обработку и доставку адресату в системе. Интегрированная банковская система АБС «Ва-Банк XL» имеет модульную архитектуру. Модули "Ва-Банк XL» поддерживают  отдельные  бизнес-области банковской деятельности. Они реализованы как независимые клиент —серверные приложения, основанные на единых принципах и разрабатываемые параллельно.   Бизнес-области   разграничены естественным образом так, что большая часть информационных взаимодействий между программными компонентами остается внутри модуля. Прямые внешние обращения из модуля в модуль практически отсутствуют. Исключением является модуль Ядро содержащий картотеки клиентов, лицевые счета, архив проводок, курсы валют, процентные ставки и прочие справочники, необходимые всем модулям системы. «Ядро» — единственный в системе модуль, объекты которого используются другими модулями непосредственно.

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

    Интерфейс ММС содержит очередь сообщений, набор хранимых процедур для ее обслуживания, а также описание типов межмодульных сообщений, механизмы настройки и динамического исполнения процедур приема и передачи информации. Обычные типы ММС — это платежные документы в формате РКЦ, платежные документы в формате SWIFT, файлы различных форматов и т. д. Структуры данных и базовые процедуры исполнения обработки ММС расположены в ядре системы и доступны для обращения из любого модуля Ва-Банк XL, а реализованная гибкая настройка и динамическое исполнение процедур обработки ММС позволяет легко решать задачи конфигурирования и пополнения новыми функциональными модулями версии системы, установленные в банках-заказчиках.

 

Банки и электронное

взаимодействие организаций-контрагентов

 

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

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

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

  Даже если произвести беглый анализ интересов клиентов универсальной (не вертикальной, не отраслевой и не корпоративной) торговой площадки, наглядно видно, что большинство ее участников, которые время от времени либо покупают какой-то товар, либо продают другой, заинтересованы не только и не столько в технических преимуществах торговли, таких как:

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

Напротив — в первую очередь им нужна такая простая и несложно реализуемая, казалось бы, услуга, как оперативное оповещение получателя платежа (далее — «поставщик») о выдаче распоряжения на перевод денег на его счет.

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

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

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

 

Технология взаимодействия

 

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

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

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

    Можно ли реализовать оповещение поставщиков о перечислении им средств потребителей с помощью той же системы «Клиент—Банк»? Да, но только в том случае, если у поставщика установлена такая же программа с предусмотренным сервисом оповещения. Но это, скорее, исключение из правил. Нельзя же, в конце концов, у каждого поставщика установить все программы «Клиент—Банка», с которыми могут работать его потребители! Системы класса «Интернет—Клиент» зарекомендовали себя как более универсальные решения. Впрочем, такая характеристика относится лишь к тем из них, которые действительно являются «тонкими» и используют стандартный НТМL-интерфейс без установки на компьютер поставщика каких-либо дополнительных программ, будь то АсtiveХ-компоненты или Java-аплеты (и те, и другие — разновидность так называемых толстых программ «Клиент—Банк»).

   И поскольку большинство существующих разработок «Клиент—Банк» такой сервис не реализуют, за него берутся торговые площадки, становясь не только деловыми, но и технологическими посредниками между потребителями и поставщиками товаров и услуг. Очевидно, что как только банки начнут использовать некоторые несложные механизмы оповещений, значительное число их клиентов вообще перестанет обращаться к сервису торговых площадок. Ну не нужен фирме из десяти человек, срочно заказывающей тонер для единственного принтера, механизм гарантирования сделок!

 

 

 

 

 

 

Коммуникации

 

  Что же требуется для поддержания необходимых коммуникаций между поставщиками и потребителями в обход сервиса торговых площадок? Как уже было сказано выше, традиционные системы «Клиент—Банк» здесь практически бессильны. Если же взглянуть повнимательнее на системы класса «Интернет—Клиент—банка», то здесь ситуация следующая. Поставщик хочет получать оповещения об оплате от всех своих потребителей с минимальными для себя усилиями, иначе он просто откажется от этой идеи и будет дожидаться реального зачисления средств на свой счет. Устанавливать для этого специальное программное обеспечение поставщика уж точно не заставишь, поэтому остается уповать на возможности стандартного офисного ПО. Неоспоримое преимущество здесь приобретают действительно «тонкие» НТМL-системы, для которых достаточно стандартного браузера и встроенных в операционную систему криптографических средств, обеспечивающих безопасность.

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

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