kleverence

На складе нашли товар, которого, если верить учётной системе, у компании не было. Но коробки не прятались в дальнем углу и не лежали там забытыми несколько лет: сотрудники видели товар, брали его с полок и отгружали клиентам. Странности начинались позже, когда фактические остатки пытались сверить с учётными.

Первая версия в таких случаях довольно предсказуемая — где-то неправильно посчитали. Проводят инвентаризацию, исправляют остатки и какое-то время живут спокойно. Но через некоторое время цифры снова расходятся, хотя при последнем пересчёте всё привели в порядок.

И это не экзотическая проблема нескольких неудачно организованных складов. Расхождения могут появиться в любой компании, где каждый день принимают поставки, размещают и перемещают товар, собирают заказы и отгружают их клиентам. Причём ошибка далеко не всегда обнаруживается там же, где возникла — иногда между этими двумя событиями проходят недели.

Всё может начаться с обычной приёмки

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

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

При этом на самом складе ничего подозрительного не происходит. Машину разгрузили, коробки расставили, сотрудники продолжили работу. Поэтому ошибка вполне может остаться незамеченной до того момента, когда товар понадобится для следующей операции.

Особенно «весело» становится с ассортиментом, где недостаточно правильно посчитать коробки. Одежда отличается размерами и цветами, запчасти — артикулами и модификациями, инструмент — характеристиками и комплектацией. По общему количеству всё может сойтись идеально, а нужной позиции в итоге не окажется.

Коробку переставили, а в системе она осталась на старом месте

С приёмкой всё может пройти нормально: товар посчитали, правильно определили и внесли в систему. Но дальше-то коробки перемещаются по складу. Для них освобождают места, уплотняют хранение, перестраивают зоны, переносят ходовой товар ближе к сборке. Иногда коробку нужно просто убрать с прохода и поставить туда, где сейчас свободно.

Если новый адрес нужно отдельно внести в систему, сделать это можно уже через пять минут. Или через час. Или вспомнить об этом только тогда, когда кто-нибудь придёт за коробкой на старое место.

Сначала всё держится на памяти сотрудников. Кладовщик помнит, куда вчера перенёс товар. Коллега видел, что происходило. Если коробка понадобится, кто-нибудь вспомнит, куда же её переставили, и даже ткнёт пальцем в конкретный стеллаж.

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

Формально компания товар не потеряла. Но заказ нужно собирать сейчас, и знание о том, что коробка «где-то точно есть», мало чем помогает.

Когда товар есть, а информации о нём нет

На складах иногда собранные заказы обозначают цветными стикерами. Сотрудники вручную пишут на них информацию о заказе и клеят на коробки. И такая схема даже работает, пока стикер не отклеится.

То есть коробка остаётся на месте, товар — внутри, но экспедитор уже не может быстро определить, кому предназначен заказ. И кладовщики снова движутся по заданному кругу: ищут информацию и сверяют содержимое. Заодно появляется риск отправить клиенту чужую коробку или продукцию с другими сроками годности.

А если на складе миллионы позиций? Там потерянная этикетка может обойтись гораздо дороже. Например, в случае с автозапчастями даже опытный сотрудник не сможет посмотреть на «железку» и безошибочно определить её артикул.

Если этикетка потерялась, а восстановить артикул не удалось, исправная деталь фактически превращается в металлолом. Она принадлежит компании, занимает место на складе и стоит денег, но продать её уже нельзя.

Почему инвентаризация не решает проблему с остатками?

Во время инвентаризации все накопившиеся расхождения видны одновременно. По одной позиции в системе числится 126 единиц, сотрудники находят 121. По другой должно быть 40, а на полке лежат 43. Ещё несколько коробок обнаруживаются не в тех ячейках, а часть расхождений — вообще пересорт.

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

Но сама причина никуда от этого не девается. Если коробку можно переставить сейчас, а новый адрес указать потом, однажды кто-нибудь снова забудет это сделать. Если результаты приёмки сначала записывают на бумаге, а потом вручную переносят в 1С, снова можно пропустить строку или выбрать не ту позицию.

