Автоматизация простого склада с ТСД и сайтом (без классической системы учета) : Другие вопросы

День добрый.
В течение 2-3 последних недель я регулярно вычитываю на форумах, в статьях и пр. источниках информации о терминалах сбора данных, сканерах штрих-кодов и многое другое. У меня нет навыков автоматизации торговли или логистики, но по роду предыдущей деятельности некоторое время занимался компами, сетями и прочим..

Опишу вкратце, что планируется осуществить:

сервис по приему товаров из интернет-магазина и их последующей перевозке \ сборке в одну посылку с целью отправки клиенту.

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




Действующие лица и краткое описание процесса:

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

- склад первичный (на нем происходит прием выкупленного товара с интернет-магазина, внесение товаров в базу, распечатка и наклеивание штрих-кода, подготовка к отправке и сама отправка товаров на следующий склад;

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

> Пример: пришли на первичный склад 30 единиц товара. Пусть это будут джинсы, мобильники и наушники (для упрощения понимания), каждого товара по 10 штук.. Всего 3 конечных клиента-получателя, соответственно 3 посылки: у одного клиента это 10 джинс, у второго 10 телефонов и третий ждет у себя коробку с 10ю наушниками.

Что планируется сделать на первичном складе: присвоить каждой посылке свой ID, пусть это будет ПОСЫЛКА 1, ПОСЫЛКА 2 и ПОСЫЛКА 3; присвоить каждому товару свой штрих-код, содержащий информацию о:

номере посылки,
названии товара,
количестве товара (в будущем еще добавятся параметры, но пока основными будут являться перечисленные 3 параметра).

Примерно такая суть: ПОСЫЛКА 1 \ джинсы мужские \ 1 шт


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


[ После этого товары передаются курьерской службе для доставки на следующий склад (конечный). ]


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

_____________


Что требуется от ТСД (если я верно представляю себе возможности этих устройств):

1. Связь с БД проекта, в которой будут присутствовать записи о текущих посылках и о текущих товарах \ штрих-кодах
2. При сканировании штрих-кода поступающих товаров сотрудник конечного склада должен видеть на дисплее терминала номер посылки, которой принадлежит данный товар. Проще говоря, чтобы он при получении мог раскидать джинсы в коробку для клиента, который ждет джинсы, наушники в коробку к наушникам и мобильники в коробку с мобильниками) вместо того, чтобы каждый раз при получении джинс или наушников не подбегал к кому, не смотрел в экселе или в сайте, к какой же посылке принадлежит тот или иной товар и не терял на этом время ( по факту товары практически всегда разные ). Как раз это и объясняет, кстати, одну из причин отсутствия классической системы учета.


3. Продолжая пункт 2: ТСД после каждого сканирования (предполагается покупка аппарата с WIFI) должен связываться с БД и вносить туда изменения
(INSERT INTRO ... "джинсы мужские 1 шт" ... ПОЛУЧЕНО_КОНЕЧНЫМ_СКЛАДОМ", "1")
Синтаксис SQL подзабыл, ну да ладно, тут важно суть передать.


Сканер отработал - данные в базу внесены - на сайте видно, что, например, все 10 джинс из ПОСЫЛКА-1 благополучно приняты и просканированы ТСД на конечном складе.

___________________




Интересует вопрос: возможна ли организация логистических процедур без участия классической программы учета с учетом описанной выше специфики ?

Что вы могли бы посоветовать (в т.ч. в плане ТСД?
Бюджет пока не определен. Могут ли знатоки оценить сумму? Сам ТСД с поддержкой беспр. сети, принтер штрих-кода, конфигурирование ТСД - вроде все статьи расходов. Уложимся тысяч в 40? Если принтер взять за 10, ТСД тысяч за 25.. Разработка сайта сюда не входит.. Возможно, потребуется оплатить частному разработчику создание конфигурации для ТСД и скрипт или (не знаю, как оно работает) для связи с БД. Пока не известно, насколько это сложная задача и сколько она может потребовать денег - может, тысячу рублей и полчаса работы, а может и больше).

Ввиду ограниченности знаний в этом направлении, а также преобладании сугубо теоретических сведений при построении схемы "проекта" возможны неточности и нестыковки. Буду рад конструктивной критике и предложениям. :)

Самый первый вопрос, а зачем вам столько складов???

Мне кажется, что вы выбрали очень тернистый и непрямой путь, который достаточно часто выбирают начинающие. А именно: "Мы сейчас напишем себе все с нуля". Либо это что-то совсем маленькое по товарообороту, либо после того, как вы вложите уйму денег, придется все же причалить к чему-то более-менее стандартному. Думаю, что с учетом описанной выше специфики нолик у бюджета потерян. Ну или, минимум, половина от этой суммы. Заложив мизер в разработку сайта и прошивки ТСД, вы очень сильно промахнулись. А у вас еще и распределенная база? Не очень понятно, что есть "товары всегда разные"?

На мой взгляд возможна, но, так как учёт всё равно нужен (мы же должны знать - товар вот этого клиента по такому-то заказу - где находится?) - то придётся организовывать его самим (на сайте?).

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

Я не возьмусь :)

