Обсудить задачу
Интернет-магазины

Skirbo +
DC Commerce

Исключить повторный заказ от витрины, OMS и ERP. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Заказ выбранного торгового контураDC Commerce → SkirboОбсудим в составе подключения

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

Доступность товараSkirbo → DC CommerceНужна проверка

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

Результат комплектацииSkirbo → DC CommerceНужна проверка

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

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

DC Commerce рассматриваем как конкретную сборку торговой платформы для B2C/B2B, где каталог, заказ, оплата и логистика могут принадлежать разным сервисам. Задача склада — принять один согласованный поток физических строк и вернуть исполнение в выбранного владельца заказа.

Как организовать обмен

Схема авторизации, сетевой доступ и права зависят от развертывания. Для on-premise/private cloud нужен согласованный адрес среды и техническая роль, для SaaS — подтверждённый доступ поставщика; конкретных требований к сети источник не задаёт.

Предлагаемый порядок работы

  1. Команда клиента называет единственный сервис, которому разрешено выдавать складскую команду. Платёжный сервис сообщает факт оплаты этому владельцу, а не создаёт параллельное задание.
  2. Из заказа выделяем физические строки, их постоянные идентификаторы, вариант товара, количество, получателя и выбранный маршрут. PIM-описания и маркетинговые атрибуты не заменяют складской код.
  3. Согласованная таблица связывает tenant магазина, клиента фулфилмента, SKU и склад; редакция заказа фиксируется перед передачей. Транспорт выбирается по спецификации реальной сборки.
  4. Skirbo принимает задание один раз, резервирует на разрешённой площадке и передаёт оператору проверенные строки. Неполная карта SKU останавливает проблемную строку до сборки.
  5. После комплектации возвращаем владельцу заказа фактические строки, количества и идентификатор отгрузки. Соседние сервисы получают изменения через согласованный маршрут платформы.
  6. Подтверждением служит состояние исходного заказа после обработки результата, а не только успешная передача сообщения. Сохраняем ссылку на принятую редакцию и журнал подтверждений.
  7. Если пришла новая редакция или отмена, сравниваем её с начатой работой. До отбора можно пересчитать задание; после отбора оператор согласует разбор, частичную отправку либо возврат.

Практические сценарии

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

Единственная команда на сборку из составной платформы

Задача: Исключить повторный заказ от витрины, OMS и ERP.

Когда начинается: В установленной сборке выбранный владелец заказа переводит его в согласованный этап исполнения.

  1. Команда клиента называет единственный сервис, которому разрешено выдавать складскую команду. Платёжный сервис сообщает факт оплаты этому владельцу, а не создаёт параллельное задание.
  2. Из заказа выделяем физические строки, их постоянные идентификаторы, вариант товара, количество, получателя и выбранный маршрут. PIM-описания и маркетинговые атрибуты не заменяют складской код.
  3. Согласованная таблица связывает tenant магазина, клиента фулфилмента, SKU и склад; редакция заказа фиксируется перед передачей. Транспорт выбирается по спецификации реальной сборки.
  4. Skirbo принимает задание один раз, резервирует на разрешённой площадке и передаёт оператору проверенные строки. Неполная карта SKU останавливает проблемную строку до сборки.
  5. После комплектации возвращаем владельцу заказа фактические строки, количества и идентификатор отгрузки. Соседние сервисы получают изменения через согласованный маршрут платформы.
  6. Подтверждением служит состояние исходного заказа после обработки результата, а не только успешная передача сообщения. Сохраняем ссылку на принятую редакцию и журнал подтверждений.
  7. Если пришла новая редакция или отмена, сравниваем её с начатой работой. До отбора можно пересчитать задание; после отбора оператор согласует разбор, частичную отправку либо возврат.

Результат: Один заказ имеет один маршрут в склад и проверяемый обратный результат.

Если возникло исключение

  • Недоступность владельца заказа оставляет результат в очереди, но не создаёт повторную сборку.

Проекция доступности в несколько витрин

Задача: Разделить физический запас и представление наличия в каналах.

Когда начинается: Складской факт меняется после резерва или приёмки.

  1. Владелец резерва формирует доступный объём по SKU, владельцу и складу; каталог остаётся источником описания товара.
  2. Адаптер передаёт проекцию только в назначенный сервис наличия, который обслуживает нужные витрины.
  3. Сверка сопоставляет опубликованный объём с исходным расчётом; при запаздывании включается согласованное ограничение продаж.

Результат: Витрины используют одну модель обещания товара.

Если возникло исключение

  • Нельзя независимо вычитать резерв в каждом микросервисе.

Согласование изменения уже переданного заказа

Задача: Удержать количество и адрес при конкурентных изменениях.

Когда начинается: Менеджер меняет строку или доставку после передачи в склад.

  1. Изменение получает новую редакцию у владельца заказа; сравниваем её с принятой складом версией.
  2. Оператор подтверждает, можно ли изменить незавершённую сборку; готовую отправку не переписываем молча.
  3. Решение возвращается владельцу заказа и становится видимым для остальных каналов.

Результат: Коммерческая правка не расходится с физической отправкой.

Если возникло исключение

  • История редакций и повторная доставка команды обязательны к проверке конкретного транспорта.

Отмена в OMS при уже начавшейся сборке и потерянном подтверждении

Задача: Согласовать коммерческую отмену с физическим товаром без двойного снятия резерва.

Когда начинается: Владелец заказа прислал новую редакцию с отменой, когда склад уже принял прежнюю команду.

  1. Журнал связывает отмену с тем же tenant, исходным заказом, строками и новой редакцией; отмена из платёжного сервиса сама по себе не становится независимой командой складу.
  2. Склад сверяет свой последний подтверждённый этап. До отбора возможна отмена незатронутого задания, после отбора требуется решение оператора, после передачи перевозчику открывается возвратный процесс.
  3. Ответственный выбирает отменяемые и сохраняемые строки; сведения о фактической партии остаются неизменными, даже если OMS уже показывает отменённый коммерческий заказ.
  4. Снятие резерва поручается одному согласованному владельцу. Изменение резерва в OMS и физический разбор отобранного товара регистрируются разными фактами.
  5. Результат остановки либо отказ в остановке передаётся владельцу заказа с исходной редакцией и фактическим количеством; оплата и денежный возврат остаются в финансовом контуре.
  6. Получатель подтверждает итоговое состояние. При тайм-ауте сначала сверяются принятая редакция и уже снятый резерв; повтор доставки решения не создаёт вторую отмену или приёмку.

Результат: OMS знает, какой объём остановлен, а какой требует возврата; физическое наличие и деньги не изменяются одной неподтверждённой командой.

Если возникло исключение

  • Порядок событий, механизм версий и права отмены должны быть подтверждены для установленной сборки; сценарий не объявляет готовую гарантию DC Commerce.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ и строкиВыбранный сервис заказа DC CommerceВитрина, ERP и OMS не получают одинаковое право независимо создавать складскую команду.
SKU и вариантыКаталог/PIM проектаSKU и вариант сопоставляются с номенклатурой склада, владелец атрибутов назначается явно.
Остатки и резервСклад и назначенный сервис резерваФизическое наличие и обещанный каналу объём разделяются.
СтатусыВладелец заказа и SkirboКоммерческий этап и физический прогресс связаны таблицей переходов.
ДокументыУчётный контур проектаИнвойс, чек и отгрузочный документ не выводятся из события резервирования.
ВозвратыВладелец заказа + склад приёмкиРазрешение, физическая приёмка и финансовое решение ведутся отдельно.

Что обсудить перед пилотом

  • Какой сервис фактически владеет заказом и какими операциями допускает внешний склад?
  • Кто вычитает резерв и как публикуется доступность?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Перед оценкой

Что нужно уточнить

  • Спецификация сервисов и интерфейсов установленной сборки DC Commerce.
  • Карта владельцев заказа, оплаты, каталога и складского резерва.
  • Обезличенный пример заказа с частичным исполнением и описание очередности событий.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Для конкурентной отмены — матрица владельцев команд, редакций заказа, снятия резерва и финансового возврата в установленной сборке.
Границы сценария

Что учесть заранее

  • Состав микросервисов и доработки конкретного проекта определяют доступные операции.
  • Наличие маркетингового описания интеграций не подтверждает webhook, endpoint или готовый адаптер Skirbo.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Основной сценарий рассчитан на продавца в России. Для Казахстана и Узбекистана отдельно проверяются договор поставщика, локальные документы и правила обращения товара; российские ЭДО, касса и маркировка автоматически не переносятся.
  • Описание кабинетов поставщиков не определяет права технической роли склада и не доказывает доступ к заказам всех поставщиков.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

К какому сервису подключать склад в компонуемой архитектуре?

Вопросы о подключении

К какому сервису подключать склад в компонуемой архитектуре?

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

Можно ли сохранить существующий OMS?

Да, это один из вариантов проектирования: OMS продолжает управлять заказом, а Skirbo возвращает физический результат; контракт и ответственность фиксируются до разработки.

Достаточно ли пометки API-first на сайте?

Для оценки архитектуры она полезна, для реализации нужны схемы сообщений, права и подтверждение бизнес-переходов конкретной сборки. Прочитанный Getting started таких сведений не содержит.

Кому отправлять отгрузку, если есть и OMS, и ERP?

Одному согласованному владельцу состояния заказа. Дальнейшую доставку результата в ERP и витрины описываем отдельно, чтобы повторные сообщения не породили повторную отгрузку.

Отмена платежа должна автоматически отменить сборку?

Она должна пройти через назначенного владельца заказа. Тот сверяет физический этап и допускает отмену либо возврат; иначе платёжный и торговый сервисы могут независимо снять один резерв.

Что делать, если сообщение об отгрузке доставлено, но ответ потерян?

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

Интеграция уже готова?

Изучаем возможность: нужны договорный интерфейс и проверка предметного сценария. Принятый коннектор Skirbo, доступность пилота, срок запуска и SLA не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

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

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

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

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

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