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

 

Модуль вкладных операций «Scrooge Savings». Пакет технической документации

Глава 1. Вводная часть

Модуль вкладных операций «Scrooge Savings» (далее по тексту - МВО, модуль, система) - это отдельная, работающая независимо от операционного дня, банковская подсистема, предназначенная для ведения депозитных договоров и операций по ним, которая также является удобным хранилищем данных для различных систем, работающих с платежными картами. На данный момент реализованы интерфейсы модуля с Национальной системой массовых электронных платежей (НСМЭП) Национального банка Украины и с системой «Tieto Conts». Планируется также реализовать взаимодействие с системой «Card Galaxy», возможно и с другими платежными системами.

Раздел 1.1. Общие положения

МВО позволяет вести внутри себя массивы клиентов, договоров и счетов. Операции по счетам можно консолидировать на сводные счета, которые открываются одинаково в МВО и в САБ, и вести параллельный учет. МВО содержит в себе подсистему пакетирования, которая позволяет автоматически получать ведомость сводных проводок для переноса в операционный день. Эта же подсистема используется и для взаимодействия с различными процессингами (карточными системами).

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

Этот документ содержит описание структур данных Модуля вкладных операций «Scrooge Savings» на понятийном уровне (сущности и связи между ними), а также, логики построения и функционирования системы. Он предназначен, прежде всего, для администратора МВО. Хотя этот документ не является описанием работы с АРМом администратора (руководством по программе в традиционном смысле), его понимание необходимо для того, чтобы грамотно произвести начальную настройку системы и вести ее сопровождение.

Раздел 1.2. Требования к аппаратному и программному обеспечению

МВО реализован в технологии «Клиент-сервер» (двухуровневая архитектура). В качестве серверной платформы может быть использован «Microsoft SQL Server 7.0», или «Microsoft SQL Server 2000». В качестве клиентской платформы используется «Microsoft Windows 95/98/NT 4.0 с SP 5 или выше/2000» c установленным «Internet Explorer 4.0», или выше.

Минимальные требования к аппаратной конфигурации сервера зависят от предполагаемого объема операций, количества рабочих мест, и т.п., поэтому они могут сильно варьироваться. Минимальные требования к клиентской рабочей станции: процессор - P200 MMX и выше; ОЗУ -- 16 Мб для Windows 9x, 32 - для Windows NT, 64 - для Windows 2000; не менее 100Мб свободного места на жестком диске.

Глава 2. Общие принципы организации данных в МВО

Раздел 2.1. Мотивация

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

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

Раздел 2.2. Описание подхода. Роль администратора МВО

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

Те, кто знаком с концепцией объектно-ориентированного программирования, могут провести следующую аналогию, которая должна упростить понимание этой идеи. Типовую сущность можно представить себе аналогом класса (объектного типа), а реальную -- аналогом экземпляра (переменной) этого класса (типа).

Эти два набора сущностей определяют два уровня функционирования системы в целом:

• построение типовых сущностей (т.е. настройка шаблонов);
• построение по готовым шаблонам реальных сущностей и работа с ними.

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

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

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

Администратору МВО следует постоянно помнить о том, что ошибка в настройке бухгалтерской модели может привести к весьма трагическим последствиям. Примерами таких последствий могут быть массовые неправомерные действия операторов, или вообще остановка работы системы в целом, либо какой-то ее подсистемы. Причем может не существовать штатных средств восстановления работоспособности системы и/или восстановления данных после таких ошибок.

ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ!

Прежде чем делать любые изменения в настройке бухгалтерской модели на рабочей базе данных, ОБЯЗАТЕЛЬНО проделайте эксперимент на резервной базе!

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

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

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

Раздел 2.3. Немного о структуре таблиц

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

• Id (целое число) - внутренний, автоматически формируемый номер записи в таблице (суррогатный ключ), на основе которого строятся ссылки (внешние ключи), и который уникален в пределах таблицы.
• Код (поле Code) - текстовый идентификатор (до 32-х символов), уникальный в пределах таблицы.
• Название (поле Name) -- длинный (до 80-ти символов) текстовый идентификатор, предназначенный для пояснения смысла данной записи в таблице.

Структура простейшей таблицы (справочника) этими тремя полями (не считая служебных полей) и ограничивается.

Далее в этом разделе, при описании структур конкретных таблиц, мы, как правило, не будем упоминать о поле «Id» (оно есть во всех таблицах модуля) и других чисто технических полях. Также для всех таблиц, если не оговорено обратное, предполагается, что поддерживается уникальность по полю «Код».

