← На главную

При внедрении обязательной маркировки товаров многие компании сталкиваются с архитектурным вопросом: как распределить работу с системой «Честный Знак» (ГИС МТ) между несколькими информационными базами. Классическая связка — это 1С:Управление торговлей (или УНФ) для оперативного контура и 1С:Бухгалтерия предприятия для регламентированного учета.

Часто возникает желание настроить прямой обмен с «Честным Знаком» в обеих базах одновременно. Однако специалисты (франчайзи) нередко утверждают, что работать можно только в одной базе. Разберемся подробно, так ли это, какие технические ограничения существуют и как их можно обойти, основываясь на опыте сообщества и технической документации.

Суть проблемы: конфликт авторизации

Рассмотрим ситуацию, когда у нас есть две базы (БП и УТ), и мы хотим подключить обмен с ГИС МТ в обеих, используя одну и ту же электронную подпись (УКЭП) организации.

Главная техническая проблема кроется в механизме авторизации. Когда 1С обращается к серверам «Честного Знака», происходит следующая цепочка действий:

1. Система отправляет запрос на авторизацию с использованием сертификата.
2. Сервер ГИС МТ возвращает токен доступа (session token).
3. 1С сохраняет этот токен и время его действия, чтобы использовать для последующих запросов (проверка статусов, отправка документов).

Если обе базы настроены на один и тот же сертификат, возникает конфликт сессий, который подробно описан участниками обсуждения. Разберем этот механизм.

Когда две базы «стучатся» одновременно:

• База 1 (например, БП) получает токен. Сессия активна.
• База 2 (например, УТ) пытается выполнить обмен. Она отправляет запрос на авторизацию с тем же сертификатом.

Здесь возможны два сценария поведения API «Честного Знака», оба из которых приводят к ошибкам в работе:

Сценарий А (Сброс сессии): Выдача нового токена для Базы 2 делает недействительным токен, выданный Базе 1. В результате, когда в БП запустится следующее фоновое задание, оно получит отказ в доступе («Ошибка 401» или аналогичная), так как токен протух раньше времени.

Сценарий Б (Кэширование unitedToken): Начиная с определенных обновлений протокола (переход с JWT на unitedToken), наблюдается поведение, при котором сервер возвращает тот же самый токен, если он еще валиден. Однако 1С при получении токена рассчитывает время его жизни локально.

Разберем пример из практики:

1. В 10:00 БП запрашивает токен. Сервер выдает токен, действительный 10 часов. БП записывает: «Токен годен до 20:00».
2. В 12:00 УТ запрашивает токен. Сервер видит, что сессия по этому сертификату активна, и отдает тот же самый токен (который был создан в 10:00).
3. УТ получает этот токен и, не зная, когда он был создан реально, прибавляет стандартное время жизни (например, 10 часов). УТ записывает: «Токен годен до 22:00».
4. В 20:01 токен реально протухает на сервере ГИС МТ.
5. В 21:00 УТ пытается сделать запрос, считая, что у нее есть еще час. Сервер возвращает ошибку авторизации.

Это приводит к нестабильной работе обменов, «красным» регламентным заданиям и необходимости постоянно перезапускать сеансы обмена вручную.

Решение проблемы авторизации

Если вам критически необходимо работать в двух базах одновременно, существует проверенное решение, которое позволяет обойти конфликт токенов.

Использование разных сертификатов.

Система маркировки привязывает сессию не к ИНН организации, а конкретно к пользователю (отпечатку сертификата). Чтобы развести потоки данных:

1. В личном кабинете «Честного Знака» добавьте еще одного пользователя (сотрудника).
2. Оформите на него отдельную УКЭП (или используйте МЧД — машиночитаемую доверенность).
3. Настройте 1С:Бухгалтерию на работу с основным сертификатом (например, директора).
4. Настройте 1С:Управление торговлей на работу с сертификатом ответственного сотрудника.

В этом случае каждая база будет получать свой уникальный токен, и они перестанут «выбивать» друг друга из системы.

Проблема ЭДО и захвата документов

Даже если мы решим проблему с токенами, остается более серьезная проблема — работа с Электронным Документооборотом (ЭДО). Маркировка неразрывно связана с ЭДО, так как коды передаются через УПД (Универсальные передаточные документы).

Давайте проанализируем, что произойдет, если настроить получение документов ЭДО в обеих базах под одним профилем:

Когда поставщик отправляет вам УПД с кодами маркировки, этот документ попадает на сервер оператора ЭДО. Далее 1С запускает регламентное задание «Получить новые документы».

• Если первым сработает регламентное задание в УТ, она заберет пакет с сервера оператора, отметит его как полученный и загрузит себе.
• Когда через минуту сработает задание в БП, сервер оператора скажет: «Новых документов нет».

В итоге у вас получится «лоскутная» автоматизация: часть поступлений будет только в УТ, часть — только в БП. Это приведет к хаосу в учете НДС и складских остатков.

Рекомендованная архитектура

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

Вариант 1: Оперативный контур — главный (Рекомендуется)

• Вся работа с маркировкой ведется в УТ (Управление торговлей). Приемка товара, сканирование марок, вывод из оборота при продаже, агрегация — все здесь.
• В УТ настраивается ЭДО для получения УПД.
• В БП (Бухгалтерию) документы передаются через штатную синхронизацию (обмен данными). Марки в БП приходят уже в справочном виде или не приходят вовсе (в зависимости от настроек), так как финансовому учету важны суммы и номенклатура, а не конкретные коды DataMatrix.

Вариант 2: Тестовый запуск

Автор темы упоминал желание «запустить в УТ, но если что-то пойдет не так — вернуть на БП». Для такой схемы:

1. Обязательно отключите регламентные задания по обмену с ГИС МТ и ЭДО в одной из баз (например, в БП), пока тестируете другую (УТ).
2. Не запускайте их параллельно. Если нужно «откатиться», сначала выключите обмен в УТ, убедитесь, что сессия закрыта, и только потом включайте в БП.

Технические нюансы JWT токенов (перспектива)

Важно отметить техническое замечание касательно формата токенов. Ранее использовались классические JWT-токены, в которых зашит срок действия (expiration time). Их можно расшифровать и точно знать, когда токен протухнет.

Сейчас наблюдается переход на так называемые unitedToken (как в СУЗ — Станции Управления Заказами). Особенность их работы в том, что при актуализации токена сервер может возвращать предыдущий полученный токен с непонятным остаточным сроком годности, если запрос происходит в рамках определенного временного окна.

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

Резюме

Отвечая на вопрос автора: франчайзи был прав, предостерегая от одновременной работы, но не совсем точен в деталях.

1. Работать можно, но только при условии использования разных цифровых подписей (сертификатов) для каждой базы.
2. Даже с разными сертификатами, вы столкнетесь с проблемой разделения входящего потока документов ЭДО. Вам придется либо настраивать сложную маршрутизацию у оператора ЭДО, либо вручную контролировать, куда приходят документы.
3. Самый надежный вариант — выбрать одну базу в качестве «Мастер-системы» для маркировки (обычно это УТ/ERP/КА), а во вторую базу (БП) выгружать только финансовый результат через синхронизацию.