Автоматизация склада с помощью штрих-кодов : Другие вопросы

У нас есть задача - проводить приемку, отпуск и инвентаризацию товара. Хотелось бы это делать с помощью штрих-кодов (чтобы это происходило быстрее) .

1. Приемка. От нескольких поставщиков привозят товар (50-500 единиц ежедневно). Нужно с помощью штрих-кодов учесть их на складе. Оператор сканирует каждую полученную единицу товара, результат загружается в базу.

2. Отпуск товара. Оператор берет бланк заказа - на нем есть уникальный номер заказа, отображаемый в виде штрих-кода. Затем сканирует его номер, а также коды входящих в заказ товаров. Так мы считаем, какой товар ушел, и по какому заказу. Нужно, чтобы можно было задать кол-во единиц товаров.

3. Инвентаризация. Сканирование кодов имеющихся на складе продуктов.

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

Хотелось бы эти процессы автоматизировать с помощью терминала сбора данных. Желательно, чтобы терминал получал и отправлял данные по wifi. Какой терминал выбрать? Чтобы он еще и был легок в настройке и подключению к интернет-приложению. Возможно использование готового софта, но лучше интегрироваться с нашими имеющимися наработками.

Наверное надо идти не от терминала, а от системы.
Какое именно ПО будет стоять на складе?

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

1. Есть база продуктов (с названиями, стоимостью продажи, штрих-кодами). Сейчас в нее вручную вносятся поступаемые от поставщиков продукты. Так увеличиваются остатки продуктов.

2. При отпуске продуктов оформляется заказ, к нему прикрепляются продукты. Так уменьшаются остатки.

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

Нужно модифицировать задачу, чтобы приемка (увеличение остатков) и отпуск (уменьшение остатков) проводилась по штрих-кодам.

Естественно, нужна возможность задавать кол-во продуктов после сканирования штрих-кода.

Оптимальным решением была бы подгрузка информации по отсканированному коду продукту прямо из базы, и наоборот выгрузка информации по отсканированным продуктам обратно в базу. Желательно через WiFi по HTTP.

Есть ли устройства, с которыми можно было бы решить такую задачу?

Интересно, что скажут профессионалы, но свои 5 копеек я вставлю...

По ТСД есть три (как минимум) разных направления автоматизации. Взять готовую программу с кучей настроек, взять софт, который позволяет конфигурить на псевдоязыке, писать на винапи...

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

Вариант три, написать софт с нуля - самый правильный, и вы точно получите то, что надо. Минусы - это долго, нужен спец на написание и поддержку, и прочее и прочее и прочее... Но он и будет САМЫМ выгодным, если этих ТСД будет реально много.

Вариант два - промежуточный. И по цене, и по внедрению. Пример - ну например атол mobile logistic. Софт ваяется реально на коленке, но потом достаточно нудно отлаживать... Ну и, естественно, за лицензии надо платить...

Поэтому ответ на вопрос "Есть ли устройства, с которыми можно было бы решить такую задачу?" - да, они есть. И их достаточно много, десятки моделей.
Самый простой вариант для внедрения - тсд на вин мобайл, с лазерным сканнером. Цена - ну от штуки баксов и выше... За каждый... БЕЗ софта. Компиа, оптиконы, сайферы... Реально много...
Если это не пугает - ну в путь. Определяешься по времени работы (далеко не все модели могут тянуть вайфай и рабочий сканнер хотя бы 8 часов, т.е. смену), по быстродействию проца, по операционке, по памяти, по... Ну или хотя бы описываешь саму базу, тут уже посоветуют модельки.

Готовый софт искать не рекомендую. Если ту же инвентаризацию описали в куче программ, и хоть как-то, но оно работает, то нюансы прихода - это реально отдельный разговор. Ибо далеко не каждый софт умеет принять 2 коробки и 4 штучки товара (коробки естественно считываются коробками) и перевести в штуки (разные штрихкода - разные коэффициенты), сделать из товара с 10ю разных штрих5одами - один, "в ассортименте", вывести огроменное предупреждение/бибикнуть, если попадается "проблемный" товар (был момент, когда коньяк белый аист 0.5 и 1л имел один штрихкод, не знаю, как сейчас), принять товар вообще БЕЗ штрихкода или с поврежденным штрихкодом... Да масса нюансов есть. Вообще считаю приход с неподписанными контрактами на поставку (когда штрихкода оговариваются заранее, и с неподтвержденными штрихкодами товар возвращается назад) одной из достаточно сложных задач для автоматизации неопытным персоналом.

Скажу так, если надо запустить это дело быстро, и чтобы работало - реально бери тот же мобайл логистик (25 тыс за конфигуратор, это софтинка для одновременно работающих программистов, до 5 штук, свой дебильный. но достаточный язык, плюс 4200 за лицензию на каждый терминал, это все - если тсд будет больше 5 штук) - и вперед. Мне надо было автоматизировать отгрузку, неделя - тестовая версия пошла на склад в реальную работу, еще 3 недели - и все блохи отловлены и пожелания добавлены. Но отлаживать - реально жесть, врагу не пожелаю, там НЕТ отладчика, там есть спецрежим, когда все действия записываются в лог со значением переменных, получается такая некислая портянка на 200 кил голого текста, мозги вывихивает напрочь.
Выгружаю / загружаю текстовыми файликами с разделителями, по вайфай, онлайн. Терминала Opticon h19 с увеличенным аккумулятором хватает на 7-8 часов работы с включенным вайфаем и сканнером. Можно взять Н15, в принципе почти то же самое, но дешевле, но аккумулятора увеличенной емкости нету...