Поэтому через несколько месяцев следующая инвентаризация вполне может показать новые расхождения. Не потому, что предыдущая была проведена плохо, а потому, что пересчёт исправил остатки, но не тот порядок работы, при котором они разошлись.

Между «я сделал» и «я записал» может пройти слишком много времени

На приёмке сотрудник сначала пересчитывает поставку, а потом вносит данные. При перемещении сначала переносит коробку, и только после меняет адрес. При сборке сначала берёт товар, затем отмечает позицию в документе.

Первую часть человек выполнит в любом случае: машина ждёт разгрузки, коробку нужно убрать с прохода, заказ пора собирать. А запись можно сделать через пять минут. За это время приезжает следующая машина, звонит менеджер, водитель приносит документы, коллега просит помочь с разгрузкой. Иногда заканчивается смена.

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

Мобильное приложение на ТСД коннектится с 1С или другой учётной системой. Это нужно как раз для того, чтобы складские операции фиксировались в текущий момент работы с товаром, а сотруднику не приходилось потом отдельно переносить в систему то, что он уже сделал физически.

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

А если остатки уже расходятся?

Необязательно сразу проводить ещё одну инвентаризацию или начинать большой проект автоматизации. Для начала можно взять одно конкретное расхождение и попробовать понять, откуда оно взялось.

Например, на полке лежит пять единиц товара, а в системе числится шесть. Что приехало по документам и сколько приняли фактически? Под тем ли артикулом оприходовали товар? Куда его поставили? Перемещали ли потом? Что собирали и отгружали по заказам?

Если пройти этот путь назад, можно найти операцию, после которой фактическое количество, артикул или местоположение товара перестали совпадать с данными в системе. И уже тогда становится понятно, что именно нужно менять.

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

Где-то проблему действительно решит ТСД. Где-то достаточно поменять порядок работы. А где-то выяснится, что причина вообще в другом процессе.

Главное — не останавливаться на исправлении цифры в остатках. Если просто добавить найденную коробку в систему или списать недостачу, цифры снова сойдутся. Но если не понять, откуда взялось расхождение, через некоторое время на складе появится следующая коробка, которой по документам не существует.

Статья написана на основе интервью с Алексеем Воротягиным, IT-директором компании «ИталТрак».

Однажды нам пришлось искать запчасти для двух сломавшихся грузовиков IVECO сразу на нескольких континентах. Одну нашли в Австралии, другую в Латинской Америке, ещё две — в США, четыре — в Италии. Везли срочно, в том числе чартерными рейсами: сначала до Москвы, потом до Красноярска. Сама «железка» могла стоить около €1000, её доставка — €12 000. И это всё равно имело смысл.

Грузовики работали на золотом прииске. Всего машин было шесть, две вышли из строя, а то время, когда техника простаивала, обходился клиенту намного дороже стоимости запчастей и их доставки. В таких ситуациях вообще перестаёшь смотреть на цену «железки» отдельно: если машина должна работать прямо сейчас, важнее становится то, сколько бизнес потеряет за каждый час или день простоя.

Мы в «ИталТраке» занимаемся запчастями для импортных грузовиков и сельскохозяйственной техники, поэтому такие истории для нас не что-то совсем из ряда вон выходящее. Конечно, чартер через океан нужен далеко не для каждой поставки, но срочные заказы — важная часть нашего бизнеса. Иногда настолько срочные, что, когда нужная деталь приезжает на склад, сотрудники откладывают остальные операции и занимаются только ею.

А на складе у нас при этом ассортимент более двух миллионов товарных позиций.

У нас два миллиона позиций. Узнать нужную деталь в лицо невозможно

С таким ассортиментом невозможно рассчитывать на кладовщика, который посмотрит на железку и скажет: «А, знаю, это такой-то артикул». Нет специалиста, способного взять любую деталь из нашего ассортимента и по внешнему виду точно определить её номер. Запчасти отличаются модификациями, размерами, применяемостью, а справочники номенклатуры у нас исчисляются миллионами позиций.

Поэтому на складе мы пришли к тому, что я называю «100% доверием терминалу». Если ТСД говорит сотруднику идти в определённую ячейку за определённой деталью, он идёт туда и сканирует код. Запомнить расположение такого количества товаров или узнавать их в лицо просто невозможно.

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

