.. _econtracting_tutorial:

Туторіал
========

Загальна картина
----------------

Процес визначення переможця відбувається на майданчиках 1-4 рівнів акредитації.

Процес електронного контракту відбувається на майданчиках 6 рівня акредитації.

.. image:: /contracting/econtract/diagram/activity/image.png

Передумови
----------

Вимоги до тендеру
~~~~~~~~~~~~~~~~~

Для електронних контрактів тендер має відповідати наступним вимогам

* має бути обрано шаблон договору за допомогою поля `contractTemplateName` в тендері
* має бути обраним майданчик 6 рівня акредитації для замовників та постачальників

Розглянемо детальніше вимоги щодо тендеру.

Шаблон договору
~~~~~~~~~~~~~~~

Поле `contractTemplateName` має бути обов'язково обрано на етапі створення тендеру (більше тут :ref:`contract-template-name`)

Це поле визначає шаблон договору, який буде використано для створення PDF документу договору.

Майданчик 6 рівня акредитації
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

При створенні контракту замовнику (buyer) та постачальнику (supplier) має бути надано можливість вказати майданчик на якому буде проходити контрактінг.

Назва майданчика має бути вказана

* в полі `contract_owner` в `procuringEntity` (або `buyers` для закупівель ЦЗО) для замовників
* в полі `contract_owner` в `tenderers` пропозиції для постачальників

Поле `contract_owner` може мати лише назву майданчика, який пройшов акредитацію 6 рівня.

Для замовника майданчик має вказати поле `contract_owner` в `procuringEntity` (або `buyers` для закупівель ЦЗО).

Отримати перелік майданчиків можна за допомогою API запиту:

.. http:example:: http/get-brokers-all.http
   :code:

Якщо спробувати створити тендер з майданчиком не 6го рівня, то отримаємо помилку:

.. http:example:: http/create-tender-broker-1-fail.http
   :code:

Відфільтруємо майданчики 6го рівня:

.. http:example:: http/get-brokers-level-6.http
   :code:

Створимо тендер з майданчиком 6го рівня:

.. http:example:: http/create-tender-broker-6.http
   :code:

Тендер створено успішно.

Для постачальника майданчик має вказати поле `contract_owner` в полі `tenderers` пропозиції.

Переглянемо як виглядає пропозиція для постачальника:

.. http:example:: http/get-bid.http
   :code:

Як бачимо, майданчик вказано правильно.

Створення договору
------------------

Нехай у нас відбулась закупівля і є переможець. Після вибору переможця **автоматично** створюється контракт в закупівлі з обмеженим набором полів(`id`, `awardID`, `status`, `date`, `value`) та в системі договорів з повним набором полів(:ref:`Econtract`) у статусі ``pending``.

Договір створюється з додатковими полями:

* `contractTemplateName` - копіюється з закупівлі, якщо вона встановлена (більше про це в :ref:`contract-template-name`)
* `period` - `startDate` дорівнює `dateCreated` контракту + 5 календарних днів, `endDate` дорівнює кінець року, що вказаний у `startDate`

Договір PQ створюється з додатковими полями:

* `attributes` - формується з вимог та відповідей на вимоги у закупівлі

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

* `buyer.contract_owner` - майданчик зі сторони замовника, на якому буде проходити контрактінг (переїзжає з `tender.procuringEntity.contract_owner` або `tender.buyers.contract_owner`)
* `suppliers.contract_owner` - майданчик зі сторони постачальника, на якому буде проходити контрактінг (переїзжає з `tender.bids.tenderers.contract_owner`)

Більш детально про `contract_owner` в закупівлі можна прочитати в розділі :ref:`contract-owner`.

Також, PDF документ створюється на основі шаблону (`contractTemplateName`) та автоматично прикріплюється до договору з documentType `contractNotice`.

Цей документ буде потрібен для підписання як постачальником, так і замовником пізніше, щоб активувати договір.

Отримання договору
------------------

Договір в системі закупівель

.. http:example:: http/example-contract.http
   :code:

*Ідентифікатор `id` договору однаковий в системах закупівель та договорів.*

