Пояснительная записка в XML: что подготовить и проверить перед экспертизой

Уточните, какую пояснительную записку вы готовите

Пояснительная записка раздела 1 проектной документации и пояснительная записка к сметной документации — разные задачи. Совпадение слов «пояснительная записка» в названии не позволяет использовать одну схему вместо другой. При выборе редактора и проверки сопоставляйте полное название документа.

Для раздела 1 подготовка XML начинается со сведений проекта, а не с оформления оглавления. Полезно сразу назначить человека, который согласует общие реквизиты между авторами разделов. Иначе один и тот же объект попадёт в пакет с несколькими вариантами названия, адреса или состава участников.

Проверьте редакцию схемы перед новым выпуском

В официальном сообщении ГГЭ о переходе с 11 июня 2026 года для ПЗ указана версия 01.07. Это конкретное сообщение о конкретном обновлении, а не обещание, что номер больше не изменится. Перед выпуском заново проверьте каталог Минстроя и требования принимающей системы.

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

Соберите исходники до заполнения формы

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

Попросите авторов передать сведения с указанием версии. Если показатель изменился после согласования ПЗ, сначала уточните, какая редакция должна войти в выпуск. XML не должен становиться местом, где без согласования объединяют старый титул, новый показатель и приложение из прошлого проекта.

Разберите разночтения до автоматического заполнения

Условный пример: в задании объект называется «Реконструкция участка сети», а в титуле ПЗ — «Капитальный ремонт сети». Выбор более короткой строки не решает вопрос. Зафиксируйте оба источника, передайте расхождение ответственному и используйте подтверждённую формулировку во всём комплекте.

Второй пример — адрес. Текстовый адрес объекта, кадастровый номер участка и наименование территории относятся к разным сведениям. Не подменяйте одно другим только для заполнения обязательного поля. Если редактор не принимает значение, сначала выясните назначение поля и применимость блока.

Проверяйте показатели вместе с единицами и границами

Число без контекста опасно: протяжённость сети, длина отдельной нитки, длина участка работ и общая протяжённость существующей системы могут выглядеть одинаково убедительно. Для каждого переносимого показателя удобно записать, к чему он относится и какой документ его подтверждает.

Не пересчитывайте единицы молча. Если в исходнике показатель указан в километрах, а поле требует метры, сохраните расчёт преобразования в рабочей ведомости. Проверку поручайте человеку, понимающему предмет показателя: технический валидатор не узнает, что вы перепутали существующую и проектируемую часть.

Сверьте состав проекта с фактическими файлами

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

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

Проверьте машиночитаемый и человекочитаемый результат

Сначала получите технический протокол для типа «Пояснительные записки» в официальной проверке ГГЭ. Затем просмотрите представление, сформированное из итогового XML, если выбранное средство его поддерживает. Сравнивать нужно результат той же версии файла, а не отдельный PDF, сохранённый до исправлений.

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

Контроль перед передачей ПЗ на подпись

Сохраните этот контрольный список рядом с выпуском. При повторной подготовке он позволит проверять изменённые сведения адресно и одновременно видеть общие реквизиты, на которые изменение могло повлиять.

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