Минстрой обновил XML-схемы для Раздела 1 ПД, Задания на проектирования, Заключения экспертизы: что важно учесть проектировщикам

Минстрой России обновил сразу несколько XML-схем, с которыми проектные организации работают на этапе подготовки и сопровождения документации. Изменения затронули пояснительную записку, заключение экспертизы и задание на проектирование. Для специалистов это означает не просто переход на новые версии файлов, а необходимость проверить, как теперь оформляются участники проекта, адресные данные, признаки объекта и обязательные сведения в документах.

Пояснительная записка

Обновлённая XML-схема раздела ПД №1 «Пояснительная записка» переведена на версию 01.07 и заметно переработана по внутренней логике. Основное направление изменений связано с унификацией сведений об участниках подготовки документации.

В схеме появился новый элемент ChiefProjectEngineerSurvey, который используется для описания главного инженера проекта, обеспечившего подготовку инженерных изысканий. В этом блоке указываются ФИО, СНИЛС, номер в НРС НОПРИЗ и, при необходимости, e-mail.

Также существенно изменён подход к описанию участников разработки документа. Вместо типа tProjectDocParticipants теперь применяется новый тип tDocParticipants. Он используется для сведений о разработке, нормоконтроле и согласовании и включает единый набор данных: ФИО, СНИЛС, номер в НРС НОПРИЗ и e-mail.

Тип tEngineeringSurveyDocument дополнен элементом DocParticipants. За счёт этого можно более подробно фиксировать участников подготовки и согласования отчетной документации по инженерным изысканиям.

Также переработана структура подписантов документа. Теперь: 

• ChiefProjectEngineer использует тип tEngineerPersonNOPRIZ; 
• Signer использует тип tEngineerPersonNoNOPRIZ; 
• добавлен ChiefProjectEngineerSurvey с типом tEngineerPersonNOPRIZ.

Обновлены типы для авторов, застройщиков, технических заказчиков и разработчиков документации. Часть прежних сущностей исключена, вместо них введены более унифицированные модели описания организаций, индивидуальных предпринимателей и физических лиц. Эти изменения затрагивают, в частности, типы tAuthor, tDeveloper, tTechnicalCustomer и tProjectDocumentationAuthor.

Отдельный блок изменений касается адресов. Адресные типы перенесены в общую группу и теперь используют новый тип tRegionCode вместо устаревшего tRegionsRF. Для тех, кто автоматизирует заполнение XML-документов, это важно, поскольку влияет на настройку адресных блоков и проверку данных.

Кроме того, введена новая иерархия типов для физических лиц, организаций и индивидуальных предпринимателей.

В целом новая версия схемы стала более согласованной с другими XML-схемами строительной отрасли. Это упрощает унификацию данных и делает структуру документа более устойчивой к последующим изменениям.

Заключение экспертизы

XML-схема заключения экспертизы обновлена до версии 1.04. Основные изменения здесь затрагивают описание объекта капитального строительства и его связь с государственными информационными системами.

В схеме появился новый тип tElectronicBudgetObjectCode для объектов, связанных с бюджетным финансированием. Он предназначен для хранения уникального кода объекта капитального строительства, присвоенного системой «Электронный бюджет».

Расширен тип tObject. В него добавлены:

• необязательный атрибут ElectronicBudgetObjectCode;
• обязательный атрибут DangerousAndComplex — признак отнесения объекта к технически сложным или опасным;
• обязательный атрибут Unique — признак уникального объекта.

Иными словами, характеристики объекта в заключении экспертизы теперь фиксируются более четко.

Изменен и подход к описанию адреса. Это связано с введением обязательного указания кода ОКТМО и наименования муниципального образования. Для этого в схеме добавлены типы tRussianAddress, tForeignAddress и tObjectAddress, а типы tAddress и tPostAddress переработаны. Дополнительно из справочника кодов субъектов исключено значение «00».

В схеме появился элемент NationalProject типа tNationalProject для объектов, реализуемых в рамках государственных программ. Он позволяет указать, включен ли объект:

• в федеральный проект в составе национального проекта;
• в региональный проект в составе национального проекта.

В сложный тип tExpert добавлен элемент SNILS. Теперь в структуре схемы предусмотрено хранение страхового номера индивидуального лицевого счета эксперта.

Кроме того, введен тип tRequirementsDate. Он используется для указания даты, на которую действовали нормативные требования, применяемые при проведении экспертизы. Это важное изменение с точки зрения прослеживаемости нормативной базы, особенно в условиях частого обновления правил и требований.

Часть типов данных также была пересмотрена для унификации с другими XML-схемами. Это делает структуру документов более совместимой и помогает сократить разночтения между различными электронными формами.

Задание на проектирование

