Концептуальный проект интеграции по заказам

Назначение документа

Определить общие принципы построения и архитектуру (состав и схему взаимодействия компонент) интеграции Домино8 и Сбермаркет (СМ) по заказам. Для каждой компоненты описывается её функционал, критические требования, основные алгоритмы работы и схемы взаимодействия с другими компонентами.

Оценить объём работ и затраты.

Последние варианты описаний:

Интеграция Домино со Сбермаркет по заказам (1.6).doc

Инфраструктра. Развертывание и обновлениен.doc

Сборка заказов СМ. Web-сервис обработки уведомлений по заказам. Спецификация и ТЗ (1.0).doc

Сборка заказов СМ. Web-сервис сборки заказов. Спецификация и ТЗ (1.0).doc

 

Схема интеграции

Интеграция Домино со Сбермаркет (СМ) разрабатывается для модели «Сборка продавца, доставка СМ». Самовывоз покупателя из магазина, а так же доставка заказа силами продавца не предполагается.

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

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

Клиентское Домино в магазине запускается для обработки заказов. Пользователь видит привычный интерфейс и возможности Домино, но при этом работает не с данными БД магазина, а с данными в ЦБД через http-запросы к web-сервисам.

Такая схема позволяет:

  1. Значительно упростить будущий переход от распределённой базы данных к централизованной БД.
  2. Будущее применение мобильного приложения для сборки заказа не потребует изменения протокола взаимодействия с web-сервисом.
  3. Время передачи данных почтовой службой Домино не является критичной величиной, поскольку вся важная для заказов информация передаётся по интернету в реальном времени.
  4. Обеспечивается наличие в ЦБД актуальной информации по заказу, синхронизированной с СМ и магазинами. (Если бы магазин самостоятельно отправлял сообщения в СМ, то пришлось бы отправлять копию этого сообщения в ЦБД. В таком случае появляется потенциальная ошибка рассинхронизации данных в ЦБД и СМ. Если какое-то из сообщений не было бы доставлено вовремя и уже пришло следующее сообщение, то запоздавшее сообщение может быть обработано неверно.)

Почтовый обмен между ЦБД и базами магазинов передаёт заказы только в одном направлении – из ЦБД в БД магазина. Заказы передаются акцептованными для того, чтобы списать товар с остатков. Скорость доставки почты особого значения не имеет.

Для информирования сотрудников  о событиях, возникающих в процессе работы с заказами СМ, предлагается использовать мессенжер Телеграмм.

image-1691664311380.png

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

 

Составные части интеграции

Для интеграции потребуется разработать 8 компонент и настроить ещё одну.

Выделяются пять независимых сервисов, работающих с ЦБД:

  1. Обработчик уведомлений, приходящих от СМ. Реализуется как web-сервис Домино (хук).
  2. Обработчик запросов, поступающих от клиентских приложений Домино (сборка заказа). Реализуется как web-сервис Домино.
  3. Сервис мониторинга состояния заказов. Контролирует качество процессов и работоспособность других компонентов системы. Выделяется в отдельный сервис, чтобы его производительность и работоспособность не влияла на работу остальных сервисов. Реализуется через планировщик Домино.
  4. Сервис отправки уведомлений через телеграмм. Реализуется через планировщик Домино аналогично сервису мониторинга.
  5. Сервис формирования документов реализации по отгруженным заказам СМ. Реализуется через планировщик Домино аналогично сервису мониторинга.

Все сервисы должны работать с данными БД Домино от имени специальных (отдельных) пользователей, чтобы их следы были хорошо различимы в системных протоколах.

Обмен сообщениями со Сбермаркетом осуществляется с использованием OrderAPI. Описание API размещено на сайте СМ https://docs.sbermarket.ru/api-products/other/orders/description

Отдельная компонента запускается в магазине и применяется для сборки заказов. В будущем она может быть заменена на приложение на мобильном устройстве.

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

image-1691665627371.png

И последняя компонента для интеграции - это web-сервер NGINX.

NGINX предполагается использовать для обеспечения безопасности в качестве единой точки доступа. 

На web-сервер NGINX возлагаются следующие задачи:

 

Модель данных Домино для интеграции

Для хранения заказов СберМаркета вводится документ специального типа «Заказ СМ». Товарная часть заказа сохраняется в виде строк этого документа. Заказ СМ не является расходным товарным документом - для списания товара с остатков магазина формируется отдельный документа расхода (реализации) по заказу.