Глава 3. Типовой договор. Основные понятия. Настройка операций

Центральным понятием системы является понятие типового договора. Типовой договор - это настраиваемая администратором модель (шаблон), в соответствии с которой, оператор открывает реальные (клиентские) договоры. При открытии любого клиентского договора, указывается типовой договор, который служит ему шаблоном. Т.е. для каждого клиентского договора определен типовой договор, в котором открыт этот клиентский. Свойствами типового договора определяются все основные свойства открытых в нем клиентских договоров, а именно:

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

Типовой договор в МВО является достаточно сложной сущностью и строится на основе многих элементарных.

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

Раздел 3.1. Группы типовых договоров

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

Справочник групп типовых договоров содержит следующий набор реквизитов:

• Код
• Название

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

Раздел 3.2. Понятие назначения счета

Назначение счета - это минимальный элемент, на основе которого строится вся бухгалтерская модель МВО. Хотя это - «элементарная» сущность, описать ее смысл словами не очень просто. В базе данных это понятие представлено справочником назначений счетов, который содержит минимальный набор реквизитов:

• Код
• Название

Иначе говоря, определяя в системе назначения счета, мы просто присваиваем ему какой-то код, а в поле «Название» пишем пояснение, например «Вкладной счет».

Можно сказать, что назначение счета является «модельным» (или типовым) аналогом реального счета.

На самом деле это не совсем так -- оно находится на несколько более высоком уровне абстракции.

Назначение не определяет ни валюту счета, ни балансовый счет, в котором он (будет) открыт, ни маску счета.

Его смысл скорее можно определить как «тип функциональной нагрузки» счета в контексте бухгалтерской модели.

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

Каждое из назначений определяет какую-то сторону функциональности счета.

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

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

Назначение счета является основным инструментом базовых механизмов функционирования системы. Основные функции назначения счета:

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

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

Раздел 3.3. Справочник валют

Этот справочник определяет набор валют, с которыми может работать система. Справочник содержит следующие реквизиты:

• Цифровой код валюты
• Символьный код валюты
• Название валюты
• Полное название целых
• Полное название дробных
• Аббревиатура целых
• Аббревиатура дробных

Раздел 3.4. Справочник типов документов

Этот справочник предназначен для определения типов (печатных форм) банковских документов. Он содержит следующий набор реквизитов:

• Код
• Название

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

При печати операции каждая проводка из нее печатается определенным для этой проводки типом документа (выводится соответствующая этому типу отчетная форма).

Вот пример стандартного заполнения справочника типов документов:

Код типа документа	Название	Комментарий
unknown	Неизвестный тип	Данный код типа присваивается документам, определить тип которых не представляется возможным. Как правило, это документы, автоматически закачиваемые в МВО из др. систем.
mem_order	Мемориальный ордер
obyava	Объявление
plat_por	Платежное поручение
pri_cash	Приходный кассовый ордер
ras_cash	Расходный кассовый ордер

Раздел 3.5. Типовые проводки

Типовая проводка - это «модельный» или «типовой» аналог бухгалтерской проводки в МВО. Как уже упоминалось выше, при определении типовой проводки, корреспонденция счетов задается терминах назначений счетов. Например, пусть в системе определены назначения счетов «Счет кассы» и «Вкладной счет». Тогда можно определить типовую проводку: дебет «Счет кассы» - кредит «Вкладной счет». Определение такой проводки, дает возможность (пока только принципиальную) корреспонденции кассовых счетов в дебете с депозитными счетами в кредите.

Справочник типовых проводок содержит следующий набор реквизитов:

• Код
• Название
• Назначение счета по дебету (ссылка на справочник назначений счетов)
• Назначение счета по кредиту (ссылка на справочник назначений счетов)
• Режим экспорта проводки в САБ:
• Сводная проводка
• Отдельный документ
• Не передается
• Тип печатного документа по умолчанию (ссылка на справочник типов документов)
• Информация для отчетов:
• Тип движения
• Приход
• Расход
• Тип оборотов
• Кассовые
• Мемориальные

Заметим, что типовые проводки сами по себе никак не привязаны к справочнику валют.

Раздел 3.6. Типовые операции, как модели проводок

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

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

Справочник типовых операций содержит (определяет) полный набор типовых операций, которые возможно выполнить в системе. Вот список реквизитов этого справочника:

• Код
• Название
• Тип
• Приход
• Расход
• Признак «Системная операция»

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

Признак «Системная операция» следует устанавливать операции, если ее не следует показывать оператору (т.е. она должна быть недоступна для выполнения в ручном режиме). Зачем это нужно, мы поясним позже, при описании регламентных работ.

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

