Дослідження систем автоматизації для контролю фінансових операцій

Нечаєнко, Сергій Русланович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6443

Title:	Дослідження систем автоматизації для контролю фінансових операцій
Authors:	Зубко, Ігор Анатолійович Нечаєнко, Сергій Русланович
Issue Date:	Jan-2026
Abstract:	В кваліфікаційній роботі освітнього ступеня «магістр» було проведено дослідження систем автоматизації для контролю фінансових операцій та створено гнучкий програмний продукт а також інтегровано в нього засоби для взаємодії з банківськими системами та системами сповіщень. Для реалізації поставленої мети були вирішені наступні завдання: проаналізовано недоліки використання системи приват24; створено математичну модель виконуваних процесів; розроблено власний додаток усунувши знайдені недоліки; розроблено зручний інтерфейс для користувачів; налагоджено автоматизований зв’язок з банківською системою для отримання даних; створено гнучку систему сповіщень.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6443
Appears in Collections:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)

Files in This Item:

File	Description	Size	Format
М_123_2025_Нечаєнко.pdf Restricted Access		1.27 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ
КОМП’ЮТЕРНИХ СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: «ДОСЛІДЖЕННЯ СИСТЕМ АВТОМАТИЗАЦІЇ ДЛЯ
КОНТРОЛЮ ФІНАНСОВИХ ОПЕРАЦІЙ»

Виконав: студент 2 курсу,
групи МСКС-2407
спеціальності
123 Комп’ютерна інженерія
освітня програма
«Спеціалізовані комп’ютерні
системи»
Сергій НЕЧАЄНКО
(прізвище та ініціали)

Керівник Ігор ЗУБКО
( прізвище та ініціали)
Рецензент
(прізвище та ініціали)

Захист дозволяю:
зав. кафедри, д.т.н., професор Валентина ЛУКАШЕНКО
(підпис) (ім’я та ПРІЗВИЩЕ)

Черкаси 2025 року

ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ

БД – База даних
API – Application Programming Interface
CRON – Command Run On (UNIX scheduler)
MVC – Model View Controller, схема розподілення обов’язків програми
HTML – Hyper Text Markup Language, мова розмітки гіпертекту
CSS – Cascading Style Sheets, каскадні таблиці стилей
JS – JavaScript
PM – Primary Key
SQL – Structured Query Language, мова запитів для реляційних БД
ENV – Environment, середовище
FTP – File Transfer Protocol, протокол передачі файлів
SSH – Secure Shell, протокол для з'єднання через консоль
SVC – System Version Control, система контролю версій
FK – Foreign Key
ПЗ – Програмне забезпечення

2

ЗМІСТ

ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ....................2
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ .........................................4
РОЗДІЛ 1. ОГЛЯД ІСНУЮЧИХ ТЕХНОЛОГІЙ ..................................9
1.1. Банківська система Приват24. .................................................... 10
1.2. Система iPUMB ............................................................................... 12
1.3. Переваги додатка «ORDERLIFE». .............................................. 16
Висновки до розділу 1 ........................................................................... 20
РОЗДІЛ 2. АРХІТЕКТУРА ДОДАТКА, ПРОЕКТУВАННЯ БАЗИ
ДАНИХ ТА РОЗРОБКА ІНТЕРФЕЙСУ .............................................. 21
2.1 Міграції БД ........................................................................................ 22
2.2 Database Seeding ............................................................................... 27
2.3.Робота з API ...................................................................................... 29
2.4. Telegram API .................................................................................... 31
2.5. Розробка інтерфейсу ....................................................................... 36
2.6 Статистика. Таблиці. Графіки ...................................................... 43
Висновки до розділу 2 ........................................................................... 48
РОЗДІЛ 3. АВТОМАТИЗАЦІЯ ТА ІНТЕГРАЦІЯ В МОНОБАНК 49
3.1 Планувальник завдань daemon Cron .......................................... 49
3.2 Черги. Воркери. Supervisor. ........................................................... 52
3.3.Інтеграція в МОНОБАНК. Зміни в БД. ...................................... 54
3.4. Зміни в коді ...................................................................................... 55
3.5. Зміни в інтерфейсі .......................................................................... 58
Висновки до розділу 3 ........................................................................... 59
ВИСНОВКИ ............................................................................................... 60
ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ ...................................................... 62

3

ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ

Актуальність теми
Організація контролю фінансів є дуже важливим питанням для
кожного. На поточний момент системи, які пропонують українські
банки, не є достатньо гнучкими для зручного використання.
Питання аналізу фінансових потоків є актуальним доти, поки
„Гроші керують світом“. Одним із важливих недоліків сучасних
банківських систем є недостатня гнучкість в напрямі інформування своїх
клієнтів
Не менш важливим є наявність зручного користувацького
інтерфейсу. Тому, перш за все, основним критерієм на який мають
орієнтуватися розробники таких додатків – зручність. Звісно, ми маємо
розуміти, що не існує програми, яка б повністю ідеально задовольняла
всі потреби користувача, адже для кожного вони різні. Для когось – це
інтерфейс, важливість комфортного візуального сприйняття інформації,
для когось – наявність додаткових розширень додатка, спеціального
функціоналу для реалізації необхідних операцій.
У сучасних умовах цифровізації економіки та стрімкого зростання
обсягів фінансових даних особливої актуальності набуває питання
ефективного контролю фінансових операцій.
Підприємства, фінансові установи та державні органи щоденно
здійснюють значну кількість транзакцій, що потребують точного,
оперативного та прозорого обліку. Традиційні методи контролю,
засновані на ручній обробці даних, є трудомісткими, схильними до
помилок і не забезпечують належного рівня оперативності та безпеки.
Системи автоматизації контролю фінансових операцій дозволяють
здійснювати безперервний моніторинг транзакцій у реальному часі,
4