Подивимося на фід в модулі контрактінгу та яку інформацію там можна побачити:

.. http:example:: http/contract-list.http
   :code:


Спробуємо отримати створений об’єкт по URL:

.. http:example:: http/contract-view.http
   :code:

Отримання доступу
-----------------

Для отримання доступу для замовника або постачальника використовується ендпоінт `contracts/{contract_id}/access` після ствворення контракту.

Алгоритм отримання доступу:

* POST `/access` з індентифікатором клієнта - повертає токен для клієнта

Треба зробити POST `/access` - запит з індентифікатором клієнта, по якому визначається чи це buyer чи supplier. Якщо ідентифікатор не відповідає жодній із сутностей, то видається помилка:

.. http:example:: http/contract-access-invalid.http
   :code:

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

.. http:example:: http/contract-access-owner-invalid.http
   :code:

Якщо індентифікатор знайшло і `owner` підходить, то сетапиться токен відповідно до сутності для постачальника або замовника:

.. http:example:: http/contract-access-by-buyer.http
   :code:

Якщо замовник запитує доступ, то у відповіді також буде згенерований новий `transfer` токен.

Після генерації токену все ще дозволено перегенерувати токен, тому можна робити нові POST запити з цим ідентифікатором:

.. http:example:: http/contract-access-by-buyer-2.http
   :code:

**NOTE:** Тепер користувачу дозволено редагувати контракт як замовник тільки використовуючи останній згенерований токен.

Після того, як токен був перегенерований, попередній токен при редагуванні контракту вже не можна буде використати:

.. http:example:: http/contract-patch-by-buyer-1-forbidden.http
   :code:

Такий самий алгоритм і для отримання доступу постачальником.

Запросимо доступ для постачальника:

.. http:example:: http/contract-access-by-supplier.http
   :code:

**WARNING:** Отримання доступів дозволено тільки під час `pending` контракту.

Реєстрація договору
-------------------

Якщо контракт був створений за правилами електронного контрактингу за новим флоу зі встановленними майданчиками для постачальника та замовника ще під час закупівлі, то для активації такого контракту обов'язковими є заповнення інформації підписантів та додавання підписів всіх учасників.

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

Вимоги до підпису:

* Має бути підписаний документ договору з `documentType` `contractNotice`
* Файл підпису має бути прикріплений до договору з `documentType` `contractSignature`
* Підпис повинен мати наступні параметри:

  * Формат підпису: CAdES-X Long
  * Алгоритм підпису: ДСТУ 4145
  * Тип підпису: Підпис та дані в окремих файлах (detached)

Діаграма процесу підписання:

.. image:: /contracting/econtract/diagram/e_contract_pdf_signing/image.png

Після того, як обидві сторони підтвердять завершення підписання поточної верcії контракту, контракт стає `active`.

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

Постачальник додає документ підпису використовуючи свій токен (`supplier_token`), який він отримав при запиті доступу:

.. http:example:: http/contract-supplier-add-signature-doc.http
   :code:

Постачальник додає другий опціональний документ підпису використовуючи свій токен (`supplier_token`), який він отримав при запиті доступу:

.. http:example:: http/contract-supplier-add-signature-second-doc.http
   :code:

Постачальник підтверджує завершення процесу підписання використовуючи свій токен (`supplier_token`), який він отримав при запиті доступу:

.. http:example:: http/contract-supplier-add-signatory.http
   :code:

Замовник додає документ підпису використовуючи свій токен (`buyer_token`), який він отримав при запиті доступу:

.. http:example:: http/contract-buyer-add-signature-doc.http
   :code:

Замовник підтверджує завершення процесу підписання використовуючи свій токен (buyer_token), який він отримав при запиті доступу:

.. http:example:: http/contract-buyer-add-signatory.http
   :code:

Коли усі підписи додані і підтверджені, то система автоматичер активує контракт:

.. http:example:: http/get-active-contract.http
   :code:


.. _contract_versions:

Нові версії договору
====================

Якщо одна зі сторін договору не погоджується підписувати поточну версію контракту, існує можливість створити нову версію контракту, змінивши деякі поля.

