Обмен с интернет-магазином СберМаркет

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

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

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

Определить общие принципы построения и архитектуру (состав и схему взаимодействия компонент) интеграции Домино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. количество раз, когда этот товар фактически отсутствовал и был заменён или вычеркнут.

 

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

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

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

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

Инфраструктура интеграционного решения

Инфраструктура интеграционного решения

Компоненты инфраструктуры

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

В качестве единой точки доступа будет использован web-сервер nginx. Его задачи:

Web-сервис (хук) для обработки входящих уведомлений от СМ. Принимает и обрабатывает уведомления о создании, изменении состояния и отмене заказа со стороны СМ. Реализуется в виде Домино web-сервера. Для обеспечения достаточной производительности развёртывается пул из 4 однородных web-серверов с балансировкой нагрузки через nginx.

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

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

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

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

 

Инфраструктура интеграционного решения

Параметры виртуальных машин

Для развёртывания интеграционного решения используются две виртуальные машины

1. ВМ  для установки http- сервера nginx

Параметры ВМ: 

…

2. ВМ для развёртывания web-сервисов и планировщиков Домино

Параметры ВМ:

Инфраструктура интеграционного решения

Развёртывание и настройка nginx

После установки linux следует отключить cистему безопасности SELinux.

В противном случае возникает масса проблем с настройками nginx, когда отклоняются те или иные операции. Можно также отключить SE только для домена httpd_t

semanage permissive -a httpd_t

Информацию о настройках безопасности nginx можно найти здесь: https://disnetern.ru/nginx-server-configure-and-protect/

Если после настройки прокси в nginx.conf  location … { proxy_pass домино_web_сервер} получаем ошибку 502 Bad Gateway, а в логах nginx видим (13: Permission denied) while connecting to upstream, то нужно разрешить в SELinux upstream http соединения:

setsebool -P httpd_can_network_connect 1

Для того, чтобы при включённом SELinux увеличить число файлов на рабочий процесс (worker_rlimit_nofile) нужно разрешить эту операцию:

setsebool -P httpd_setrlimit 1

В настройках /etc/nginx/nginx.conf указывается:

Контекст main

# Увеличиваем общее число файлов для рабочих процессов. Так как мы работаем
# в режиме proxy, то минимум число входящих соединений х2 + резерв
worker_rlimit_nofile 65535;

events {
   # Увеличиваем число соединений на рабочий процесс
   worker_connections 4096;
   # Включаем возможность одновременного приема множества подключений
   multi_accept on;
}

Контекст http

# Включаем буферизацию логов доступа

# В продуктиве логи доступа лучше вообще отключить
access_log … buffer=32k flush=10s;

# Пул web- серверов Домино для обработки уведомлений СМ по заказам (хук)
upstream SberMarketOrdersHook {
   server <ip web- сервера Домино>:8081;
   server <ip web- сервера Домино>:8082;
   server <ip web- сервера Домино>:8083;
   server <ip web- сервера Домино>:8094;
}

# Пул web- серверов Домино для реализации процесса сборки заказов (api)
upstream SberMarketOrdersApi {
   server <ip web- сервера Домино>:8091;
   server <ip web- сервера Домино>:8092;
   server <ip web- сервера Домино>:8093;
   server <ip web- сервера Домино>:8094;
}

Контекст server

# Локации для перенаправления запросов
location /sbermarket/orders/hook/

   # Проксируем запросы на пул SberMarketOrdersHook по методу round-robin
   proxy_pass http://SberMarketOrdersHook;

   # Ставим ограничение по ip СМ (не применять на тестовых конфигурациях)

   allow 84.201.148.122;

   allow 178.154.232.168;

   allow 51.250.5.205;

   deny all;
}

location /sbermarket/orders/api/

   # Проксируем запросы на пул SberMarketOrdersApi по методу round-robin
   proxy_pass http://SberMarketOrdersApi;
}

Обязательно на сервере nginx следует отключить протокол http и настроить протокол https.

 

 

