Как настроить обмен 1С с ФГИС «Меркурий» и какие решения выбрать для интеграции?

← На главную

Интеграция учетных систем 1С с государственной информационной системой в области ветеринарии ФГИС «Меркурий» (ВетИС) — одна из ключевых задач для предприятий, работающих с подконтрольной продукцией (производство, оптовая и розничная торговля). Разберем доступные варианты интеграции, архитектурные особенности взаимодействия по протоколу ВетИС.API 2.0, а также методы решения типовых проблем с производительностью и блокировками записей складского журнала.

Выбор варианта интеграции с ФГИС «Меркурий»

Проанализируем основные подходы к организации обмена данными между 1С и шлюзом ВетИС:

Встроенная типовая подсистема 1С: Начиная с версий программных продуктов «1С:ERP Управление предприятием 2», «1С:Комплексная автоматизация 2», «1С:Управление торговлей 11» и «1С:Розница» типовой функционал включает подсистему интеграции с ВетИС. Этот вариант подходит для оптовой и розничной торговли, где требуется гашение входящих эВСД и оформление транспортных партий при перепродаже без сложного многопередельного производства.
Специализированные отраслевые решения (например, «1С:Управление ветеринарными сертификатами»): Самостоятельные конфигурации или модули, работающие как шлюзы. Они позволяют реализовать обмен даже со старыми конфигурациями (включая платформу 1С:Предприятие 7.7 и УПП 1.3), вынося всю нагрузку по хранению метаданных ВетИС и логике протокола в отдельную базу.
Сторонние коммерческие интеграционные модули и шлюзы провайдеров: Решения от операторов электронного документооборота и интеграторов. Они берут на себя форматирование запросов, очереди отправки и адаптацию под изменения форматов API, однако требуют регулярной оплаты лицензий и доработки под специфику нетипового учета.
Прямая самостоятельная интеграция через Web-сервисы (ВетИС.API): Разработка собственного модуля интеграции в 1С. Подходит для крупных предприятий с уникальными бизнес-процессами, высокими объемами отгрузок (тысячи ВСД в час) и жесткими требованиями к скорости формирования документов.

Технические особенности работы с ВетИС.API 2.0

Рассмотрим, как устроена работа со шлюзом ВетИС на низком уровне. Протокол взаимодействия построен на базе SOAP с асинхронной обработкой запросов:

Отправка заявки: Клиентское приложение 1С вызывает метод submitApplicationRequest, передавая XML-пакет с телом операции (например, оформление производственной партии, списание, инвентаризация или оформление транспортного ВСД).
Получение идентификатора: Сервис возвращает уникальный идентификатор заявки (applicationId).
Опрос результата: С интервалом в несколько секунд отправляется запрос receiveApplicationResultRequest. До момента завершения обработки шлюз возвращает статус IN_PROCESS. По завершении статус меняется на COMPLETED (с результатом операции) или REJECTED (с описанием ошибки).

Посмотрим на пример структуры заголовка и тела SOAP-запроса для получения списка ветеринарных документов:


<soapenv:Envelope xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"
                  xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
                  xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
                  xmlns:apl="http://api.vetrf.ru/schema/cdm/application"
                  xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"
                  xmlns:bs="http://api.vetrf.ru/schema/cdm/base"
                  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
        <apldef:submitApplicationRequest>
            <apldef:apiKey>КлючДоступаAPI</apldef:apiKey>
            <apl:application>
                <apl:serviceId>mercury-g2b.service:2.0</apl:serviceId>
                <apl:issuerId>ИдентификаторИнициатораGUID</apl:issuerId>
                <apl:issueDate>2024-01-15T10:00:00</apl:issueDate>
                <apl:data>
                    <merc:getVetDocumentListRequest>
                        <merc:localTransactionId>TR-000101</merc:localTransactionId>
                        <merc:initiator>
                            <vd:login>ЛогинПользователяВетис</vd:login>
                        </merc:initiator>
                        <bs:listOptions>
                            <bs:count>100</bs:count>
                            <bs:offset>0</bs:offset>
                        </bs:listOptions>
                        <vd:vetDocumentType>TRANSPORT</vd:vetDocumentType>
                        <vd:vetDocumentStatus>CONFIRMED</vd:vetDocumentStatus>
                        <dt:enterpriseGuid>GUIDПлощадки</dt:enterpriseGuid>
                    </merc:getVetDocumentListRequest>
                </apl:data>
            </apl:application>
        </apldef:submitApplicationRequest>
    </soapenv:Body>
