Внедрение штрих-кодирования на складе.

Игорь, нужно начинать с полного описания вашего ТЗ и ПО: что планировали получить от ИТ-шников и что, в результате, получили? Такого понятия, как «ПО для сканеров» не существует; точнее, это — блок складской учетной системы, который переводит ШК в текстовую/цифровую информацию. Поэтому вопрос: неужели вам важно, какие программы используются для ЧТЕНИЯ штрих-кода? Гораздо важнее: каким образом и какие программы используют ту информацию, которая «вшита» в ШК. Вообще, внедрением системы учета ШК занимаются поставщики WMS. Обратитесь к ним: они вас очень подробно проконсультируют.

Илья, благодарю за комментарий.

Да, мне действительно важно знать какие программы используются для чтения ШК, но мне важны не названия, а важен функционал. Как я указал, у разных поставщиков товаров, ШК разные и дело не формате котрый использован для создания ШК, а в информации которую несет в себе ШК. Один поставщик заносит в 1 штрих код и артикул, и серийный номер, и номер заказа, другой делает для каждого реквизита отдельный штрих код, третий, вносит в ШК артикул и номер заказа, а для серийника использует отдельный ШК, а если принять во внимание, что у всех поставщиков свои префиксы и постфиксы, и приведенный список реквизитов не ограничивается артикулом, серийником и номером заказа, то набирается таких вариаций великое множество. Нам необходимо понять механим, которым пользуются склады, основой бизнеса которых является оказание услуг по хранению и распределению. Не могут ведь они иметь под каждого заказчика спец. формат по считыванию информации из ШК. Мы обращались к многим, в том числе и к компании «Рарус», но они не смогли нам помочь, нашли другую компанию, но они подошли к задаче «в лобовую» то есть выполнили наше ТЗ от точки  до точки, не дав никаких профессиональных советов или рекомендаций и не указав на слабые места нашего ТЗ, хотя я думаю они могли это сделать. В итоге мы имеем ПО, которое отвечает нашим нуждам лишь частично, поскольку оно не учитывает возможных вариантов отображения информации в ШК и не может вычленять нужную нам инфо из ШК. Подсказать как сделать так, чтобы мы могли не задумаваться о том, какое количество и какая инфо будет зашифрована в 1ШК и спокойно использовать сканер зная, что он будет брать только нужную нам инфо из ШК, они не могут. :)   

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

Если знаете каких либо толковых поставщиков WMS и можете поделиться их контактными данными, буду крайне благодарен!

Коллеги, добрый день!

Прежде всего хотел бы заметить, что Илья в чем-то прав. Игорь, Ваша ошибка в том, что Вы, при огромном многообразии кодов поставщиков (условно) и отсутствии возможности получать базы (и обновления этих баз) шк от производителей, пытаетесь работать по их кодировкам. Пример: нам на склад одна международная фармацевтическая компания поставляла препараты со своих заводов. При этом один и тот же препарат мог производиться и в Восточной и в Западной Европе на разных заводах. Соответственно, и коды на паллетах стояли разные — иной раз до 7 этикеток на одной паллете, что характеризовало этапы изготовления именно этой партии именно на этом заводе. Кстати, количество этикеток не унифицировалось — иногда 7, иногда 5, и т.д. Примерная история и у Вас, насколько я понимаю. Ваши приемщики могут идентифицировать товар? Или для них это черный квадрат? В любом случае, для успешной работы и спокойствия каждой из сторон (Вас и клиента), желательно бы заранее получать типа заявки на прием товара. Нет необходимости говорить, что товар должен быть занесен в Вашу учетную. либо WM систему. При этом синхронизация записей в базах (Вашей и клиента) должна быть однозначной. Иными словами не допускается написания А, С,Н и т.д. в одной базе латиницей, а в другой кириллицей — вид один, но значение разное. Далее… Если Ваши приемщики могут отличить «вилку от ложки» то лепите на товар собственный шк и синхронизируйте его с записью в своей базе. Вообще-то этот вопрос уже попахивает ТЗ для полноформатной WMS)))), коллеги равильно отметили, что ПО для сканнеров работает лишь со сканнером — что и как прочитать и чего дать на выход. А вот взять это «чего» и преобразовать в «наименование товара — количество — место хранения…» — это уже задача другого ПО.

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

Что касается собственных ШК, то, как я понимаю, «не совсем приемлемый вариант» из-за вроде бы необходимости наклейки ШК на каждое единичное изделие? Но это не совсем так… Можно ведь кодировать тару, в которой находятся однотипные (одинаковые) изделия и место хранения этой тары. Тогда Вы получаете однозначную связь: место хранения — тара — Наименование — Количество… Разве нет? Конечно, прикольно, когда на каждом изделии стоит ШК, но что это дает практически? Использовать сканнер при пикинге одинаковых изделий (с одинаковым ШК) — бесполезное занятие! Уверяю, что если у Вас будет такой процесс (возмите изделие-считайте ШК-положите в комплектовочную тару-возьмите изделие…. и т.д. до набора 100 шт), то наборщик просто считает 100 раз ШК с одного изделия, а потом отсчитает 100 штук в тару)))… например, 9pin’овые разъемы))). Насколько я понял, Вы работаете со стандартным оборудованием поставщиков… Да, какие-то характеристики различаются от поставки к поставке… ну, условно емкость памяти, количество входных-выходных каналов, но ведь это, суть, разные товары! Вам сильно необходимо знать про внутреннюю партию CISCO при получении какого-нить аппарата от них? Вы же либо «привязываете» этот аппарат к заказу Вашего клиента, либо указываете его характеристики и выставляете в свободную продажу? Разве не так?

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

Мне действительно не безразлично знать какая внутренняя партия (внутренний номер заказа поставщика) у того или иного «железа», поскольку это дает возможность готовить отчеты для поставщика где и используется внутренняя и внешняя партия (внутренний номер заказа покупателя), а также серийный номер. И нам действительно необходимо списывать определенное «железо», из определенной партии, на определенного покупателя. Соответственно при приеме товара на склад, мы хотим внести эти реквизиты в нашу систему и тем самым связывать конкретный «приход» с конкретным заказом в нашей учетной системе (1С), в расходный ордер будет попадать вся необходимая инфо (артикул, серийник, номер партии) и когда во время отгрузки будет формироваться партия отгружаемого товара, то ПО не даст «списать» похожую железку из другой партии. 

Думаю, что у нас есть 2 варианта:

1) ввести процедуру обклейки своими штрихкодами (то, что Вы порекомендовали)

2) ввести учет на основании номенклатурных групп (каждый поставщик это группа)

А пока, мы анализируем ШК для того, чтобы объединить их в группы по принципы содержащейся информации и тем самым снизить возможное количество групп.

Игорь, правильно ли я понял, что у Вас по-заказные поставки и отгрузки? Я попробую описать ситуацию, а Вы либо подтвердите, либо опровергните…

Итак… Насколько я понял, Ваши инженеры оборудуют какой-то объект (или рекомендуют определенный набор оборудования). При этом возможна ситуация, когда при определенных условиях Вам необходимо нестандартное оборудование, которое поставщик исполняет именно для этого заказа. Так? Если  — да, то он (поставщик), соответственно присваивает ему какой-то уникальный номер (партия, серия и т.п.). Кроме того, могу предположить, что такое же (по виду) оборудование может поступить к Вам от того же поставщика вместе с уникумом.При этом в сопроводительных доках поставщик указывает ШК партии (серии) и, по идее, должен их «привязывать» к различным заказам от Вас. Так?

Александр, добрый день,

Да, Вы все правильно описали, только лишь за исключением того, что поставщик дает нам сопроводительные документы в которых указаны ШК. Такой инфо в документах нет. Мы получаем инфо из оn-line системы или по отдельному запросу и только о серийных номерах товара. Номер партии присваевается сразу при размещении заказа. Как правило у нас не возникает проблем с «уникумами», проблемы возникают со стандартными позициями которые мы должны поставлять согласно данных которые мы предоставили поставщику в момент размещения заказа.  

ОК. Таким образом у Вас есть возможность «выгрузить» из базы поставщика серийники по-позиционно к конкретной поставке? Если так, то остается только «подтянуть» к каждому серийному номеру его ШК (естественно, уникальный). Можно ли договориться с поставщиком о такой информации? Если можно, то, думаю, и наименование он вам не откажется давать…

В любом случае, «скоростная» идентификация товара сканнером возможна только при наличии некоей таблицы, с данными которой сравниваются «читаемые» Вашим сканнером ШК. Самое простое  — получать ШК с соответствием SKU от поставщика, сложнее получить структуру ВСЕХ используемых на производстве ШК от поставщика и писать ПО, анализирующее тот или иной ШК. Но последнее, по-моему, слишком круто и не нужно…

Александр, Вы можете дать Ваш скайп контакт?

Думаю, что будет проще и интереснее пообщаться в живую.

azve_5910

Уважаемый игорь,

Ваша задача не так уж и сложна, по причине того, что данные устройства они просто переводят с картинки в уникальный код, а вся логика заложена в Вашем программном обеспечении. Что там заложено — это второй вопрос. Я выпонил проект в одной из самых крупных дистрибьюторских компаниях по продаже запасных частей и реализовал проект переезда с одного склада на другой с внедрением 100% сканерной системы (для уменьшения ошибок и увеличения оборачиваемости) за 1 (ОДИН) месяц. При этом — стеллажи были ТРЕХЭТАЖНЫЕ !!!!!! Обращайтесь за деталями — все не так просто. 

Один из вариантов был: внедрение системы RFID меток на базе сканерного оборудования на сборочном складе производства автомобилей в Украине !!!! Это был нонсонс RFID но очень упрощенно.

Сергей, добрый день!

Благодарю Вас за комментарий. Буду Вам очень признателенесли Вы сможете поделиться деталями, относительно програмного обеспечения для сканеров.

Склад дистрибуция запасных частей:

Поное техничекское задание с этических правил — выложить не могу. В базе использовался С++ Билдер 6.0 на SQL базах данных. Устройства сканеров — брались самые дешовые, двайвера к ним брались с коробок. А дальше Ваша логика… Пришел сотрудник на работу (пик бейджиком) взял заказ на сборку (пик + пик документа), собрал 100% (пик+ пик) собрал не 100% ( пик+пик в другом месте). Упаковщик (пик+пик). упаковочный вложил (пик+пик). Загружаем на паллету (для отправки (пик+пик), загружаем место в машину (пик+пик), …… и так далее. Более дорогие сканера использовались для инвентаризации (переносные) — их было очень мало но — недособранный заказ — сразу же учетчик летит делать срочную инвентаризацию по данной позиции на место (инв лист-пик, место на  полке — пик, результат инвентаризации — пик) ……

В складской программе нужно добавить функционал, позволяющий к артикулу привязать поле разбора штрихкода. В этом поле IT специалист (администратор WMS) на языке программирования пишет процедуру парсинга ШК. Если пойти дальше, то можно ШК описывать макро языком, понятным любому пользователю, а внутри складской программы должен быть обработчик макроязыка.