Инфраструктура интеграционного решения

Развёртывание и настройка web-сервисов Домино

В настройках Windows Server firewall нужно разрешить входящие соединения по портам 8080-8099. Если количество web- серверов Домино превысит 20, то нужно соответственно расширить диапазон портов.

Для нормальной работы экземпляров Домино, работающих в режиме сервиса нужно резервировать примерно 400Мб оперативной памяти сервера на экземпляр.

Структура каталогов

Корневой каталог для всех web-сeрвисов - /Domino/SberMarket/WebServices. Каждый сервис развёртывается изолированно в своём собственном каталоге (бины, проект). Такая схема позволит обновлять сервисы по отдельности, без перезапуска всей инфраструктуры.

/Domino

  /SberMarket

    /WebServices

      /OrdersHook

        /Bin

        /Project

        /Log

        startService.bat

        stopService.bat

        restartService.bat

      /OrdersApi

        /Bin

        /Project

        /Log

        startService.bat

        stopService.bat

        restartService.bat

Параметры запуска приложения

Web-сервис (хук) для обработки входящих уведомлений от СМ. Четыре экземпляра приложения, прослушивающих порты с 8081 по 8084.

C:\Domino\SberMarket\WebServices\OrdersHook\Bin\domino8.exe

   C:\Domino\SberMarket\WebServices\OrdersHook\Project\RETAIL-STORE

   /SERVER

   LISTEN=http://<ip web- сервера Домино>:8081/

   DBSERVER=<Ссылка на tnsnames.ora>

   SCHEME=<Имя схемы oracle (БД Домино)>

   USERNAME=SberMarketOrdersHook

   TOKEN=81

Web-сервис для сборки заказов СМ. Четыре экземпляра приложения, прослушивающих порты с 8091 по 8094.

C:\Domino\SberMarket\WebServices\OrdersApi\Bin\domino8.exe

   C:\Domino\SberMarket\WebServices\OrdersApi\Project\RETAIL-STORE

   /SERVER

   LISTEN=http://<ip web- сервера Домино>:8091/

   DBSERVER=<Ссылка на tnsnames.ora>

   SCHEME=<Имя схемы oracle (БД Домино)>

   USERNAME=SberMarketOrdersApi

   TOKEN=91

Автозапуск сервисов при старте сервера

Через задание с однократным запуском.

Ручной останов и запуск сервиса

Батники start/stop/restartService.

 

Инфраструктура интеграционного решения

Развёртывание и настройка планировщиков Домино

Структура каталогов

Корневой каталог для всех планировщиков - /Domino/SberMarket/Schedulers. Каждый сервис развертывается изолированно в своем собственном каталоге (бины, проект). Такая схема позволит обновлять сервисы по отдельности, без перезапуска всей инфраструктуры.

/Domino

  /SberMarket

    /Schedulers

      /QualityMonitor

        /Bin

        /Project

        /Log

        startScheduler.bat

        stopScheduler.bat

        restartScheduler.bat

      /OrdersSales

        /Bin

        /Project

        /Log

        startScheduler.bat

        stopScheduler.bat

        restartScheduler.bat

      /TelegramNotifcations

        /Bin

        /Project

        /Log

        startScheduler.bat

        stopScheduler.bat

        restartScheduler.bat

Параметры запуска приложения

Авто- запуск сервисов при старте сервера

Ручной останов и запуск сервиса

 

Инфраструктура интеграционного решения

Установка обновлений

Как устанавливать обновления при работающих сервисах. Обновление проекта. Обновление ядра.

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

Инфраструктура интеграционного решения

Масштабирование решения

Делается через запуск дополнительных экземпляров web- сервера Домино. Их можно запускать на той же самой ВМ, либо развернуть еще одну. Сервисы - планировщики не масштабируются, однако они спроектированы так, чтобы их производительность не была критически важна.

Инфраструктура интеграционного решения

Тестовый контур

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

