Організація електронного документообігу на прикладі операцій з депозитними та поточними рахунками фізичних осіб АТ "ОТП Банк" в автоматизованій системі "Retail"

Размещено на http://www.allbest.ru/

УДК 336.717:004.

Організація електронного документообігу на прикладі операцій з депозитними та поточними рахунками фізичних осіб АТ "ОТП Банк" в автоматизованій системі "Retail"

О.В. Красоткін

Здійснено аналіз організації електронного документообігу за рахунками АТ «ОТПБанк» фізичних осіб на прикладі автоматизованої банківської системи «Retail», висвітлено процеси роботи з інтерфейсом системи. електронний длкументообіг депозитний рахунок

Ключові слова: автоматизована система електронного документообігу, АРМ оператор, депозитні рахунки, електронний документ, електронний документообіг, інтерфейс, інформаційні технології, контрагент, програмне забезпечення, поточні рахунки, фізичні особи.

Implemented analysis of electronic records management on accounts SC «OTP Bank» physical clients on example of automated banking system «Retail», highlights process of working with the interface of the system.

Keywords: automatized system of electronic records management, APM operator, deposit accounts, electronic document, electronic records management, interface, information technologies (IT), rear agent, software, current Accounts, physical clients.

Публічне акціонерне товариство «ОТП Банк» один із найбільших провідних вітчизняних банків, визнаний лідер фінансового сектора України. На українському ринку він представлений з 1998 р., має стійку репутацію соціально відповідальної, надійної та стабільної структури, що пропонує споживачам сервіси європейської якості.

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

Метою статі є аналіз та висвітлення процесів керування електронним документообігом в АТ «ОТП Банк» на прикладі заведення депозитних і поточних рахунків в автоматизованій системі «RETAIL».

Об'єктом статті є електронний документообіг за рахунками АТ «ОТП Банк».

Предметом статті є сучасні принципи організації керування електронною документацією в автоматизованій системі «RETAIL» АТ «ОТП Банк».

У даний час відкриття поточних і депозитних рахунків фізичних осіб в АТ «ОТП Банк» пов'язане з використанням двох систем: MIDAS і САБ (система автоматизації банку), що включає програму NBUreports, базу даних за клієнтами і відкритими рахунками, і дозволяє здійснювати бухгалтерські проводки в системі «Cash».

Відкриття депозитних і поточних рахунків фізичних осіб здійснюється за такою схемою:

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

* пакет перерахованих вище документів передається на перевірку та візування контролеру. Після контролю правильності заповнення документів та їхньої відповідності вимогам нормативів, дані за клієнтом вносяться в систему Midas для відкриття поточного та депозитного рахунків;

* дані з системи Midas автоматично завантажуються в систему САБ з періодичністю 10 хв;

* після підвантаження даних контролер вносить українські реквізити клієнта і параметри контрагента для формування звітності в систему САБ за допомогою програми NBUreports;

* після виконання операцій, згідно п.14, у ручному режимі формується проводка в системі «Cash», друкуються касові ордери, на підставі яких здійснюються касові операції;

* клієнту видається касовий ордер, який підтверджує касову операцію і договорів.

Програма «Retail» передбачає такі робочі місця: АРМ оператора; АРМ адміністратора документів; АРМ контролера [1, ст. 25].

До функцій АРМ оператора відносяться: пошук існуючого в САБ контрагента, перегляд і редагування його реквізитів; відкриття нового контрагента, введення його реквізитів, присвоєння їй унікального номера; друк документів контрагента; перегляд списку рахунків контрагента. Відкриття нових і редагування реквізитів існуючих рахунків; друк документів за рахунком (заяви, договору тощо); введення касової операції за рахунком. При цьому в операцію автоматично підставляється № рахунку, ПІБ контрагента і його паспортні дані. Інші реквізити автоматично беруться з обраного шаблону касової операції. Друк касових документів та подальша обробка операції виробляється програмою «Cash» і відповідно до її процедур; введення регулярних платежів (Standing Order) і передача їх на авторизацію контролеру; друк документів за введеними SO (дод. угоду, форма SO і т ін.)

