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

Мирорр клієнт 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 на три години менший від datePublished?

В: Так як, до ЦБД закладенно 0-й часовий пояс, якщо з датою не передати часовий пояс, то для ЦБД часовий пояс буде 0-вим.

Модуль Аукціону П: Які дії потрібно виконати в разі, якщо модуль аукціонів віддає 500/503 помилку?

В: В виникнення разібудь-яких помилок з кодом 5ХХ та 4ХХ слід заповнити звіт про помилку та передати співробітникам ДП та/або розробникам в публічний канал.

ДС П: Що потрібно робити, якщо при спробі з майданчика зареєструвати документу в ДС (в лот МП) з наступною передачеє до ЦБД майданчик отримує 403 помилку?

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

ЦБД П: В разі отримання майданчиком помилок 4ХХ та 5ХХ варто повторити запит чи одразу оформлювати та Передавати на ДП звіт про помилку?

В: Для запітів від майданчика прцює загальне правило, як і для будь-якого http API — є сенс повторити запит якщо код відповіді> = 500 з великою ймовірністю помилка НЕ повториться. В разі повторення відповіді з помилками 4ХХ та 5ХХ слід заповнити звіт про помилку та передати співробітникам ДП та/або розробникам в публічний канал.

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

В: Вірогідно, в запиті передається пусте поле id. Для отримання коректної відповіді поле id має бути заповненим.

ЦБД П: Майданчик отримує помилку сервера Server error: `PUT https://procedure-sandbox.prozorro.sale/api/procedures/5ebea9d0705317826e2a3e19/documents` resulted in a `500 Internal Server Error` response: {"message": "Internal server error"} у відповідь на запит

[{"title":{"uk_UA":"test7.txt"},"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImRzIn0.eyJpZCI6IjUyMTQ5YTNhZGUwODRhYTdhNDZlMGIyNGMzODUyZWM0Iiwic2NvcGUiOiJwdWJsaWMiLCJmaWxlbmFtZSI6InRlc3Q3LnR4dCIsImRvY3VtZW50VHlwZSI6ImlsbHVzdHJhdGlvbiIsImZvcm1hdCI6InRleHQvcGxhaW4iLCJzaGEiOiI2NGVjODhjYTAwYjI2OGU1YmExYTM1Njc4YTFiNTMxNmQyMTJmNGYzNjZiMjQ3NzIzMjUzNGE4YWVjYTM3ZjNjIiwiaGFzaCI6Im1kNTozZTI1OTYwYTc5ZGJjNjliNjc0Y2Q0ZWM2N2E3MmM2MiIsImRhdGVDcmVhdGVkIjoiMjAyMC0wNS0xNSAxNDo0MDoxNi41Nzg3MzMiLCJpYXQiOjE1ODk1NTM2MTZ9.zF2xnsVfwEKJKH25H3I-4UngKu69ixNw4geVoOXDLfsFKHtR2muxayT5o86O0JefFAklxgrvn72kzGhvLBFy0zRce6J23obJ8fJ6vT5uEPw35sj3dIn7FmF-wGV0du7NX_Q0_lcASqyoz2mtVqM9Qa3cybGgSkkliJtGIxfFYYYdK_lxBHKOmlic1Iu6wz0spPDdsKCmEWjhPfSoAypTYpuO8EgPUwbaOS3OoI4C6BUlauSgGXyqQIbHMa-u6ffyF5dipsZaGrCs4ySSKq_fJDewJEwlrDb88TNggd9W4sjHRyT5T8NRe-p3mOcss3QmCijdXPBx3nYV3POn1kSEWNfjfRU4MzoqL5KJ8WY55ZUcjUiWrRkT6vetf3ViRxyn30mGC-QsawhMEWft4eQOyGCfVvee8pIqj-SE4bX_yCF-dE8LuOtlIxhrvJYTsxyqUIw_sTqcYS6K8FhXXXTne6TMBvkeWic-_GCi-HK7-NKiPJoI2RkYPp-RSeuoT1Zaw-Pm4b84z-5PXuhVsprEXnAtmR32c4j3bPW188SsTeorP8679jytGornT4q3lWSFypSVjcGnTp4ftnpEw_X_kxvu2VjMieJ5N0N_GUufzmnbj4LCMtNk0M3V1i20nUbWwAMYkQH-ogSlXUPxMAhh2HP3pNpX5Uab1QktBURBg0w","documentOf":"auction"}]

В: Наразі проблему в коді виправлено, згідно тікета, по суті цей запит видалить старий документ, та на основі токену, замінити його новим документом.

ЦБД П: З якою метою створений, і де взагалі може використовуватись запит історії процедур: /api/procedures/{procedure_id}/history/{archive_id}.

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

ЦБД П: Чи є, з точки зору історії, сенс оновлювати окремий item, а не всю процедуру?

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

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

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

ЦБД, ДС П: За яким посиланням можна знайти опис взаємодії з ДС?

В: За посиланням https://procedure-sandbox.prozorro.sale/api/doc#/ documentType - через query

ЕЦП П:Чи вірна посладовність дій по роботі з з digitalSignature: 1) завантажити документ, на який буде накладатися ЕЦП, до ДС 2) прикріпити id (отримане з DocumentService) в поле relatedDocument документу digitalSignature?

В: Так, такий порядок дій є вірним, додатково про ЕЦП можна подивитися за посиланням https://confluence-sale.prozorro.org/display/PUB/CDB-3+FAQ 

Процедури:

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

В: Так, така можливість має бути, але завантаження такого документу не є обов'язковою дією

Procedure GE П: Чи можливий такий варіант реалізації, де documentType: clarification буде доступний до вибору гарантованим покупцем на формі створення і редагування аукціону?

В: Реалізація при якій документ clarification буде доступним до завантаження на етапі створення аукціону не є логічним, так як документ clarification має бути доступним вже на етапах active_rectification та active_tendering.

Procedure GE П: З якої причини після виконання наступних дій по процедурі 1) створення процедури 2) відредаговано процедуру, без оновлення документів 3) відправка процедури та запиту на /api/procedures/{procedure_id}/documents/history повертається історія з змінами документу, хоча фактично докумиенти не оновлювались?

В: Так як, з оновленням процедури було передано документи, що не фактично оновлювались, то для них змінилася dateModified, то і запит повертає історію по документам. ЦБД не порівнює дані до апдейту з тими даними, що надходять з оновленням. Якщо з оновленнями процедури буде передано документ і він буде валідним, ЦБД його оновить. Те саме правило працює і для оновлення документу — якщо з оновленням документу будуть передані дані процедури (без змін) і вони будуть валідними, то дані будуть оновлені.

Procedure, Subsoil П: З яких міркувань тип аукцону міститься в назві процедури, а не реалізовано додатковим полем?

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

Procedure П: Чи існує API для отримання мінімальної можливої дати для конкретної процедури?

В: https://procedure-sandbox.prozorro.sale/api/procedures/renewables-fast/auctionPeriod/min_startDate — API повертає мінімальну можливу дату старту аукціону