• Минимальная сумма проводки
• Максимальная сумма проводки
• Процент от общей суммы операции
• Тип документа в САБ (необязательный реквизит)
• Кассовый символ (необязательный реквизит)

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

Рис. 1. Структурная схема операций в МВО

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

Раздел 3.7. Определение типовых операций в типовом договоре

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

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

• минимально допустимая сумма операции;
• максимально допустимая сумма операции.

Вот схема определения типовых операций в типовом договоре:

Рис. 2. Структурная схема определения операций в типовом договоре

На этом описание механизма настройки операций в основном завершено.

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

Глава 4. Типовой договор. Настройка счетов

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

Раздел 4.1. Типы счетов

Справочник типов счетов имеет следующую структуру:

• Код
• Название

Понятие типа счета в МВО введено для того, чтобы объединять назначения счетов, сходные по типу выполняемых функций в группы. Например, к типу «Счета расходов» можно отнести назначения «Расходы по депозитным договорам физлиц», «Расходы по карточным договорам физлиц» и «Расходы по договорам юрлиц». Саму «сходность типа выполняемых функций» система никак не отслеживает, ответственность за «правильность» (точнее -- за логичность) группировки назначений счетов по типам целиком лежит на администраторе системы. Технически таблица назначений счетов просто ссылается на таблицу типов счетов посредством внешнего ключа.

Раздел 4.2. Сводные счета

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

Таблица сводных счетов имеет следующую структуру:

• Номер счета (код)
• Валюта счета (ссылка на справочник валют)
• Тип (ссылка на таблицу типов счетов)
• Активность
• Активный
• Пассивный
• Название
• Признак запрещения автоматического открытия счетов
• Маска для автоматического открытия счетов
• Последний открытый счет (счетчик номеров)

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

Заметим также, что активность лицевого счета определяется активностью сводного счета, на который он консолидируется.

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

B

B

B

B

K

L

L

L

L

L

L

L

L

L

Где:

• BBBB - четыре цифры балансового счета
• K - место контрольного разряда
• LLLLLLLLL - cтрока цифр и букв «X» (икс в верхнем регистре), длиной от 1-го до 9-ти символов

При открытии счета цифры переносятся из маски в номер «позиция в позицию», кроме пятой (позиции контрольного разряда), где в маске всегда должен стоять 0, а в номере счета пишется рассчитываемая контрольная цифра. Позиции, где стоят символы «X» заполняются монотонно возрастающими номерами с ведущими нулями, как если бы они все стояли последовательно.

Заметим, что в таблице (лицевых) счетов МВО поддерживается уникальность по номеру счета. Т.е. попытка открыть счет с уже существующим номером, приведет к ошибке нарушения уникальности, и такой счет не будет открыт. Поэтому, задавая маски для автоматического открытия счетов, нужно избегать ситуаций, могущих привести к нарушению уникальности:

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

2

6

2

0

0

X

X

X

1

X

и

2

6

2

0

0

X

X

X

X

2

приведет к генерации счета с номером 2620800012, т.е. если использовать обе маски, уникальность будет нарушена. Маски

2

6

2

0

0

X

X

X

1

X

и

2

6

2

0

0

X

X

X

2

X

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

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

Раздел 4.3. Назначения счетов в типовом договоре. Сервис автоматического открытия счетов. Поиск счетов при выполнении операций

Список назначений счетов в типовом договоре определяет:

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

Для определения списка назначений счетов используется связочная таблица - таблица назначений счетов типового договора. Вот список реквизитов этой таблицы:

• Типовой договор (ссылка на таблицу типовых договоров)
• Назначение счета (ссылка на справочник назначений счетов)
• Валюта (ссылка на таблицу валют)
• Сводный счет (ссылка на таблицу сводных счетов)
• Режим определения назначения счета
• Автоматическое открытие счета
• Открытие вместе со сводным счетом (вручную)
• Применение назначения к счету уже открытому в этом договоре
• Применение назначения к счету, уже открытому в другом договоре того же клиента
• Применение назначения к счету уже открытому в договоре другого клиента
• Типовой договор, из которого берется назначение уже открытого счета для последних трех режимов определения назначения (еще одна ссылка на таблицу типовых договоров)
• Назначение счета (уже определенное), к которому применяется определяемое назначение для последних трех режимов определения назначения (циклическая ссылка на себя)

Для применения (привязки) назначений счетов к лицевым счетам, в МВО используется таблица назначений счетов клиентского договора. Она имеет очень простую структуру:

• Договор (ссылка на таблицу договоров)
• Назначение счета в типовом договоре (ссылка на таблицу назначений счетов типового договора)
• Счет (ссылка на таблицу счетов)

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

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

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

• «Вкладной счет»,
• «Счет карты»,
• «Счет кассы».

Также будем считать, что определены следующие типовые проводки:

Название типовой проводки	Назначение дебета	Назначение кредита
Взнос наличных	Счет кассы	Вкладной счет
Выдача наличных	Вкладной счет	Счет кассы

И определены две операции «Взнос наличных» и «Выдача наличных», у каждой из которых в списке проводок стоит одна одноименная ей типовая проводка.

Пункт 4.3.1. Определение назначения счета в режиме «Автоматическое открытие счета».

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

Пример 1.

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

Итак, в этом примере мы получили для депозитного договора механизм взноса/снятия наличных денег через кассу.

Пункт 4.3.2. Определение назначения счета в режиме «Открытие вместе со сводным счетом».

Режим открытия счета вместе со сводным счетом применяется в том случае, если этот счет необходимо параллельно вести в САБ. Он похож на режим автоматического открытия. В этом случае задается тот же набор параметров (собственно назначение, валюта и сводный счет). Однако указание сводного счета в этом случае имеет другой смысл.

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

Приведем схему определения назначений счетов в типовом договоре для первых двух режимов.

Рис. 3. Структурная схема привязки счетов к договорам для режимов определения назначения счета в типовом договоре, предполагающих открытие счета

Пункт 4.3.3. Определение назначения счета в режиме «Применение назначения к счету уже открытому в этом договоре».

Для назначений, определяемых в режиме «Применение назначения к счету уже открытому в этом договоре», нужно указать валюту, и назначение, уже определенное в этом договоре в режиме «Автоматическое открытие счета», или в режиме «Открытие вместе со сводным счетом», в этой же валюте. Назначения счетов, определенные в этом режиме, не инициируют открытия счетов. Смысл их в том, что они применяют определяемое назначение счета в контексте данного договора к другому, уже определенному назначению. Иначе говоря, назначение счета, определяемое в этом режиме, становится в контексте данного типового договора псевдонимом (или синонимом) для другого назначения. Поясним на примере.

Пример 2.

• Допустим, в системе определен типовой договор «Обслуживание карт» и в нем, в режиме «Автоматическое открытие счета» определено назначение «Счет карты» в валюте UAH (украинская гривна).
• Пусть для назначения «Счет карты» в этом договоре разрешены какие-то операции, специфичные для карт (для примера не важно какие).
• Допустим, что нам необходимо разрешить в этом договоре для счета карты операции взноса/выдачи наличных через кассу, как мы делали в предыдущем примере для депозитного счета. Можно конечно завести в системе типовые проводки для взноса/выдачи наличных с карточного счета через кассу, потом завести соответствующие операции, а далее проделать все как в предыдущем примере. Но можно поступить иначе.
• Определим в типовом договоре «Обслуживание карт» назначение счета «Вкладной счет» в режиме «Применение назначения к счету уже открытому в этом договоре», и применим его к назначению «Счет карты».
• Разрешим в этом типовом договоре операции «Взнос наличных» и «Выдача наличных» в валюте UAH.
• Теперь при открытии клиентского договора в типовом договоре «Обслуживание карт», в нем будет открыт лицевой счет в валюте UAH, и к нему будет применено назначение «Счет карты». Будем для определенности считать, что ему присвоен номер 262501. А затем к этому же счету будет применено еще и назначение «Вкладной счет».
• При попытке выполнить операцию «Взнос наличных» в этом договоре, все будет происходить, как в предыдущем примере, только при поиске счета по назначению «Вкладной счет», будет найден счет 262501, открытый как счет карты (ведь к нему применено и назначение «Вкладной счет»). И он будет подставлен в реальную проводку как счет кредита. Таким образом, в контексте данного договора, назначение «Вкладной счет» становится псевдонимом (синонимом) назначения счета «Счет карты». Теперь в контексте типового договора «Обслуживание карт» проводки, определенные для назначения «Вкладной счет» применяются к счету карты.

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

Пункт 4.3.4. Определение назначения счета в режиме «Применение назначения к счету, уже открытому в другом договоре того же клиента»

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

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

Пример 3.

