Двадцать тысяч рублей за одну упаковку. Столько с 1 сентября 2026 года стоит продать товар, код маркировки которого числится в Честном Знаке выведенным из оборота. И начисляют этот штраф теперь без выездной проверки, по данным ГИС МТ: система видит расхождение и выставляет постановление в личный кабинет.
Неприятность в том, что склад об этом коде ничего плохого не думает. Он лежит на остатке, кассир пробивает его как обычный товар, документ проводится. А в Честном Знаке этот же код уже месяц как выбыл: его списал другой документ, который в базу не попал, или он ушёл возвратом, который провели задним числом и забыли. Между тем, что лежит на складе в 1С, и тем, что числится за вами в ГИС МТ, набегает разница, и растёт она молча.
Эта статья про то, где в учётной системе на самом деле живёт код маркировки, почему остаток по нему приходится вычислять руками, и как свести список из Честного Знака с тем, что реально лежит на складе. В конце скажу, чем я это считал.
Что изменилось 1 сентября 2026 года
До этого лета за нарушения с маркировкой штрафовали по классической схеме: приходит проверка, смотрит, составляет протокол. Редко и точечно. Федеральный закон от 2 мая 2026 года поменял механику: теперь оператор ГИС МТ сам сопоставляет данные и передаёт сведения о нарушении, а штраф выставляется по факту расхождения в системе. Продали единицу товара с кодом, который в обороте не значится, и система это увидела? Постановление придёт само.
Это переносит вес с "вдруг проверят" на "видно всегда". Раньше проблемный код на остатке был спящей миной, которая могла и не сработать. Теперь она на виду у системы постоянно, и вопрос только в том, когда вы продадите то, что продавать нельзя.
Маркировка тут не одна такая. Государство переводит на автоматическую сверку по своим реестрам всю розницу разом: тем же курсом идёт закон о платформенной экономике, где сертификат соответствия становится частью карточки товара на маркетплейсе и проверяется без участия человека. Логика одна: данные в учётной системе продавца должны совпадать с тем, что о нём знает государственный реестр. Коды маркировки просто первыми дошли до автоматического штрафа.
Практический вывод простой: узнать про такие коды надо до того, как их пробьёт касса, и точно до того, как придёт штраф.
Типовая проверяет код в тот момент, когда его трогают
Первое, что приходит в голову: наверняка типовая 1С это уже умеет. И да, и нет.
Типовая проверяет код разрешительного режима в момент операции: при пробитии чека касса спрашивает у системы, можно ли продавать эту единицу, и результат складывает в регистр проверок. При приёмке сверяет коды по электронному документу. Всё это работает, когда с кодом что-то делают: продают, принимают, списывают.
Слепое пятно ровно там, где кода никто не трогает. Лежит упаковка на дальней полке полгода. Никто её не продаёт, не перемещает, не списывает. Касса про неё не спрашивает, потому что её не пробивают. А в Честном Знаке за это время код мог выбыть, сменить владельца или у него истёк срок. Типовая узнает об этом только в ту секунду, когда товар наконец возьмут в руки и попробуют продать. То есть ровно тогда, когда уже поздно.
Контроль в момент операции и контроль остатка это разные задачи. Первую типовая закрывает, вторую нет.
Остатка по коду в базе просто нет
Тут начинается самое интересное. Казалось бы, чтобы посчитать, какие коды сейчас на складе, нужно открыть регистр остатков по кодам маркировки и прочитать его. Такого регистра в конфигурации нет.
Я перебрал все регистры накопления в типовой Управлении торговлей и не нашёл ни одного с измерением по коду маркировки. Остатки товаров есть, партии есть, серии есть, а по конкретной упаковке с её кодом остатка не ведётся. Код живёт в справочнике штрихкодов упаковок и привязан к документам через табличную часть. То есть код это не то, по чему считают остаток, а то, что прикрепили к строке документа.
Из этого следует неприятная вещь. Чтобы узнать, лежит ли конкретный код на складе сейчас, надо пройти все документы, которые этот код двигали, разложить их по времени и посмотреть, каким было последнее движение. Пришло приходом и с тех пор ничего? Значит, на остатке. Ушло реализацией? Значит, нет. Никакой запрос к регистру этого не даёт, потому что регистра нет. Остаток по коду приходится собирать движением документов, и это и есть то новое знание, которого ни один типовой отчёт не выдаёт готовым.
Практический вывод: если кто-то обещает "остаток кодов маркировки одним запросом", спросите, откуда он его берёт. Штатно взять его неоткуда.
Отчёт "Список КИ на балансе" не сравнивает ничего
Есть в типовой документ, который тянет из Честного Знака список кодов на балансе участника. Выглядит как решение: вот же он, список из ГИС МТ прямо в 1С. Я прочитал, как он устроен, и оказалось, что он забирает данные из системы, раскладывает их в таблицу и на этом останавливается. С остатком 1С он не сопоставляет ничего. Это выгрузка, а не сверка.
Разница принципиальная. Список из Честного Знака отвечает на вопрос "что числится за мной у оператора". Остаток по документам отвечает на вопрос "что реально лежит у меня на складе". Проблема живёт между этими двумя ответами, а типовая их рядом не кладёт. Каждый список сам по себе есть, а вычитания одного из другого нет.
Что на самом деле отдаёт True API
Раз готового ответа нет, список кодов из Честного Знака придётся забирать самому, через True API. И тут ждёт несколько сюрпризов, на которых спотыкаются почти все, кто это делал.
Список кодов владельца отдаёт метод cises/search. Фильтровать выдачу по статусу через поле status бесполезно: сервис его молча игнорирует. Работает только массив states с явным перечислением состояний. Пагинация тоже не такая, как ждёшь: параметры limit, page и offset игнорируются, листать надо курсором по дате эмиссии и коду последней записи предыдущей страницы. Счётчика "всего найдено" в ответе нет вовсе, поэтому заранее не узнать, сколько страниц придётся забрать.
Именно на пагинации ломаются готовые обработки с полки. Под их карточками один и тот же крик из комментариев: "превышен максимально допустимый результат 10000" и "превышен лимит попыток". Первое это попытка забрать большой список без курсора, упираясь в потолок метода. Второе это отсутствие пауз между запросами: сервис отвечает отказом на слишком частые обращения, и без выдержки прогон захлёбывается на первой же тысяче кодов.
Практический вывод: список из Честного Знака берётся курсором, страницами, с паузой между запросами. Без этого он берётся только на маленькой базе, а на настоящей рассыпается.
Три гипотезы, которые не подтвердились
Пока разбирался с API, три очевидных пути завели в тупик. Пишу их, потому что каждый выглядит правильным, и на проверку каждого уходит время.
Первая. Есть метод warehouse/balance, буквально "остаток склада". Название обещает ровно то, что нужно. Я его вызвал, он ответил успехом и пустым массивом. Оказалось, это остаток склада на стороне самой ГИС МТ, к остатку в 1С отношения не имеющий. Для сверки не годится совсем, хотя выглядит главным кандидатом.
Вторая. Товарную группу для запроса типовая хранит числовым кодом. Я подставил этот код и получил отказ: текущий участник не принадлежит выбранной товарной группе. Список групп, по которым можно спрашивать, берётся из тела токена авторизации, справочник видов продукции тут ни при чём. Берёшь оттуда, именами, и всё встаёт на место.
Третья дороже двух первых, и она из области отладки, документация тут ни при чём. Ключ сессии, переданный сервису структурой вместо строки даёт ошибку "токен не действителен". Ровно тот же текст приходит на протухший ключ. То есть по сообщению не отличить, у тебя ключ испортился или ты его неправильно упаковал. На выяснение этого ушло два прогона, и обиднее всего, что виноват тот, кто сделал одинаковый текст ошибки на две разные причины.
Семнадцать тысяч кодов за минуту, ни одного отказа
Когда пагинация и паузы встали на место, полный список кодов участника на тестовом стенде забрался за минуту с небольшим: около семнадцати тысяч кодов, два десятка страниц, ни одного отказа по лимиту. Это тот самый порог, на котором чужие обработки пишут "превышен результат": курсор его не замечает, потому что не просит у сервиса больше, чем тот готов отдать за раз.
Скорость тут не самоцель. Смысл в том, что список берётся целиком и повторяемо. Половинчатый список хуже отсутствия списка: по нему сверка покажет несуществующие расхождения, и вы побежите искать проблему там, где её нет.
Четыре способа двум спискам разойтись
Теперь у нас два списка: коды, которые Честный Знак числит за участником, и коды, которые по документам лежат на складе. Разойтись они могут ровно четырьмя способами, и каждый означает свою беду.
Код есть на остатке 1С, но Честный Знак его за вами не числит. Самый тяжёлый случай: по документам товар у вас, а система его не видит. Обычно код выбыл операцией, которая в базу не попала.
Код в обороте у владельца, а в 1С на остатке его нет. Зеркальная ситуация: система считает, что товар у вас, а по документам его уже отгрузили или он вообще не оприходован.
Код и там, и там, но статусы разные. В 1С он на остатке, а в ГИС МТ уже выведен из оборота. Продавать такой нельзя, хотя на складе он числится живым.
Код числится за другим участником. Он у вас на остатке, но владелец в системе чужой. Продать его вы не имеете права.
Три из этих четырёх типов невидимы до инвентаризации, потому что с кодом ничего не делают, и типовая молчит. Расхождение это не ошибка программы, а свойство предметной области: списки ведут два разных механизма, и они неизбежно расходятся. Вопрос не в том, есть ли расхождение, а в том, знаете ли вы про него до продажи.
Чего эти числа не говорят
Честности ради, о границах. Остаток по коду считается по последнему проведённому движению, без разреза по складам. Перемещения между складами и внутренняя пересортица направление кода не меняют: для сверки с Честным Знаком важно, у вас код или нет; на какой он полке, для этого не важно. Для складского учёта этого мало, для аудита достаточно.
Корректировки приобретения и реализации в первой версии направление не меняют тоже, и это честно видно: обработка перечисляет документы, чьё направление она не смогла определить, отдельным списком. Если в вашей базе коды активно ходят корректировками, остаток по ним будет неполным, и вы это увидите сразу, ещё до штрафа.
И главное. Сумма потенциального риска в рублях это оценка по ставкам, а не начисленный штраф. Автоматика ловит не всё, и цифру риска надо читать как повод разобраться, но ещё не как счёт к оплате. Аудит показывает, где смотреть, а решение остаётся за человеком.
Чем я это считал
Всё, что выше, я собрал в одну внешнюю обработку - Первичный аудит маркировки. Она берёт список кодов у владельца в Честном Знаке, считает остаток по коду из документов 1С, сводит два списка и показывает по каждому товару, сколько кодов уже нельзя продать и почему. Токен берёт из типовых настроек обмена, в ГИС МТ ничего не пишет.
Остался вопрос, на который у меня нет однозначного ответа. Остаток по коду я считаю по последнему проведённому движению, и перемещения с пересортицей в расчёт не беру. На складе с активной пересортицей это может врать. Как вы считаете остаток по коду, если у вас коды часто ходят между складами? Любопытно свериться подходами.
Другие наши инструменты
- Первичный аудит маркировки - обработка из этой статьи: какие коды на складе уже нельзя продать.
- Выгрузка товаров в Национальный каталог Казахстана - GTIN и карточка товара под маркировку.
- Сертификаты в Ozon: выгрузка из 1С и проверка готовности - тот же курс на автосверку с госреестрами.
- Чек-ап чистоты базы 1С - сколько займёт уборка и что сломается.
- ИИ-анализ кода 1С - движок находит, модель объясняет и чинит.
Вступайте в нашу телеграмм-группу Инфостарт