Факторинг BRD

Вступ

Контекст

Концепція факторингу, хоча й корисна для зменшення фінансового навантаження на малі та середні бізнеси, залишається в нашій країні великою мірою незвіданою та незрозумілою фінансовою послугою. Факторинг в нашій країні не просто є не автоматизованим, а не врегульованим законодавчо. Кредитори (підрядники), які потребують швидкої сплати інвойсу за наданий товар, змушені вручну шукати сервіси факторингу, звертатися до кожної компанії і порівнювати пропозиції, щоб визначити найвигідніші умови. Одночасно, факторингові компанії витрачають значні зусилля та ресурси на пошук бізнес-партнерів, часто звертаючись до суб'єктів, які не зацікавлені у факторингових послугах. Цей застарілий, ручний підхід до факторингових транзакцій неефективний та непрозорий.

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

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

Останньою проблемою є відсутність регулювання з боку держави, хоча НБУ і заклав розвиток факторингу в план на 2025 рік. 

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

Впровадивши факторинг згідно з цінностями нашої компанії, ми сприятимемо розвитку ефективного, безпечного та прозорого факторингу в Україні. 

Мета

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

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

Успіх цього проекту на етапі MVP визначається наступними пунктами:

1. Впровадження факторингу на щонайменше 3 майданчиках 
2. Активна участь щонайменше 3 організаторів
3. Активна участь щонайменше 3 факторингових компаній (банків)

Кінцевою метою є створення екосистеми факторингу, яка буде супроводжувати всі залучені сторони в процес етапу створення закупівлі і до моменту розрахування дебітора з фактором. З фінансосої точки зору ми очікуємо прибуток від 2 млн гривень додаткових надходжень за 2024 рік до 9 млн грн за 2026 рік. Цей стратегічний крок спрямований на перехід нашої бізнес-моделі до відновлюваного та необмеженого джерела доходу, забезпечуючи довгострокову життєздатність та прибутковість, ніж продаж вичерпних ресурсів. 

Обсяг

Основні функції, які будуть розроблені для MVP, включають:

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

Користувачі: 

Цільова аудиторія - середні бізнеси з обсягами угод від 150К до 1М та малі бізнеси з угодами між 20К та 150К. 

Виключення:

На етапі MVP будуть виключені наступні функціональності:

• Автоматизація підписів документів; інтеграція з сервісами на кшталт DocuSign розглядається для майбутніх поліпшень.
• Контактинг: моніторинг виконання умов контракту після отримання організатором коштів від факторингової компанії (розрахування дебітора з фактором). Попередньо - після завершення процедури створюється контрактинг на кшталт Execution в процедурі малої приватизації, де і буде відслідковуватись взаєморозрахунок між дебітором та фактором. 

Створення МВП дозволить нам створити базу для подальшого розвитку і покращення процедури факторингу згідно фідбеку реальних користувачів.

Бізнес-цілі

Бізнес-проблема

Перелік поточних проблем, з якими стикаються учасники факторингу:

1. Маленький та середній бізнес - отримує кошти надто довго, що призводить до того, що бізнесу бракує грошей в обороті, щоб комфортно продовжувати функціонувати. Боїться співпрацювати з державними замовниками, або з замовниками, які повільно платять, що призводить до зменшення кола потенційних джерел доходів, а також зменшує конкурентність (великий бізнес більш вирогідно візьметься за виконання замовлення від такого дебітора). Той бізнес, який обізнаний в понятті факторингу, стикається з проблемою пошуку надійної факторингової компанії, а також пошуку найкращої пропозиції. Це дуже часомісткий процес, який ніяк не автоматизований. Бізнеси вимушені шукати факторингові компанії в інтернеті, звертатися в ручному режимі до кожної, чекати ознайомлення факторів з документами, чекати від них відповіді, і тільки потім приймати рішення. Бізнес вимушений збирати ці пропозиції в ручному форматі, що не є зручно для нього. Ще одним чималим фактором є ризик натрапити на шахраїв, які насправді не мають лізенції, або нечесні компанії, які змінюють умови співпраці вже після підписання документів.
2. Факторингові компанії - для цих компаній великою проблемою є пошук зацікавлених бізнесів. Бізнес в Україні не обізнаний щодо факторингу, тому ринок надто малий. До того ж, факторингові компанії вимушені так само як і бізнес витрачати велику кількість ресурсів та часу для пошуку зацікавлених бізнесів, що включає в себе безуспішні спроби зв'язатися з бізнесами, які не зацікавлені у факторингу. Додатково проблемою для факторингових компаній є відсутність державного регулювання факторингу та єдиного реєстру факторингових транзакцій, що призводить до того, що бізнеси продають права за договором декілька разів різним факторам. 

Бізнес-можливість

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

Цінність для стейкхолдерів:

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

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

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

Цілі та завдання

• запуск MVP з першими укладеними угодами факторингу через функціонал продукту

• розробка платформи факторингу згідно з Business Requirements Document від IFC на стартовій базі державних закупівель

• запуск продукту і ринку

• розвиток функціоналу для приватного сектору

• розвиток і інтеграції з іншими сервісами: Держказначейство, ЕКА, е-контрактинг, страхування факторингу, інші реєстри

Зацікавлені Сторони

Основні стейкхолдери

1. Бізнес
2. Майданчики
3. Факторингові компанії
4. АТ "Прозорро.Продажі"
5. Держава
6. IFC - консультант-адвокат

Ролі та Відповідальності 

1. IT Grigoriy Legenchenko
2. Product oleksandr akulenko PO Andrii Salii
3. Фінанси / Finance
4. Donors Coordination Oleksii Davydenko
5. GR від GR офісу Market Owner Oleksiy Khyzhniakov - координація з зовнішніми стейкхолдерами та партнерами
6. Юрист / Legal
7. PR
8. International Cooperation Oleksii Opanasenko

Вимоги до проекту

Функціональні вимоги

1. На стороні майданчику:
   1. Реєстрація та управління профілем організатора.
   2. Реєстрація та управління профілем факторингової компанії. 
   3. Процес верифікації факторингових компаній.
   4. Фактор повинен мати змогу переглянути приватні документи процедури факторингу.
   5. Майданчик має верифікувати кожен бід фактора.

2. Створення процедури факторингу: організатори можуть створити нову процедуру факторингу.

3. Редагування процедури факторингу: організатори можуть редагувати процедуру факторингу. 
4. Організатори можуть завантажувати документи до процедури факторингу (приватні):
   1. Анкета кредитора
   2. Фінансова звітність: річна/квартальна на останню звітну дату та за аналогічний період попереднього року, з відміткою повноважених органів Державного комітету статистики України про прийняття звітності
   3. Оборотно-сальдові відомості 361 та 631 рахунків за останні 6 місяців
   4. Картка 361 рахунку Дебітора за останні 6 місяців
   5. Договори поставок з Дебіторами, що передаються на факторинг
5. Факторингові компанії можуть створювати біди, які містять цінові та нецінові критерії.
6. Факторингові компанії можуть редагувати біди.
7. Факторингові компанії можуть деактивувати біди. 
8. Факторингові компанії можуть активувати біди. 
9. Організатор може обрати найкращу пропозицію.
10. Організатор може відхилити пропозицію. 
11. Організатор може дискваліфікувати учасника (фактора).
12. Організатор може завантажити протокол аукціону. 
13. Організатор може завантажити документи: 
    1. підписану дебітором  ДУ до договору закупівлі/сповіщення про переуступку договору
    2. акт прийому/передачі (документ, що підтверджує передачу товару чи надання послуг)
    3. Підтвердження умов оплати
    4. Підтвердження оплати винагороди майданчика 
    5. Договір факторингу
14. Факторингова компанія підтверджує винагороду організатора.
15. Організатор завершує процедуру факторинга.

Нефункціональні вимоги

1. Система має швидко віддавати запити користувачів на надання інформації. 
2. Очікувана максимальна кількість процедур одночасно - до 1000 (скоріше за все менше)
3. Очікувана максимальна кількість учасників в 1му аукціоні - до 100
4. Очікувана середня кількість учасників в 1му аукціоні - 4 учасники
5. Дані системи мають бути захищені згідно поточних протоколів захисту. 
6. Процедура має бути розроблена з урахуванням обмежень та вимог закону України (законопроект по факторингу знаходиться в розробці). 
7. Система має анонімізувати КІ кредитора та дебітора в документах, які надаються організатором при створенні процедури. Тільки у прекваліфікованих учасників має бути змога передивитися документи без анонімізації. 
8. Очікується аптайм системи 99.9% часу.  
9. В разі виявлення критичних багів в процедурі, необхідно в терміновому порядку випустити оновлення для виправлення помилки. 
10. Має бути реалізована інтеграція з наступними сервісами: Прозорро (на етапі пілоту), на майбутнє - сервіс документообігу, банківські системи. 
11. Локація основних користувачів системи - Україна.

Схема процесу та use cases

Опис операційного процесу (верхньорівнево):

Учасники

Учасниками операційного процесу є:

Дебітор - замовник закупівлі на платформі Прозорро. 

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

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

Фактор (учасник) - факторингова компанія (найчастіше - банк), розміщує пропозиції по викупу права вимоги за договором. Має ліцензію на здійснення факторингової діяльності.

Період поза системою

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

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

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

Прийняття заяв на участь (5 календарних днів)

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

1. Зареєструватися на майданчику. 
2. Надати документи (включаючи ліцензію на надання послуг факторингу) для проходження прекваліфікації. 
1. Майданчик має перевірити надані документи та прекваліфікувати учасника. 
   

На цьому етапі починається взаємодія з майданчиками та ЦБД Прозорро.Продажі. Кредитор, який є організатором в нашій системі, виконує наступні дії:

1. Обирає акредитований нами майданчик
2. Реєструється на обраному майданчику
3. Створює чернетку оголошення на майданчику, завантажує документи
1. поля заповнюються вручну
2. за бажанням майданчик може надати змогу копіювати поля з відповідної процедури закупівлі
4. Публікує оголошення
1. На цьому етапі майданчик має відправити запит на створення процедури в ЦБД. Тоді процедура з’явиться на всіх акредитованих майданчиках. 
2. може бути одне активне оголошення факторингу в нетермінальному статусі на одну процедуру закупівлі
5. Оголошення стає доступним для перегляду будь-якому відвідувачу майданчика, або спостерігачу. Проте для того, щоб переглянути документи кредитора й дебітора, необхідно бути прекваліфікованим фактором (учасником).
6. Якщо факторингову компанію зацікавило оголошення, вона має можливість створити пропозицію. Пропозиція має в собі містити як цінову пропозицію у відсотках, так і нецінову пропозицію по певних умовах факторингу.
   ❗Поки не буде закінчено цей період, ані ЦБД, ані організатор, ані спостерігач, не мають доступу до кількості та змісту пропозицій.

Додаткові можливості: 

1. Організатор може скасувати процедуру 
2. Організатор може редагувати процедуру
3. Учасник може редагувати пропозицію 
4. Учасник може деактивувати пропозицію 
5. Учасник може створити нову пропозицію після деактивації

Очікується опублікування протоколу (до 6 робочих днів)

На цьому етапі розкриваються пропозиції учасників, і всі заяви, які подали учасники стають доступні для перегляду спостерігачам і Організатору.

1. Організатор переглядає всі пропозиції, і обирає найкращу пропозицію. 
2. Після того, як організатор обере найкращу для себе пропозицію, має відбутися підписання протоколу аукціону між організатором та учасником. 
3. Організатор має завантажити протокол в оголошення. 

Додаткові можливості:

1. Організатор може скасувати процедуру за наявності підтверджуючих документів.
2. Організатор може відхилити пропозицію.

Очікується підписання договору (до 20 календарних днів) 

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

1. Сповіщення про переуступку договору
2. Акта прийому-передачі
3. Підтвердження умов та строків оплати
4. Договору факторингу

Підписання документів відбувається поза системою. 

1. Як тільки організатор має всі підписані документи, він має завантажити їх в процедуру. 
2. Виконуються взаєморозрахунок між учасником та організатором. Цей процес відбувається поза системою.
3. Далі факторингова компанія (учасник) має підтвердити надсилання коштів організатору (не обов’язкова дія).
4. Факторингова компанія має підтвердити сплату винагороди майданчика
5. Як тільки організатор отримує кошти, він має завершити процедуру. 
1. завершення процедури відбувається після підтвердження організатора отримання коштів від фактора

Додаткові можливості:

1. Організатор може скасувати процедуру за наявності підтверджуючих документів.
2. Організатор може дискваліфікувати учасника за наявності підтверджуючих документів.

Період після передачі прав за договором

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

Flowchart операційного процесу: 

Факторинг Flowchart

Timeline процедури факторингу 

Факторинг Timeline

BPMN операційного процесу (детализовано):

Факторинг BPMN Diagram - WIP (detalization)

Use cases

Use case 1. Реєстрація організатора на майданчику

Актори: майданчик, організатор

Флоу:

1. Організатор заходить на майданчик
2. Організатор надає свою пошту та пароль
3. Організатор створює свій профіль
4. Організатор підтверджує електрону пошту
5. Оргазінатор заходить в акаунт

Альтернативні сценарії: 

1. Організатор вказує неправильну пошту, що викликає помилку
2. Оргазінатор вказує надто легкий пароль, що не дозволяє йому створити акаунт

Use case 2. Редагування акаунту організатора

Актори: майданчик, організатор

Флоу:

1. Організатор заходить на майданчик
2. Організатор заходить в свій акаунт
3. Організатор заповнює дані профілю 
4. Оргазінатор зберігає внесені зміни
5. Зміни збережено для подального використання в процедурах

Альтернативні сценарії:

1. Зміни не збережено через помилки валідації введених організатором даних

Use case 3. Реєстрація факторингової компанії на майданчику

Актори: майданчик, факторингова компанія

Флоу:

1. Факторингова компанія заходить на майданчик
2. Факторингова компанія надає свою пошту та пароль
3. Факторингова компанія створює свій профіль
4. Факторингова компанія підтверджує електрону пошту
5. Факторингова компанія заходить в акаунт

Альтернативні сценарії: 

1. Факторингова компанія вказує неправильну пошту, що викликає помилку
2. Факторингова компанія вказує надто легкий пароль, що не дозволяє йому створити акаунт

Use case 4. Редагування акаунту факторингової компанії

Актори: майданчик, факторингова компанія

Флоу:

1. Факторингова компанія заходить на майданчик
2. Факторингова компанія заходить в свій акаунт
3. Факторингова компанія заповнює дані профілю 
4. Факторингова компанія зберігає внесені зміни
5. Зміни збережено для подального використання в процедурах

Альтернативні сценарії:

1. Зміни не збережено через помилки валідації введених організатором даних

Use case 5. Прекваліфікація акаунту факторингової компанії

Актори: майданчик, факторингова компанія

Флоу:

1. Факторингова компанія заходить в свій акаунт
2. Факторингова компанія завантажує документи для прекваліфікації 
   1. Ліцензію
3. Майданчик перевіряє завантажені документи
4. Майданчик прекваліфікує факторингову компанію 

Аьтернативні сценарії: 

1. Майданчик не кваліфікує факторингову компанію через розбіжності в документах

Use case 6. Перегляд документів процедури факторингу факторингової компанії

Актори: майданчик, факторингова компанія, ЦБД

Флоу: 

1. Прекваліфікована факторингова компанія входить в свій акаунт
2. Переходить на сторінку процедури факторингу на майданчику
3. Має змогу переглянути документи кредитора та дебітора процедури факторингу (пропозиція - щоб організатор завантажував документи як приватні, тоді майданчик зможе зі своїм токеном діставати документи процедури та відправляти їх листом прекваліфікованому учаснику. Як по іншому їх показувати прямо на сайті майданчика не знаємо). 

Аьтернативні сценарії: 

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

Use case 7. Організатор створює чернетку процедури факторингу

Актори: майданчик, організатор

Флоу: 

1. Організатор заходить в свій акаунт на майданчику
2. Організатор створює нову процедуру
3. Організатор заповнює обов'язкові поля
4. Немає інших процедур факторингу по закупівлі на Прозоро в нетермінальному статусі
5. Організатор зберігає чорнетку процедури

Альтернативні сценарії: 

1. Організатор намагається створити дубль процедури факторингу для закупівлі на Прозоро, на що отримує помилку
2. Організатор намагається зберегти чернетку процедури без обов'язкових полів, на що отримує помилку

Use case 8. Організатор активує процедуру факторингу

Актори: майданчик, організатор, ЦБД

Флоу: 

1. Організатор заходить в свій акаунт на майданчику
2. Організатор активує процедуру факторингу 
3. Немає інших процедур факторингу по закупівлі на Прозоро в нетермінальному статусі
4. Майданчик відправляє дані в ЦБД
5. Процедуру створено та активовано

Альтернативні сценарії: 

1. Організатор намагається створити дубль процедури факторингу для закупівлі на Прозоро, на що отримує помилку
2. Організатор намагається зберегти чернетку процедури без обов'язкових полів, на що отримує помилку

Use case 9. Фактор розміщує бід на майданчику

Актори: майданчик, фактор, ЦБД

Флоу: 

1. Фактор заходить в свій прекваліфікований акаунт на майданчику
2. Фактор передивляється процедури факторингу в статусах "прийняття заяв на участь", ознайомлюється з документами
3. Фактор створює бід (пропозицію з ціновими і неціновими критеріями) в статусі "чернетка"
4. Майданчик відправляє запит на створення біда на ЦБД
5. Майданчик в ручному режимі перевіряє бід та активує його
6. Успішно розміщено та активовано закриту цінову пропозицію

Альтернативні сценарії:

1. Майданчик не верифікує бід та деактивує його

Use case 10. Організатор редагує активовану процедуру факторингу

Актори: майданчик, організатор, ЦБД, фактор

Флоу:

1. Організатор логіниться в свій акаунт
2. Організатор редагує процедуру в статусі "прийняття заяв на участь" та зберігає зміни
3. Немає інших процедур факторингу по закупівлі на Прозоро в нетермінальному статусі
4. Майданчик відправляє запит на оновлення процедури в ЦБД
5. ЦБД оновлює процедуру
6. ЦБД деактивує всі активні біди
7. Майданчик повідомляє факторів про деактивацію бідів

Альтернативні сценарії:

1. Якщо організатор намагається вказати ID закупівлі на прозоро, яка вже має інші процедури факторингу в нетермінальному статусі, то отримає помилку
2. Якщо біди в статусах "деактивовано", "чернетка", "видалено", то статус біда не змінюється

Use case 11. Фактор редагує бід

Актори: майданчик, фактор, ЦБД

Флоу: 

1. Фактор логіниться в свій акаунт на майданчику
2. Фактор редагує бід 
3. Майданчик відправляє нові дані в ЦБД 

Альтернативні сцеранії:

1. Фактор не може зберегти нові дані через помилку валідації

Use case 12. Фактор деактивує бід

Актори: майданчик, фактор, ЦБД

Флоу: 

1. Фактор логіниться в свій акаунт на майданчику
2. Фактор деактивує бід
3. Майданчик відправляє нові дані в ЦБД 

Use case 13. Фактор активує бід

Актори: майданчик, фактор, ЦБД

Флоу: 

1. Фактор логіниться в свій акаунт на майданчику
2. Фактор активує бід в статусі "деактивовано"
3. Майданчик відправляє нові дані в ЦБД

Альтернативні сценарії:

1. Фактор намагається активувати бід в статусі "видалено", на що отримує помилку

Use case 14. Організатор обирає найкращу пропозицію 

Актори: організатор, майданчик, ЦБД, фактор

Флоу: 

1. Проходить час подання заяв на участь
2. На стороні ЦБД створюються аварди (фінальні пропозиції)
3. Майданчик відображає організатору наявні пропозиції
4. Організатор ознайомлюється з пропозиціями
5. Організатор обирає найкращу пропозицію
6. Всі інші пропозиції від інших учасників набувають статусу "неактивно"

Альтернативні сценарії:

1. Не було жодної пропозиції від учасників, тоді процедура набуває статусу "неуспішно"

Use case 15. Організатор відхиляє пропозицію

Актори: організатор, майданчик, ЦБД, фактор

Флоу: 

1. Проходить час подання заяв на участь
2. На стороні ЦБД створюються аварди (фінальні пропозиції)
3. Майданчик відображає організатору наявні пропозиції
4. Організатор ознайомлюється з пропозиціями
5. Організатор відхиляє нецікаві пропозиції, вони набувають статусу "відхилено"

Use case 15. Організатор дискваліфікує учасника

Актори: організатор, майданчик, ЦБД, фактор

Флоу: 

1. Проходить час подання заяв на участь
2. На стороні ЦБД створюються аварди (фінальні пропозиції)
3. Майданчик відображає організатору наявні пропозиції
4. Організатор ознайомлюється з пропозиціями
5. Організатор обирає найкращу пропозицію
6. Всі інші пропозиції від інших учасників набувають статусу "неактивно"
7. Організатор з певних причин дискваліфікує обраного учасника
8. Пропозиція учасника набуває статусу "дискваліфіковано" 

Use case 16. Організатор завантажує протокол

Актори: організатор, майданчик, ЦБД, фактор

Флоу:

1. Процедура факторингу знаходиться в статусі "очікується підписання протоколу"
2. ЦБД генерує протокол на основі наявних даних
3. Організатор завантажує протокол
4. Організатор підписує протокол, відправляє його фактору
5. Фактор підписує протокол, відправляє його організатору
6. Організатор завантажує підписаний протокол до процедури

Use case 17. Організатор завантажує документи 

Актори: організатор, майданчик, ЦБД, дебітор, фактор

Флоу:

1. Процедура факторингу знаходиться в статусі "очікується підписання документів"
2. Організатор надає дебітору документи на підпис: 
   1. підписану дебітором  ДУ до договору закупівлі/сповіщення про переуступку договору
   2. акт прийому/передачі (документ, що підтверджує передачу товару чи надання послуг)
   3. Підтвердження умов оплати
   4. Підтвердження оплати винагороди майданчика 
   5. Договір факторингу
3. Дебітор підписує надані дебітором документи, відправляє їх назад організатору
4. Організатор завантажує підписані документи в процедуру факторингу

Структура даних

Вхідні дані (для створення процедури)

}

Зовнішні та внутрішні інтерфейси

Портал

Необхідно буде промапити об'єкт процедури факторингу для коректного відображення на порталі. 

На порталі процедури факторингу мають відображатися разом зі всіма процедурами:

1. В списку всіх процедур на сторінці пошуку
2. Можливість передивитись обрану процедуру факторингу на порталі. Відображення процедури буде максимально схожим на відображення процедури SSW.

Пошук на порталі має співпрацювати з процедурами факторингу. Має бути можливість: 

1. Шукати процедури факторингу по наявних фільтрах
2. Сортувати процедури фаткорингу по наявних опціях сортування

Панель адміністратора

В панелі адміністратора мають бути наступні можливі дії з процедурою факторингу: 

1. Змінити власника процедури
2. Змінити власника біда
3. Додати ДІ до процедури факторингу
4. Редагувати ДІ, додану до процедури факторингу

BI

В BI процедури факторингу мають відображатись з усіма процедурами:

1. Процедури мають фільтруватись згідно наявних фільтрів
2. Додати факторинг в список процедур для фільтрації
3. Додати можливість фільтрувати процедури по неціновим критеріям

Інтеграції 

1. Інтеграція з Прозорро. В рамках цієї інтеграції ми маємо:
   1. Додати в нашу процедуру ідентифікатор закупівлі на порталі Прозорро.
   2. По цьому ідентифікатору необхідно валідувати кількість активних процедур в ЦБД по кожній закупівлі. Одночасно може існувати тільки одна процедура в активному статусі на одну закупівлю.
   3. Валідувати об'єкти закупівлі на порталі Прозорро за їх класифікатором CAV: кількість об'єктів закупівлі має співпадати з кількістю об'єктів в процедурі ЦБД, а також їх класифікатори об'єктів на порталі Прозорро та ЦБД мають співпадати.
2. Інтеграція з сервісами документообігу - не на етапі пілоту. Задача полягає в тому, щоб дозволити учасникам аукціону підписувати документи в електронному форматі. На майбутнє необхідно буде продумати механізм інтеграції, які дані плануємо зберігати в ЦБД, де плануємо зберігати ті дані. 
3. Інтеграція з системами банку - не на етапі пілоту. Поки триває обговорення, можливо ці інтеграції буде виконано на стороні майданчику, можливо будемо робити на стороні ЦБД. 

Acceptance criteria 

Визначення критеріїв

1. Процедура факторингу повністю функціональна і протестована, запущена вчасно, всі необхідні функції реалізовані згідно технічного опису.
2. Процедура факторингу впроваджена на щонайменше 3 майданчиках, реалізовані всі необхідні для МВП функціональності. 
3. Активно залучені користувачі: кредитори та факторингові компанії, щонайменше 3 бізнеси та 3 факторингові компанії, які здійснюють факторингові операції на майданчиках. 
4. Фінансовий успіх: факторингові операції генерують дохід від комісій для майданчиків та нашої компанії. Досягнення   2 млн гривень доходу до кінця 2024 року для нашої компанії. 

5. Успішне проходження періоду пілоту та збору фідбеку від зацікавлених осіб (3 місяці), після чого вихід на комерційний ринок. 

Тестування та валідація

TBD

Часовий план та основні етапи

План та строки виконання основних етапів проєкту доступні за посиланням: План факторинг. 

Swot? Risk assessment?