А некоторые запчасти приходится ещё и обслуживать, пока они просто лежат и ждут покупателя. Металл нужно защищать от коррозии, резиновые элементы — от пересыхания. Например, клапаны обрабатываются маслом и заворачиваются в плёнку, подшипники хранятся в промасленной парафинированной бумаге. В зависимости от материала консервацию приходится повторять примерно раз в три-шесть месяцев.

Получается, нам недостаточно знать, что деталь есть на складе и лежит в конкретной ячейке. Иногда нужно ещё помнить, когда к ней пора вернуться и снова провести обслуживание.

80% запчастей ещё не приехали на склад, а мы уже знаем, кому они достанутся

У нашего склада есть ещё одна особенность: около 80% поступающих деталей заранее зарезервированы под конкретного клиента. Мы ещё до приезда товара понимаем, кому предназначена запчасть и куда она должна отправиться дальше.

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

А для мегасрочных поставок раньше вообще существовал отдельный приоритет. Если приезжала деталь, которую где-то уже ждёт вставшая техника, сотрудники знали: сейчас всё остальное откладываем и занимаемся этим грузом. Когда запчасть уже прилетела из Латинской Америки через океан, а дальше её нужно успеть отправить в Красноярск, потерять несколько часов на складе — очень дорогая ошибка.

У нас бывали логистические цепочки, рассчитанные практически по времени: машина приезжает, груз нужно обработать, дальше он едет во Внуково, а самолёт вылетает через два часа. И в этот момент вся сложная международная логистика внезапно упирается в очень простой вопрос: где сейчас лежит нужная коробка и точно ли мы понимаем, кому она должна уехать?

В какой-то момент по складу одновременно бегали кладовщики с бумажками и айтишники

Мы довольно быстро росли, поэтому красивой истории в духе «сначала тщательно спроектировали процессы, потом выбрали систему и спокойно её внедрили» у нас не было. Склад уже работал, объёмы увеличивались, машины приезжали каждый день, а автоматизировать всё это приходилось параллельно.

В какой-то момент доходило буквально до того, что по складу бегали сотрудники с бумажками, а рядом бегали айтишники и пытались что-нибудь запустить. Остановить работу на несколько месяцев, спокойно всё настроить и потом включить новый склад мы, конечно, не могли. Клиенту не объяснишь, что его запчасть пока нельзя принять, потому что у нас IT-проект.

Своя разработка у нас при этом была. У нас есть 1С-разработчики, внутренний IT и достаточно много компетенций, чтобы делать собственные решения. Но компания росла не только на складе: развивались продажи, закупки, работа с ценами, конкурентами. Забрать всех разработчиков и посадить их на несколько месяцев исключительно на мобильную автоматизацию означало остановить другие проекты.

Поэтому мы одновременно пробовали готовые решения и что-то делали сами. Причём времени на долгие конкурсы и сравнительные таблицы особенно не было. Логика была довольно прагматичная: берём вариант, пробуем запустить. Не работает — идём дальше.

Сначала нашли другое готовое решение, которое показалось проще во внедрении. Но оно не смогло нормально работать со сканирующей головкой терминалов, которые мы уже купили. Началась переписка с разработчиками, попытки разобраться, время шло, а склад продолжал работать. Я решил не ждать и начал искать следующий вариант.
Так мы пришли к Клеверенсу. А после того, как выстроили полноценный учётный контур, даже поучаствовали в съёмках подкаста.

Сначала мы решили, что часть процессов проще написать самим. А потом начали «городить огород»

Когда у компании есть собственные разработчики, вопрос возникает совершенно логичный: зачем вообще брать готовую платформу? Можно же написать приложение точно под свои процессы и ни от кого не зависеть.

На небольшом количестве операций эта идея действительно выглядит разумно. Допустим, нам нужно, чтобы сотрудник взял товар, отсканировал и положил в определённую ячейку. Такой сценарий можно довольно быстро сделать самостоятельно.

Проблемы начинаются, когда таких сценариев становится десять. Обычную приёмку нужно раскладывать по складу одним способом, товар под конкретных клиентов — другим. Для мегасрочных деталей нужен отдельный приоритет. Появляются свои исключения, дополнительные данные, нестандартные документы. И каждая следующая доработка начинает цепляться за предыдущую.