Procedure GE П: Як визначити максимальну можливу дату початку аукціону, виходячи з вимог описаних в ТЗ - auctionPeriod.startDate має бути встановлено у проміжку - не раніше ніж за 30 календарних днів, але не пізніше 60 календарних днів?

В: Оскільки, максимальна можлива дата це 60 календарних днів, то можна обраховувати на боці майданчика. Необхідність в ендпоїнті зз мінімалною датою виникла через вимогу обраховувати 2 робочі дні + 30 календарних, відповідно максимальна можлива дата це мінімальна можлива дата, які повертає АРІ + 60 календарних дні.

Procedure GE П: Чи має Замовник самостійно вімінити аукціон в разі, якщо статус аукціону active.qualification, а всі аварди мають статус "unsuccessful" та/або "cancelled"?

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

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

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

Procedure GE П: Після підтвердження договору на майданчику має відображати статус award’у — active (Переможець. Очікується договір)?

В: Згідно ТЗ: "Після підтвердження протоколу майданчик змінює статус award’у на active (Переможець. Очікується договір). Після успішного завантаження та підтвердження договору - статус залишається без змін, відповідно, після підтвердження договору змінюється тільки статус award’у — active (Переможець. Очікується договір) остается, меняется только статус contract'у на active

Procedure П: Яким чином можна дізнатися точний час на сервері цбд?

В: На даний момент окремого ендпойнта немає, але в теорії при необхідності/за запитом від майданчиків такий ендпойнт можливо реалізувати.

Procedure П: Чи обов'язково закладати очікування в 2 хвилини при подачі попозиції через автотест?

В: Так, реалізовано мінімальну тривалість active_rectification в 2 хвилини.

Procedure П: Який procurementMethod слід використовувати щоб не чекати закінчення аукціону декілька днів?

В: При використанні fast варіантів процедури можна призначити дату аукціону на now + 5mins

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

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

Procedure, railwayCargo-english П: Як дізнатися перелік доступних id для додаткового класифікатора

В: Доступні варіанти класифікаторів для кожної процедури, можна знайти в Сваггера, в описі потрібної моделі, також о в Сваггера є 2 ендпоінта:

з тегом classifiers - https://procedure-sandbox.prozorro.sale/api/doc#/classifiers — відображає список всіх класифікаторів, що є в системі
по ендпоінту - https://procedure-sandbox.prozorro.sale/api/classifiers/{classifier} (https://procedure-sandbox.prozorro.sale/api/classifiers/timberEnglish-species) — відображає всі варіанти id для потрібного класифікатора

Procedure GE, Subsoil П: Чи вірно, що функції cancel_admission()  в AwardsApi використовується для того, щоб відмінити авард, який знаходиться в статусі pending_waiting і є відмовою учасника, що зайняв друге місце, від очікування?

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

Procedure GE П: Чи достатньо буде для учасника використовувати лише IBAN?

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

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

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

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

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

Procedure, Subsoil П: В якому форматі майданчик має передавати час та дату проведеня аукціону?

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

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

В: Так, sellingMethod існує і може бути використаний без обмежень. Докладніше про різні sellingMethod можна подивитися за посиланням: https://gitlab.prozorro.sale/prozorro-sale/procedure/-/tree/master/specs

Procedure, timberEnglish П: Як на тестовому середовищі збільшити час відведений на раунд з 1 хвилини до 3 хвилин?

В: Слід використовувати sellingMethod який більше підходить за харрактеристиками. Докладніше про різні sellingMethod можна подивитися за посиланням: https://gitlab.prozorro.sale/prozorro-sale/procedure/-/tree/master/specs

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

В: Словник для поля auctionRestriction.loadObject за посиланням https://procedure-sandbox.prozorro.sale/api/classifiers/objectLoadUnloadOrExclusionRange

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

В:Так, перераховані документи обов'язково мають бути приватними.

Procedure, timberEnglish П: З якої причини procurementMethod = timberEnglishEnglish, а не простоtimberEnglish?
В: procurementMethod = timberEnglisа не просто timber, через те що запланована реалізація ще одиного типу процедури - timberMultiAwards (перевернутий "стакан")

Procedure, timberEnglish П: Чи будуть для timberEnglish та timberMultiAwards реалізовані режими -fast які використовуються для тестування?

В:Так, такі режими будуть реалізовані і будуть доступні.

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

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

Procedure, timberEnglish П: Яке значення відображає поле items.0.unitValue ?

В: Дане поле відповідє полю на "Ціна лоту за 1 м3" інтерфейсі.

Procedure, timberEnglish П: Які значення True або False мають приймати value.valueAddedTaxIncluded та unitValue.valueAddedTaxIncluded?

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

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

В: В рамках timberEnglish.Items: 

в масиві unitValue, Організатор вказує - стартову ціну за 1 м.куб, 

в поле quantity, Організатор вказує - розмір партії дерева в лоті.

В рамках timberEnglish.TimberEnglishProcedure:  

масиві value, Організатор вказує - стартову ціну лота (розміру партії дерева). За коректність введення цих даних на боці Організатора з урахуванням поточної валідації в свагері

Procedure, timberEnglish П: Які дані мають міститися у полі LotId якщо tenderAttempts = 1?

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

і вручну не заповнюється.

Procedure, timberEnglish П: Чи має бути поле minNumberOfQualifiedBid sreadOnly?

В: Для процедури timberEnglish є можливість його змінювати.

Procedure, timberEnglish П: Якщо 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, timberEnglish П: Яка мета реалізації поля discount?

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

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

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

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

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

Procedure, timberEnglish П: Яка струткура поля spec?

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

Procedure, timberEnglish П: Як буде реалізовано додаткові класифікатори?

В: Додаткові класифікатори будуть реалізовані у вигляді як словників (значення будуть обиратися зі словника) так і просто заповнюватися вручну (без словника).

Procedure, timberEnglish П: Які дані по 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, timberEnglish П: Який шаблон використовувати для реалізації вимоги Створення чернетки/набору чернеток з *.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, timberEnglish П: Необхідне роз'яснення пункту з тк "У випадку невідповідності даних в шаблоні - виводиться повідомлення про необхідність виправленя шаблону".

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

Procedure, timberEnglish П: З якою метою потрібно відправляти статус драфт в бід, адже чернетка == це не опублікована процедура в ЦБД?

В: В питанні мова йде одночасно про бід та про процедуру. В ЦБД-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, timberEnglish П: Як чинити з чернетками, що з часом накопичуватимуться в ЦБД і на майданчику?

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

Procedure, timberEnglish П: Як майданчик має опрацьовувати та відображати та яку ознаку передавати для конфінденційних документів, що містяться у біді?

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

Procedure, timberEnglish П: Як реалізувати розміщення багатьох аукцвонів на одній закладці в рамках реалізації 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, timberEnglish П: В чому різниця між CPV  та CAV-PS?

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

Procedure, timberEnglish П: Ким і коли заповнюються дані масивуя _prepaymentDetails – що міститься находиться в контракті?

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

