31.07.2026
Підписане завдання не реєструється, а система повертає «23502: наявність пустих значень». І це при тому, що всі розділи начебто заповнені, а протокол перевірок пройшов без жодної помилки. Саме на цьому найчастіше спотикаються ті, хто вперше вносить завдання на проектування в ЄДЕССБ.
Причина майже завжди не в «пустих полях» як таких. Коротка відповідь: завдання створює замовник через АРМ Заявника, а блокують реєстрацію три речі. Перша: немає права підпису на тип документа «завдання на проектування» у замовника або проєктувальника. Друга: не підтягнулася назва об’єкта з містобудівних умов та обмежень. Третя: щось не так із редакціями завдання, коли їх стало дві. Частину проблем виправляють без нової редакції, частину, навпаки, лише через неї. Нижче розберемо кожен сценарій, коди перевірок, які їх викликають, і як повернути першу редакцію діючою, якщо друга «з’їла» чинну.
Хто і як створює та оновлює завдання на проектування (ZP01) у ЄДЕССБ
Завдання на проектування має внести замовник, і зробити це через АРМ Заявника. Без цього документ просто не з’явиться в замовника для підписання. Логіка системи проста: хто вносив документ до системи, тому він і показується на підпис. Тому спроби «створити завдання за замовника» з іншого кабінету обертаються глухим кутом.
Підписантів двоє. Керівник проєктної організації (або уповноважений співробітник) та замовник. Якщо замовник юридична особа, він підписує юридичним ключем. Окремий нюанс за стадією ТЕО: там завдання підписує лише замовник, підпис проєктувальника на цій стадії не потрібен.
Найболіснішою буває ситуація, коли завдання вже висить у системі, але оновити його нема кому.
Тут працює те саме правило: редагувати документ може організація, під якою він створений. Якщо завдання завела стороння особа, коректний шлях це сформувати документ у рамках потрібної проєктної організації чи ФОП, а не «дописувати» чуже.
✅ Висновок: завдання має жити в кабінеті замовника через АРМ Заявника, інакше воно не дійде до підписантів і його не вдасться оновити.
Повний перелік напрямків — у розділі послуги PRO InfoBud.
Помилка 23502 та D-коди при реєстрації завдання: чому «пусті значення» при заповнених розділах
Помилка «23502: наявність пустих значень» вискакує після спроби зареєструвати вже підписане завдання. Найбільше збиває з пантелику те, що видимих незаповнених полів немає.
Річ у тім, що система читає не лише те, що ви бачите на екрані. Частина обов’язкових значень підтягується зі зв’язаних об’єктів, і якщо там пусто, реєстрація падає. Найчастіші джерела блокування описані окремими перевірками з кодом D.
| Код перевірки | Що блокує | Як зняти |
|---|---|---|
| D007317 | У замовника немає права підпису на тип документа «завдання на проектування» | Додати або погодити співробітника з правом підпису та атестовану особу |
| D007318 | Те саме право підпису відсутнє у проєктувальника | Додати уповноважену на підписання завдання особу в організації проєктувальника |
| «Не введена назва об’єкта в Завданні або МУО» | У містобудівних умовах та обмеженнях, доданих до завдання, немає назви об’єкта будівництва | Внести назву об’єкта будівництва в МУО |
| D008019 | Назва об’єкта в проєктній документації не збігається з назвою в завданні | У ПД відкрити «Загальна інформація», «Редагувати» і вписати назву точно як у завданні |
Окремо варто тримати в голові, що вимоги до повноти даних лише зростають. У 2026 році система отримала нову блокуючу перевірку та низку ризикоінформуючих перевірок на повноту внесеної інформації, а логіку перевірки назви об’єкта (тієї самої D008019) доопрацювали. Простіше кажучи, дедалі більше «дрібниць», які раніше проходили, тепер зупиняють реєстрацію.
✅ Висновок: «23502» це не про порожні поля на екрані, а про обов’язкові значення у зв’язаних об’єктах: право підпису та назва об’єкта з МУО. Пройдіться по D-кодах перш ніж переробляти саме завдання.
Як додати проектувальника і виправити статус без нової редакції завдання
Тут ховається головне непорозуміння. Виправити вже підписаний документ у самому тілі неможливо: видалення чи редагування після завершення підписання система не дозволяє, зміни вносяться тільки новою редакцією. Але це не означає, що будь-яка правка вимагає нової редакції завдання.
Проблема з правом підпису проєктувальника чи замовника (перевірки D007317, D007318) лежить не в документі, а на рівні організації. Ви додаєте або погоджуєте співробітника з відповідним правом підпису, і завдання підписується без жодної нової редакції. Саму організацію проєктувальника у створеному документі змінити не вийде: цей розділ формується автоматично від того, яку організацію обрала атестована особа при створенні. Виправляють це формуванням нового документа в рамках діючої проєктної організації, а попередній документ з невірним проєктувальником переводять у статус «скасований» або лишають як чернетку.
Ще один частий випадок це документи зі статусом реєстрації «зареєстровано (внесено за відомостями замовника)». Вони з’являються, коли дані вносив замовник на порталі Дія або інспектор при формуванні дозвільного документа. Щоб працювати з таким документом далі, ви підтверджуєте наявність документа, підписуєте його, після чого створюєте нову редакцію і змінюєте статус на «діючий» для подальшого редагування.
✅ Висновок: права підпису і підтвердження статусу правляться поза новою редакцією, а от зміст підписаного завдання чи організацію проєктувальника без неї не змінити.
Як змінити вид будівництва та підтягнути назву об’єкта з МУО у завданні
Назву об’єкта в завданні не можна просто «переписати». Вона визначена в містобудівних умовах та обмеженнях і є остаточною. Змінити її можна лише через внесення змін до самих МУО. Тому коли завдання лається на назву об’єкта, шукати треба у вихідних даних, а не в полі завдання.
Важлива деталь, про яку часто забувають: назва повинна відображати вид будівництва, будь то нове будівництво, капітальний ремонт чи реконструкція. Вимоги до складу й змісту завдання та проєктної документації задає ДБН А.2.2-3:2014 «Склад та зміст проектної документації на будівництво». Якщо вид будівництва в назві й у завданні розходиться з фактичним станом об’єкта, це прямий шлях до питань при реєстрації.
⚠️ Ризик: невірно визначений вид будівництва це близько 12% відмов у реєстрації (розбіжність фактичного стану об’єкта з обраним видом робіт, помилки класифікації). Виправляти це на етапі завдання дешевше, ніж переробляти вже поданий пакет.
✅ Висновок: вид будівництва і назва об’єкта живуть у МУО; правити їх у завданні наосліп марно, спочатку узгодьте вихідні дані.
Редакції завдання: коли потрібна друга і як повернути першу діючою
Друга редакція завдання потрібна тоді, коли завдання реально змінювалося під нову редакцію проєктної документації. Це закладено в перевірку D007989: реєстраційний номер завдання в поточній редакції ПД має збігатися з номером у попередній редакції. Якщо номери різні, система вважає, що взяли інше завдання без нової редакції, або номер змінили помилково. Виняток лише для першої редакції ПД чи коли в попередній редакції завдання не було.
Звідси типовий збій: ПД не бачить нову редакцію завдання.
Перевіряти тут варто статус (перевірка D007267): у робочому стані статус документа має бути «Діючий», а статус реєстрації «Зареєстровано (внесено реєстратором)». І пам’ятайте, що після нової редакції ПД доводиться створювати нові редакції зв’язаних документів: відомостей про авторський і технічний нагляд, експертизи, відомостей про виконання робіт, затвердження ПД. Детальніше про це в матеріалі про помилки затвердження проєктної документації.
Найбільш болісний сценарій це коли друга редакція «поховала» першу.
Правильна профілактика прописана в логіці роботи з редакціями: при створенні нової редакції статус попередньої лишають діючим, скасовувати не потрібно. Актуальними система бере відомості з останньої діючої підписаної редакції. Якщо ж друга редакція вже зробила першу архівною, самовільне «видалення» тут рідко можлива дія, і питання радше вирішується через звірку статусів і роботу з підтримкою, ніж кнопкою «видалити».
«Та структура складових частин, яку закладе проєктувальник у проєкт, так само у вас наприкінці буде зареєстровано право власності.» — Ірина Гальченко, авторка курсів з дозвільної документації та роботи в ЄДЕССБ, ЄДЕССБ від А до Я
✅ Висновок: нова редакція завдання виправдана лише коли завдання змінилося; щоб не втратити чинну редакцію, попередню не скасовуйте, а тримайте діючою.
Чому реєстрацію завдання варто довірити PRO InfoBud
Завдання на проєктування це фундамент, від якого залежить і реєстрація ПД, і майбутнє право власності на кожну складову частину об’єкта. Помилка в назві, виді будівництва чи редакціях означає не просто повторну спробу, а зупинку всього ланцюжка внесення документації в ЄДЕССБ.
- Компанія повного циклу: закриваємо все, окрім самих будівельних робіт, від вихідних даних до реєстрації права власності.
- Практика в дозвільній документації з 2012 року. Ірина Гальченко, CEO PRO InfoBud, гендиректорка консорціуму CLC Group.
- Щороку супроводжуємо 85+ об’єктів і проводимо понад 150 індивідуальних консультацій, тому щодня працюємо з реальними помилками реєстрації, а не з теорією.
- Досконало знаємо всі зміни в перевірках і логіці ЄДЕССБ та бачимо ризики ще до того, як вони стануть відмовою.
Якщо завдання не реєструється або ви заплутались у редакціях, ми беремо професійне внесення проєктної документації та супровід реєстрації на себе: розбираємо причину, знімаємо D-коди й доводимо документ до статусу «зареєстровано». Почати можна з виправлення помилок затвердження ПД в ЄДЕССБ.