своєчасно виявляти фінансові порушення, шахрайські дії та аномальні
операції. Їх впровадження сприяє підвищенню достовірності фінансової
інформації, зниженню ризиків, оптимізації управлінських рішень і
забезпеченню відповідності діяльності вимогам законодавства та
міжнародним стандартам фінансової звітності.
Особливо важливою є роль таких систем в умовах посилення
вимог до фінансової прозорості, протидії відмиванню коштів та
фінансуванню тероризму, а також інтеграції України у світовий
економічний простір.
Використання сучасних інформаційних технологій, зокрема
автоматизованих інформаційних систем, аналітичних платформ та
елементів штучного інтелекту, створює передумови для підвищення
ефективності фінансового контролю та безпеки фінансових потоків.
Таким чином, дослідження систем автоматизації для контролю
фінансових операцій є актуальним і своєчасним, оскільки воно
спрямоване на вирішення важливих практичних і наукових завдань,
пов’язаних з підвищенням надійності, прозорості та ефективності
управління фінансовими ресурсами.
Дослідженням систем автоматизації для контролю фінансових
операцій присвячені роботи відомих вітчизняних та зарубіжних вчених,
таких як Бутинець Ф. Ф., Кузьмін О. Є., Мельник О. Г., Ковалюк О. М.,
Легенчук С. Ф., Пономаренко В. С., Вовчак О. Д., Turban E., Volonino L.,
Scott Konishi, Alan Yuille, James Coughlin, Каленіченко Дмитро, Редмон
Джозеф, Фархаді Алі, Бочковський Олексій, Гіршик Росс, Рен Шаочінг
та багатьох інших.
Тому, проаналізувавши роботу вже існуючих конкурентних
додатків, є актуальним створення власного проекту, в якому буде
враховано всі переваги та недоліки вже існуючих сервісів.
5

Під час розробки програмного продукту використовується
еволюційна модель, заснована на таких принципах. Розробляється
початкова версія продукту, яка передається кінцевим користувачам для
оцінки, після чого продукт доробляється, враховуючи думку замовника.
Аналогічно розробляються, передаються й оцінюються проміжні версії
програмного продукту, поки не з’явиться повністю готовий продукт,
який відповідає всім вимогам замовника.
В якості інструменту створення програмного засобу було обрано
PhpStorm 2018.3.5 – інтегроване середовище розробки (IDE) мовою
програмування PHP, яке є продуктом компанії jetbrains.

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

- проаналізувати недоліки використання системи приват24.
- створити математичну модель виконуваних процесів.
- розробити власний додаток усунувши знайдені недоліки.
- розробити зручний інтерфейс для користувачів.
- налагодити автоматизований зв’язок з банківською системою для
отримання даних.
- створити гнучку систему сповіщень.
6

Об’єкт дослідження - процес отримання та подальшої обробки
даних про здійснені фінансові операції та стан фінансових рахунків за
допомогою API Приватбанку.
Предмет дослідження – система автоматизації для контролю
фінансових операцій.

Методи дослідження базуються на використанні методів
математичного моделювання, машинного навчання, мова програмування
JavaScript, Framework Laravel 5.7, система контролю версій Git, хостинг
Ukraine.

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

Практичне значення одержаних результатів полягає в
доведенні отриманих наукових результатів до конкретних інженерних
рішень:
− створено програмний продукт «Система контролю фінансових
операцій OrderLife».

Апробація результатів роботи. Результати роботи доповідалися
й обговорювалися на студентській науковій конференції:
− дні студентської науки ЧДТУ, 23 квітня, м. Черкаси,
Україна, 2025.
7

Структура та обсяг випускної роботи. Кваліфікаційна
робота магістра складається із загальної характеристики роботи, 4
розділів, висновків та списку використаних джерел. Робота
викладена на 83 сторінках. Ілюстрована 40 рисунками та має
5 таблиць. Список використаних джерел містить 41 найменування.

8

РОЗДІЛ 1.
ОГЛЯД ІСНУЮЧИХ ТЕХНОЛОГІЙ

Банківські картки — невід'ємна частина нашого повсякденного
життя. На сьогоднішній день використання банківських карток майже
повністю витіснило готівковий розрахунок.
Переведення коштів, сплата послуг, розрахунки в магазинах та
безліч інших операцій наразі можна здійснювати з їх допомогою. Такий
перехід пов’язаний із рядом переваг, які надають безготівкові
розрахунки:
● Зручність. Маючи картку, можна не носити із собою велику суму
готівки, але в той же час завжди мати змогу зробити необхідну
покупку. Більшість підприємств, орієнтованих на надавання
якісного сервісу покупцям, приймають карти.
● Безпека. В разі втрати гаманця готівку вже буде не повернути, а
кошти, що зберігаються на карті можна зберегти, якщо своєчасно
заблокувати карту, зателефонувавши в банк.
● Фінансовий контроль. Привчивши себе робити покупки,
використовуючи карту людина має змогу аналізувати свої витрати.
● Швидкість. Купівля за допомоги безконтактних технологій
відбуваються майже миттєво.
● Інноваційність. Можливість поєднання безконтактної карти з
іншими пристроями.
Щоб отримати можливість аналізувати свої витрати раніше
користувалися функцією щомісячної виписки по карті. Її можна
отримати в банку, або ж електронною поштою.
9

Як правило, дані виписки формують у певний відведений день, але
за бажанням клієнта її можуть скласти в будь-який день і за будь-який
період. В залежності від банку дана послуга може бути платною. Такий
метод є не дуже зручним, тому на сьогодні вже існує ряд створених
додатків, здатних задовольнити потреби користувача у можливості
бачити статистику своїх розрахунків не тільки за місяць, а і за
конкретний день. До найвідоміших з них належать:
1.1. Банківська система Приват24.
Приват24 — це багатофункціональна система дистанційного
банківського обслуговування, розроблена АТ КБ «ПриватБанк»,
яка забезпечує клієнтам доступ до фінансових послуг у режимі
24/7 через мережу Інтернет.
Система Приват24 надає можливість фізичним та юридичним
особам здійснювати широкий спектр банківських операцій без
необхідності відвідування відділень банку. Доступ до сервісу
реалізується за допомогою вебверсії та мобільного додатка для
операційних систем Android та iOS.
Основними функціями системи є перегляд залишків коштів і
історії транзакцій, здійснення грошових переказів між рахунками,
оплата комунальних і державних послуг, поповнення мобільного
зв’язку, керування депозитними та кредитними продуктами, обмін
валют, а також керування банківськими картками.
Особлива увага в системі Приват24 приділяється безпеці
фінансових операцій. Для захисту даних користувачів
застосовуються сучасні криптографічні методи, двофакторна
автентифікація, підтвердження операцій одноразовими кодами та
постійний моніторинг підозрілої активності.
10