Procedure, timberEnglish, Єдиний інтерфейс П: Які дії виконуються або як пов'язати перелічені запити з єдиним інтерфейсом:

• 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, timberEnglish П: Для чого для дискваліфікації використовується два документи?

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

Procedure, timberEnglish, ЕЦП П:   Які особливості роботи з ЕЦП? 

В:

• ЕЦП \ КЕП накладається поза системою. Завантажується в системі окремим файлом (тільки підпис або підписаний файл), в якому прописується поле relatedDocument, де додається посилання на оригінальний документ, вже закруженний в DocumentService.

• за бажанням учасника \ майданчика. Централізоване рішення поки не пропонуємо, це є в беклоге, але терміни реалізації поки невідомі

• за бажанням Організатора, учасника на всіх етапах де йде робота з документами суті (завантаження, оновлення документа), або обов'язково для Організатора, учасника, якщо того вимагає нормативку, такі особливості вказані в ТЗ 

• переважно підпис документів ЕЦП / КЕП необов'язково. Обов'язковість вказана в ТЗ, в тому випадку, якщо цього вимагає нормативку. 

• до будь-якого документу за бажанням або необхідності повинна бути можливість прикріплювати ЕЦП / КЕП

• 2 варіанти: окремо документ підписи і назва \ посилання на оригінальний документ або поруч з оригінальним документів виводити пов'язаний файл підпису

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

В: Так, можна

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

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

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

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

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

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

Procedure, timberEnglish П: Чи повинна в учасника, після аукціону, бути можливість завантажити в свою пропозицію протокол аукціону?

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

Procedure, timberEnglish П: При спробі передати аукціон з discount.discountPercent: 0 Цбд повертає помилку та унеможливлює створення аукціону без зниження вартості.

В: В разі, якщо аукціон без зниження вартості, discount.discount = false а discount.discountPercent не заповнюється і не передається

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

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

Procedure, timberEnglish П: Які особливості завантаження протоколу аукціону Учасником та Організатором в разі настання та verificationPeriod.endDate?

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

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

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

Procedure, timberEnglish П: Згідно ТЗ - Учасника можна дискваліфікувати навіть коли контракт в статусі active, але при спробі передати в контракт причину дискваліфікації - terminationReason, майданчик отримує помилку помилку

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

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

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

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

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

Procedure: Чи слід реалізовувати всі процедури УЗ, Надра, Ліс, в разі якщо планується прцювати не з усіма, а з окремими процедурами?

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

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

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

Procedure: При спробі забрати закриту пропозицію учасника з використанням його токену від пропозиції майданчик отримує помилку: {"message": "Forbidden. Wrong context"}?

В: Дана помилка виникла, через те, що майданчик запитом не передавав токен майданчика (header Authorization)

Procedure, timberEnglish П: Чи має у учасника під час  active_qualification можливість заміняти/видаляти документи, що було завантажено до bid чи у учасника є можливість вантажити тільки auctionProtocol и digitalSignature до протоколу? 

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

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

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

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

В: 

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

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

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

Procedure, timberEnglish П:  Чи обов'язковим є завантаження документу x_nonSanctionedStatement?

В: Так, даний документ є обов'язковим до завантаження.

Procedure, timberEnglish П: Чи є документ x_nonSanctionedStatement унікальним для кожного аукціону?

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

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

Procedure, timberEnglish, ЄІ П: З якої причини після створення руму в статусі "Прийом пропозицій" та підключення сокету auction-sandbox.prozorro.sale/api/auctions/rooms/ddd46c6e0b1144a2b3ca361ae38a9b18/feed, та встановлення успішного з'єднання майданчик не отримав відповідь?

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

Procedure, timberEnglish П:  Через які зміни ЦБД віддала неповну модель даних по руму? 

В: З оновленням було видалено об'єкт procedure, а  об'єкт bids приховали в стейт, решта даних не змінювалася.,

Procedure, timberEnglish П: Яким чином майданчик має передати до ЦБД дані погодження з умовами регламенту ЕТС і відповідальністю учасника?
Чи, можливо, підписання контракту із майданчиком і є погодженням із регламентом ЕТС ?

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

Procedure, timberEnglish П: Виходячи з вимог Які є вимоги до формування пулу лотів з точки зору UI/UX?

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

Procedure, timberEnglish П: Як для ЄІ має бути реалізовано вимогу “Погодитись з умовами регламенту ЕТС і відповідальністю"

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

 Procedure П:  За яким посиланням можна ознайомитися з бібліотекою для накладання єцп/кеп в аукціонах цбд-3?

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

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

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

Procedure, timberEnglish П: Чи є актуальним для процедури timberEnglish (ЦБД3) питання стоверння чернеток аукціонів з xls файлу (один файл - багато чернеток)?

В: Так, це залишається актуальним.  Шаблон документа https://docs.google.com/spreadsheets/d/1vE-_1qc7ydWq1jyO0WfzvdYNGCx6tRCUSnL5KCOTzFk/edit#gid=1148486548

Procedure П:  За яким посиланням можна ознайомитися з переліком причин скасування аукціону?

В: Причини дискваліфікації Учасника timber
https://procedure-sandbox.prozorro.sale/api/classifiers/timberTerminationReason
Причини дискваліфікації Учасника subsoil
https://procedure-sandbox.prozorro.sale/api/classifiers/subsoilTerminationReason
Причини скасування аукціону subsoil
https://procedure-sandbox.prozorro.sale/api/classifiers/subsoilCancellationReasons

Згідно ТЗ timber-english, можна вказати одну або декілька причин дискваліфікації учасника.

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

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

Procedure, timberEnglish П: Яка тривалість Яка тривалість пауз МА , а саме  pending - статус до початку аукціону, pre_round_pause - пауза перед початком раундом, open_pause - пауза між раундами. 

  В: Тривалість пауз наступна: pre_round_pause - 5m, open_pause - 3m fast, pre_round_pause - 15s, open_pause - 1s

Procedure, timberEnglish П: Де можна ознайомитися з повним довідником статусів?

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

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

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

Procedure П: У яких випадках не формується посилання на участь, за умови продуктивного статусу?

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

Procedure, GE П: З якою метою в процедурі реалізовано три різні поля для валюти value, contractTotalValue і x_valueUAH?

В: Для процедури Зелена енергетика реалізовано наступні поля для наступних даних:

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

Procedure, timberEnglish П: Чи має учасник вказувати quantity (Розмір Частки квоти) в заяві?

• В: У процедурі timberEnglish учасник купує весь об'єм

Procedure, timber П:  Чи можлива часткова участь у процедурі timberEnglish?

В: Для простого timberEnglish- учасник купує весь об'єм, тільки для timber-multiAwards буде поле quantity

Procedure, timberEnglish П: З яких причин для процедури timberEnglish не реалізовано поле auctionPeriodShouldStartAfter?

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

Procedure П: В якому вигляді слід передавати для роботи з наступним endpoint:  https://procedure-sandbox.prozorro.sale/api/doc#/Invalid%20Swagger/delete_api_procedures__procedure_id__contracts__contract_id__documents__doc_id_

