Перейти к содержимому

Как это происходит по шагам

Проверено: v2026.09 · 2026-09-06

На этой странице каждая картинка — это история из нескольких шагов: кто кого позвал и что от этого изменилось. Переключатель в углу диаграммы показывает ту же историю как схему или как список шагов сверху вниз. Шаги названы теми же словами, что и вызовы в коде, поэтому по ним можно найти нужное место в API.

Учётная система клиента присылает заявку; PickUpper проверяет строки, находит координаты адреса и отвечает номером заявки. Повторная отправка той же заявки обновляет её, а не создаёт дубль.

Интеграционный API → OrderIntake → Geocoding → ответ ERP.

Диспетчер отправляет заявки «в планирование» и запускает задание за день. Система берёт водителей со сменами, машины с отсеками, зоны и навыки, считает расстояния и решает задачу маршрутизации. Что не встало — объясняется по каждой паре «заявка × машина».

Planning собирает исходные данные, решает VRP и публикует рейсы.

Действия в приложении сохраняются на телефоне и досылаются, когда появляется связь. Если за это время диспетчер изменил тот же стоп, действие попадает в список конфликтов, а не теряется.

Офлайн-очередь и досылка с проверкой конфликтов.

Частичная доставка, отказ или утеря фиксируются по каждой позиции. Возвращённый товар получает возвратный стоп на склад-источник, а ERP видит итог по заявке.

Исходы по позициям → возвратный стоп → статус заявки в ERP.

Приглашение сразу создаёт отключённую учётную запись в Keycloak, привязанную к компании и роли. Ссылка из приглашения одноразовая: по ней человек задаёт пароль и учётка включается.

Tenants ↔ Keycloak: учётка создаётся отключённой, включается при установке пароля.

Через 90 дней после архивации и выгрузки данных система удаляет учётные записи людей в Keycloak и только потом стирает данные компании. Если Keycloak недоступен, удаление откладывается до следующей попытки — чтобы не потерять список того, что надо удалить.

Сначала идентичности, потом данные; при недоступном Keycloak — перенос.