Структурный подход к проектированию системы автоматизации кассовых операций

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

Прежде, чем приступать к созданию системы автоматизированной обработки информации, необходимо сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity — relationship model, ER — model).

Модель «сущность-связь» была предложена в 1976 г. Питером Пин-Шэн Ченом.

Модель «сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных. Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей [5].

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

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

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

На этапе инфологического проектирования представляется модель заданной предметной области. Фактическим стандартом инфологического проектирования является ER-модель, которая имеет в основе два базовых понятия: сущность и связь. Инфологическая модель дает формализованное описание предметной области независимо от структур данных, исключая неоднозначность за счет использования средств формальной логики. Модель программы приведена на Рис. 1.

Рис. 1. Инфологическая модель предметной области.

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

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

Основными задачами даталогического проектирования является создание корректной схемы БД и нормализация исходного отношения.

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

Рис. 2. Даталогическая модель предметной области.

Данные системы учета кассовых операций хранятся в связанных таблицах. Структура основных таблиц базы представлена ниже:

Таблица 2.2.1 Сотрудники.

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

Таблица 2.2.2 Клиенты ф/л.

Ключевым полем таблицы «Клиенты ф/л» является поле Код клиента. Оно однозначно определяет номер каждого клиента в системе. Данная таблица связана с такими таблицами, как «Счет ф/л», «Расходный кассовый ордер», «Приходный кассовый ордер».

Таблица 2.2.3 Клиенты ю/л.

Ключевым полем таблицы «Клиенты ю/л» является поле Код организации. Оно определяет номер каждого юридического лица в системе. Данная таблица связана с такими таблицами, как «Счет ю/л», «Расходный кассовый ордер», «Объявление на взнос наличными».

Таблица 2.2.4 Подразделения.

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

Таблица 2.2.5 Должности.

В данной таблице ключевым полем является Код должности. Таблица имеет связь 1: М с таблицей «Сотрудники».

Таблица 2.2.6 План счетов.

В таблице «План счетов» ключевым является поле № счета. Таблица связана с таблицами «Приходный кассовый ордер» и «Расходный кассовый ордер» связью 1: М.

Таблица 2.2.7 Приходный кассовый ордер.

В данной таблице ключевыми являются поле Номер и поле Дата. Вместе они однозначно определяют каждую операцию. Имеются связи с таблицами, «План счетов» и «Клиенты ф/л».

Таблица 2.2.8 Расходный кассовый ордер.

В таблице «Расходный кассовый ордер» ключевыми являются поля Номер и Дата. Имеются связи с таблицами, «План счетов», «Клиенты ф/л» и «Клиенты ю/л».

Таблица 2.2.9 Авансовый отчет.

В таблице «Авансовый отчет» ключевыми являются поля Номер и Дата. Имеется связь типа М:1 с таблицами «Сотрудники» и «Подразделения.

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

Таблица 2.2.10 Объявление на взнос наличными.

В таблице «Объявление на взнос наличными» ключевым является поле Объявление №. Имеется связь с таблицей «Клиенты ю/л».

На основе данной схемы уже производится физическое проектирование системы.

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

«Главная» форма — форма, через которую осуществляется взаимодействие остальных форм и просмотр отчетов.

Форма «Сотрудники» — форма для ввода, просмотра и редактирования справочников «Сотрудники», «Должности» и «Подразделения».

Формы «Расходный кассовый ордер», «Приходный кассовый ордер» и «Авансовый отчет», «Объявление на взнос наличными» — формы для ввода, редактирования и просмотра справочников «Расходный кассовый ордер», «Приходный кассовый ордер», «Авансовый отчет», «Объявление на взнос наличными» соответственно и выполнения проводок о выдаче/получении денежных средств в кассу. Пункты меню «Расходный кассовый ордер», «Приходный кассовый ордер», «Авансовый отчет» и «Объявление на взнос наличными» также могут работать в нескольких режимах, а именно ввод, изменение и просмотр данных, поэтому блок-схемы технологического процесса для этих пунктов будут выглядеть аналогичным образом.

кассовый автоматизация учет денежный.