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

Skirbo +
OXID eShop

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

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

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

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

ОперацияНаправлениеСостав и готовность
Заказ магазинаOXID eShop → SkirboНужна проверка

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

Варианты товаровOXID eShop → SkirboОбсудим в составе подключения

Отделить родительский товар от реально продаваемых вариантов.

Исполнение и наличиеSkirbo → OXID eShopНужна проверка

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

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

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

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

OXID eShop рассматриваем как установленный магазин с конкретной редакцией и набором модулей. Официальные GraphQL-модули — отдельные компоненты: их существование не означает, что интерфейс включён у клиента или разрешает внешнему складу читать все заказы.

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

GraphQL Base описывает JWT; способ выдачи токена и права проверяются в установленной схеме. Introspection зависит от роли, поэтому доступную query/mutation подтверждают вместе с активными модулями и областью магазина. Нужные складские операции не выводятся из одного storefront-токена.

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

  1. Инвентаризируем редакцию OXID, версии и активные интеграционные модули. Не начинаем с предположения, что публичный GraphQL endpoint установлен и доступен.
  2. Проверяем нужный серверный интерфейс: право получить заказ, строки, варианты и разрешённый статус. Пользовательский storefront-токен не принимается за право экспорта всех заказов.
  3. Сопоставляем исходные строки и варианты с SKU клиента и физическим складом, сохраняя контекст магазина и историю кода.
  4. Skirbo резервирует и комплектует допущенный объём; при кастомных опциях менеджер подтверждает, какая из них определяет отдельный физический вариант.
  5. Факт партии и отправления возвращаем через подтверждённую операцию модуля либо согласованный операторский шаг. Состав заказа не меняем из-за ошибки сопоставления.
  6. Читаем принятый результат и сверяем количества; JWT или успешный ответ GraphQL не заменяет проверку разрешённой бизнес-операции.
  7. После обновления модулей, изменения схемы или отмены начатой сборки спорные задания блокируются до проверки. Повторное сообщение сверяется с уже принятым заказом.

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

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

Заказ установленного OXID через проверенный модуль

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

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

  1. Инвентаризируем редакцию OXID, версии и активные интеграционные модули. Не начинаем с предположения, что публичный GraphQL endpoint установлен и доступен.
  2. Проверяем нужный серверный интерфейс: право получить заказ, строки, варианты и разрешённый статус. Пользовательский storefront-токен не принимается за право экспорта всех заказов.
  3. Сопоставляем исходные строки и варианты с SKU клиента и физическим складом, сохраняя контекст магазина и историю кода.
  4. Skirbo резервирует и комплектует допущенный объём; при кастомных опциях менеджер подтверждает, какая из них определяет отдельный физический вариант.
  5. Факт партии и отправления возвращаем через подтверждённую операцию модуля либо согласованный операторский шаг. Состав заказа не меняем из-за ошибки сопоставления.
  6. Читаем принятый результат и сверяем количества; JWT или успешный ответ GraphQL не заменяет проверку разрешённой бизнес-операции.
  7. После обновления модулей, изменения схемы или отмены начатой сборки спорные задания блокируются до проверки. Повторное сообщение сверяется с уже принятым заказом.

Результат: Процесс привязан к установленной схеме и правам, а не к абстрактному наличию GraphQL.

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

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

Варианты и остаток магазина

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

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

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

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

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

  • Наличие GraphQL-схемы не подтверждает inventory mutation.

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

Задача: Не продолжать обмен по устаревшей схеме.

Когда начинается: Изменена версия OXID, GraphQL-модуля или кастомного расширения.

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

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

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

  • README текущей ветки не является матрицей совместимости всех старых редакций.

Возврат кастомного варианта в конкретный магазин

Задача: Сохранить связь возвращённого товара с историческим заказом, физическим вариантом и решением продавца.

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

  1. Продавец указывает installation/shop, исходный order/line и исполненную партию. Склад использует сохранённое соответствие варианта и опций на момент отгрузки; нынешнее название товара не заменяет историческую связь.
  2. Проверяем, что продавец, владелец товара и склад приёмки относятся к тому же клиентскому контуру. Возврат из другого subshop без подтверждённого соответствия направляется оператору.
  3. Склад фиксирует полученное количество, комплектность, состояние и результаты осмотра. Нераспознанная кастомная опция остаётся в карантине до решения продавца.
  4. По согласованному правилу разделяем годный запас, брак и товар на дополнительной проверке. Коммерческое разрешение возврата само по себе не увеличивает доступное наличие.
  5. Передаём результат через подтверждённую операцию установленного модуля либо явно согласованное действие оператора. Сохраняем обратный номер и перечитываем результат, если контракт это позволяет; ошибку прав не обходим другим пользовательским токеном.
  6. Учёт продавца отдельно подтверждает денежное решение и документы. Повтор того же сообщения сверяется с ранее принятой партией и не создаёт вторую складскую приёмку.
  7. Закрываем возврат после сверки первоначально отгруженного, фактически возвращённого и возвращённого в продажу количества. Спорный состав и неподтверждённую обратную запись сохраняем с ответственным.

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

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

  • Прочитанные Base/Storefront документы не подтверждают универсальную return mutation; способ обратной записи остаётся частью проверки установки.
  • Изменение модуля или кастомной схемы во время возврата требует сверки старой и новой структуры до повтора.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиЗаказ установленного OXIDДоступ и коммерческий допуск определяются реальными модулями и кастомизацией.
SKU и вариантыКаталог OXID и складская картаВарианты и опции проверяются на фактической схеме.
Остатки и резервНазначенный складской учётЗапись наличия не предполагается из наличия storefront GraphQL.
СтатусыМагазин и складJWT-аутентификация не устанавливает допустимый бизнес-переход.
ДокументыERP/учёт магазинаДокументы не выводятся из одного GraphQL-запроса заказа.
ВозвратыПродавец и принимающий складВозврат связывается с историческим вариантом и результатом осмотра.

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

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

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

  • Редакция и версия OXID eShop, список интеграционных модулей и их документация.
  • Карта вариантов, магазинов и складов, если используется несколько витрин.
  • Пример заказа с частичной сборкой и правило определения оплаты.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

  • Наличие developer-документации не означает установленный API в магазине клиента.
  • Кастомизация заказа и товарных вариантов может менять доступные объекты и правила обновления.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Новые прочитанные разделы относятся к документации GraphQL 13.0; архивные README ветки b-7.6.x сохраняют другую версионную область. Для клиентской установки необходимы её lockfile, редакция, subshops и активные модули.
Стоимость и запуск

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

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

Можно ли оценить подключение без списка модулей?

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

Можно ли оценить подключение без списка модулей?

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

Как передавать варианты одного родительского товара?

Каждому физическому варианту назначим отдельное соответствие SKU. Родительская карточка не должна стать единицей складского отбора.

Официальный GraphQL-модуль уже означает подключаемый складской API?

Он подтверждает наличие компонента. Нужно проверить установку, версию, схему и права конкретных операций; storefront-доступ может не позволять читать все заказы.

Можно не проверять обмен после обновления OXID?

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

Если нужного поля нет в introspection, значит API не поддерживает операцию?

Не обязательно: OXID документирует фильтрацию схемы по правам роли. Проверим установленный модуль, версию, токен и группу пользователя. Если нужного разрешённого контракта нет, согласуем отдельную разработку или операторский шаг; права не расширяются автоматически.

Можно ли увеличить остаток сразу после разрешения возврата?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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