Мы тоже в какой-то момент начали «городить огород». Например, нам понадобилось разделить обычную приёмку и запчасти, которые сразу распределяются по клиентам. И мы стали придумывать под это собственную механику, что-то дорабатывать, накручивать. А потом выяснилось, что похожий результат можно получить гораздо проще, используя уже существующий бизнес-процесс.

Для меня это стало одним из аргументов в пользу готовой платформы. Внешний специалист нужен не только затем, чтобы написать по твоему техническому заданию ещё несколько строк кода. Иногда гораздо полезнее, когда ты описываешь ему бизнес-задачу, а он говорит: «Стоп. Вам вообще не нужно делать то, что вы придумали. Вот этот же результат можно получить проще».

Поэтому самый удобный кусок собственной разработки — иногда тот, который тебе не пришлось разрабатывать.

На документах в 8000 строк некоторые программы просто «превращались в тыкву»

Масштаб был отдельной проблемой. На тестовом примере многие системы работают прекрасно. А потом на склад приезжает реальная поставка и появляется документ на 8000 строк.

Нам нужна была возможность нормально работать с таким документом онлайн. Нельзя сказать машине: «Подождите, мы сначала разобьём вашу поставку на удобные для программы части». Коробки выгружаются в том порядке, в котором физически лежат в кузове. Первая может относиться к строке где-нибудь в конце документа, следующая — к его началу.

Мы сталкивались с решениями, которые на таких объёмах, как я обычно говорю, просто «превращались в тыкву». Пока данных немного, всё выглядит отлично. Когда справочник измеряется миллионами позиций, а один документ — тысячами строк, требования к системе становятся совсем другими.

Со стороны складская автоматизация при этом выглядит довольно скучно: сотрудник взял ТСД, отсканировал штрихкод, что-то появилось на экране. Но за одним этим «пиком» у нас может стоять поиск нужной позиции среди миллионов товаров и огромный документ, который должен обработаться достаточно быстро, чтобы человек не стоял посреди разгрузки и не ждал программу.

Мы могли отправить исправную запчасть в металлолом просто потому, что потерялась этикетка

При миллионном ассортименте есть ещё одна проблема: мы не всегда можем восстановить информацию о детали по самой детали. Если бумажная этикетка порвалась или потерялась, а точный артикул определить невозможно, перед нами может лежать совершенно исправная запчасть, которую мы больше не способны нормально идентифицировать.

Раньше такого товара за год могло набираться около полутонны. И речь не о сломанных или ржавых запчастях — они могли быть абсолютно нормальными. Просто мы уже не могли с достаточной уверенностью сказать, что именно перед нами, а значит, товар приходилось списывать и отправлять в металлолом.

Поэтому вполне резонно появилась необходимость перепечатать повреждённую этикетку, пока старый штрихкод ещё можно считать. Так мы точно знаем, с какой позицией работаем. Кажется мелочью на фоне самолётов, миллионов строк и огромных площадей хранения, но на реальном складе именно из таких мелочей в итоге складываются деньги.

Похожим образом мы изменили и инвентаризацию. Вместо того чтобы ждать одного большого пересчёта, можно постепенно проверять отдельные полки и ярусы между основными операциями. В тот же процесс удобно включать обслуживание товара: проверить давно лежащие детали, провести консервацию, заменить повреждённую этикетку. Тогда склад не приходится в какой-то момент останавливать целиком ради попытки разом пересчитать миллионы позиций.

Мы добавили ещё 1000 м² склада и приготовились нанимать людей, но они не понадобились

Рост склада обычно довольно легко превращается в рост штата. Стеллажей стало больше — значит, нужны новые кладовщики. Но при нашем ассортименте проблема даже не столько в количестве квадратных метров, сколько в том, сколько времени человек тратит на перемещения и поиск.

Мы недавно считали, что на тысячу квадратных метров при нескольких миллионах позиций без нормально настроенных процессов нам понадобилось бы порядка 17–18 человек. Если дать сотруднику заказ на 20–30 разных деталей и заставить самостоятельно искать их среди такого ассортимента, он может ходить по складу несколько часов. А заказов у нас не один и не десять — их сотни.