В:  Посилання має мати вигляд: /api/procedures/{procedure_id}/contracts/{contract_id}/documents/{doc_id}?acc_token=procedure_owner_token

Procedure П: З яких причин при спробі видалити документи учасником в verification period, майданчик отримує наступну помилку:

[headers] => Array
        (
            [0] => HTTP/1.1 500 Internal Server Error
            [Date] => Thu, 30 Jul 2020 11
            [Content-Type] => application/json; charset=utf-8
            [Content-Length] => 36
            [X-Request-ID] => 987094a9-48f6-418a-b629-75cf7af496b4
            [Server] => Prozorro
        )    [body] => Array
        (
            [message] => Internal server error
        )    [raw] => {\“message\“: \“Internal server error\“}
    [code] => 500
)

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

Procedure, Subsoil П:  Чи має можливість у Учасника №2 (pending_waiting) повернути гарантійний внесок, за умови що контракт знаходиться в статусі active процедура в статусі pending_admission?

В: Така можливість, за описаних умов ,має бути 

Procedure, П: Про що свідчить наступна помилка, що виникає при спробі публікації аукціону  майданчик отримує помилку: {\"message\": {\"auctionPeriod\": {\"startDate\": [\"Could not parse 2020-08-14T14:25:00.000Z as date\"]}}}

В Наведена помилка виникає через заборону з боку майданчика передавати час проведення аукціону, але дату передавати дозволяється, так як час проведення аукціону генерується на боці ЦБД.

Procedure, П:  Яка суттєва різниця між роботою зі sandbox та sandbox?

В: Основними відміностями між роботою зі sandbox та sandbox наступні: останні зміни викладені на на sandbox, на staging потраплять за 1-2 тижні, після тестування на sandbox.  На staging може знаходитись тільки версія, яку можна одразу, за потреби, викладати на production, без тестування майданчиками цієї версії на sandbox, нести щось на staging не можемо. Рекомендуємо майданчикам працювати одночасно з 2ма версіями: sandbox для розробки і тестування, перевірки нових фіц ЦБД. Staging для стабільної роботи, демо клієнтам (на проді тестових процедур не буде), перевірки майданчика перед викладенням на прод і т.д. Якщо працюєте лише зі стейджингом - постійно будуть затримки + буде вирогідність, що на sandbox буде пропущене щось, що важливе саме для вашого майданчика. 

Procedure, timberEnglish , П: Про що свідчить наведена помилка, що виникає при створенні аукціону з документами отримуємо помилку "msg": "{\"message\": {\"documents\": {\"0\": {\"id\": \"UUID hex required\"}}}"

В: Наведена помилка виникає через спробу майданчика передати "_id" : ""з об'єктом документу, в той час як для роботи з документами є окремі ендпоінти і слід використовувати їх: /api/procedures/{procedure_id}/bids/{bid_id}/documents  (POST и PUT)

Procedure, timberEnglish , П: Ким, при дискваліфікації після Завантаження contractSigned  переводить  award в статус unsuccessful, ЦБД чи майданчиком?

В: Статус контракту змінюється майданчиком, а статус award змінює ЦБД

Procedure, timberEnglish , П: За наявністтю якої ознакою в ЦБД-3 можна визначити, що документ був видалений після публікації процедури? Як, дивлячись на респонс цбд-3 можна побачити відмінність між видаленим і заміненим документом?

В: Для видалення / редагування документів є окремі ендпоінти (patch і delete методи)  крім того,  віддалені документи залишаться в історії.

Procedure, timberEnglish , ЄІ П:  Чи закладено обмеження та вимоги по кількості аукціонів, в яких, через ЄІ, учасник може брати участь? 

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

Procedure, timberEnglish , П: З якої причини статус Учасника 2 не змінився на cancelled автоматично, після того як для аварду було завантажено та підтверджено договір, тобто кваліфікація 1-го award'у пройшла успішно, та Організатор аукціону підтвердив виконання умов договору для 1-го award'у?

В: За описаних умов ЦБД переводить авард в статус pending_waitingвcancelled  при переведенні процедури в статус complete, це відбувається через те, що у Організатора зберігається право дискваліфікувати учасника, навіть після підтвердження договору.

Procedure, П: Чи має бути доступним видалення документів з Bid під час awardVerificationPeriod в статусі процедури active_qualification

В: а етапі кваліфікації видалення документів біда (якщо вони були завантажені до аукціону) не має бути доступним, але якщо документ (наприклад протокол) завантажили на етапі кваліфікації, до зміни статусу на наступний, має бути доступний стандартний функціонал роботи з документами.

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

В: Для роботи з видаленням/ редагуванням документів є окремі ендпоінти (patch і delete методи), крім того видалені документи залишаться в історії.

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

В: В тому разі, якщо видаляти/ замінювати весь список (put), то по Респонс ви ніяк не виявити, але видалені документи залишаться в історії.

Procedure, П: Чи існує можливість створення аукціону для тестування на +10 хвилин від поточного часу?

В: Для маніпуляції з часовими параметрами слід використовувати тестові процедури з прискореннями, докладніше за посиланням: https://gitlab.prozorro.sale/prozorro-sale/procedure/-/tree/master/specs

Procedure, П: Які особливості роботи з параметрами дати та часу початку аукціону для режимів fast та режимук симуляції продуктивного аукціону?

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

Procedure, П: За яких умов учасник має змогу відредагувати закриту пропозицію та документи до неї?

В: Редагування bid та документів біда, які були завантажені до початку кваліфікації, на наступних стадіях не має бути доступним. Але у деяких випадках можлива робота з документами після початку кваліфікації (більше документів для зеленої енергетики, протокол учасника для інших процедур). Тоді заміна\видалення і т.д. доступне для цих документів, але теж не для тих, які завантажені на попередньому етапі.

Procedure, П: Чи може бід мати статус invalid ?

В: На даний момент даний статус зустрічаєтьс в голландських аукціонах

Procedure, railwayCargoEnglish, П: Чи мають майданчики для процедури  railwayCargoEnglish відображати ВСІХ учасників аукціону після завершення МА, якщо реалізується лише функціонал учасника?

В: На майданчику відображається інформація по award'у, що кваліфікується:
     - Повна юридична назва Учасника (bids.tenderers.identifier.legalName)
     - Розмір цінової пропозиції (bids.value.amount, bids.value.currency)
     - Статус award'у (award.status)
     - Документи Учасника (bids.documents)
     - Терміни на завантаження протоколу (award.verificationPeriod.startDate — award.verificationPeriod.endDate)

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

Procedure, П: Чи планується розробка АРІ аналогічне до room для процедури продажу деревини для інших процедур?

В: Технічно це можливо у різних процедурах, але юридично це дозволено поки тільки у деревині

Procedure, П: Чи описано документом очікуване представлення для клієнтів історії змін документів, зараз ендпоінт повертає список зі списків об'єктів Documents? 

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

Procedure, timberEnglish , П: В яких статусах можливо скасувати аукціон?

В: Скасування  можлива для усіх статусів процедури, крім : active_auction та термінальних

Procedure, timberEnglish , П: Що означає повідомлення в МА "З'єднання з cервером модулю аукціону втрачено"?

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

Procedure, timberEnglish , П: Чи має створюватися room за умови наявності лише одного учасника?

В: Ні, аукціони з одним учасником, не мають потрапляти до room, так як для таких аукціонів МА не запускається, а переходить одразу до кваліфікації.

Procedure, timberEnglish, П: Як відрізнити документи завантажені Учасником, а які Організатором?

В: Учасник завжди вантажить документи в бід, а Організатор завжди вантажить документи в авард.

Procedure, timberEnglish, П:  Які параметри налаштування слід обрати, для того щобможливість створення аукціону для тестування на +10 хвилин від поточного часу?

В:  Для створення тестових процедур з заданими параметрами часу  слід використовувати потрібний тип проискорення -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.  За нормативка не пердбачає завантаження з боку Організатора, але з боку ДП додано цю опцію як можливість, як  додатковий механізим контролю. Це працює так само, як і в інших процедурах для учасника, що не призводить ні до яких змін. Відповідно в ідеальному світі, згідно нормативки:

• протокол завантажує учасник
• підтверджує Організатор

Procedure, timberEnglish, П: З яких причин  при спробі  додати протокол в bid учасника через ендпоінт ​ PUT /api​/procedures​/{procedure_id}​/bids​/{bid_id}​/documents  у  відповідь цбд повертає помилку {"message": "Forbidden state - active_qualification. Cannot update bid document list in current state"}

В: Помилку у відповіть  надходить через те, що PUT  у даному статусі заборонений, так як PUT  дозволяє "видалити" раніше завантажені документи. Слід використовувати POST замість PUT, який дозволяє тільки додати нові документи.

Procedure, timberEnglish, П: Чи може майданчик повторно не передавати документи до ДС (документ сервісу), а перевикористовувати, якщо документи були раніше завантажено і відомі JWT  токен документу і сам документ має такі ж documentType, scope та md5:hash  як і раніше завантажений?

В: Не тільки можна, а і потрібно, так як відразу така робота з ДС і планувалася.

Procedure, П: Чи можливо реалізувати використання в параметрі Documents.relatedDocument для digitalSignature не ID документу в якості ідентифікатора а його токен?

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

Procedure, timberEnglish, П: Чи можливо отримати історію документів прямим запитом: використовуючи для цього два ндпроїнти:   api/procedures/{procedureId}/documents/ та api/procedures/{procedureId}/documents/history? 

В: Так, таку можливість реалізовано.

Procedure, timberEnglish, П: Чи нормальною є ситуація, при якій після внесення змін owner зникає доступ до "старих" процедур на sandbox? 

В: Так, така ситуація є нормальною для sandbox.

Procedure, timberEnglish, П: Про що свідчить наступна помилка, отримана при спробі дискваліфікації єдиного учасника: 
   "BODY": {
        "message": {
            "status": "No matching documents: ('rejectionProtocol',)"
        }
    },
    "HEADERS": {
        "0": "HTTP\/1.1 422 Unprocessable Entity",
        "Date": "Wed, 02 Sep 2020 11",
        "Content-Type": "application\/json; charset=utf-8",
        "Content-Length": "72",
        "X-Request-ID": "70fc0949-c3c7-4d8c-b985-0f72dd1694ca",
        "Server": "Prozorro"
    }
}

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