Спасибо за проявленный интерес.
Отвечаю по порядку на вопросы

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

Наверное, маленькое по товарообороту, как Вы выразились :)
Расскажу вкратце:

количество обрабатываемых посылок в месяц: ~50, клиентов-получателей примерно 40 (некоторые заказывают по 2 посылки)
количество обрабатываемых товаров: пусть будет 20 товаров в каждой. Помножить на 50 посылок = 1 000 видов товаров, некоторые из которых заказываются не в единичном количестве (например, клиент заказывает 1 часы, 1 джинсы, затем 5 рубашек и 10 телефонов, образно говоря).

Насчет потерянного нолика - это несопоставимо. 500к для этого почина - все равно что из пушки по воробьям. Инфраструктура представлена сайтом, 1-2 ТСД и принтером штрих-кода..

Я хотел сказать мысль о том, что, в отличие от магазина, например, в котором 80% товаров являются постоянными, в моем случае все товары разные заказываются (намного реже встречаются случаи, когда клиент заказывает какой-то товар, который был ранее заказан другим клиентом). Их не нужно хранить в базе, каждый месяц сверять остатки и проводить инвентаризации.. Получули - отправили дальше - забыли.. Всё. :) Записи о товарах будут храниться на сайте и в ЛК клиента (по суди, в SQL-базе сайта просто для того, чтобы у клиента была история покупок, история посылок, товаров и пр).
Для ТСД потребуется работа только с текущими товарами.

Фронт-офис по этим товарам будет реализован на сайте (клиент будет видеть у себя в кабинете название товара, количество, статус, картинку и прочее). Там же он будет следить за своими посылками, оформлять запросы на покупку \ добавление товаров, общаться с оператором и прочее..
Сам сайт и будет системой учета (нет нужды, например, формировать бухгалтерские какие-либо ведомости.. Накладные и прочие бумаги).
Проще говоря: клиент оформил на сайте покупку 1 джинс, 1 рубашки и 10 телефонов..
На сайте он в своем кабинете видит эти товары со статусом (выкуплено).
Позднее товары приходят на первичный склад, сотрудники вносят в базу записи о пришедших товарах (скорее всего на первичном складе без ТСД), т.к. там как раз возможны возвраты товаров, недополучение, всякие косяки, которые автоматизировать нужно будет долго и трудно. Наверное, тут работа будет больше в ручном режиме - получить, приклеить штрих-коды, вписать в базу и подготовить для дальнейшей отправки.

А вот на конечном складе уже нужна автоматика. К моменту отправки товаров с первичного склада клиент в своем ЛК на сайте увидит статус "в пути на конечный склад".
У сотрудников этого склада задачи будут представлены приемом товара с помощью ТСД, который должен на дисплее дать информацию о том, что эти вот джинсы для клиента с "ПОСЫЛКА 1", а эти телефоны - для клиента "ПОСЫЛКА 2".
Сотрудник склада сам рассортирует по коробкам, едва ли в обозримом будущем ему придется собирать одновременно более 5 коробок..
После сканирования ТСД каким-то образом должен связаться с базой сайта, выполнить SQL-запрос. Пока не знаю, как это реализовать, но, думаю, современные терминалы должны уметь дружить с SQL. Мне кажется, это самый простой способ для выполнения моих задач.

Рекомендую сесть и подумать, как вы все себе это представляете, пошагово.
Я, например, не очень понимаю, что у вас будет учетной единицей? Штрихкод товара? Артикул? Товар-то еще как-то надо на сайте заказать и связать покупку с тем, что на складе... Не будете же Вы подробно расписывать "Джинсы с медалькой синие, три кармана", чтобы объяснить складскому персоналу, что принести. Вопросов больше, чем ответов.
Либо приходит посылка с "джинсами 1шт, рубашкой, 10 телефонов", но вы вообще никак не участвуете в ее разборе, т.е. как пришла она, так Вы ее клиенту и передаете, просто отмечая ее каким-то кодом. Нюансов много, многие из них в корне поменяют подход к автоматизации.

С этим замечательным сообщением пропало всё то, что я достаточно долго набирал в ответ. Приятного мало.

Второй вопрос - есть кнопка редактировать или нет? Для цитат аш 3 кнопки вижу.. Но для правки - увы.

Третий вопрос по теме - спасибо за совет. Буду работать в указанном направлении. Между делом хотелось бы узнать, есть ли у ТСД современного образца взаимодействовать, например, с SQL? Есть какие-либо несложные решения по взаимодействию ТСД и веб-сайта как такового? Могли бы вы привести рабочий пример ?

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

По вопросам сервера есть соответствующий раздел, предлагаю не оффтопить, тем более, что я многое в том разделе уже описал.
Что касается "взаимодействовать", то Java, например, поддерживает коннекторы почти под все средней нормальности СУБД. И, да, она работает на многих мобильных ОС. Вот это и есть рабочий пример. С веб-сайтом еще менее понятно. Да, браузеры так же есть практически на всех мобильных ОС. Что есть "взаимодействие"? Я же предлагал сесть и пошагово представить себе весь процесс, чтобы таких вот теоретических вопросов о смысле жизни не было.