Как сформировать валидный XML протокола для ФГИС

XML для ФГИС протокол должен быть не просто технически читаемым файлом, а машиночитаемым представлением конкретного испытания: с корректной структурой, обязательными реквизитами и справочными идентификаторами. Ошибка в одном поле может привести к отказу при загрузке, даже если сам протокол оформлен правильно. Разберём, из чего состоит валидный XML одного протокола и какие проверки нужно сделать до отправки.

Что значит «валидный XML протокола»

Валидность XML складывается из двух уровней. Первый — технический: файл должен соответствовать XML-синтаксису и XSD-схеме, которую использует ФГИС. Все обязательные элементы должны быть на месте, вложенность должна быть правильной, даты и числовые значения — в ожидаемом формате. Если нарушен этот уровень, система даже не переходит к смысловой проверке данных.

Второй уровень — предметный. Файл может быть корректным с точки зрения XML, но содержать данные, которые ФГИС не сможет принять: методика не связана со справочником ФСА, показатель указан произвольной строкой, объект испытаний не соответствует ОА, номер протокола дублируется, дата выбивается из допустимой логики. Для лаборатории важны оба уровня, потому что отказ обычно выглядит как единая ошибка загрузки, а причина может быть как в структуре файла, так и в содержании.

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

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

Обязательные блоки XML протокола

У каждого формата есть свои технические детали, но логика XML протокола во ФГИС обычно строится вокруг нескольких смысловых блоков. Первый блок — идентификация лаборатории: сведения об аккредитованном лице, аттестате и подразделении, если оно используется в учёте. Второй — идентификация самого протокола: номер, дата выдачи, дата проведения испытаний, основание и сведения о заказчике в том объёме, который требуется для передачи.

Третий блок — объект испытаний. Здесь важно не смешивать внутреннее коммерческое название образца и справочное значение объекта из ОА. Для ФГИС нужен объект, который можно сопоставить с областью аккредитации и справочниками ФСА. Четвёртый блок — методики и показатели: по каждой строке результата должно быть понятно, каким методом испытаний получено значение и какой показатель измерялся.

Пятый блок — результаты испытаний. Ошибки здесь часто возникают не из-за цифр как таковых, а из-за формата: десятичный разделитель, единицы измерения, пустые значения, текстовые комментарии в числовом поле. Если в протоколе используется «менее 0,1», «не обнаружено» или диапазон значений, нужно заранее понимать, как это кодируется в XML, а не переносить строку как есть.

• Лаборатория: аттестат, наименование, сведения из реестра аккредитованных лиц.
• Протокол: номер, даты, статус, ссылка на документ или скан, если он передаётся.
• ОА: методика, показатель и объект со справочными идентификаторами.
• Результаты: значения, единицы измерения, признаки неопределённости или комментарии.
• Контроль: отсутствие дублей, корректные даты, заполненные обязательные поля.

Справочники ФСА и идентификаторы в XML

Самая чувствительная часть XML после 1 сентября 2026 — связка с официальными справочниками ФСА. В протоколе недостаточно написать название методики и показатель так, как они выглядят в бумажном документе. XML должен содержать данные, которые позволяют ФГИС однозначно сопоставить протокол с областью аккредитации лаборатории и справочными записями.

Проблема в том, что в реальных протоколах формулировки часто живут своей жизнью. Методика может быть сокращена, показатель переименован для удобства заказчика, объект указан более конкретно, чем в ОА. Для человека это не всегда ошибка, но для выгрузки возникает разрыв: ОА говорит одно, протокол показывает другое, XML передаёт третье. Валидация должна находить такие расхождения до того, как файл попадёт в личный кабинет.

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

Для пакетной отправки эти требования становятся ещё строже: одна повторяющаяся ошибка в шаблоне может размножиться на десятки протоколов. Подробно сценарий пакета разобран отдельно в материале о том, как сформировать XML для ФГИС. В этой статье важно зафиксировать принцип: валидность начинается на уровне одной строки результата, а не на уровне готового файла.

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

Проверки перед отправкой

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

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

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

Четвёртый блок — справочники. Проверьте, что методики, показатели и объекты имеют актуальные идентификаторы, а не только текстовые названия. Если система формирует XML из Excel, обратите внимание на ручные правки: пользователь мог изменить название в ячейке, но не обновить скрытый код. Именно такие несоответствия трудно заметить глазами.

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

Типичные ошибки валидности

Частая ошибка — пустое обязательное поле, которое в визуальном протоколе вообще не заметно. Например, в Word-документе дата стоит в колонтитуле или в свободном тексте, а генератор XML ждёт её в отдельной структурированной ячейке. В результате человек видит дату, а файл передаёт пустоту.

Вторая ошибка — дублирование номера протокола. Оно возникает, когда лаборатория копирует прошлый документ, меняет видимую часть номера, но не обновляет внутренний идентификатор в реестре или таблице выгрузки. Для ФГИС это выглядит как повторная отправка уже существующей записи.

Третья ошибка — неверная связь методики и показателя. Показатель может быть корректным сам по себе, но выбран не под той методикой или объектом. В бумажном протоколе это выглядит как нормальная строка, а при машиночитаемой проверке превращается в несоответствие ОА.

Четвёртая ошибка — попытка передать комментарии в поле результата. Формулировки вроде «менее предела обнаружения», «следы» или «не нормируется» нужно кодировать так, как допускает формат. Если просто положить текст в числовое поле, XML не пройдёт проверку.

Если ФГИС уже вернула ошибку, полезно сверить её с общей картой причин в статье «ФГИС не принимает протокол: что делать». Но практичнее находить эти ошибки до отправки, пока протокол ещё можно спокойно исправить во внутреннем реестре.

Почему валидность начинается в источнике данных

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

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

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

Часто задаваемые вопросы

Что такое XML для ФГИС протокол?

Это структурированный файл, в котором сведения из протокола испытаний представлены в машиночитаемом виде. В нём должны быть реквизиты лаборатории, номер и даты протокола, объект, методики, показатели, результаты и справочные идентификаторы, если они требуются форматом.

Можно ли проверить XML до загрузки во ФГИС?

Да. Минимум — проверить XML по синтаксису и XSD-схеме. Более полезная проверка включает сверку обязательных полей, дат, дублей и идентификаторов ФСА, потому что технически корректный файл всё равно может содержать предметную ошибку.

Почему XML проходит схему, но ФГИС всё равно отклоняет протокол?

XSD проверяет структуру, но не всегда закрывает все смысловые несоответствия. Протокол могут отклонить из-за неверного идентификатора методики, несоответствия ОА, дубля номера или ошибки в справочном значении.

Нужно ли добавлять идентификаторы ФСА в каждый XML?

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

Как Лаб.Регора помогает сформировать валидный XML?

Лаб.Регора проверяет протокол до отправки: извлекает методики и показатели, сверяет их со справочниками ФСА, подсвечивает незаполненные обязательные поля и показывает несоответствия, которые лучше исправить до формирования XML.

Лаб.Регора помогает подготовить XML для ФГИС протокол без лишнего риска: проверяет обязательные поля, справочники ФСА и потенциальные ошибки до отправки. Загрузите протокол бесплатно и получите отчёт о готовности за минуты.