Обсудить задачу
Автоматизация

Skirbo +
XWAY Seller API

Оценить один FBS-кабинет: получить разрешённый заказ, выполнить физическую сборку в Skirbo и сверить передачу упаковочных данных обратно через XWAY.

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

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

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

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

Нужно подтвердить внешний ID заказа и строки, кабинет, версию, количество и вариант товара. Это требования к контракту, а не имена полей XWAY.

Таблица товара и складаКаталог и учёт клиента → таблица соответствий адаптераОбсудим в составе подключения

Связать клиентский SKU/вариант, карточку канала и склад. Одинаковые наименования или номер заказа в разных кабинетах не объединяются.

Доступный остатокНазначенный складской учёт → XWAY → выбранный каналОбсудим в составе подключения

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

Упаковка, места и этикеткиСклад ↔ XWAY ↔ кабинетОбсудим в составе подключения

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

Отмена, возврат и отчётКанал через XWAY → обработка исключений и учёт клиентаОбсудим в составе подключения

Нужно раздельно установить операционные события и отчётные строки возврата. Денежное возмещение и физическая приёмка имеют своих владельцев.

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

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

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

XWAY Seller API рассматривается как отдельный интеграционный продукт для продавца с собственной учётной системой. Реклама XWAY ADV и агентское сопровождение не входят в эту карточку. Начальный сценарий ограничен конкретным российским кабинетом и FBS-складом. Поддержка продукта на уровне предложения не подтверждает каждую операцию и схему FBO/FBS/Express.

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

Поставщик описывает обмен по API. README раскрывает принцип уведомления/опроса результата длительных операций; ReDoc не раскрыл схемы методов в доступном чтении. Конкретные endpoints, поля, авторизация и события заказов требуют текущего контракта.

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

  1. На этапе оценки выбирают способ получения изменений, подтверждённый контрактом, и контрольный интервал первоначальной загрузки. Произвольный webhook не предполагается.
  2. Адаптер сохраняет исходный объект, кабинет, внешний номер и версию. Сопоставляет строку с вариантом SKU и конкретным складом; неизвестные связи блокируют автоматическое задание.
  3. По устойчивому ключу создаётся одно задание склада. Оператор проверяет наличие и резерв, подбирает товар, измеряет и упаковывает места.
  4. После проверки стадии в канал возвращаются только разрешённые упаковочные данные. Имена полей и порядок вызовов фиксируют из полученной спецификации.
  5. Результат читается повторно из подтверждённого источника; сверяются заказ, состав мест и стадия. Этикетка прикрепляется к той версии упаковки, которую принял канал.
  6. Физическую передачу подтверждает склад. Расхождения состава, отказ метода и неизвестный результат после тайм-аута остаются отдельными задачами разбора.
  7. При повторе сообщения адаптер проверяет существующее задание. Перед повтором мутации выясняет, применено ли прежнее действие; автоматический повтор без такой проверки не разрешается.

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

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

Один FBS-кабинет: заказ → сборка → обратная сверка

Задача: Проверить законченный обмен на ограниченном наборе заказов.

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

  1. На этапе оценки выбирают способ получения изменений, подтверждённый контрактом, и контрольный интервал первоначальной загрузки. Произвольный webhook не предполагается.
  2. Адаптер сохраняет исходный объект, кабинет, внешний номер и версию. Сопоставляет строку с вариантом SKU и конкретным складом; неизвестные связи блокируют автоматическое задание.
  3. По устойчивому ключу создаётся одно задание склада. Оператор проверяет наличие и резерв, подбирает товар, измеряет и упаковывает места.
  4. После проверки стадии в канал возвращаются только разрешённые упаковочные данные. Имена полей и порядок вызовов фиксируют из полученной спецификации.
  5. Результат читается повторно из подтверждённого источника; сверяются заказ, состав мест и стадия. Этикетка прикрепляется к той версии упаковки, которую принял канал.
  6. Физическую передачу подтверждает склад. Расхождения состава, отказ метода и неизвестный результат после тайм-аута остаются отдельными задачами разбора.
  7. При повторе сообщения адаптер проверяет существующее задание. Перед повтором мутации выясняет, применено ли прежнее действие; автоматический повтор без такой проверки не разрешается.

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

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

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

Один автор остатков для нескольких каналов

Задача: Исключить перезапись доступного количества конкурирующими интеграциями.