Етапи:

* скасування попереднього контракту

* створення нової версії зі змінами (POST)

* підписання нової версії і очікування поки друга сторона погодиться підписати дану версію (або створення нової версії контракту вже іншою стороною)

Скасування
----------

Інсує можливість скасування поточної версії контракту та створення нової тільки поки контракт знаходиться в статусі `pending`.

Для того, щоб скасувати контракт, учасник договору має додати об'єкт `cancellation` обов'язково вказавши причину скасування `requiresChanges`:

.. http:example:: http/contract-supplier-cancels-contract.http
   :code:

Подивимося на договір:

.. http:example:: http/cancellation-of-contract.http
   :code:

Заборонено додавати більше ніж один `cancellation`:

.. http:example:: http/cancellation-of-contract-duplicated.http
   :code:

Після того, як додано `cancellation`, підписувати цю версію контракту вже заборонено:

.. http:example:: http/contract-supplier-add-signature-forbidden.http
   :code:

Створення нової версії договору
-------------------------------

Після скасування будь-який учасник має створити нову версію контракту, використовуючи свій токен.

Сторона, яка створює нову версію може змінити наступні поля:

* period
* contractNumber
* items.unit
* items.quantity
* value
* title
* title_en
* description
* description_en
* dateSigned
* signerInfo (інформацію про підписанта своєї сторони)
* milestones

Якщо учасник намагається змінити якесь інше поле, то він побачить помилку:

.. http:example:: http/contract-supplier-post-contract-invalid.http
   :code:

Змінемо наступні поля `period` та `signerInfo.name`, використовуючи токен замовника:

.. http:example:: http/contract-supplier-post-contract-version.http
   :code:

Успіх! Подивимося на попередню версію контракту, в нього статус тепер `cancelled` і `cancellation` тепер має статус `active`:

.. http:example:: http/get-previous-contract-version.http
   :code:

Подивимося на всі контракти в закупівлі:

.. http:example:: http/get-tender-contracts.http
   :code:

Після цього починається новий етап підписання.

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

Скасування електронного договору
================================

Договір можна скасувати, поки він в статусі `pending`.

При створенні скасування договору можна обрати одну з двох причини скасування:

* `requiresChanges`
* `signingRefusal`

Причина скасування `requiresChanges` використовується, якщо одна зі сторін договору не погоджується підписувати поточну версію контракту і є необхідність створити нову версію контракту, змінивши деякі поля. Детально описано в :ref:`contract_versions`.

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

Підписант (замовник/постачальник) може створити `cancellation` з причиною `reasonType = signingRefusal`:

.. http:example:: http/contract-supplier-cancels-contract-2.http
   :code:

Подивимося на договір:

.. http:example:: http/winner-cancellation-of-contract.http
   :code:

Після цього замовник скасовує переможця - `award` змінює статус на `cancelled`:

.. http:example:: http/winner-award-cancellation.http
   :code:

Подивимося на контракт ще раз і побачимо, що в нього статус тепер `cancelled` і `cancellation` тепер має статус `active`:

.. http:example:: http/contract-with-winner-cancellation.http
   :code:

Подивимося на закупівлю, переможець скасований і підтвердження кваліфікації продовужється (статус закупівлі знову `active.qualification`):

.. http:example:: http/tender-with-winner-cancellation-of-contract.http
   :code:

Додаткові угоди (зміни) в EContract
===================================

Зміни в умови контрактів можуть бути внесені підписантами через подання і підписання додаткових угод. В системі використовується термінологія «змін» / «changes».

Ініціатором внесення змін може бути обидва замовник і постачальник.

Ініціатор заповнює три обов’язкових поля:

:rationale:
    string, причина змін

:rationaleTypes:
    list, типи причин

    Можливі значення для поля `rationaleTypes` валідуються зі списку причин, вказаних в  `contractChangeRationaleTypes`.

:modifications:
    object, нові значення в електронних полях


`modifications` це структура, що відображає зміни в електроних поля, які буде внесено:

:title:
    string

:title_en:
    string

