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

Skirbo +
Medusa

Передать физические строки через согласованный workflow установленной Medusa. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

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

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

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

ОперацияНаправлениеСостав и готовность
Подтверждённый заказMedusa → SkirboОбсудим в составе подключения

Определить допуск к исполнению в workflow проекта и источник обновлений заказа.

Складской запасSkirbo → MedusaНужна проверка

Сопоставить SKU, inventory-модель и локации установленной сборки.

Выполнение физических строкSkirbo → MedusaНужна проверка

Проверить provider исполнения и разрешённый способ отражения частичной отгрузки.

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

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

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

Medusa рассматриваем как конкретную серверную сборку commerce-платформы; предметный добор относится к документации Medusa v2. Состав установленных функций проверяется по версии проекта. Владелец магазина или разработчик определяет модули и workflows; фулфилменту нужны связи вариантов, inventory-позиций и stock locations.

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

Получить серверный API-контракт и permissions установленной версии. Архитектура модулей не подтверждает конкретный grant или состав ролей; Store/Admin контексты не смешивать.

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

  1. Фиксируем версию Medusa, состав модулей и точку коммерческого допуска. Store API витрины не используется для административного изменения складского результата.
  2. Получаем заказ и физические строки через подтверждённый серверный контракт; сохраняем исходный вариант и связь с inventory-позициями.
  3. Сопоставляем inventory item и stock location с SKU клиента и физической площадкой. Если один вариант использует несколько физических компонентов, нужен утверждённый состав, а не предположение по названию.
  4. Skirbo принимает задание, резервирует и комплектует разрешённые позиции. Fulfillment provider и владелец резерва согласуются с разработчиком магазина; штатное изменение stock/reservation выполняется workflow, поэтому его нельзя повторять отдельной дельтой.
  5. Фактические количества и отправление возвращаем в выбранный workflow/provider, сохраняя исходные строки. Прямую запись во внутренние таблицы не предлагаем.
  6. Читаем результат workflow и объект исполнения; только принятый результат отражается в статусе клиента. Успех отдельного сетевого вызова не гарантирует завершение всего workflow.
  7. При ошибке шага сохраняем состояние и согласованно возобновляем процесс. Если физическое действие уже выполнено, компенсация программного шага не означает автоматический возврат товара на полку.

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

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

Складской provider в процессе исполнения заказа

Задача: Передать физические строки через согласованный workflow установленной Medusa.

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

  1. Фиксируем версию Medusa, состав модулей и точку коммерческого допуска. Store API витрины не используется для административного изменения складского результата.
  2. Получаем заказ и физические строки через подтверждённый серверный контракт; сохраняем исходный вариант и связь с inventory-позициями.
  3. Сопоставляем inventory item и stock location с SKU клиента и физической площадкой. Если один вариант использует несколько физических компонентов, нужен утверждённый состав, а не предположение по названию.
  4. Skirbo принимает задание, резервирует и комплектует разрешённые позиции. Fulfillment provider и владелец резерва согласуются с разработчиком магазина; штатное изменение stock/reservation выполняется workflow, поэтому его нельзя повторять отдельной дельтой.
  5. Фактические количества и отправление возвращаем в выбранный workflow/provider, сохраняя исходные строки. Прямую запись во внутренние таблицы не предлагаем.
  6. Читаем результат workflow и объект исполнения; только принятый результат отражается в статусе клиента. Успех отдельного сетевого вызова не гарантирует завершение всего workflow.
  7. При ошибке шага сохраняем состояние и согласованно возобновляем процесс. Если физическое действие уже выполнено, компенсация программного шага не означает автоматический возврат товара на полку.

Результат: Кастомный workflow связан с реальным складским процессом и имеет контролируемое восстановление.

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

  • Методы, события и компенсационные действия зависят от версии и кастомизации.

Один вариант и несколько stock locations

Задача: Согласовать резерв и доступность площадок.

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

  1. Таблица связывает variant, inventory item и location; клиент фулфилмента является отдельной областью.
  2. Владелец резерва выбирает разрешённую площадку и рассчитывает свободный объём без двойного вычитания.
  3. После исполнения сверяем остаток и резерв в обеих системах; перенос между локациями обрабатывается как перемещение, а не продажа.

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

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

  • Модуль Inventory не определяет вашу стратегию распределения.

Комплект с физическими компонентами как кастомный сценарий

Задача: Собрать комплект по утверждённой спецификации.