Когда начинается: Учёт склада изменился после приёмки, резерва или отгрузки.

  1. Утвердить владельца запаса и таблицу соответствия склада и варианта товара в каждом кабинете.
  2. Рассчитать согласованную доступность и сохранить её версию. Показатель в отчёте продаж не использовать как исходный запас.
  3. Через подтверждённый метод XWAY передать только согласованные пары SKU/склад. Семантика полного снимка и частичного изменения проверяется заранее.
  4. Проверить принятие отдельных строк и затем состояние целевого канала. Ошибка одного SKU не превращается в успех всего пакета.
  5. При сбое сохранить неподтверждённую версию и сверить канал перед повтором; старое количество не должно перезаписать более новое.

Результат: У каждого изменения есть автор, версия и подтверждение нужного кабинета.

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

  • Состав полей ошибок, квоты и правила частичного ответа пока неизвестны.

Отмена и возврат: операционный факт отдельно от отчёта

Задача: Не считать возвращённым товар, который ещё физически не поступил.

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

  1. Сверить внешний заказ, строки и фактическую стадию склада; до выдачи проверить возможность остановки сборки.
  2. После передачи создать ожидание возврата с внешним основанием. Отчётную корректировку денег хранить отдельно от маршрута обратного движения.
  3. При поступлении оператор проверяет количество, вариант и состояние товара, фиксирует расхождение и решение о пригодности.
  4. Только подтверждённая приёмка меняет складской запас. Бухгалтерия сверяет компенсацию/возмещение с финансовым источником.
  5. Повторная строка отчёта или событие связывается с существующим основанием возврата; её повторная загрузка не создаёт вторую приёмку.

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

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

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

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

ДанныеОтветственный источникПравило обмена
Заказ, строка, коммерческий статусМаркетплейс и кабинет продавцаСклад принимает согласованную версию. В адаптере хранится связь кабинета, заказа и внутреннего задания.
SKU и карточкаКаталог продавцаВладелец утверждает соответствия вариантов и единиц; изменение карточки не меняет товар в уже выданном заказе.
Остаток и резервОдна назначенная система складского учётаXWAY получает согласованный результат. Параллельная запись из двух интеграций в один склад исключается проектным правилом.
Сборка и передачаСотрудник складаСканирование, упаковка и выдача фиксируются физически; API-статус дополняет эти факты.
Возврат и деньгиКанал — основание; склад — факт; бухгалтерия — возмещениеОтчётная строка не заменяет проверку поступившего товара и не является банковской выпиской.

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

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

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

  • Действующий коммерческий доступ именно к Seller API, имя ответственного технического контакта и читаемая версия спецификации.
  • Матрица доступов по кабинету, площадке, складу и схеме продаж; выдача ключей через защищённый канал.
  • Обезличенные запрос/ответ заказа, упаковки, ошибки, отмены и возврата; правила обновления и частичного исполнения.
  • Подтверждённая авторизация, тестовый контур, квоты, время жизни событий и процедура восстановления пропусков.
  • Согласованный владелец заказа, SKU, остатка, документов и финансов; список других интеграций, пишущих в тот же канал.
Границы сценария

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

  • API существует как опубликованное предложение; доступный ReDoc не раскрыл содержание схем в использованном читателе. Это ограничение чтения, а не доказательство отсутствия API.
  • Не подтверждены endpoints, конкретные поля, модель авторизации, идемпотентность и гарантии доставки событий.
  • Наличие этикеток или статусов в описании продукта не подтверждает их формат и доступность для каждого кабинета.
  • Рекламная автоматизация XWAY ADV и услуги агентства не включены в этот сценарий.
  • Цены и сроки из кейсов не являются оценкой подключения Skirbo. Российская география не переносит правила на зарубежные кабинеты.
Стоимость и запуск

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

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

Подготовьте читаемую спецификацию Seller API, один кабинет и обезличенные примеры заказа, упаковки и возврата — проверим контракт и состав пилота.

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

Можно начать разработку только по странице ReDoc?

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

В XWAY нужен отдельный интерфейс склада?

Seller API предназначен для обмена с собственной учётной системой. В проекте оператор выполняет складские действия в согласованном рабочем интерфейсе, а адаптер передаёт подтверждённые результаты.

Можно оставить две интеграции остатков одновременно?

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

Успешный запрос означает, что заказ отгружен?

Принятие запроса, стадия канала и физическая передача проверяются отдельно. В приёмку входит чтение результата и складское подтверждение факта.

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

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

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

Изучаем возможность. Подготовлен сценарий оценки, но методы, права и форматы конкретного Seller API ещё требуют читаемой спецификации. Работа коннектора Skirbo и клиентский пилот не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

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

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

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

Весь каталог →
Изучаем возможность

Автоматизация

Albato

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

Сценарий подключения
Изучаем возможность

Автоматизация

Boomi Integration

Связь корпоративного интеграционного контура с операциями фулфилмента и контролем результата.

Сценарий подключения
Ваш процесс → следующий шаг

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

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

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

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

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

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

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

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

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

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

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

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