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

Skirbo +
Shopware

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

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

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

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

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

Сохранить внешний заказ, sales channel и варианты, исключив корзины витрины.

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

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

Результат доставки заказаSkirbo → ShopwareНужна проверка

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

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

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

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

Shopware рассматриваем в области серверной интеграции магазина с Admin API, по документации Shopware 6. Store API обслуживает покупательский контекст и не заменяет полномочия склада. Для продавца важны каналы продаж, варианты и отдельные доставки одного заказа.

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

Подтверждены Admin OAuth client_credentials и Bearer-токен; Store API использует другой контекст sales channel. Роль Admin integration выдаётся с минимальными нужными правами, не с полным администрированием по примеру quickstart.

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

  1. Серверная интеграция читает заказ в области согласованных прав Admin API. Ключ витрины Store API не используется как универсальный доступ склада.
  2. Сохраняем заказ, канал продаж, исходные строки, варианты и связи доставок. Оплату и разрешённый этап проверяем по утверждённой модели состояния.
  3. Сопоставляем вариант с SKU клиента, доставку — с физической площадкой и маршрутом. Sales channel не считаем складом и не объединяем его запас без правила.
  4. Skirbo резервирует и комплектует назначенные строки; фактическая партия сохраняет исходные связи и количество. Неполная партия не закрывает все доставки заказа.
  5. Возвращаем факт в соответствующую доставку/согласованный объект через разрешённый переход. Конкретный контракт state machine проверяется для версии и расширений клиента.
  6. Читаем новое состояние и сверяем строки партии; общий успех HTTP или массового запроса недостаточен без проверки конкретной записи.
  7. При отмене, конфликте состояния или ошибке отдельного объекта сохраняем успешные результаты и разбираем только неподтверждённые. Повтор не создаёт новую партию и не переписывает более поздний этап.

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

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

Заказ с несколькими доставками через Admin API

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

Когда начинается: Коммерческий процесс Shopware допускает заказ выбранного sales channel к исполнению.

  1. Серверная интеграция читает заказ в области согласованных прав Admin API. Ключ витрины Store API не используется как универсальный доступ склада.
  2. Сохраняем заказ, канал продаж, исходные строки, варианты и связи доставок. Оплату и разрешённый этап проверяем по утверждённой модели состояния.
  3. Сопоставляем вариант с SKU клиента, доставку — с физической площадкой и маршрутом. Sales channel не считаем складом и не объединяем его запас без правила.
  4. Skirbo резервирует и комплектует назначенные строки; фактическая партия сохраняет исходные связи и количество. Неполная партия не закрывает все доставки заказа.
  5. Возвращаем факт в соответствующую доставку/согласованный объект через разрешённый переход. Конкретный контракт state machine проверяется для версии и расширений клиента.
  6. Читаем новое состояние и сверяем строки партии; общий успех HTTP или массового запроса недостаточен без проверки конкретной записи.
  7. При отмене, конфликте состояния или ошибке отдельного объекта сохраняем успешные результаты и разбираем только неподтверждённые. Повтор не создаёт новую партию и не переписывает более поздний этап.

Результат: Заказ остаётся связан с фактическими доставками, а доступ склада отделён от покупательского API.

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

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

Варианты и массовое обновление

Задача: Обрабатывать каталог без скрытой потери отдельных изменений.

Когда начинается: Подготовлена партия соответствий вариантов или доступности.

  1. Проверяем карту product/variant–SKU и состав разрешённых полей для данной версии.
  2. Передаём изменения согласованной серверной операцией; результат разбираем по объектам, сохраняя успешно принятые.
  3. Повторяем только исправленные или временно не принятые записи и сверяем контрольное состояние.

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

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

  • Наличие Sync API не даёт разрешения массово менять чужие поля или резерв.

Правка заказа после передачи на склад

Задача: Согласовать state machine с реальным этапом работы.

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

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

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

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

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

Возврат одной доставки из заказа с двумя партиями

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

Когда начинается: Покупатель возвращает товар, ранее выданный в одной из доставок заказа.

  1. Продавец связывает разрешение возврата с исходным заказом, конкретной delivery, её строками и количеством. Первая запись deliveries не выбирается автоматически.
  2. Склад принимает именно возвращённые физические единицы, сверяет вариант, клиента и площадку и отделяет годное от брака.
  3. В журнале фиксируем фактическую приёмку и расхождения с заявленным составом. Другая доставка этого заказа сохраняет прежнюю историю выдачи.
  4. Ответственный выбирает согласованный переход состояния данной delivery, проверив допустимость в текущем состоянии и установленной версии Shopware.
  5. Возвращаем результат разрешённым Admin-контрактом или согласованным операторским шагом. Статус оплаты не меняем автоматически по одному складскому сообщению.
  6. Перечитываем конкретную доставку и связываем подтверждение с возвратом. Годная часть увеличивает согласованный запас один раз, брак остаётся отдельно.
  7. При конфликте перехода либо потерянном ответе сверяем уже принятые записи. Менеджер разбирает исключение без повторной приёмки и без переноса результата на другую delivery.

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

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

  • Доступные переходы и поля количества проверяются на версии клиента.
  • Этот процесс не использует принудительный обход state machine и не подменяет физическую приёмку сменой статуса.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиShopware Admin-контурСостав заказа и коммерческий допуск принадлежат магазину.
SKU и вариантыКаталог Shopware и складской справочникВариант и родительский продукт не объединяются в один SKU.
Остатки и резервНазначенный владелец запасовСемантика stock/available и влияние плагинов проверяются до записи.
СтатусыState machine магазина и физический этап SkirboРазные доставки могут находиться на разных этапах.
ДокументыУчётный контур и разрешённые документы магазинаФакт отгрузки не заменяет оплату и проведение документа.
ВозвратыСервис продавца и складВозврат связывается с исходной доставкой и осмотром товара.

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

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

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

  • Версия Shopware и права интеграции Admin API, список расширений заказа и наличия.
  • Соответствие вариантов, каналов продаж и складов.
  • Пример разделённой доставки и допустимые переходы её состояний.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Страна и юридическое лицо продавца, валюта заказа и правила учёта sales channel. Склад сохраняет исходную валюту коммерческих сумм и не выполняет неоговорённую конвертацию.
Границы сценария

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

  • Store API предназначен для покупательского взаимодействия и не заменяет серверные права Admin API.
  • Массовая запись не отменяет проверку ошибок отдельных объектов и согласование бизнес-статусов.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Примеры server-side StateMachineRegistry не заменяют спецификацию Admin API конкретной версии и не подтверждают право произвольной записи stateId.
Стоимость и запуск

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

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

Почему складской обмен рассматривается через Admin API?

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

Почему складской обмен рассматривается через Admin API?

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

Что делать, если заказ доставляется двумя посылками?

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

Почему общий статус заказа не закрывает все доставки?

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

Sync API позволяет считать всю партию успешной?

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

Почему недостаточно взять первую delivery из заказа?

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

Статус returned означает, что покупателю уже вернули деньги?

В Shopware состояния доставки и транзакции разделены. Склады подтверждают приёмку и годность товара; финансовое решение и подтверждение платежа принадлежат продавцу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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