Пример формирования адресов:

Продуктивный контур

https://bim.domino.ru/sbermarket/orders

Тестовый контур

https://test-bim.domino.ru/sbermarket/orders

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

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

Назначение сервиса

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

Web-сервис работает с данными БД Домино от имени специального пользователя SberMarketOrdersHook.

Сервис реализуется через единую точку доступа (хук), http- адрес которой партнёр передаёт в СМ. Так же партнёр генерирует и передаёт в СМ авторизационный токен для доступа к сервису. СМ для аутентификации в каждом запросе к сервису передаёт этот токен параметром заголовка Client-token. Cервис должен проверить полученный токен, и вернуть http-код 403 forbidden в случае ошибки.

Адрес точки доступа для отправки уведомлений по заказам со стороны СМ: https://компания.ru/sbermarket/orders/hook/

Спецификация Sbermarket Orders API Partner's WebHooks API находится здесь: https://docs.sbermarket.ru/api-products/other/orders/partners-webhooks . Данные о событии передаются в теле запроса в json формате. Тип события передаётся атрибутом event-type.

Сервис обрабатывает следующие уведомления о событиях СМ

  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- сервис должен распознать эту ситуацию, и отправить СМ положительный ответ по уже созданному с Домино заказу, а не пытаться создать новый.

По всем уведомлениям, кроме order.created, сервис должен возвращать только http- код завершения. Содержание ответа (content) отсутствует.

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

Обработка события order.created (создание заказа)

Уведомление информирует ИС партнёра о появлении нового заказа в СМ. Результатом его обработки является создание нового документа «Заказ СМ» в БД Домино.

Алгоритм обработки:

Структура ответа на уведомление order.created

{

  "status" : "created",

  "number" : "123456"

}

 

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

Обработка события order.changed (изменение заказа)

Уведомление может быть обработано при любом состоянии заказа, кроме «Доставлен» и «Отменен». Если заказ находится в статусе «Новый», и данные уведомления содержат информацию о товарах payload.positions, то состав заказа должен быть изменен. Во всех остальных случаях меняются реквизиты заказа, но не его состав.

Алгоритм обработки:

 

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

Обработка события order.paid (оплата заказа)

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

Алгоритм обработки:

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

Обработка события order.received (передача заказа в доставку)

Уведомление может быть обработано только при состоянии заказа «Собран». В остальных статусах это уведомление игнорируется. В результате обработки заказ переводится в состояние «Передан курьеру», в поле «Дата передачи курьеру» записываются текущие дата-время.

Алгоритм обработки:

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

Обработка события order.delivered (доставка заказа)

Уведомление может быть обработано при состоянии заказа «Собран» или «Передан курьеру». В остальных статусах это уведомление игнорируется. В результате обработки заказ переводится в состояние «Доставлен», в поле «Дата доставки/отмены» записываются текущие дата-время. Если поле «Дата передачи курьеру» пусто, то оно устанавливается равным дате доставки. Если признак оплаты заказа не установлен, то он устанавливается, и в строки заказа прописываются итоговые суммы и цены из payload.positions - аналогично order.paid.

Алгоритм обработки:

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

Обработка события order.cancelled (отмена заказа)

Это уведомление может быть обработано при любом состоянии заказа, кроме «Доставлен»

Алгоритм обработки:

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

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

Назначение сервиса

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

Web-сервис работает с данными БД Домино от имени специального пользователя SberMarketOrdersApi.

 

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

Методы web-сервиса сборки заказов СМ

Все методы web- сервиса сборки заказов вызываются http(s) запросом POST. Приложения Домино могут получить адрес сервиса из параметра «Сервис сборки заказов СМ» карточки компании.

Адрес точки доступа для сервиса сборки заказов:

https://компания.ru/sbermarket/orders/api/

Для аутентификации при вызове необходимо передавать авторизационный токен в заголовке запроса Client-Token. Приложения Домино могут получить токен из параметра «Авторизационный токен сервиса сборки заказов» карточки компании. Каждый метод сервиса должен проверить полученный токен, и вернуть http-код 403 forbidden в случае ошибки.

