Если вы, как и я, в декабре и январе занимались маркировкой остатков текстиля, подпадающего под «Честный Знак», исползуя для этого любую типовую конфиругацию 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.
Я курю тему маркировки всего месяц. В виду крайне сжатых сроков, многое постигал методом "научного тыка", и мог пропустить какие-то важные регламенты, инструкции и прочие мануалы. Буду признателен сообществу, если меня в них ткнут носом. Может быть я вообще что-то неправильно понимаю, и никакой проблемы и нет вовсе?
