Как дистрибьютору настроить интеграцию 1С с ГИС «Меркурий» и запустить партионный учет подконтрольной продукции

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

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

В этой статье мы подробно разберем, как правильно выстроить ИТ-архитектуру предприятия для работы с ФГИС «Меркурий», почему стандартная бухгалтерия не подходит для этих задач, как организовать партионный учет в торговых конфигурациях и как обойти типичные технические проблемы интеграции, включая зависания шлюзов и ошибки веб-служб.

Выбор архитектурного решения: почему «1С:Бухгалтерия» не подходит для автоматизации «Меркурия»

Первое заблуждение многих руководителей компаний и главных бухгалтеров заключается в том, что интеграцию с ВетИС можно полноценно запустить на базе типовой конфигурации 1С:Бухгалтерия предприятия 3.0. Рассмотрим, почему при сколько-нибудь серьезном обороте (более 10–20 отгрузок в день) эта схема обречена на провал.

В конфигурации 1С:Бухгалтерия 3.0 отсутствует оперативный складской учет в разрезе физических партий и серий. Да, в программе декларируется партионный учет (списание по FIFO), однако это финансово-стоимостные партии, не привязанные к конкретным физическим датам производства и срокам годности на складе. Типовой механизм интеграции ВетИС в БП 3.0 потребует от оператора подбирать записи складского журнала ВетИС вручную для каждой строки реализации. При объеме отгрузок в сотни заказов в сутки ручной подбор превращается в логистический кошмар.

Для стабильной работы дистрибьютора необходима связка управленческой и финансовой баз. В качестве ядра автоматизации товародвижения и интеграции с ГИС «Меркурий» следует выбирать решения с поддержкой полноценного серийного учета:

  1. 1С:Управление торговлей 11 (УТ) — оптимальный выбор для чистой дистрибуции.
  2. 1С:Комплексная автоматизация 2 (КА) или 1С:ERP Управление предприятием 2 — если у компании, помимо оптовой торговли, есть собственная переработка, фасовка или производство.

В этих решениях складские серии напрямую связываются с записями складского журнала ВетИС, что позволяет полностью автоматизировать выписку транспортных эВСД на основании документов реализации.

Организация партионного (серийного) учета в 1С

Проанализируем суть требований ВетИС к автоматическому списанию. Чтобы программа могла автоматически подобрать запись складского журнала «Меркурия» при отгрузке, информационная система должна точно знать, товар какой даты выработки физически уехал клиенту. Вариант «списывать по FIFO виртуально» в учетной системе не сработает: если в бумажных документах (или эВСД) будет значиться одна дата выработки, а на коробках в машине приедет другая, торговые сети оформят возврат всей машины, а надзорные органы могут выписать крупный штраф.

Для решения этой задачи необходимо задействовать механизм серий. Разберем по шагам логику настройки учета в 1С:Управление торговлей 11:

  1. Для подконтрольной номенклатуры создаем отдельный Вид номенклатуры (например, «Молочная продукция подконтрольная»).
  2. В настройках этого вида номенклатуры включаем флаг Использовать серии.
  3. Настраиваем политику учета серий. Для дистрибьютора оптимально подходит политика с типом Управление остатками серий. В качестве идентифицирующих параметров серии выбираем Дата производства и Срок годности (именно эти параметры транслируются в ВетИС как основные).
  4. При поступлении товаров от поставщика кладовщики обязаны фиксировать реальные серии (даты выработки) с упаковок. Если используется ТСД (терминалы сбора данных), этот процесс автоматизируется сканированием штрихкодов.

При такой схеме каждая серия в 1С однозначно сопоставляется с идентификатором записи складского журнала ВетИС (GUID записи). При проведении документа Реализация товаров и услуг система автоматически определяет серии списываемых товаров и по регистру сведений Соответствие номенклатуры ВЕТИС находит нужные GUID для генерации исходящих эВСД.

Решение проблемы пересчета веса: нетто против брутто

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

Если система 1С будет передавать в ВетИС вес, рассчитанный на основе брутто, вы получите постоянные расхождения объемов сырья и готовой продукции. Рассмотрим, как решить эту проблему:

В конфигурациях на платформе 1С v8.3 необходимо использовать механизм индивидуальных упаковок. В карточке номенклатуры базовой единицей измерения назначается «шт» (штука). Вес нетто (чистый вес продукта) фиксируется в поле Вес (нетто) карточки номенклатуры или в реквизитах сопоставления ВетИС. Для целей логистики и расчета грузоподъемности машин создаются упаковки (например, «Коробка 12 шт»), для которых задается собственный вес брутто.

При передаче данных в ВетИС система берет количество в штуках, умножает его на чистый вес нетто единицы товара и получает точный вес в килограммах для эВСД, избегая расхождений с данными заводов-изготовителей.

Запуск тестового контура ВетИС: старт с нуля

Перед запуском обмена в продуктивной базе крайне важно провести сквозное тестирование процессов в тестовом контуре (TQS). Разберем, как запустить тестовую цепочку с нуля, если в тестовой базе отсутствуют входящие остатки подконтрольных товаров.