Номер документа заказа совпадает с номером заказа СМ. Использование собственной внутренней нумерации заказов не предполагается.

 Подразделение документа заказа - структурное подразделение торговой точки, на которую назначен заказ.

 Контрагент документа заказа – заполняется специальным партнёром «Сбермаркет».

Параметр «Состояние документа» отражает этапы работы с документом заказа. Возможные значения:

Параметр «Состояние оплаты» означает, что от СМ поступило уведомление (хук) о финализации состава заказа и цен. Возможные значения:

Параметр «Состояние отгрузки» отражает факт расхода товаров из магазина. Возможные значения:

Все даты (со временем), отражающие изменения статусов документа, сохраняются в шапке документа. К ним относятся: дата поступления заказа, начала сборки, завершения сборки, передачи курьеру, отмены/доставки. Все эти даты можно получить из протокола, но хранение их в документе упрощает алгоритмы обработки и анализа.

При создании заказа все атрибуты, которые СМ передаёт в шапке заказа и в строках, переносятся в документ заказа «как есть», без исключений (если иное не описано явно). После этого разрешаются ссылки на объекты Домино (партнеры и товары).

В процессе сборки коды маркировки товара сохраняются в строках, дочерних к соответствующей товарной строке.

Признак акцепта устанавливается на документ заказа при установке статусов «передан курьеру», «доставлен» или «отменен».

Акцепт документа не списывает остатки и не приводит к автоматическому формированию документа реализации.  Реализация формируется отдельным сервисом, если определена дата передачи товара курьеру (товар фактически отгружен). 

Строки заказа СМ

Следует учитывать тот факт, что в заказе СМ нет нумерации строк и идентификация строки при необходимости выполняется по коду товара. Поэтому не может быть двух строк с одинаковым товаром. В строке заказа сохраняются 3 количества:

Эти три количества являются ключевыми для процесса сборки заказа.

 Протоколирование событий

Все входящие уведомления от СМ (хуки) и все исходящие уведомления (нотификации) сохраняются в виде записей Протокола специального класса-типа. Записи протокола привязываются к конкретному документу заказа. Так же в протоколе сохраняются все телеграмм-уведомления по документу.

Действия при сборке «по умолчанию»

В шапке заказа СМ покупатель указывает, каким образом сборщик должен отрабатывать ситуации с отсутствием или недостаточным количеством товара (в терминах СМ это называется «политика отмен/замен товаров»).

Возможные варианты

 «Отмена позиции» - действие, которое выполняется по согласованию с покупателем в том случае, если указанный в заказе товар отсутствует полностью или частично. При отмене в строке заказа изменяется «Согласованное количество», что позволяет завершить сборку заказа с собранным количеством в строке меньше заказанного. Отмена может быть согласована покупателем как в момент формирования заказа на сайте СМ, так и непосредственно в процессе сборки по телефону.

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

 «Изменение/добавление позиции»

СМ допускает произвольное изменение количества, добавление и удаление позиций заказа в процессе сборки (по согласованию с клиентом). Для всех таких позиций должно быть указано новое «Согласованное количество».

Изменение состава заказа со стороны СМ

До того момента, пока заказ не поступил в сборку, покупатель может через сайт СМ изменить его состав. При этом СМ направляет специальное уведомление об изменении состава заказа, которое аналогично по своему содержимому уведомлению о создании нового заказа. Данная возможность является экспериментальной в СМ, её поддержка не обязательна, но желательна.