Потом мы добавили ещё примерно тысячу квадратных метров, построили большие стеллажи и пришли к сотрудникам с вполне логичным вопросом: людей «докупать» будем? Они ответили, что пока справляются сами.

Вообще за время развития склада объёмы выросли примерно в десять раз. Когда-то постоянно хранящегося товара было примерно на 60–70 млн рублей, позже — уже на 500–600 млн. При этом увеличивать штат пропорционально объёмам не пришлось.

Приёмка и отгрузка в итоге ускорились примерно в десять раз, инвентаризация — в пять. Операция, которая раньше могла занимать около пяти минут из-за поиска информации в 1С и Excel, теперь занимает примерно минуту.

Но после нескольких лет работы мне кажется, что лучше всего масштаб этой истории показывает вообще не эта статистика.

Где-то на золотом прииске ломается грузовик. Мы ищем нужную железку на другом конце света, ради неё заказывают чартер, самолёт пересекает океан, груз перехватывают в Москве и отправляют дальше. Клиент готов заплатить за доставку в несколько раз больше стоимости самой запчасти, потому что простой техники стоит ещё дороже.

А потом вся эта дорогая логистическая цепочка приезжает на наш склад.
И наша задача — среди миллионов других «железок» просто не потерять одну нужную.

Ага, попались! Вы тоже путаете понятия. Это же DataMatrix! И говорить будем именно о нём, а не о «куаркодах», в которых нам подсовывают рекламу или рецепты... Хотя логика такой путаницы вполне понятна: видишь на упаковке маленький квадратик, внутри чёрные и белые кубики — и думаешь, что это QR-код. А это не он!

На пачке йогурта, бутылке воды или упаковке молока сегодня мы видим именно DataMatrix. На кассе его сканируют, иногда сканер не может поймать код с первого раза, кассир поворачивает упаковку, раздаётся «пик» — и товар отправляется дальше.

Со стороны легко представить, что внутри этого квадрата спрятано вообще всё: кто произвёл товар, где, когда, из чего, в какую машину его загрузили, в каком магазине он оказался и когда должен испортиться.

Но если взять DataMatrix и посмотреть, что в нём действительно закодировано, картина окажется интереснее. И информации непосредственно внутри кода будет гораздо меньше, чем можно ожидать.

Сначала важное: DataMatrix — это не ссылка и не маленькая база данных

Мы привыкли к QR-кодам: наводишь камеру телефона — открывается сайт, меню ресторана или страница оплаты. Поэтому DataMatrix легко воспринимать примерно так же. Но сам по себе DataMatrix — это способ записать последовательность символов в компактном двумерном коде. Сканер считывает рисунок и превращает его обратно в цифры, буквы и специальные символы.

А уже дальше программа должна понять, что означает получившаяся строка. Для маркированного товара отдельные фрагменты этой строки имеют своё назначение. Чтобы их различать, используются так называемые идентификаторы применения GS1 — Application Identifiers, или AI.

Проще всего посмотреть на конкретном примере

Возьмём обычную пачку молочной продукции. В коде маркировки можно встретить, например, такую структуру: 01 — GTIN, 21 — индивидуальный серийный номер, 93 — код проверки. Цифры 01, 21 и 93 здесь работают примерно как подписи к следующим за ними данным: они сообщают системе, что именно она сейчас читает.

Начнём с 01

После него идёт 14-значный GTIN — глобальный номер товарной позиции. Он позволяет определить, что это вообще за товар. Условно говоря, по этой части система понимает: перед ней йогурт определённого производителя, определённого вида и в определённой упаковке.

Но…

Два одинаковых йогурта для системы всё равно разные

После идентификатора 21 записывается серийный номер конкретного экземпляра. И вот именно он у двух одинаковых пачек будет разным.

Например, вы видите полке две упаковки йогурта. У них один производитель, один вкус, одинаковый вес и одинаковая упаковка. Для покупателя между ними практически нет разницы. Для информационной системы — есть.

