2020-01-14
452
При создании банка основной его задачей является получение прибыли. Но для успешного функционирования банка необходимо соблюдать ряд определенных условий, от них напрямую зависит то, как будет работать банк, его прибыль и убытки, а так же возможность его дальнейшего расширения и предоставления клиентам новых услуг. В связи с тем, что направления работы банка осуществляются с учетом анализа рисков, возможной прибыли и потерь. Возникает необходимость в введении учета кассовых операций, и возможность оперативного анализа полученных доходов и их дальнейшее распределение по усмотрению аналитического отдела. Создание программного продукта, который удовлетворяет ряду требований предъявляемых для автоматизации учета кассовых операций, является одной из главных задач, которыми должен заняться отдел по техническому и программному обеспечению банка.
Программа, разработанная в рамках данного курсового проекта, является наиболее подходящей для автоматизации учета кассовых операций коммерческого банка.
|
|
|
Прежде, чем приступать к созданию системы автоматизированной обработки информации, необходимо было сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).
Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом.
Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным для нас является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных. Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей [19].
Источником поступления данных являются сведения о клиентах банка и суммах вносимых ими в кассу или получаемых из кассы.
Выходными данными являются отчеты, которые рассчитываются после ввода исходных данных. Все отчеты предоставляются по аналогии с данными, которые представлены в формах программного продукта. Выходными документом являются отчет за период о произведенных операциях по счетам клиентов и кассовая книга. В зависимости от выбранных параметров они могут менять свое содержание и внешний вид.
|
|
|
Для четкого представления структуры нашей системы, необходимо рассмотреть инфологическую модель базы данных.
На этапе инфологического проектирования представляется модель заданной предметной области. Фактическим стандартом инфологического проектирования является ER-модель, которая имеет в основе 2 базовых понятия: сущность и связь. Инфологическая модель дает формализованное описание предметной области независимо от структур данных, исключая неоднозначность за счет использования средств формальной логики. Модель нашей программы приведена на Рис.1
Рис.1. Инфологическая модель предметной области.
После инфологического проектирования базы данных следует построение даталогической модели.
Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.
Основными задачами даталогического проектирования является создание корректной схемы БД и нормализация исходного отношения.
Связи между классами, показанные в инфологической модели, в даталогической модели отображаются либо за счет совместного расположения связанных элементов, либо путем объявления связей между ними. Данные системы учета кассовых операций хранятся в связанных таблицах. Структура основных таблиц базы представлена ниже:
Таблица1
Сотрудники.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Табельный номер | числовой | Длинное целое |
| 2 | ФИО | текстовый | 150 |
| 3 | Код должности | числовой | Длинное целое |
| 4 | Должность | текстовый | 150 |
| 5 | Код подразделения | числовой | Длинное целое |
| 6 | Подразделение | текстовый | 150 |
| 7 | Адрес | текстовый | 100 |
| 8 | Дата рождения | дата/время | - |
| 9 | Место рождения | текстовый | 100 |
| 10 | Гражданство | текстовый | 50 |
В таблице «Сотрудники» ключевым полем является поле Табельный номер. Именно ключевое поле однозначно определяет каждую запись в таблице. Ключевые поля используются для быстрого поиска и связи данных из разных таблиц при помощи запросов, форм и отчетов. Если правильно заданы ключевые поля, то исключается возможность дублирования информации в базе данных. Данная таблица связана почти со всеми другими таблицами базы, что показано на схеме данных (рис.2).
Таблица2
Подразделения.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Код подразделения | числовой | Длинное целое |
| 2 | Наименование подразделения | текстовый | 150 |
Ключевым полем таблицы «Подразделения» является поле Код подразделения. Оно однозначно определяет номер каждого подразделения в системе. Данная таблица связана с такими таблицами, как «Сотрудники», «Расходный кассовый ордер», «Приходный кассовый ордер», «Авансовый отчет».
Таблица3
Должности.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Код должности | числовой | Длинное целое |
| 2 | Наименование должности | текстовый | 150 |
В данной таблице ключевым полем является Код должности. Таблица имеет связь 1:М с таблицей «Сотрудники».
Таблица4
Справочник счетов.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | № счета | тестовый | 50 |
| 2 | Наименование счета | текстовый | 100 |
В таблице «Справочник счетов» ключевым является поле № счета. Таблица связана с таблицами «Приходный кассовый ордер» и «Расходный кассовый ордер» связью 1:М.
Таблица5
Приходный кассовый ордер.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Номер | числовой | Длинное целое |
| 2 | Дата | дата/время | - |
| 3 | ФИО | текстовый | 150 |
| 4 | Табельный номер | числовой | Длинное целое |
| 5 | Код структурного подразделения | числовой | Длинное целое |
| 6 | Корреспондирующий счет | текстовый | 50 |
| 7 | Дебет | текстовый | 50 |
| 8 | Тип | текстовый | 100 |
|
|
|
В данной таблице ключевыми являются поле Номер и поле Дата. Вместе они однозначно определяют каждую операцию. Имеются связи с таблицами «Сотрудники», «Подразделения», «Справочник счетов».
Таблица6
Расходный кассовый ордер
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Номер | числовой | Длинное целое |
| 2 | Дата | дата/время | - |
| 3 | ФИО | текстовый | 150 |
| 4 | Табельный номер | числовой | Длинное целое |
| 5 | Код структурного подразделения | числовой | Длинное целое |
| 6 | Корреспондирующий счет | текстовый | 50 |
| 7 | Кредит | текстовый | 50 |
| 8 | Тип | текстовый | 100 |
В таблице «Расходный кассовый ордер» ключевыми являются поля Номер и Дата. Связи данной таблицы аналогичны связям, имеющимся в таблице «Приходный кассовый ордер».
Таблица7
Авансовый отчет.
| № п/п | Имя поля | Тип поля | Размер поля |
| 1 | Номер | числовой | Длинное целое |
| 2 | Дата | дата/время | - |
| 3 | Табельный номер | числовой | Длинное целое |
| 4 | Подотчетное лицо | текстовый | 150 |
| 5 | Подразделение | текстовый | 50 |
| 6 | Назначение аванса | текстовый | 100 |
| 7 | Получено | денежный | - |
| 8 | Израсходовано | денежный | - |
| 9 | Остаток | денежный | - |
| 10 | Перерасход | денежный | - |
| 11 | Дебет/счет | текстовый | 50 |
| 12 | Дебет/сумма | денежный | - |
| 13 | Кредит/счет | текстовый | 50 |
| 14 | Кредит/сумма | денежный | - |
| 15 | Тип | текстовый | 100 |
В таблице «Авансовый отчет» ключевыми являются поля Номер и Дата. Имеется связь типа М:1 с таблицами «Сотрудники» и «Подразделения.
Схема спроектированной базы данных, т.е. связи и отношения между сущностями показаны на схеме данных (рис 2).
Рис.2. Схема базы данных
На основе данной схемы уже производится физическое проектирование системы.
Все процедуры событий для системы хранятся в модуле форм (Рис.3). При создании первой процедуры события для формы Access автоматически создает модуль формы. Модуль формы представляет способ хранения в одном месте всего кода, который относится только к отдельной форме. Как правило, модули форм содержат только процедуры событий, но в них также могут храниться подпроцедуры и функции.
|
|
|
Рис.3. Дерево программных модулей
«Главная» форма – форма, через которую осуществляется взаимодействие остальных форм и просмотр отчетов.
Форма «Сотрудники» - форма для ввода, просмотра и редактирования справочников «Сотрудники», «Должности» и «Подразделения».
Формы «Расходный кассовый ордер», «Приходный кассовый ордер» и «Авансовый отчет» - формы для ввода, редактирования и просмотра справочников «Расходный кассовый ордер», «Приходный кассовый ордер», «Авансовый отчет» соответственно и выполнения проводок о выдаче/получении денежных средств в кассу. Пункты меню «Расходный кассовый ордер», «Приходный кассовый ордер» и «Авансовый отчет» также могут работать в нескольких режимах, а именно ввод, изменение и просмотр данных, поэтому блок-схемы технологического процесса для этих пунктов будут выглядеть аналогичным образом.
