Державний вищий навчальний заклад
«Українська академія банківської справиНаціонального банку України»
Кафедра економічної кібернетики
Контрольна робота
З дисципліни:
«Інформаційні системи і технології у фінансах»
Суми 2008
Зміст
1. Структура, апаратне забезпечення системи «клієнт-банк»
2. Автоматизація касових розрахунків в ПТК ОДБ
3. Підтвердження платежів СЕП
Список літератури
1. Структура, апаратне забезпечення системи «клієнт-банк»
Система «Клієнт-банк» складається з двох складових: банківського та клієнтського робочого місця.
На клієнтському робочому місці вводяться платіжні документи, формуються в пачки і записуються в базу даних АРМ клієнта в файл «Платіжних документів» (PD). Введеним та записаним в БД документам спочатку присвоюється статус, який дає змогу їх переглядати, переміщувати в інші пачки, друкувати, редагувати та вилучати. Для передачі платіжні документи підписуються електронним цифровим підписом (ЕЦП) головного бухгалтера. Головний бухгалтер також має змогу до того, як поставив свій підпис, редагувати дані файла PD. Перед тим, як підписати, бухгалтер позначає потрібні документи, вставляє дискету чи картку зі своїм індивідуальним ключем, який є закритим, і викликає відповідну функцію, яка ставить ЕЦП. Після успішного завершення функції підпису документа змінюється його статус, а також файл PD доповнюється певними символами, які ідентифікують підпис бухгалтера.
На другому етапі документи підписуються директором. З меню системи викликається відповідна функція, вставляється дискета чи картка з ключем директора і на екран видаються ті документи, які завірені підписом бухгалтера. Директор, переглядаючи платіжні документи, у разі необхідності має змогу вилучити деякі з них, а документи, готові до передачі, підписує. Після підпису директором файл доповнюється символами, які ідентифікують підпис директора. Далі файл шифрується і готується до передачі.
Підписані й зашифровані платіжні документи формуються в пакет і передаються з клієнтського робочого місця в банк засобами електронної пошти у вигляді текстового файлу типу R.
Документи, вилучені директором, автоматично змінюють свій статус. Ці документи можуть бути відредагованими і підписаними бухгалтером і повторно подані директору на підпис на наступних етапах функціонування системи.
Після здійснення сеансу зв’язку з банком банківська частина системи, що знаходиться в банку, має сформувати транспортні квитанції (файл типу T) на платіжні документи й надіслати їх клієнту. Якщо при прийомі документів було виявлено помилки, файл типу Т містить коди помилок та інформацію тих платіжних документів, у яких вони виявлені. Якщо при передачі чи заповненні платіжних документів були допущені помилки, то банк до обробки їх не приймає. Клієнт повинен виправити помилки й ще раз зв’язатися з банком для відправки виправлених платіжних документів.
Якщо файл типу R не має помилок, про що свідчать нульові коди помилок у файлі типу Т, то він приймається банком до обробки. Кожний прийнятий банком до обробки платіжний документ аналізується, і йому присвоюється відповідний статус, який свідчить про те, на якій стадії банківської обробки перебуває той чи інший документ. Статус документа присвоює відповідальний працівник банку, за яким закріплені особові рахунки даного клієнта.
Відповідальний працівник має можливість: оплатити документ; у разі відсутності достатніх коштів розмістити документ в картотеці; відхилити документ від оплати й передати його на розгляд кредитному інспектору, головному бухгалтеру чи керуючому і т.п. Кожне рішення, яке може прийматись по платіжному документу, має відповідне кодове позначення, що зберігається в довіднику статусів платіжних документів.
На прийняті до обробки платіжні документи формується й передається клієнту файл-квитанція типу С про рух та оплату документів в банку. Цей файл містить дані кожного платіжного документа та дані про його статус, якщо ж документ був оплачений, то відповідно – дані про вид акцепту, вид платежу. Разом з файлом типу С банк передає клієнту файли типу I та V, які є виписками з особових рахунків клієнта. Виписка I є поточною, а виписка V – підсумковою. У виписці I банк надає клієнту поточні дані щодо списання й зарахування коштів на особовий рахунок та залишок коштів на момент формування виписки. Крім того, поточна виписка включає всі документи, які були передані клієнтом в банк і надійшли на адресу клієнта. Поточна виписка має інформативний характер. Періодичність її формування оговорюється в договорі, який підписує клієнт з банком, і залежить від інформаційних потреб клієнта.
Підсумкова виписка дається щоденно по завершенні банківського дня і містить дані про обіг коштів за день та залишки коштів на рахунках на кінець дня.
При такій технології обміну платіжними документами в електронному вигляді банк потребує раз на тиждень подавати їх в паперовому вигляді, завіреними підписами директора і головного бухгалтера та печаткою підприємства. Разом з паперовими документами клієнт повинен подавати в банк у роздрукованому вигляді щоденні реєстри переданих в банк та оплачених банком платіжних документів за допомогою системи «Клієнт-банк». Також раз на тиждень касир повинен доставляти в банк другі примірники вже оплачених платіжних документів, на яких у його присутності ставляться штампи банку, й забирати проштамповані виписки з рахунків клієнта. Ці виписки мають правову силу, оскільки вони завірені печаткою банку, а виписки, що їх можна отримати за допомогою системи «Клієнт-банк», мають лише інформативний характер. Вони хоч і містять достовірну інформацію, але правової сили не мають.
Усі файли, що були сформовані чи прийняті системою «Клієнт-банк», архівуються і зберігаються в архіві.
Крім обміну платіжними документами, квитанціями та виписками, за допомогою системи «Клієнт-банк» клієнт може отримати файли внесення змін до бази даних нормативно-довідкової інформації, а також по запиту допоміжні файли довідково-інформативного характеру, що містять дані про курси валют, котировки цінних паперів на фондовій біржі тощо.
Інформаційну модель клієнтського робочого місця системи «Клієнт-банк» наведено на рис. 1.
Рис. 1. Інформаційна модель клієнтської частини системи «Клієнт-банк»
Вхідними повідомленнями для даного АРМ є платіжні документи, файли нормативно-довідкової інформації та файли, які надходять від банку електронною поштою.
До файлів нормативно-довідкової інформації належать:
довідник підприємств-кореспондентів (D_KOR), довідник клієнта (КLIENT), довідник банків (BANK), довідник призначень платежів (PLATIG), довідник видів платіжних документів (D_PD), довідник статусів (STATUS), довідник кодів помилок (POMILKA), довідник касових символів (KASA).
Довідник клієнта (КLIENT) містить такі поля: код клієнта, назву клієнта, код за ЄДРПОУ, МФО банку, № особового рахунку, відкритий ключ (адресу банку), відкритий ключ директора, відкритий ключ головного бухгалтера, реєстраційний номер в банку.
Довідник підприємств-кореспондентів (D_KOR) містить такі поля: код підприємства, назву підприємства, код за ЄДРПОУ, МФО банку, № особового рахунку.
Довідник банків (BANK) містить такі поля: МФО банку, назву банку, нижню межу особових рахунків, верхню межу особових рахунків.
Довідник видів платіжних документів (D_PD) включає такі поля: код виду платіжного документа (ПД), вид ПД, тип ПД, код платежу. В цьому довіднику наведено всі види платіжних документів, які можуть передаватись за допомогою системи, наприклад такі: платіжні доручення, меморіальний ордер, відмова від акцепта, реєстр чеків, касові документи та ін. Тип платіжного документа може бути дебетовим чи кредитовим, що відповідно відображається в полі «тип ПД».
Довідник призначень платежів (PLATIG) містить такі поля: код призначення платежу, зміст платежу.
Довідник статусів (STATUS) містить такі поля: код статусу платіжного документа, зміст статусу платіжного документа.
Довідник кодів помилок (POMILKA) містить такі поля: код помилки та зміст помилки. Всі помилки, які можуть виникнути при передачі повідомлень в системі, згруповані в п’ять груп. Перший рівень включає помилки, які виникли під час передачі та формування файлу: в архіві вже є вхідний файл з таким ім’ям, власник вхідного файлу невідомий, клієнт не підключений до системи «Клієнт-банк», недопустима дата в імені файлу. Другий рівень включає помилки, що мають місце в структурі файлу чи документа.
Третій рівень включає помилки, які виникли в результаті недопустимості значень поля документа. Наприклад, недопустиме значення МФО по дебету чи по кредиту, недопустиме значення коду платежу і т. п.
Четвертий рівень включає помилки недостовірності та невідповідності значень поля тим значенням, які містять поля довідників бази даних. Наприклад, невідомий номер особового рахунку, код ЄДРПОУ не відповідає його паспортному значенню в довіднику і т.п.
П’ятий рівень – це помилки дублювань значень документа в базі даних.
Довідник касових символів (KASA) містить коди видів касових операцій та їхні відповідні назви.
На основі платіжних документів формується файл PD, який містить такі поля: код виду платіжного документа (ПД), номер пачки, номер ПД, дата заповнення ПД, код платника, назва платника, МФО платника, назва банку платника, номер особового рахунку по дебету, сума платежу, код отримувача, назва отримувача, МФО отримувача; назва банку отримувача, номер особового рахунку по кредиту, призначення платежу. Файл PD зберігається в базі даних системи, а після підпису бухгалтером та директором трансформується у файл типу R та передається в банк.
Файли, що передаються каналами зв’язку, формуються як текстові файли. Основним файлом, що його надсилає клієнт в банк, є файл платіжних документів, який позначається як файл типу R. Структура цього файла така: код виду платіжного документа (ПД); номер ПД; дата заповнення ПД; МФО по дебету; МФО по кредиту; номер особового рахунку по дебету; номер особового рахунку по кредиту; сума платежу; назва отримувача; призначення платежу; дата надання послуги або попередня оплата; код виду акцепту; код платежу; код ЄДРПОУ отримувача.
Після отримання файлу типу R банк надсилає клієнту транспортну квитанцію, яка ідентифікується як файл типу Т. Крім транспортних квитанцій, які сигналізують клієнта про отримання банком платіжних документів, є ще квитанція типу К про оплату документів банком. Структура цього файла-квитанції така: код виду платіжного документа; номер документа; дата документа; сума по документу; код помилки; дата оплати; вид квитанції; статус квитанції. В полі статусу квитанції проставляється статус платіжного документа, який був наданий йому в банку, наприклад, документ відхилено від оплати керівництвом банку.
Дані про рух та оплату документів, що надійшли в банк від клієнта, містить файл типу С. Його структура така: код помилки; код виду платіжного документа (ПД); номер ПД; дата виписки ПД; МФО по дебету; МФО по кредиту; номер особового рахунку по дебету; номер особового рахунку по кредиту; сума платежу; назва отримувача; призначення платежу; дата надання послуги або попередня оплата; код виду акцепту; код платежу; код ЄДРПОУ отримувача; ознака передачі; статус документа в базі даних; дата виписки квитанції.
Крім бази даних оперативної та нормативно-довідкової інформації, ведеться архівна база даних ARHIW, в якій зберігаються пачки оплачених документів та підсумкові виписки з особових рахунків.
Забезпечення безпеки передачі даних в системі «Клієнт-банк» здійснюється таким чином. Система «Клієнт-банк» повинна бути надійно захищена від несанкціонованого доступу та різного роду можливих зловживань. Вона повинна використовувати різні механізми захисту інформації як всередині офісу чи банку, так і зовні при проходженні файлів платежів каналами зв’язку. Для захисту використовуються системи аутентифікації та криптографічного захисту. Система повинна мати індивідуальні носії ключової інформації та робоче місце генерації ключів.
Перш за все система повинна передбачати організаційні засоби захисту, які полягають в обмеженні кількості користувачів системи та розмежуванні їх прав доступу. Система повинна мати також пароль, який присвоюється їй під час купівлі, а кожний користувач – індивідуальний код доступу. Посадові особи, які мають індивідуальні носії ключової інформації, повинні бути зареєстрованими в банку. Як правило, цими особами є директор та головний бухгалтер.
Користувачі, які мають право працювати з системою, поділяються на три групи, кожна з яких має різні права.
Перша група користувачів має лише право вводити, коригувати і друкувати документи, формувати звіти, архівувати дані та читати їх з архіву.
Бухгалтер має права першої групи, а також право другого підпису на документах, які він підписує своїм індивідуальним ключем, але не має права відправляти й приймати платіжні банківські документи.
Директор – користувач з максимальними правами доступу, який має всі права двох перших груп, а також право першого підпису на документах своїм індивідуальним ключем. Крім того, він має право знімати з документів підпис бухгалтера, відправляти й приймати платіжні банківські документи.
Кожний користувач має індивідуальний код доступу, який розпізнається на вході в систему і визначає його права доступу.
Кожний документ у файлі платіжних документів, що готується до передачі, підписується електронним цифровим підписом (ЕЦП), тобто доповнюється певною комбінацією символів, що ідентифікують відповідальну особу, яка поставила цей підпис. ЕЦП заснований, як правило, на відкритих та закритих ключах, які можуть з певною періодичністю змінюватись.
Крім того, всі повідомлення, що їх передають системою, підлягають криптографуванню. Тобто повідомлення одного абонента іншому перед відправкою шифрується та дешифрується під час прийняття його тим абонентом, якому воно було адресоване.
Право встановлювати й змінювати права доступу до системи має лише її адміністратор. Вся робота користувачів з системою протоколюється й записується у відповідні журнали.
2. Автоматизація касових розрахунків в ПТК ОДБ
Автоматизована обробка касових документів з огляду на їхню специфіку у відповідний модуль програмно-технологічного комплексу ОДБ. В основу технології автоматизованого опрацювання касових операцій покладено такий принцип – відповідальний виконавець з контролю за рухом коштів на особовому рахунку клієнта під час вводу касових документів перевіряє наявність особового рахунка, виявляє ознаки заблокованості чи закриття рахунка, наявності на ньому коштів. У момент прийому чи видачі готівки касир на своєму робочому місці виконує операцію «Оплата», заносячи відповідний запис до робочого файлу, де фіксуються зміни залишків коштів на рахунках. Скоригувати чи вилучити документ можна лише до моменту виконання операції «Оплата». У разі відповідного налагодження системи зазначена операція може виконуватися також із інтерфейсу технолога. Модуль «Каса» функціонує за такими режимами: прибуткова каса, видаткова каса, вихідні форми, регламентні роботи, об’єкти інкасації.
Зауважимо, що в меню «режими» спочатку вказуються процедури, які виконуються найчастіше, а далі наводяться ті процедури, до яких протягом дня звертаються лише один чи декілька разів.
Для виконання режимів автоматизованого обліку операцій з готівкою слугують: АРМ касира, АРМ відповідального виконавця, АРМ бухгалтера, АРМ адміністратора БД. Залежно від повноважень користувача й згідно з паролями доступу до заданого АРМ включаються різні пункти меню. Але при цьому насамперед виконуються регламентні роботи. До них належать:
роботи, виконувані в разі інсталяції модуля та в аварійних ситуаціях (ініціалізація файлів БД з касовими документами, ініціалізація журналу регламентних робіт, зміна стану модуля, зберігання документів поточного дня);
роботи, виконувані протягом поточного операційного дня (відкриття дня за касою, поповнення документів поточного дня, закриття дня за касою з архівацією касових документів, огляд журналу регламентних робіт);
регламентні роботи з архівними касовими документами (наприклад, перегляд касових документів з архіву).
Ініціалізація касових файлів – це та операція, за допомогою якої адміністратор БД очищає всі касові документи в разі інсталяції модуля «Каса» або під час аварійних ситуацій. У машинному журналі регламентних робіт ведеться протокол усіх дій, виконаних у цьому режимі із зазначенням дати, часу здійснення операції і табельного номера особи, котра виконала цю операцію. Журнал регламентних робіт можна переглядати і при потребі ініціалізувати.
До регламентних робіт, які виконуються щодня, належать відкриття і закриття дня каси. Ці режими запускаються з робочих місць відповідального виконавця та адміністратора БД. При цьому послідовно виконуються перевірки, аби встановити, чи не ведуться регламентні роботи, чи відкритий операційний день банку. Окрім того, під час відкриття каси перевіряється дата відкриття, яка не повинна повторюватися, а під час закриття виконуються додаткові перевірки й процедури обробки інформації. З’ясовується зокрема, чи коректні файли касових документів (усі документи мають бути оплачені, зареєстровані в касових журналах, їх символи мають відповідати шаблонам за структурою), чи коректно відкрита каса, чи наявні касові документи. Якщо документів немає, то каса закривається, але архів не створюється. Закриття каси передбачає, що в журналі регламентних робіт фіксується, коли й хто закривав касу, та наводяться контрольні суми, а спеціальна програма записує в архівну БД поточні файли (ці процедури виконуються автоматично). Зрештою на екран виводиться повідомлення про результати виконання програми із закриття каси.
Режими регламентних робіт дають змогу прочитати касовий документ із архіву за будь-який день роботи каси, але тільки після закриття дня за касою.
Робота відповідального
Робота касира з касовими документами виконується в режимах «Прибуткова каса» або «Видаткова каса» за допомогою процедури «Оплата документів». Касиру пропонується екран зі списком ще не сплачених касових документів поточного дня, введених всіма відповідальними виконавцями на поточний момент часу. Обслуговуючи клієнта, касир вибирає рядок, тобто необхідний документ, і натисканням відповідного клавіша запускає програму оплати документа чи відмови від оплати. Підпрограма оплати документа виконує бухгалтерські проводки згідно з кодами рахунків і видами операцій з готівкою, а також фіксує ці зміни у відповідних машинних регістрах (бази даних) аналітичного обліку банківських операцій. У разі відмови касира оплатити документ в полі «Бухгалтерська проводка» в журналі відповідального виконавця з’явиться відповідна помітка, а в полі «Касир» – табельний номер касира. Виконавши процедуру «Оплата документа», касир видає клієнтові готівку, якщо операція видаткова, або квитанцію, якщо операція прибуткова. Касир повторює процедури оплати документів доти, доки на екрані не з’явиться повідомлення: «Немає документів для оплати». При цьому через деякий проміжок часу процедуру вибору документів пропонується повторити.
У режимі виконання операцій грошових переказів, тобто оформлення прийому готівкових коштів від клієнтів, рахунки яких відкриті в інших банках, відповідальний виконавець заводить або вибирає з існуючих касовий журнал грошових переказів. Документи за операціями грошових переказів вводяться так само, як і прибуткові та видаткові документи. Після правильного вводу документів натисканням відповідного клавіша запускаються програми, згідно з якими документ записується до касового журналу без проводки або з виконанням бухгалтерських проводок. Можливий і такий варіант, коли виконується бухгалтерська проводка і друкуються рядки журналу на принтері. У режимі грошових переказів формується меморіальний ордер, виконується проводка транзитного переказування коштів до інших банків і нараховуються суми сплати за банківські послуги.
Банки організовують іноді виносні каси, функції яких також автоматизуються. Робота виносних кас автоматизується таким чином.
1. Програмно-апаратний модуль забезпечує автоматизацію обліку готівкових коштів на робочому місці касира.
2. По каналу зв’язку системи «Клієнт-Банк» передаються меморіальні ордери проводок виносної каси.
3. Відповідальний виконавець приймає ці меморіальні ордери й здійснює операцію «Оплата».
4. Адміністратор БД кілька разів протягом дня та перед закриттям виконує регламентні роботи, створюючи та доповнюючи при цьому касові журнали роботи виносних кас. Такі журнали виносних кас включають в архів касових документів, а надалі використовують під час формування касових звітів.
У режим «Вихідні форми» включаються процедури зі складання, перегляду та друкування щоденних оперативних форм звітності. Технологія виконання цих процедур передбачає введення дати, на яку формуватимуться звітні форми, а також утворення робочого файлу. Користувачеві пропонується для вибору список таких вихідних форм: прибутковий касовий журнал, видатковий касовий журнал, довідка касира з прибутків, довідка касира з видатків, зведена довідка про касові обороти, довідка щодо видів касових операцій, довідка щодо БД каси, перелік неоплачених і сторнованих документів. Окрім того, інформаційна система формує звітні файли стосовно прогнозу готівкового обігу та касових оборотів. Прогноз готівкового обігу розробляється на підставі файлів, які формуються згідно з касовими заявками, прогнозними розрахунками, що надходять від підприємств і установ, а також архівними даними за попередні періоди. Результати обробки інформації видаються як прогнозні розрахунки касових оборотів (форма 720-н), календар видачі готівки на заробітну платню (форма 729-н) і т.ін. Звіти про касові обороти складаються на підставі файлів оперативної інформації БД ОДБ. Результати обробки інформації формуються у звітні файли: №12 – дані про касові обороти символів форма 747Д, №13 – дані про касові обороти символів форми 778. Ці звітні файли передаються комерційним банком до регіонального управління НБУ.
3. Підтвердження платежів СЕП
Платіжні документи готуються в АІС комерційного банку. Оскільки для передачі платіжних документів використовується ЕП НБУ, то одиницею обміну даними між елементами СЕП є не окремий платіжний документ, а пакет (конверт) платіжних документів у вигляді файлу певного типу. Залежно від результатів перевірки пакета він може або не може бути прийнятий «у цілому» (без вилучення в ньому коректних документів).
Підготовлені в БАІС у вигляді файлу типу А документи з початкових міжбанківських розрахунків надходять до АРМ-3, де їх перевіряють на відповідність вимогам, що їх передбачено СЕП. Забраковані на рівні АРМ-3 документи не потрапляють до СЕП. У такому разі АРМ-3 формує для ОДБ БАІС файл помилок типу «О», в якому зазначаються номери забракованих документів файлу А та коди виявлених у них помилок.
Якщо результат перевірки, здійснюваної на АРМ-3, позитивний, пакет платіжних документів (файл типу А) із цього робочого місця надходить до АРМ-2 РРП, що обслуговує даний банк.
На АРМ-2 РРП пакет також перевіряється на відповідність прийнятим у СЕП вимогам. Якщо пакет приймається, то платіжні документи з нього просуваються по СЕП далі. У противному разі пакет не приймається загалом без виокремлення в ньому коректних документів. При цьому у файлі-квитанції типу Т про отримання файлу типу А, вказуються номери забракованих у ньому документів та кодів наявних у них помилок.
Забраковані на рівні АРМ-2 файли не обробляються і не повертаються до АРМ-3, а зберігаються у відповідних базах даних АРМ-2 і можуть бути використані як довідковий матеріал.
Якщо АРМ-2 забракував файл, припустимою є спроба повторно надіслати на нього файл з таким самим іменем і тим самим змістом. Після того як файл прийнято на АРМ-2, наступні примірники файлу з тим самим іменем на цьому робочому місці не розглядатимуться. Квитанція про повторну обробку зазначених файлів також не формується. Відповідальність за розміщення в одному пакеті коректних і некоректних платіжних документів покладається на комерційні банки.
АРМ-2, прийнявши пакети платіжних документів, «розкриває» ці пакети і, перш ніж передати їх далі, групує отримані документи за таким правилом.
Якщо банк-отримувач платіжного документа обслуговується тим самим АРМ-2, то формується пакет (у вигляді файлу типу В) безпосередньо для цього банку.
Якщо ж банк-отримувач платіжного документа обслуговується іншим АРМ-2 тієї самої палати, то формується пакет (у вигляді файлу типу С), який містить усі платіжні документи від банків даного АРМ-2 для банків АРМ-2 отримувача. Сформований такий пакет надсилається до АРМ-2 РРП.
Якщо ж банк-отримувач обслуговується іншою РРП, то даний платіжний документ включається до пакета (також файл типу С), який містить усі платіжні документи від банків даної РРП для банків РРП-отримувача. Сформований такий пакет відправляється відповідному АРМ-2 відповідної РРП.
АРМ-2 у РРП-отримувачі приймає пакет платіжних документів від АРМ-2 РРП-відправників поряд із пакетами платіжних документів від своїх комерційних банків, розкриває прийняті пакети і відповідно перегруповує вміщені в них документи. Зрештою платіжний документ потрапляє до пакета (файл типу В) для банку-отримувача і відправляється йому в разі його виходу на зв’язок з РРП.
Отже, на рівні РРП отримують «конверти» з платіжними документами, розкривають їх і працюють безпосередньо з документами: формують із них нові пакети, не змінюючи суті та змісту самих документів.
Для однозначного визначення «долі» кожного пакета платіжних документів використовується механізм файлів-квитанцій ЕП НБУ про підтвердження отримання пакета. При цьому кожний АРМ СЕП, який отримав пакет ПД, обов’язково формує файл-квитанцію на нього, в якій зазначається, приймає він цей пакет чи ні (в останньому разі наводяться причини відмови). Файл-квитанція надсилається АРМ-відправникові пакета платіжних документів. Лише після отримання квитанції про прийняття документів абонент-відправник (КБ або РРП) виконує відповідні розрахункові операції, пов’язані з платіжними документами пакета.
На підставі аналізу файлів-квитанцій і пакетів завжди можна встановити факт і час проходження (непроходження) за маршрутом вузлів СЕП кожного відправленого із КБ платіжного документа. На цій базі в СЕП працює система з надання довідок про проходження документів.
Відображення сум платежів при міжбанківських розрахунках на відповідних особових і балансових рахунках забезпечує можливість проведення бухгалтерського обліку і контролю правильності проходження платежів на рівні як КБ, так і РУ НБУ.
Бухгалтерський облік і контроль виконання платежів на рівні КБ здійснюють, як правило, також і ПТК ОДБ.
У СЕП існує й система бухгалтерського обліку, яка забезпечує облік і контроль проходження грошових коштів по міжбанківських розрахунках, в розрізі таких основних операцій.
{І} – списання коштів із кореспондентського рахунка КБ (сума файлу типу A).
{ІІ} – зарахування коштів на транзитний рахунок КБ (сума файлу типу B).
{ІІІ} – зарахування коштів на кореспондентський рахунок КБ після підтвердження їх отримання (сума файлу типу S).
{ІV} – переміщення коштів між різними АРМ-2 одного регіону, тобто зарахування коштів на транзитний рахунок АРМ-2-одержувача (сума файлу типу C).
{V} – переміщення коштів між різними АРМ-2 одного регіону, тобто зарахування коштів на внутрішній рахунок АРМ-2-одержувача після підтвердження їх отримання (сума файла-квитанції підтвердження типу R про отримання файлу С).
{VІ} – переміщення коштів за межі регіону: зарахування коштів на транзитний регіональний рахунок (сума файлу типу C).
{VІІ} – переміщення коштів за межі регіону: зарахування коштів на рахунок регіону в Головній установі НБУ (сума файлу типу R).
{VІІІ} – перерахування коштів між регіонами, виконуване в Головній установі НБУ (сума файлу типу R).
{ІX} – зарахування на внутрішній рахунок АРМ-2 – одержувача коштів, що надійшли з іншого регіону (сума файлу типу R).
{X} – списання коштів із рахунка установи НБУ (сума файлу типу A).
{XІ} – зарахування коштів на транзитний рахунок установи Національного банку України (сума файлу типу B).
{XІІ} – зарахування коштів на рахунок установи Національного банку України після підтвердження (сума файлу типу S).
У разі, якщо платіжний документ був прийнятий у СЕП, але не доведений до одержувача того самого банківського дня, він залишається в одній із РРП, через які проходить, і відправляється одержувачу наступного банківського дня. Суми коштів, які залишилися в РРП, відображаються на відповідних транзитних і технічних рахунках стосовно одержувачів коштів. Отже, із закінченням роботи всієї системи на підставі даних РРП про кошти на зазначених рахунках можна визначити загальний розмір платежів, які залишилися на «ночівлю» у СЕП, хто є їх одержувачами і т. д. Можна також, урахувавши обороти коштів за день, визначати переміщення грошової маси між регіонами тощо.
У забезпеченні нормальної роботи такої складної системи, як СЕП дуже важливими є регламентація етапів технології та узгодження роботи всіх її елементів у часі.
ЦРП працює протягом усіх робочих днів. Упродовж робочого дня ЦРП працює у звичайному режимі з передачі та контролю даних. Основне програмне забезпечення ЦРП – комплекс АРМ-1 працює в автоматичному режимі. Наприкінці робочого дня виконуються зведені баланси міжрегіональних платежів. За умови їх успішного завершення із ЦРП до РРП надсилається дозвіл на виконання технологічного етапу – «Кінець робочого дня».
Коли від усіх РРП отримано сигнал про закінчення робіт, у ЦРП виконуються заключні роботи з формування та передачі до Центрального управління НБУ звітних форм, а також системні процедури, пов’язані із закінченням поточного робочого дня і підготовкою до початку наступного, включаючи архівацію даних тощо.
У РРП до початку робочого дня також виконуються підготовчі системні роботи. До цього часу ОДБ відповідного РУ НБУ передає кожному АРМ-2 інформацію про стан кореспондентських рахунків банків, які ним обслуговуються. Протягом робочого дня в РРП обробляються платіжні дані за загальною технологією. Кожний АРМ-2 РРП працює в циклічному режимі. Інтервал циклу (повної обробки даних) становить від 15 до 30 хв. залежно від кількості прийнятих пакетів і документів у них. Після кожного циклу створюються дублі (копії) баз даних АРМ-2 за станом на кінець технологічного сеансу.
Наприкінці робочого дня за погодженням із ЦРП у РРП виконується етап технології під назвою «Закінчення початкових міжрегіональних оборотів РРП». На цьому етапі вона ще приймає дані від КБ, але акумулює їх і не передає до інших РРП. Отримані суми платежів відкладаються на відповідних рахунках РРП-отримувача. Інформація про виконання цього етапу передається до ЦРП.
Технологічний етап роботи «Кінець робочого дня» для РРП настає після сигналу ЦРП. Цей етап може виконуватися, якщо отримано дозвіл від ЦРП на його виконання і немає відправлених, але не підтверджених РРП-отримувачем міжрегіональних платежів. На цьому етапі в РРП припиняється робота з приймання платіжних документів і виконуються заключні роботи з формування банкам виписок із їх ТКР, передача оборотів по ТКР за день до ОДБ РУ НБУ, передача звітних форм, технічної інформації до ЦРП і т.ін. Виконуються також системні роботи, пов’язані із закінченням робочого дня та підготовкою до початку наступного, включаючи архівацію даних тощо.
Регламент роботи КБ передбачає також виконання етапу «Початок робочого дня», який полягає у встановленні зв’язку його АРМ-3 з відповідним АРМ-2 РРП. Під час першого сеансу зв’язку АРМ-3 отримує від АРМ-2 файл стану кореспондентського рахунка в РУ НБУ, файл коригувань списку учасників СЕП і т.ін.
Початкові платежі з КБ до СЕП дозволяється передавати до початку в РРП технологічного етапу «Кінець робочого дня». До цього моменту протягом дня банк сам визначає і проводить сеанси зв’язку з РРП, а також обробляє здобуті дані.
Етап технології «Кінець робочого дня» здійснюється в КБ за умови, що на всі відправлені файли платіжних документів (файли типу А) отримано від РРП файли-квитанції (типу Т), а також сформовано й відправлено до РРП файли-квитанції (типу S) на всі отримані банком від РРП зворотні платежі (файли типу В).
Ознакою закінчення банком роботи на поточний день є передача ним до РРП файлу «Протокольний звіт» (файл типу Z). Якщо цей файл не може бути переданий до РРП через порушення зв’язку, то інформація про закінчення обміну банку з РРП має бути передана в той самий день телефоном.
По закінченні робочого дня в КБ архівують та звіряють дані, видають на друкування реєстри платіжних документів для кожного клієнта і т.ін.
Графік взаємодії РРП із КБ може коригуватися, але повідомлення про це доводиться до банку не менш як за три доби до моменту, коли зміни стануть чинними.
Список літератур
и
1. Ананьєв, О.М. Інформаційні системи і технології в комерційній діяльності [Текст]: підручник / О.М. Ананьєв, В.М. Білик, Я.А. Гончарук. – Львів: Новий Світ-2000, 2006. – 584 с.
2. Антонов, В.М. Фінансовий менеджмент: сучасні інформаційні технології [Текст]: навчальний посібник / В.М. Антонов, Г.К. Яловий; ред. В.М. Антонов; Мін-во освіти і науки України, КНУ ім. Т.Г. Шевченка. – К.: ЦНЛ, 2005. – 432 с.
3. Гужва, В.М. Інформаційні системи і технології на підприємствах [Текст]: навчальний посібник / В.М. Гужва; Мін-во освіти і науки України, КНЕУ. – К.: КНЕУ, 2001. – 400 с.
4. Гуржій, А.М. Інформатика та інформаційні технології [Текст]: підручник / А.М. Гуржій, Н.І. Поворознюк, В.В. Самсонов. – Х.: Компанія СМІТ, 2003. – 352 с.
5. Информационные системы и технологии: приложения в экономике и управлении: Кн. 6 [Текст]: учебное пособие / Мин-во образования и науки Украины, Донецкий нац. ун-т; ред. Ю.Г. Лысенко. – Донецк: Юго-Восток, 2004. – 377 с.
6. Колесник А.П. Компьютерные системы в управлении финансами. – М.: Финансы и статистика, 2004. – 312 с.
7. Маслов, В.П. Інформаційні системи і технології в економіці [Текст]: навчальний посібник / В.П. Маслов; Мін-во освіти і науки України. – К.: Слово, 2003. – 264 с.
8. Олійник, А.В. Інформаційні системи і технології у фінансових установах [Текст]: навчальний посібник / А.В. Олійник, В.М. Шацька. – Львів: Новий Світ-2000, 2006. – 436 с.
9. Рогач І.Ф., Сендзюк М.А., Антонюк В.А. Інформаційні системи в фінансово-кредитних установах. – К.: КНЕУ, 1999. – 216 с.
10. Рудакова О.С. Банковские электронные услуги: Учебн. пособие для вузов. – М.: Банки и биржи, ЮНИТИ, 1997. – 261 с.
11. Румянцев, М.И. Информационные системы и технологии финансово-кредитных учреждений [Текст]: учебное пособие для вузов / М.И. Румянцев; Западнодонбасский ин-т экономики и управления. – Днепропетровск: ИМА-пресс, 2006. – 482 с. –
12. Черняк, О.І. Системи обробки економічної інформації [Текст]: підручник / О.І. Черняк, А.В. Ставицький, Г.О. Чорноус. – К.: Знання, 2006. – 447 с.