GTIN-14 и EAN-13: в чём разница и почему в карточке маркетплейса нужны обе формы
Иван Недомолков · Chop etilgan:
GTIN-14 и EAN-13 - это один номер товара в двух записях. Четырнадцатизначная форма отличается от тринадцатизначной только ведущим нулём слева, контрольная цифра у них одна и та же. Для 1С и для человека с коробкой в руках это одно значение. Для Ozon это два разных штрихкода в списке карточки: площадка не склеивает их и недостающую форму сама не достраивает. Если в карточке лежит только 02000000000015, по 2000000000015 с коробки товар не найдётся. Поэтому выгрузка из 1С должна класть обе формы, и проверять это стоит до того, как о пропаже узнает склад.
Что такое GTIN-14 и EAN-13
GTIN (Global Trade Item Number) - глобальный номер товарной позиции. В нашей учётной базе он хранится четырнадцатизначным. На упаковке штучного товара печатают тринадцатизначный EAN-13. Короткая форма получается из длинной, если убрать ноль слева.
Почему контрольная цифра не меняется, видно из формулы. Цифры номера умножаются попеременно на 1 и на 3, сумма дополняется до ближайшего десятка. У длинной формы веса сдвинуты на одну позицию, и ведущий ноль попадает под вес 3. Ноль, умноженный на три, остаётся нулём, сумма та же.
Пример на номере из диапазона внутренней нумерации (префикс 20 не выдаётся ни одному производителю):
// EAN-13, первые 12 знаков с весами 1,3,1,3...:
// 2*1 + 0*3 + ... + 0*1 + 1*3 = 5, дополнение до десятка = 5
EAN13 = "2000000000015";
// GTIN-14, первые 13 знаков с весами 3,1,3,1...:
// 0*3 + 2*1 + ... + 0*1 + 1*3 = 5, контрольная цифра та же
GTIN14 = "02000000000015";Номер с префиксом 20 взят только для арифметики. Для Национального каталога Казахстана внутренние номера с двойкой не годятся, там нужен настоящий GTIN от GS1. Эту сторону мы разбирали отдельно, в статье про код товара НКТ в 1С.
Ozon и Яндекс Маркет: как хранят штрихкод и что делают с одной формой
Данные по прогонам на живом каталоге из УТ 11.5 и по документации площадок.
| Ozon (Seller API) | Яндекс Маркет (Partner API) | |
|---|---|---|
| Где лежит номер | список штрихкодов карточки | список штрихкодов товара |
| Отдельный атрибут под GTIN | нет: среди 66 атрибутов категории такого поля нет, документация велит класть номер в штрихкоды | в разборе не встречался |
| 14-значная форма | хранится отдельным элементом | принимается и хранится |
| Две формы одного номера | два разных элемента, не склеиваются | обе формы лежат в списке после записи |
| Если в карточке одна форма | по второй форме товар не находится | вывод второй формы не проверяли |
| Метод записи | /v1/barcode/add | offer-mappings/update |
| Лимит записи | до 100 штрихкодов в запросе, до 20 запросов в минуту | чтение: до 100 значений в offerIds |
| Как пишет | добавляет | дополняет список, применяет асинхронно, около минуты |
| Как отказывает | текст про диапазон “от 1 до 100”, в том числе на пустой список | код 200, ошибка в поле status, вся порция не применяется |
Одно предупреждение про Яндекс. Тот же offer-mappings/update в поле certificates набор заменяет целиком. Штрихкоды он дополняет, номера документов затирает. Про сертификаты и проверку карточек с 1 октября подробно написано в статье о сертификатах для маркетплейсов из 1С.
Как проверить свои карточки: пять шагов
Шаг 1. Выгрузить штрихкоды с площадки и разложить по формам
Заберите из кабинета список штрихкодов по каждой карточке и сопоставьте с номером из 1С. Каждая карточка попадает в одну из четырёх корзин: обе формы, только 14 знаков, только 13 знаков, ни одной.
Так выглядела наша контрольная выборка из 46 карточек до правки и после:
| Что в карточке | До | После |
|---|---|---|
| обе формы | 19 | 45 |
| только 14 знаков | 26 | 0 |
| только 13 знаков | 0 | 0 |
| ни одной | 1 | 1 |
Товар и карточка были у всех 46, штрихкод виден глазами у 45. Правильно заполненных было 19. Пустая строка “только 13 знаков” подсказывает, куда смотреть: в обмене оказалось два метода под разные площадки, один отправлял длинную форму, второй короткую, и ни один не читал, что уже лежит в карточке. Последняя карточка осталась пустой, потому что у товара нет номера в самой базе, кодом это не лечится.
Шаг 2. Проверить контрольную цифру
Прежде чем что-то дописывать, убедитесь, что номер в базе вообще сходится. Функция ниже принимает строку из 13 или 14 цифр: вес 3 получает цифра, стоящая перед контрольной, дальше веса чередуются влево.
Функция КонтрольнаяЦифраВерна(Код)
Длина = СтрДлина(Код);
Если Длина <> 13 И Длина <> 14 Тогда
Возврат Ложь;
КонецЕсли;
Сумма = 0;
Для Позиция = 1 По Длина - 1 Цикл
Вес = ?((Длина - Позиция) % 2 = 1, 3, 1);
Сумма = Сумма + Число(Сред(Код, Позиция, 1)) * Вес;
КонецЦикла;
Возврат (10 - Сумма % 10) % 10 = Число(Прав(Код, 1));
КонецФункцииНецифровые символы функция не отсекает, поэтому строки с пробелами и буквами уберите до вызова.
Шаг 3. Отрезать только ведущий ноль
Справочник легко испортить правилом “убираем первый знак”. Первый знак GTIN-14 это индикатор уровня упаковки: 0 у штучного товара, от 1 до 8 у короба и паллеты. Контрольная цифра упаковочного номера посчитана вместе с индикатором.
GTIN14 = "12000000000012"; // короб, индикатор 1
Обрезанный = Сред(GTIN14, 2); // "2000000000012"
// по формуле EAN-13 здесь должна быть 5, стоит 2: номер битыйКороткую форму получаем только из номера, который начинается с нуля:
Если СтрДлина(GTIN14) = 14 И Лев(GTIN14, 1) = "0" Тогда
Штрихкоды.Добавить(Сред(GTIN14, 2));
КонецЕсли;Примет ли Ozon номер с несошедшейся контрольной цифрой, мы не проверяли. Битые номера на живой каталог не заливали.
Шаг 4. Переписать выгрузку из УТ 11.5 на добавление
В УТ 11.5.22.67 интеграция с маркетплейсами есть, но в перечислении ВидыОбъектовМаркетплейсов вида “Штрихкод” нет, номер уходит внутри вида “Товар”. Сколько форм класть в карточку, типовая не решает, это остаётся на доработке.
Правка выгрузки держится на трёх вещах:
- номер добавляется элементом списка: сначала читаем, что в карточке уже есть, отправляем недостающее;
- из 14-значного номера с ведущим нулём получаются два значения;
- пачка считается в штрихкодах. Лимит Ozon 100 штрихкодов на запрос, и пока шла одна форма, сто пар “товар - номер” в него укладывались. С двумя формами пачка вдвое меньше:
// каждая пара товар-номер даёт два штрихкода
Если Пачка.Количество() >= 50 Тогда
Порции.Добавить(Пачка);
Пачка = Новый Массив;
КонецЕсли;Если обмен писался давно, проверьте и обратное. У нас был метод под Яндекс, который срезал ведущий ноль перед отправкой в убеждении, что площадка берёт только 13 знаков. Прогон показал, что Яндекс Маркет принимает и хранит 14-значную форму, так что метод годами оставлял карточке одну форму из двух.
Шаг 5. Проверить, что запись дошла
У Ozon отказ /v1/barcode/add про “от 1 до 100” приходит и на пустой список. У нас тело уходило строкой вместо структуры, и площадка видела ноль элементов. При вызове через КоннекторHTTP.Post смотрите ключ в дополнительных параметрах:
Доп = Новый Структура;
Доп.Вставить("Json", ТелоЗапроса); // структура уйдёт как JSON
// Доп.Вставить("Строка", ТелоЗапроса); // Ozon получит пустой список
Ответ = КоннекторHTTP.Post(URL, , Доп);У Яндекс Маркета код 200 говорит лишь о том, что запрос доехал. Результат лежит в поле status тела ответа, и при ошибке не применяется вся порция. Журнал обмена, который проверяет код ответа, будет зелёным всегда. Список штрихкодов перечитывайте не сразу: запись асинхронная, сразу после неё чтение отдаёт старый список, примерно через минуту новый.
Первую массовую запись пробуйте на товаре, где в поле уже что-то есть. На пустом товаре и дополнение, и замена выглядят одинаково успешными.
Что показал регламент после правки
Разовая дозаливка чинит данные, новые карточки получают обе формы только из исправленных методов. После правки первая же ночь подняла долю связанных карточек Ozon в очереди с 0,03 до 0,7, в 23 раза. За ночь связано 1 647 карточек. Вся работа по всем кабинетам заняла около 7 250 операций записи, отказов площадки, дошедших до счётчика, ноль.
При этом часть очереди регламент не обработал и в журнал не записал ни одной ошибки. Лимит 20 запросов в минуту это не объясняет: 1 647 карточек при пачке в 100 штрихкодов дают 17 запросов, меньше минуты работы. Настоящую причину мы не нашли, журнал прогона не держал такой детализации. Если ваш регламент тоже заканчивается “без ошибок”, сверяйте число обработанных объектов с размером очереди.
Если хотите, чтобы обмен с Ozon и Яндекс Маркетом проверили и довели до двух форм без ручной дозаливки, это наша интеграция 1С с маркетплейсами. Документы к тем же карточкам грузят обработки сертификатов для Ozon и для Яндекс Маркета.
Что будет в 1С, когда обе формы лежат у одной номенклатуры
Площадка обе формы не требует и пишет, что примет товар с любым действующим штрихкодом. Держать обе мы решили сами, чтобы товар находился по любому номеру. Это осознанное дублирование, и у него есть обратная сторона на стороне учёта. Поиск на ТСД найдёт товар по любой форме. А отчёт о продажах, в котором площадка присылает 13 знаков, пока ключом в базе служат 14, не начнёт ли двоить строки при сверке? И что делать, если 13-значная форма одного товара в справочнике штрихкодов уже закреплена за другой номенклатурой?
