Маркировка: как не надо печатать этикетки SSCC

Если вы, как и я, в декабре и январе занимались маркировкой остатков текстиля, подпадающего под «Честный Знак», исползуя для этого любую типовую конфиругацию 1с, проверьте один важный момент. Наверняка вы печатали не только марки на единицу изделия, но и штрихкод логистической упаковки, так называемый КИТУ (Коды Идентификации Транспортной Упаковки), в терминах GS1 (бывшей EAN) они называются SSCC (Serial Shipping Container Code - серийный номер транспортного контейнера). Просканируйте любую из них, и посмотрите, какие символы вернет сканер. Видите что-то вроде (00)146012345600123453 (со скобками) — поздравляю, у вас проблема.                   

Что в типовом?                                      

Пользователям 1с, как я считал, очень повезло — эксперимент уже несколько лет идет полным ходом, сотни компаний уже обкатали это до нас, нам достаточно просто обновить конфигурацию. С первым клиентом мы провели тест — отправили УПД, они проверили марки, все хорошо, УПД отклонили. С чистой совестью мы физически отправили первую партию товара.

Логика работы в типовых конфигурациях 1с, поддерживающих маркировку следующая:

1. эмиссия марок (получаем от ЧЗ или сами генерируем серийные номера каждой единицы товара)

2. виртуальная агрегация (генерируются коды SSCC коробов, сохраняются, определяется состав каждого конкретного короба, распечатываются этикетки на штучки и короба, но данные в ЧЗ пока не передаются — они остаются в 1с)

3. марки вводятся в оборот (поштучно, не упаковками)

4. введенные в оборот марки агрегируются, согласно п.2, т. е. данные виртуальной агрегации передаются в ЧЗ.

5. при отгрузке формируются паллеты, под каждый паллет генерируется еще один упаковочный код (SSCC-паллета, включающий в себя перечень SSCC-коробов), проводится агрегация

6. выполняется отгрузка, клиенту передается электронный документ (УПД через ЭДО, либо непосредственно через ЧЗ), содержащий перечень передаваемых SSCC.

7. покупатель сканирует коды SSCC (паллет или коробок), и подтверждает, что именно эти коды он и получил.

Разумеется, это не единственный возможный вариант цепочки. Можно вообще не использовать агрегацию, и в УПД передавать весь перечень марок. Можно агрегировать заранее, и в оборот вводить уже упаковки (мы так и делаем, но для этого пришлось дорабатывать конфигурацию, из коробки она так не умеет). Но давайте вернемся к нашему кейсу. Как оказалось, в п.2 компания 1с подложила нам свинью. Выяснили мы это только на п.7.

Проблема                   

Беда пришла откуда не ждали. Клиент получил УПД, проверил переданные КИТУ, выгрузил их на ТСД, с помощью которого должна пройти приемка. Однако, сканируя непосредственно ШК, он не находил такого кода в списке ожидаемых.

Чтобы понять, как это получилось, давайте обратимся к инструкции GS1 по формированию SSCC. Сам формат описан, например здесь. Обратите внимание на идентификатор применения — он помещается в скобочки. Вот только если просканировать сам штрихкод, то никаких скобочек в нем нет (хотя словарь code-128 на основе которого реализован GS1-128 стандарт для SSCC позволяет зашивать в ШК символы скобок).

Возьмем методичку непосредственно от GS1ru, там есть пример самого баркода, как может выглядеть SSCC. Попробуем сгенероировать точно такой же с помощью типовой актуальной КА 2.4.13.103.

Для примера, возьмем штрихкод из методички: (00)146012345600123453                          

Для проверки, сгенерируем штрихкод сами, с помощью онлайн-сервисов, например вот этого.

Создадим макет логистической этикетки. Тип штрихкода GS1-128, отдельного типа для SSCC при создании макета не предлагается:

Сравним с тем, что выдает на печать 1с и то, что показано в методичке:

Как видно, 1с формирует совершенно другой узор.                 

Первая причина элементарна: 1с выводит ШК как есть, вместе со скобками. Это можно проверить, считав ШК любым сканером, хоть приложением с мобильного телефона.           

Это неверно. В методических рекомендациях GS1 прямо сказано:

7.4 Представление скобок в символе штрихового кода GS1-128

Скобки, содержащие идентификатор применения, не подлежат представлению в символах штрихового кода символики GS1-128. Их используют только в тексте представления для визуального чтения под символом штрихового кода для различения отдельных элементов данных. Программное обеспечение символики GS1-128 распознает различную информацию на основе типового формата идентификатора применения.

Наши партнеры, не пользующиеся продуктами 1с, сами реализовавшие механизмы работы с маркировкой, в том числе работы SSCC, не ожидают от нас штрихкода с зашитыми скобками, и не могут сопоставить его с КИТУ, пришедшими им в электронной УПД.

Я экспериментировал с выводом на печать различных вариантов идентификатора применения, но так и не добился точного сходства штрихкода с эталонным. Тем не менее, для себя, я пока переделал печать ШК таким образом, чтобы идентификатор применения зашивался в штрихкод без скобок. Вы можете скачать расширение, с помощью которого я этого добился. При чтении этикетки SSCC любым сканером, вы получите 20-ти символьную строку, которую можно сопоставить с корректным КИТУ, однако это будет не совсем SSCC-код.

Вторая причина в том, что SSCC штрихкод формируется немного иначе. Идентификатор применения 1с просто вставляет как часть штрихкода, но по стандарту это не так. Идентификатор применения помещается в специальный раздел FNC1:

Начальная комбинация двух знаков (знак СТАРТ + FNC1) во всем мире зарезервирована для прикладного применения системы GS1. Она позволяет отличить символы штрихового кода GS1-128 от иных не соответствующих этой символике символов штрихового кода.

Если поковыряться в коде 1с, то под «gs1-128» на самом деле имеется в виду EAN-128. Тип данных «2» в компоненте печати ШК. Вероятно, переименовывать, или делать отдельно gs1-128 или SSCC просто не стали. Очевидно, что алгоритм формирования узора штрихкода несколько иной, чем в генераторах, поддерживающих «настояший SSCC». Возможно мое конкретное предположение об использовании FNC1 и не корректно, возможно компонента по-умолчанию сама добавляет этот символ — но тогда не понятно, как заставить ее сгенерировать эталонный узор штрихкода. Пока для меня эта задача не решаема, а значит, либо «под капотом» что-то не то, либо обертка в БСП работает не совсем корректно.

Что делать?

1. С каждым клиентом, проводите предварительный тест. Одним из пунктов чек-листа должно быть сканирование образца этикетки КИТУ. Вполне может быть, что они уже подстроились, и умеют читать такие «нестандартные» варианты формирования картинки штрихкода.

2. Если штрихкод не читается, пробуйте решить проблему на стороне приемки. Если есть возможность выгрузить на ТСД несколько возможных вариантов написания КИТУ — лучше сделать так, и больше не вспоминать об этой проблеме.

3. Уточнить, готовы ли клиенты получить КИТУ в формате EAN-128, с идентификаторами применения зашитыми прямо в сам штрихкод, но без скобок. Если так — можно накатить приложенный патч (сделан в виде расширения). Это чуть менее неправильно, и для некоторых клиентов может решить проблему.

При отгрузке формируйте паллеты, агреггируйте короба в паллеты и передавайте в УПД КИТУ паллет. Напечатать новые упаковочные коды на паллеты несколько проще чем заново печатать SSCC коробов, и попытаться не перепутать, на какую именно коробку их наклеить.

Есть пара сложностей:

а. для этого нужно генерировать новые упаковки / паллеты, и фиксировать их состав. В типовой 1с это более-менее нормально работает только на этапе эмиссии марок, когда генерируется вся структура упаковок. Нормального интерфейса, как генерировать паллетные упаковки, я не нашел.

Фактически, для этого нужно создать элемент справочника «Штрихкоды упаковок», и заполнить его табличную часть «вложенные штрихкоды». Туда нужно положить упаковки. При этом, не забудьте, что после изменения состава упаковки, нужно пересчитать ее хэш.

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

Выход — формировать csv, и загружать его на портале Честного Знака руками. Благо формат не сложный.

в. Нужно подобрать вновь созданные штрихкоды в реализацию, и отправить их в Честный Знак. Печать этикеток в этом случае не должна вызвать больших сложностей. Перечень штрихкодов для этих целей хранится в табличной части накладной "ШтрихкодыУпаковок"

Disclamer. Если покупатель будет вскрывать паллеты, и пытаться продавать кому-то далее коробами — он поимеет ту же проблему что и вы. Единственный приемлемый вариант, когда так можно сделать — если вы продаете эти короба в сеть, которая будет продавать товар только в розницу (причем от одного юрлица). В общем, проговаривайте с партнерами ситуацию.

4. И если совсем уже ничего не помогает — перепечатывать и переклеивать упаковочные коды. Тут есть две опции:

4.1 оставить КИТУ неизменными. Нужно будет обновить наклейки, но главное не перепутать. Технически, можно попробовать сварганить обработку, которая будет взаимодействовать со сканером/ТСД: считал код — сгенерировал корректный код (без скобок) - распечатал новый — наклеил туда же где считал.

4.2 проводить агрегацию «с нуля»: сгенерировал упаковочный код - просканировал N штучек, - просканировал КИТУ, зафиксировав этим самым состав этой коробки.

p.s.

Я курю тему маркировки всего месяц. В виду крайне сжатых сроков, многое постигал методом "научного тыка", и мог пропустить какие-то важные регламенты, инструкции и прочие мануалы. Буду признателен сообществу, если меня в них ткнут носом. Может быть я вообще что-то неправильно понимаю, и никакой проблемы и нет вовсе?