Решения для торговли по образцам

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

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

Здесь стоит отметить, что это основная задача, но хотелось бы, чтобы были какие-то еще классические ТСДшные функции у данного решения. Еще заказы оптовиков могут быть очень большие, соответственно работа с заказом может длиться достаточно долго. Помещение отапливаемое, но большое, и по нему нужно будет с этим решением часто и много бегать. База 1С:Управление торговлей 11.1. Необходимо, чтобы решение не требовало длительной интеграции.

Попробую озвучить все разумные варианты, которые могли бы подойти:

  1. Оффлайновые терминалы сбора данных.
  2. Онлайновые терминалы сбора данных.
  3. Станции-посты расставленные по залу с прямым доступом в базу.
  4. Планшеты со сканером штрихкода по wifi подключенные к базе.

На данном этапе выбора решения был следующий отсев: 1 – не подходит по оперативности данных, 3 – не подходит из-за привязки менеджера к месту станции, 4 – раскуют планшеты и нужно писать отдельный интерфейс (pip-boy не предлагать).

Остановились на втором варианте: Онлайновые терминалы сбора данных.

На этом этапе возник первый «затык»: что такое «онлайновый» ТСД? Понятно, что нужен wifi, но понимания итоговой архитектуры это не дало.

Опять был выбор:

  1. Писать 1С интерфейс для ТСД.
  2. Взять готовое онлайн решение Cleverence или Datamobile (не реклама, других не знаю).

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

Теперь был выбор между Cleverence или Datamobile. Я составил такую таблицу:

 

 

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

Оба этих программных продукта работают со всеми представленными ниже ТСД.

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

На этом этапе выбор пал на Cleverence, т.к.:

  • Для заказчика была важна нетронутость рабочей базы
  • Был опыт работы с этим решением

Далее нужно было выбрать ТСД. ТСД есть много хороших и разных. Бюджета не было, были только рамки разумности. Итак, мои кандидаты:

 

В таблицу я постарался добавить актуальные характеристики. Желтым цветом выделил те параметры, которые считаю ключевыми. Желтый цвет в шапке это мое предпочтение по выбору ТСД.

По ценам за ТСД – тапками не закидывайте. Цена в розницу, на стоковую версию ТСД, на середину ноября 2024 года, при курсе доллара 65р. У всех ТСД есть wifi и лазерный 1D считыватель.

 

Теперь о моделях:

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

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

Chipherlab – «кирпич» в мире ТСД. По моему мнению – самая распространенная марка в бюджетном секторе. Меня поразила гарантия: 3 ГОДА! На мой взгляд, это очень круто. Но у этого варианта есть большой минус – нет крэдла в данной поставке, если хотим крэдл нужно еще минимум 10 т.р. добавить. В целом, кроме размера экрана, характеристики этого ТСД очень хороши!

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

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

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

 

У меня все.

7 Comments

  1. CheBurator

    публикацию внес в http://infostart.ru/community/groups/22/

    Reply
  2. CheBurator
    » При высокой интенсивности работы менеджеров все равно будут ситуации, что на момент завершения заказа покупателя некоторые позиции из заказа могут уже отсутствовать в свободных остатках в нужном количестве. И будут проблемы с их резервом. Если на этапе формирования заказа мы видим оперативные остатки и можем маневрировать в ассортименте вместе с покупателем, то при отгрузке покупатель будет уже в ожиданиях стоять на выдаче и ломать его в мелочах – это неприятно. Делать построчное резервирование – это сложное управленческое решение, к которому заказчик пока не готов, не говоря уже об отсутствии такой функции в программах ТСД.»

    — вот вы и попали практически мгновенно в ловушку лишней «прокладки» между пользователем и базой (что мне неудивительно).

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

    .

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

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

    Построчное резервирование — не такая уж и страшная штука (если не забивать себе голову парадигмой 1С, ориентированной на работу с документами, а не на выполнение реальных действий). По моей прикидке все это построчное резвервирование — скорее всего да его придется ДОПИСАТЬ, но типовую конфигу можно и не трогать. ну появится 1-2 вида мегапростых документа. — в чем принципиальная трудность загнать в документ — состоящий только из шапки — все необходимые реквизиты для «горячего» резервирования данного конкретного товара напротив которого стоит менеджер с клиентом в данный момент? а по факту «все, утрясли все что надо» — жмакнуть ТСД и вместо этих горячих строк сгенерить обычный типовой заказ в терминах родной УТ? как-то вот так примерно…

    Reply
  3. ogre2007

    (2) CheBurator,

    вот вы и попали практически мгновенно в ловушку лишней «прокладки» между пользователем и базой

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

    Reply
  4. nickpugachev

    (3) зато каждая строчка может быть отдельным документом.

    работа заказом целиком хорошо идет пока нет конкуренции за сток, иначе построчное резервирование — спасение

    Reply
  5. Новиков

    В задаче явно прослеживается мысль об онлайн тсд. При этом, что важно, никакого доп.софта вообще покупать не нужно было, достаточно прокинуть RDM к нужному серверу. В этом случае нужно было всего лишь нарисовать отдельный АРМ для этого терминала. Если не браться за эту задачу универсально, то это вполне себе посильная задача на два-три дня, если с умом, думами о великом и т.д. При этом, нет никакого промежуточного оффлайнового софта и есть возможность запилить именно так, как подсказывает сердце 🙂

    Reply
  6. V.Nikonov

    (4) nickpugachev, При ОнЛайн работе предполагается видимость остатков… Фиксировать промежуточные стадии Заказа проведением проблем не составит. На практике — списание в заказ под остаток крайне редки. оценить риск всегда можно видя оперативные остатки, и при появлении критических товаров зафиксировать Проведением/Перепроведением обычного Заказа (Не каждая строка, а после добавления критической позиции).

    Reply
  7. nickpugachev

    (6) V.Nikonov, перепроводить заказ будем временем первой записи или оперативно? добавлять в заказ товары через пару часов можно? а если в заказе несколько сотен строк?

    это для размышления 🙂

    задачи разные бывают, условия тоже.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *