Смекни!
smekni.com

Автоматизація обліку депозитних операцій комерційного банку (стр. 14 из 18)

3. Підготовка до роботи

Для початку роботи необхідна наявність всіх технічних і пргорамних засобів: IBM-сумісної ПЕОМзі стандартним набором технічних засобів (принтер стандартної конфігурації, маніпулятор типу миша, монітор не нижче VGA, мікропроцесор не нижче INTEL80386, ОЗУ-не нижче 2Мб, на вінчестері-20Мб), OS MS WINDOWS 95, СУБД ACCESS 2.0 і вище.

А також наявність файлу deprach.mdb, який є основним файлом бази даних для роботи програмногго комплексу.

4. Опис операцій

Після запуску програмного комплексу висвічується запит на введення паролю. Якщо занесений пароль є невірним, то програма завершує свою роботу. При правильному набраному паролі з”являється форма меню, в якій необхідно вибрати потрібний пункт.

При виборі “Новий договір” висвічується форма для занесення нових нових даних в БД “Договір”. .Якщо клієнт, який обслуговується новий, то спочатку в пункті меню “Перегляд довідників” необхідно вибрати “Довідник клієнтів”, де в відповідні поля занести дані по кожному новому клієнту. При цьому необхідно враховувати маски вводу на полях ідентифікаційний код- 10 знаків. Коли клієнт вже є в довіднику, то відкривається форма “Договір ” в “Новий договір” і в БД вносяться всі дані по укладеному договору. При чому введення в поля: код клієнта, код виду вкладу,код валюти виконується при виборі відповідних записів з довідників. В поле сума вкладу можна заносити лише числовий вираз. Поля, в які заносяться дані про дати виконання операцій, мають спеціальний формат дати. Після занесення даних по договору клієнту відкривається депозитний рахунок та обслуговуючий (рахунок процентів). Поля рахунків мають маску вводу і розмір 14 знаків. Після занесення всіх даних необхідно натиснути клавішу ВИХІД і повернутися до головної форми меню.

При виборі пункту меню “Стан рахунків”, можна вибрати або “Поточні договори”, або “Перевані договори”. Якщо вибір “Поточні договори”, то видається форма звіту, яка відображає поточний стан рахунків по сплаті процентів на депозитні вклади. Якщо на поточний момент часу не існує укладених договорів, то форма буде не заповнена.

При виборі “Перевані договори”- висвічується форма, яка відображає всі договори, що були достроково перервані, а також суми та терміни переривання по ним. Після натиску клавіши ВИХІД відбувається повернення до форми головного меню.

При виборі “Формування звітів” висвічується перелік тих звітів, які можна отримати:

1) Нараховані % по депозитним вкладам

2) Аналіз залишків по видам вкладів в національній валюті

3) Аналіз залишків по видам вкладів в розрізі іноземних валют

4) Аналіз депозитів по видам вкладів в національній валюті

5) Аналіз депозитів по видам вкладів в розрізі іноземних валют

Кожний з цих звітів можна роздрукувати вибраши відповідну команду ДРУК.

При завершенні роботи в головному меню вибирається “Завершення роботи” і програмний комплекс завершить свою роботу.

5. Аварійні ситуації

Припинення автоматизованої обробки інформації відбувається, якщо:

1. Відсутні або порушенні структури вхідних масивів, а також при несвоєчасності отримання вхідного масиву- “Курс валют”, який необхідно щоденно поновлювати і надсилати до всіх відділів, в тому числі і до депозитного відділу. Для виправлення такої ситуації необхідно звернутися до системного адміністратора мережі або відділу програмного забезпечення.

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

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

4. Автоматизована обробка припиняється також у разі несправності обчислювальної техніки, відсутності електроенергії, несправності в мережі банківської системи. В цих випадках потрібно налагоджувати технічні засоби без втручання до внутрішньої структури програмного за безпечення.

Як рекомендація для користувачів є створення резервних копій файлу програми.

5. Рекомендації щодо засвоєння

Процес роботи з програмним комплексом показаний на конрольному прикладі в Додатку 4.


3.3. Технічне забезпечення

Для вирішення задачі автоматизації обліку депозитних операцій застосовують наступний комплекс технічного забезпечення:

Персональну ЕОМ (кількість ПЕОМ визначається кількістю економістів, працюючих в депозитному відділі):

* принтер стандартної конфігурації,

* маніпулятор типу миша,

* монітор не нижче VGA,

* мікропроцесор не нижче INTEL80386,

* ОЗУ-не нижче 2Мб, на вінчестері-20Мб.

* OS MS WINDOWS 95, СУБД ACCESS 2.0 і вище.

2.Всі ПЕОМ об”єднані у внутрішню мережу відділу.

3.Внутрішня мережа відділу має вихід до загальної внутрішньо-банківської мережі.

Такий комплекс технічних засобів пояснюється тим, що всі операції, які проходять в банку, відбуваються взаємопов”язано в єдиній сиситемі, яка обслуговує внутрішньо-банківську мережу. Системою, в якій працює банк і через яку зв”язані всі підрозділи є система “Операційного дня банку”.

Для депозитного відділу виділений сервер відділу, який зв”язаний з Сервером Операційного Управління, що має вихід до центрального серверу банку. Для серверу депозитного відділу доступна лише та інформація, що необхідна для процесу роботи відділу, а саме:

* Курс валют отримується лише на валюти, які приймають участь в депозитних операціях

* Масив проведених платежів містить лише операції, що проводяться на рахунках відкритих в відділі

* В довіднику клієнтів містяться дані про клієнтів- фізичних осіб.

Але зв”язок з сервером ОПЕРУ проходить в двох напрямках:

на прийом інформації,

та на подачу даних до серверу.

Відсилатися можуть такі дані:

* Масив рахунки- інформація про відкриті рахунки в відділі.

* Масив довідника клієнтів- інформація про нових клієнтів відділу, тобто і банку в цілому.

* В вигляді файлів можуть надсилатися електронні документи- звіти по роботі відділу. Право доступа до такої інформації надається лише відповідальним особам.

Схема функціонування внутрішньо-банківської мережі подана на рисунку 3.4.

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


Правління
банку
Центральний
сервер банку
Сервер Операцій- Сервер бухгалтерії Сервер відділу
ного Управління управління активами
та пасивами
Сервер відділу Сервер депозитного АРМ голов- АРМ
ОДБ відділу ного бухгалтера аналітика з питань
депозитної політики
АРМ опе- АРМ керів- банку
раціоніста ника депоз.відділу
АРМ опе-
раціоніста Арм еко- АРМ еко-
номіста номіста

Рисунок 3.4. Схема внутрішньо-банківської мережі ЕОМ


3.4. Програмне забезпечення

В даній випускній роботі програмна реалізація розробки виконана за допомогою СУБД ACCESS.

СУБД ACCESS підтримує реляційну модель БД і працює в середовищі WINDOWS. Це продукт, який входить до складу Microsoftoffise.

В ACCESS усі відомості, що стосуються певної предметної області, представляються у вигляді сукупності, пов”язаних між собою таблиць і на фізичному рівні зберігаються у вигляді одного файла, який має розширення .mdb. Крім таблиць у файлі зберігаються всі інструментальні засоби для роботи з таблицями: форми, запити, макроси, модулі, звіти.

СУБД ACCESS є діалоговою системою, яка працює з вікнами. В цій СУБД є довідкова система, за допомогою якої можна отримувати різну інформацію про поточну робочу ситуацію та довідки загального характеру про роботу з системою.

В ACCESS можна задавати не лише первинні, а і вторинні ключі таблиць, а також будувати схему даних шляхом встановлення реляційних зв”язків. Зв”язки між об”єктами моделі даних реалізуються через однакові реквізити- ключі зв”язку - в відповідних таблицях. При цьому ключом зв”язку завжди повинен бути ідентифікатор головного об”єкту в зв”язку.

Зв”язки між окремими реляційними таблицями будуть носити статичний характер, вони будуть постійними і ці зв”язки будуть забезпечувати підтримку цілістності та узгодженності БД. Можливе встановлення таких типів зв”язків як : 1:1 та 1:Б ( Б- багатьох ). За допомогою статичних зв”язків можна виконувати каскадне оновлення та каскадне вилучення даних з БД.

Процес проектування в СУБД ACCESS починається з розробки інфологічної моделі БД. Метою інфологічного проектування є створення структурованої інформаційної моделі предметної області, для якої буде розроблятися база даних. В даній випускній роботі інфологічне проектування виконується на основі синтезу атрибутів. В попередніх розділах даної випускної роботи вже були визначені ті об”єкти, які приймають участь в програмному забезпеченні, що розроблюється. Результатом такого інфологічного проектування є інфологічна модель БД, яка представлена на рисунку 3.5.

Довідник вкладів Договір Угода_договір
'Платежі Довідник валют
Довідник клієнтів
Курс валют
Довідник операцій
Рахунки

Рисунок 3.5. Інфологічна модель БД