Procedure, timberEnglish, П: З якої причини  після успішної кваліфікації 1-го award'у  та підтвердження Організатором аукціону виконання умов договору для 1-го award'у  ЦБД  автоматично не змінила статусу 2-го award'у на cancelled?  

В: За описаної ситуації ЦБД переводить авардpending_waiting, статусcancelled  буде присвоєним при переведенні процедури в статусcomplete. Така реалізація обумовлена можливісттю Організатора дискваліфікувати учасника навіть після підтвердження договору.

Procedure, timberEnglish, П: Про що свідчить повідомлення   "З'єднання з cервером модулю аукціону втрачено", що відображається в МА? 

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

Procedure, timberEnglish,  ЄІ, П:  Яка повідінка є вірною, в разі, якщо в аукціоні є лише 1 учасник і спробі для такого аукціону створити руму? 

В: Так, як за умови, що учасник тільки один, то МА не буде запускатися, отже такий аукціон не повинен додаватися до руму.

Procedure, timberEnglish, П: З якої причини при спробі  перевести авард в статус cancelled  (з боку учасника)  помилка: "Cannot refuse awarding in current state"?

В: Для того, щоб не виникала подібна помилка не виникала, слід  використовувати токен бід, а не acc token.

Procedure, timberEnglish, П: З якої причини при спробі Організатором дискваліфікувати єдиного учасника виникає помилка:  

HTTP response body: {"message": {"status": "No matching documents: ('rejectionProtocol',)"}}
В: Виходячи з текству помилки,  майданчик "кладе" rejectionProtocol  не в авард.

Procedure, timberEnglish, П: Чи має бути у Організатора можливість видаляти документ "Лот аукціону"?

В: Так як це  обов'язковий документ, то Організатор спочатку може завантажити новий документ, а потім видалити попередній.

Procedure, timberEnglish, П: Де можна подивитися на задокументовану інформацію по МА?

В: Наявну інформацію можна переглянути за посиланнями: 
https://live.staticflickr.com/65535/50293430777_904d2c3166_o.png

https://live.staticflickr.com/65535/50293430777_904d2c3166_o.png

        https://live.staticflickr.com/65535/50293431437_51bcb0594d_o.png

Procedure, timberEnglish, П:  Де можна знайти інформацію про гарантійний та  реєстраційний внести в процедуріtimberEnglish?

В:  В постанові КМУ "Про реалізацію експериментального проекту щодо проведення електронних аукціонів з продажу необробленої деревини"

Procedure, timberEnglish, П: З якої причини при передачі запиту (сандбокс, timber-multiAwards-fast-manual)

майданчик у відповідь  отримує наступну  помилку: 

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

Procedure, timberEnglish, П: Де можна подивитися коректне значення для патерна UA-IBAN? 

В: Для України IBAN - 2 символа латиниці і будь-якому регастрі та  27 цифр.

Procedure, timberEnglish, П:   З якої причини немає можливості змінити статус award з pending_waiting  на cancelled, а при спробі змінити  повертається  помилка “wrong context”?

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

Procedure, timberEnglish, П:  З яких причин при спробі присвоїти статус unsuccessful отримуємо помилку:

В:   Така помилка виникає через порушення порядку роботи з ендпоінтами. Вірний порядок наступний: 

1. PATCH/api/procedures/{procedure_id}/awards/{award_id}
2. PATCH/api/procedures/{procedure_id}/awards/{award_id}/status

Procedure, timberEnglish, П:  З якою метою до процедури timberEnglish було додано registrationFee  та які особливості роботи з ним? 

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