Чтобы смоделировать отгрузку, нам сначала необходимо сформировать остатки на виртуальном складе в «Меркурии». Для этого мы должны использовать документ Инвентаризация продукции ВЕТИС. Посмотрим на пример программного создания и заполнения такого документа:


// Создание документа инвентаризации для ввода стартовых остатков в тестовом контуре
ДокументИнвентаризация = Документы.ИнвентаризацияПродукцииВЕТИС.СоздатьДокумент();
ДокументИнвентаризация.Дата = ТекущаяДата();
ДокументИнвентаризация.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7700000000");
ДокументИнвентаризация.ХозяйствующийСубъект = Справочники.ХозяйствующиеСубъектыВЕТИС.НайтиПоНаименованию("Тестовый Дистрибьютор");
ДокументИнвентаризация.Предприятие = Справочники.ПредприятияВЕТИС.НайтиПоНаименованию("Склад №1 Тест");

// Заполнение строки выявляемой продукции (остатка)
НоваяСтрока = ДокументИнвентаризация.Товары.Добавить();
НоваяСтрока.Номенклатура = Справочники.Номенклатура.НайтиПоРеквизиту("Код", "00-000012"); // Например, Сыр
НоваяСтрока.ЕдиницаИзмерения = НоваяСтрока.Номенклатура.ЕдиницаИзмерения;
НоваяСтрока.Количество = 10; // 10 головок сыра
НоваяСтрока.Вес = 45.5; // общий вес нетто в кг
НоваяСтрока.ДатаВыработки = ТекущаяДата() - 172800; // дата выработки 2 дня назад

// Запись и проведение документа для отправки в тестовый шлюз ВетИС.API
ДокументИнвентаризация.Записать(РежимЗаписиДокумента.Проведение);

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

Борьба с системными ошибками: обход ошибки APLM0012

При работе через интеграционный шлюз ВетИС.API в периоды пиковых нагрузок (обычно это утренние часы сборки и ночные отгрузки) пользователи регулярно сталкиваются с ошибкой:
APLM0012: An unexpected error has occurred while invoking target service operation.

Проанализируем причину этой ошибки. Она была введена разработчиками ВетИС как инструмент «выравнивания нагрузки» (load shedding). Когда очередь входящих запросов к серверам превышает критический порог, шлюз начинает принудительно отклонять часть транзакций с кодом APLM0012, защищая систему от полного падения.

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


// Функция отправки транзакции в ВетИС с обработкой перегрузки шлюза
Функция ОтправитьЗапросСПовторомВетИС(Операция, ПараметрыЗапроса) Экспорт
    МаксимальноеЧислоПопыток = 8;
    ИнтервалПаузы = 2; // Начальная задержка в секундах
    
    Для НомерПопытки = 1 По МаксимальноеЧислоПопыток Цикл
        Попытка
            // Вызов стандартного метода отправки пакета в API ВетИС
            РезультатОбмена = ИнтеграцияВетИСПередачаДанных.ВыполнитьЗапросШлюза(Операция, ПараметрыЗапроса);
            Возврат РезультатОбмена;
        Исключение
            ОписаниеОшибки = КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
            
            // Проверяем, вызвана ли ошибка перегрузкой шлюза (код APLM0012)
            Если Найти(ОписаниеОшибки, "APLM0012") > 0 Тогда
                Если НомерПопытки = МаксимальноеЧислоПопыток Тогда
                    ЗаписатьВЖурналРегистрации("ВетИС.Обмен", УровеньЖурналаРегистрации.Ошибка, , , 
                        "Лимит попыток исчерпан. Ошибка APLM0012: " + ОписаниеОшибки);
                    ВызватьИсключение "Сервер ВетИС временно перегружен. Пожалуйста, повторите отправку документа позже.";
                КонецЕсли;
                
                // Применяем экспоненциальный рост паузы между попытками
                СигналыПериодичности.Ожидать(ИнтервалПаузы);
                ИнтервалПаузы = ИнтервалПаузы * 1.8;
            Иначе
                // Если ошибка критическая и не связана с перегрузкой - прерываем выполнение
                ВызватьИсключение ОписаниеОшибки;
            КонецЕсли;
        КонецПопытки;
    КонецЦикла;
КонецФункции

Применение данного алгоритма в коде регламентных заданий позволяет полностью исключить зависание цепочек обмена из-за кратковременных сбоев серверов госсистемы.

Современные реалии дистрибуции: концепция «Единого окна»

В современных условиях дистрибьюторы сталкиваются с требованиями двойного контроля. Для молочной продукции, сыров и мороженого параллельно действует система маркировки «Честный ЗНАК» (ГИС МТ). Это означает необходимость связывать единичные коды DataMatrix (штучный учет маркировки) с партиями сырья в эВСД «Меркурий» (ветеринарный объемный учет).

Для минимизации трудозатрат персонала на складе необходимо внедрять решения, поддерживающие концепцию «Единого окна». Современные модули интеграции (такие как продукты от Контур, АСП или расширения для 1С:ERP/УТ) позволяют выполнять все операции в рамках единого складского бизнес-процесса:

Такой подход позволяет полностью исключить человеческий фактор, снизить процент пересортицы на складе до сотых долей процента и гарантировать прохождение проверок со стороны Россельхознадзора и ФНС.

← На главную