До функцій АРМ адміністратора документів відносяться: програма «Retail» проектувалася так, щоб мінімізувати її виправлення при зміні форм вихідних документів. Досить часто відбувається зміна списку вихідних документів та їхніх форм. У кожного відділення банку можуть бути свої вимоги до списку документів та їхнього змісту (адреса банківської установи, її атрибути, ПТБ керівника і т ін.). Для забезпечення такої гнучкості був обраний такий метод: форми документів винесені з програми і зберігаються на сервері бази даних у вигляді спеціально оформлених документів MS Word із вбудованими полями, що забезпечують передачу інформації з програми Retail в Word. Тепер будьяка зміна форми документа або навіть додавання нового документа не потребують зміни програми.

Крім того, філії та відділення Банку можуть самі редагувати набір необхідних їм документів. Для цього в програмі реалізований «АРМ адміністратор документів», який дозволяє: редагування списку документів, доступних для друку з форми клієнта або рахунки вказаної філії; редагування самих шаблонів документів з вищевказаного списку в MS Word; вставити готовий файл шаблону документа в базу даних [1, ст. 43].

До функцій АРМ контролера відносять: АРМ контролер призначений для перегляду введеної оператором інформації за регулярними платежами клієнтів і прийняття рішення про авторизацію чи скасування його дій. Calk Key Сервісний пункт програми дозволяє розрахувати контрольний розряд номера рахунку у форматі НБУ

Форма АРМ Контролера

У полі [Brca] вводиться код бранча, до якого належить документ, у [Form Name] вибирається Account, Customer або Standig Order документ відноситься до рахунку, контрагенту або регулярних платежів клієнта. У полі [Doc Name] вводиться ім'я документа, під яким він буде з'являтися в списку доступних для друку документів. По правій клавіші мишки викликається спливаюче (PopUp) меню, пункти якого дозволяють: перечитати список документів з БД; записати зміни в БД; вставити новий запис; видалити поточний запис.

Оскільки всім пунктам цього меню призначені «гарячі клавіші», можна користуватися ними, не викликаючи самого меню. По клавіші Edit Doc запускається MS Word, в який завантажується з сервера бази даних шаблон документа для редагування. По клавіші Insert File користувач може вибрати готовий файл шаблону документа і записати його в базу даних [1, ст. 51].

Форма «Документи клієнта» призначена для друку документів контрагента (напр., карта контрагента). Насправді програма не друкує документ, а створює його з шаблону, зробленого адміністратором документів, у форматі MS Word, запускає MS Word, де користувач може переглянути згенерований документ, при необхідності відредагувати і роздрукувати. Форма «Рахунки клієнта» у цій формі можливо переглянути список рахунків клієнта. Натисканням кнопки «Make Cash» викликається вікно для введення касової операції за участю обраного рахунку. При цьому всі реквізити операції підставляються з обраного шаблону операції, плюс із програми «Retail» підставляються реквізити обраного рахунку (його номер) і контрагента (ШБ, паспорт, адресу і т. ін.). Оператору залишається тільки ввести суму операції та при необхідності відредагувати призначення операції. Друк касових документів та подальша обробка (авторизація та виконання) касової операції відбувається в системі «Cash» відповідно до її процедур.

Крім експорту операцій, у «Cash», за існуючими рахунками, програма дозволяє відредагувати, додати або видалити рахунок за обраним клієнтом. Видалення можливо тільки тих рахунків, які є нововведеними (не заведений у MIDAS) і за видаленим рахунком ще не робили проводок.

Размещено на http://www.allbest.ru/

Форма «Документи рахунки»: ця форма аналогічна формі «Документи клієнта», тільки друкуються (генеруються в MS Word) документи, що стосуються рахунків (карта рахунку, картка зразків підписів, договору, заяви на відкриття і т. ін.). Крім того, у спливаючому меню цієї форми є ще один пункт: «Print Fields». Цей пункт призначений для адміністратора документів. За цією командою генерується документ MS Word, в якому будуть усі заповнені на прикладі поточного контрагента та поточного рахунку поля, які можуть бути використані в шаблонах документів за контрагентом та рахунком [1, ст. 67].