</soapenv:Envelope>

Важное правило адресации пространств имен: Обратите внимание, что поля типа документа и статуса (vetDocumentType, vetDocumentStatus) должны находиться в пространстве имен http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2 (префикс vd), иначе парсер Oracle Service Bus шлюза вернет ошибку разбора XML BEA-382513: expected exactly one item, got 0 items.

Решение проблемы блокировок записей журнала (MERC02462)

При массовых отгрузках часто возникает критическая ошибка: MERC02462: «В запросе был указан идентификатор записи журнала, которая была обновлена одновременно с попыткой выполнения данной операции».

Выясним причину: система ВетИС версионирует каждую запись складского журнала. При списании части объема создается новая версия записи с новым UUID. Если отправить параллельно несколько запросов на списание объемов из одной и той же исходной партии (например, одна производственная партия разлита по десяткам расходных накладных), все запросы, кроме первого, завершатся ошибкой.

Разберем проверенные алгоритмы устранения этой проблемы:

Очередь сообщений с контролем используемых записей:
Реализуем в 1С буферную таблицу (регистр сведений) неотправленных накладных. Фоновое задание анализирует список документов к отправке. Если в очереди есть несколько накладных, списывающих остаток с одной и той же записи складского журнала, система отправляет первую накладную, блокирует отправку остальных документов с этой записью до получения ответа COMPLETED, обновляет актуальный остаток/версию записи в 1С и только затем отправляет следующую накладную.
Технологическое схлопывание/дробление партий:
Перед массовой выпиской рейса можно средствами производственной транзакции или инвентаризации объединить разнородные остатки в одну сводную запись либо, наоборот, сформировать отдельные дочерние записи складского журнала под каждую планируемую ТТН. Это исключает пересечение записей между параллельными потоками отправки.
Использование GUID вместо UUID:
В структурах данных ВетИС GUID идентифицирует сам объект (партию) на протяжении всего жизненного цикла, а UUID — конкретную ревизию (версию) записи. В операциях оформления транспортных партий по возможности передавайте глобальный GUID партии, что снижает риск рассинхронизации ревизий.

Учет по сериям и сопоставление номенклатуры в 1С

Для корректной работы обмена необходимо настроить структуры данных в учетной системе 1С:

Серийный и партионный учет: В 1С справочник СерииНоменклатуры (или механизм партий) должен хранить:
- Дату производства и дату окончания срока годности;
- Идентификатор записи складского журнала ВетИС (GUID);
- Номер производственной партии производителя.
Сопоставление номенклатуры (4-й уровень классификатора ВетИС): Каждая номенклатурная позиция 1С должна быть привязана к записи четвертого уровня справочника продукции ВетИС (реестр наименований конкретного предприятия с указанием артикула или GTIN), а не только к общей категории 3-го уровня (например, «Мясная продукция»).
Управление правами доступа (Приказы Минсельхоза № 646, 647, 648):
Учитывайте уровень полномочий пользователя, под логином которого подписывается транзакция:
- По Приказу № 646 уполномоченные лица организаций имеют право оформлять ВСД только на определенные виды готовой переработанной продукции (прошедшей термическую обработку, упакованной в потребительскую тару).
- По Приказу № 648 (сырое мясо, сырое молоко, рыба без термообработки) оформление ВСД требует роли аттестованного специалиста или государственного ветеринарного врача.
Проверить и настроить эти права можно в личном кабинете системы Ветис.Паспорт.

Оптимизация производительности обмена

Для стабильной обработки больших объемов документов (более 1000 накладных в сутки) придерживайтесь следующих правил:

Асинхронные пулы отправки: Выносите запросы в фоновые задания на сервере 1С:Предприятие. Клиентский сеанс пользователя должен лишь создавать задачу в очереди, не ожидая ответа от внешнего сервиса.
Интервалы опроса статуса: Не опрашивайте шлюз циклически без пауз. Оптимальная задержка между отправкой заявки и первым опросом составляет 10–15 секунд, с последующим шагом опроса в 5–10 секунд.
Контроль дробных остатков: Из-за различий в округлении объемов между 1С (обычно 3 знака) и базой данных ВетИС при многократных отгрузках могут накапливаться микроостатки (доли грамма). Периодически выполняйте автоматическую инвентаризацию для списания нулевых и несущественных остатков, чтобы журнал не засорялся миллионами неактуальных записей.