Procedure, timberEnglish, П:  Чи може поле registrationFee  бути пустим чи не відповідати тарифній сітці? 

В:  Тарифна сітка первина, майданчик одержує реєстраційний внесок відповідно до тарифної сітки. За коректність заповнення даного поля ( та за заповнення поля в цілому)  лежить на Організатору, але майданчик Організатора може таке поле заповнювати автоматично або обмежувати  переліком допустимі значення. Крім того в 4 кравталі 2020 року планується готовність та передача майданчикам   ендпоінт  на який можна буде орієнтуватися при роботі з registrationFee. Але, так як тарифні сітки можуть змінюватися, то можливість заповнення поля вручну зберігатиметься.

Procedure, railwayCargo-english, П: В яких випадках, процедура при наявності одного біда може набувати статус unsuccessful, а не переходити до створення аварду та його кваліфікації? 

В: Така поведінка є нормальною в разі. якщо minNumberOfQualifiedBids = 2. Тобто, Організатор, при створенні процедури (або за замовчуванням) для початку кваліфікації необхідно два учасника, а на аукціон "прийшов" лише один.

Procedure, railwayCargo-english, П: Який розмір  гарантійного та реєстраційного внесків? 

В: При розрахунку вказаних внесків слід орієнтуватися на документ: Постанова КМУ "Про реалізацію експериментального проекту щодо проведення електронних аукціонів з продажу необробленої деревини"
https://www.kmu.gov.ua/npas/pro-realizaciyu-eksperimentalnogo-pr-a1178

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

В:  В railwayCargo-english  в рамках кваліфікації учасник може працювати тільки з auctionProtocol.

Procedure, П: Чи має майданчик реалізовувати та відображати необов'язкві поля?

В: Майданчик має дати змогу користувачу заповнити всі поля, тобто вивести і обов‘язкові, і необов’язкові. форма, групування, типи елементів і т.ін. майданчик визначає на свій розсуд таким чином, щоб прийняте рішення не конфліктувало з форматом даних, який очікує ЦБД.

Procedure, timberEnglish,  ЄІ, П: Які дані має містити поле bidder_id  в работі з аукціонами (єдиний інтерфейс)?

В:  Це поле відповідає полю bid_id в процедурах, але дані поля потрібні лише на моменті створення руму (кімнати) і має вказуватися для кожного аукціону окремо, коли рума вже створена передавати ці дані вже не потрібно передавати. 

Procedure, RailwayCargoDutchProcedure, П: З яких причин так багато полів, майданчики мають передавати до ЦБД, а тільки dutchStepQuantity не достатньо?

В:  На даний  момент ситуація наступна: 
dutchStepQuantity - по дефолту 99
dutchStepPercent - по дефолту завжди 1
dutchStepValue - дані об'єкту автогенеруються 

Відповідно, за необхідності  достатньо змінити значення для dutchStepQuantity и dutchStepPercent або залишити дефолтні значення (у цьому випадку нічого передавати не потрібно).

Procedure, П: Де можна переглянути переліки офіційних назв процедур? 

В:  Переліки процедур та їх офіційні (юридичні  назви) можна переглянути за посиланням: https://gitlab.prozorro.sale/prozorro-sale/procedure/-/issues/614

Procedure, П: Про що свідчить  помилка при переході за посиланням на аукціон:  Have a trouble? 

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

Procedure, П: Чи реалізовано в ЦБД-3 перенесення аукціонів, в разы спроби Організатора опублікувати процедуру на вихідний або святковий день? 

В:  ЦБД не переносить аукціони, а або дозволяє опублікувати процедуру, або ні. Додатково до звичайного календаря ЦБД "дивиться" на словник державних свят. 

Procedure, П: При накладенні digitalSignature на документ, з яким id  він має бути пов'язаним з id  чи з ds_id?

В: Має бути пов'язаним з id

Procedure, railwayCargo-dutch,  П:  Які особливості режиму railwayCargo-dutch-initial-auction-real?

В:  В цьому режимі процедура стартує одразу з МА, але його голандський етап триває 6+ годин.

Procedure, П:  Яка процедура тестування, у випадку розробки функціоналу для учасника, яким чином можна для тестування створювати необхідні ситуації, з боку організтора?

В:  Зазвичай використовують такі варіанти:

Публікація аукціонів на одному з інших майданчиків (треба домовитись, щоб вам там надали тестовий кабінет)

Самостійна публікація необхідних процедур\створення ситуацій напряму у ЦБД за допомогою postman або інших інструментів

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

Procedure, П: Які дії та з якими документами учасник може виконувати в рамках verification period?

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

Procedure, П:  Які є варіанти  присвоєння document.id який присвоює ЦБД документам, після публікації процедури? 

В:  Варіантів декілька: 

 реалізувати логіку, за якою  беруться всі document.id присвоєні ЦБД і співставляти їх з локальними токенами документів, які були попередньо завантажені

реалізувати логіку, за якою робота з кожним документом (створення, оновлення, видалення) відбувається окремо

Procedure, П:  Яким чином, у випадку розробки функціоналу для учасника, можна (для тестування) створювати необхідні ситуації, з боку організтора? 

В:  В разі розробки тільки функціоналу Учасника, доступні наступні варіанти:  1. Публікація аукціонів на одному з інших майданчиків (треба домовитись, щоб вам там надали тестовий кабінет) 2. Самостійна публікація необхідних процедур\створення ситуацій напряму у ЦБД за допомогою postman або інших інструментів 3. Розробка власного мінімального інтерфейсу для організатора, через який можна виконати базові дії

Procedure, П:  Чи прив'язаний JWT токен з DS  до майданчика і чи допустимо використовувати один і той самий JWT токен для кількох майданчиків (клонів)? 

В: JWT токен з DS  до майданчика не прив'язано і итакий токен, потенційно може бути використаним для кількох майданчиків. 

Procedure, П:  Наскільки небезпечною є ситуація, якщо  коистувач на вкладці network  знайде JWT токен документу?,

В: Токен визначає володаря документу, відповідно той у кого токен може виконувати з ним деякі дії (прочитати, прикріпити до процедур) видалити документ він не зможе, тобто за негативного сценарія, що може бути володар токенв може отримати  можливість прочитати приватні документи за допомогою токена власника

Procedure, timber-multiAwards, П:   Яка офіційна назва процедури timber-multiAwards?

В:  Всі назви процедур будуть перераховано за посиланням: https://procedure-sandbox.prozorro.sale/api/legal_names

Procedure, railwayCargo-dutch,  П:  В тест кейсах по процедурі вказано "Публікація та активація заяви на участь під час DUTCH PART”. Учасник має можливість подавати заяву на участь лише протягом tenderPeriod до завершення Dutch Part. В якому полі приходить інформація про Dutch Part?

В: В голандському варіанті процедури tenderPeriod триває до завершення Dutch Part

Procedure, railwayCargo-dutch,  П: В свагері для процедури railwayCargoDutch є два поля minimalStep та dutchStep з однаковим legalName “Розмір кроку аукціону“. В чому різниця між ними?