Модуль «Standing Order» (далі SO) призначений для введення та виконання регулярних платежів клієнта. Всі SO за цільовими підсистемами діляться на три види: Payments платежі, згенеровані на підставі SO, експортуються в систему Payments і виконуються там відповідно до її процедур; Card платежі, згенеровані на підставі SO, експортуються в систему Card або Card Paym і виконуються там відповідно до її процедур; SWIFT використовується тільки для генерації документів. При експорті такого платежу жодні проводки не генеруються. Проводки та вихідні SWIFTповідомлення генеруються засобами MIDAS.

Для того, щоб почали виконуватися платежі за SO, потрібно пройти такі етапи:

* первинне введення SO оператором, роздруківка документів (дод. угода);

* передача введеного SO на авторизацію контролеру;

* контролер може або авторизувати введений SO, або повернути його на етап введення.

У цій закладці оператор може переглянути список усіх SO вибраного клієнта. При цьому статус SO показаний в останній колонці, і для зручності перегляду рядка з різними статусами, виділені різними кольорами.

У закладці «Форма SO» оператором проводиться перегляд докладної інформації за обраним SO, а також введення нових або редагування існуючих SO. Залежно від обраного типу SO (Payments, Card або SWIFT), оператору, для введення, будуть доступні різні поля. Наприклад, поле номера платіжної картки доступно тільки для SO з перерахування на картковий рахунок, а реквізити свіфтовому платежу тільки для SO типу SWIFT.

У закладці «Графік платежів» можна переглянути всі платежі (виконані і ті, що чекають на виконання) за SO вибраного клієнта. Платежі згруповані за рахунками клієнта. При необхідності цей список можна експортувати в зовнішній файл «Save As» по правій клавіші миші або «роздрукувати». Закладка «Документи» призначена для друку документів, необхідних для оформлення регулярних платежів і аналогічна закладка для друку документів за клієнтом і рахунками.

У першій закладці «Список SO» контролеру показується, що очікують від контролера прийняття рішення про підтвердження або скасування дій оператора (введення SO, скасування SO). Тут же видно SO, оброблені контролером сьогодні. При бажанні цей список можна відфільтрувати за статусом SO за допомогою показаного нижче списку [1, ст. 76].

За зовнішнім виглядом усі закладки АРМ контролера ідентичні АРМ оператора. Тільки в контролера немає печаті документів (він їх отримує від оператора вже на папері), немає можливості редагувати інформацію (тільки дивитися). І якщо в оператора показувався список SO за обраним клієнтом, то контролеру показуються SO всіх клієнтів, як це описувалося вище. Всі дії контролер виробляє в першій закладці «Список SO». Всі дії проводяться тільки з виділеними рядками.

АРМ оператор експорту регулярних платежів призначений для генерації платежів на підставі введених і авторизованих SO. Пункти спливаючого меню дозволяють користувачеві: оновити список платежів, які очікують вивантаження; виділити поточний рядок; виділити всі платежі, на які вистачає коштів на відповідних рахунках платників; провести експорт виділених платежів до цільових системи (Payments, CardPaym, SWIFT).

У вікні АРМ з'являється список усіх регулярних платежів, які очікують експорту. Платіж «очікує експорту» означає: відповідний SO дійсний має статус «Авторизований» або «На відміну» (до тих пір, поки відміна SO не підтверджена контролером, SO вважається чинним); настала дата платежу при закладі SO, програма автоматично генерує графік платежів і там проставляє дату кожного платежу; платіж що не експортувався, або експортувався, але був скасований у цільовій системі. Тобто, якщо платіж експортували, то він більше недоступний для повторного експорту, але якщо цей платіж після експорту, наприклад, у «Payments», там скасували з якихнебудь причин (недостатньо коштів на рахунку, неправильні реквізити платежу...), то такий платіж знову стане доступним до експорту. У разі, якщо платіж не пройшов через те, що його реквізити неправильні, то відповідний SO потрібно скасувати і в разі необхідності завести новий, уточнивши правильні реквізити.

