Документи та посилання на ресурси: 

Мирорр клієнт https://gitlab.prozorro.sale/public-projects/mirror-clients

П: де знайти посилання на ТЗ/swagger або інші документи? 
В:  https://gitlab.prozorro.sale/public-projects/documentations

П:  як подати запит на отримання або зміну ключів доступу/ip

В:  https://docs.google.com/document/d/1idIvUsix04RD63uVtNXcZxiMKGyx9C-lyCbgngc8xfw/edit

Помилки,взаємодії  з АРІ та ЦБД: 

ЦБД П: Чи потрібно відправляти auctionPeriod startDate додатково в якомусь часовому форматі? Так як при публікації на ЦБД startDate періодів починаються -3 години, від datePublished.

В: в ЦБД 0-й часовий пояс, якщо в даті не передати часовий пояс - то він і сприймається як теж 0-ой

Модаль Аукціону П: модуль аукціонів видає 500/503 помилку 

В:  заповнити шаблон звіту про помилку та надати розробнику (додати шаблон)

ДС П: 403 помилка при спробі зареєструватидокумент в ДС (в лот МП)

В: проблема з ключами, потрібна заміна ключа

ЦБД П: Чи варто  надсилати повторний запит від майданчика в разі отримання 500 та 400 помилок? 

В:  Загальні правила такі ж як для будь-якого http API:

1. має сенс повторити запит якщо код відповіді> = 500 з великою ймовірністю помилка НЕ ​​повториться
2. 400 коду повторювати не варто швидше за все майданчик з свого боку робить  щось не так

Відповідно варто Залогувати таку  інформацію про помилки з боку майданчика  - час, код, текст помилки, оточення і версія АПИ і бажано проблемні дані щоб була можливість повторити ситуацію та передати інформацію про помилку розробнику. 

АРІ П:  надсилаємо POST /api/cdb3/procedures/5ea01c461776095d27a5b113/question
але у відповідь отримуємо тільки токен без ID {"id": "", "acc_token": "b3b2a47a-fd97-45db-86e4-dfd77fe97aab"}

В:  Для вирішення питання  поле id повинно бути заповненим

АРІ  П: 500 помилка при завантажені документу на Staging

В:  Проблеми з коннектом Swift.

ЦБД П: При першій синхронізації з ЦБД Staging передається неповне посилання  в поле procedure.auctionUrl, відсутній домен. При наступних синхронізаціях посилання стає повним. При синхронізації використовується search by date endpoin з сортуванням за зростанням дати модифікації, для перегляду тільки актуальних змін фіксується дата модифікації останнього елемента, яка є відправною точкою для подальших запитів. Таймаут 30 сек.

В: Виправлений баг, повино працювати

ЦБД П: Server error: `PUT https://procedure-sandbox.prozorro.sale/api/procedures/5ebea9d0705317826e2a3e19/documents` resulted in a `500 Internal Server Error` response: {"message": "Internal server error"}

В: Виправлено, повино працювати 

ЦБД П: Запит /api/procedures/{procedure_id}/history/{archive_id}.  З якою метою він створений, і де взагалі може використовуватись?Ще одне запитання у зв’язку з цим — чи є з точки зору історії сенс оновлювати окремий item, а не всю процедуру? З документами зрозуміло— там є своя історія, тому документи ми оновлюємо, коли вони дійсно були змінені, а от як оновлення усіх items при кожному оновленні процедури буде впливати на історію, поки що не зрозуміло.

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

ЦБД П: Який практичний час різниці між подією на ЦБД та її відображенням у mirror’і за умови нормальної синхронізації? Цікаво наскільки практично створити процедуру і одразу(1-5-30) секунд шукати її у вже у себе.

В: При кількості вставок в базу менш 200 / секунду затримка в мірор більше не 1 секунди. На практиці думаю близько 100 мс в більшості випадків

ЦБД, ДС П: Чи є десь опис взаємодії з ДС?

В: Є тільки https://procedure-sandbox.prozorro.sale/api/doc#/ documentType - через query

ЕЦП П: Питання по роботі з digitalSignature . Хотілось би уточнити чи правильно розумію флоу. Ми спочатку завантажуємо документ, який підписуємо ЕЦП, в DocumentService, а потім прикріпляємо id цього документу (отримане з DocumentService)  в поле relatedDocument документу digitalSignature,

В:  Так https://confluence-sale.prozorro.org/display/PUB/CDB-3+FAQ - тут відповіді на ряд запитань про підпис

Процедури:

Procedure, Subsoil П: Чому тип аукцону міститься в назві процедури, а не реалізовано додатковим полем? Було б набагато зрозуміліше бачити процедуру nadra, а тип аукціону вже був би зазначений усередині

В:  Технічно простіше працювати з 1 параметром плюс набір параметрів для англыйського і голландського аукцыоныв дещо відрізняється

