22.07.2026
Ви натиснули «сформувати заяву» на реєстрацію СМП, а система повернула сухий код D007573 замість наступного кроку. За цим кодом майже завжди стоїть одне: ідентифікатори складових частин (МОН) не прив’язані до правильного батьківського ідентифікатора будинку чи будівлі. Складовими частинами тут називають квартири, паркомісця, комори, приміщення, тобто ті об’єкти, на які ви й реєструєте майбутнє майнове право.
Коротко, щоб не гортати далі. Заяву на СМП пропустить, коли збігаються три речі одночасно: кожен МОН належить своєму батьківському об’єкту (інакше D007573, D007612, D007918); статуси ідентифікаторів правильні, тобто «Діючий» і «Зареєстровано (внесено реєстратором)» (інакше D007481, D007580); ідентифікатор об’єкта будівництва заповнений і в документі гарантійної частки, і в самій заяві (інакше D007266, D007454). Зайві та дубльовані ідентифікатори доведеться анулювати, а видалені чернетки прибрати з карти. Нижче розберемо кожну помилку і що з нею робити.
Що таке ідентифікатори складових частин (МОН) і як вони пов’язані з основним об’єктом
Майбутнім об’єктом нерухомості, тобто МОН, вважають не будинок цілком, а його складову частину: конкретну квартиру, паркомісце чи нежитлове приміщення. Саме на неї виникає спеціальне майнове право.
Правова рамка тут одна. Закон України «Про гарантування речових прав на об’єкти нерухомого майна, які будуть споруджені в майбутньому» (№2518-IX) визначає, що спеціальне майнове право виникає з моменту державної реєстрації у Державному реєстрі речових прав. А те, який саме майбутній об’єкт кому дістанеться, фіксує договір щодо організації та фінансування будівництва разом із документом про гарантійну частку.
Тому ідентифікатор складової частини не живе сам по собі. Він підпорядкований батьківському ідентифікатору об’єкта будівництва, який проєктувальник створює за генеральним планом. Порушите цю ієрархію на етапі проєкту, і система зупинить заяву вже на перевірках.
✅ Висновок: МОН реєструють на складову частину, а не на будинок, і кожна складова частина мусить коректно належати своєму батьківському ідентифікатору.
Повний перелік напрямків — у розділі послуги PRO InfoBud.
Належність складових частин до батьківського ідентифікатора: помилки D007573 і D007612
Обидві помилки про одне: складова частина «відірвалася» від свого батька. Різниця лише в тому, до якого рівня її прив’язували, до основного об’єкта (будинку, будівлі, споруди) чи безпосередньо до будівлі.
За довідником ЄДЕССБ помилка D007573 (перевірка належності ідентифікаторів складових частин МОНів до ідентифікатора основного об’єкта) виникає, якщо ідентифікатори складових частин, доданих до проєктної документації, не належать батьківському ідентифікатору, до якого їх додано. D007612 працює так само, але звіряє належність до ідентифікатора будівлі. Логіка перевірки ідентична, змінюється тільки рівень підпорядкування.
Що робити. Звертаєтеся до проєктувальника, щоб він перевірив правильність підпорядкованості складових частин головному об’єкту в проєктній документації. Якщо підпорядкованість насправді коректна, а помилка все одно висить, тоді вже пишете в підтримку ЄДЕССБ.
✅ Висновок: D007573 і D007612 лікуються не в заяві, а в проєкті, через проєктувальника, який перевіряє прив’язку кожного МОН до батьківського ідентифікатора.
Статус ідентифікаторів для формування заяви: «Діючий» і «Зареєстровано» (D007481, D007580)
Тут перевіряють не ієрархію, а статус кожного ідентифікатора, який ви тягнете в заяву. Порожня квартира без правильного статусу заяву не пропустить.
Довідник ЄДЕССБ для помилки D007481 (перевірка статусу ідентифікаторів, обраних для формування заяви) прямо називає три умови, які мають збігтися одночасно:
- статус документа «Діючий»;
- статус об’єкта «Діючий»;
- статус реєстрації «Зареєстровано (внесено реєстратором)».
Помилка D007580 спрацьовує, коли статус доданих ідентифікаторів відмінний від «Діючий», а статус реєстрації відмінний від «Зареєстровано (внесено реєстратором)». Рекомендація підтримки на цей випадок: звернутися до проєктувальника, перевірити додані ідентифікатори і наявність дозвільного документа на них. Без чинного дозволу ідентифікатор потрібного статусу не отримає.
✅ Висновок: перш ніж формувати заяву, звірте по кожному МОН обидва статуси, бо один «недіючий» ідентифікатор блокує весь пакет.
Заповненість і наявність ідентифікатора об’єкта будівництва (D007266, D007454)
Дві останні перевірки цієї групи ловлять банальні, але часті пропуски: ідентифікатор просто не обрали там, де він обов’язковий.
D007266 (перевірка заповненості ідентифікатора об’єкта будівництва) вискакує, коли в розділі «Загальна інформація» ідентифікатор об’єкта будівництва не обрано взагалі. Лікується просто: тиснете кнопку «Додати» і вносите ідентифікатор.
D007454 суворіша. За довідником ЄДЕССБ у документі про визначення гарантійної частки та розподіл прав має бути рівно один об’єкт будівництва. Якщо будинків, будівель чи споруд у документі кілька, тоді в заяві СМП, у тому ж розділі «Загальна інформація», ви обираєте конкретний ідентифікатор. Причина проста: заява на реєстрацію СМП створюється на один будинок, не на весь комплекс одразу.
✅ Висновок: D007266 і D007454 закриваються перевіркою «Загальної інформації», один об’єкт будівництва на заяву, ідентифікатор обрано.
Як анулювати зайві та дубльовані ідентифікатори
Найнеприємніший сценарій, коли складову частину створили двічі. Наприклад, додавали МОН по одному і випадково повторили номер, дві «26-ті» квартири замість однієї.
На вебінарі ЄДЕССБ по ідентифікаторах це пояснили так: у протоколі перевірки система покаже дублювання складових частин, і це кваліфікується як порушення порядку присвоєння адрес (Постанова КМУ № 690 про адресацію). Наслідок жорсткий:
Тому дублі краще ловити до підпису. Механіка така: при створенні нової редакції ідентифікатори можна редагувати, а помилково створені анулювати і виключити з проєктної документації. Для самого анулювання в АРМ ідентифікатора об’єкта будівництва передбачена окрема процедура зміни та анулювання. Система не дасть підписати документ із задубльованими складовими, доки їх не приберете.
✅ Висновок: зайвий чи дубльований ідентифікатор анулюють через АРМ і виключають із проєкту до підпису, бо після реєстрації дубль номерів виправляється вже тільки судом.
📁 Кейс з нашої практики: Черкаська обл., апарт-готель. Девелопер був одночасно генеральним підрядником, а апартаменти йшли з розподілом по чергах, тому структуру ідентифікаторів довелося ув’язувати вручну без жодного дубля. Результат: близько 1130 МОН зареєстровано за півтора місяця, об’єкт продається.
Видалення чернеток і помилкових ідентифікаторів з карти ЄДЕССБ
ЄДЕССБ влаштована так, що внесені відомості не видаляються фізично, у них лише змінюється статус. Якщо ідентифікатор складової частини ще не підписаний, ви заходите в картку документа і тиснете «видана чернетка». Об’єкт переходить у статус чернетки, тобто перестає діяти, хоч і лишається в системі.
Далі виникає окреме питання, яке на вебінарі поставив учасник Андрій: як прибрати з карти вже видалені чернетки та помилкові ідентифікатори, коли вони заважають перегляду. Відповідь підтримки: такий шар прибирається з відображення, бо він справді ускладнює розуміння і показ основного ідентифікатора.
✅ Висновок: помилковий непідписаний ідентифікатор переводимо у чернетку через його картку, а зайвий шар прибираємо з карти, щоб бачити діючий ідентифікатор об’єкта.
Помилка квартири, успадкованої з батьківського ІОБ
Класична ситуація після коригування проєкту: у будинку зменшили кількість квартир, а в заяву на адресну довідку чи в СМП підтягуються старі, зайві квартири. Причина в тому, що адреса й склад складових тягнуться саме з батьківського ідентифікатора, а не з проєкту.
Логіка з практики підтримки проста. Якщо ви видалили неактуальні приміщення тільки в об’єкті будівництва, а в батьківському ідентифікаторі їх не анулювали, то зайві квартири залишаться в структурі. Правильний хід, підтверджений у чаті офіційної підтримки:
Тобто зміну типу приміщення чи його видалення робимо в обох місцях: і в проєкті, і в батьківському ідентифікаторі. Окремо тримайте в голові ще один нюанс: надлишкові квартири не перекочують самі в документ про визначення гарантійної частки з батьківського ідентифікатора, тому цей документ теж треба звіряти вручну.
✅ Висновок: якщо після коригування в заяву лізуть зайві квартири, анулюйте їх і в проєкті, і в батьківському ідентифікаторі, і окремо перевірте документ гарантійної частки.
Через таку ланцюгову залежність (проєкт → батьківський ідентифікатор → адреса → гарантійна частка → заява СМП) одна неврахована квартира здатна зупинити всю реєстрацію. За словами Ірини Гальченко, фахівця з ЄДЕССБ, авторки патентованого курсу «ЄДЕССБ від А до Я», правильність реєстрації МОН напряму залежить від коректності батьківських ідентифікаторів: вони мають відповідати генплану, мати правильну нумерацію і склад складових частин ще до роботи в системі.
Чому забудовники звертаються до PRO InfoBud
- Напрямок СМП/МОН у нас ведуть два досвідчені фахівці, Ірина Гальченко та Анна Хльобас, щодня і на потоці, тому D-помилки ідентифікаторів для нас рутина, а не квест.
- Ірина Гальченко, практик ЄДЕССБ і CEO PRO InfoBud, провела перший фаховий вебінар по закону про гарантування ще 18.10.2022 і веде авторський курс по роботі в ЄДЕССБ.
- Telegram-канал PRO InfoBud, 4500+ підписників: розбори D-кодів, статусів ідентифікаторів і практики реєстрації МОН.
- Не було випадку, щоб до нас звернулися по виправлення помилки, а ми не допомогли.
Помилки ідентифікаторів рідко ходять поодинці: за D007573 часто ховається і неправильний статус, і зайва квартира з батьківського ІОБ. Якщо не хочете місяцями звіряти прив’язку по кожному МОН вручну, передайте це фахівцю. Ми розбираємо структуру, анулюємо зайве і доводимо заяву СМП до реєстрації: виправлення помилок ідентифікаторів складових частин (МОН) у ЄДЕССБ під ключ.