Платежі з'являються відсортовані та згруповані за рахунком платника. Під кожною групою програма показує підсумкову суму коштів, необхідних для відправки платежів із цього рахунку. У середині групи платежі упорядковано пріоритетам SO. Якщо коштів не достатньо для відправлення всіх платежів, то платежі, на які не вистачає коштів, виділяються червоним кольором.

Для експорту платежів оператор повинен виділити бажані рядки і у спливаючому меню вибрати пункт «Export». Якщо вибрати «Select All» (<Ctrl+A>), то програма виділить усі «білі» рядки. При бажанні виділення можна робити вручну клавішею <Insert>. Програма розраховує поточний залишок по рахунку платника, але не може гарантувати, що платіж обов'язково пройде, тому що на залишок впливають операції, що вводяться в різних системах (MIDAS, Payments, Cash і т.д.), і яка операція буде проводитися за рахунком «перший» ніхто не знає. Тому й залишена можливість ручного виділення платежів для експорту.

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

У головному меню програми є розділ «Reports», за допомогою пунктів якого можна згенерувати та роздрукувати список мем. ордерів, експортованих у Payments, список розпоряджень на списання валюти (SWIFT) і протокол роботи з регулярними платежами. Документи за згенерованими перерахуваннями на карткові рахунки друкуються з програми CardPaym (реєстр зарахувань і зведений мем. ордер) [1, ст. 105].

Аналізуючи систему організації електронного документообігу депозитних і поточних рахунків АТ «ОТП Банк», чітко простежується, що на початковому етапі введення даних за клієнтом здійснюється в 4 етапи, а саме: для друку пакету документів, у «Midas», у «NBUreports», у «Cash».

У такому випадку простежується неможливість виконання проводки в «Cash» без послідовного переносу інформації з Midas в САБ і додаткового введення даних в NBUreports. Тривалість кожного етапу описаної процедури: загальний час на обслуговування одного клієнта становить у середньому 60 хв.

Автоматизована система «Retail», впроваджена в АТ «ОТП Банк», зарекомендувала себе як сильний інструмент роботи з електронною документацією. Оформлення документів у системі «Retail» більшість питань цієї проблематики відноситься не тільки до оформлення документів для конкретної системи, а й до грамотного оформлення документів MS Word взагалі.

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

ПО «Retail» дозволяє : вносити дані за клієнтами і рахунками безпосередньо в систему САБ без використання програми NBU reports і Midas; формувати та друкувати заданий набір документів із можливого переліку; формувати касові проводки для системи Cash; подальші операції з цими проводками здійснюються згідно з процедурою даної програми; здійснювати перенесення даних із системи САБ в Midas після закінчення обслуговування клієнта; уникнути чотириразового введення даних за клієнтом для формування пакету документів і для відкриття рахунків, тому що дані будуть заведені безпосередньо в САБ; істотно скоротити час на відкриття рахунків фізичних осіб, що дозволить збільшити кількість обслуговуваних клієнтів на день; спростити схему документообігу по всій процедурі відкриття рахунків.

Із питань оформлення документів, використовуючи стилі, в системі «Retail» виділяються такі переваги:

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

* при необхідності переоформлення документа (зміна шрифту, властивостей параграфа і т. ін.) це робиться зміною властивостей стилю, і всі фрагменти тексту, оформлені в цьому стилі, автоматично успадкують усі зроблені зміни. В іншому випадку доведеться самостійно вишукувати фрагменти тексту в документі та повторювати для них переформатування. Це займе набагато більше часу, і чим більший документ тим більше часу;

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

* у MS Word є можливість пошуку фрагмента тексту в обраному стилі. Це теж може бути корисним;

* дасть можливість легко і швидко вставити в документ автоматично оновлюваний зміст, індексний покажчик, список ілюстрацій та інші корисні таблиці посилань та індексів.

Використане джерело

1. Polozov A.V Procedures Manual Department: Software Projecting and Development / A.V Polozov : RBU. K., 2013. 178 p.

Размещено на Allbest.ru