В: Тут minimalStep автогенерується api

Procedure, railwayCargo-english, П: Підкажіть, як отримати протокол про результати аукціону у JSON або YAML форматах?

В:  https://auction-sandbox.prozorro.sale/api/auctions/TIE001-UA-20200929-59003/protocol- json
https://auction-sandbox.prozorro.sale/api/auctions/TIE001-UA-20200929-59003/protocol/yaml- yaml

Procedure, lease, П: В структурі даних БДК для entity не вказано broker, проте в описі функційЗміна адміністратора організаціїтаБлокування/розблокування користувача(пункт 4.3) викорисовується broker організації. Або все таки мається на увазі broker користувача, або треба розширити entity на broker?

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

Procedure, lease, П:  Згідно ТЗ Орендодавець - підтверджувач дій по об'єкту: визначається шляхом приналежності до організації, EDR-ID якої прописано в полі полі organizingEntity для кожного об'єкту в БДР. Має наступні повноваження:

• активація об'єкт, первинно створений власником об'єкту 
• підтвердження зміни значення listType об'єкту, виконаної власником об'єкту
• завантаження в ДСх документів і асоціація їх зі своїм об'єктом
• завантаження в ДСх документів і асоціація їх з заявками, що прикріплені до його об'єкта

Відповідно, згідно https://prozorrosale.slack.com/archives/C019HQJKQ15/p1599822030016600 Орендодавець(підтверджувач дій по об'єкту) може створювати registry.RealEstate, registry.JointPropertyComplex,  registry.Vehicle, registry.OtherProperty.

В: Інформацію про інші організації заповнює орендодавець. Часто він співпадатиме з балансоутримувачем (хоча не завжди)

