← На главную

При организации схемы перепродажи маркированного товара между собственными юридическими лицами внутри одной информационной базы 1С:УНФ 3.0 часто возникает практическая сложность: как в режиме реального времени понимать, за какой именно организацией закреплен конкретный КИЗ. Стандартный регистр сведений ПулКодовМаркировкиСУЗ предназначен главным образом для хранения эмитированных марок и подготовки к их нанесению, при этом измерение Организация в нем отсутствует (оно вынесено в ресурсы), а сам регистр является непериодическим. Попытка вести собственный локальный регистр для перемещения кодов маркировки часто приводит к рассинхронизации учетных данных с государственной системой.

Рассмотрим, почему чисто локальный учет принадлежности кодов не работает, как выстроить надежную архитектуру проверки владельца и какие стандартные механизмы интеграции с ГИС МТ (Честный знак) можно задействовать в 1С:УНФ.

Проблема локального учета и рассинхронизация с Честным знаком

Проанализируем типовой жизненный цикл кода при межфирменной перепродаже через электронный документооборот (ЭДО):

1. Организация-продавец формирует документ Расходная накладная, сканирует или подбирает коды маркировки и отправляет электронный УПД через оператора ЭДО.
2. Организация-покупатель получает входящий УПД, подписывает его и формирует документ Приходная накладная.
3. Оператор ЭДО передает сведения об успешной сделке с кодами маркировки в систему «Честный знак».

Главная ошибка проектирования на данном этапе — смена организации-владельца в локальном регистре 1С в момент проведения документа реализации. Смена владельца КИЗ в ГИС МТ происходит не при проведении накладной в 1С и не в момент отправки УПД, а только после двустороннего подписания документа и успешной регистрации передачи права собственности на серверах маркировки.

Если в учетной системе перезаписать владельца КИЗ сразу, то до момента фактической обработки на стороне Честного знака возникнет разрыв: в 1С товар числится за покупателем, а по данным ГИС МТ им все еще владеет продавец. В результате покупатель не сможет отгрузить товар дальше контрагентам или продать его через розничную кассу — система выдаст блокирующую ошибку о попытке продажи чужого товара.

Архитектурное решение: онлайн-проверка владельца через True API

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

При формировании документов реализации или при проверке партий перед дальнейшей продажей система запрашивает актуальный статус массива КИЗ через вызовы методов интеграции. Проверка пакета из сотен или даже тысячи марок через сервис выполняется за несколько секунд.

В ходе запроса система маркировки возвращает актуальные параметры кода:

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

Где в типовом функционале 1С:УНФ найти механизмы проверки владельца

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

1. Интерактивное рабочее место: обработка ПроверкаКодовМаркировкиИСМП. Она позволяет загрузить список КИЗ (в том числе списком до 1 000 штук за один сеанс) и получить из системы актуальный статус, текущего владельца по ИНН и состояние оборота.
2. Инструмент подбора в накладных: обработка ПроверкаИПодборПродукцииИСМП, встроенная в документы Расходная накладная и Приходная накладная. При сканировании или нажатии кнопки проверки система выполняет фоновый запрос к API и сверяет принадлежность кода с организацией документа.
3. Программный интерфейс: механизмы отправки запросов сосредоточены в общих модулях подсистемы интеграции с ГосИС, в частности ИнтерфейсИСМПВызовСервера и ИнтеграцияИСМПКлиентСервер. Запрос сведений о кодах выполняется к ресурсу True API cises/info.

Возможность проверки владельца КИЗ без ЭЦП

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

Сведения о владельце кода являются защищенными данными. Сервер ГИС МТ не предоставляет их без авторизации. Однако постоянное присутствие токена с ЭЦП на каждом рабочем месте пользователя не требуется:

1. Серверная авторизация: сертификат УКЭП настраивается на стороне сервера 1С. Регламентное задание по расписанию выполняет авторизацию в ГИС МТ с помощью подписи и получает сессионный токен.
2. Использование сессионного токена: полученный токен авторизации действителен до 10 часов. Все клиентские сеансы и фоновые задания учетной системы могут отправлять HTTP-запросы на проверку владельцев кодов без физического подключения ключа ЭЦП к компьютеру пользователя, пока действует текущий сеанс авторизации.

Важное замечание: статический токен доступа, генерируемый в личном кабинете Честного знака для разрешительного режима работы контрольно-кассовой техники, не подходит для оптовых операций — он не возвращает развернутую информацию о смене владельцев по цепочке поставок.

Рекомендованный алгоритм учета КИЗ при внутренних перепродажах

Если для аналитических отчетов внутри базы требуется непрерывно видеть принадлежность марок, реализуем двухфазную схему учета:

1. При проведении документа «Расходная накладная» фиксируем статус КИЗ как «В процессе передачи» или «В пути». Код блокируется для повторных продаж организацией-отправителем, но еще не становится собственностью покупателя.
2. Смену владельца в учетной системе фиксируем только после получения подтверждения от оператора ЭДО о том, что титул покупателя подписан обеими сторонами, а документооборот успешно зарегистрирован в ГИС МТ.
3. При дальнейшей передаче или продаже товара организацией-покупателем обязательно выполняем фоновую пакетную онлайн-валидацию марок через вызов методов cises/info, гарантируя фактическую смену собственника на стороне регулятора.