Пакетная загрузка протоколов во ФГИС: как сформировать XML

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

Чем пакет отличается от разовой отправки

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

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

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

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

Какие данные подготовить для XML

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

Перед формированием пакета проверьте таблицу соответствий. Методика должна быть связана с записью справочника ФСА, показатель — с методикой, объект — с областью аккредитации. Если идентификатор отсутствует или выбран по сомнительному совпадению, протокол не должен попадать в пакет.

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

Как формировать пакетный XML

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

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

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

Если нужен разбор валидности отдельного протокола, используйте материал как сформировать валидный XML протокола для ФГИС. Пакетная загрузка строится на той же логике, только требования к дисциплине выше.

Как контролировать результат загрузки

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

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

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

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

Preflight-проверка перед сборкой пакета

Перед формированием XML сделайте preflight-проверку списка протоколов. У каждого документа должен быть статус, источник данных и отметка о справочниках. Если статус неизвестен, протокол не включается в пакет. Если источник данных менялся после проверки, документ возвращается на повторный контроль.

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

Проверьте справочные идентификаторы. Если методика или показатель отмечены как спорные, протокол не должен попадать в XML. Сначала подтверждение, затем пакет. Это правило кажется строгим, но именно оно защищает от массового размножения одной ошибки.

Как поддерживать пакетную выгрузку в рабочем состоянии

После первого успешного пакета важно не считать задачу закрытой. Справочники ФСА обновляются, шаблоны меняются, появляются новые методики и сотрудники. Раз в период проверяйте, что таблица соответствий актуальна, а генератор XML использует именно её последнюю версию.

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

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

Роли и ответственность при пакетной выгрузке

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

Если роли не разделены, пакетная выгрузка превращается в ручную работу одного внимательного сотрудника. Пока он на месте, процесс держится. Как только поток растёт или сотрудник уходит в отпуск, появляются дубли, пропущенные поля и спорные идентификаторы. Регламент нужен не для бюрократии, а для воспроизводимости.

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

Зачем нужна тестовая партия

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

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

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

Типичные ошибки при сборке пакета

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

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

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

Четвёртая ошибка — отсутствие контроля версий справочников. Если пакет готовился по старой таблице идентификаторов, часть методик может выглядеть корректно внутри лаборатории, но быть проблемной для ФГИС. Перед массовой отправкой проверяйте дату обновления справочников и таблицы соответствий.

Что делать, если пакет не принят

Если пакет не принят, сначала разделите ошибку на локальную и системную. Локальная относится к одному протоколу: пустое поле, неверный номер, нестандартный результат. Системная повторяется во многих документах: неправильный ID методики, ошибка шаблона, неверное правило импорта. От этого зависит, исправлять один документ или всю партию.

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

Если ошибка непонятна, уменьшите партию. Сформируйте тестовый XML из одного-двух проблемных протоколов и проверьте их отдельно. Так проще найти поле, которое ломает загрузку, и не тратить время на весь пакет.

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

Что такое пакетная загрузка протоколов ФГИС?

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

Сколько протоколов можно включать в один XML?

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

Что проверить перед формированием пакетного XML?

Номера, даты, обязательные поля, методики, показатели, объекты, идентификаторы ФСА, дубли и нестандартные результаты. Спорные протоколы лучше исключить из партии до подтверждения.

Почему пакет может не пройти загрузку?

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

Как Лаб.Регора помогает с пакетной загрузкой?

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

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