Краткое описание элементов схемы
Журнал операций хранит данные о проведенных операциях и некоторых их атрибутов, например: Архитектура проекта DFO существует в двух вариантах: для работы в онлайне и офлайне. Код клиента в БД АБС и т. д. Тип порожденного объекта. Код порожденного объекта. Уникальный код операции; Дата операционного дня; Мемориальный ордер. Депозитный договор. Код пользователя; Кассовый ордер. Код операции. Счет… Читать ещё >
Краткое описание элементов схемы (реферат, курсовая, диплом, контрольная)
Продукты, разрабатываемые нами, представляются в древовидной форме. Доступ к тому или иному банковскому продукту осуществляется через глобальную систему прав, разработанную в нашем банке. Каждый продукт связан с одной или несколькими последовательно выполняемыми процедурами на сервере Oracle.
Метаданные отчетов — подсистема справочников для описания правил и алгоритмов формирования отчетов по операциям. Отчеты формируются на основе Wordили Excel-шаблонов или через вызов процедур из DLL (печать справок строгой отчетности, посылка задания на печать в ККМ и т. д.).
Настроечные справочники — таблицы, в которых хранятся глобальные настройки, диалоги, настройки печати справок строгой отчетности, настройки принтеров и т. д.
Метаданные полей ввода — для каждого продукта задается набор полей для ввода информации. Поле характеризуется несколькими атрибутами: название, тип данных, SQL-запрос для установки начального значения, SQL-запрос, реализующий алгоритм после ввода поля, SQL-запрос для получения списка значений и т. д.
Подсистема проверок — набор SQL-запросов для проверки правильности ввода информации исполнителем.
Журнал операций хранит данные о проведенных операциях и некоторых их атрибутов, например:
- · дата операционного дня;
- · код пользователя;
- · уникальный код операции;
- · код клиента в БД АБС и т. д.
Все используемые функции написаны преимущественно на PL/SQL и хранятся либо как строки SQL-запросов в БД, либо как хранящиеся на сервере процедуры.
При выборе пользователем конкретного продукта программа создает универсальную форму со списком полей, подлежащих вводу. После ввода автоматически запускается подсистема проверок, которая исключает возможность ввода неправильных данных. Введенные параметры передаются запускаемой на сервере головной процедуре, а она в свою очередь создает в БД АБС все необходимые для данного продукта банковские объекты: кассовые ордера, мемориальные ордера, депозитные договора и т. д. При этом она широко использует существующую серверную логику АБС. Головная процедура всегда возвращает результат своего выполнения. При успешном выполнении создается запись в журнале операций с уникальным кодом и заполняется журнал квитанций порожденных объектов, который схематически можно представить в виде следующей таблицы:
Код операции. | Тип порожденного объекта. | Код порожденного объекта. |
N1. | Кассовый ордер | N2. |
N1. | Мемориальный ордер | N3. |
N1. | Счет. | N4. |
N1. | Депозитный договор | N5. |
Этот журнал используется процедурами отката и процедурами подготовки отчетов. После удачного исполнения основной процедуры выполняется печать всех необходимых документов, печать справок строгой отчетности и печать на ККМ. Для использования справок строгой отчетности из программы обменного пункта обеспечена возможность интеграции с ним.
Архитектура проекта DFO существует в двух вариантах: для работы в онлайне и офлайне.
Процесс разработки нового продукта заключается в том, что разрабатывается вся серверная логика, описываются поля вводимых параметров, создается шаблон отчета в одном из офисных приложений, описываются поля и алгоритмы их вычисления в этом шаблоне. Таким образом, данная программная оболочка позволяет очень быстро создать программу обработки практически любого банковского продукта в едином и знакомом операционному работнику интерфейсе.