Procedure  GE П: Якщо аукціон знаходиться в статусі active.qualification,  аварди учасників знаходяться в статусі  "unsuccessful" та "cancelled" ( переможців не має), то Замовник повинен вімінити аукціон сам? 

В: "Якщо статус усіх учасників unsuccessful чи cancelled, ЦБД автоматично змінює статус процедури на "Аукціон не відбувся - unsuccessful".

Procedure  GE П:  Чи повинна бути можливість  у "Замовник аукціону - Гарантований покупець" завантаження clarifications при редагуванні аукціону?

В: Так, але дія не обов'язкова

Procedure  GE П: Запитання стосовно поля "Адреса розташування". В ТК написано, що поля не обов'язкові до заповнення але в swagger навпаки. Де коректна інфо?

В: Працює наступним чином, поля не обов'язкові, в разі незаповнення всіх полів, якщо ж заповнено хоч одне поле, то заповнювати потрібно всі поля.

Procedure П: При спробі надіслати пропозицію отримуємо  [{api {"message": "Forbidden state - active_rectification. Cannot create bid in current state"}}]
при цьому періоди для аукціону наступні

    "auctionPeriod": {
      "startDate": "2020-05-30T20:18:49.000000Z"
    },
    "rectificationPeriod": {
      "startDate": "2020-05-27T17:17:18.198000Z"
    },
    "enquiryPeriod": {
      "startDate": "2020-05-27T17:17:18.198000Z"
    },
    "tenderPeriod": {
      "startDate": "2020-05-27T17:19:18.198000Z"
    },
    "questionPeriod": {
      "startDate": "2020-05-27T17:17:18.198000Z"
    },

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

В:  На даний момент ендпойнта немає, але в теорії можемо додати якщо вам він потрібен. в теорії час у нас повинно бути нормально синхронізовано з UTC (принаймні я на це сподіваюся), за фактом так наші тести зараз теж чекають 2 хвилини. ми зробили мінімальну тривалість active_rectification 2 хвилини і це було пов'язано з тестами питань начебто. Можу подивитися чи можемо зробити менше. а який ви взагалі використовуєте? якщо я правильно пам'ятаю то при використанні fast варіанти процедури можна призначити дату аукціону на now + 5mins

Procedure, УЗ П: Навіщо в УЗ використовувати додатковий класифікатор Додатковий класифікатор (код) - MA08-5 — Для залізничного транспорту якщо ми маємо цілу окрему процедуру?

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