Инвентаризацию, с кучей пожеланий, тоже можно наваять за те же сроки... С приемом товара (случай - когда товар может придти с произвольным штрихкодом) - все сложнее, и намного.

После некоторого сбора данных, готов сформулировать вопрос теперь так:

какой терминал сбора данных способен отправлять HTTP-запросы по Wifi?

Должен реализовываться такой сценарий:
терминал считывает штрих-код, упаковывает его в строку (вместе с другими параметрами), отправляет запрос на http-сервер, и получает ответ в удобном для себя формате.

Прикольно, хорошее настроение с утра обеспечено.
Чтобы терминал мог отсканировать штрихкод и отправить его по вайфай надо два условия - наличие сканнера и вайфая!. (Сам терминал - подразумевается)
А вот то, что софта под твои условия, в общем случае, НЕТ - тебе и пытаются сказать, сначала Mtirt, потом я. И на чем ты его напишешь - да хоть на чем, можешь на яве, на бейсике, можешь на сишарпе, можешь на...на ассемблере, вот...

sevushka Ок, хорошо. Мое понимание задачи растет, но может не такими темпами, как хочется.

Поэтому подведу некоторые итоги на текущий момент.

1. Мне нужно подключить ТСД к веб-приложению на PHP. Поэтому нужно, чтобы он отправлял запросы по HTTP (в каком-нибудь формате - это может быть SOAP, XML-RPC, просто GET-запрос, да все что угодно), и умел понимать получаемый ответ.

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

3. Готового решения (на стороне ТСД) под мою задачу нет, как я понял из Ваших слов, и облазив интернет. Есть конфигруации, которые могут быть хорошей отправной точкой:

• Атол Mobile Logistics, как я понял для WinCE
• Сканкод/Cipher, на какой-то своей операционке.
• [ Клеверенс Mobile Smartes ], на WinCE, в одной из [ брошюр ] говорят, что на низком уровне драйвер работает с 1С через SOAP/WIFI (стр.7)

Наверное, есть еще какие-то системы. Но, по всей видимости, все предлагаю схожие подходы и инструментарий.

4. Лучше ориентироваться на WinCE. Однако хотелось бы услышать мнения по поводу продукции Сканкода.

5. Стоимость самого терминала громадной роли не играет, поскольку пока нужно только 1-2 штуки. Желательно, чтобы она была обоснованной. Opticon H15, действительно, хороший ориентир.

6. Вести самостоятельную разработку под ТСД возможности нет. Поэтому нужна компания или специалист, которые смогут доработать тот же Мобайл Логистикс (или что-то альтернативное, поддающееся напильнику) под наши довольно гибкие требования за разумный бюджет. Буду благодарен за рекомендации.

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

ТСД могут работать в двух режимах, онлайн и оффлайн. Онлайн - каждое сканирование отдается обработчику на стороне (в твоем случае - веб приложение), получается ответ - и только отображает результаты того, что насчитал сервер.
Оффлайн - загрузил всю базу товаров, все накладные (или шаблоны накладных для создания), все инвентаризационные ведомости (и прочее) в базу, отработал документ, и готовый документ отослал на сервер.

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

А теперь главная заподлянка. Тот же мобайл логистик, включенный в режим непосредственного обмена с драйвером, на достаточно серьезном железе (оптиконы н19) дает нереальные задержки при сканировании онлайн, до 3-4 секунд. Это пауза, между самим фактом сканирования, и до отображения готового результата из внешней базы на экране. Причем уменьшить мне их так и не удалось. Поверь мне, это очень много.
Более того, документ в 20-30 строк и результат одного сканирования уходят примерно одинаково, т.е. основная задержка в установке соединения и прочих накладных расходах. Может быть, в каком-то софте это и исправлено(т.е. отклик хотя бы 0.5 секунд или меньше), но я про такое - не знаю.
Именно поэтому все терминалы, которые встречал я, работают в режиме оффлайн... Получили базу номенклатуры, документы, доп информацию... отработали документ, с локальным поиском по своей базе, всех штрихкодов, отправили результат назад.

С онлайн запросами на каждый писк - ну для меня будешь первопроходцем, потом сам в форумах будешь опытом делиться... Если заработает так, как надо


Стандартно я таких не видел. Не говорю про хмл, даже гет запросы...Или текстовый файл с разделителями, или свой СОБСТВЕННЫЙ закрытый протокол обмена с драйвером.

