Найчастіше про делегування згадують у гострий момент: ДІАМ не приймає повідомлення про початок будівельних робіт, бо в ЄДЕССБ функції замовника не делеговані. Делегування повноважень замовника означає передачу права подавати й підписувати документи в системі від замовника до уповноваженої особи або іншої організації. Оформлюють його окремим документом «Відомості про делегування повноважень» (тип TR, TR01) у розділі 2.6 профілю, а не в розділі 2.4 «Документи про зміни замовника».
Правова основа тут одна: Закон України «Про регулювання містобудівної діяльності» (№ 3038-VI). Він допускає виконання функцій замовника уповноваженими особами, а у визначених законом випадках, наприклад для об’єктів комунальної власності, і виконавчими органами місцевих рад.
Далі розберемо покроково: як оформити TR01, чому для уповноваженої особи потрібен окремий ключ, як продовжити термін, як прив’язати TR до проектної документації та як зняти помилки розділу 2.6, зокрема D007313 і D007319.
Що таке делегування повноважень замовника і як оформити TR01 у розділі 2.6
Куди вносити делегування, замовники плутають найчастіше. Правильне місце: розділ 2.6 «Відомості про делегування повноважень», документ типу TR. Розділ 2.4 «Документи про зміни замовника» вирішує іншу задачу і для делегування функцій не підходить. У практиці навіть трапляється, що чернетка в 2.6 «не знаходить» замовника, а та сама чернетка в 2.4 підтягує його одразу. Це не привід переносити документ: тип документа має відповідати дії.
Закон України «Про регулювання містобудівної діяльності» (№ 3038-VI) прямо передбачає, що функції замовника можуть виконувати уповноважені особи, а делегування цих функцій оформлюється відповідним документом. У ЄДЕССБ таким документом і є TR01.
✅ Висновок: делегування функцій замовника вносять у розділ 2.6 документом TR, а не в розділ 2.4. Тип документа під дію обираєте на старті, інакше зіпсуєте весь ланцюжок.
Делегування права подання дозволу уповноваженій особі: чому потрібні окремі ключі
Типовий запит: зробити так, щоб директор не заходив у «Дію» своїм ключем, а всі документи подавала уповноважена особа. У ЄДЕССБ це робиться штатно, але через окремі електронні підписи, а не «під ключем директора».
Причина юридична, а не технічна. Фізична особа саме як фізична особа не відповідає по документах за юридичну особу, це різні суб’єкти права. Тому й ключі (КЕП) робляться окремо: уповноважена особа підписує своїм підписом у межах наданих їй повноважень. Постанова КМУ № 466 від 13.04.2011 (Порядок виконання підготовчих та будівельних робіт) послідовно говорить про замовника або його уповноважену особу як сторону, що діє в дозвільних процедурах. Тобто підстава для дій уповноваженої особи має бути зафіксована в системі до подання.
✅ Висновок: щоб працівник подавав документи замість директора, оформіть делегування і видайте йому окремий КЕП. Спроба «підписати за юрособу фізичним ключем» законної сили не має.
Внесення змін і продовження терміну у Відомостях про делегування (TR01)
Коли термін повноважень спливає, замовники шукають кнопку «редагувати» у вже підписаному TR01. Її немає, і це не збій. Видалення або виправлення документа після завершення підписання в ЄДЕССБ неможливе. Будь-які зміни, зокрема продовження терміну делегування, вносять тільки через створення нової редакції документа (механізм версійності).
На практиці це означає простий порядок: створюєте нову редакцію TR, вносите оновлений термін чи склад повноважень, підписуєте. Стара редакція лишається в історії, а чинною стає нова. Так система зберігає незмінність підписаного і водночас дає легальний спосіб оновити дані.
✅ Висновок: продовжити термін або змінити склад повноважень у TR01 можна лише новою редакцією документа. Правити підписаний оригінал не вийде і не потрібно.
Прив’язка документа делегування (TR) до проектної документації (PD)
Окреме питання, яке ставить навіть ДІАМ: як зв’язати номер документа делегування (TR) з номером проектної документації (PD). Функціонал такого зв’язування в ЄДЕССБ передбачений, хоча в інтерфейсі його не завжди видно з першого разу.
Логіка та сама, що й для інших зв’язків між документами. Щоб PD взагалі підтягувалася у випадаючих списках, вона має бути підписана і мати статус реєстрації «зареєстровано», а номер введений точно, зі співпадінням серії та цифр. Якщо зв’язок треба перебудувати вже після підписання, це реалізується через нову редакцію відповідного документа, а не редагування «на місці».
✅ Висновок: прив’язати TR до PD можна, але лише коли PD зареєстрована, а її номер введений без помилок. Зміну зв’язку проводять новою редакцією.
Усунення помилок делегування: не підтягує замовника у 2.6, збій за коректним ЄДРПОУ (D007313, D007319)
Дві помилки блокують оформлення TR найчастіше, і в обох є конкретна причина.
- D007313 «в організації відсутні співробітники з правом підпису». Система перевіряє, чи є в осіб право підпису саме на тип документа «Відомості про делегування повноважень». Якщо жодному співробітнику чи атестованій особі це право не надане, TR підписати не дадуть. Рішення: керівник надає право підпису на цей тип документа через профіль організації.
- D007319 «відповідність замовників». Система звіряє замовника в TR із замовником у проектній документації і сигналізує про розбіжність. Треба перевірити, чи правильно вказані РНОКПП або ЄДРПОУ, і привести їх до одного значення.
Окремий випадок: після натискання «Отримати інформацію з ЄДР» дані замовника не підтягуються навіть за коректним ЄДРПОУ. Це означає, що потрібних відомостей просто немає в Єдиному державному реєстрі, а не що ви помилилися в кабінеті.
✅ Висновок: D007313 знімається наданням права підпису на тип «Відомості про делегування повноважень», D007319 знімається звіркою РНОКПП/ЄДРПОУ з проектною документацією. Порожня відповідь ЄДР вказує на реєстр, а не на систему.
Передача функцій замовника іншій організації та зміна замовника: алгоритм
Коли функції замовника передають іншій організації, наприклад від виконавчого комітету до управління капітального будівництва за договором доручення, самого договору ЄДЕССБ «не бачить». Поки делегування не оформлене в системі, ДІАМ не прийме ні повідомлення, ні дозвіл: формально функції замовника не делеговані.
У практиці чату склалися два робочі варіанти зміни замовника. У першому новий замовник створює «Відомості про делегування повноважень», які підписують і старий, і новий замовник. Для об’єктів комунальної власності діє ще й норма Закону № 3038-VI: у випадках, визначених законом, функції замовника будівництва виконують виконавчі органи відповідної сільської, селищної, міської ради. Це і є підстава, щоб рада або її УКБ стали замовником у системі.
⚠️ Ризик: якщо почати роботи на об’єкті, поки делегування не зареєстроване в ЄДЕССБ, повідомлення про початок будівельних робіт завернуть, і легальний старт доведеться відкладати до оформлення TR.
Хто оновлює відомості про делегування у профілі та надає право підпису
Технічно налаштування підписантів робить не «система» і не підтримка, а керівник організації. У розділі профілю (Налаштування організації, Співробітники) керівник підтверджує себе за ключем юридичної особи, додає співробітника чи атестовану особу і надає їй право підпису на потрібний тип документа. Без цього кроку і виникає D007313.
Тут замовники часто спотикаються: підтверджують керівника, оновлюють дані, а «олівець» для редагування підписанта не з’являється. Причина зазвичай у тому, що керівник авторизований не тим ключем або дані про керівника в ЄДР не збігаються з підписом.
✅ Висновок: право підпису на «Відомості про делегування повноважень» надає керівник через профіль організації, зайшовши ключем юрособи. Це передумова і для оформлення TR, і для його підписання.
«Планується знесення, а замовником планує бути тільки одна особа. Забезпечити це можна через делегування повноважень: є така функція в електронній системі, тобто 22 інших співвласника делегують своє повноваження одній особі бути замовником.» — Ірина Гальченко, авторка курсів з дозвільної документації та роботи в ЄДЕССБ, ЄДЕССБ від А до Я
Чому PRO InfoBud
Делегування виглядає простим, поки не впираєтесь у 2.6, версійність і право підпису одночасно. Тут дешевше зайти з фахівцем, ніж місяцями шукати причину відмови самотужки.
- Практика в дозвільній документації з 2012 року: щодня працюємо з реальними TR01, зміною замовника та передачею функцій, а не з теорією.
- Бачимо не окрему помилку, а тенденцію: знімаємо D007313/D007319 і збої за ЄДРПОУ, налаштовуємо підписантів і право підпису під тип документа.
- Супроводжуємо передачу функцій замовника іншій організації, зокрема для ОТГ, рад та УКБ, з коректним оформленням у ЄДЕССБ.
- Працюємо тільки в законному полі: 100% задач наших замовників вирішені.
Потрібно оформити делегування чи передати функції замовника без відмов ДІАМ? Передаємо це під ключ у послузі супровід делегування та передачі повноважень замовника в ЄДЕССБ.
Повний перелік напрямків — у розділі послуги PRO InfoBud.