Завдяки зручному інтерфейсу, високому рівню надійності та
широкому функціоналу система Приват24 є ефективним
інструментом автоматизації фінансових операцій і широко
використовується у повсякденній діяльності користувачів та в
дослідженнях сучасних інформаційних банківських систем.
Тут є доступ до всіх карток і рахунків користувача і
можливість проведення операцій з ними, різноманітні платежі,
поповнення телефону, оплата послуг (комуналка, інтернет,
кабельне, ігри), покупка та інше. Що найголовніше, працювати з
додатком завдяки продуманому інтерфейсу (рисунок 1.1) дуже
зручно – усі пункти меню і підменю розташовуються в лівій
частині екрана в горизонтальному положенні, а операції та
інформація щодо рахунків – у правій. Завдяки цьому заплутатися
в ньому, незважаючи на велику кількість пунктів, практично
неможливо.

11

Рис. 1.1. Інтерфейс “Приват24”
1.2. Система iPUMB

iPUMB — це сучасна система дистанційного банківського
обслуговування, розроблена Акціонерним товариством «Перший
Український Міжнародний Банк» (ПУМБ), яка призначена для
автоматизації фінансових операцій фізичних осіб із
використанням мобільних інформаційних технологій.
Система функціонує у режимі реального часу та забезпечує
цілодобовий доступ користувачів до банківських послуг через
мережу Інтернет.
Система iPUMB реалізована у вигляді мобільного
застосунку для операційних систем Android та iOS і надає
користувачам можливість дистанційно керувати власними
фінансовими ресурсами без необхідності відвідування банківських
відділень. Архітектура системи побудована за клієнт-серверним
принципом із використанням захищених каналів передачі даних.
Функціональні можливості системи iPUMB включають
перегляд залишків коштів та історії операцій за рахунками і
платіжними картками, здійснення внутрішніх і міжбанківських
переказів, оплату комунальних, державних та комерційних послуг,
поповнення мобільного зв’язку, керування кредитними та
депозитними продуктами, а також налаштування параметрів
банківських карток.
Особлива увага в системі iPUMB приділяється забезпеченню
інформаційної безпеки. Для захисту персональних і фінансових
даних застосовуються механізми багатофакторної автентифікації,
біометричної ідентифікації, криптографічного шифрування
12

інформації та підтвердження фінансових операцій у режимі
реального часу. Це дозволяє забезпечити високий рівень
надійності та захисту від несанкціонованого доступу.
Таким чином, система iPUMB є ефективним інструментом
автоматизації банківських операцій, що поєднує зручність
користування, високий рівень безпеки та широкий функціонал.
Вона може розглядатися як об’єкт дослідження в дипломній
роботі у сфері інформаційних систем, фінансових технологій та
автоматизованих систем управління.
iPumb. Додаток має карти, на якій позначено відділення та
банкомати, конвертер основних валют, стрічки новин банку і
контактну інформацію. Через браузер можна зайти і в систему
онлайн-банкінгу “ПУМБ”(рисунок 1.2).
Таким чином, ним можна користуватися з мобільного
пристрою навіть без спеціального додатка, до того ж всі функції
будуть доступні клієнту.
Вони дають можливість зручно здійснювати операції з
грошима на власних рахунках, оплачувати комунальні та інші
послуги, мобільний зв’язок та інші додаткові функції, зв’язані з
банківськими операціями.
В таблиці 1.1. наведено загальну структурну схему системи
iPUMB, яка відображає взаємодію користувача з клієнтською
частиною, серверними модулями та зовнішніми інформаційними
сервісами.

13

Таблиця 1.1.
Структурна схема системи iPUMB

№ Назва Пояснення
1 Користувач фізична особа, яка здійснює
(смартфон, біометрична взаємодію з системою через
автентифікація) мобільний пристрій
2 Мобільний застосунок клієнтська частина системи,
iPUMB що забезпечує інтерфейс
(інтерфейс користувача, користувача та попередню
клієнтська логіка) обробку запитів.
3 Захищений канал зв’язку забезпечує конфіденційність
(HTTPS, TLS) та цілісність даних під час
передавання.
4 Сервер автентифікації відповідає за ідентифікацію
(логін, MFA, токени користувача та контроль
доступу) доступу.

5 Сервер бізнес-логіки обробляє фінансові операції
(платежі, перекази, та взаємодіє з базами даних.
керування рахунками)
6 Банківські бази даних зберігають інформацію про
(рахунки, транзакції, рахунки, транзакції та
клієнтські дані) клієнтів.
7 Зовнішні платіжні та забезпечують інтеграцію з
державні сервіси платіжними системами та
(НБУ, платіжні системи, державними
комунальні сервіси) інформаційними ресурсами
14

Рис. 1.2 – Інтерфейс iPumb.

15

1.3. Переваги додатка «ORDERLIFE».

Провівши аналіз роботи додатків Приват24 та PUMB, було
розроблено персональний додаток, який враховує всі недоліки
використання згаданих додатків. Складний інтерфейс додатка часто
призводить до того, що користувач не в стані розібратись з роботою
функціоналу.
Звичайно, це буде ускладнювати та уповільнювати процес
користування таким додатком, якщо він не має навичок роботи в такому
середовищі. Як результат - користувач видаляє додаток.
Основною задачею було створення максимально зручного
інтерфейсу, простої інструкції використання та необхідного базового
функціоналу. OrderLife включає в себе:
1. Інтуїтивний інтерфейс. Після запуску додатка система
пропонує підказки, які допоможуть зорієнтуватись у
послідовності дій, які треба виконати для здійснення бажаної
операції.
2. Компактне розміщення різноманітної статистики, що
пропонує система, такі як показники та графіки динаміки
витрат та доходів за певний період.
3. Включено можливість класифікації витрат за категоріями:
продукти, комунальні витрати, грошові перекази, розваги
тощо.
4. Безпека. Забезпечено перевірку коректності введених даних
та забезпечення приватності всіх персональних даних.
5. Нотифікація. Додаток надає можливість отримувати
інформацію про здійснені платежі шляхом надсилання
16

