...
В: Для створення тестових процедур з заданими параметрами часу слід використовувати потрібний тип проискорення -fast процедур. З описом -fast процедур можні остайомитися за поситанням: https://gitlab.prozorro.sale/prozorro-sale/procedure/-/tree/master/specs та обрати той, що найбільше піжходить під потреби.
Procedure, timberEnglish, П: В чому різниця планування на дату та час аукціонів при використання процедур з прискоренням -fast та без?
В: При використанні - -fast процедур дату та час проведення аукціону можливо задати вручну, а для процедур без -fast дата та час визначає ЦБД
Procedure, timberEnglish, П: На яких етапах можливе/не можливе видалення документів з bid?.
В: На етапі кваліфікації видалення документів біда (якщо вони були завантажені до аукціону) не має бути доступним, але якщо документ (наприклад протокол) завантажили на етапі кваліфікації, до зміни статусу на наступний, має бути доступний стандартний функціонал роботи з документами.
Procedure, П: Чи має ЦБД дозволяли повністю змінити закриту пропозицію користувача і документи до неї (включно з видаленням документів), навіть якщо пропозиція була вже кваліфікована плюс редагування bid в статусі active ?
В: Редагування bid та документів біда, які були завантажені до початку кваліфікації, на наступних стадіях не має бути доступним. У деяких випадках можлива робота з документами після початку кваліфікації (більше документів для зеленої енергетики, протокол учасника для інших процедур). Тоді заміна\видалення і т.д. доступне для цих документів, але теж не для тих, які завантажені на попередньому етапі
Procedure, П: Чи може сутність bid мати статус invalid ?
В: На даний момент таких статус є тільки для bid у процедур з голландським типом.
Procedure, timberEnglish, П: Чи може майданчик бути підключеним до продуктового середовища без реалізованого/робочого Єдиного Інтерфейсу, з можливістю його підключення і окремого тестування згодом?
В: Ні, наявність Єдиного Інтерфейсу для роботи з аукціонами з продажу деревини - обов'язкова вимога для початку роботи з продуктивом. Якщо майданчик працює з іншими процедурами, там можлива робота без Єдиного Інтерфейсу
Procedure, railwayCargo-english, П: Чи має аукціон переходити в статус неуспішного якщо протокол не було завантажено протягом verificationPeriod?
В: ЗгідноТЗverificationPeriod не завершується автоматично, а тільки вручну Організатором, відповідно для завершення цього періоду, з боку учасника потрібна обов'язкова дія завантаження підписаного протоколу, а з боку Організатора, потрібна обов'язкова дія підтвердження завантаженого учасником протоколу. Без вищевказаних дій завершення verificationPeriod неможливо.
Procedure, railwayCargo-english, П: Чи має у переможця має бути можливість завантаження auctionProtocolі після verificationPeriod.endDate ?
В: Настання verificationPeriod.endDate неможлива без дій Організатора, тому учасник, фактично, ніяк не зможе завантажити протокол після verificationPeriod.endDate. За нормативка не пердбачає завантаження з боку Організатора, але з боку ДП додано цю опцію як можливість, як додатковий механізим контролю. Це працює так само, як і в інших процедурах для учасника, що не призводить ні до яких змін. Відповідно в ідеальному світі, згідно нормативки:
- протокол завантажує учасник
- підтверджує Організатор