Загрузка в личный кабинет — отдельный шаг, а не автоматика
Собрать XML-пакет по приказу № 704 — только часть пути протокола до реестра. Дальше файл нужно загрузить в личный кабинет ФГИС Росаккредитации, и на этом шаге тоже можно потерять данные, даже если сам пакет подготовлен без ошибок. Загрузка не происходит сама по себе: файл в личный кабинет загружает сотрудник лаборатории, и это не формальность, а способ своими глазами видеть результат и контролировать, что именно ушло в реестр, а не полагаться на автоматику вслепую.
На практике это значит, что у загрузки должен быть конкретный ответственный человек — не «система как-то сама разберётся», а сотрудник, который знает, где посмотреть статус отправки и что делать, если личный кабинет вернул ошибку. Когда такого человека нет или обязанность размыта между несколькими сотрудниками, отказы дольше остаются незамеченными — иногда до следующей проверки, которая может случиться нескоро.
Токен доступа: частая причина, о которой забывают
Доступ к личному кабинету ФГИС для программной или полуавтоматической загрузки завязан на токен. Если токен просрочен, отозван или введён с ошибкой, загрузка не начнётся вовсе — и это выглядит как техническая ошибка, а не как проблема с содержимым пакета. Отличить одно от другого важно: если разбираться с токеном как с содержательной ошибкой в данных протокола, можно потратить время впустую, проверяя то, что и так было в порядке.
Токен стоит хранить так, чтобы доступ к нему был только у тех, кто отвечает за выгрузку, и желательно в зашифрованном виде — это не только вопрос безопасности, но и защита от случайной потери доступа при увольнении или смене сотрудника, когда токен «уходит» вместе с человеком, а новый никто вовремя не оформляет.
Лимит пакета и частичный приём
Один XML-файл вмещает не бесконечное число протоколов — на практике лаборатории ориентируются на пакет примерно в 100 протоколов. Если отправить файл с превышением, типичный результат — не полный отказ, а частичный приём или ошибка обработки, которую придётся разбирать отдельно по каждому протоколу внутри пакета, чтобы понять, какие именно из них прошли, а какие нет.
Проще заранее делить крупную партию на несколько файлов правильного размера, чем потом выяснять постфактум, где именно в большом пакете случился сбой. Особенно это чувствуется в периоды пиковой нагрузки — например, в отчётные месяцы, когда протоколов на выгрузку накапливается заметно больше обычного.
«Файл принят системой» — не то же самое, что «протокол в реестре»
Личный кабинет может подтвердить получение файла раньше, чем закончится его обработка. Между отправкой и итоговым статусом протокола в реестре проходит время, и в этот промежуток полагаться на память или переписку в почте — плохая идея: список того, что «вроде бы отправили», быстро расходится с тем, что реально дошло до реестра.
Факт приёма фиксируется в системе отдельной записью, и по каждому пакету должна оставаться запись в журнале — кто, когда и что именно отправил, с каким результатом. Подробнее о том, чем статус «сформировано» отличается от статуса «принято», и почему это разные факты — в отдельной статье про разницу этих двух статусов.
Типичные причины отказа на уровне содержимого
Часть ошибок при загрузке на самом деле не про сам процесс отправки, а про содержимое пакета, которое стоило проверить раньше: просроченная поверка прибора, пересечение специалиста или прибора между протоколами на одну дату, регион работ вне области аккредитации лаборатории, неполные реквизиты заказчика. Внешне это выглядит как «ошибка загрузки», хотя правильнее — как «ошибка подготовки», которую загрузка просто сделала видимой.
Подробный разбор состава XML-пакета и того, что чаще всего останавливает выгрузку по приказу № 704, — в статье «Приказ № 704: что должно быть в XML-пакете протокола». Если ошибки повторяются из пакета в пакет, стоит смотреть не на конкретную загрузку, а на то, как устроена подготовка протоколов до момента отправки.
Как снизить число неудачных загрузок
Практика, которая заметно снижает число отказов: не собирать и не загружать пакет одним действием в последний момент, а видеть готовность каждого протокола заранее — токен доступа под рукой и проверен, поверки приборов актуальны на дату загрузки, пакет не превышает разумный размер, реквизиты заказчика заполнены полностью. Каждый из этих пунктов по отдельности несложно проверить руками; сложность возникает, когда протоколов много и проверять приходится каждый раз заново.
Система, которая держит эти проверки на этапе подготовки протокола, а не только в момент отправки, переносит момент обнаружения ошибки туда, где её дешевле всего исправить — в черновик, а не в уже отправленный файл, который потом придётся пересобирать и загружать заново.
Чек-лист перед отправкой пакета
Чтобы не гадать постфактум, что именно пошло не так, стоит проверять перед каждой загрузкой один и тот же короткий набор условий:
- Токен доступа к личному кабинету действителен и не истекает в ближайшее время.
- Число протоколов в пакете не превышает практический лимит около 100 — иначе пакет лучше разбить на части заранее.
- Поверки приборов, указанных в протоколах, действительны на даты фактических измерений, а не только на сегодняшний день.
- Регион проведения работ по каждому протоколу входит в область аккредитации лаборатории.
- Реквизиты заказчика заполнены полностью и в формате, который ожидает ФГИС.
- Ответственный сотрудник понимает, где после отправки проверить итоговый статус, а не только факт получения файла.
Ни один из этих пунктов не заменяет собой внимательность при подготовке протокола — это именно последняя проверка перед тем, как файл уходит за пределы лаборатории, где исправить что-либо станет уже сложнее.
Пример из практики: пропущенный срок токена
Сотрудник лаборатории, который обычно отвечает за загрузку, ушёл в отпуск, а токен доступа к личному кабинету ФГИС был оформлен лично на него и хранился только в его рабочих заметках. За две недели отпуска накопилось несколько готовых пакетов — их пытались отправить, но каждый раз получали ошибку доступа, которую сначала приняли за сбой на стороне ФГИС. Только когда сотрудник вернулся и проверил токен, выяснилось, что срок его действия истёк ещё до отпуска, а обновить его без него никто не смог.
После этого случая в лаборатории завели правило: токен доступа не привязывается к одному человеку, а хранится в общем защищённом месте, доступном как минимум двум сотрудникам, и его срок действия проверяется заранее, а не постфактум по ошибкам загрузки.
Что это значит на практике для лаборатории
В ЛИМСИ загрузка в личный кабинет ФГИС остаётся действием сотрудника — система не подменяет собой ответственность лаборатории за то, что уходит в реестр, а собирает пакет, заранее проверяет ресурсы и реквизиты и ведёт журнал по каждой отправке, чтобы не приходилось восстанавливать историю загрузок по памяти. Если хотите увидеть, как это выглядит на данных вашей лаборатории — загляните на главную страницу ЛИМСИ.