повідомлення засобами обмінників повідомлень чи
поштових скриньок.
6. Швидкість. Забезпечена шляхом мінімізації надлишкового
функціоналу та оптимізації процесу завантаження всіх даних
на сторінку.
7. Мультибанкінг. Можливість підключення карток різних
банків, а саме Монобанку та Приватбанку з перспективою
додавання інших.

1.4. Система МОНОБАНК.

Монобанк — це український необанк (мобільний банк), який
працює без фізичних відділень і надає повний спектр банківських послуг
через мобільний застосунок на Android та iOS. Він був запущений у 2017
році командою Fintech Band у партнерстві з Universal Bank під його
банківською ліцензією.
Основною ідеєю є те що банк повністю цифровий: всі операції
виконуються через мобільний додаток — відкриття рахунків, платежі,
перекази, кредити, валютні операції тощо.
Тобто немає відділень — для операцій, як зняття чи внесення
фізичної валюти, використовують каси Universal Bank або партнерські
банки (наприклад, A-Bank).
Реєстрація та використання проводиться за допомогою додатків.
Для цього потрібно завантажити додаток з App Store або Google Play.
Потім пройти ідентифікацію онлайн (паспорт або ІПН через фото чи
Дія); Отримуєш карту — кур’єром або самовивозом з точки видачі.
Основні функції додатку: рахунки в UAH, USD, EUR — для гривні
повністю все в додатку, для валюти частково через каси партнерів.
17

