XML для экспертизы: как подготовить документы из Word и PDF

Сначала определите документ, который нужен экспертизе

Запрос «сделать XML для экспертизы» кажется одной задачей, пока не выясняется, что под ним понимают разные документы: пояснительную записку, задание на проектирование, материалы изысканий или сметные данные. У них различаются состав сведений, схема и порядок проверки. В частности, ПЗ раздела 1 проектной документации и пояснительная записка к сметной документации — разные документы. Универсального файла, который заменяет весь комплект, не существует.

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

Почему переименование PDF в XML не работает

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

С Word похожая ситуация. Наличие XML внутри формата DOCX не делает документ экземпляром схемы Минстроя. Нужен содержательный перенос: определить назначение каждого фрагмента, связать его с нужным полем и проверить результат. Распознавание скана решает лишь задачу извлечения текста; принадлежность реквизитов и смысл таблиц проверяются отдельно.

Выберите схему до переноса данных

Официальный отправной пункт — каталог XML-схем Минстроя. Найдите документ по полному названию, проверьте дату начала применения выбранной редакции и сохраните доступный пакет схем с описанием. Не ориентируйтесь только на дату скачивания или название папки у коллеги: внутри может оказаться архивная версия.

В информации ГГЭ о задании на проектирование от 9 июля 2025 года применение XML связано с наличием действующей схемы соответствующего документа; отдельно оговорены ситуации повторной экспертизы. Поэтому нельзя распространять одну дату и один порядок на любой документ и любое обращение. Спорный сценарий лучше уточнить до подготовки файла.

Соберите таблицу переноса: значение, источник, статус

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

Переносите смысл, а не внешний вид страницы

Предположим, в PDF написано «две нитки по 300 м». Нельзя без проверки занести 600 в поле, назначение которого — протяжённость трассы. Сначала установите, какое именно значение требуется полю, затем сохраните исходное объяснение. Этот пример показывает риск переноса показателей; он не устанавливает правило заполнения конкретной схемы.

То же относится к датам, номерам и названиям организаций. Отделяйте номер документа от даты, не переносите подпись соседнего столбца в значение. Если редактор предлагает справочник, выбирайте подтверждённый вариант. При отсутствии сведений оставляйте вопрос ответственному; «0», «нет» и «неизвестно» имеют разный смысл.

Проведите четыре отдельные проверки

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

• Файл читается: XML не оборван, сохранён в корректной кодировке и открывается XML-инструментом.
• Структура подходит: выбран правильный тип документа и выполнена проверка по соответствующей XSD-схеме.
• Сведения согласованы: реквизиты, показатели, участники и ссылки сопоставлены с исходниками и комплектом.
• Передача подготовлена: выбран требуемый способ подписания, собраны приложения и проверен результат загрузки.

Как организовать исправления без путаницы версий

Заведите отдельные папки рабочего проекта и передаваемого выпуска. Для внутреннего учёта достаточно понятной версии, даты и короткого описания изменения: исправили заказчика, уточнили показатель, заменили приложение. Не называйте пять разных файлов «финальный» и не собирайте пакет из вложений разных писем.

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

Что должно остаться после подготовки

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

Последовательность применима к выбранному вами редактору: документ и схема → ведомость данных → формирование → проверка → подписание → загрузка. Порядок полезен именно тем, что не зависит от кнопки конкретной программы. Смена инструмента не отменяет необходимости подтвердить исходные сведения и проверить передаваемый выпуск.