Синхронизация остатков: WMS получает из учетной системы документы поставки, на основании этих документов создаются партии товара, после чего товар размещается в ячейки. Товар из ячеек отбирается для заказов и уезжает клиентам. После продажи заказа WMS получает чеки из приложения курьера и отправляет их в учётную систему, там товар списывается на основании чеков. В WMS товар списывается после изменения статуса заказа на «выкуплен» или «выкуплен частично»
Приложение для складских рабочих: приложение на Android. В котором в webView крутится одностраничное веб-приложение на knockout.js и jQuery, которое по api стучится в WMS.
Для курьеров используется парк промышленных устройств на Android, потому приложение выдачи заказов написано под Android,
проблему с выключением фонового отслеживания GPS не требовалось решать для этой платформы.
Вопрос потребления энергии решается повышенной емкостью батарей устройств и доступности зарядки в автомобиле :)
Что же касается нашего приложения для клиентов, где можно заказать товары, то оно написано под две платформы.
Приложения для внутреннего использования обновляются через собственный сервис, есть идеи посмотреть в сторону Android Enterprise для этого.
Номер телефона прячется посредством вызова через дополнительный сервис.
Сначала был обычный телефонный вызов на общий номер КЦ в котором через DTMF передавался айди, и дальше станция набирала номер клиента,
затем перешли к схеме с вызовом через дополнительный сервис, т.е. после нажатия кнопки связи с клиентом в приложении, отправляется REST запрос на сервис,
затем этот сервис совершает два исходящих звонка на номер курьера и клиента.
Да, мы уже начинаем готовится к тому, чтобы автоматизировать максимально все ручные операции и, конечно же, сборку на складе. Сейчас на рынке есть несколько интересных решений, которые мы рассматриваем и готовимся к постепенной роботизации склада.
А у нас есть такая функция и она так и называется: самовывоз. При оформлении заказа вы можете выбрать, что вам удобнее: получить заказ курьером (этот вариант выбран по умолчанию) или забрать заказ в магазине. Правда, далеко не все магазины доступны к выбору, но их количество постоянно увеличивается.
1. ТСД на Android от Urovo, модели разные, постоянно ищем и тестируем новые аппараты
2. При отборе сотрудник не сканирует ячейку, т.к. мы резервируем товар в конкретной ячейке и формируем задание на отбор из этой ячейки. Сотрудник выполняющий задание может отобрать товар из той ячейки где он зарезервирован либо отправить его в брак или утерю. В этом случае проблемы с остатками нет. Т.к. у ячеек нет физических границ товар может оказаться в соседней ячейке, но это не вызывает проблем у склада.
Откат на предыдущую версию реализован восстановлением из бэкапа. Процесс обновления включает в себя бэкапирование предыдущей версии ПО на сервере и на каждой кассе, что позволяет нам быстро и с почти 100% успешностью восстановить работоспособность магазина. Восстановить можно как отдельную кассу, так и весь магазин в целом. Магазины, которые не сформировали бэкап, исключаются из обновления.
Практически 100% восстановление работоспособности магазина при неудачном обновлении, позволяет нам не учитывать количество магазинов в конкретном населенном пункте. “На всякий случай”, мы обновляем половину касс в магазинах, на стадии пилота новой версии ПО, особенно в его первой фазе. Это позволяет нам исключить остановку продаж, в случае форс мажорных ситуаций.
Обновление торгового ПО с выездом в магазин не используется с того момента, как счет магазинов Компании пошел на сотни.
Суть статьи сводится к описанию кардинального увеличения скорости и безопасности распространения релизов торгового ПО путем автоматизации этапов работ, оптимизации и изменения технических и организационных процессов.
С точки зрения архитектуры, используется клиент-серверная схема взаимодействия кассы и локального сервера в магазине.
Естественно мы задумываемся про облачные решения. В наших планах реализовать пилот по переводу пока одной кассы в магазине в облако. Главная проблема облачных решений – доступность, у нас обширная география расположения магазинов и, к сожалению, не везде возможно обеспечить качество и доступность каналов связи на высоком уровне.
Основная проблема – это достижение баланса между количеством обновляемых конфигурационных единиц (касс/серверов) и безопасности обновления для Бизнес-процессов. Безопасность достигается наличием строго регламентированной последовательности действий: подготовки системы, предварительных проверок и исключения объектов из обновления, самого процесса обновления, комплексной проверки, четкого порядка действий по «реанимации» проблемной кассы/сервера в срок, остающийся до открытия магазина утром.
Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.
Под непосредственно обновлением касс подразумевается доставка дистрибутивов приложения торгового программного обеспечения до каждой локальной конфигурационной единицы (сервер/касса), распаковка, запуск и успешное прохождение процесса инсталляции новой версии приложения. Все работы проводятся удаленно без выезда специалистов в магазин.
12000000 – это кол-во DFU (PLU * кол-во магазинов) примерное количество на Перекресток.
Товары заводим для X5, но пилот с Марсом проводил Перекресток, поэтому информация только по этой сети.
Вы видели в «Пятёрочках» огромные мешки с собачьим кормом? Ассортимент гипермаркета и магазина «у дома» все-таки отличается. КСО используется для быстрых покупок, как правило с небольшим количеством товара.
Система с ручными сканерами и КСО у нас представлена в «Перекрестках», где как правило корзина покупок очень большая.
В «Пятёрочках» с помощью таких касс можно очень быстро оплатить 3-5 товаров, сканер для этого не особо нужен.
Пока в Екатеринбурге именно таких касс нет, но мы работаем над этим)
Воровство под контролем.
Будем развивать этот проект, чтобы такие кассы появлялись во многих «Пятёрочках».
Тестирование проходит две недели,
за этот период может выполняться несколько итераций восстановления исходной системы, накатки обновлений и сравнения с эталоном.
Обновления устанавливаются только раз в месяц.
Межрасчетные выплаты это частный случай регулярного расчета и тестируются они точно так же.
Он подключен по Bluetooth к ТСД на Android, который воспринимает его как устройство ввода.
Приложение для складских рабочих: приложение на Android. В котором в webView крутится одностраничное веб-приложение на knockout.js и jQuery, которое по api стучится в WMS.
проблему с выключением фонового отслеживания GPS не требовалось решать для этой платформы.
Вопрос потребления энергии решается повышенной емкостью батарей устройств и доступности зарядки в автомобиле :)
Что же касается нашего приложения для клиентов, где можно заказать товары, то оно написано под две платформы.
Приложения для внутреннего использования обновляются через собственный сервис, есть идеи посмотреть в сторону Android Enterprise для этого.
Номер телефона прячется посредством вызова через дополнительный сервис.
Сначала был обычный телефонный вызов на общий номер КЦ в котором через DTMF передавался айди, и дальше станция набирала номер клиента,
затем перешли к схеме с вызовом через дополнительный сервис, т.е. после нажатия кнопки связи с клиентом в приложении, отправляется REST запрос на сервис,
затем этот сервис совершает два исходящих звонка на номер курьера и клиента.
2. При отборе сотрудник не сканирует ячейку, т.к. мы резервируем товар в конкретной ячейке и формируем задание на отбор из этой ячейки. Сотрудник выполняющий задание может отобрать товар из той ячейки где он зарезервирован либо отправить его в брак или утерю. В этом случае проблемы с остатками нет. Т.к. у ячеек нет физических границ товар может оказаться в соседней ячейке, но это не вызывает проблем у склада.
Практически 100% восстановление работоспособности магазина при неудачном обновлении, позволяет нам не учитывать количество магазинов в конкретном населенном пункте. “На всякий случай”, мы обновляем половину касс в магазинах, на стадии пилота новой версии ПО, особенно в его первой фазе. Это позволяет нам исключить остановку продаж, в случае форс мажорных ситуаций.
Суть статьи сводится к описанию кардинального увеличения скорости и безопасности распространения релизов торгового ПО путем автоматизации этапов работ, оптимизации и изменения технических и организационных процессов.
С точки зрения архитектуры, используется клиент-серверная схема взаимодействия кассы и локального сервера в магазине.
Прорыв, необходимый компании – это трехсоткратное увеличение количества объектов, в отношении которых возможно безопасное обновление силами 1 сотрудника.
Товары заводим для X5, но пилот с Марсом проводил Перекресток, поэтому информация только по этой сети.
В «Пятёрочках» с помощью таких касс можно очень быстро оплатить 3-5 товаров, сканер для этого не особо нужен.
Воровство под контролем.
Будем развивать этот проект, чтобы такие кассы появлялись во многих «Пятёрочках».
за этот период может выполняться несколько итераций восстановления исходной системы, накатки обновлений и сравнения с эталоном.
Обновления устанавливаются только раз в месяц.
Межрасчетные выплаты это частный случай регулярного расчета и тестируются они точно так же.