Procedure, УЗ П: При спробі створити процедуру по УЗ отримуємо [{api {"message": {"items": {"0": {"additionalClassifications": "This field is required"}}}}}] коли додаємо з класифікатором з документації отримуємо api {"message": {"items": {"0": {"additionalClassifications": {"0": {"id": {"id": "Cannot found classifier with id MA08-5"}}} як дізнатися перелік доступних id для додаткового класифікатора

 В: ви відправляєте legalName (Породи), як id. доступні варіанти класифікаторів для кожної процедури, можна знайти в Сваггера, в описі потрібної моделі.
так само в Сваггера є 2 ендпоінта з тегом classifiers - https://procedure-sandbox.prozorro.sale/api/doc#/classifiers
по ендпоінту - https://procedure-sandbox.prozorro.sale/api/classifiers, можна побачити список всіх класифікаторів в системі
по ендпоінту - https://procedure-sandbox.prozorro.sale/api/classifiers/{classifier} (https://procedure-sandbox.prozorro.sale/api/classifiers/timber-species) - можна знайти все варіанти id для потрібного класифікатора

Procedure ЗЕ, Надра П: Функції cancel_admission()  в AwardsApi ? Це функція для того, щоб відмінити авард, який знаходиться в статусі pending_waiting , тобто відмова учасника, що зайняв друге місце, від очікування?

В: Це функція для того, щоб скасувати Авард, який отримав залишок квоти і знаходиться в pending_admission.  В надрах через update_award_status

Procedure ЗЕ П: Чи достатньо буде користувача просити ввести тільки IBAN? Для чого використовуються інші реквізити, якщо IBAN по ідеї все включає в себе?

В: процедура опублікується в ЦБД з вказаним лише IBAN, але бажано додатково реалізувати можливість заповнення інших полів зі списку (UA-EDR, UA-MFO, UA-accountNumber)

Procedure  П:  Через що слід вказувати тип документа на етапі його завантаження/реєстрації в ЦБД, а не в момент атачменту документа до аукціону ? При цьому жодної валідації типів при завантаженні немає

 В: Основою для цього рішення було те що в майбутньому в ДС буде список документ типів, а також відповідність які документи можуть бути публічними / приватними. І ось коли він буде ДС буде стежити за тим що ви не завантажуєте (паспорт як публічний документ і т / д /) або не завантажується тендерну пропозицію як приватний документ.

Procedure  П: З якою метою було введено приватні файли? 

В: Ідея була в тому що паспорт інн і ряд інших документів є приватними за законом і за цим для перегляду вони будуть доступні тільки організатору процедури т / к / йому треба ознайомиться з ними, для всіх інших (пошукових індексаторів наприклад) вони не будуть доступні

Procedure, Subsoil  П: питання по надрах по полю leaseDuration Відправляємо значення P11Y11M11D API повертає з повідомленням

{
    "message": {
        "leaseDuration": [
            "Could not parse P11Y11M11D. Should be ISO 8601 or timestamp."
        ]
    

В: На даний момент приймається в форматі 2020-07-30T16:28:01.041+0000

Procedure, Timber  П: Чи планується додавання окремого sellingMethod для створення аукціону в статусі active_qualification по дереву?

В: Так планується

Procedure, Timber П: Чи можна збільшити час раунду для тестового аукціону з 15 секунд до 1 або 3 хвилин? Швидко створити аукціон через timberEnglish-initial-auction ми можемо, а встигнути потестить за 15 секунд не встигаємо

В: Якщо стврювати процедуру як fast-manual, то там більше довгі  періоди

Procedure, УЗ П:  З  якого словника треба брати значення для поля auctionRestriction.loadObject (x-legalNameUa: Ознака об’єкту полігону навантаження). Процедура railwayCargo-english?

В: https://procedure-sandbox.prozorro.sale/api/classifiers/objectLoadUnloadOrExclusionRange

Procedure, Timber П: Чи обов'язково  документи копія паспорту та копія ІПН мають бути  приватними (перегляд доступний лише для організатора аукціону)? 

В:  Так, для цих документі обов'язково

Procedure, Timber П:  Чому procurementMethod = timberEnglish, а не простоtimber? Чи будуть ще якісь види аукціонів по деревині? 
В:  Буде ще один тип процедури -  timberMultiAwards (перевернутий "стакан") 

Procedure, Timber П: Чи буде для timberEnglish та timberMultiAwards доступним режими (для тестування) -fast?

В: Так, буде

Procedure, Timber П: Для поля LotId валідація має вигляд TI000-UA-YYYYMMDD-00000 / UA-PS-YYYYMMDD-00000, в якому випадку що використовується?

В:  Валідація UA-PS-YYYYMMDD-00000 використовується для повторних торгів, при цьому, попередні проходили в ЦБД-2.  TI000-UA-YYYYMMDD-00000 також валідується в разі повторних торгів, але попередні торги проходили в ЦБД-3.

Procedure, Timber П:  timberEnglish-fast на staging. Питання по полю items.0.unitValue:

1. це "Ціна лоту за 1 м3"?
2. для поля items.0.unitValue  має бути модель base.Value або timberEnglish.Value? Зараз  value.valueAddedTaxIncluded може бути False, а поле unitValue.valueAddedTaxIncluded завжди True

В: в свагері для полей timberEnglish value.valueAddedTaxIncluded и unitValue.valueAddedTaxIncluded завжди значення True

Procedure, Timber П: Якщо поле items.0.unitValue.amount являє собою  value.amount / items.0.quantity (в цій процедурі завжди 1-й item), то навіщо користувачеві його вводити, чому не генерувати unitValue на рівні ЦБД при створенні процедури? Зараз організатор може туди ввдити будь-які дані і отримаємо  дані типу: 
Стартова ціна лота: 1000 грн з ПДВ
Розмір партии деревини: 100 м³
Ціна лоту за 1 м3: 1000000.01 грн з ПДВ

В: в рамках timberEnglish.Items: в масиві unitValue, Організатор вказує - стартову ціну за 1 м.куб, в поле quantity, Організатор вказує - розмір партії дерева в лоті. В рамках timberEnglish.TimberEnglishProcedure:  масиві value, Організатор вказує - стартову ціну лота (розміру партії дерева). За коректність введення цих даних на боці Організатора з урахуванням поточної валідації в свагері+

Procedure, Timber П: Якщо лот виставляється вперше (tenderAttempts = 1), то поле LotId ми не заповнюється і не передається?

В: якщо tenderAttempts = 1, то відбувається автогенерація ЦБД значення з auctionId

Procedure, Timber П:  staging, поле minNumberOfQualifiedBidsмає бути readOnly?

В: для timberEnglish є можливість його змінювати

Procedure, Timber П: Чи є заява на участь обов'язковим? 

В: ні, не є

Procedure, Timber П: Якщо tenderAttempts> 1, то поле discount.discount стає обов'язковим. Як це має виглядати для організатора на UI майданчики?
Варіант 1.
Коли організатор заповнює tenderAttempts> 1
І заповнює обов'язкове lotId
Тоді валідація на майданчику змушує організатора заповнити discount.discountValue і discount.percentDiscount
І в ЦБД передавати discount.discount: True
Варіант 2.
Коли організатор заповнює tenderAttempts> 1
І заповнює обов'язкове lotId
І організатор залишає порожніми необов'язкові поля discount.discountValue і discount.percentDiscount
Тоді в ЦБД просто передавати discount.discount: False

В: За умови tenderAttempts > 1, то заповнення полів об'єкту Discount є обов'язковим і в такому випадку ЦБД від майданчика повинна отримати відповідні дані (discount:true, discountValue, percentDiscount). Майданчик не зможе надати порожні поля Discount. Відповідно в такому випадку, така ж валідація має бути присутньою на і на майданчику, при значенні Лот виставляється>1, Організатор обов'язково повинен вказати дані щодо знижки.
- Discount потрібна для аукціонів в яких tenderAttempts > 1. Суть цього поля як в МП.
- Так бути не повинно, якщо значення discount: true, тоді всі поля об'єкту повинні бути обов'язково заповнені.
- Мінімальна валідація буде на стороні ЦБД, правильність заповнення полів Discount на відповідальності Організатора.

Procedure, Timber П:  На що взагалі впливає discount в цій процедурі? Це просто поле для відображення? Або як в МП на повторний аукціон знижка 50%?

В:  Модель Discount потрібна для аукціонів в яких tenderAttempts> 1. І так, суть цього поля як в МП.

Procedure, Timber П:   Чи нормально те, що є можливість створити аукціон discount.discount: True і не вводити "Стартова ВАРТІСТЬ попередня аукціону" і "Розмір знижки від попередня аукціону,%"? це баг?

В:  так бути не повинно, якщо discount: true, тоді все поля моделі повинні бути обов'язково заповнені.

Procedure, Timber П:  Чи повинна майданчик або ЦБД валідувати поля "Стартова ВАРТІСТЬ попередня аукціону" і "Розмір знижки від попередня аукціону,%"?

В: Мінімальна валідація буде на боці ЦБД, коректність заповнення цих полів на відповідальності користувача

Procedure, Timber П: Незрозуміла струткура поля spec

В: speс це внутрішнє поле ЦБД-3, можете його ігнорувати, майданчик із ним ніяк не взаємодіє.

Procedure, Timber П: Відсутня інформація по додатковим класифікаторам

В: додаткові класифікатори будуть у вигляді як словників (значення будуть обиратися зі словника) так і просто заповнюватися вручну (без словника). Додаткові класифікатори плануються до релізу, орієнтовно, за два тижні. Наразі працюємо тільки з єдиним додатковим класифікатором “timber-species”.

Procedure, Timber П: Незрозуміло які дані по FF записувати в additionalClassifications.

В:  ЦБД-3 відсутні flexible fields. 
В рамках timberEnglish додаткові класифікатори наступні:
- Додатковий класифікатор CPVS (timber-CPVS) QB49-3 — З питань лісового господарства - буде реалізовано у вигляді 1-го значення зі словника CPVS
- Сортимент (timber-sortment) - буде реалізовано у вигляді словника, Організатор повинен буде обирати значення зі словника
- Порода (timber-species) - реалізовано у вигляді словника, Організатор обирає значення зі словника
- Клас якості (timber-class) - буде реалізовано у вигляді словника, Організатор повинен буде обирати значення зі словника
- Група діаметрів (timber-diameter) - буде реалізовано у вигляді словника, Організатор повинен буде обирати значення зі словника
- Довжина (timber-length) - буде реалізовано у вигляді ручного заповнення, Організатор повинен буде вказати необхідне значення
- Склад (timber-storage) - буде реалізовано у вигляді словника, Організатор повинен буде обирати значення зі словника
- Рік заготівлі (timber-productionYear) - буде реалізовано у вигляді ручного заповнення, Організатор повинен буде вказати необхідне значення
- Квартал заготівлі (timber-productionQuarter) - буде реалізовано у вигляді ручного заповнення, Організатор повинен буде вказати необхідне значення

Procedure, Timber П:  Незрозуло який пейлоад формувати у випадку реалізації вимоги Створення чернетки/набору чернеток з *.xls/*.xlsx таблиці (опціонально)https://prnt.sc/shazhb. ПС згадували що нададуть офіційно базовий шаблон xls/xlsx.

В: Описано в ТЗ timberEnglish за наступним посиланням:https://gitlab.prozorro.sale/public-projects/documentations/-/blob/master/Timber/timberEnglish/timber-english-general-information.md#%D0%B2%D0%B8%D0%BC%D0%BE%D0%B3%D0%B8-%D0%B4%D0%BE-%D0%BC%D0%B0%D0%B9%D0%B4%D0%B0%D0%BD%D1%87%D0%B8%D0%BA%D1%96%D0%B2-%D0%BF%D0%BE%D0%B7%D0%B0-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BE%D1%8E

Procedure, Timber П: Незозуміло фраза із тк "У випадку невідповідності даних в шаблоні - виводиться повідомлення про необхідність виправленя шаблону." Виводити якісь повідомлення користувачу після завантаженн ексель файлу? Чи робити валадації використовуючи макроси в екселі, щоб уникнути відправки невалідних даних в чернетку яка вже опублікується в цбд.

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

Procedure, Timber П:  Незрозуміло чому потрібно відправляти статус драфт в бід. Раніше чернетка == це не опублікована процедура в цбд. Проте зараз ми відразу повинні публікувати процедури в чернетці в цбд?

В: В питанні мова йде одночасно про бід та про процедуру. В ЦБД-2 і для бідів, і для процедур був статус ДРАФТ. 
При проектуванн ЦБД-3 було прийнято рішення публікувати процедуру одразу в активному статусі, без статусу драфт. Чорновик - локальна копія процедури на майданчику до публікації в ЦБД. Для біда статус драфт залишається. Майданчик публікує бід у статусі драфт, отримує токен, якщо все успішно, використовуючи цей токен, активує процедуру. Драфт тут використовується в якості захисту для того, щоб гарантувати можливість майданчика в майбутньому працювати із цим бідом.
Ця частина описана в ТЗ з процедури timberEnglishhttps://gitlab.prozorro.sale/public-projects/documentations/-/blob/master/Timber/timberEnglish/timber-english-general-information.md#%D1%80%D0%BE%D0%B7%D0%BC%D1%96%D1%89%D0%B5%D0%BD%D0%BD%D1%8F-%D0%B7%D0%B0%D1%8F%D0%B2%D0%B8-%D0%BD%D0%B0-%D1%83%D1%87%D0%B0%D1%81%D1%82%D1%8C-timberenglish
При цьому, майданчик перед публікацією драфту біда в ЦБД, може працювати із чорновиком біда на стороні майданчика.

Procedure, Timber П: Припустимо через 1 рік, що робити із великою к-сю чернеток які будуть опубліковані в цбд і на майданчику також?

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

Procedure, Timber П:  Незрозуміло як опрацьовувати(який признак передавати) для конфіденційних документів в біді. Незрозуміло як відображати конф. документи в різних статусах процедури.

В: ознака public\private у документах. На стороні ЦБД буде валідація, які з типів документів які ознаки підтримують. Майданчик відображає конфіденційні документи учасника тільки для такого учасника та для організатора, який опублікував процедуру.

Procedure, TimberП:  room+timberEnglish. Чи є якесь розуміння як реалізувати розміщення багатьох аукцвонів на одній закладці, можливо є якійсь приклади.

В: основні вимоги у презентаціях, ТЗhttps://gitlab.prozorro.sale/public-projects/documentations/-/blob/master/Timber/timberEnglish/timber-english-general-information.md#%D0%B2%D0%B8%D0%BC%D0%BE%D0%B3%D0%B8-%D0%B4%D0%BE-%D0%BC%D0%B0%D0%B9%D0%B4%D0%B0%D0%BD%D1%87%D0%B8%D0%BA%D1%96%D0%B2-%D0%BF%D0%BE%D0%B7%D0%B0-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BE%D1%8Eта у тест кейсах. Все інше - дизайн інтерфейсу на стороні майданчика і конкуренція майданчиків між собою. Нами приймаються різні варіанти, які будуть відповідати базовим вимогам.

Procedure, Timber П:  В чому різниця між CPV  та CAV-PS?

В: CPV - європейський стандарт, адаптований в Україні. І який може змінюватися тільки якщо були зміни в цьому стандарті.
CAV-PS - наш "стандарт", зібраний за правилами CPV, в який додані коди, яких немає в CPV. Може розширюватися нами самостійно в будь-який момент, коли нам не вистачає кодів (дотримуючись загальні принципи і не перетинаючись з кодами CPV). Плануємо в даного ендпоінті об'єднати ЦІ словники в один. Тому так, в ендпоінт будут вносітіся и Зміни и ДОПОВНЕННЯ.

Procedure, Timber П: Масив x_prepaymentDetails - що це і коли його потрібно заповнити і кому? За свагеру воно необов'язкове і знаходиться в контракті

В: Необов'язкове поле для внесення інформації про передоплату. Дата здійснення передоплати і сума здійснення передоплати

Procedure, Timber , Єдиний інтерфейс П:  Незрозуміло які дії відбуваються за цими запитами і / або як їх пов'язати з єдиним інтерфейсом:

• get/api/ping
• get/api/auctions
• get​/api​/auctions​/{auction_id}
• get​/api​/auctions​/{auction_id}​/feed
• get/api​/auctions​/{auction_id}​/history
• get/api/auctions/{auction_id}/history/{archive_id}
• post/api/auctions/rooms
• get/api​/auctions​/rooms​/{room_id}​/feed

В:  

get/api/ping - This end-point allows to test that service is up.

get/api/auctions - 

List auction objects (вам это скорее всего не нужно)

get​/api​/auctions​/{auction_id} - дает один обьект Auction

get​/api​/auctions​/{auction_id}​/feed - вебсокет который раз в секунду дает вам актуальное состояние данного аукциона

get/api​/auctions​/{auction_id}​/history (это вам скорее всего не надо)

get/api/auctions/{auction_id}/history/{archive_id} (это вам скорее всего не надо)

post/api/auctions/rooms - Create auction room (позволяет создать “комнату” для учасника который одновременно участвует в нескольких аукционах)

get/api​/auctions​/rooms​/{room_id}​/feed - вебсокет который для созданной комнаты отдает актуальное состояние для множества аукционов в случае их изменения (т/е/ будет отдавать обьект если он изменился в базе)

Procedure, Timber П:   documentType:rejectionProtocol даний тип документу використовуємо для відхилення учасника до підписання протоколу та не вказуємо причини відхилення. Але навіщо він також і в дискваліфікації, якщо є документ типу -documentType:act?

 В: Відхилення учасника - через rejectionProtocol без вказання причини.  Дискваліфікація учасника - черезrejectionProtocolабоact + причина з списку.  Повинна бути реалізована можливість дискваліфікації через обидва документи на розсуд Замовника/Організатора.

Procedure, Timber, ЕЦП П:  Чи є особливості роботи з ЕЦП? 

В:

• ЕЦП \ КЕП накладається поза системою. Завантажується в системі окремим файлом (тільки підпис або підписаний файл), в якому прописується поле relatedDocument, де додається посилання на оригінальний документ, вже закруженний в DocumentService.
• за бажанням учасника \ майданчика. Централізоване рішення поки не пропонуємо, це є в беклоге, але терміни реалізації поки невідомі
• за бажанням Організатора, учасника на всіх етапах де йде робота з документами суті (завантаження, оновлення документа), або обов'язково для Організатора, учасника, якщо того вимагає нормативку, такі особливості вказані в ТЗ 
• переважно підпис документів ЕЦП / КЕП необов'язково. Обов'язковість вказана в ТЗ, в тому випадку, якщо цього вимагає нормативку. 
• до будь-якого документу за бажанням або необхідності повинна бути можливість прикріплювати ЕЦП / КЕП
• 2 варіанти: окремо документ підписи і назва \ посилання на оригінальний документ або поруч з оригінальним документів виводити пов'язаний файл підпису

Procedure, Subsoil П: В nadraEnglish учаснику можна редагувати і видаляти пропозицію в статусі active?

В: так, можна

Procedure, Timber П: За яких умов виконується дискваліфікаціф, а в яких відхилення?

В:  можливість відхилити Учасника в Організатора існує за умови лише одного аварду, якщо авардів 2 - відхилення недоступне, лише дискваліфікація

Procedure, Timber П: Чи всі додаткові класифікатори обов'язкові до заповнення?

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

Procedure, Timber П:  У всіх словниках доп класифікаторів ми відображаємо на майданчику uk_UA текстівки, але в timberDiameter вони дублюються (5 різних "штабель")

В: першочергово вибір сортименту, діаметра повинен бути обраний після, коли організатор вибрав сортімет сКруглі то може вибрати діаметр тільки від D1 до D6, в разі вибору "3 група Деревина дров'яна НП" у нього вибір діаметра тільки firewood3NPstack з uk_UA штабель

Procedure, Timber П: Чи повинна в учасника, після аукціону, бути можливість завантажити в свою пропозицію протокол аукціону, тому що при спробі ЦБД повертає   "message":{"documentType":["Value must be one of ['commercialProposal', 'qualificationDocuments', 'eligibilityDocuments', 'x_passport', 'x_IPN', 'x_tenderersRegisterExtract', 'x_nonResidentRegistrations', 'x_nonSanctionedStatement', 'digitalSignature' але тут https://procedure-sandbox.prozorro.sale/api/legal_names/timberEnglish auctionProtocol є documentType:bid

В: Так, при цьому, учасник працює з bid, а замовник з award

Procedure, Timber П: При спробі передати аукціон з discount.discountPercent: 0  помилка: 

Організатор не може створити аукціон без зниження вартості.

В: Повинно бути discount.discount = false а discount.discountPercent не повинен передаватися взагалі

Procedure, Timber П:  Чи правильно я розумію процес завершення аукціону по лісі: організатор переводить контракт в статус active і після цього ЦБД саме завершує аукціон і переводить його в статус complete?

В: За посиланням є відмінна вкладена схема яка це описує https://confluence-sale.prozorro.org/pages/viewpage.action?pageId=57671842

Procedure, Timber П: Дата завершення verificationPeriod і signingPeriod несе тільки інформаційний характер і не впливає на роботу, валідації і тп. Наприклад, у організатора та учасника є можливість завантажувати протокол аукціону поки статус Авард pending, навіть якщо verificationPeriod.endDate вже настав?

В: Для Організатора - робота без обмежень. Для Учасника - має бути можливість завантаження документів в бід лише до завершення award.verificationPeriod

Procedure, Timber П: В чому  різниця між Відхиленням та Дискваліфікацією учасника? 

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

Procedure, Timber П:  Згідно ТЗ - Учасника можна дискваліфікувати навіть коли контракт в статусі active, але при спробі передати в контракт причину дискваліфікації - terminationReason, отримуємо помилку -Forbidden status. Cannot update contract info object with status active, тобто вносити  зміни в поля контракту зі статусом active - заборонено.

В: Поле terminationReason - це поле award, а не контракту, тому з полями контракту не працюємо, відповідно, причина дисквалификації передаєтся до авард, а не до контракту.

Procedure, УЗ П:  В процедурі railwayCargo auctionProtocol  від учасника завантажується в award, вірно?

В: Як і домовлялися із розробниками, з авардом працює тільки Організатор, з бідом працює тільки Учасник. У процедурі railwayCargo робота із протоколом відбувається наступним чином: В обов'язковому порядку протокол завантажує до біда саме учасник. ЦБД автоматично прикріплює такий протокол в авард, де із ним працює вже майданчик Організатора.

Procedure: Чи планується додавання поля auctionId в API процедур, так як майданчики зобов'язані робити всякі посилання на протоколи і для функціональності room, теж потрібен id саме аукціону (НЕ процедури)?

В: В  процедурі вже є поле auctionId яке власне даремний ідентифікатор який ніде всередині системи не використовувався. Щоб не вводити окреме поле для технічного id аукціону вирішено поміняли його апішку таким чином, що тепер цей ідентифікатор і буде ідшніком аукціону в момент його створення. т / е / тепер линка на аукціон буде виглядати як https://ps-auction-dev.kube.raccoongang.com/TIE001-UA-20200706-13315

Procedure: Хотів би уточнити з приводу "звʼязки" уз-надра-ліс: якщо ціквить лише одна з цих процедур, все-одно потрібно реалізовувати усі 3? Чи це стосується лише звʼзку в плані тестування? 

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

Procedure: Чи можливо в свагері додавати коментарі з додатковою інформацією до списків типів документів статусів та подібних структур з офіційними назвами та параметрами обов'язковості та приватності якщо говорити конкретно про список типів документів

В:  в плані є задача додати всю відсутню інформацію про деталі роботи з полями, документами і т.д. до description у swagger. Це не впливає на сумісність

Procedure: При спробі забрати закриту пропозицію учасника з використанням його токену від пропозиції через посилання https://procedure-sandbox.prozorro.sale/api/procedures/5f0c612ed426d8019c61ed09/bids/35d20aea044e4b2b82bf1be22f3be698?acc_token=f9b9c9ea-c7ae-4ed2-bd6a-6da07e766498
отримуємо {"message": "Forbidden. Wrong context"}  в даному випадку, що ця помилка може означати? чи ми маємо використати тут токен від процедури?

В: Не передаете токен площадки (header Authorization)

Procedure, Timber П: В active_qualification у участника должна быть возможность заменять/удалять документы загруженные в bid или у участника есть только возможность подгружать auctionProtocol и digitalSignatureк протоколу? Сценарії timberEnglish-manual

В: В рамках active_qualification, протягом verificationPeriod для учасника доступне завантаження/оновлення/видалення документів типу - auctionProtocol та digitalSignature, що були завантажені Учасником в бід лише протягом verificationPeriod

Procedure, УЗ П: де можна подивитися список причин дискваліфікації по УЗ?

В: Словник буде доданий в ендпоінт зі словниками. Поки його там немає ми надішлемо Вам файл для ознайомлення

Procedure, Timber П: Коли генерується award.verificationPeriod.endDate?

В: 

- періоди verificationPeriod, signingPeriod ЦБД генерує  для авардів в момент набуття ним статусу pending , тому для аварду pending_waiting вони відсутні.
 - ці дати є статичні та не змінються

Procedure, Timber П:  Є такий кейс Сценарії timberEnglish-manual B0% D1% 80% D1% 96% D1% 97timberEnglish-manual-11-08
але ми завжди відхиляємо учасника, а дискваліфікуємо тобто в Авард статус змінюється на unsuccessful, а тут коли він один то треба cancelled слати. Згідно з постановою п.12 гарантійнік при дискваліфікації учасника ми повинні відправляти організатору, це і білінг зламає і з постановою не сходиться. Гарантійний внесок НЕ возвращается особі, позбавленій статусу учасника аукціону, а перераховується оператором, якому внесок БУВ сплачений, організатору аукціону в течение 10 робочих днів з моменту Прийняття рішення про позбавлення такой особи статусу учасника аукціону.

В: У організатора по лісі 2 опції - відхилити учасника, якщо він не готовий продавати одному. Або дискваліфікувати, якщо щось не так з документами

Procedure, Timber П: Питання з приводу обов'язковості завантаження документа x_nonSanctionedStatement. На інтерфейс це теж буде поширюватися і часом не виникне проблеми як з commercialProposal, що учаснику все-таки доведеться завантажувати для кожного лота окремо документ x_nonSanctionedStatement?

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

Procedure, Timber П: Створили рум для аукціонів в статусі "Прийом пропозицій".
Підключаємо сокет auction-sandbox.prozorro.sale/api/auctions/rooms/ddd46c6e0b1144a2b3ca361ae38a9b18/feed
З'єднання встановлюється, а у відповідь тиша. Звідси питання.
У момент з'єднання повинна віддаватися модель аукціону? Може це залежить від статусу процедури? Хотілося б зрозуміти алгоритм взаємодії з цим ендпоінтом.
'X-Request-ID' => 'b0b8498b-5b88-4e3b-9228-4bd52c754eef'

В:  Кімнату слід створювати з id процедури а не аукціону, крім того  аукціон створюється, коли процедура переходить у статус active_auction а id procedure.auctionId генерується при створенні процедури

Procedure, Timber П: Вимоги Погодитись з умовами регламенту ЕТС і відповідальністю учасника та зберегти заяву в якій формі потрібно передавати в цбд?
Чи, можливо, підписання контракту із майданчиком і є погодженням із регламентом ЕТС ?

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

Procedure, Timber П:  Вимоги з ТК Сформована таблиця лотів які відповідають обраним критеріям FF (додаткових класифікаторів лоту) . Ми можемо по-своєму формувати пул лотів з точки зору UI/UX? Чи обов'язково має бути таблиця....?

В: Має бути одна сторінка, на якій учасник бачить всю необхідну для прийняття рішення про участь інформацію про лот, якщо це буде не таблиця - ваше право

 Procedure П: Прошу надати лінк на хоча б якусь доку по бібліотеці для накладання єцп/кеп в аукціонах цбд-3 openprocurement-crypto. Гугл видав пустий репозиторій https://github.com/openprocurement-crypto 

В: На даний момент спеціальної бібліотеки для цбд3 немає, також на даний момент цбд3 НЕ валідірует підпису, тобто можна використовувати будь-які рішення, головне завантажити підпис і прикріпити її до завантаженого документу

Procedure, Timber П: Чи має в ЄІ лісу відображатися після проведення аукціону статус учасника/біда?

В: Так, якщо на майданчику не передбачено іншого варіанту інформування учасника про статус

Procedure, Timber П: Після зміни terminationReason на словник, виходить тепер можна передати тільки 1 причину дискваліфікації?

В:  На даний момент, "1, 2", як і з іншими словниками розшифровка доступнна тут https://procedure-sandbox.prozorro.sale/api/classifiers/timberTerminationReason

Procedure, Timber П: Виникли питання по дескріпшену статусів аукціону (який віддає фід рума через вебсокет), а саме, 'pending' 'pre_round_pause', 'open_pause'? Скільки паузи тривають?

В:  Для англійського аукціону: pending - статус до початку аукціону, pre_round_pause - пауза перед початком раундом, open_pause - пауза між раундами. 

             pre_round_pause - 5m, open_pause - 3m fast, pre_round_pause - 15s, open_pause - 1s

Procedure, Timber П:  Чи є повний довідник статусів?

В:   Для англійського аукціону:  'pending', 'pre_round_pause', 'sequential_round', 'open_pause', 'done'

Procedure, Timber П: Для вебсоккета по учаснику не плануєте ввести окремий статус в стилі "Подача пропозиції"?

В:  Не планувалося. Зараз можна визначити що учасник ходить, за інформацією в public_meta.current_bid_id, public_meta.current_bid_index

Procedure, ЗЕ П: В чому суть зміни з contractTotalValue в contracts http://dl4.joxi.net/drive/2020/06/11/0033/2838/2210582/82/797f24be53.jpg
У договорах зелених було два поля value: 
x_valueUAH - в грн вводив організатор
value - формувало ЦБД в євроцентів
Тепер в договорах відразу 3 різних value
http://dl4.joxi.net/drive/2020/06/11/0033/2838/2210582/82/d5d9d554cf.jpg
За що тепер відповідає кожне з цих полів?

В:  Стосовно ЗЕ:

1. поле value - автогенеріруется з Авард, в євроцентах
   поле contractTotalValue - заповнюється вручну Організатором, підсумкова сума контракту в євроцентах
   поле x_valueUAH - заповнюється вручну Організатором, підсумкова сума контракту в грн.
   За фактом поля contractTotalValue і x_valueUAH - одна і та ж підсумкова сума за контрактом, яку Організатор заповнює вручну, тільки в різній валюті.