Як читати статуси закупівлі

Статус описує етап, а не весь результат

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

Як визначити потрібну дію

Для участі перевіряйте не тільки слово «активна», а доступність подання й кінцеву дату. Для аналізу переможця відкривайте рішення, а для виконання — відповідний договір. Стан усієї закупівлі та стан договору описують різні об’єкти.

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

Приклад завершеної процедури

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

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

Що читати поруч зі статусом

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

Побудуйте словник станів для свого сценарію

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

Відокремте назву, яку бачить користувач, від технічного значення поля, якщо працюєте з вивантаженням або API. Інтерфейс може показувати зрозумілий переклад чи додаткове пояснення. У звіті збережіть правила відповідності між ними. Це дозволить перевірити, чому певні записи потрапили до групи «приймання пропозицій» або «завершені».

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

Різні рівні в одній картці

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

Рішення щодо учасника та відомості про договір також потребують окремого читання. Команда може побачити зміну в одному розділі й помилково припустити завершення всього процесу. Зіставте подію з пов’язаними документами та наступними доступними діями. Якщо дані ще не дозволяють встановити результат, прямо позначте його як невизначений на момент перегляду.

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

Як працювати зі зміною стану

Коли стан змінився, зафіксуйте час, попереднє значення та нову подію, яку вдалося знайти. Далі визначте, чи виникла дія для вашої компанії. Не кожне оновлення потребує подання документа, але кожна важлива зміна має бути зрозуміла відповідальному. Повідомлення керівнику повинне описувати наслідок для роботи, а не просто повторювати новий ярлик.

Якщо доступна дія не відповідає очікуванню, перевірте тип процедури, належний обліковий запис і фактичні строки. Після цього звертайтеся до підтримки з конкретним описом розбіжності. Не намагайтеся обійти обмеження інтерфейсу через іншу картку або сторонній профіль. Спочатку потрібно встановити, чи є проблема технічною, чи ваше очікування ґрунтується на неправильному розумінні етапу.

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

Статуси у внутрішньому звіті

Створіть окремі поля для системного стану та власного робочого висновку. Наприклад, «документи аналізуються» є внутрішнім завданням команди, а не офіційним статусом закупівлі. Якщо об’єднати їх в одну колонку, наступний читач не зрозуміє, що взято з джерела, а що описує ваш процес. Залишайте також дату актуальності запису.

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