...
- ТЗ процедури
- Swagger
- Словник legal_names
- Словник дискваліфікації
- Timeline процедури
- Діаграма зміни статусів bid
- Діаграма зміни статусів award
- Діаграма зміни статусів contract
Логіка ролей для всіх GET ендпоінтів
Особливості процедури:
- Функціонал відмови від очікування для pending_waiting - ВІДСУТНІЙ.
- По завершенню tenderPeriod відразу розпочинається qualificationPeriod (без МА).
Організатор зі своїм токеном бачить всі поля процедури. Учасник зі своїм токеном бачить тільки свій bid, award, contract в усіх статусах.
- На кожен bid в статусі active має створитися award в статусі pending_waiting.
- Протокол в процедурі не формується.
- Новий статус award'у - discarded.
- Причина скасування вказується вручну в текстовому полі.
- Відсутня можливість додавання додаткового класифікатора.
Майданчик має гарантувати, що на одну закупівлю (на один lot) одночасно існує тільки одна процедура факторингу в активному статусі, або в статусі completed.
При публікації процедури через Майданчик - в Організатора доступна можливість вказати productEntity.humanId "UA-2020-09-22-000016-b", або productEntity.lotId в форматі "9ee6ebbf2ad21ac0c5ad52b06e776fa4". В одній закупівлі може бути одночасно декілька лотів, і на кожен лот можна створювати окрему процедуру факторингу.
- Нове поле perks для bids, award, contract.
- Щодо валідації на поле value. Необхідно прибрати валідацію, що bid.value має дорівнювати або бути більшим procedure.value, оскільки банки будуть пропонувати меншу суму угоди, ніж ціна закупівлі.
- Для створення заяви на участь Майданчик має пропускати тільки UA-EDR, щоб унеможливити створення заяви на участь від фізичних осіб або ФЛП.
Для зміни статусу contract'у з pending на signed мають бути завантажено contractSigned.
- Для зміни статусу contract'у з signed на active мають бути змінено з lotPaymentConfirmation з false на true та завантажено:
...