Терминал сбора данных в телефоне кладовщика: веб-ТСД для склада на 1С
Веб-ТСД на обычном смартфоне: сканирование камерой, пять складских процессов и интеграция с 1С без изменения её интерфейса. Как очередь и локальные копии документов позволяют кладовщику работать, пока 1С отвечает с задержкой.
Мы сделали складское приложение, которое открывается в браузере обычного смартфона и
заменяет терминал сбора данных. Кладовщик сканирует штрихкоды камерой телефона или Bluetooth сканером,
а приложение работает с учётной системой клиента на 1С. Главное требование было такое:
работа система должна работать быстро, даже когда 1С отвечает по 20–30 секунд.
Главное меню. Кладовщик вошёл по бейджу, склад выбран, пять процессов крупными плитками.
Задача
Склады клиента ведут учёт в 1С. Старый ТСД был написан внутри самой 1С и имел ряд
проблем.
Он работал только на основном складе. Раскатать его на остальные без переделки было
нельзя.
Он был медленным. Каждое действие кладовщика ждало ответа 1С, до 60 секунд, и всё
это время экран терминала был заблокирован. В часы нагрузки люди больше ждали, чем
работали.
Он требовал специальных терминалов и обучения. Заказчик хотел, чтобы новый сотрудник
начинал работать со своего телефона в первый же день.
При этом оригинальную систему, которая работала на основном РЦ заказчика было нельзя. Мы получили 28 HTTP-методов «как есть».
Какие запросы они принимают, мы восстановили по исходному коду старого модуля. Что они
отвечают, не было записано нигде, поэтому форму ответов пришлось снимать с живой базы.
Решение
Между телефоном и 1С мы поставили сервер-посредник. Он берёт скорость и надёжность на
себя, а 1С остаётся главной учётной системой.
Телефон (PWA): камера и интерфейс кладовщика.
Посредник (Django + PostgreSQL): копии документов, очередь и сверка.
1С: 28 методов «как есть».
Быстро, даже когда 1С медленная
Мгновенный ответ телефону. Кладовщик сканирует товар, посредник записывает действие
у себя и сразу отвечает телефону. Это занимает миллисекунды. Отдельный процесс в фоне
доставляет действие в 1С и повторяет попытку, если что-то пошло не так. Действие и
задание на отправку сохраняются в базу одной транзакцией, поэтому ситуация «данные
записались, а отправка потерялась» исключена самим устройством системы.
Копии документов под рукой. Состав документа хранится у посредника, и телефон
получает его без обращения к 1С. После каждой синхронизации 1С перезаписывает копию.
Если 1С что-то изменила сама, кладовщик видит пометку «состав обновлён».
Пачки вместо потока запросов. Всё, что кладовщик подряд положил в одну ячейку,
уходит в 1С одним документом, а не отдельным запросом на каждый скан. Первые 10 секунд
пачку можно отменить или дополнить. Это разгружает 1С и даёт человеку исправить ошибку.
Размещение. Кладовщик положил товар, и у него есть 10 секунд, чтобы отменить укладку. Внизу пачка «Ждёт отправки», в шапке счётчик очереди в 1С.
Штрихкоды запоминаются. Выгрузить весь справочник штрихкодов из 1С нельзя, поэтому
посредник запоминает каждый распознанный код. Незнакомый код стоит одного медленного
запроса, а все следующие сканы того же кода читаются из базы. Пока код распознаётся,
работа не стоит: строка появляется сразу и дозаполняется сама.
«Информация»: один скан показывает товар, его упаковку и все ячейки с остатками.
Надёжно, даже когда связь рвётся
Самое опасное в работе с учётной системой — дубли. Методы 1С, которые создают документы,
нельзя безопасно повторять: повторный запрос создаёт второй документ. Если ответ 1С
потерялся, приложение не отправляет запрос вслепую ещё раз. Сначала оно спрашивает у
1С, что получилось на самом деле:
нашло созданный документ — продолжает работу с ним;
не нашло — делает один повтор;
не смогло определить — откладывает задачу и показывает её старшему смены.
Чтобы проверить всё это до выхода на склад, мы написали эмулятор 1С. Он реализует
все 28 методов и умеет намеренно портить обмен: отвечать с задержкой 25 секунд, падать
на треть запросов, «терять» ответы после успешной записи и менять состав документа
втихую. На нём работают сквозные тесты. Они проверяют не ответы сервера, а итог на
складе: товар лёг в нужную ячейку ровно один раз, а потерянный ответ не привёл ни к
двойной проводке, ни к дублю документа.
Удобно для людей на складе
Вход — скан бейджа. Нет паролей и списков сотрудников.
Сканер — камера телефона. Используется встроенное в браузер распознавание, а где
его нет, подключается запасной движок. Код засчитывается, только когда два кадра
прочитали его одинаково. Мы добавили эту проверку после реального случая: EAN-13
прочитался с ошибкой, а контрольная сумма при этом сошлась.
Крупные кнопки под перчатки. Кнопки не меньше 56 px, а цвета и звуки успеха и
ошибки такие же, как в старом терминале, поэтому переучиваться не нужно.
Сначала кнопки, потом камера. Списки и карточки товаров работают без камеры.
Камера включается только там, где на экране есть сканер, и отключается, когда
приложение свёрнуто. Так телефон меньше разряжается за смену.
Приёмка: нажмите на товар, чтобы взять.Раскладка: приложение подсказывает, где такой товар уже лежит.
Работает на iPhone и Android. Мы отдельно разобрались с многокамерными
Android-смартфонами: там браузер иногда выбирает вспомогательную камеру, которая
показывает чёрный экран.
Что умеет приложение
Процесс
Что делает кладовщик
Информация
Сканирует товар или ячейку и видит остатки и места хранения
Размещение
Раскладывает товар из приёмки по ячейкам и видит подсказку, где такой товар уже лежит
Перемещение
Собирает товар из разных ячеек и раскладывает по другим, всё одним документом
Пересчёт
Считает ячейку вслепую по скану и получает итог с расхождениями
Отбор
Собирает оптовые заказы по штрихкоду ордера и розничные по дню отгрузки, идёт по маршруту через ячейки
Отбор
Задание на день: маршрут по ячейкам сверху вниз.Одна позиция на экран: ячейка, количество, большая кнопка.Взятое сразу уходит в 1С, зелёная метка «В 1С» подтверждает запись.
Перемещение и пересчёт
Перемещение: забираю из одних ячеек, кладу в другие. Внизу история действий.Пересчёт вслепую: кладовщик считает, не видя остатка 1С, и в конце получает расхождения.
Как мы запускали на живой базе
Боевую учётную систему легко испортить, поэтому мы запускали приложение по шагам:
Только чтение. Первый режим подключения к живой 1С физически не умеет в неё
писать. Изменения копятся в очереди и никуда не уходят. Отдельная проверка измеряет
реальные задержки 1С и то, как разбираются ответы.
Запись на одном складе. Каждый пишущий процесс мы сначала проверяли на тестовом
складе, отдельным экспериментом, согласованным с клиентом.
Флаги по процессам и доступ по складам. Запись в 1С включается отдельно для
каждого процесса. Каждый сотрудник видит только те склады, которые ему открыли в
админке.
Полные логи. Каждый запрос с телефона и каждый обмен с 1С записываются вместе с
содержимым (пароли скрыты) и связываются общим идентификатором. Когда на складе
что-то пошло не так, мы видим всю цепочку от нажатия кнопки до ответа 1С.
Дополнительный результат: аудит интеграции с 1С
Пока мы разбирали протокол, мы нашли в HTTP-сервисе 1С девять дефектов. Среди них метод,
который падает ровно тогда, когда он нужен, фильтры, которые ничего не фильтруют,
разные единицы количества в опте и рознице, а также проводки, которые уводят остатки
ячейки в минус. Приложение обходит каждый дефект у себя, а для программиста 1С мы
составили список с живыми примерами, чтобы исправить их у источника.
В цифрах
28 методов 1С описаны и покрыты эмулятором
5 складских процессов
~19 000 строк кода, 130+ автотестов
2 недели от первого коммита до работающего отбора, перемещения и размещения
0 изменений на стороне 1С, которые потребовались для запуска
Хотите так же? Мы делаем мобильные и веб-интерфейсы поверх существующих учётных систем,
не переписывая их. Обсудить проект