Когда начинается: Проект магазина продаёт комплект, поддержанный его custom workflow.

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

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

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

  • Это предложение расширения конкретного проекта, а не утверждение о готовом модуле комплектов каждой установки Medusa.

Приёмка возврата и подтверждение stock в Medusa v2

Задача: Вернуть в доступный запас только принятую годную часть и не повторить корректировку штатного workflow.

Когда начинается: Продавец разрешил возврат ранее исполненного заказа, и посылка прибыла на склад.

  1. Связываем возврат с исходной строкой, вариантом, inventory items, клиентом и фактической stock location. Если вариант представляет inventory kit, сохраняем состав и необходимые количества компонентов.
  2. Оператор принимает реальное количество и проверяет комплектность и состояние. Ожидание посылки и финансовое решение не считаются завершённой приёмкой.
  3. Отдельно фиксируем принятую и отклонённую или повреждённую часть. Владелец процесса определяет, какое количество относится к dismissed, и подтверждает складской акт.
  4. Передаём согласованный результат через утверждённый workflow приёмки возврата конкретной сборки. Для стандартного Medusa v2 учитываем, что этот workflow сам меняет stock.
  5. Перечитываем inventory level и результат приёмки и сверяем их с физическими единицами; отдельная интеграционная дельта не должна повторить штатное увеличение.
  6. При потерянном ответе ищем уже завершённую приёмку и её эффект. Повтор одного сообщения не создаёт второй приход и не меняет dismissed на годное автоматически.
  7. Если компоненты, локация или количества расходятся, блокируем дальнейшую публикацию спорного остатка и назначаем разбор. Финансовое возмещение проверяет продавец отдельно.

Результат: Возврат, пригодный запас и изменение inventory level согласованы по исходной строке и локации.

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

  • Названия API, статус возврата и состав шагов проверяются по установленной версии; описанный процесс не является действующей интеграцией.
  • Кастомная компенсация workflow не подтверждает физическое возвращение товара.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиOrder-модуль и workflow магазинаТочка допуска и версия процесса фиксируются разработчиком и продавцом.
SKU и вариантыProduct/Inventory и карта складаVariant, inventory item и физический компонент различаются.
Остатки и резервInventory/Stock Location и согласованный владелец резерваНе вычитать один резерв одновременно в workflow и складской проекции; проверить наличие reservation по исходной строке до исполнения.
СтатусыWorkflow/fulfillment provider и SkirboПрограммный шаг и физическая передача товара подтверждаются раздельно.
ДокументыУчёт/платёжный контур проектаWorkflow исполнения не заменяет локальные документы и финансовый статус.
ВозвратыПроцесс возврата магазина и склад осмотраКомпенсация workflow не доказывает, что товар физически вернулся.

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

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

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

  • Версия Medusa, перечень кастомных модулей и контракт server API.
  • Соответствие variants, inventory-позиций и stock locations.
  • Правила workflow подтверждения, отмены и provider исполнения.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Версия Medusa v2 или отдельное обследование v1, тип размещения и список переопределённых core workflows.
  • Страна продавца, валюта исходного заказа, коммерческий region и связь sales channel с обслуживающими stock locations; склад не выполняет неоговорённую валютную конвертацию.
Границы сценария

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

  • Возможности одной версии или демонстрационного проекта не распространяются на все установки Medusa.
  • Store API и административные операции имеют разные полномочия; доступ клиента витрины не подходит для складских изменений.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • В одной установке нельзя одновременно считать резерв владельцем двух независимых списаний: стандартный core workflow и внешний адаптер должны согласовать одну модель изменений.
  • Документированные inventory kits не отменяют исходный вопрос о custom workflows и составе коммерческих комплектов.
Стоимость и запуск

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

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

Почему нельзя подключиться только по URL магазина?

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

Почему нельзя подключиться только по URL магазина?

URL витрины не показывает версию backend, кастомные workflows и административные права. Для оценки нужен контракт установленной сборки.

Как учитывать несколько складских локаций?

Сопоставим каждую используемую локацию и определим источник резерва. Общее число товаров не заменяет количество, доступное конкретному заказу.

Рецепт интеграции ERP означает готовое подключение Skirbo?

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

Можно полностью откатить workflow после отгрузки?

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

Заказ создан: значит, reservation уже существует?

Не обязательно. В документации Medusa v2 различаются завершение корзины с созданием резерва и workflows создания заказа, которые могут обойти этот этап. Перед штатным исполнением проверяют связанный с исходной строкой резерв.

Inventory kit — это готовый механизм продажи любого комплекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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