• Допустим, в системе определен типовой договор «Обслуживание карт» и в нем, в режиме «Автоматическое открытие счета» определено назначение «Счет карты», в валюте UAH (украинская гривна).
• Пусть для назначения «Счет карты» в этом договоре разрешены какие-то операции, специфичные для карт (для примера не важно какие).
• Допустим, что нам необходимо разрешить для счета карты операции взноса/выдачи наличных через кассу. Причем по каким-то соображениям мы хотим разрешить операции со счетом карты через кассу не всем клиентам - владельцам карт, а только некоторым из них.
• Заведем в системе типовой договор «Кассовые операции с карточным счетом» и определим в нем назначение счета «Вкладной счет» в режиме «Применение назначения к счету уже открытому в другом договоре этого клиента». Применим это назначение к назначению «Счет карты» из договора «Обслуживание карт».
• В договоре «Кассовые операции с карточным счетом» разрешим операции «Взнос наличных» и «Выдача наличных» в валюте UAH.
• Допустим, мы откроем клиенту «Иванов» договор в типовом договоре «Обслуживание карт». В нем будет открыт лицевой счет в валюте UAH, к которому будет применено назначение «Счет карты». Будем для определенности считать, что ему присвоен номер 262501. С этим счетом пока можно выполнять только определенные в типовом договоре «Обслуживание карт», специфичные для карт операции.
• Теперь откроем этому же клиенту договор в типовом договоре «Кассовые операции с карточным счетом». При открытии этого договора, система найдет уже открытый клиенту «Иванов» договор «Обслуживание карт», затем найдет открытый в нем счет 262501 с назначением «Счет карты» и применит к нему назначение «Вкладной счет», определенное в типовом договоре «Кассовые операции с карточным счетом».
• При попытке выполнить операцию «Взнос наличных» в договоре «Кассовые операции с карточным счетом» клиента «Иванов», когда система будет искать счет по назначению «Вкладной счет», она найдет счет 262501, открытый в договоре «Обслуживание карт». Именно этот счет будет подставлен в кредит выполняемой проводки.
• Таким образом, у клиента «Иванов» открыто два договора «Обслуживание карт» и «Кассовые операции с карточным счетом», каждый из которых определяет свой набор операций со счетом 262501 (каждый через свое назначение, примененное к этому счету).

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

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

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

Пункт 4.3.5. Определение назначения счета в режиме «Применение назначения к счету уже открытому в договоре другого клиента».

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

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

Рис. 4. Структурная схема привязки счетов к договорам для режимов определения назначения счета в типовом договоре, не предполагающих открытия счета

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

Глава 5. Счета банка. Алгоритм выполнения операции

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

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

Раздел 5.1. Служебный договор

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

В заключение этого

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

Раздел 5.2. Общие назначения счетов

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

• Назначение счета (ссылка на справочник назначений счетов)
• Валюта счета (ссылка на справочник валют)
• Счет (ссылка на таблицу счетов)

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

Приведем структурную схему определения общих назначений счетов.

Рис. 5. Структурная схема определения общих назначений счетов

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

• Определить назначение в служебном типовом договоре в режиме «Автоматическое открытие счета» или «Открытие вместе со сводным счетом» (предпочтительно последнее).
• Если на предыдущем шаге назначение было определено в режиме «Автоматическое открытие счета», нужно открыть для этого счета сводный счет.
• Открыть счет с этим назначением в реальном служебном договоре.
• Если назначение в служебном типовом договоре было определено в режиме «Автоматическое открытие счета», установить сводному счету признак запрещения автоматического открытия счетов
• Определить это назначение как общее, сопоставив ему только что открытый счет.

Естественно, определять назначения и открывать счета нужно в одной и той же валюте.

Раздел 5.3. Филиалы

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

• МФО банка (филиала)
• Номер филиала
• Название банка
• Адрес банка

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

Раздел 5.4. Клиенты. Группы клиентов

Клиенты - это единственная в МВО реальная сущность, не имеющая типового аналога. Эта таблица просто хранит реквизиты клиентов, обслуживающихся в системе:

• Тип клиента
• Физическое лицо
• Юридическое лицо
• Филиал (ссылка на таблицу филиалов)
• Код клиента (уникален в пределах филиала)
• Идентификационный код
• Фамилия
• Имя
• Отчество
• Дата рождения (необязательный реквизит)
• Название (необязательный реквизит)
• Реквизиты документа удостоверяющего личность
• Название документа
• Номер документа (необязательный реквизит)
• Кем выдан документ (необязательный реквизит)
• Дата выдачи документа (необязательный реквизит)
• Резидентность
• Резидент
• Нерезидент
• Адрес
• Индекс
• Город
• Улица
• Телефон
• e-mail

Для того чтобы обеспечить возможность работы механизма раздачи прав на клиентов пользователя