← На главную

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

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

Почему продукция в Меркурии «удаляется» и как устроена версионность ВетИС

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

1. Тип продукции (например, «Мясо и мясопродукты»).
2. Продукция (например, «Свинина»).
3. Вид продукции (например, «Свинина охлажденная» или «Свинина замороженная»).
4. Конкретное наименование продукции (номенклатурный четвертый уровень, создаваемый самим производителем или поставщиком).

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

В этот момент и возникает конфликт между Меркурием и 1С, завязанный на разнице между идентификаторами:

• GUID (Глобальный идентификатор) — уникальный код конкретной карточки товара (ее сущности в реестре).
• UUID (Идентификатор версии записи) — код конкретной версии карточки. Любое изменение в карточке товара на стороне поставщика (например, исправление опечатки в названии или ГОСТе) порождает новый UUID, при этом GUID остается прежним.

Когда карточка аннулируется, ей присваивается статус «400» (удалена/архивирована). Это означает запрет на создание новых партий с этим идентификатором. Но старые партии, выпущенные ранее, продолжают легально существовать в обороте и числятся на остатках в складских журналах получателей именно под этой «удаленной» версией. 1С:КА 2.4 при попытке выполнить операции с такой продукцией через API часто блокирует транзакции, так как запрашивает устаревший UUID или GUID, который шлюз ВетИС считает неактуальным.

Рассмотрим по шагам, как исправить эту ситуацию в 1С.

Шаг 1. Корректировка сопоставления номенклатуры в 1С

Если поставщик создал новую карточку взамен удаленной, нам необходимо разорвать старую связь в нашей базе 1С и сопоставить нашу позицию справочника Номенклатура с новым актуальным GUID Меркурия. В противном случае система продолжит автоматически подтягивать неактивную карточку.

Проанализируем процесс настройки сопоставления:

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

Важный практический совет: во избежание подобных проблем в будущем, при настройке интеграции и сопоставлении элементов рекомендуется привязывать внутреннюю номенклатуру 1С именно к GUID продукции (к самой карточке), а не к конкретному UUID (версии записи). Это позволит системе безболезненно переживать мелкие правки реквизитов товара поставщиком.

Шаг 2. Перенос остатков со старого GUID на новый в 1С

Простое пересопоставление карточек решит проблему с будущими поставками, но не уберет зависшие остатки старой продукции из нашего складского журнала Меркурия. Чтобы легально перенести объемы со старого (удаленного) GUID на новый актуальный, воспользуемся механизмом инвентаризации.

Выполним следующие действия в 1С:КА 2.4:

1. Перейдем в раздел документов ВЕТИС и создадим новый документ ИнвентаризацияПродукцииВЕТИС.
2. На вкладке «Товары» нам необходимо отразить две разнонаправленные операции.
3. Для старой (удаленной) позиции: добавляем строку, выбираем запись складского журнала с удаленной продукцией, устанавливаем операцию «Удаление» (или «Изменение», обнулив объем до 0). В поле «Причина» обязательно указываем основание, например: «Списание в связи с изменением карточки продукции производителем / реорганизацией справочника РСХН».
4. Для новой (актуальной) позиции: добавляем вторую строку с операцией «Добавление» (оприходование). Выбираем сопоставленный новый GUID продукции ВетИС, указываем точное количество переносимого объема, а также переносим все качественные характеристики партии: даты выработки, сроки годности и номера ветеринарных документов (если применимо), чтобы не разорвать цепочку прослеживаемости.
5. Проводим документ ИнвентаризацияПродукцииВЕТИС и отправляем запрос в систему Меркурий через кнопку «Выполнить обмен».

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

Шаг 3. Обход блокировок ВетИС.API через веб-интерфейс

Иногда при попытке провести инвентаризацию для списания удаленной продукции через API 1С возвращается жесткая ошибка протокола обмена (например, MERC02023 или MERC02009), так как шлюз считает транзакции со ссылкой на неактивный GUID недопустимыми. В этом случае мы можем применить обходной алгоритм через веб-интерфейс «Меркурий.ХС».

Разберем этот сценарий подробно:

1. Откроем любой интернет-браузер и авторизуемся в личном кабинете веб-интерфейса «Меркурий.ХС» нашего предприятия.
2. Перейдем в раздел «Инвентаризация» и инициируем создание новой заявки на инвентаризацию непосредственно на сервере ГИС. Веб-интерфейс Меркурия гораздо лояльнее относится к ручным операциям с архивными карточками, нежели программный интерфейс API.
3. Вручную добавим операцию списания остатка с неактивной записи складского журнала и операцию оприходования аналогичного объема на новую действующую запись продукции.
4. Подтвердим и проведем инвентаризацию непосредственно на сайте.
5. Вернемся в программу 1С:Комплексная автоматизация 2.4. В панели обмена с ВЕТИС запустим команду «Запрос остатков» или «Загрузка документов ВЕТИС» за соответствующий период.
6. После загрузки актуального состояния складского журнала из системы Меркурий, 1С зафиксирует корректные остатки на новой сопоставленной номенклатуре, а старые записи журнала закроются.

Важные ограничения: почему нельзя использовать объединение записей

Ранее многие специалисты для решения проблемы дублей и зависших позиций использовали механизм объединения записей складского журнала в 1С (функция ОбъединениеЗаписейСкладскогоЖурнала). Обратим ваше внимание на то, что сейчас этот способ не сработает.

Россельхознадзор существенно ужесточил контролирующие алгоритмы на стороне сервера ВетИС. В настоящее время действуют жесткие ограничения на слияние записей:

• Нельзя объединять записи, если хотя бы одна из них ссылается на недействительный (удаленный) GUID/UUID.
• Нельзя объединять позиции с незаполненными или различающимися датами выработки, сроками годности, а также при наличии расхождений в ветеринарно-санитарных экспертизах.

Поэтому единственным технически верным и стабильным решением остается проведение операции инвентаризации (списание «минусом» старой записи и оприходование «плюсом» новой) по описанной выше методике.

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