У одной пачки может быть серийный номер X7K2P9, у другой — M4T8Q1. GTIN отвечает на вопрос «что это?», а серийный номер — «какой именно экземпляр?». Именно эта комбинация позволяет перейти от учёта вида «у нас есть 100 пачек такого йогурта» к учёту конкретных пачек.

То есть DataMatrix нужен не просто для того, чтобы ещё раз написать на упаковке название товара в машинном виде. Он позволяет отличить одну физическую единицу от другой.

А что такое 93?

Ещё один элемент, который можно встретить в коде маркировки молочной продукции, — идентификатор 93. После него располагается код проверки. Он нужен для проверки КМ и помогает системе отличать корректно сформированные коды от произвольных комбинаций символов.

И здесь возникает интересный момент. Если мы знаем GTIN какого-нибудь йогурта, это ещё не значит, что теперь можно самостоятельно напечатать сколько угодно DataMatrix-кодов для таких же пачек. Одного номера товара недостаточно: экземпляр должен иметь свой уникальный серийный номер и корректные проверочные данные.

Поэтому просто нарисовать квадрат, внешне похожий на DataMatrix, — совсем не то же самое, что получить действующий код маркировки.

Значит, внутри есть ещё дата производства и срок годности?

Не обязательно. И это, пожалуй, одна из самых интересных особенностей всей системы. Когда после сканирования на экране появляется информация о товаре, легко решить, что сканер только что извлёк её непосредственно из DataMatrix. Но часть сведений программа может получить уже после того, как поняла, какой именно экземпляр перед ней.

Сам КМ в таком случае работает скорее как уникальный идентификатор, по которому информационная система находит связанную с товаром информацию. При этом структура данных зависит от товарной группы и конкретного сценария маркировки. Нельзя взять один код маркировки и сказать: «Вот эти поля обязательно находятся внутри каждого DataMatrix».

Например, стандарт GS1 позволяет использовать разные идентификаторы применения. 10 может обозначать номер партии, 17 — срок годности. Для некоторых товаров переменного веса применяются отдельные идентификаторы для указания массы.

Но наличие таких идентификаторов в стандарте ещё не означает, что каждый DataMatrix на любом маркированном товаре содержит все эти данные. Поэтому универсального списка «вот что всегда зашифровано в DataMatrix» не существует.

А сканер тогда что делает?

У него гораздо более скромная задача, чем иногда кажется. Сканер видит двумерный рисунок, распознаёт расположение чёрных и белых модулей и декодирует их обратно в последовательность символов. Например, получает длинную строку, внутри которой встречаются уже знакомые нам 01, 21, 93 и данные после них.

На этом магия самого DataMatrix практически заканчивается. Дальше начинается работа программного обеспечения: оно должно разобрать строку, понять назначение её частей и решить, что делать с полученными данными.

Поэтому один и тот же код можно физически считать разными устройствами. Вопрос не только в том, способен ли сканер увидеть квадрат, но и в том, что произойдёт с полученной строкой после считывания.

И ещё один неожиданный факт про цифры на упаковке

Раз уж мы заглянули внутрь кодов, стоит вспомнить ещё один популярный миф. Иногда первые цифры товарного номера воспринимают как указание на страну, где товар был произведён. Например: увидели определённый префикс — значит, продукт точно изготовлен в этой стране.

Это не совсем так. Префикс связан с организацией GS1, которая выделила компании соответствующий диапазон номеров. Сам по себе он не является надёжным доказательством страны производства конкретного товара.

Поэтому определить происхождение продукта только по первым цифрам товарного номера не получится.

Так что же всё-таки находится в маленьком квадрате?

Не полная биография товара. DataMatrix не обязан хранить внутри себя рассказ о том, где товар произвели, на какой машине привезли, сколько дней он лежал на складе и в какой магазин приехал.

Его главная сила в другом. GTIN позволяет понять какой это товар. А индивидуальный серийный номер — какой это конкретный экземпляр. И дальше информационные системы уже могут работать именно с ним.

Поэтому две одинаковые пачки йогурта на одной полке для человека могут быть совершенно взаимозаменяемыми. А для системы между ними есть принципиальная разница: у каждой своя цифровая идентичность.

И, пожалуй, это самая интересная вещь, спрятанная в маленьком чёрно-белом квадрате.