.. _has_multi_sourcing:

hasMultiSourcing
================

Поле `hasMultiSourcing` є булевим полем, яке дозволяє укласти більше одного контракту в межах одного тендеру/лоту.

Можливі значення для поля `hasMultiSourcing` залежать від поля `procurementMethodType`. Наразі підтримується для `requestForProposal` та `competitiveOrdering`.

.. csv-table::
   :file: csv/has-multi-sourcing-values.csv
   :header-rows: 1

hasMultiSourcing встановлено у `true`
-------------------------------------

Створимо тендер з `hasMultiSourcing` встановленим у `true`:

.. http:example:: http/has-multi-sourcing-true-tender-post.http
   :code:

Логіка авардингу
~~~~~~~~~~~~~~~~

У межах тендеру/лоту може бути визначено більше ніж одного переможця. Активація аварди створює відповідний контракт у статусі `pending`.

Як саме генеруються аварди залежить від `hasAwardingOrder`:

* **`hasAwardingOrder: true`** (послідовний розгляд) — аварди створюються по одній. Після активації аварди система автоматично генерує наступну аварду у статусі `pending`, поки не вичерпано усі нерозглянуті пропозиції. У будь-який момент існує одна `pending`-аварда (якщо ще лишилися пропозиції).

* **`hasAwardingOrder: false`** (одночасний розгляд) — усі аварди для відповідних пропозицій створюються одночасно у статусі `pending` при переході тендеру у `active.qualification`. Замовник може активувати їх у будь-якому порядку. Нові аварди генеруються лише у разі скасування (`cancelled`) однієї з існуючих авард.

В обох випадках **замовник сам вирішує, скільки переможців він хоче** — для цього він активує потрібну кількість авард і потім підписує відповідні контракти. Pending-аварди, які замовник не активував, не блокують завершення тендеру.

Переходи статусу тендера
~~~~~~~~~~~~~~~~~~~~~~~~

* Поки існує хоча б одна `pending`-аварда — тендер залишається у `active.qualification`.
* Коли усі аварди мають термінальні статуси (`active` або `unsuccessful`) — тендер переходить у `active.awarded`.
* Тендер переходить у `complete` після активації останнього контракту лоту/тендеру.

**Якщо замовник зупиняє розгляд раніше** (тобто не активує останню pending-аварду), при активації останнього контракту тендер переходить безпосередньо з `active.qualification` у `complete` — статус `active.awarded` пропускається. Незавершені pending-аварди не блокують завершення тендеру.

Скарги
~~~~~~

Логіка блокування скаргами — на рівні лоту. Невирішені скарги у межах лоту (як на сам лот, так і на будь-яку з його авард) блокують підписання контрактів усіх авард цього лоту, поки скарги не буде розглянуто. Це не залежить від `hasMultiSourcing` і працює так само як для звичайних тендерів.

Покроковий приклад
~~~~~~~~~~~~~~~~~~

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

**Сценарій.** Замовник публікує `competitiveOrdering` тендер з `hasMultiSourcing: true`, отримує 4 пропозиції, але хоче обрати лише 2 переможців.

**Крок 1. Створення тендеру.**

.. http:example:: http/has-multi-sourcing-true-tender-post.http
   :code:

**Крок 2. Активація 1-ї аварди.**
Система автоматично створює відповідний контракт у статусі `pending`. З `hasAwardingOrder: true` також генерується наступна pending-аварда для розгляду.

Після цієї операції стан тендеру:

* `tender.status = active.qualification` (залишається, бо є pending-аварди);
* `awards`: `[active(1), pending(2)]` (нова pending-аварда автоматично згенерована);
* `contracts`: `[pending(C1)]` (для активованої аварди).

**Крок 3. Активація 2-ї аварди.** Аналогічно — створюється новий контракт, генерується наступна pending-аварда (якщо ще є пропозиції):

* `awards`: `[active(1), active(2), pending(3)]`;
* `contracts`: `[pending(C1), pending(C2)]`;
* `tender.status = active.qualification` (досі є pending-аварда).

**Крок 4. Підписання контрактів.**

Після підписання `contract_1`:

* `contracts`: `[active(C1), pending(C2)]`;
* `lot.status = active` (бо `contract_2` ще pending);
* `tender.status = active.qualification` (бо є pending-аварда).

**Крок 5. Підписання останнього контракту.**
Активація **останнього** pending-контракту лоту тригерить завершення лоту й тендеру.

Після підписання `contract_2`:

* `contracts`: `[active(C1), active(C2)]`;
* `lot.status = complete` (усі контракти лоту активні);
* `tender.status = complete` (усі лоти у термінальному статусі);
* `award_3` залишається у `pending` — це нормально, не блокує завершення.


Альтернативний хід подій
^^^^^^^^^^^^^^^^^^^^^^^^

Якщо замовник хоче розглянути **усі** аварди:

* активує по черзі всі pending-аварди (або відхиляє їх через `status: unsuccessful`);
* коли pending-авард більше не залишається, тендер автоматично переходить у `active.awarded`;
* потім — активація контрактів, останній тригерить `tender.status = complete`.

Послідовність статусів у цьому випадку: `active.qualification → active.awarded → complete`.

Стандартний хід (замовник зупинився на K переможцях) пропускає `active.awarded` і йде напряму: `active.qualification → complete`.

hasMultiSourcing встановлено у `false`
--------------------------------------

Тепер створимо тендер з `hasMultiSourcing` встановленим у `false`.

.. http:example:: http/has-multi-sourcing-false-tender-post.http
   :code:

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