Имя вызываемого метода передается в URL. Параметры всегда передаются как content в формате json (требуется установить параметр заголовка Content-type : application/json ). Json – объект с параметрами запроса имеет следующую структуру:

{

  requestId : <уникальный идентификатор запроса, string, не обязательный>,

  requestData : {

    <параметры запроса в формате json, в зависимости от вызванного метода>

  }

}

Рекомендуется в каждом запросе передавать уникальный идентификатор запроса requestId. Это упростит анализ протоколов при разборе ошибок. В качестве идентификатора запроса проще всего использовать GUID.

Если метод выполнился, то http-кодом ответа всегда будет 200 OK, вне зависимости от результата выполнения метода. Иные коды ответа (4xx или 5xx) означают ошибки в работе сервиса, но не метода.

Результат выполнения метода всегда возвращается в виде json- объекта с фиксированной на верхнем уровне структурой:

{

  requestId : <уникальный идентификатор запроса, string, не обязательный>,

  errorCode : <код ошибки (0-успешно), целое, обязательный>,

  errorMsg : <описание кода ошибки, string, обязательный при ошибке>,

  responseData : {

    <данные ответа в формате json, в зависимости от вызванного метода>

  }

}

Объект «Заказ» возвращается большинством методов сервиса сборки. Его структура:

order : {

  orderId : <Идентификатор заказа СМ, string>

  storeId : <Идентификатор магазина СМ, string>

  state : <Статус заказа, enum string>

  created : <Время поступления заказа, datetime>,

  collectAt : <Планируемое время сборки заказа, datetime>,

  deliveryAt : <Планируемое время передачи заказа в доставку, datetime>,

  collector : <Сборщик, string>,

  customer : {

    name : <Имя покупателя, string>,

    phoneNumber : <Телефон для связи с покупателем, string>,

    auxNumber : <Добавочный номер, string>

  },

  positions : [

    {

      productId : <Идентификатор товара (SKU), string>,

      replacedById : <Товар, на который заменена позиция, string>,

      name : <Наименование товара, string>,

      picture : <URL картинки с изображением товара, string>,

      storage : <Место хранения товара, string>,

      isWeight : <Весовой товар, bool>,

      isMarked : <Маркированный товар, bool>,

      orderedQuantity : <Заказанное количество, number>,

      agreedQuantity : <Согласованное количество, number>,

      collectedQuantity : <Собранное количество, number>,

      markingCodes : [

        <Код маркировки, string>,

        ...

      ]

    },

    ...

  ],

  comment : <Комментарий к заказу, string>,

  replacementPolicy : <Политика замены, string>

}

Комментарии по реквизитам заказа:

  1. Тип datetime - дата и время в ISO формате, обычно YYYY-MM-DDTHH:MI:SS (время местное).
  2. state, статус заказа. Возможные значения «Новый», «В сборке», «Собран, «Передан курьеру», «Доставлен», «Отменен».

Для синхронизации состояния заказа между СМ и Домино сервис сборки заказов отправляет в СМ специальные уведомления. Спецификация API уведомлений СМ https://docs.sbermarket.ru/api-products/other/orders/partners-notifications .

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

Сборщик заказа - это Пользователь в терминах Домино, для которого установлена роль «Сборщик заказов СМ». Сборщик во всех методах web- сервиса сборки заказов идентифицируется именем пользователя, которое в Домино уникально. Если заказ собирается без указания сборщика (т.н. сборка магазина), то поле «Сборщик» документа заказа СМ остается пустым (NULL).  При вызове методов web- сервиса сборки заказов можно указывать специальное имя сборщика «Сборка магазина», либо null, либо вообще не указывать -  все эти способы эквивалентны, если иное не указано явно. В возвращаемом заказе в случае сборки магазина поле order.collector всегда будет иметь значение null.

 

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

Метод getOrdersList. Получить список заказов указанного магазина

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

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

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

Параметр states (массив статусов) ограничивает выдачу метода заказами, которые находятся в одном из указанных статусов.

Параметр createdBefore ограничивает выдачу заказами, созданными до указанной даты (включительно).

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

Параметры pageSize/pageNumber задают размер и номер страницы выдачи. pageSize не может быть больше 1000 записей. Страничной выдачей следует пользоваться осторожно, так как метод не хранит состояние между вызовами (является stateless), поэтому при параллельном изменении заказов некоторые из них могут не попасть в выдачу или попасть в нее дважды. Кроме того, попытка получить данные с большим номером страницы может потребовать от сервера много времени и ресурсов на предварительное пролистывание набора данных.

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  collector : <Сборщик, не обязательный, string>,

  states : [<Массив статусов, не обязательный>],

  createdAfter : <Созданные после даты, не обязательный, datetime>,

  pageSize : <Размер страницы выдачи, integer>,

  pageNumber : <Номер страницы выдачи, integer>

}

Возвращаемый ответ

responseData : {

  endOfData : <Признак, что возвращены все записи, bool>,

  orders : [

      <Массив объектов типа order, без строк (order.positions)>

  ]

}

 

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

Метод getOrder. Получить содержимое заказа

Метод возвращает заказ по указанному магазину и номеру. Заказ возвращается в виде объекта типа order включая строки (order.positions).

Примечание: хотя номер (идентификатор) заказа СМ и является уникальным, указание идентификатора магазина при вызове метода обязательно.

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

 

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

Метод collectOrder. Начать сборку заказа

Метод переводит заказ, находящийся в статусе «Новый» в состояние «В сборке», назначает сборщика на заказ, отправляет в СМ уведомление order.in_work, создаёт телеграмм- уведомление для сборщика и магазина о назначении заказа в сборку. Возвращает обновлённое содержание заказа, включая строки (order.positions).

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>,

  collector : <Сборщик, не обязательный, string>

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

 

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

Метод completeOrder. Завершить сборку заказа

Метод проверяет полноту сборки заказа, после чего переводит заказ, находящийся в статусе «В сборке» в состояние «Собран», отправляет в СМ уведомление order.ready_for_delivery, создаёт телеграмм- уведомление для сборщика и магазина о завершении сборки заказа. Возвращает обновлённое содержание заказа, включая строки (order.positions).

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

 

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

Метод cancelOrder. Отменить заказ

Метод проверяет статус заказа, после чего переводит его в состояние «Отменен», отправляет в СМ уведомление order.cancelled с указанием причины, создаёт телеграмм-уведомление для сборщика и магазина об отмене заказа. Возвращает обновлённое содержание заказа, включая строки (order.positions).

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  cancelReason : <Причина отмены, string>

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

 

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

Методы работы с позицией заказа xxxPosition

Группа методов работы с позицией заказа (collectPosition, changePosition, appendPosition, replacePosition, clearPosition)  обеспечивает собственно процесс сборки товаров. Все эти методы используют одинаковую схему работы с заказом (алгоритм) и все они в качестве результата возвращают обновлённое содержание заказа, включая строки (order.positions).

Алгоритм (каркас) для всех методов:

Возвращаемый ответ для всех методов:

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

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

Метод collectPosition. Сборка позиции

Метод сборки товара, который есть в заказе, в рамках согласованного количества.

Передаются код товара (ШК, КМ или SKU) и (опционально) собранное количество. По коду товара находится товар в Домино и позиция (строка) в заказе. Если товар весовой, то код товара должен содержать вес, либо вес должен быть передан отдельно как собранное количество. Для штучного товара, если собранное количество не передано, предполагается 1 шт. Если код товара является кодом упаковки, то собранное количество умножается на мультипликатор (вложимость) упаковки. Если товар маркированный, то код товара должен быть кодом маркировки, при этом собранное количество не должно передаваться. Для весовых маркированных товаров (в заводской фасовке с маркировкой) вес должен передаваться тегом (AI) 310 кода маркировки. Весовые маркированные товары собственной фасовки должны идентифицироваться и обрабатываться как немаркированные. Увеличивает собранное количество в строке заказа, при этом проверяется, чтобы собранное количество не превысило согласованное (для весового товара допускается превышение в 10%). Если товар маркированный, то переданный код маркировки сохраняется в дочерней строке специального типа.

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  productCode : <Код товара (ШК, КМ или SKU), обязательный, string >

  collectedQuantity : <Собранное количество, не обязательный, number>,

}

 

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

Метод changePosition. Изменение согласованного количества по позиции

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

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  productId : <Идентификатор товара (SKU), обязательный, string>

  agreedQuantity : <Согласованное количество, обязательный, number>,

}

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

Метод appendPosition. Добавление новой позиции

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

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  productCode : <Код товара (ШК, КМ или SKU), обязательный, string >

  agreedQuantity : <Согласованное количество, обязательный, number>,

  collectedQuantity : <Собранное количество, не обязательный, number>,

}

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

Метод replacePosition. Замена позиции

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

В метод передаются идентификатор заменяемого товара, код заменяющего товара (ШК, КМ или SKU), согласованное количество и (опционально) собранное количество. По идентификатору заменяемого товара находится позиция заказа и проверяется, чтобы заказанное количество в ней было больше 0, а собранное равно 0.  Далее по коду заменяющего товара находится товар в Домино, и проверяется, есть ли такая позиция в заказе. Если такая позиция есть, то согласованное количество в ней увеличивается на переданное в параметрах метода значение (с учётом ограничений по весу и стоимости заказа), после чего логика такая же, как при сборке существующей позиции методом collectPosition. Если же позиция в заказе отсутствует, то она добавляется аналогично методу appendPosition. После всех этих действий в строке с заменяемым товаром согласованное количество устанавливается равным 0, и сохраняется идентификатор заменяющего товара.

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  replacingProductId : <Идентификатор заменяемого товара (SKU), обязательный, string>,

  productCode : <Код заменяющего товара (ШК, КМ или SKU), обязательный, string >

  agreedQuantity : <Согласованное количество, не обязательный, number>,

  collectedQuantity : <Собранное количество, не обязательный, number>,

}

 

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

Метод clearPosition.Удалить информацию о сборке позиции

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

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  productId : <Идентификатор товара (SKU), обязательный, string>

}

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

Метод clearAllPositions. Удалить из заказа всю информацию по сборке

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

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

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

Метод assignCollector. Назначить сборщика на заказ

Метод назначает нового сборщика на заказ, уже находящийся в состоянии «В сборке», создаёт телеграмм- уведомление о передаче заказа для старого и нового сборщиков и магазина (применимо и для перевода заказа с магазина на конкретного сборщика, и со сборщика на магазин). Новый сборщик должен иметь открытую смену по магазину. Возвращает обновлённое содержание заказа, включая строки (order.positions).

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  orderId : <Идентификатор заказа СМ, обязательный, string>

  collector : <Сборщик, не обязательный, string>,

}

Возвращаемый ответ

responseData : {

  order : {

      <Заказ в виде объекта типа order, включая строки (order.positions)>

  }

}

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

Метод beginSession. Начать смену сборщика

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

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  collector : <Сборщик, обязательный, string>,

  duration : <Продолжительность смены, часов, обязательный, [1..24], integer>

}

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

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

Метод endSession. Завершить смену сборщика

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

Алгоритм:

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>,

  collector : <Сборщик, обязательный, string>

}

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

 

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

Метод getSessions. Получить список активных смен по магазину

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

Параметры

requestData : {

  storeId : <Идентификатор магазина СМ, обязательный, string>

  collector : <Сборщик, не обязательный, string>

}

Возвращаемый ответ

responseData : {

  sessions : [

    {

      collector : <Сборщик, string>,

      startAt : <Дата и время начала смены, datetime>,

      finishAt : <Планируемые дата и время окончания смены, datetime>,

      orders : <Число назначенных заказов в сборке, integer>

    },

    ...

  ]

}

 

 

 

Сборка заказов. Руководство пользователя

Сборка заказов. Руководство пользователя

Запуск

Режим сборки заказов СберМаркет в магазине доступен пользователям с установленной ролью «Оператор заказов СберМаркет». Раздел меню «Оператор заказов СберМаркет», пункт «Сборка заказов СберМаркет».

Режим сборки использует учётные данные пользователя, роли и настройки подразделений из той БД, к которой присоединился пользователь.

В начале работы программа пытается автоматически подобрать подразделение.

Права пользователя на подразделения в этом случае не анализируются.

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

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

Сборка заказов. Руководство пользователя

Список заказов

После входа в режим сборки пользователь видит список заказов, которые относятся к выбранному структурному подразделению. Заказы всегда сортируются по дате создания, самые новые заказы находятся сверху списка. В списке по каждому заказу отображается следующая информация:

В зависимости от статуса заказы выделяются цветом

В списке отображаются заказы по выбранному структурному подразделению, которые удовлетворяют следующим условиям:

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

image-1698680057599.png

Назначение кнопок на панели инструментов окна:

«Просмотр/сборка заказа» - переходит в режим просмотра состава и параметров заказа. Если заказ «В сборке», то в этом режиме осуществляется регистрация собранных позиций.

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

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

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

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

«Напечатать сборочный лист» - печатает сборочный лист по выбранному заказу. Выполнение возможно при любом статусе заказа.

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

 

Сборка заказов. Руководство пользователя

Список товаров в заказе

Для перехода к содержимому заказа выберите его в списке заказов, и нажмите на панели инструментов кнопку «Просмотр/сборка заказа». На экран будет выведен состав (строки) заказа с товарами. Позиции заказа всегда отображаются в том порядке, в котором они предоставлены СберМаркет. В списке по каждой позиции отображается следующая информация:

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

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

image-1698680233738.png

Назначение кнопок на панели инструментов:

«Параметры заказа» - открывает форму для просмотра параметров заказа (номер, дата, статус, условия сборки, данные покупателя, примечание). Действие доступно при любом статусе заказа.

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

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

«Изменить согласованное количество» - изменяет согласованное количество по выбранной позиции.

«Заменить товар» - оформляет замену товара выбранной позиции на другой товар.

«Добавить товар» - добавляет новый товар к списку позиций заказа

«Убрать товар» - устанавливает согласованное количество в 0 по выбранной позиции.

«Собрать товар заново» - удаляет информацию о сборке по выбранной позиции.

«Собрать заказ заново» - удаляет всю информацию о сборке по всем позициям заказа, приводит заказ к исходному состоянию.

«Напечатать сборочный лист» - печатает сборочный лист выбранному заказу. Действие доступно при любом статусе заказа.

image-1698680289730.png

 

Сборка заказов. Руководство пользователя

Схема работы

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

При появлении нового заказа в системе сразу переведите его в статус «В сборке», и распечатайте сборочный лист. Возьмите сборочный лист, ручку или маркер, тележку/корзину, фасовочные и упаковочные пакеты, телефон для связи с покупателем и отправляйтесь собирать заказ.

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

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

При сборке штучного товара нужно собрать точно указанное в заказе количество. Весовой товар можно собрать с отклонением до 10% от заказанного веса. Отмечайте собранное количество в сборочном листе.

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

Если товар отсутствует или его недостаточно, ориентируйтесь на правило замены и комментарий покупателя на первой странице сборочного листа. Координаты покупателя для согласования изменений (имя и телефон) вы тоже найдёте там.

Если принято решение исключить позицию из заказа, то просто вычеркните строку в сборочном листе, или исправьте заказанное количество на 0. Аналогично, если принято решение собрать столько товара, сколько есть в наличии, просто исправьте (уменьшите) в строке сборочного листа заказанное количество.

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

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

После того, как все позиции заказа собраны, переместите заказ на рабочее место оператора и зарегистрируйте собранные позиции.

Откройте нужный заказ, он должен быть в статусе «В сборке».

Большинство товаров можно зарегистрировать сканированием кодов. Этот способ проще и меньше ошибок. Нажмите в панели инструментов кнопку «Собрать сканированием». Появится окно ввода кода товара. Последовательно считывайте сканером штриховые коды с отобранных товаров. У товаров с маркировкой (молочная продукция, вода, иные группы) вместо ШК сразу считывайте код маркировки. Система самостоятельно разносит считанные коды по позициям заказа и считает собранное количество. Таким способом можно регистрировать сборку штучного товара с заводской маркировкой, сборку штучного товара без маркировки (чтением ШК из альбома),  весового товара, который был взвешен на весах с печатью этикеток, и весового маркированного товара (целыми заводскими упаковками), код маркировки которого содержит в себе вес. Следите за экраном - после сканирования очередного кода возможно появление сообщения об ошибке, на которое нужно правильно отреагировать. Причина, по которой система отказывается зарегистрировать товар, всегда будет описана в сообщении.

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

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

Система ограниченно контролирует сборку товара с кодами маркировки ЧЗ. Невозможно дважды зарегистрировать в заказе один и тот же код маркировки ЧЗ.

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

Для того, чтобы зарегистрировать изменение согласованного количества, выберите в заказе нужную позицию, и нажмите на панели инструментов кнопку «Изменить согласованное количество». Введите новое значение количества/веса по позиции.  Новое значение не должно быть меньше, чем уже собранное по позиции количество.

Для того, чтобы удалить товар из заказа, выберите в заказе нужную позицию, и нажмите на панели инструментов кнопку «Убрать товар». После подтверждения действия согласованное количество по позиции изменится на 0.

Для того, чтобы добавить товар к заказу нажмите на панели инструментов кнопку «Добавить товар». Сканируйте в поле формы ШК товара (с упаковки или из альбома). Для маркированного товара вместо ШК сканируйте код маркировки. Введите согласованное с клиентом и фактически собранное количество товара. Если не вводить собранное количество, то для штучного товара оно будет установлено равным 1. Для весового товара собранное количество берётся из весового ШК (или из кода маркировки с весом). Если не вводить согласованное количество, то оно установится равным собранному.

Для того, чтобы оформить замену одного товара другим, выберите в заказе нужную позицию, и нажмите на панели инструментов кнопку «Заменить товар». По позиции не должно быть зарегистрировано собранного товара. Сканируйте в поле формы ШК товара-замены (с упаковки или из альбома). Для маркированного товара вместо ШК сканируйте код маркировки. Введите согласованное с клиентом и фактически собранное количество товара-замены. Если не вводить собранное количество, то для штучного товара оно будет установлено равным 1. Для весового товара собранное количество берётся из весового ШК (или из кода маркировки ЧЗ с весом). Если не вводить согласованное количество, то оно установится равным собранному. Если товар-замена отсутствует в заказе, то он будет добавлен. Если же товар-замена уже есть в заказе, то к согласованному и собранному количествам будут добавлены введённые вами значения.

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

Если вы окончательно запутались со сборкой, то можно привести заказ полностью в исходное состояние. При таком сбросе удаляется вся информация о кодах маркировки ЧЗ по всем позициям, удаляются добавленные позиции, согласованное количество устанавливается равным заказанному, а собранное равным 0.

После того, как все позиции по заказу собраны (помечены зелёным цветом) проверьте, не остались ли у вас в корзине не зарегистрированные товары. Их наличие означает, что вы либо ошиблись при сборке, либо не внесли в заказа согласованные с покупателем изменения. В таком случае ещё раз проверьте сборку заказа и исправьте ошибки.

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

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

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

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

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