«Магазин». Обязательная сущность, структурное подразделение в Домино. Точка сборки и передачи заказов курьерам СМ. Регистрируется в СМ как Магазин (store). В карточке Магазина может быть указан телефон для отправки телеграмм-уведомлений (рекомендуется, необходимо для сборки заказов без назначения сборщика).

 «Сборщик». Не обязательная сущность, позволяет персонифицировать процесс сборки заказа и получение телеграмм-уведомлений. Так же позволяет строить отчёты в разрезе сборщиков и анализировать эффективность их работы. Альтернатива - сборка заказа магазином без персонификации. «Сборщик» - это Сотрудник (в терминах Домино). Сборщик работает сменами, смена привязывает сборщика к конкретному магазину на определённый промежуток времени. Продолжительность смены не может быть больше 24 часов. В течении смены сборщик получает телеграмм-уведомления о поступлении новых заказов СМ и может брать заказы в сборку. Сборщик прописывается в шапку документа заказа. Сборщик не может завершить смену, пока у него есть несобранные заказы, они должны быть собраны либо переданы другому сборщику.

 «Управление сменами сборщиков». Специальный документ, в котором регистрируются все открытые за конкретный день смены. Создаётся автоматически на организацию в целом, на конкретный день (сутки), смены регистрируются строками документа. Управляется через web-запросы к сервису сборки заказов.

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

 «Администратор заказов СМ» - сотрудник, который отвечает за мониторинг всего процесса взаимодействия с СМ, включая технические аспекты. Администратор получает телеграмм-уведомления обо всех особых ситуациях. Администратор имеет прямой доступ к документам Заказов СМ и может вносить в них изменения. Администраторов может быть несколько, они все имеют доступ к единому массиву уведомлений (организуется в виде группы в телеграмм, в котором могут оставлять сообщения как Администраторы, так и информационный бот.

 

Web-сервис обработки уведомлений по заказам СМ

Этот web-сервис предназначен для обработки уведомлений, которые СМ отправляет в ИС партнёра (Домино), с помощью которых передаётся информация о создании, изменении состояния и отмене заказа со стороны СМ. Сервис реализуется в виде Домино web-сервера, при необходимости масштабирования (при увеличении нагрузки) может быть развернут пул из нескольких однородных web-серверов с балансировкой нагрузки через nginx proxy.

Сервис обрабатывает следующие запросы СМ

  1. Создание заказа (order.created). Создаёт документ заказа в БД Домино. Создаёт телеграмм-уведомление для сборщиков и магазина о появлении нового заказа.
  2. Изменение заказа (order.changed). Анализирует изменения, вносит их в документ заказа. Создаёт телеграмм-уведомление для сборщиков и магазина об изменении состава заказа.
  3. Оплата заказа (order.paid). Корректирует цены заказа, закрывает заказ от изменений.
  4. Передача заказа курьеру (order.received). Закрывает заказ от изменений, помечает заказ как отгруженный (остатки списываются с баланса магазина).
  5. Доставка заказа (order.delivered). Закрывает заказ от изменений, помечает заказ как отгруженный (если пока нет этого статуса) и доставленный.
  6. Отмена заказа (order.cancelled). Закрывает заказ от изменений, помечает заказ как отменённый. Создаёт телеграмм-уведомление для сборщиков и магазина об отмене заказа, если заказ ещё не передан курьеру (не отгружен)

При обработке хуков СМ нужно учитывать специфические особенности протокола СМ. Тайм-аут на ответ составляет 5 секунд. Если в течении этого времени не будет ответа или вернётся статус 4хх или 5хх, то у СМ начнут отрабатывать ретраи – сообщение будет отправляться повторно 7 раз с увеличивающимся интервалом. Если и это не поможет (для хука order.created), то система автоматически отменит заказ. Таким образом, может возникнуть ситуация, когда заказ в Домино создан, но СМ не дождался подтверждения и повторно отправил заказ. Web- сервис должен распознать эту ситуацию, и отправить СМ положительный ответ по уже созданному с Домино заказу, а не пытаться создать новый.

 

Web-сервис для сборки заказов СМ

Назначение этого web- сервиса - обработка запросов от приложений сборки заказов СМ, изменение состояний заказа и отправка уведомлений (нотификаций) в СМ. В качестве приложения для сборки заказа может выступать как Домино, так и отдельное приложение (в том числе на мобильном устройстве), которое поддерживает протокол обмена с сервисом сборки заказов. Сервис реализуется в виде Домино web-сервера, при необходимости масштабирования при увеличении нагрузки может быть развернут пул из нескольких однородных web-серверов с балансировкой нагрузки через nginx.

Обрабатывает следующие запросы:

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

 

Сервисы мониторинга заказов и отправки уведомлений

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

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

Каждый Магазин использует отдельный групповой чат, к которому подключаются сотрудники магазина, занятые в сборке заказов СМ. Телеграмм-бот отправляет в этот чат уведомления по заказам, относящимся к конкретному магазину. Через этот чат организуется процесс сборки заказов, на которые не назначен конкретный сборщик (сборка магазином).

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

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

За передачу сообщений в телеграмм-боты отвечает специальный сервис – сервис отправки уведомлений.

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

Качество процесса обработки заказов СМ на основании метрик контролирует сервис контроля заказов.

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

Метрики качества обработки заказа:

 

Сервис формирования реализации по заказам СМ

Формирует документы реализации по отработанным (доставленным) заказам СМ. Реализуется в виде процедуры планировщика, которая запускается каждый час. Реализация может формироваться как отдельным расходным документом по каждому заказу,  так и сводным расходом за день по магазину.

 

Модуль сборки заказов в Домино

Модуль сборки заказов предназначен для реализации процесса «Сборка заказа Магазином», когда сборщик работает с распечатанной копией заказа. Согласование изменений с клиентом производится по телефону, который указан в заказе. По окончании сборки отобранный товар перемещается к рабочему месту оператора, где регистрируется с использованием сканера. Назначение сборщика на заказ в этом случае возможно, но не обязательно.

Модуль сборки заказов в магазине реализуется как обычное приложение Домино. Особенностью модуля является то, что он работает с заказами только через http-запросы к web-сервису сборки заказов, то есть выполняет роль web-клиента. При этом пользователи получают привычный интерфейс и возможности Домино.

Модуль сборки заказов предоставляет пользователю следующие интерфейсы:

  1. Список активных заказов магазина с их статусами. В этом интерфейсе возможно:
  1. Заказ (шапка и строки). В этом интерфейсе возможно:
  1. Управление сменами сборщиков. В этом интерфейсе возможно:

На основе этого модуля может быть разработан его упрощённый вариант для запуска в rdp сессии на мобильном устройстве - мобильное приложение сборщика. В этом случае сборка заказа будет происходить онлайн без использования бумажных документов, то есть будет реализован процесс «Сборка заказа Сборщиком»

Сборка заказа

Процесс сборки и регистрации собранных товаров (SKU) в заказе имеет множество особенностей. Товары бывают штучные и весовые, с заводской маркировкой, маркировкой магазина и без неё, маркированные кодами маркировки ЧЗ. В процессе сборки с покупателем может быть согласована замена позиции, в том числе и частичная, а также изменение количества (веса) в определённых границах. Принципы идентификации товара, которые используются при сборке заказа, во многом аналогичны тем, которые используются в торговой кассе RETAIL-POS. Все операции по сборке выполняются из интерфейса «Заказ (шапка и строки)».

Сборка штучного товара, имеющего заводской ШК либо ШК магазина (EAN). Коды магазина могут быть как нанесены на товар, так и считываться из альбома. Оператор считывает ШК сканером, отправляется web-запрос collectPosition с указанным кодом. Процедура метода collectPosition распознает переданный ШК и определяет товар. Если товар подлежит обязательной маркировке, то возвращается ошибка «Требуется сканировать код маркировки». Далее программа пытается найти строку с этим товаром и, если находит, то увеличивает количество на единицу и возвращает обновлённый заказ. Если строка заказа с этим товаром уже собрана (собрано столько, сколько согласовано), то возвращает ошибку «Товар уже собран в нужном количестве»

Сборка штучного товара, подлежащего обязательной маркировке. Оператор считывает КМ сканером, отправляется web-запрос collectPosition с указанным кодом маркировки. Процедура метода collectPosition распознает переданный код маркировки и определяет по нему товар. Переданный код маркировки проверяется на уникальность в пределах заказа. В случае повтора возвращается ошибка «Этот код маркировки уже добавлен в заказ». Далее алгоритм подбора строки и увеличения количества идентичен обычному товару. Переданный код маркировки сохраняется в строке, дочерней к товарной строке заказа.

Торговля алкоголем, меховыми и ювелирными изделиями не предполагается. Коды маркировки товаров из данных групп не содержат в своем составе gtin товара. Для преодоления данного ограничения потребуется решить задачу связи марки с идентификатором товара.

Сборка штучного товара в групповой потребительской упаковке. Используется регистрации упаковок из нескольких одинаковых товаров, упаковка должна иметь собственный штриховой код (или код маркировки для маркированных товаров). Оператор считывает ШК или КМ с упаковки сканером, отправляется web-запрос collectPosition с указанным кодом. Процедура метода collectPosition распознает переданный код и определяет по нему товар и количество товара в упаковке. Далее алгоритм подбора строки и увеличения количества идентичен соответствующим алгоритмам для единицы товара.

Сборка штучного товара с прямым указанием количества. Применяется для товаров без маркировки, не рекомендованный к использованию метод. Вместо этого метода для регистрации подобных товаров рекомендуется сканирование кодов из альбома. Оператор находит нужный товар (строку) в заказе, после чего выбирает действие «Собрать». Вводит количество собранных единиц, отправляется web-запрос collectPosition с указанным номером строки заказа и количеством. Процедура метода collectPosition проверяет, чтобы собранное количество не превысило согласованное, если проверка пройдена, то собранное количество увеличивается и метод возвращает обновлённый состав заказа. Этот метод применим для любой строки заказа, содержащей товар, не подлежащий обязательной маркировке.

Сборка весового товара с предварительным взвешиванием и маркировкой. Используется, если в торговом зале есть весы с печатью этикеток. Сборщик собирает нужный товар и взвешивает его как обычный покупатель. Этикетка с весовым ШК наклеивается на товар (или упаковку). Оператор считывает ШК сканером, отправляется web-запрос collectPosition с указанным кодом. Процедура метода collectPosition распознает переданный ШК, определяет товар и вес. Далее система пытается найти строку с этим товаром, если находит, то увеличивает вес и возвращает обновлённый заказ. Если строки заказа с этим товаром уже собрана, то возвращает ошибку «Товар уже собран в нужном количестве». При подборе строки заказа по весу нужно учитывать, что отклонение в весе до 10% считается допустимым без отдельного согласования с покупателем. По этой же схеме происходит сборка фасованного весового товара, товар может фасоваться и маркироваться весовыми ШК как изготовителем, так и магазином.

Сборка весового товара с прямым указанием веса. Используется при отсутствии весов с печатью этикеток. Сборщик собирает нужный товар, и взвешивает его на обычных весах. Получившийся вес он пишет маркером прямо на пакете или в бланке заказа. Оператор находит нужный товар (строку) в заказе, после чего выбирает действие «Собрать». Вводит собранный вес, отправляется web-запрос collectPosition с указанным номером строки заказа и весом. Процедура метода collectPosition проверяет, чтобы собранный вес не превысил согласованный более чем на 10%, если проверка пройдена, то собранный вес увеличивается и метод возвращает обновлённый состав заказа.

Сборка весового товара по коду маркировки, содержащему вес. Используется для товаров, подлежащих обязательной маркировке в том случае, когда товар расфасован изготовителем в потребительскую упаковку с индивидуальным кодом маркировки, и этот код маркировки содержит вес в теге 310. Оператор считывает КМ сканером, отправляется web-запрос collectPosition с указанным кодом маркировки. Процедура метода collectPosition распознает переданный код маркировки и определяет по нему товар и вес. Переданный код маркировки проверяется на уникальность в пределах заказа. В случае повтора возвращается ошибка «Этот код маркировки уже добавлен в заказ». Далее алгоритм подбора строки и увеличения веса идентичен обычному весовому товару. Переданный код маркировки сохраняется в строке, дочерней к товарной строке заказа.

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

Оформление замены. Если заказанного товара не оказалось в наличии, то сборщик может согласовать с покупателем замену. Заменена может быть как вся позиция целиком (собранное количество 0), так и часть позиции. Заменяющий товар может быть как один, так и несколько разных. Количество/вес заменяющих товаров не контролируются, так как речь может идти о товаре в разной фасовке. Можно заменять весовой товар штучным и наоборот. Можно заменять товар, подлежащий маркировке обычным товаром и наоборот. Если сборщик согласует замену, то он делает отметку об этом в бланке заказа, указывая новое согласованное количество (или полный вычерк) для заменяемого товара и заменяющий товар. Оператор для оформления замены выбирает нужную строку заказа, и вызывает действие «Замена». После этого оператор сканирует штрих-код/код маркировки товара-замены. Отправляется web-запрос collectPosition с кодом заменяемого товара, признаком замены, и штрих-кодом заменяющего товара. Процедура метода collectPosition проверяет, чтобы заменяющий товар был в ассортименте СМ. Если заменяющего товара нет в заказе, то в заказ добавляется новая строка. Согласованное количество для заменяемого и заменяющего товаров корректируется. Далее алгоритмы обработки идентичны обычным товарам.

Так как сборщик в зале работает оффлайн, то для предложения замены ему будет нужна информация, какой товар входит в ассортимент СМ, а какой нет. Одна из возможностей сделать это – выводить на ценники товара специальную отметку «Можно заказать через СберМаркет».

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

Замечание: алгоритм идентичен операции «Отмена».

Добавление произвольного товара. Сборщик может согласовать с покупателем добавление в заказ любого товара из ассортимента СМ. Сборщик делает отметку об этом в бланке заказа, указывая товар и согласованное количество. Оператор для оформления вызывает действие «Добавить новый товар». Система предлагает указать ШК/Код маркировки нового товара и новое согласованное количество. Отправляется web-запрос collectPosition с ШК товара и согласованным количеством. Система проверяет, чтобы этого товара не было в заказе. В заказ добавляется с указанным товаром и согласованным количеством. Далее алгоритм идентичен сборке товара, который есть в заказе.

Завершение сборки. По окончании сборки заказ должен быть переведён в состояние «Собран». Программа не позволит завершить сборку заказа, если в нем есть расхождения между согласованным и собранным количеством.

Для весового товара отклонение собранного веса в пределах 10% не считается расхождением.

 

Отчёты по заказам СМ

Отчеты по заказам СМ доступны пользователям с правами «Менеджер заказов СМ» и «Администратор заказов СМ». В ЦБД можно получить отчеты по любому из магазинов сети, по группе магазинов и сводный отчёт по всем магазинам. В магазине можно получить отчёты только по заказам этого магазина.

Отчет по заказам СМ (финансовые результаты) позволяет анализировать финансовые показатели процесса за период. В отчете учитываются данные по заказам СМ, которые были доставлены покупателю. Так же отдельными строками отображаются данные по заказам, которые были переданы курьерам, но не доставлены (отменены или не получено уведомление о доставке). Отчет может быть построен по магазину, группе магазинов или сети в целом (всем магазинам). Стандартно отчет детализируется до магазина и дня, при необходимости возможна детализация отчета до заказа. В отчет так же включаются итоги по уровням группировки, а так же общий итог.

В отчете рассчитываются следующие показатели:

Отчёт по заказам СМ (статистика выполнения и метрики) – комплексный отчет, позволяющий оценить качество процесса. Отчет рассчитывается за период по магазину, группе магазинов или сети в целом. В отчет включаются все заказы СМ, независимо от их статуса.

В отчете рассчитываются следующие показатели (как отдельные разделы):

  1. Количество заказов по периодам (день, неделя, месяц). За каждый период рассчитываются:
    1. количество поступивших и отмененных заказов,
    2. сумма и прибыль по заказу (80% квантиль от-до),
    3. время взятия в сборку (80% квантиль от-до и максимальное),
    4. время сборки (80% квантиль от-до и максимальное),
    5. %заказов, собранных к сроку,
    6. %заказов с заменами и вычерками,
    7. %замененных позиций и %вычеркнутых позиций,
    8. время ожидания курьера (80% квантиль от-до и максимальное).
  2. Статистика по сборщикам. Для каждого сборщика рассчитываются:
    1. количество отработанных смен,
    2. их суммарная продолжительность,
    3. общее количество собранных заказов,
    4. суммарное время, потраченное на сборку,
    5. время взятия в сборку (80% квантиль от-до и максимальное),
    6. время сборки (80% квантиль от-до и максимальное),
    7. %заказов, собранных к сроку,
    8. %заказов с заменами и вычерками,
    9. %замененных позиций и %вычеркнутых позиций.
  3. Статистика по отменам заказов. Учитываются все заказы в статусе «Отменен» за период. Показывается:
    1. общее количество заказов за период,
    2. количество и процент отмен всего,
    3. количество отмен и доля по каждой причине в отдельности (сортировка причин по убыванию количества отмен).
  4. Сто самых популярных товаров. Для каждого магазина или сети в целом отображаются 100 товаров, которые заказывали чаще всего. По каждому товару показываются:
    1. количество заказов, в которых был заказан этот товар,
    2. количество заказанного товара и процент от общего количества заказов, в которых присутствовал этот товар.
    3. процент исполнения заказов по этому товару, т.е. отношение количества поставленного товара к количеству заказанного.
  5. Сто самых маржинальных товаров. Для каждого магазина или сети в целом отображаются 100 товаров, которые принесли наибольшую прибыль. По каждому товару показываются:
    1. количество заказов, в которых был заказан этот товар,
    2. количество заказанного и поставленного товара,
    3. общая сумма выручки и прибыль.
    4. процент исполнения заказов по этому товару.
  6. Сто самых дефицитных товаров. Для каждого магазина или сети в целом отображаются 100 товаров, по которым было больше всего замен. По каждому товару показываюся:
    1. количество заказов, в которых был заказан этот товар,
    2. количество заказанного товара
    3. количество раз, когда этот товар фактически отсутствовал и был заменён или вычеркнут.

 

Административные функции для работы с заказами СМ

Пользователь с правами «Менеджер заказов СМ» может

Пользователь с правами «Администратор заказов СМ» может