Содержание статьи
На склад приходит палета: 40 коробов по 24 маркированные единицы — всего 960 кодов. В УПД при поэкземплярном учёте должны оказаться конкретные экземпляры. Кладовщик при этом видит один штрихкод на палете: индивидуальные DataMatrix скрыты под плёнкой и внутри коробов.
Можно вскрыть палету, достать товар, отсканировать 960 кодов и упаковать всё обратно. Но тогда ПЭУ превращается в дорогую ручную перепись — медленную и плохо совместимую с потоком склада.
Рабочий промышленный сценарий устроен иначе. Единичные коды заранее объединяют в зарегистрированную иерархию. Сотрудник сканирует доступный код верхнего уровня, а система раскрывает его до конкретных КМ и переносит их в операцию.
Именно здесь появляются КИГУ, КИТУ, SSCC, а у импортёров — ещё и АТК. Все они помогают работать с множеством кодов, но решают разные задачи и не заменяют друг друга.
Почему упаковки перестали быть частным случаем
В 2026 году поэкземплярный учёт затрагивает ещё 13 товарных групп. По состоянию на конец августа новые требования уже начали действовать для части технических средств реабилитации, ветеринарных препаратов, безалкогольных напитков и пива, а также для отдельных позиций лёгкой промышленности, антисептиков, медицинских изделий, автомобильных жидкостей и икры.

Следующие этапы запланированы на конец года. С 1 ноября изменения коснутся растительных масел, а с 1 декабря — строительных материалов, радиоэлектроники и кормов для животных.
Переход продолжится и в 2027 году. С февраля новые требования начнут действовать для детских игрушек, с марта — для спортивного питания. На сентябрь намечены отдельные медицинские изделия и пиротехника, на октябрь — консервы, на декабрь — первая группа бакалейной продукции.
При этом одной даты недостаточно, чтобы определить обязанности конкретной компании. Внутри товарной группы требования могут зависеть от вида продукции, её кода, даты производства и выполняемой операции. Поэтому календарь перехода нужно сверять с правилами именно своей категории.
Масштаб виден и по обезличенной внутренней выборке пользовательских обращений по маркировке. Около 74% запросов в тематическом массиве пришлись всего на два почти равных направления: примерно 37% — на транспортные упаковки, КИГУ и SSCC, ещё около 37% — на ввод в оборот и агрегацию.
Сложность не в расшифровке аббревиатур, а в границах систем: почему после сканирования палеты на ТСД появились не все бутылки, откуда мобильное приложение получает вложенность, что именно пришло через ЭДО и кто должен исправить состав короба.
ПЭУ — это требование к данным, а не к количеству движений сканером
При объёмно-сортовом учёте в УПД указывают GTIN и количество товара. При поэкземплярном учёте документ должен содержать сведения о конкретных кодах идентификации.
При этом поэкземплярный учёт не означает, что на каждой приёмке нужно заново сканировать все единицы внутри закрытой транспортной упаковки. В официальных материалах «Честного ЗНАКа» указано: в УПД можно передать код каждой единицы, групповой или транспортной упаковки. Если указан агрегированный КИГУ или КИТУ, система учитывает вложенные коды маркировки.
Это и есть практический смысл агрегации: сначала зарегистрировать состав упаковки, а затем работать с её идентификатором, пока фактический состав упаковки соответствует зарегистрированному.
Как верхний код упаковки попадает в УПД
ПЭУ связывает складскую операцию с юридически значимым документом. Электронный УПД может быть двухтитульным: продавец формирует титул с данными об отгрузке и маркированном товаре, покупатель — титул с результатом приёмки. Между этими двумя действиями находится физическая поставка, которую нужно сопоставить с документом.
В одном УПД могут одновременно передаваться сведения о потребительских, групповых и транспортных упаковках. Если передан зарегистрированный код верхнего уровня, дублировать в документе каждый вложенный код не требуется: ГИС МТ раскрывает состав через ранее зарегистрированную агрегацию. Поэтому закрытая палета может войти в поэкземплярный документ одним КИТУ, но за этим КИТУ всё равно стоит определённый набор экземпляров.
Важно не перепутать передачу упаковки с созданием упаковки. УПД не строит иерархию КМ → короб → палета, а использует уже существующую связь. Если палету разобрали, заменили короб и собрали обратно, но цифровую агрегацию не обновили, документ останется формально читаемым, однако будет описывать не тот физический груз.
Типовой процесс отгрузки выглядит так. В системе на базе 1С создают заказ или реализацию с номенклатурой и количеством, но ещё без конкретных кодов. Документ передают на ТСД; сотрудник сканирует фактически отобранные единицы, короба или палеты. После завершения операции результат возвращается в учётную систему уже с КМ и кодами агрегации. Только затем эти сведения попадают в УПД и уходят контрагенту через ЭДО.
Здесь у каждого компонента своя роль. Система на базе 1С хранит задание на отгрузку; сотрудник и ТСД фиксируют фактический отбор; ГИС МТ хранит зарегистрированную вложенность; ЭДО передаёт результат контрагенту. Стоит одному звену заменить факт предположением — и цифровой состав расходится с физическим грузом.