:description:
    string

:description_en:
    string

:period:
    :ref:`Period`

    Дата початку та кінця договору.

:items:
    Список об'єктів :ref:`Item`

:value:
    :ref:`ContractValue` object

:contractNumber:
    string

:milestones:
    List of :ref:`ContractMilestone` objects

Зміни можна вносити тільки в підписані контракти:

.. http:example:: http/changes-for-pending-contract.http
   :code:

Створення додаткових угод
-------------------------

Якщо буде вказана причина, якої немає в  `contractChangeRationaleTypes`, ми побачимо помилку:

.. http:example:: http/create-change-invalid-rationale-types.http
   :code:

Запит створення пропозиції змін:

.. http:example:: http/create-change.http
   :code:

Для деяких полів договору існують валідації (такі самі як і були при PATCH для активного договору),

Наприклад, якщо замовник вирішив змінити валюту в `value` договору:

.. http:example:: http/change-modifications-invalid-currency.http
   :code:

Наприклад, якщо постачальник вирішив змінити період договору на неправильну дату:

.. http:example:: http/change-modifications-invalid-period.http
   :code:

Підписання змін
---------------

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

Після того, як обидві сторони підтвердять завершення підписання поточної верcії зміни, зміна стає `active` і модифікації будуть враховані під час наступних змін.

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

Постачальник додає документ підпису використовуючи свій токен (`supplier_token`):

.. http:example:: http/change-supplier-add-signature-doc.http
   :code:

Постачальник додає другий опціональний документ підпису використовуючи свій токен (`supplier_token`):

.. http:example:: http/change-supplier-add-signature-second-doc.http
   :code:

Постачальник підтверджує завершення процесу підписання використовуючи свій токен (`supplier_token`):

.. http:example:: http/change-supplier-add-signatory.http
   :code:

Замовник додає документ підпису використовуючи свій токен (`buyer_token`):

.. http:example:: http/change-buyer-add-signature-doc.http
   :code:

Замовник підтверджує завершення процесу підписання використовуючи свій токен (`buyer_token`):

.. http:example:: http/change-buyer-add-signatory.http
   :code:

Коли усі підписи додані і підтверджені, то система автоматично активує зміну:

.. http:example:: http/get-active-change.http
   :code:

Скасування
----------

Сторони можуть скасовувати дод. угоди, якщо вони неактуальні, надавши коментар.

Створимо ще одну додаткову угоду:

.. http:example:: http/create-change-2.http
   :code:

Для того, щоб скасувати угоду, учасник договору має додати об'єкт `cancellation` обов'язково вказавши причину скасування:

.. http:example:: http/contract-supplier-cancels-change.http
   :code:

Подивимося на додаткову угоду:

.. http:example:: http/cancellation-of-change.http
   :code:

Заборонено додавати більше ніж один `cancellation`:

.. http:example:: http/cancellation-of-change-duplicated.http
   :code:

Після того, як додано `cancellation`, підписувати цю додаткову угоду вже заборонено:

.. http:example:: http/contract-supplier-add-signature-to-change-forbidden.http
    :code:

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

.. http:example:: http/get-contract-with-changes.http
    :code:

Оновлення специфікації Договору
-------------------------------

Існує можливість змінювати і додавати новий масив items в активному статусі контракту через `changes`.

Дозволяється додавати новий item, але при цьому основні поля мають відповідати попереднім значенням в масиві `items`.

Поля, які не можна змінювати:

* `classification`
* `relatedLot`
* `relatedBuyer`
* `additionalClassifications`

Спробуємо додати новий `item` з новим полем `classification` і побачимо помилку:

.. http:example:: http/create-change-items-invalid-classification.http
    :code:

Наприклад, розділимо перший `item` на дві номенклатури з такими самими основними полями.

Але при цьому все ще існує валідація на суму цін за одиницю для всіх `items`:

.. http:example:: http/create-change-items-invalid-price.http
    :code:

Відредагуємо `quantity` в першому `item` і додамо новий `item` з коректною ціною `unit.value`:

.. http:example:: http/create-change-items.http
    :code: