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

Skirbo +
Headless Evolution

Сохранить канал продаж, не создавая отдельную сборку для каждого фронтенда. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

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

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

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

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

Сохранить исходный канал и единый номер заказа в центральной системе.

Доступный остатокSkirbo → Headless EvolutionНужна проверка

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

Состояние физического исполненияSkirbo → Headless EvolutionНужна проверка

Разделить готовность к выдаче, передачу перевозчику и доставку покупателю.

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

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

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

Headless Evolution — торговая платформа, в которой витрины и каналы могут использовать общий коммерческий контур. Рассматриваем продавца с сайтом, приложением или операторским каналом и несколькими складами; складской обмен должен начинаться в центральном заказе.

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

Прочитана продуктовая страница; схема доступа и разрешения конкретной редакции не подтверждены. Получить договорный API-контракт и назначить роль для одного тестового магазина.

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

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

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

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

Заказ из нескольких каналов в единый складской маршрут

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

Когда начинается: Центральный коммерческий контур допускает заказ к исполнению.

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

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

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

  • Конфликт правки сайта и менеджера решается по согласованной версии заказа, а не по порядку прихода сообщений.

Общий резерв для сайта и приложения

Задача: Не обещать один экземпляр одновременно двум каналам.

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

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

Результат: Каналы используют согласованную доступность.

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

  • Лояльность и персональная цена не меняют физическое количество.

Самовывоз и доставка как разные физические результаты

Задача: Не закрыть заказ раньше реальной передачи покупателю или перевозчику.

Когда начинается: Заказ распределён на площадку выдачи либо отправку.

  1. В заказе закрепляем способ получения и разрешённую площадку.
  2. Для самовывоза фиксируем готовность и отдельный факт выдачи; для доставки — передачу отправления перевозчику.
  3. В центральный заказ возвращаем только тот этап, который фактически произошёл, и сверяем его принятие.

Результат: Менеджер видит различие готовности и состоявшегося вручения.

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

  • Документированные статусы и возможность их записи ещё предстоит проверить.

Возврат интернет-заказа через другую площадку выдачи

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

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

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

Результат: Каналы видят один возврат с фактическим складом приёмки, а запас и финансовое решение подтверждаются независимо.

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

  • Способ регистрации возврата и допустимые площадки определяются договором и центральным контрактом проекта; универсальная функция API Headless Evolution не подтверждена.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиЦентральный заказ Headless Evolution/подключённой OMSВыбор определяется архитектурой проекта; фронтенд не назначается владельцем по умолчанию.
SKU и вариантыPIM или каталог проектаСвязь вариантов всех каналов со складскими SKU утверждается один раз.
Остатки и резервЕдиный контур резервов и SkirboЗапас по владельцу и площадке не копируется как независимый резерв каждого канала.
СтатусыЦентральный заказ и складКоммерческие этапы, готовность к выдаче и фактическая передача различаются.
ДокументыERP и платёжный контурЧек, оплата и складская отгрузка имеют отдельные подтверждения.
ВозвратыКлиентский сервис + принимающий складВозврат из любого канала связывается с исходной строкой и результатом осмотра.

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

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

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

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

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

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

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

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

Как избежать двойного резерва между несколькими витринами?

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

Как избежать двойного резерва между несколькими витринами?

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

Нужно ли подключать каждый frontend отдельно?

Это зависит от архитектуры проекта. При едином владельце заказов предпочтителен один согласованный складской маршрут с сохранением канала происхождения.

Можно ли сменить самовывоз на доставку после отбора?

Это зависит от фактического этапа. До упаковки можно согласовать новый маршрут; после передачи товара нужны отдельные действия по перенаправлению или возврату. Правка центрального заказа не должна скрывать физический результат.

Будет ли склад применять бонусы и программы лояльности?

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

Можно принять возврат на складе, отличном от места исходной отгрузки?

В предлагаемом процессе — только после согласования принимающей площадки и владельца товара. Затем возврат связывается с исходной строкой; межскладское перемещение учитывается отдельно.

Заявление об обмене в реальном времени гарантирует мгновенное снятие наличия?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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