Что именно обозначают КМ, КИГУ, КИТУ, SSCC и АТК
КМ: конкретный экземпляр
Код маркировки идентифицирует конкретную единицу товара. Его состав и формат средства идентификации зависят от правил маркировки соответствующей товарной группы, поэтому универсальной длины или единой структуры DataMatrix для всех категорий нет.
КИГУ: групповая упаковка, которую можно продать потребителю
КИГУ — код идентификации групповой упаковки. «Честный ЗНАК» определяет групповую упаковку как упаковку, объединяющую потребительские упаковки товара и допускающую реализацию конечному потребителю.
На групповую упаковку получают отдельный код маркировки и наносят DataMatrix. Вложенные товары должны быть объединены с КИГУ операцией агрегирования. Конкретные требования к составу групповой упаковки и статусам вложенных кодов следует проверять по правилам своей товарной группы.
КИТУ: идентификатор транспортной упаковки
КИТУ — код идентификации транспортной упаковки. Транспортная упаковка объединяет товары или другие упаковки, не передаётся конечному потребителю и используется для транспортировки и хранения.
Средство идентификации транспортной упаковки участник может сформировать по собственным требованиям, требованиям получателя или по стандарту GS1-128. В качестве КИТУ может использоваться SSCC. После регистрации агрегации система маркировки знает, какие КМ и КИТУ нижнего уровня включены в транспортную упаковку.
КИТУ верхнего уровня может включать КИТУ нижнего уровня. Поэтому короб и палета могут быть двумя разными уровнями одной зарегистрированной иерархии.

Агрегация — это состояние, а не вечная наклейка
Код на коробе или палете имеет смысл только пока физический состав совпадает с зарегистрированной вложенностью. Переклеить этикетку на другую палету недостаточно: идентификатор продолжит ссылаться на прежний состав.
Это особенно важно при частичном отборе. Если из агрегата изъяли короб или отдельную единицу, дальнейшее действие зависит от правил товарной группы и реализованного процесса: упаковку расформировывают, изменяют её состав либо создают новую агрегацию. Продолжать сканировать старый КИТУ как будто ничего не произошло — значит размножать расхождение на следующих операциях.
Поэтому агрегация должна быть встроена в складские события: упаковку создали, изменили, расформировали, приняли или отгрузили. Если она существует только как разовая операция на производственной линии, склад довольно быстро перестаёт доверять верхним кодам и возвращается к поштучному сканированию.
SSCC: стандарт GS1 для логистической единицы
SSCC — 18-значный идентификатор логистической единицы по стандарту GS1. Идентификатор применения для SSCC — AI (00).
Важно различать сам SSCC и строку элемента GS1: SSCC содержит 18 цифр, а строка вместе с двухзначным AI 00 — 20 цифр. Скобки в записи «(00)» используются в человекочитаемом представлении и в штрихкод не кодируются.
SSCC не является отдельным уровнем упаковки рядом с КИТУ. Это стандартизированный идентификатор, который может использоваться в качестве КИТУ.

АТК: код для таможенного декларирования
АТК — агрегированный таможенный код. По определению «Честного ЗНАКа», это уникальная последовательность символов для отдельной совокупности товаров в упаковке. АТК включает коды идентификации товаров и упаковок, содержит 25 символов и генерируется в ГИС МТ.
АТК предназначен для таможенного декларирования товаров как одного товара и указывается в графе 31.13 декларации на товары. Он не заменяет КИТУ в складских операциях после прохождения таможни.
Что происходит после сканирования КИТУ
КИТУ не содержит внутри текстовый перечень всех вложенных DataMatrix. Он идентифицирует транспортную упаковку, состав которой был передан в систему маркировки при агрегировании.
После сканирования прикладная система получает идентификатор упаковки и должна сопоставить его с зарегистрированным составом. Откуда именно мобильное приложение получает эти сведения — из учётной системы на базе 1С, из связанной с ней складской системы, из входящего документа либо через интеграцию с внешней системой — зависит от реализованной архитектуры.
Конкретный пример — «Склад 15». Начиная с версии 2.0 продукт может в онлайн-режиме напрямую запросить в «Честном ЗНАКе» сведения об агрегированной транспортной упаковке, если её штрихкода ещё нет в 1С. Для этого в 1С должны быть настроены сертификат ЭЦП и коннектор к «Честному ЗНАКу». Если упаковка найдена, она добавляется в документ; подробный просмотр её вложений в этом сценарии недоступен.
Универсального JSON, единого метода API или общей для всех конфигураций 1С структуры регистров здесь нет. Публично описанный результат один: после регистрации агрегации по КИТУ можно определить включённые в него КМ и КИТУ нижнего уровня.
Где хранится состав упаковки
ГИС МТ хранит сведения о зарегистрированной агрегации. Состав упаковки может также храниться в учётной системе на базе 1С или связанной с ней складской системе — это зависит от используемого решения и настроенной интеграции. ЭДО передаёт сведения документа между участниками, а ТСД фиксирует результат физической операции.
Поэтому при диагностике нельзя считать ТСД источником состава закрытой палеты. Устройство считывает идентификатор; состав должен быть получен из данных, сформированных до складской операции.
Приёмка: сравнить документ с физическим грузом
На практике приёмку удобно представить как сравнение двух наборов. Первый набор приходит через ЭДО: это КМ и коды упаковок, которые поставщик указал в УПД. Второй формируется на приёмке: сотрудник сканирует то, что действительно приехало. Задача системы — раскрыть агрегаты до нужного уровня и сопоставить результат, а не просто посчитать одинаковые GTIN.
Полное совпадение означает, что документ и фактическая поставка описывают одни и те же экземпляры. Несовпадение может выглядеть по-разному: код есть в УПД, но отсутствует в машине; товар приехал, но его кода нет в документе; вместо ожидаемого короба приехал другой; КИТУ распознан, но его зарегистрированный состав не соответствует ожидаемому набору.
Характерный складской сценарий — две внешне одинаковые коробки для разных получателей поменялись местами при погрузке или доставке. По номенклатуре и количеству всё сходится, поэтому объёмно-сортовая проверка не замечает проблемы. Поэкземплярная сверка обнаруживает, что фактические коды относятся к другой поставке.
Если расхождение найдено до подписания входящего документа, товар можно отделить от нормального потока и урегулировать расхождение с поставщиком до завершения приёмки. Если документ уже подписан, потребуется корректировка данных и документов. Конкретный путь — новый или исправленный УПД, УКД либо иной предусмотренный процесс — зависит от того, изменились коды, количество, стоимость или сама номенклатура.
Критично, чтобы проблемный экземпляр не ушёл дальше в хранение, комплектацию и торговый зал. Иначе ошибка обнаружится уже на кассе или при следующей отгрузке: система может сообщить, что участник не является владельцем кода, код имеет неподходящий статус или отсутствует в ожидаемой поставке.
Поэтому результат мобильной приёмки должен возвращаться в систему на базе 1С не одной отметкой «сканирование завершено», а структурированным результатом: что ожидалось, что найдено, какие упаковки раскрыты, какие коды отсутствуют или оказались лишними и какое решение принято по расхождению. Именно эти данные позволяют корректно завершить ЭДО и не переносить ошибку на следующую операцию.
Почему упаковка может не раскрыться
Ниже не перечень статусов ГИС МТ, а практические направления проверки интеграции:
1. агрегация не была зарегистрирована;
2. отсканированная строка не распознана приложением как КИТУ;
3. упаковку расформировали или изменили её физический состав;
4. в учётную систему не поступили сведения, необходимые для обработки входящего документа;
5. обмен с ЭДО или внешней системой ещё не завершён;
6. на ТСД выгружен уровень упаковок, недостаточный для выполняемой операции;
7. результат сканирования не записался в учётную систему на базе 1С.
Проверку полезно вести по цепочке: считанная строка, распознанный тип кода, найденная упаковка, её зарегистрированный состав, сопоставление с документом и запись результата в учётную систему. Так можно отделить проблему чтения штрихкода от ошибки данных или обмена.
Вместо вывода
Переход на ПЭУ меняет не только формат УПД. Он превращает упаковку в часть модели данных.
КМ отвечает за экземпляр. КИГУ — за групповую упаковку как товар. КИТУ — за транспортный агрегат. SSCC стандартизирует идентификацию логистической единицы. АТК позволяет представить множество кодов в таможенном контуре, но не заменяет складскую агрегацию.
В итоге одно сканирование палеты экономит сотни движений только потому, что за ним уже существует точная цифровая модель груза. Её поддерживают агрегация, синхронные данные в системе на базе 1С, ЭДО и ГИС МТ, а также складской процесс, который фиксирует любое изменение физического состава упаковки.
В следующей статье разберём, кто и на каком этапе формирует КИГУ, КИТУ и АТК, как регистрируется состав упаковок, какие сведения хранятся в ГИС МТ и системах на базе 1С и что в итоге получает ТСД.