11 марта 2026 года Минстрой России разместил обновленную версию XML-схемы задания на проектирование — DesignAssignment-01-01.xsd. Новая версия учитывает изменения в законодательстве, исправляет ошибки предыдущих редакций и пересматривает обязательность ряда полей.

Общая логика новой версии — сделать схему более гибкой и унифицированной. Разработчики сократили количество строго обязательных полей, актуализировали справочники и уточнили структуру участников проекта.

В новой редакции ряд элементов стал опциональным. Это касается, в частности:

• EngineeringSurvey;
• Land;
• InitialDocuments;
• ProjectDocuments;
• выбора типа объекта: IndustrialObject, NotIndustrialObject, LinearObject.

Также необязательными стали многие атрибуты объекта, которые в версии 01.00 были обязательными, в том числе SecurityInfluence, DangerousIndustrialObject, FireDangerCategory, ResponsibilityLevel и ряд других.

Среди важных структурных изменений — возможность указывать нескольких технических заказчиков. Для этого введен контейнер TechnicalCustomers.

Переработан блок разработчиков проектной документации. Теперь:

• DesignerGeneral используется для генпроектировщика;
• можно указывать несколько элементов Designer для субподрядчиков;
• появилась возможность фиксировать номер в реестре НОПРИЗ.

Изменена и модель адреса. Новый тип tObjectAddress позволяет описывать не только стандартный адрес объекта, но и расположение на континентальном шельфе, во внутренних водах и в исключительной экономической зоне.

Есть и ряд технических изменений:

• в тип tSecurityLabel добавлено значение 4 — «Для служебного пользования»;
• тип tFinanceRatioValue изменён с float на decimal для более точной работы с долями финансирования;
• в tFunctionalRole вместо числовых значений теперь используются текстовые — «Утверждено» и «Согласовано»;
• тип tObjectCode исключен, вместо него применяется tNotEmptyString200.

Кроме этого:

• тип автора в DocumentInfo приведен к единому tAuthor;
• удален элемент Author внутри Requirement;
• удален элемент IULFile — информационно-удостоверяющий лист больше не требуется;
• аннотации элементов дополнены ссылками на приказ Минстроя 307/пр.

При этом проектировщикам важно учитывать один принципиальный момент. То, что часть полей стала необязательной на уровне XSD-схемы, не означает, что эти сведения можно не указывать с точки зрения законодательства. Например, уровень ответственности объекта, категория пожарной опасности и другие характеристики по-прежнему должны содержаться в задании на проектирование, если этого требует часть 11 статьи 4 Федерального закона № 384-ФЗ.

То есть XML-схема стала гибче технически, однако требования закона к содержанию документа это не отменяет.

Что это значит для проектных организаций

Если рассматривать эти обновления в комплексе, становится видно, что Минстрой последовательно переводит документацию к более единому цифровому формату. Схемы становятся ближе друг к другу по структуре, по типам данных и по логике описания участников проекта.

Для проектных организаций это означает, что привычные шаблоны и внутренние процессы стоит пересмотреть заранее. Особенно это касается компаний, которые используют собственные формы выгрузки XML, автоматизированные решения или работают сразу с несколькими типами документов в одном проекте.

На практике внимание стоит обратить на несколько вещей:

• поддерживают ли используемые инструменты новые версии схем;
• корректно ли в документах отражаются разработчики, подписанты и технические заказчики;
• правильно ли передаются адресные данные и характеристики объекта;
• не исчезают ли из документа важные сведения только потому, что в новой схеме они стали технически необязательными.

Именно на этих деталях чаще всего и возникают проблемы при переходе на обновленные форматы.

Итог

Обновление XML-схем затрагивает сразу несколько базовых документов, которые используются в проектировании и экспертизе. Формально изменения выглядят как технические, однако по факту они влияют на повседневную работу проектировщиков, ГИПов, технических заказчиков и всех, кто участвует в подготовке и выпуске документации.

Новая версия схемы пояснительной записки усиливает унификацию данных об участниках проекта. Схема заключения экспертизы делает более формализованным описание самого объекта. Обновлённое задание на проектирование даёт больше гибкости по структуре, при этом не снимает обязательных требований законодательства к содержанию документа.

Поэтому главный практический вывод простой: новые версии схем нужно не просто принять к сведению, а заранее встроить в рабочие процессы. Это поможет избежать технических сбоев, формальных замечаний и лишней доработки уже на этапе подачи документов.

Будьте в курсе изменений в сфере строительного законодательства, вступайте в наш Телеграм-канал, где мы обсуждаем вопросы проектирования и экспертизы проектной документации, делимся актуальными новостями и изменениями в правовых актах, отвечаем на Ваши вопросы.