Procedure, lease, П: Орендодавець(підтверджувач дій по об'єкту) == sellingEntity ?

В: Так, все вірно

Procedure, lease, П: Стосовно "Інформацію про інші організації заповнює орендодавець" - чи означає це, шо  при створенні об'єкту Орендодавець вручну вносить дані по всім іншим ролям в relatedOrganizations ?

В: Так. Там з обов’язкового Балансоутримувач, інші - опціональні (і де юре, і де факто)

Procedure, lease, П:Чи мають майданчики  для переліків реалізовувати пошукові фільтри?

В: Для першого етапу достатньо інтерфейсу у якому можливо: 

1. Опублікувати об'єкт з усіма доступними полями 
2. Додати документи до цього об'єкту
3. Редагувати цей об'єкт

В подальшому: 
Фільтри, відображення усіх об'єктів з переліку, робота з заявками

Procedure, lease, П: Чи потрібно по оренді створити нову роль організатора, який зможе додавати об'єкти в реєстр, а потім у перспективі створювати з цього об'єкту аукціон, так?

В: Так, мінімально має з’явитись роль “орендодавець“, яка дозволятиме створювати і редагувати власні записи в реєстрі

Procedure, lease, П: Чи достатньо, для передачі  на тестування щоб на майданчику відображався список власних створених об'єктів? тобто можна поки не відображати об'єкти інших майданчиків, поки не буде розроблено функціонал міррора?

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

Procedure, lease, П: Чи вірно, що скоріш всього на продуктиві реєстру не буде мірор а буде в кращому разі search ендпоінт?

В: В першій версії, скоріше за все не буде

Procedure, lease, П: Де можна знайти словники? 

В: https://gitlab.prozorro.sale/prozorro-sale/prozorro-registry/-/tree/master/classifiers - тут есть yaml файли со словарями, которые сейчас. https://gitlab.prozorro.sale/prozorro-sale/prozorro-registry/-/issues/9 - словари, которые будут в слудующем релизе

Procedure, lease, П: Є сгенерований клієнт: https://pypi.prozorro.sale/simple/procedure-api-client/, чи планується до нього додавання  registry?

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

Procedure, lease, П: Де можна знайти інформацію по логіці роботи з реєстрами?

В: Тут

Procedure, lease, П: Чи можливо на  етапі реєстрації Орендодавця (sellingEntity) та створення нового об'єкту,  значення в поля propertyOwner тягнути з sellingEntity, чи потрібно їх вводити вручну?

В: В разі, якщо вони співпадають (що трапляється, але далеко не завжди) - можна тягнути, звісно

Procedure, lease, П: В чому принципова різниця між ролями Орендодавець та Балансоутримувач? Чи може одна й та сама особа бути і Орендодавцем і Балансоутримувачем? Наведіть нам якійсь приклад з реального життя взаємовідносин Балансоутримувача і Орендодавця.

В: Так, може, але це не точно (див.п.1). частішим буде випадок, коли, наприклад, орендодавець - фонд держмайна, а балансоутримувач - якесь ДП

Procedure, lease, П: Чи може, гіпотетично,  фізична особа бути Орендодавцем чи Балансоутримувачем?

В: Ні, не може

Procedure, lease, П: В документіПереліки (реєстр) орендиє Перелік формальних дій. Прокоментуйте будь-ласка першу дію “1. Балансоутримувач надсилає орендодавцю копію рішення про намір передачі майна в оренду через ЕТС“. - яким чином ця дія має відобразитися в системі? чи це офлайнова дія?

В:  Тут певна офлайнова дія, під яку доброчесний балансоутримувач має створити додатково сутність “дія“, куди долучить скан цього рішення. ну або - принаймні - має долучити цей скан безпосередньо до сутності об‘єкта. ми це жорстко не регламентуємо

Procedure, lease, П: Чи потрібно реалізувати весь перелік Дій? Чи поки достатньо функціоналу створення обьєкту?

В: Потрібно реалізувати Об’єкти, Заявки і Дії. Дії відрізняються одна від іншої єдиним полем - actionType. від його значення ніяка логіка не залежить

Procedure, lease, П: З яких причин  у свагері  в base.RegistryObject не додано масив registryObjectItems?

В: В даному випадку registryObjectItemsце поле структуриregistry.RealEstate  в залежності від itemTypeтам різне наповнення, тому базова модель для нього відсутня. Дляregistry.JointPropertyComplex в ціх полях будеregistry.JointPropertyComplexItem

Procedure, lease, П: Чи має бути можливість створювати чернетку обєкту?

В: Так, на стороні майданчика до публікації у ЦБД так, як і при роботі з іншими сутностями

Procedure, lease, П: Чи потрібно створювати окрему роль для роботи з переліками?

В: Якщо вже є роль для Орендодавця по ЗУ, який працює з аукціонами з оренди у ЦБД-2, окремий обліковий запис створювати немає потреби, цей орендодавець може працювати і з переліками у ЦБД-3. Юридично Орендодавець по ЗУ - це та сама особа, що являється Орендодавцем, який публікує інформацію у переліках. І яка потім буде публікувати аукціони
І набір даних у неї співпадає. Відмінності, які можуть бути, вже на рівні ЦБД

Procedure, lease, П: Підкажіть, де можна переглянути список типів документів об"єкту в розрізі типу об"єкту?

В: По-перше - рекомендую використовувати свіжіщий спрощений документ: https://prozorrosale.slack.com/archives/C019HQJKQ15/p1600424693005800щодо питання по суті: в поточній версії домовились відмовитись від обмежень типів документів. тобто поняття обов’язкових документів немає, і ви можете самостійно визначати типи документів, які завантажуєте

Procedure, lease, П: Підкажіть будь-ласка, після того як Орендодавець заповнить поля в формі створення нового обєкту і натисне кнопку Створити і дані відправляться в цбд, а що ми отримаємо у відповідь?

В:  idоб'єкта та acc_tokenоб'єкта

Procedure, lease, П: Чи вірно, що в реєстрах об"єктів маємо виводити перелік об"єктів чи перелік айтемів в об"єктах?

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

Procedure, lease, П: В свагері   RealEstateItem ->basicInfo->additionalClassification написано, що їх може бути  необмежена кількість, але за схемою це не масив, а об'єк? 

В:  base.additionalClassification действительно может сожержать неограниченное колличество класификаторов в зависимости от процедуры.Это базовое описание базовой модели. Так же для реестров basicInfo.additionalClassification необязательное поле и кол-во класификаторов не определено. 

Procedure, lease, П:  registryObjectItems->reProps->powerSupplyClass не приймає значення зі словника "second"  та registryObjectItems->reProps->locationInBuilding  не приймає нічого зі словника, окрім "basement"

В: Скоріше за все, словники ще не реалізовано  (24.09.2020)

Procedure, lease, П: Як валідується contactPoint.url?

В: По http://

Procedure, lease, П:  Як працювати по полями, якщо у  табличці з прикладами є чимало полів, яких немає в свагері? 
Наприклад:

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

Procedure, lease, П: Як опрацьовувати дані з наступних полів: 

• Електроенергія
• Опалення
• Холодна вода (постачання і відведення)
• Гаряча вода (постачання і відведення)
• Постачання природного газу
• Утримання будинку і прибудинкової території
• Вивіз сміття
• Порядок сплати орендарем комунальних послуг

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

Procedure, lease, П: Для чого потрібне поле _version  і чи має майданчик його відображати? 

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

Procedure, lease, П: З яких причин при створенні  об'єкту реєстру  на стейджингу - помилкавалідації? 

В:  ЦБД приймає тільки варіант: 

Procedure, lease, П: В LeaseAction поле що пов'язує  "Дію"  з об'єктом має назву relatedObjectId, в  LeaseRequest поле що пов'язує "Заявку" з об'єктом має назву  registryItemId - чи вірно, що   "Дію" створюють на об'єкт, а "Заявку" на окремий айтем об'єкту? 

В:  Тут опис структури дії. вона може бути пов’язана з чим завгодно: 

це - для завяки. вона має кріпитися до об’єкту: 

Procedure, lease, П: Чи вірно що LeaseAction.description и  LeaseRequest.description   не  multiLang? 

В: Згодом будуть внесено зміни, зараз вірно 

Procedure, lease, П: Через що виникає помилка, при спробі публікації реєстра? 

В: Дана помилка виникає череез невірно використаний класифікатор. має використовуватися CAV   а не CPV

Procedure, lease, П:  Чи правильно, що для всіх 4 relatedOrganizations потрібно залишити виключно UA-EDR виходячи з: 

В:  Так, все вірно, за нормативкою це або ЦОВВ і їх підрозіділи, або ДП/КП (або ще хтось, про кого я не знаю), але енівей - юр.особа. ще й державна так чи інакше

Procedure, lease, П: Чи має майданчик виводити на форму створення обєкту інформацію ізhttps://procedure-staging.prozorro.sale/api/doc#  statusesDecisions→description?

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

Procedure, lease, П: Який словник використовувати для  додаткового класифікатора реєстрів?

В: На зараз (05.10.2020) основний класифікатор CAV, додаткові можуть різнитися від процедури до процедури.

Procedure, lease, П: Чи можуть для LeaseAction бути заповненими  relatedObjectId, relatedRequestId і relatedActionId чи має бути заповнено тільки якесь одне поле?

В: Поля, за бажанням користуача, можуть бути заповнені у будь-якій комбінації.

Procedure, lease, П:  З яких причин при оголошені, не зважаючи на передачу з класифікатором CAV , на стейджингу майданчик отримує помилку? 

В: Потрібно взяти з  будьякого об'єкту з  https://procedure-staging.prozorro.sale/api/registry/objects/search/byDateModified/2020  класифікатор і  передати дані з ним.

Procedure, lease, П: Чи є нормальним не пов'язаний ні з чим action  https://procedure-staging.prozorro.sale/api/registry/actions/5f7dcaa3d488ef8f846979dc? 

В:  За логікою, ні не нормально, але технічно - так. 

Procedure, lease, П:

Procedure, lease, П: З яких причин  при передачі даних на створення  об'єкту  на  https://procedure-staging.prozorro.sale/api/registry/realEstate майданчик отримує помилку Not Found.
"x-request-id": "01b87658-6f32-43c1-8007-947e5e88527a"

В:  З тієї причина, що передавати потрібно на https://procedure-staging.prozorro.sale/api/registry/objects/realEstate

Procedure, lease, П: Чи може користувач при реєстрації обрати одразу дві ролі (Балансоутримувач та Орендодавцем), щоб потім при створенні обєкту обирати під якою роллю він створює обєкт?

В: Користувач реєструється як користувач, а вже при роботі з певним об’єктом він має обирати хто він: блнсутр, орендд або обидва

Procedure, lease, П: Чи є (чи планується) загальна база Орендодавців та Балансоутримувачів звідки майданчик підтягував би інформацію при створенні нового обєкту по ЄДРПОУ?

В: В майбутньому. наразі  рекомендується робити це на боці майданчика

Procedure, lease, timber, П: Чи може організатор з продажу деревени (це окрема роль згідно вимог по тімберу) бути одночасно і організатором з переліків?

В: В  разі, якщо у нього є і ліс, і майно в оренду - то так

Procedure, lease, timber, П: В разі, якщо майданчик реалізовує мультироль з селектом при створенні об’єкту, то поки не дуже зрозуміло як будуть Орендодавець та Балансоутримувач надсилати один одному Дії, наприклад клопотання?

В: Дії - вони не надсилаються “комусь“, вони асоціюютья з іншою сутністю. Доречі це неправильно,  варто б дати можливість асоціювати дію в тому числі і з кимось.

Procedure, lease, П: Чи не є наступна поведінка помилковою:  Створити об'єкт з документами → при редагуванні передати породній масив → отримати порожній об'єкт без документів? 

В: Ні, така поведінка не є помилкою, передача порожнього масиву затирає існуючі об'єкти

Procedure, lease, П: Питання по продуктивному середовищу:  яку початкову дату використовувати для повної синхронізації xthtp /api/registry/objects/search/byDateModified/{date_modified}?

В: Найпростіший варіант передавати /api/registry/objects/search/byDateModified/2020, це збере всі об'єкти з початку року.