Платежі та перекази — без комісії між картами і зручні оплати
комунальних.
Кредити та карти — дебетові й кредитні картки з кешбеком.
Кешбек-система — клієнт обирає категорії витрат, за які повертається до
20 % (залежно від умов
Підтримка у месенджерах — Viber, Telegram, Messenger, телефон.
Монобанк має системи продуктів, сервіси та накопичувальні
рахунки.
Монобанк має сервіс «Банка» — це накопичувальний рахунок для
заощаджень зі зручними тарифами, який можна налаштувати під свої
цілі і фінансові правила.
Інтегровані сервіси, такі як market by mono — маркетплейс у
застосунку для покупки товарів, у тому числі з можливістю розстрочки.
monobazar — нова функція (зима 2025) для торгівлі вживаними
товарами прямо через застосунок з автоматичним описом через штучний
інтелект, персональними сторінками продавця та захищеними оплатами
Гейміфікація / ачівки — система віртуальних досягнень, які
стимулюють активність у застосунку.
Shake2Pay / соціальні платежі — інноваційні способи
оплати/переказів (через рух телефону або GPS-локацію).
Монобанк сам не є банком у юридичному сенсі — усі банківські
операції виконуються під ліцензією Universal Bank, а Fintech Band
розробляє та підтримує додаток і сервісну частину.
Монобанк є одним із найбільш завантажуваних фінансових
застосунків в Україні. Станом на початок 2025 року — близько 9.8 млн
активних карток.
Переваги й недоліки системи МОНОБАНК.
Переваги:
− Повністю цифровий, без черг і відділень
18

− Зручний інтерфейс і швидкі платежі
− Хороші умови кешбеку
− Інтегровані додаткові сервіси
Недоліки / ризики:
− Залежність від мобільного додатка (без веб-версії)
− Можливі тимчасові збої системи
− Обмежені операції з готівкою
В таблиці 1.2. представлена різниця між Монобанком і
традиційним банком.
Таблиця 1.2.
Відмінність між Монобанком і традиційними банками
Критерій Монобанк Традиційний банк
Повністю онлайн Відділення,
Формат роботи
(мобільний застосунок) онлайн-сервіси
Дистанційно, за 10–15 Часто з візитом у
Відкриття рахунку
хв відділення
Каса, менеджер, кол-
Обслуговування Через чат у застосунку
центр
Нижчі Вищі
Витрати банку
(немає відділень) (утримання офісів)
Швидкість
Дуже висока Залежить від банку
операцій
Обмежена
Робота з готівкою Повноцінна
(через партнерів)

19

Висновки до розділу 1

В цьому розділі кваліфікаційній роботі магістра було розглянуто
такі фінансові системи, як iPUMB, «ORDERLIFE», Приват24 та
Монобанк, проаналізовано їх преваги та недоліки використання.

20

РОЗДІЛ 2.
АРХІТЕКТУРА ДОДАТКА, ПРОЕКТУВАННЯ БАЗИ ДАНИХ
ТА РОЗРОБКА ІНТЕРФЕЙСУ

Було спроектовано архітектуру додатка у вигляді блок-схеми
(рисунок 2. 1):
- Вибірка даних з БД (користувач та його транзакції) (1)
- Формування XML запиту для ПриватБанк API (1-2 )
- Запит на отримання транзакцій користувача по API ( 2)
- Парсинг XML відповіді від ПриватБанк API (2 -3)
- Запис нових транзакцій в БД (3)
- Відправка нових транзакцій в Telegram по API (4)

Рис. 2.1. Архітектура додатка
21

2.1 Міграції БД

Веб-фреймворк Laravel має гнучку систему міграцій. Таблиці
можна створювати і вручну, проте використання міграцій має значні
переваги:
- через файли міграцій відслідковується історія змін БД.
- механізм дозволяє створити повну структуру БД в новому
середовищі (не використовуючи бекап).
- дає можливість відмінити останні зміни в БД.
Створюються міграції командою php artisan make:migration
назва , які потім викликаються командою php artisan migrate.
Для проекту було створено 10 таблиць (рис. 2.2).
Таблиці migrations, users, password_resets, jobs, failed_jobs є
сервісними (архітектура визначена розробниками Laravel). Міграції для
них були створені командами:

22

Рис. 2.2 Таблиці БД
23

- php artisan make:auth
- php artisan queue:table
- php artisan queue:failed-table
Таблиця migrations містить в собі інформацію про вже виконані
міграції. Міграції інших таблиць були створені вручну. Приклад міграції
для створення таблиці transactions (рисунок 2.3).
timeStamps() – створює колонки created_at та updated_at. При
кожному збереженні запису поле updated_at буде оновлюватись
автоматично (реалізація в батьківському класі – Model).
softDeletes() – додає колонку deleted_at. Цей механізм носить назву
м'яке(soft) видалення. По замовчуванню всі запити будуть вибирати
лише записи, де deleted_at – порожнє. Для жорсткого (hard) видалення на
рівні БД використовується метод forceDelete().

24

Рис. 2.3. Міграція

unique() – створює індекс (unique constraint) для вказаних полів.
Подібні індекси значно пришвидшують вибірку з масивних таблиць.
Метод міграції down() – викликається при *відкаті*. Команда: php
artisan migrate:rollback. Для зв'язку між таблицями були створені foreign
keys окремою міграцією (рисунок 2.4.).
25

Рис. 2.4. Foreign Keys

Та відповідно його rollback (рисунок .2.5.):

Рис. 2.5. Rollback міграції

Використання FK значно полегшує роботу з даними:
- Можливість (ON DELETE CASCADE). При видаленні
користувача нам не треба додатково шукати його дані в інших таблицях.
Записи, які прив’язані по FK до нього, будуть видалені автоматично.
26

- створення записів в таблицях, де зв'язок з користувачем
обов'язковий буде заборонено на рівні БД.

2.2 Database Seeding
В створеній БД всі таблиці містять динамічні дані, окрім таблиць
categories та category_keyword. Ці таблиці містять категорії транзакцій та
ключові слова для її визначення, вони були заповнені одноразово (в
майбутньому ці таблиці можна буде зробити динамічними, наприклад,
давши адміністраторам можливість їх редагувати).
Для заповнення таблиць статичними даними зручно
використовувати механізм Seeding (посів). Для початку створимо Seed
командою php artisan make:seed CategoriesSeeder. Заповнюємо створений
Seeder. Переходимо в файл database/seeds/DatabaseSeeder.php та
вказуємо в ньому запуск створеного CategoriesSeeder (рисунок 2.6.).

Рис. 2.6. Заповнення таблиць
27

Команда для запуску посіву даних: php artisan db:seed.
На рисунку 2.7 показано результат заповнення categories.

Рис. 2.7. Результат заповнення categories

Вищеописані механізми дають можливість в новому оточенні (з
порожньою БД) створити повну структуру таблиць та заповнити їх
статичними даними, написавши лише 2 команди в консолі.

28

2.3.Робота з API
Privat24Api
API ПриватБанку надає можливість взаємодії з ним зовнішніх
проектів. З документацією можна ознайомитися на сайті
https://api.privatbank.ua/
Мерчант це сутність яку можна створити в особистому кабінеті
приват24 та прив'язати його до однієї з банківських карток. Для даної
сутності було створено таблицю merchants в БД та модель Merchant в
проекті.
Обмін відбувається за SOAP (simple object access protocol). Запит
та відповідь надсилаються в XML (формат визначений ПриватБанком).
В проекті будуть використовуватись 2 методи API:
1. Метод перший. Поточний баланс мерчанта. Формат запиту
(рисунок 2.8):

Рис. 2.8. Поточний баланс мерчанта. Формат запиту.
2. Метод другий. Виписки по рахунку мерчанта. В запиті вказується
період за який необхідно отримати виписки. У відповідь отримуємо
29

масив транзакцій за вказаний період. Для обох АРІ методів написано
методи в моделі Merchant (рисунок 2.9).

Рис. 2.9. Методи в моделі Merchant

30

Метод для отримання балансу буде відрізнятись форматом XML
для запиту та обробкою результату.
З приводу використання останнього методу. Експериментальним
шляхом було виявлено, що ПриватБанк не завжди стабільно передає дані
за довгий період. Тому було вирішено розбивати довгі періоди на короткі
(не більше 1 місяця) та отримувати дані окремими запитами.
В проекті даний метод для довгих періодів викликається лише раз.
Тому логіка розбиття періоду знаходиться зовні методу класу. При
подальшому використанні даного методу, гарною ідеєю було б
перенести логіку розбиття періоду всередину.
Ідея розбиття періоду була вдалою, проте кількість запитів по API
збільшилась. Час виконання імпорту також виріс суттєво. Головною
проблемою було синхронність виконання запитів (кожен наступний
чекав відповіді попереднього).
Це наштовхнуло на асинхронне надсилання запитів. Проте і це не
вирішило проблему (виявилось що API при одночасному надходженні
запитів з одного IP починає повертати статус *too many requests*) . Тож
поки ПриватБанк не змінить свою політику, оптимізувати роботу з
даним API не є можливим.

2.4. Telegram API

На поточний момент Telegram один із найбільш популярних
обмінників повідомлень в Україні. В роботі він використаний, як один із
можливих варіантів отримання сповіщень для користувачів.
31

Ознайомитись з документацією API можна на посиланням [6].
Використовуючи @BotFather (рисунок 2.10) було створено власний
TelegramBot(@orderlife_bot) для системи “OrderLife”.

Рис. 2.10. Telegram bot

Для надсилання повідомлень в Telegram використано метод
sendMessage. Метод надсилання – GET. Обов’язкові параметри text та
chat_id.

https://api.telegram.org/bot<token>/sendMessage?chat_id=...&text=...

Унікальний сhat_id має кожен користувач Telegram (його потрібно
вказувати після реєстрації кожному користувачу). Дізнатись сhat_id є
32

можливість, використавши @userinfobot (для цього була створена
допоміжна вказівка).
Для взаємодії з ПриватБанкApi були написані методи напряму в
моделі Merchant. Аналогічно можна було і реалізувати для Telegram-у в
моделі User, проте було вирішено застосувати альтернативний підхід і
розробити допоміжний сервісний клас для роботи з TelegramBotApi.
В подальшій розробці в ньому можна буде реалізувати інші методи
API (рисунок 2.11):

33

Рис. 2.11. Метод надсилання повідомлення

сonfig() – стандартна helper-функція веб-фреймворку Laravel. В
поточному випадку використовується для отримання конфігурації
Telegram боту (рисунок 2.12).

Рис. 2.12. Отримання конфігурації Telegram боту

Використання запропонованого методу представлено на рисунку 2.13.

Рис. 2.13. Використання методу

34

Запропоновано розглянути сфери застосування систем
автоматизації для контролю фінансових операцій наведені в таблиці 2.1.

Таблиця 2.1.
Сфери застосування систем автоматизації для контролю
фінансових операцій

№ Сфера застосування Характеристика використання
1 Банківська сфера Контроль платежів, кредитних
та депозитних операцій,
виявлення підозрілих
транзакцій
2 Підприємства та організації Автоматизація
бухгалтерського обліку,
контроль доходів і витрат
3 Державні фінансові органи Контроль бюджетних коштів,
державний фінансовий аудит
4 Податкові служби Аналіз податкової звітності,
контроль сплати податків
5 Фінансовий моніторинг Виявлення відмивання коштів
(AML/CFT) та фінансування тероризму
6 Торгівля та сервіс Контроль касових операцій,
електронних платежів
7 Страхові компанії Контроль страхових платежів і
виплат
35

8 Інвестиційні ринки Моніторинг операцій з
цінними паперами
9 Аудиторські компанії Автоматизований фінансовий
аналіз та аудит
10 Електронна комерція та Контроль онлайн-платежів та
фінтех цифрових транзакцій

2.5. Розробка інтерфейсу

Реєстрація та авторизація.
Веб-фреймворк Laravel має стандартний механізм Authentication
(використвується стандартний сессійний підхід). Саме цей класичний
механізм і було використано, з додаванням певної кастомізації.
Традиційно головна сторінка доступна за адресою
https://domen.name/ . Для створення потрібного шляху було додано роут
до файлу /routes/web.php. Допоміжний клас фреймворку Router при
завантаженні додатка зчитує цей файл та знаходить потрібний запис та
визначає потрібний Controller та його action.
Розширення файлів .blade вказує на те що з цими працює
шаблонізатор (потрібен для спрощення роботи php з html). Вміст файлу
views/welcome.blade.php (рисунок 2.14):

36

Рис. 2.14. Вміст файлу views/welcome.blade.php.

Після авторизації користувач перенаправляється в Особистий
кабінет.

Тобто буде запущено action(index) в HomeController (рисунок 2.15).

37

Рис. 2.15. Запуск action(index) в HomeController

Вміст конструктору запускає механізм MiddleWare . В поточному
випадку це потрібно для того, щоб перенаправляти неавторизованих
користувачів на сторінку авторизації.
MiddleWar-ами займається класс – App\Http\Kernel. В ньому
вказані шляхи до классів з аліасами , в нашому випадку – auth (рис.
2.14).

Рис. 2.14. Шляхи до классів з аліасами

В середині цього класу і реалізовано перенаправлення. Даний
MiddleWare було підключено до всіх Контролерів (весь доступний
функціонал потребує авторизованого користувача). Тобто
неавторизованому користувачу доступні лише 3 сторінки
(авторизація, реєстрація та головна сторінка з посиланнями на них).
MiddleWare дуже зручний механізм, який дає наступні переваги:
- Звільняє Controller-и від непотрібної в них логіки.
38

- Об’єднує в собі логіку для багатьох роутів
- Дає можливість масово змінювати формат відповіді серверу

Особистий кабінет. Налаштування облікового запису.

Сторінка особистого кабінету доступна за роутом (рисунок 2.15):

Рис. 2.15. Route

Тіло методу index:

Рис. 2.16.Index

39

Отримавши авторизованого користувача, перевіряється чи
заповнив користувач основні дані для роботи з додатком та записуються
підказки для юзера в масив warnings. За індексом ‘modal’ записується id
модального вікна реалізованого на сторінці. В цих модальних вікнах
дається можливість завершити налаштування.
Підхід з використанням модальних вікон допомагає менше
перезавантажувати сторінку, що збільшує комфорт використання
програмного забезпечення (ПЗ). Особливо зручним та доречним це є при
необхідності виконати нескладну операцію або показати додадкову
інформацію.
На рисунку 2.17. представлено виведення warnings на view .

Рис. 2.17. Виведення warnings на view

Обробка збереження telegram-id (рисунок 2.18.)

40

Рис. 2.18. Обробка збереження telegram-id

WithErrors() - допоміжний метод який записує масив з помилками
в сесію. Те саме відбувається при валідації некоректних даних. Потім ці
помилки виводяться таким самим чином як і нещодавно
продемонстровані підказки (рисунок 2.19).

Рис. 2.19 Помилка при валідації некоректних даних

41

Обробка збереження картки банку представлено на рисунку 2.20.

Рис. 2.20. Обробка збереження картки банку.

Перед збереженням картки використувується раніше написанний
метод getBalance() щоб додаково перевірити валідність введенних даних,
надіславши запит до Приват24.
Для можливості отримувати сповіщення було створено 2 checkbox-
и (рисунок 2.21) .

42

Рис. 2.21. Checkbox-и

При зміні значення на backend відправляється ajax запит, який
змінює значення даного поля в БД. Реалізація методу (рисунок 2.22):

Рис. 2.22. – Зміна значення

2.6 Статистика. Таблиці. Графіки

Завершивши всі налаштування, та завантаживши транзакції на
сторінку особистого кабінету в окремих блоках завантажується
статистика (рисунок 2.23).
43

Рис. 2.23. Статистика

Кожен із блоків завантажується на сторінку окремим ajax методом.
Такий підхід дозволяє не формувати всі дані при завантаженні сторінки,
а підтягувати їх вже після її завантаження. Таким чином сторінка
віддається значно швидше. Реалізація методу для статистики за
категоріями (рисунок 2.24).

44

Рис. 2.24. Метод статистики за категоріями

Тіло методу представлено на рисунку 2.25.

45

Рис. 2.25. Тіло методу

Після цього бібліотека chart.js трансформує дані в графік. Також
можливий перегляд повної історії транзацій (рисунок 6.13). Для цього
була створена окрема сторінка.
46

Рис. 2.26. Історія транзацій

Використані компоненти: Select2 для фільтрів (вид, категорія,
картка), jQuery Datepicker для фільтрів по датам. Datatable для таблиці з
данними (містить миттєве сортування, пошук по всім полям та пагінацію
на стороні фронтенду).

47

Висновки до розділу 2

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

48

РОЗДІЛ 3.
АВТОМАТИЗАЦІЯ ТА ІНТЕГРАЦІЯ В МОНОБАНК

3.1 Планувальник завдань daemon Cron

Cron – це найбільш популярна утиліта, яка запускає процеси за
розкладом. Laravel в свою чергу має механізм scheduling, зручна ООП
обгортка для cron. Для того щоб почати використовувати допоміжний
Scheduler, потрібно налаштувати його щохвилинний cron запуск. На
сервері хостингу Ukraine це cron-завдання виглядає таким чином
(рисунок 3.1):

Рис. 3.1. Кронове завдання

***** - розклад запуску команди згідно синтаксису cron-завдань. В
поточному випадку щохвилинний запуск.
Тепер щохвилини крон буде інстанціювати клас нашого Scheduler-
а (рис. 3.2).
49

Рис. 3.2 Клас Scheduler-а

В Методі schedule є можливість запускати команди за внутрішнім
розкладом додатка. Раніше для запуску різних процессів, для кожного
ставилось кронове завдання на файл. Scheduler в свою чергу позбавляє
необхідності щоразу при зміні в логіці запуску процесів змінювати
конфігурації крону, що суттєво спрощує процесс розробки.
Команда UploadTransactions була створена для регулярного,
щохвилинного оновлення актуальних транзакцій користувачів. Це є
необхідністю, через обмежність функціональності API.
Всі написані команди також є можливість запускати і вручну через
консоль подібним чином (рисунок 3.3) :

Рис. 3.3 – Запуск через консоль

Тіло класу команди UploadTransactions показано на рисунку 3.4.
50

: В класі TransactionsSaver реалізовано збереження транзацій до БД.
Також він повертає транзакції, яких в БД не було (нові). Так як
щохвилини надсилаються запити, то у відповідях постійно
зустрічаються одні і ті самі транзакції.

Рис. 3.4 Клас команди UploadTransactions

Сповіщати в свою чергу потрібно лише про нові. Уніфікація
відбувається полем appcode. Після отримання нових транзакцій та
перевірки прапорців, які виставив користувач (чи потрібні йому
сповіщення) запускається механізм сповіщення. Так як відправлення
пошти та повідомленнь в телеграм не завжди швидковиконувані операції
для них раціонально використовувати черги та воркери (про це
наступний розділ).

51

3.2 Черги. Воркери. Supervisor.
Використання черг для виконання завдань має величезні переваги
над синхронним виконанням:
- Після dispatch скрипт іде далі, і не чекає завершення завдання.
- Асинхронне виконання. В сучасних реаліях багатопоточних
процесорів швидкість виконання великої кількості завдань суттєво
зростає.
- Фатальні помилки. У випадку відключення серверу, всі процеси
примусово зупиняються. При використанні черг, завдання
записуються в БД і при перезапуску серверу, воркери
перепіднімають завдання і виконують його. (при синхронному
виконанні, завдання втрачається назавжди).
Supervisor. Механізм який тримає процеси з чергами, і
перепіднімає їх у всіх можливих випадках (при фатальних помилках в
додатку або після відключення світла та перезапуску серверу). У випадку
з веб-фреймворком Laravel процес запускають команда: php artisan
queue:listen. Кожен із таких процесів і називається воркером.
Завдання для відправки транзакії в телеграм (рисунок 3.5):

Рис. 3.5. Завдання для відправки транзакії в телеграм
52

При dispatch-і викликається лише конструктор, який записує
об’єкт в БД ( для цього була створена таблиця jobs). Потім воркер
перехоплює завдання та викликає метод handle. При виконанні видаляє
запис із таблиці jobs, а при помилці записує в таблицю failed-jobs, звідки
потім є можливість запустити завдання ще раз. Ручний запуск воркера
(рисунок 3.6):

Рис. 3.6 Запуск воркера

Можливості фреймворку в роботі з завданнями:
● Примусово провалити виконання завдання. Метод ->fail().
● Синхронний запуск, якщо це необхідно
● Можливість підняти процеси з чергами
● Дебаг алгоритму. Метод ->dispatchNow().

53

3.3.Інтеграція в МОНОБАНК. Зміни в БД.

Головною відмінністю API Приватбанку та Монобанку є різний
тип ідентифікації користувачів (Мерчанти у Приватбанка,
Account_tokens у Монобанка). Проте в системі може бути користувач у
якого є картки обох банків, тому створювати повністю відокремлені
таблиці, інтерфейс, код під кожен банк було б не зовсім раціонально.
Було вирішено інтегрувати логіку нового банку в уже написаний код
(рисунок 3.7).

Рис. 3.7. База даних

54

Було створено дві нові таблиці для роботи з Монобанком
monobank_accounts та monobank_tokens. Дві тому, що аккаунт-людина,
токен-картка. У однієї людини может бути кілька карток-токенів (В
логіці Приватбанку під кожну картку створюється Мерчант, тому
таблиця там одна).
Також була змінена структура таблиці transactions. Додано
стовпчик bank з типом Enum та можливими значеннями –
[‘privat’,’monobank’], стовпчики account_id,
monobank_unique(абсолютний аналог стовпчиків merchant_id та
appcode).
Також для уніфікації транзакцій було створено унікальні ключі (рисунок
3.8).

Рис. 3.8. Унікальні ключі

3.4. Зміни в коді

Першим доповненням було отримання та збереження транзакцій
від Монобанку. Реалізовано це було в класі TransactionsSaver. Раніше
був лише один метод – SaveTransactions (рисунок 3.9).
55

Рис. 3.9. Нова архітектура

Така реалізація дозволяє додати новий метод, не змінюючи
інтерфейс виклику старого методу (Отримано новий функціонал,
використавши та не зламавши старий).
Подібним чином були реалізовані інші методи інших класів
(створення/видалення картки, вибірка транзакцій тощо.)
Другим кроком була перевірка всіх місць в коді, де є запити в БД
до таблиці transactions. Запити були змінені таким чином як
представлено на рисунку 3.10.

56

Рис. 3.10. Зміна запитів

Тобто для отримання всіх транзакцій користувача не забуваємо
додавати в вибірку транзакції нового банку. Також були додані опції для
валютних карток Монобанку (рисунок 3.11).

Рис. 3.11 Опції валютних карток

57

3.5. Зміни в інтерфейсі

Так як з’явився новий функціонал (мультибанкінку), була додана
опціональність при створенні картки (рисунок 3.12).

Рис. 3.12. Опціональність

Також була створена інструкція для користувачів Монобанку (рисунок
3.13):

Рис. 3.13. Інструкція використання

58

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

59

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

- проаналізовано недоліки використання системи приват24.
- створено математичну модель виконуваних процесів.
- розроблено власний додаток усунувши знайдені недоліки.
- розроблено зручний інтерфейс для користувачів.
- налагоджено автоматизований зв’язок з банківською
системою для отримання даних.
- створено гнучку систему сповіщень.
Результатом роботи став сучасний web-додаток з технічної та
функціональної точки зору. Backend був розроблений відповідно до
сучасних тенденцій та практик. Незважаючи на давність впровадження
принципів реляційних БД, вони є значно надійнішими за сучасні аналоги
NoSql (в рамках задач кваліфікаційної роботи магістра роботи).
Перевірено на практиці переваги та недоліки роботи з API.
Зокрема, виявлена проблема API-Приватбанку. Відсутність системи
callback, яка могла б значно оптимізувати використання ресурсів серверу
та дозволила б реагувати додатку на зміни швидше. Головною ж
проблемою є обмеження на кількість одночасно виконуваних запитів, що
залишило можливості застосувати асинхронний підхід.
Вищеперераховані недоліки позбавляють можливості оптимально
масштабувати проект.
60

Використані сучасні frontend-бібліотеки для відображення
необхідних даних(графіки, таблиці, фільтри).
Неодноразово застосовано підхід з використанням технології Ajax
там, де це доречно з міркувань оптимізації чи userfriendly-інтерфейсу.
Проаналізовано переваги використаного framework-у. Робота з БД
за допомогою міграцій, посіву та моделей дозволяє організувати
структуру через інтерфейс мови програмування та суттєво пришвидшує
процес розробки. Також фреймворк яскраво демонструє використання
архітектурного щаблону – MVC. Веб-фреймворк Laravel задає досить
високу планку своїми механізмами для роботи з регулярними процесами
та чергами.
Робота має потенціал для масового впровадження в галузі
комерційних проектів, які можуть собі дозволити нести юридичну
відповідальність за конфіденційність інформації своїх клієнтів.
Сумісно з виконуваною роботою було розроблено бібліотеку для
веб-фреймворку laravel для відправлення фатальних помилок в telegram
та NoSql БД (mongoDB).

61

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ
1. Бутинець Ф. Ф. Бухгалтерський облік у зарубіжних країнах : навч.
посіб. – Житомир : ПП «Рута», 2019. – 512 с.
2. Кузьмін О. Є., Мельник О. Г. Інформаційні системи і технології в
управлінні організаціями : навч. посіб. – Львів : Львівська
політехніка, 2018. – 416 с.
3. Ковалюк О. М. Фінансовий контроль: теорія та практика : навч.
посіб. – Київ : Знання, 2020. – 378 с.
4. Легенчук С. Ф. Автоматизовані інформаційні системи
бухгалтерського обліку : навч. посіб. – Київ : КНЕУ, 2017. – 284 с.
5. Бондар М. І., Савченко В. Ф. Фінансовий моніторинг та протидія
легалізації доходів : монографія. – Київ : Центр учбової літератури,
2021. – 360 с.
6. Laudon K. C., Laudon J. P. Management Information Systems:
Managing the Digital Firm. – 16th ed. – New York : Pearson, 2020. –
640 p.
7. Hall J. A. Accounting Information Systems. – 10th ed. – Boston :
Cengage Learning, 2021. – 816 p.
8. Romney M. B., Steinbart P. J. Accounting Information Systems. – 15th
ed. – London : Pearson Education, 2021. – 736 p.
9. Пономаренко В. С., Мінухін С. В. Інформаційні системи в
економіці : підручник. – Харків : ХНЕУ ім. С. Кузнеця, 2019. – 494
с.
10. Закон України «Про бухгалтерський облік та фінансову звітність в
Україні» : чинне законодавство станом на 2024 р.
11. Закон України «Про запобігання та протидію легалізації
(відмиванню) доходів» : чинне законодавство.
12. ISO/IEC 27001:2022 Information security management systems –
Requirements.
62

13. Національне положення (стандарт) бухгалтерського обліку 1
14. «Загальні вимоги до фінансової звітності».
15. Вовчак О. Д. Фінансові інформаційні системи : навч. посіб. – Київ
: КНЕУ, 2018. – 312 с.
16. Turban E., Volonino L. Information Technology for Management. –
12th ed. – Hoboken : Wiley, 2022. – 480 p.
17. Scott Konishi, Alan Yuille, James Coughlin, and Song Chun Zhu,
”Statistical edge detection: Learning and evaluating edge cues.” IEEE
Transactions on PAMI, 25(1):57–74, 2021.
18. William Freeman and Edward Adelson, ”The design and use of
steerable filters.” IEEE Transactions on PAMI, 13:891–906, 2023.
19. David Martin, Charless Fowlkes, and Jitendra Malik, ”Learning to
detect natural image boundaries using local brightness, color, and
texture cues.” IEEE Transactions on PAMI, 26(5):530–549, 2019.
20. R. Deriche, Using Canny's criteria to derive a recursively implemented
optimal edge detector, Int. J. Computer Vision, Vol. 1, pp. 167–187,
April 2020.
21. Документація Composer https://getcomposer.org/doc/
22. Документація GIT https://git-scm.com/doc
23. Документація PHP https://www.php.net/docs.php
24. Документація основного framework-у використаного в роботі
https://laravel.com/docs/5.8
25. Статті по проектуванню БД з https://ruhighload.com/
26. Telegram API https://core.telegram.org/methods
27. Privat API https://api.privatbank.ua/#p24/visa
28. Документація Jquery https://api.jquery.com/
29. Документація Ubuntu https://docs.ubuntu.com/
63

30. Документація Apache https://httpd.apache.org/
31. Бібліотека для побудови графіків https://www.chartjs.org/
32. Бібліотека для фільтру по датам https://bootstrap-
datepicker.readthedocs.io/en/latest/
1. Бібліотека для таблиці https://datatables.net/
2. Cron https://help.ubuntu.com/community/CronHowto
3. Supervisor http://supervisord.org/
64

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets