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

Глоссарій

Замовник (Дебітор)- замовник товарів/послуг

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

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

Нормативні засади

Наразі нормативні документи знаходяться в розробці НБУ. З поточних проблем - організатори продають декілька разів права за вимогами по одному договору. 

PRD

Основні змінні

Схема полів процедури

Timeline процедури

Періоди процедури

Періоди авардів

Періоди contracts

Періоди execution(виконання умов)

Статуси процедури:

Логіка зміни статусів процедури:

1. В момент публікації оголошення процедури ЦБД, процедура набуває статусу active_tendering.
2. Після завершення періоду tenderPeriod і наявності хоча б 1го bid в статусі active процедура переходить в статус active_awarded, в іншому випадку процедура переходить в статус unsuccessful.
3. Після переведення Постачальником contract в статус signed процедура переходить в статус pending_payment
4. Після підтвердження  оплати від оператора, Постачальник переводить contract в статус active та має можливість перевести процедуру в термінальний статус complete
5. Процедура може бути скасована(статус процдеури  = cancelled) Постачальником в будь-який момент до набуття процедурою термінального статусів: complete/unsuccessful
6. Процедура може набути статус Аукціон не відбувся(unsuccessful) в разі:
   1. відсутні валідні bid'и в момент завершення періоду подання пропозицій (tenderPeriod). Статуси процедури: active_tendering
   2. при дискваліфікації учасника, якщо учасник, що очікує (award status == pending_waiting) відсутній. Статуси процедури: pending_payment/active_awarded
7. Після набуття процедурою статусу complete проуедура може перейти на термінальні статуси:
   1. conditions_met - автоматичний термінальний статус після підтвердження отримання грошей за виконання умов за Договором Фактором та Оператором
   2. conditions_not_met - термінальний статус в який Постачальник може перевести процедуру, в разі якщо Замовник не виконав умови Договору

Статуси заяви на участь (bid)

Логіка зміни статусів заяви на участь:

1. При публікації заявки на участь форумується "Чернетка заяви" bid у статусі draft.
2. При надсиланні запиту на активацію "Чернетка заяви" bid переходить у статус active.
3. При внесенні змін Постачальником в поля Процедури (до завершення періоду процедури rectificationPeriod), bid переходить в статус inactive. Після чого учасник може знов Активувати свою заяву(bid переходить у статус active) або Видалити свою заяву(bid переходить у статус deleted)
4. Учасник може Видалити заяву (до завершення періоду процедури tenderPeriod) надіславши запит на скасування заяви Учасником зі статусів:
   1. draft
   2. active
   3. inactive

Статуси об’єкту кваліфікації (award)

Логіка обрання переможця наступна:

1. По завершенню періоду подання заяв відразу розпочинається період кваліфікації (без аукціону).
2. На кожен bid в статусі active має створитися award в статусі pending_waiting. Якщо бідів декілька, в такому випадку формується декілька авардів в статусі pending_waiting. 
   
3. Постачальник передивляється кожну пропозицію одночасно та має можливість зробити наступні дії:
   1. Відхилити пропозицію. В такому випадку статус пропозиції змінюється на discarded. Статус є термінальним.
      1. В разі відхилення всіх заявок постачальником процедура набуває стутусу unsuccessful. 
   2. Обрати переможця. В такому випадку статус обраної пропозиції змінюється на active. Одночасно може бути тільки один авард в статусі active (В разі спроби переведення в статус active другої пропозиції (без дискваліфікації попередньої) виводиться помилка). При цьому статус інших пропозицій залишається pending_waiting. 
   3. Для продовження кваліфікації Замовнику/Постачальнику(в разі відстуності Замовника в системі) необхідно завантажити в award зі статусом active документ purchaseContractEndorsement та ввести значення activationConfirmation=true
4. Статус пропозицій змінюється на cancelled:
   1. автоматично - у момент завершення процедури статус процедури (complete/cancelled) для пропозицій у статусі pending_waiting 
   2. ручна дія учасника - в разі відмови від очікування учасником у статусі pending_waiting до моменту завершення процедури статус процедури (complete/cancelled)
5. У випадку, якщо Постачальник дискваліфікує попередньо обрану пропозицію, в такому випадку організатор може обрати будь-яку іншу пропозицію в статусі pending_waiting та розпочати процес кваліфікації з другим обраним переможцем. 
6. Якщо Постачальник попередньо відхилив всі пропозиції, в такому випадку у разі дискваліфікації єдиного обраного організатором переможця процедура набуває статусу unsuccessful. 

Статуси контрактування (contract)

Логіка зміни статусів contract:

1. Після завантаження Замовником/Постачальником(в разі відстуності Замовника в системі) в award зі статусом active документ purchaseContractEndorsement та введення значення activationConfirmation=true, формується contract в статусі pending.
2. Постачальник завантажує Договір та Акт в поточний contract та Постачальник переводить contract в статус signed.
3. Постачальник підтверджує отримання оплати від Фактору (lotPaymentConfirmation = true) та переводить contract в статус active (Після процедуру можна перевести в статус complete).
4. У разі Дискваліфікації учасника award=active та статус contract =pending/signed/active → contract набуває статус cancelled, а award статус unsuccessful 
5. Після переведення процедури в статус complete Фактора не можна дискваліфікувати чи відмінити процедуру.

Статуси execution

Логіка зміни статусів execution:

1. Після переведення процедури в статус complete, створюється execution у статусі pending
2. Execution автоматично переходить в статус active після підтвердження Фактором оплати від Замовника contractPayment = true та підтвердження Оператором оплати від Фактору participationPayment = true
3. Фактор переводить execution в статус cancelled якщо Замовник не виконав умови Договору
4. Дискваліфікувати Фактора чи відмінити процедуру факторингу на еxecution не можна

Перелік документів (documents)

Наразі всі документи публікуються з типом privat, але треба закласти можливість дозволу публікації документів з типом public (Після прийняття бізнесового рішення). Документи що можуть бути завантажені в майбутньому з типом public позначені як privat/public

Вимоги до кабінетів користувачів 

Кабінет на стороні майданчика

Кабінет на стороні системи (Портал)

Адміністратор

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

BI 

1. Користувач має можливість отримувати дані по api для відображення агрегованих даних процедур Факторингу.

Спостерігач (не зареєстрований в системі користувач). 

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

1. Користувач бачить всі оголошені процедури
2. Користувач бачить всі документи додані до процедури 
3. Користувач бачить учасників, які подали свої заявки на Факторинг після завершення процедури.

Етапи процедури

Реєстрація користувачів в системі

Створення, редагування та публікація оголошення (TenderPeriod+RectificationPeriod)

Система має валідацію та приймає запит на:

1. Опублікування оглошення в разі:
   1. заповнення всіх обов'язкових полів та наявності обов'зкових документів
   2. відсутності процедур з таким самим SupplyСontractNumber для цього ж Постачальника в статусах процедури != unsuccessful, cancelled, execution_not_me

Передумови створення аукціону

Створення аукціону

Публікація оголошення

При публікації процедури на ЦБД має бути валідація, яка перевіряє, що одночасно існує тільки одна процедура факторингу на один номер договору(SupplyСontractNumber) для даного Постачальника не враховуючи процедури в статусі unsuccessful, cancelled або execution_not_met якщо знайдено процедуру з таким самим номером договору для даного Постачальника не враховуючи процедури в статусі unsuccessful або cancelled, повернути помилку "Факторинг за цим лотом вже було створено".

Перелік полів процедури, які необхідно вказати Постачальнику при публікації:

Обов'язковість полів перерахована в таблиці

1. Ідентифікатор попереднього аукціону (previousAuctionId)
2. Номер договору поставки (SupplyСontractNumber)
3. Інформація про Постачальника (sellingEntity):
1. Повна юридична назва організації або ПІБ (sellingEntity.name)
2. ЄДРПОУ/ІПН Постачальника (sellingEntity.identifier)
3. Адреса Постачальника  (sellingEntity.address)
4. Контактні дані Дебітора - (sellingEntity.contactPoint)
4. Інформація про Замовника:
1. Повна юридична назва ції або ПІБ (debitor.name)
2. ЄДРПОУ/ІПН Замовника (debitor.identifier)
3. Адреса Замовника (debitor.address)
4. Контактні дані Дебітора (debitor.contactPoint)
5. Назва процедури (title)
6. Опис лоту (description)
7. Банківські рахунки (bankAccounts)
8. Процедура з регресом (withRegression)
9. Класифікатор лот (items.classification)
10. Одиниця вимірювання (items.unit)
11. Об’єм/Кількість лоту (items.quantity)
12. Адреса розташування лоту (items.address)
13. Сума угоди за договором (value)
14. Дата поставки
15. Кількість днів на виконання платежу за договором (paymentTerms)
16. Перелік та вимоги до оформлення документів (x_documentRequirements)
17. Додаткові відомості (x_additionalInformation)
18. На фінальну суму нараховується ПДВ (valueAddedTaxCharged)
19. Лот виставляється (tenderAttempts)
20. Документи до процедури (documents)

Класифікатори

Основний:

• Обов’язковий — CAV

Додатковий:

• Відсутній

Документи при роботі з процедурою

Редагування оголошення

Перелік полів, які деактивують заяви на участь (bid status: active → inactive): 

• value
• documents
• valueAddedTaxCharged
• title
• description
• items
• x_additionalInformation
• x_documentRequirements
• paymentTerms
  
• previousAuctionId
• tenderAttempts
• sellingEntity
• bankAccounts
• withRegression

Поле SupplyСontractNumber редагувати не можна! 

Завантаження документів до оголошення / Заміна документів оголошення

Постачальник може завантажувати документи оголошення.

Завантаження відбувається за стандартним флоу

Заміна документів відбуваєтсья за стандартним флоу

Сповіщення/Нотифікація/Помилка/Дісклеймер

Період запитань (questionPeriod)

Схема - Задати запитання Перемалювати

Період відповідей (enquiryPeriod)

Схема - Надати відповідь Перемалювати

Період подання пропозицій (TenderPeriod)

Система має валідацію та приймає запит на:

1. Опублікування чернетки заявки на участь від Фактора з заповненим полем ЄДРПОУ
2. Опублікування активованої заявки на участь від Фактора в разі заповнення всіх обов'язкових полів та наявності обов'зкових документів
3. Зміни документів для певної заявки на участь від Фактора тільки в разі відповідності ключей
4. Опублікувати дві активовані звявки на участь від оного Фактора, якщо дві заявки з різними типами (bid.withRegression) = true та  (bid.withRegression) = false

Пошук аукціону для участі

Період подання пропозицій (особливості)

1. Подання заяви на участь здійснюється до початку періоду Кваліфікації
2. Створення чернетки біда можливо без документів, але обов'язково необхідно вказати ЄДРПОУ. 
3. Не має валідації на поле value (bid.value може не дорівнювати  procedure.value, оскільки банки будуть пропонувати меншу суму угоди, ніж ціна за договором). 
4. Наявна валидація на bidders identifier.scheme. Для створення заяви на участь ми маємо пропускати тільки UA-EDR, щоб унеможливити створення заяви на участь від фізичних осіб або ФОП
5. Фактор може вказати perks в bid. В подальшому поле perks автоматично переносяться в award та в contract. 
6. Наявна валідація на тип процедури withRegression та bid.withRegression :  
   1. Якщо тип процедури withRegression = false тоді Фактор може створити заявку тільки з типом (bid.withRegression)= false
   2. Якщо тип процедури withRegression = true тоді Фактор може створити заявку тільки з типом (bid.withRegression)= true
   3. Якщо тип процедури withRegression = notDefined тоді Фактор може створити:
      1. заявку тільки з типом (bid.withRegression) = false
      2. заявку тільки з типом (bid.withRegression) = true
      3. дві заявки з типами (bid.withRegression) = true та  (bid.withRegression) = false

Передумови створення заяви на участь

Створення заяви на участь

Публікація заяви на участь

Перелік полів bid, які повинні бути вказані при активації:

Поля повинні бути провалідовані непусті значення в полях:

1. bid.name
2. bid.identifier
   
3. bid.value
4. bid.bankAccounts
5. bid.perks
6. bid.withRegression
7. bid.documents

Документи при роботі з bid`ом 

Редагування заяви на участь

Активація заяви на участь

Скасування заяви на участь 

Інактивація заяви на участь

Причини інактивації заяв переходу active → inactive:

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

!!!Участь в кваліфікації доступна тільки для заяв в статусі acive.

Сповіщення/Нотифікація/Помилка/Дісклеймер

Період кваліфікації (qualificationPeriod)

Функціонал доступний у випадку початку періоду кваліфікації процедури qualificationPeriod.

Система має валідацію та приймає запит на:

1. зміну award status з pending_waiting на active, якщо в системі ще немає жодного award в статусі active
2. зміну award status з pending_waiting = discared тільки для award в статусі pending_waiting  та при заповненому полі discaredReason
3. зміну award status з pending_waiting = unsuccessful тільки для award в статусі active та при наявності документу з типом rejectionProtocol і заповненому полі terminationReason 
4. зміну award status з pending_waiting = cancelled тільки для award в статусі pending_waiting та при наявності документу з типом act
5. завантаження документу purchaseContractEndorsement та зміну значення activationConfirmation на true Постачальником, в разі якщо в системі немає користувача з роллю Замовник.

Вибір переможця (winnerSelectionPeriod)

Завантаження сповіщення про переуступку договору

Сповіщення про переуступку договору наразі не автогенерується, але треба закласти можливість

Наразі: якщо користувач підставить id процедури факторингу в сервіс протоколів, тоді користувач має отримати помилку 404. Тобто запити типу:

• https://procedure.prozorro.sale/api/protocol/[GFW.id]/download
• https://procedure.prozorro.sale/api/protocol/[GFW.id]/print
• https://procedure.prozorro.sale/api/protocol/[GFW.id]/doc

Мають відображати користувачеві помилку стандартну помилку: Procedure with auctionId [auctionId] not found. 

Відхилення заявки Фактора

Причити відхилення заявки Фактора:

Документи при роботі з award`ом

Сповіщення/Нотифікація/Помилка/Дісклеймер

Робота з договором (confirmationPeriod+signingPeriod)

Робота з контрактом розпочинається після того, як Замовник/Постачальник завантажили в систему документ purchaseContractEndorsement та поле activationConfirmation набуває значення true.

Система має валідацію та приймає запит на:

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

Перелік полів контракту, які необхідно вказати Постачальнику для його активації

1. Номер договору факторингу
2. Сума, яка була надана Фактором Постачальнику
3. Дата завершення виконання умов договору

Робота з contract`ом. Внесення даних договору 

Робота з contract`ом. Підтвердження договору

Документи при роботі з contract`ом

Сповіщення/Нотифікація/Помилка/Дісклеймер

Період оплати (paymentPeriod)

Період оплати розпочинається після того, як contract статус набуває значення signed. В цей період Фактор має перерахувати кошти Постачальнику, а Постачальник - підтвердити отримання коштів. Зміна значення lotPaymentConfirmation з false на true відбувається за допомогою окремого ендпоінта.

В разі підтвердження оплати Постачальником та Оператором статус contract зміниться з signed на active.

Внесення даних про оплату та її підтвердження

Сповіщення/Нотифікація/Помилка/Дісклеймер

Завершення процедури факторингу

Для зміни статус procedure з pending_paiment на complete система валідує чи набув статус contract = active якщо так, система може прийняти зміну статусу procedure з pending_paiment на complete

Сповіщення/Нотифікація/Помилка/Дісклеймер

Дискваліфікація переможця

Переведення status award з active на unsuccessful та status contract(в разі його наявності) з pending/signed/active на unsuccessful можливо до набуття status procedure = complete

Причини дискваліфікації переможця:

Період виконання умов (postPaymentPeriod)

Після набуття процедурою статусу complete, автоматично створюється об'єкт договору переуступки execution (для контролю виконання умов договору)

Система має валідацію та приймає запит на:

1. Зміну статусу процедури на conditions_not_met в разі надсилання запиту від Фактора і contractPayment !=true
2. Автоматичне переведення статусу процедури на conditions_met при contractPayment =true та participationPayment = true 

Запити api

Робота з bid

1. Редагування полів заяви на участь - PATCH /api/procedures/{procedure_id}/bids/{bid_id}?acc_token={bidder_token}
2. Редагування документів заяви на участь - PATCH /api/procedures/{procedure_id}/bids/{bid_id}documents/{doc_id}/?acc_token={bidder_token}
3. Скасування заяви на участь - PATCH /api/procedures/{procedure_id}/bids/{bid_id}/status?acc_token={bidder_token}
4. Активація заяви на участь - PATCH /api/procedures/{procedure_id}/bids/{bid_id}/status?acc_token={bidder_token}
5. Створення заяви на участь - POST ​/api​/procedures​/{procedure_id}​/bids

Робота з award 

1. Зміна статусу Award-у - PATCH /api/procedures/{procedure_id}/awards/{award_0_id}/status?acc_token={procedure_acc_token} 
2. Завантаження сповіщення про переуступку договору - 
3. Підтвердження сповіщення про переуступку договору - 

Робота з contract

1. Внесення даних договору - POST /api/procedures/{procedure_id}/contracts/{contract_0_id}/documents?acc_token={procedure_acc_token}
2. Підтвердження договору -  PATCH /api/procedures/{{procedure_id}}/contracts/{{contract_0_id}}?acc_token={{procedure_acc_token}} / PATCH /api/procedures/{{procedure_id}}/contracts/{{contract_0_id}}/status?acc_token={{procedure_acc_token}}

Робота з execution

1. Зміна статусу execution - 
2. Підтвердження оплати від Замовника Фактором
3. Підтвердження оплати від Фактора Оператором 

Для дискваліфікації

1. Завантаження rejectionProtocol or Act - POST /api/procedures/{procedure_id}/awards/{award_id}/documents?acc_token={procedure_acc_token}
2. Визначення terminationReason в Award-і -  PATCH /api/procedures/{procedure_id}/awards/{award_0_id}?acc_token={procedure_acc_token}
3. Зміна статусу Award-у на unsuccessful - PATCH /api/procedures/{procedure_id}/awards/{award_0_id}/status?acc_token={procedure_acc_token}

Для відхилення заявки

1. Визначення discaredReason в Award-і -  PATCH /api/procedures/{procedure_id}/awards/{award_0_id}?acc_token={procedure_acc_token}
2. Зміна статусу Award-у на discared- PATCH /api/procedures/{procedure_id}/awards/{award_0_id}/status?acc_token={procedure_acc_token} 

Тбалиця відповідностей ролей до статусів