Дебітор - замовник закупівлі на платформі Прозорро.
Кредитор - переможець закупівлі. Той, хто надає послугу / товар дебітору, а в подальшому продає право вимоги за договором факторинговій компанії. В системі Прозорро.Продажі є організатором.
Фактор - факторингова компанія (найчастіше - банк), розміщує пропозиції по викупу права вимоги за договором. Має ліцензію на здійснення факторингової діяльності. В системі Прозорро.Продажі є учасником.
Нормативні засади
Наразі нормативні документи знаходяться в розробці НБУ. З поточних проблем - організатори продають декілька разів права за вимогами по одному договору.
Timeline процедури
Періоди процедури
Технічна назва періоду
Бізнес назва періоду
Дата початку
Завершення
Результат завершення
Коментар
rectificationPeriod
Період редагування
Дата та час публікації процедури в ЦБД
за день до кінця tender period о 20:00
Редагування полів процедури та документів більше недоступне.
Робота з редагуванням полів та редагуванням документів завершується в цей період.
tenderPeriod
Період подання пропозицій
з базової (20:00)
Статус процедури змінюється на “Очікується підписання договору” (active_awarded). У випадку відсутності активних бідів статус процедури змінюється на "Неуспішно" (unsuccessful).
questionPeriod
Період запитань
з базової
Користувач більше не може задати запитання до аукціону
enquiryPeriod
Період відповідей
Організатор більше не може надіслати відповідь на запитання
qualificationPeriod
Період кваліфікаці
Дата та час завершення tenderPeriod, за умови наявності щонайменше 1 bid`а
25 к.д., не враховуючи день початку періоду
На рівні ЦБД: відсутній
На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду кваліфікації.
У випадку дискваліфікації переможця, організатор обирає наступного переможця серед авардів в статусі pending_waiting.
winnerSelectionPeriod
Період обрання переможця
Дата та час завершення tenderPeriod, за умови наявності щонайменше 1 bid`а
6 к.д., не враховуючи день початку періоду
На рівні ЦБД: відсутній
На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду обрання переможця.
Оскільки протоколів немає, то в цей період організатору необхідно обрати переможця, та вручну активувати його.
Періоди авардів
Технічна назва періоду
Бізнес назва періоду
Дата початку
Завершення
Результат завершення
Коментар
signingPeriod
Період підписання договору
Розпочинається окремо для кожного award в момент переходу зі статусу pending_waiting в active.
20 к.д., не враховуючи день початку періоду
На рівні ЦБД: відсутній
На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду підписання договору.
paymentPeriod
Період оплати
Розпочинається після переходу contract в статус singed
Розпочинається окремо для кожного award. При цьому award має бути в статусі active.
5 р.д., не враховуючи день початку періоду
На рівні ЦБД: відсутній
На рівні майданчика: за 24 години до завершення, надсилання повідомлення Організатору про завершення періоду оплати.
По завершенню періоду подання заяв відразу розпочинається період кваліфікації (без аукціону).
На кожен bid в статусі active має створитися award в статусі pending_waiting. Якщо бідів декілька, в такому випадку формується декілька авардів в статусі pending_waiting.
Організатор передивляється кожну пропозицію одночасно та має можливість зробити наступні дії:
Відхилити пропозицію. В такому випадку статус пропозиції змінюється на discarded. Статус є термінальним.
Обрати переможця. В такому випадку статус обраної пропозиції змінюється на active. Одночасно може бути тільки один авард в статусі active. При цьому статус інших пропозицій залишається pending_waiting.
Статус не обраних пропозицій змінюється на cancelled тільки у момент завершення процедури.
У випадку, якщо організатор дискваліфікує попередньо обрану пропозицію, в такому випадку організатор може обрати будь-яку іншу пропозицію в статусі pending_waiting та розпочати процес кваліфікації з другим обраним переможцем.
Якщо організатор попередньо відхилив всі пропозиції, в такому випадку у разі дискваліфікації єдиного обраного організатором переможця процедура набуває статусу unsuccessful.
Технічна назва статусу
Бізнес назва статусу
Перехід з
За умови
pending_waiting
Очікується рішення
момент створення award
створюється за умови початку періоду кваліфікації, для кожного учасника, що подав закриту пропозицію (bid)
active
Переможець. Очікується договір
pending_waiting
організатор підтверджує найкращу пропозицію
discarded
Пропозицію відхилено
pending_waiting
організатор відхилив пропозицію учасника
unsuccessful (термінальний статус)
Дискваліфіковано
active
в момент дискваліфікації учасника, що кваліфікується
cancelled (термінальний статус)
Учасник не став переможцем
pending_waiting
в момент успішного завершення процедури (переходу процедури в статус complete)
Функціонал користувачів
Ролі користувачів
Організатор - користувач, що створив оголошення процедури та отримав токен доступу для ролі Організатора.
Прекваліфікований учасник - Користувач, що подав заяву на участь в аукціоні (отримав id та токен доступу)
Переможець - Учасник для якого сформовано award в статусі active (якого обрав організатор як переможця)
Учасник, що очікує - Учасник для якого сформовано award в статусі pending_waiting
Спостерігач - Користувач, який може переглядати результати успішних аукціонів факторингу.
Документи
Всі документи процедури, біда, аварду, контракту мають бути private
Функціонал доступний Організатору
Публікація оголошення
Документи оголошення:
Анкета кредитора* -creditorApplication
Фінансова звітність: річна/квартальна, з відміткою Держкомстату - statutoryFinancialReport
Оборотно-сальдові відомості 361 та 631 рахунків за останні 6 місяців - turnoverBalanceReport
Картка 361 рахунку Дебітора за останні 6 місяців - debitorAccountCard
Договори поставок з Дебіторами* - factoringContractProforma
Всі документи вище мають бути повністю приховані і недоступні для перегляду спостерігачу. На ЦБД буде додано валідацію на можливість додавання тільки приватних документів.
Вимоги до відображення на інтерфейсі майданчика
На ЦБД реалізовано валідацію, що на один тендер закупівель (на один lot, в разі наявності в тендері лотів) одночасно існує тільки одна процедура факторингу в активному статусі active_tendering, active_awarded, pending_payment, complete.
Тобто, у Організатора не буде можливості створити "дубль" процедури по тій самій комбінації productEntity.id+productEntity.lotId закупівлі, або дві закупівлі з однаковим productEntity.id.
При публікації процедури, Організатору необхідно дати можливість вказати productEntity.humanId - це tenderId тендеру Закупівель. (productEntity.id, який є технічним ідентифікатором, необхідно заповнити автоматично (підтягнути id по повʼязаному tenderId). Відображати його організатору не обов'язково.
Для заповнення в процедурі productEntity.lotId, необхідно Організатору підтягнути і відобразити список lots із тендеру Закупівель, якщо вони є, і дати організатору обрати необхідний лот (доступний вибір тільки одного лоту із переліку).
Логіка відображення списку лотів залишається на розсуд майданчика.
В одному тендері закупівель може бути одночасно декілька лотів, і на кожен лот можна створювати окрему процедуру факторингу. Не повинно бути можливості обрати із тендеру закупівель декілька лотів для публікації процедури факторингу.
В тендері Закупівель lots можуть бути взагалі відсутні. Організатор відображає productEntity.humanId в форматі "UA-2020-09-22-000016-b". Необхідно знайти за цим humanId закупівлю, і відобразити всі лоти, які є в закупівлі (якщо вони є). Якщо є тільки один лот, треба автоматично проставити humanId лота в productEntity.lotId в форматі "9ee6ebbf2ad21ac0c5ad52b06e776fa4".
Перевірити, чи організатор є реально переможцем лоту або закупівлі по ЄДРПОУ або РНОКПП.
При створенні процедури факторингу на закупівлю такого типу, організатор має вказати productEntity.humanId. За цим айді майданчик має знайти на прозорро процедуру, та автоматино заповнити productEntity.id.
Оскількі лотів в цій процедурі немає, поле productEntity.lotId лишається порожнім.
Далі необхідно валідувати, що процедуру факторингу створює переможець тендеру. Для цього можна використовувати awards.0.suppliers, порівнявши чи збігається значення хоча б одного awards.0.suppliers.0.identifier.id з sellingEntity.identifier.id.
Далі необхідно попередньо заповнити items, але у організатора повинна бути можливість редагувати їх. items знаходяться на верхньому рівні, відсутнє relatedLot, тому items заповнити автоматично. Необхідно перенести всі items, які є в тендері.
Також необхідно попередньо заповнити з можливістю редагування поля productEntity.initialValue, productEntity.finalValue.
При створенні процедури факторингу на закупівлю такого типу, організатор має вказати productEntity.humanId. За цим айді майданчик має знайти на прозорро процедуру, та автоматино заповнити productEntity.id.
Далі майданчик має відобразити організатору можливість обрати один з lots для створення процедури факторингу. Якщо лот в закупівлі тільки один, заповнити productEntity.lotId автоматично.
Якщо в тендері є хоча б один лот, майданчик має зробити заповнення lotId (або вибір лоту, якщо їх декілька) обовʼязковим. На стороні майданчика не має бути можливості створити процедуру факторингу без lotId, якщо lotId є в тендері.
Процедура факторингу створюється завжди тільки на один лот.
Далі необхідно валідувати, що процедуру факторингу створює переможець лоту в тендері. Для цього можна використати awards.0.suppliers, порівнявши чи збігається значення хоча б одного awards.0.suppliers.0.identifier.id з sellingEntity.identifier.id. Але в даному випадку необхідно буде також провалідувати значення awards.0.lotId, він має відповідати productEntity.lotId, на який організатор створює процедуру факторингу.
Далі треба попередньо заповнити items, необхідно взяти значення relatedLot в кожному item. Дане поле відповідає productEntity.lotId. У організатора має бути можливість редагувати items.
В процедуру факторингу необхідно перенести всі items, які відносяться до лоту, на який організатор створює процедуру факторингу.
Також необхідно попередньо заповнити з можливістю редагування поля productEntity.initialValue, productEntity.finalValue.
Таблиця відповідності даних
Prozorro.sale
Prozorro
productEntity.id
id
productEntity.humanId
tenderId
productEntity.lotId
lots.0.id (лотів може бути декілька, брати id з того лота, який обирає організатор при створенні процедури факторингу
productEntity.debitor.name
procuringEntity.name
productEntity.debitor.identifier
procuringEntity.identifier
productEntity.debitor.address
procuringEntity.address
productEntity.debitor.contactPoint
procuringEntity.contactPoint
productEntity.debitor.representativeInfo
-
productEntity.items.id
-
productEntity.items.description
items.description
productEntity.items.classification
items.classification
productEntity.items.unit
items.unit
productEntity.items.quantity
items.quantity
productEntity.items.address
items.address
productEntity.initialValue (у разі відсутності lots)
value
productEntity.initialValue (у разі присутності lots)
lots.0.value (значення брати з того лота, на який створюється процедура факторингу)
productEntity.finalValue (у разі відсутності lots)
awards.0.value (необхідно брати значення з аварду переможця)
productEntity.finalValue (у разі присутності lots)
awards.0.value (значення брати з того аварду, де lotId збігається з productEntity.lotId. брати значення лише з аварду переможця)
ВИКЛЮЧЕННЯ Для анонімізованих закупок на прозорро не потрібно автоматично переносити дані.
В разі наявності в productEntity.lotId одного чи декількох items, необхідно вказати основний класифікатор кожного з айтемів. Вказаний на прозоро класифікатор збігається з класифікатором CAV в прозоро продажі, тому необхідно автоматично заповнити основний класифікатор.
Щодо документів, то документи мають бути завантажено тільки з _ds_scope = private. Замінювати це значення на public не можна.
По підтягуванню даних - необхідно реалізувати для зручності організатора автоматичний перенос даних. Для даних, які переносяться з закупівлі Прозорро було створено об'єкт productEntity. Зверніть увагу, що поле debitor є обовʼязковим.
Відображення списку процедур факторингу для організаторів
Для організатора необхідно відобразити список тільки його процедур факторингу в усіх статусах, тобто тільки ті процедури, який створив даний організатор.
При публікації процедури на ЦБД має бути валідація, яка перевіряє, що одночасно існує тільки одна процедура факторингу на один тендер або лот в нетермінальному статусі (крім complete).
Якщо процедура публікується з зазначенням productEntity.id ТА productEntity.lotId, ми маємо робити перевірку на комбінацію цих двох значень, і якщо знайдено процедуру з таким самим productEntity.id та productEntity.lotId в нетермінальному статусі (крім complete), повернути помилку "Факторинг за цим лотом вже було створено".
Якщо процедура публікується з зазначенням лише productEntity.id, необхідно зробити перевірку на наявність процедур в ЦБД з зазначеним productEntity.id, якщо такі процедури знайдено (як з productEntity.lotId, так і без), і статус знайдених процедур нетермінальний (крім complete), в такому випадку необхідно повернути помилку "Факторинг за цим лотом вже було створено".
Приклади комбінацій:
Публікую процедуру з productEntity.id1. Якщо знайдено співпадіння по productEntity.id1, і статус знайденої процедури != unsuccessful, cancelled, вертаємо помилку.
Якщо знайдено процедуру з productEntity.id1 та productEntity.lotId1, і статус знайденої процедури != unsuccessful, cancelled, вертаємо помилку.
Публікую процедуру з productEntity.id1 та productEntity.lotId1. Якщо знайдено співпадіння по productEntity.id1 (тобто така процедура є, але її було створено без лоту), і статус процедури != unsuccessful, cancelled, вертаємо помилку. В цьому кейсі і потрібна валідація майданчика на етапі створення процедури, не давати можливості організатору створити процедуру без лотів, якщо лоти є на закупках.
Публікую процедуру з productEntity.id1 та productEntity.lotId1. Якщо знайдено співпадіння по productEntity.id1, і по productEntity.lotId1, і статус процедури != unsuccessful, cancelled, вертаємо помилку.
Публікую процедуру з productEntity.id1 та productEntity.lotId2. Якщо знайдено співпадіння по productEntity.id1, а по productEntity.lotId2 співпадінь немає, публікуємо успішно процедуру
string($date-time) readOnly:true x-default:now x-legalNameUa:Дата публікації процедури x-legalNameEn:Published date
dateModified
string($date-time) readOnly:true x-legalNameUa:Остання дата зміни процедури x-legalNameEn:Procedure date modified
spec
{
x-format
"multidict"
}
auctionId
string readOnly:true x-legalNameUa:Ідентифікатор аукціону x-legalNameEn:Auction ID
previousAuctionId
string example:GFW000-UA-YYYYMMDD-00000 pattern:^GF[W][0-9]{3}-UA-[0-9]{8}-[0-9]{5}$ minLength:1 x-legalNameUa:Ідентифікатор попереднього аукціону x-legalNameEn:Previous auction Id
Якщо tenderAttempts > 1 заповнюється вручну, має відповідати auctionId попереднього аукціону. Якщо tenderAttempts = 1 то previousAuctionId не використовується
inactivationDate
string($date-time) readOnly: true x-legalNameUa: Дата деактивації заяви на участь x-legalNameEn: Inactive bid date
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
x-legalNameUa
"Повна юридична назва організації"
x-legalNameEn
"Legal name"
}
id*
string x-legalNameUa:Код ЄДРПОУ або ІПН або паспорт x-legalNameEn:ID
x-baseClass
"prozorro_sale.procedure.models.base.Identifier"
x-legalNameUa
"Ідентифікатори організації або особи"
x-legalNameEn
"Identifier"
}
address*
{...}
representativeInfo
string example:Довіреність № 123 від 22.02.2012, дійсна до 30.03.2012/Наказ № 142 від 14.12.2019/Статут ТОВ Кульбаба від 24.07.2002 x-legalNameUa:Інформація щодо підтвердження повноважень x-legalNameEn:Representative information
Інформація про документ або дані, що підтверджують повноваження представника юридичної особи (наприклад довіреність)
contactPoint*
base.ContactPoint{
description:
ContactPoint model Містить дані про контакту особу та може використовуватися для організатора, учасника і автора запитання в моделях SellingEntity та Organization
name*
base.MultiLang{
description:
Multi language string model
uk_UA*
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
x-legalNameUa
"Перелік та вимоги до оформлення документів"
x-legalNameEn
"List and requirements of registration documents"
}
x_additionalInformation
base.MultiLang{
description:
Multi language string model
uk_UA*
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
x-legalNameUa
"Додаткові відомості"
x-legalNameEn
"Other requirements and additional information"
}
value*
base.Value{
description:
Value model Містить дані щодо вартості. За замовчуванням: валюта - гривня, ПДВ - включено. Може використовуватися для стартової ціни лота, кроку аукціону і т.д.
integer($int64) default: 0 x-legalNameUa: Кількість днів на виконання платежу за договором x-legalNameEn: Number of days required to submit the payment
description
base.MultiLang{
description:
Multi language string model
uk_UA*
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
x-legalNameUa
"Додаткова інформація щодо умов розрахунку дебітора за договором"
x-legalNameEn
"Additional information regarding the debitor's payment"
}
x-legalNameUa
"Умови виконання оплати дебітором за договором організатору"
string pattern: [a-zA-Z]{2,}-[0-9]{4}-[0-9]{2}-[0-9]{2}-[0-9]{6}-[a-zA-Z]{1} x-legalNameUa: Користувацький ідентифікатор процедури закупівлі Прозорро x-legalNameEn: Prozorro tender human id
lotId
string pattern: [a-zA-Z0-9]{32} x-legalNameUa: Машинний ідентифікатор лота закупівлі Прозорро x-legalNameEn: Prozorro lot technical id
debitor*
{
description:
Organization model Містить дані про суб'єкта'
name*
base.Multilang{
description:
автогенерується з поля identifier.legalName
uk_UA
string minLength: 1 x-legalNameUa: Назва українською x-legalNameEn: Ukrainian name
en_US
string x-legalNameUa: Назва англійською x-legalNameEn: English name
x-baseClass
"prozorro_sale.registry.models.base.MultiLang"
x-legalNameUa
"Повна юридична назва організації або ПІБ"
x-legalNameEn
"Legal name or Full Name"
}
identifier*
base.Identifier
Identifier model Містить дані щодо ідентифікації суб'єкта'
address*
Адреса організації
contactPoint*
base.ContactPoint
representativeInfo
string example: Довіреність № 123 від 22.02.2012, дійсна до 30.03.2012/Наказ № 142 від 14.12.2019/Статут ТОВ Кульбаба від 24.07.2002 x-legalNameUa: Інформація щодо підтвердження повноважень x-legalNameEn: Representative information
string readOnly: true x-default: hex x-legalNameUa: Внутрішній ідентифікатор об'єкта x-legalNameEn: Item ID
description*
base.Multilang{
description:
автогенерується з поля identifier.legalName
uk_UA
string minLength: 1 x-legalNameUa: Назва українською x-legalNameEn: Ukrainian name
en_US
string x-legalNameUa: Назва англійською x-legalNameEn: English name
x-baseClass
"prozorro_sale.registry.models.base.MultiLang"
x-legalNameUa
"Повна юридична назва організації або ПІБ"
x-legalNameEn
"Legal name or Full Name"
}
classification*
unit*
quantity*
address
scheme
x-baseClass
"prozorro_sale.procedure.models.base.Item"
}]
initialValue
base.ValueWithTax{
description:
Value model Містить дані щодо вартості. За замовчуванням: валюта - гривня, ПДВ - включено. Може використовуватися для стартової ціни лота, кроку аукціону і т.д.
Value model Містить дані щодо вартості. За замовчуванням: валюта - гривня, ПДВ - включено. Може використовуватися для стартової ціни лота, кроку аукціону і т.д.
Ідентифікатор, що відображається тільки в документі digitalSignature та використовується для відображення зв'язку між цифровим підписом та документом сутності процедури.
string($date-time) readOnly:true x-default:now x-legalNameUa:Дата публікації документу x-legalNameEn:Document publishing date
dateModified
string($date-time) readOnly:true x-default:now x-legalNameUa:Остання дата редагування документу x-legalNameEn:Document modified date
index
integer($int64) x-legalNameUa:Параметр сортування ілюстрацій x-legalNameEn:Document index
Чим менше значення поля, тим вище документ буде при відображенні на майданчиках. Основним документом вважається документ з мінімальним значенням індексу. Якщо параметр не зазначений, документи будуть виводитись останніми у переліку. Якщо кілька документів мають однакове значення параметру, порядок сортування буде залежати від dateModified, Пріоритет у документів доданих раніше.
format
string readOnly:true x-legalNameUa:Формат документу x-legalNameEn:Document format
language
string x-legalNameUa:Мова документу x-legalNameEn:Document language
string example:Довіреність № 123 від 22.02.2012, дійсна до 30.03.2012/Наказ № 142 від 14.12.2019/Статут ТОВ Кульбаба від 24.07.2002 x-legalNameUa:Інформація щодо підтвердження повноважень x-legalNameEn:Representative information
Інформація про документ або дані, що підтверджують повноваження представника юридичної особи (наприклад довіреність)
contactPoint*
base.ContactPoint{
description:
ContactPoint model Містить дані про контакту особу та може використовуватися для організатора, учасника і автора запитання в моделях SellingEntity та Organization
name*
base.MultiLang{
description:
Multi language string model
uk_UA*
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
Question model Описує сервіс обговорення аукціону (запитання-відповідь)
owner
string readOnly:true x-legalNameUa:Ідентифікатор майданчика x-legalNameEn:Broker ID
ownerToken
string($uuid) readOnly:true x-default:hex
id
string readOnly:true x-default:hex x-legalNameUa:Ідентифікатор запитання x-legalNameEn:Question ID
author*
base.ContactPoint{
description:
ContactPoint model Містить дані про контакту особу та може використовуватися для організатора, учасника і автора запитання в моделях SellingEntity та Organization
name*
base.MultiLang{
description:
Multi language string model
uk_UA*
string minLength:1 x-legalNameUa:Назва українською x-legalNameEn:Ukrainian name
en_US
string x-legalNameUa:Назва англійською x-legalNameEn:English name
[ x-format:list-object default:List [] readOnly:true x-legalNameUa:Додаткова інформація x-legalNameEn:Additional informationbase.AdditionalInformation{
id
string readOnly:true x-legalNameUa:Ідентифікатор об'єкту додаткової інформації x-legalNameEn:Additional information ID x-default:hex
owner
string readOnly:true x-legalNameUa:Ідентифікатор власника об'єкта додаткової інформації x-legalNameEn:Owner ID
datePublished
string($date-time) readOnly:true x-default:now x-legalNameUa:Дата публікації x-legalNameEn:Publish date
dateModified
string($date-time) readOnly:true x-default:now x-legalNameUa:Дата модифікації x-legalNameEn:Modification date
description*
base.MultiLang{...}
initiator*
string x-dictionaries:List [ "additional_info_initiators" ] x-legalNameUa:Ініціатор публікації додаткової інформації x-legalNameEn:Additional information initiator
string x-dictionaries:List [ "additional_info_reason" ] x-legalNameUa:Причина публікації додаткової інформації x-legalNameEn:Additional information reason
Задача полягає в тому, щоб відображати повну інформацію про процедури факторингу тільки організаторам та учасникам, спостерігачі, в свою чергу, для процедур в статусі complete бачать всі поля крім тих, що зазначені як приховати. Щодо процедур в усіх інших статусах - спостерігачі їх не бачать.
Для цього в search ми маємо на запит відображення процедур факторингу віддавати тільки процедури факторингу в статусі complete без прихованих полів.
Було додано нову роль - broker. Для тих майданчиків, які планують працювати з даним напрямком, буде додано цю роль. В такому випадку саме ці майданчики отримають всі процедури факторингу в усіх статусах через mirror. Також у цих майданчиків буде можливість отримувати процедури за прямим запитом. Якщо майданчику не буде додано такої ролі, то за прямим запитом майданчик отримає 403 помилку, а в mirror синхронизацію процедур факторингу для таких майданчиків буде пропущено.
для факторингу broker ідентифікується по наявності пермішену read_procedure
перероблюються існуючі ендпоінти: виносимо логіку з вьюх і переносимо до стейт машини, всі колишні публічні ендпоінти додаємо як базові, з можливістю переопреділити
для факторингу для "публічних" ендпоінтів в стейт машині перевіряємо у юзера наявність пермішенів read_procedure
для міррора перевіряємо чи може користувач "читати" процедуру, далі - на основі ролі формуємо поля доступні для читання, іншим користувачам відправляємо noop
таким чином:
тим майданчикам, які працюють з напрямом - права read_procedure. В міррорі їм приходять оновлення по напряму, але без тієї доп інформації.
іншим майданчикам приходить noop сповіщення, таким чином не ломаючи їхню логіку
скачувати документи все ще можливо тільки брокерам (так ми зможемо трекати хто запрошував ці документи) - передивлятись список - всім з правами read_procedure.
Організатор зі своїм токеном бачить всі поля процедури.
Учасник зі своїм токеном бачить тільки свій бід та авард в усіх статусах процедури. Щодо contract, то в цьому випадку ми маємо відображати тільки його учаснику-переможцю.
Нижче наведено таблицю, де зазначена логіка роботи основних ендпоінтів в залежності від того який токен використовується.
Якщо в комірці проставлено , в такому випадку за запитом з зазначеною комбінацією токенів ендпоінт спрацює та віддасть дані.
Якщо в комірці проставлено , в такому випадку на запит буде віддано або 403, або 404.
Сірим позначено комбінації, які не будуть використовуватись.
Endpoint
No token
Broker token
Broker token + Owner token
Broker token + Bidder token
Опис
Запит без зазначення токена (публічний доступ)
Стандартний токен майданчика.
Майданчикам, що беруть участь в пілоті, в auth файл буде додано роль broker для отримання процедур факторингу по mirror
Комбінація токену майданчика та токену процедури (токен, який отримує майданчик (організатор) після створення процедури)
Комбінація токену майданчика та токену, який видається учаснику, що створив бід
GET/api/mirror/procedures
Отримує процедуру за виключенням полів bids, awards, contracts.
GET/api/procedures/{procedure_id}
Отримує процедуру за виключенням полів bids, awards, contracts.
Віддаються всі поля
Віддаються всі поля процедури, але bids, awards, contracts віддаються лише того біда, який виконує запит
POST/api/procedures
Якщо в auth додано роль procedure для факторингу
GET/api/procedures/{procedure_id}/documents
На відміну від broker token та broker token + owner token, процедурі з'явиться бід учасника, який виконує запит, якщо статус active_tendering
Побачить, коли статус процедури зміниться на active_qualification
Побачить тільки у випадку, якщо бід було створено учасником, який виконує запит
Для об'єктів історії використовується та сама логіка, яка використовується для відображення полів в процедурі. Тобто, якщо запит робить broker, в такому випадку буде відображено всі поля, за виключенням bids, awards, contracts. Якщо запит робить організатор але статус об'єкту історії active_tendering, тоді він не побачить bids, awards, contracts. Якщо ж статус інший, тоді ці поля буде відображено. Якщо запит буде робити учасник, то в об'єкті учасник побачить лише свій bid, award, contract.
Спостерігач. Бачить публічну інформацію, яка виключає приховані поля. Бачить тільки процедури в статусі complete. Не бачить процедури в статусах відмінних від complete.
Прекваліфікований фактор (прекваліфікований спостерігач). Бачить всі процедури факторингу в усіх статусах, не бачить приховані поля. Майданчик має відобразити списки процедур факторингу тільки для прекваліфікованих учасників. Технічна реалізація передбачає наступну логіку. Згідно конфігурації в auth файлі (внутрішня логіка), буде налаштовано наступну логіку. Для майданчиків, які планують брати участь в пілоті, буде додано права на створення процедури та бідів, і, відповідно, ці майданчики будуть отримувати повний список процедур в усіх статусах (без прихованих полів). Щодо інших майданчиків - вони не будуть отримувати процедури факторингу.
Учасник. Бачить всі процедури факторингу в усіх статусах, де створив бід. Бачить documents, paymentTerms, questions. Бачить лише свої bids, awards, contracts.
Організатор. Бачить всі поля.
Вимоги до відображення на інтерфейсі майданчика
Відповідно до вимог вище, майданчики отримують по mirror процедури в усіх статусах за виключенням полів bids, awards, contracts.
Тому логіка приховання полів для спостерігачів має бути реалізована на стороні майданчика. Тобто для непрекваліфікованих спостерігачів, необхідно відобразити тільки процедури в статусі complete, та в цих виведених процедурах НЕ відображати поля:
paymentTerms
bids
awards
contracts
documents
questions
Повний список процедур необхідно відображати лише тим користувачам, які є прекваліфікованими. Тобто якщо, наприклад, було прекваліфіковано ПУМБ, то для них потрібно відобразити всі процедури в усіх статусах.
Щодо перегляду деталей процедури, то ПУМБ мають бачити paymentTerms, documents, questions (за виключенням questions.author), cancellations, і тільки свої bids, awards, contracts.
Класифікатори
Основний:
Обов’язковий —CAV. Має співпадати з класифікатором items в lot на Прозорро.
Додатковий:
Видаляємо
Редагування Процедури
Редагування оголошення для Процедур, в яких Період Редагування розпочинається разом з Періодом подання заяв на участь (rectificationPeriod.startDate == tenderingPeriod.startDate)
При редагуванні деяких полів процедури відбувається деактивація бідів (bid status: active → inactive).
Перелік полів, які деактивують заяви на участь:
value
documents
valueAddedTaxCharged
title
description
items
x_additionalInformation
x_documentRequirements
paymentTerms
productEntity (поля productEntity.id, productEntity.humanId, productEntity.lotId не редагуються)
previousAuctionId
tenderAttempts
sellingEntity
lotId
bankAccounts
Поля, які вказують на айді тендера та / або лота (productEntity.id, productEntity.humanId, productEntity.lotId) редагувати не можна!
При редагуванні процедури обов'язково завантаження документу clarifications!
Функціонал доступний у випадку початку періоду кваліфікації процедуриqualificationPeriod.
Вимоги до відображення на інтерфейсі майданчика
Організатору необхідно відобразити одночасно всі award в статусі pending_waiting. Тобто, по завершенню періоду подання пропозицій, та на початку періоду кваліфікації, організатору необхідно відобразити кожен з авардів. На стороні ЦБД буде створено авард в даному статусі на кожен активний бід.
У організатора має бути можливість зробити з кожним з авардів наступні дії:
Обрати переможця. В такому випадку статус аварда буде змінено на active, і організатор буде працювати з обраним авардом за стандартним флоу.
Відхилити пропозицію. У випадку, якщо організатор категорично не хоче розглядати певну пропозицію, в такому випадку вони можуть відхилити певну пропозицію. Відхилення пропозиції має супроводжуватись сповіщенням для організатора, що у разі відхилення пропозиції, у них не буде більше можливості знов розглянути цю пропозицію, оскільки її буде переведено в термінальний статус.
Робота з award`ом
Технічний ідентифікатор
Назва українською
Назва англійською
Обов'язковість
Приватність
Деталі
Хто завантажує
rejectionProtocol
Рішення Організатора про відмову (дискваліфікацію)
Rejection protocol
Так
private
Завантажується у разі дискваліфікації переможця Організатором
Організатор
act
Акт про відмову переможця
Refusal act
Так
private
Завантажується у разі відмови переможця аукціону від підписання протоколу аукціону або від укладення договору купівлі-продажу, або несплати ним ціни продажу у встановлений строк
Організатор
digitalSignature
Цифровий підпис
Digital signature
Ні
Набуває значення документу з яким пов'язаний
При цьому обовʼязково звернути увагу, що документи є private.
Для зміни статуса Award з pending_waiting на active має відбутися ручна дія організатора.
Вимоги до відображення на інтерфейсі майданчика
Після початку періоду кваліфікації, організатору необхідно надати можливість попередньо обрати переможця тв відхилити пропозицію. Обидві дії є ручними.
При відхиленні пропозиції, організатору необхідно відобразити повідомлення, що дана дія є незвороньою та запросити додаткове підтвердження дії. Ця дія змінить статус аварду з pending_waiting на discarded.
Коли організатор обирає переможця, в такому випадку необхідно також відобразити організатору попередження, що дія є незворотньою і вимагати додаткове підтвердження дії. Ця дія змінить статус аварду з pending_waiting на active.
Підписана дебітором додаткова угода до договору закупівлі/сповіщення про переуступку договору
Організатор
handoverCertificate
Акт прийому/передачі
Handover certificate
Так
private
Документ, що підтверджує передачу товару чи надання послуг
Організатор
Зміна статусу контракту з pending на signed відбувається за допомогою окремого ендпоінта. Після підтвердження попереднього контракту розпочинається період оплати.
Для того, щоб статус контракту змінився з signed на active необхідно підтвердити отримання коштів в аварді (зміна lotPaymentConfirmation з false на true), додатковою є валідація на наявність документів purchaseContractEndorsement та handoverCertificate
Період оплати
Період оплати розпочинається після того, як завантажено та підтверджено підписаний договір. В цей період фактор має перерахувати кошти організатору (поза системою), а організатор - підтвердити отримання коштів.
Вимоги до відображення на інтерфейсі майданчика
Робота з контрактом розпочинається після того, як організатор обрав переможця.
У організатора має бути можливість завантажити документ контракту, а також два додаткових обов'язкових документа: purchaseContractEndorsement та handoverCertificate. Ці документи можна завантажити як до завантаження контракту, так і після, завантажувати оновлені версії цих документів. Але після переходу контракту в статус active ці документи змінювати не можна.
Після того, як завантажено документ контракту, організатор має попередньо підтвердити контракт окремою дією.
В цей момент у організатора має бути можливість заповнити поля контракту, а також поставити маркер lotPaymentConfirmation = true. Активувати та деактивувати цей маркер можна до переходу контракту в статус active, тобто в статусі signed. Для того, щоб контракт перейшов в статус active, обов'язково:
мають бути заповнені всі обов'язкові поля
завантажено документи purchaseContractEndorsement та handoverCertificate
завантажено документ контракту
lotPaymentConfirmation має бути обрано як true.
Активація контракту має бути ручною дією, при виконанні цієї дії, організатора необхідно попередити, що ця дія є незворотньою.
Надсилання запиту на завершення процедури відбувається шляхом натискання кнопки “Завершити аукціон”.
Кнопка "Завершити аукціон" може бути доступна тільки після того, коли статус contract == active
Функціонал доступний Користувачу та Учаснику
Надсилання запитання Організатору
Надсилання запитання відбувається за загальним флоу роботи з запитаннями
Редагування запитання відбувається за загальним флоу редагування.
Функціонал доступний Користувачу
Вимоги до відображення на інтерфейсі майданчика
Тобто додавати процедури факторингу в загальний список процедур (якщо такий є) не треба.
Робота з bid`ом
Всі документи біда мають бути private! Створення біда можливо без документів, але обов'язково необхідно вказати ЄДРПОУ.
В даній процедурі створення біда в статусі draft необхідно додати на сторону ЦБД для можливості відображення документів учасникам.
Для зміни статуса bid-а з draft на active обов'язкові документи, а також необхідно провалідувати поля value, perks та bankAccounts. Вони не мають бути порожніми.
Щодо валідації на поле value. Необхідно прибрати валідацію, що bid.value має дорівнювати або бути більшим procedure.value, оскільки банки будуть пропонувати меншу суму угоди, ніж ціна закупівлі.
Додаткова умова - додати валидацію на bidders identifier.scheme. Для створення заяви на участь ми маємо пропускати тільки UA-EDR, щоб унеможливити створення заяви на участь від фізичних осіб або ФОП.
Технічний ідентифікатор
Назва українською
Назва англійською
Обов'язковість
Приватність
Для чого
Хто завантажує
x_tenderersRegisterExtract
Витяг з ЄДРПОУ або копія документа про реєстрацію
Register extract
Ні
private
Копія витягу з ЄДРПОУ або копію документа про реєстрацію (витяг із торговельного, банківського або судового реєстру тощо) (для юрособи)
Відстуня валідація на bid.value має обовʼязково бути більша, ніж procedure.value.
У учасника є можливість вказати bankAccounts в bid. Додаткова інформація щодо bankAccounts в bid. В процедурі факторингу було додано банківські рахунки в біди. Це необхідно у звʼязку з тим, що дебітор після успішного завершення процедури факторингу має розрахуватись з учасником (банком). Для цього учасник має вказати банківські рахунки на момент створення біда. В подальшому поле bankAccounts автоматично переносяться в award та в contract.
Учасник може вказати perks в bid. В подальшому поле perks автоматично переносяться в award та в contract.
Вимоги до відображення на інтерфейсі майданчика
Прекваліфікація учасника
Кожен учасник, який бере участь в процедурі факторингу має бути прекваліфікований. Що таке прекваліфікація? Для того, щоб отримати доступ до документів процедури факторингу, майданчик має прекваліфікувати такого учасника на етапі створення акаунту учасника. Для прекваліфікації учасника необхідно переконатись, що даний учасник дійсно має право на ведення факторингової діяльності. Має бути завантажена ліцензія на ведення такої діяльності. Ліцензія має бути завантажена на стороні майданчика, в ЦБД даний документ вантажити не потрібно.
Доступ до документів процедури
Документи процедури необхідно приховати від неавторизованих непрекваліфікованих користувачів.
Для того, щоб передивитися документи процедури факторингу, учаснику необхідно створити бід в статусі draft. В цій процедурі бід в даному статусі буде створюватись і на стороні ЦБД. В цьому біді має обов'язково бути вказаний ідентифікатор учасника (ЄДРПОУ). У випадку, якщо цей учасник є попередньо прекваліфікованим, то такий учасник зможе передивитись документи процедури, і відредагувати / уточнити свою пропозицію після ознайомлення з документами.
Майданчик має гарантувати, що доступ до документів отримають тільки прекваліфіковані учасники.
Створення заяви на участь
Створити заяву на участь можливо лише вказавши хто є учасником (ЄДРПОУ). Зверніть увагу, що для активації заяви на участь, обов'язково мають бути заповнені поля value, bankAccounts, а також perks. Учаснику, який сторив заяву на участь в статусі драфт для того, щоб передивитися документи та прийняти рішення, чи цікава йому дана процедура факторингу, необхідно надати можливість закінчити створення та активацію заяви на участь в процедурі факторингу. Для цього, як вже зазначилось, мають бути обов'язково присутні поля value, bankAccounts, perks.
Відображення процедур факторингу прекваліфікованим учасникам
Для прекваліфікованих учасників необхідно показати список всіх процедур факторингу в усіх статусах. Біля процедур факторингу, де вже було додано пропозицію від учасника, треба відобразити відповідне інфо, тобто учасник в загальному списку має чітко бачити, на яких процедурах факторингу наявна пропозиція цього учасника та статус цієї пропозиції. Статус необхідно відобразити з тієї причини, що для перегляду документів процедури учаснику необхідно створити бід в статусі драфт, але фактично це не завжди буде повністю сформована пропозиція.
ВАЖЛИВО Учасник не має бачити кількість пропозицій від інших учасників, а також не має бачити деталі пропозицій інших учасників під час qualification_period та в завершеній процедурі (complete)
Функціонал доступний Учаснику
Робота з bid`ом
(перелік документів описано вище)
Активація заяви на участь (Зміна статуса Bid-а з draft АБО inactive на active)
Мають відображати користувачеві помилку стандартну помилку: Procedure with auctionId [auctionId] not found.
Інші вимоги до майданчиків
Зміни в відображеннях закупівлях (Прозорро)
На сторінці закупівлі:
Відобразити сповіщення для учасників тендеру, що на дану закупівлю доступна послуга факторингу
Відобразити тултіп, де учасникам буде роз'яснено що таке процедура факторингу
Відобразити останню процедуру факторингу, створену для даної закупівлі або лоту.
По можливості (опціонально) додати можливість переглядати історію процедур факторингу
На сторінці пошуку закупівель:
Додати на картку закупівлі маркування про існування пов'язаної процедури факторингу в активному або завершеному статусі.
Додати фільтр відображення закупівль, де була створена процедура факторингу.
Взаємодія з організатором закупівлі:
Організатора необхідно сповіщувати про створення процедури факторингу для його закупівлі.
Організатора необхідно сповіщувати про зміну статуса процедури факторингу для його закупівлі.
В кабінеті організатору необхідно відобразити реквізити факторингової компанії, яку обрав постачальник для кожної з закупівель.
Для постачальника:
Постачальнику необхідно надати можливість створити процедуру факторингу для тієї закупівлі, де постачальник є переможцем.Уточнення. Кнопку не треба показувати для видів закупівель, результатом яких є відбір учасників для участі в тендері, тобто для "Конкурентний діалог 1-ий етап", "Конкурентний діалог з публікацією англійською мовою 1-ий етап", "Відбір для закупівлі за рамковою угодою".
, в такому випадку за запитом з зазначеною комбінацією токенів ендпоінт спрацює та віддасть дані.
, в такому випадку на запит буде віддано або 403, або 404.