Эм, я понимаю, что сейчас могу обрубить все желание автоматизировать процесс, но, если бы на Вашем месте был бы я (тут вылезло ключевое условие - комп рядом), я бы поставил что-то типа аргуса или магеллана (многоплоскостной сканнер) и дисплея покупателя (ну или маленький монитор). И софт писать в разы проще, и мощность ничем не ограничена, и скорость обмена - космос, и на батарейки плевать, и качество сканирования - идеальное...

Теперь по софту. Сайферовское решение я видел только в самом зачаточном виде, это был 2006 год. Эм, как бы по вежливому назвать то это... В общем сильно похоже на бейсик для зх-спектрум. Ну или гв-бейсик для старых версий мс-дос. Я к чему виду, те версии - отпадают однозначно, для них хттп - матерное слово. Что сейчас - не знаю.

Мобайл логистик - тоже не фонтан. НО! У них есть неплохой форум поддержки, где можно задать адекватную просьбу и ее аргументировать. Если найдутся еще желающие (или вы будете готовы оплатить работу) - они добавят обмен по хттп. По крайней мере лично для меня доработки они делали бесплатно, пусть и не такие масштабные. В текущей версии к онлайн работе она не приспособлена, см. выше про задержки.

Если речь зашла про разумный бюджет - давай так посоветую...
Не изобретай велосипед. Поговори с тем же атолом, чтобы взять "на погонять" терминальчик с их стандартной конфигурацией - приемка товара (естественно - оффлайн). У них же есть и отгрузка, и инвентаризация в демо пакете, идущем с конфигуратором. Да, обмен через их драйвер, но к нему прицепиться достаточно легко.
И только потом, если это все не устроит - начинай задумываться про реализацию ваших требований. Смотри какая фишка, объем задач по сааааамым скромным прикидкам (ява/сишарп/дельфи, винапи, винсок, получить результат сканирования, сформировать хттп запрос по штрихкоду, получить ответ из базы, разобрать его -> товар из базы, обработать все случаи ошибки, получить количество, отправить товар с количеством в базу, иметь возможность начать/закончить/редактировать документ) я оцениваю часов в двадцать-тридцать работы. Причем основная часть уйдет именно на работу с вашим веб приложением. Тридцать часов работы московского программиста стоят - ну как один терминал, примерно. И это - только начало. Для решения, в котором и так будет только один терминал - лично мне эта цифра кажется завышенной.

Естественно, всегда остается вариант, что твое/аналогичное решение кто-то реализовал. Но лично я про такое не слышал. Собственно интернет большой, удачи в поисках.

sevushka, спасибо за ответы. Дам несколько комментариев.

1. Response time в 3-4 секунды в онлайн-ТСД, конечно, неприемлем. Для меня такие цифры - сюрприз, конечно. Надеюсь, что можно получить 0,5-1 сек. Обслуживание любого HTTP-запроса (обработка бизнес-логики на стороне веб-приложения) можно гарантировать в 0,1-0,2 сек (включая все сетевые взаимодействия). Все остальное время - на отправку и получение ответа внутри терминала, надеюсь ее можно уложить в 0,5 секунды (а лучше и меньше), все-таки железо на современных терминалах довольно мощное.

2. Оффлайн-ТСД - тоже не самый хороший вариант, база довольно часто меняется, закачивать ее в терминал один-два раза в день - не хочется.

3. Вся бизнес-логика реализована в веб-приложении, он на удаленном хостинге. Рабочие компьютеры по сути - тонкие клиенты. Поэтому хотелось бы сохранить эту идеологию и с ТСД - он тонкий клиент веб-приложения. Дополнительный софт (терминал покупателя, специальный стационарный компьютер для этой задачи) - это значит снижение гибкости, необходимость постоянной синхронизации между ним и веб-приложением.

4. C Cipher я успел связаться, сказали, что доработку с HTTP-протоколом сделать возможно (остается, конечно, вопрос с response times). Скудность среды разработки можно простить, даже если это будет а-ля basic от ZX-Spectrum (на нем в свое время попрограммировал :) ) - хочется сделать логику работы на стороне ТСД максимально примитивной. Все выносить в приложение. Главные вопросы - это наличие специалистов, сложность отладки (а она у всех по всей видимости одинаковая), ну и response times.

5. Ну и окончательно - почему нужна такая автоматизация. Оприходование нужно делать в очень ограниченное время (желательно в считанные минуты), если делать это вручную - значит подключать нескольких людей к этому процессу, при этом сохраняется довольно высокий уровень ошибок. В общем, в наших условиях это почти нереально.


В общем, в приоритете сейчас - поиск возможностей создания ТСД в виде тонкого клиента на HTTP. Желательно использовать существующие разработки. Если не удастся найти вариант, подходящий по цене доработки и response time, придется идти на компромиссы (оффлайн тсд, дисплей покупателя).

в свое время запускали склад на С+ WhareHause Expert
и там как раз ТСД работали в online
на самих ТСД был запущен како-то терминальный клиент
на сервере тоже что то крутилось - все работало очень быстро... ни о каких секундах ожидания даже речи не было...
ТСД - Intermec-31
единственная проблема - мертвые зоны WiFi в отдаленных углах склада..