Мнение о вреде упрощенных GTIN

Материал из ismp.wiki
Перейти к: навигация, поиск

Вопрос: Зачем нужно сканировать два раза при продаже товара замаркированного КМ с "упрощенным" GTIN? В моем понимании карточка товара и мастер-данные в ней появляются не из сканирования gtin и зашитой в него информации. Поэтому вопрос по сути в том, существует ли сканирование фактически пришедших КМ (и из привязка к карточке товара) при приемке. А она должна существовать, иначе как обеспечить корректировку УПД. Но тогда все КМ привязаны к товару, и в общем-то все равно, какой там в них gtin. В чем я ошибаюсь?


Ответ:

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

То, что Вы держите в голове как "связь товара и серийного номера" называется "партионный учёт". В нашем случае - даже не "партионный", а "штучный". Каждому товару прямо сопоставлено N кодов маркировки по уникальному серийнику. Никак иначе. Все операции осуществляются по серийнику. Остаток на каждом серийнике может быть только "1 шт", не больше. Ну или "0 шт" Сейчас мы работаем по штрих-коду. 1 товар = 1 штрих-код EAN13 (редко, больше штрих-кодо или иные стандарты). Остаток на коде может быть от 0 до полного заказа. 100, 1000, 10000 ... Все операции осуществляются по штрих-коду и агрегируются до кода товара.

Что случится при переходе на работу по серийникам ? Ну правильно. Взрывной рост баз. И если в ERP, которая работает строго по коду и в которой идёт агрегация операций до кода, это будет не слишком заметно, то на фронте - кассах, ТСД, прайс-чекерах и прочем это будет смерть. Быстрая, но мучительная. Представьте себе, что для продажи бутылки Агуши (да, да, маркировка молочки не за горами), нам нужно будет передать на кассы и ТСД всех 700 магазинов не ОДИН штрих-код, а ВСЕ штучные серийники агуши. И так для кажного товара. Это же сотни тысяч, если не миллионы дополнительных записей. Да, можно фильтровать по объектам и остаткам. Но это тоже время. И немалое. Подготовить вместо одного полного справочника на всю сеть 700 кастомных по обьектам. Это у нас 700. А у Магнита и X5 ? То есть нужны другие сервера, возможно вообще другие решения хранения БД. Поэтому никто этого делать не будет. Все включат не прямую связь, а косвенную. Товар -> штрих-код -> серийник. И учет остатка КМ в отдельном регистре, не связанном напрямую с товаром. В случае "полной" маркировки будем выцеплять штрих-код из серийника и использовать его. В случае "упрощенной" - 2 сканирования. Одно для нормального товарного учёта, второе - для учёта КМ.

Дополнение к ответу 1:

В POS системе, которая стоит в магазине ничего ни к чему не привязано. Она знать не знает ни про какие КМ, а знает только про свой номенклатурный справочник, в котором GTIN = SKU

Дополнение к ответу 2:

- учет количества товара обычно построено по принципу = Cумма приходов - Сумма расходов. Так работает ERP, WMS , касса в разрезе товара или товара / партии. Это не применимо для учета серийных номеров , т.к. таблицы остатка и формы выбора "товара в наличии" расчитаны на свертывание не менее 1000:1 по ИД товара . - а это сделать невозможно для серийных номеров. При использовани серийных номеров (КМ) в обычной системе с проверкой остатка - сначала умирают формы подбора товара, потом распухают таблицы остатков, далее мобильное оборудование и т.д. - для учета по серийным номерам используют системы Track &Trace - в общих словах , такая система хранит признак наличия товара в статусе товара, (он же теперь или есть или нет). т.е.для учета остатка по СН нужна система другого класса. Не обычная ERP , WMS , касса. а Track & Trace

Резюме

Андрей, спасибо за развернутый ответ. Он понятен, как и комментарий Алексея выше. Если резюмировать, я упустил из виду тот факт, что фронтовые системы в традиционном ритейле не могут конечно содержать данные о связке КИ - SKU, даже если ERP система такой связкой располагает. Тогда проблема с упрощенкой понятна. То есть только уникальный gtin на уровне sku в составе КИ позволяет избежать двойного сканирования.