Обсудить задачу
Маркетплейсы

Skirbo +
eBay

Предлагаем получать допустимые к исполнению заказы продавца, сопоставлять lineItemId со складскими вариантами и возвращать подтверждённые shipping fulfillments по реальным упаковкам.

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

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

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

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

orderId/lineItemId, вариант, количества и инструкции; отмена и возврат проверяются до резерва.

SKU, offer и доступное количествоSkirbo ↔ Inventory API/действующий контур листинговНужна проверка

Выбрать модель существующих объявлений и единственного владельца остатка.

Shipping fulfillmentSkirbo → eBayОбсудим в составе подключения

После согласования упаковки — строки, количества и трек; ответ подтверждается чтением.

Возврат/отменаПродавец eBay ↔ складОбсудим в составе подключения

Ожидаемый возврат и физическая приёмка отделены от денежного решения.

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

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

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

eBay Sell Fulfillment API для заказов определённого продавца; Inventory API рассматривается как отдельная модель товара и предложения. Материал относится к физическому исполнению разрешённых продавцу заказов. Рынок eBay, страна регистрации продавца и страна склада проверяются отдельно.

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

REST Sell Fulfillment API: чтение заказов и shipping fulfillments, создание подтверждения отправления. OAuth User access token выдаётся после согласия продавца. Inventory API и миграция старых объявлений проверяются отдельно; события не заменяют периодическую сверку заказов.

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

  1. Получают заказ разрешённого аккаунта через getOrder/getOrders, сохраняя orderId, lineItemId, quantity, суммы и валюту без автоматической конвертации. Запросы отмены проверяют через getOrder, потому что cancelRequests в списке getOrders пуст; оплата и возвраты проверяются отдельно.
  2. По аккаунту и рынку выбирают клиента Skirbo, склад и таблицу seller SKU/вариант → складской SKU. Неизвестный вариант направляют менеджеру.
  3. Проверяют адрес фактического участка отгрузки, а не автоматически адрес конечного покупателя: международная программа может задавать промежуточный пункт. Условия этой программы подтверждают отдельно.
  4. Склад резервирует, собирает и закрепляет разные строки за реальными упаковками. Количество сверяют по каждому lineItemId, не суммируя одинаковый SKU из разных строк; произвольное дробление одной строки по трекам не входит в принятый проект.
  5. После физической выдачи сохраняют локальный факт и передают согласованный shipping fulfillment со строками и количествами, перевозчиком и треком. Время отправления должно отражать факт, а не подготовку.
  6. Сохраняют результат создания и Location, сверяют shipping fulfillments и текущий заказ; статусы всей покупки проверяют по всем её строкам.
  7. Если ответ потерян, сначала ищут уже созданный fulfillment по заказу, строкам и треку. Несовпадение отправленных количеств блокирует повтор и передаётся ответственному.

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

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

Заказ продавца → коробка → подтверждение отправки

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

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

  1. Получают заказ разрешённого аккаунта через getOrder/getOrders, сохраняя orderId, lineItemId, quantity, суммы и валюту без автоматической конвертации. Запросы отмены проверяют через getOrder, потому что cancelRequests в списке getOrders пуст; оплата и возвраты проверяются отдельно.
  2. По аккаунту и рынку выбирают клиента Skirbo, склад и таблицу seller SKU/вариант → складской SKU. Неизвестный вариант направляют менеджеру.
  3. Проверяют адрес фактического участка отгрузки, а не автоматически адрес конечного покупателя: международная программа может задавать промежуточный пункт. Условия этой программы подтверждают отдельно.
  4. Склад резервирует, собирает и закрепляет разные строки за реальными упаковками. Количество сверяют по каждому lineItemId, не суммируя одинаковый SKU из разных строк; произвольное дробление одной строки по трекам не входит в принятый проект.
  5. После физической выдачи сохраняют локальный факт и передают согласованный shipping fulfillment со строками и количествами, перевозчиком и треком. Время отправления должно отражать факт, а не подготовку.
  6. Сохраняют результат создания и Location, сверяют shipping fulfillments и текущий заказ; статусы всей покупки проверяют по всем её строкам.
  7. Если ответ потерян, сначала ищут уже созданный fulfillment по заказу, строкам и треку. Несовпадение отправленных количеств блокирует повтор и передаётся ответственному.

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

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

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

Частичная отправка по разным строкам

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

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

  1. До упаковки строят таблицу lineItemId → коробка → количество. Полноту проверяют по всем заказанным единицам, не только по числу строк.
  2. Руководство ограничивает строку одним треком, а прочитанная схема требует держать её компоненты в одной упаковке. Поэтому проект распределяет разные lineItemId по коробкам и не обещает разделение количества одного lineItemId по нескольким трекам.
  3. Для каждой разрешённой коробки создают подтверждение только после соответствующего физического события и сохраняют его внешний идентификатор.
  4. Повторно читают заказ и список fulfillments. Уже подтверждённые строки не включают в следующую посылку заново; недостачу оформляют отдельным исключением продавца.

Результат: Можно проследить, какая часть заказа отгружена и какая ещё ожидает решения.

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

  • Готовый fulfillment нельзя считать свободно редактируемой упаковкой; изменения состава требуют проверки контракта.

Общий SKU для нескольких объявлений

Задача: Сохранить исходный сценарий общего остатка без смешивания SKU и offer.

Когда начинается: Один физический товар продаётся в нескольких листингах или рынках eBay.

  1. Продавец показывает, как созданы объявления; выбирают действующий контур управления и отдельно оценивают миграцию в Inventory API.
  2. Связывают seller SKU и вариант с каждой соответствующей записью offer/листинга и физическим местоположением. Коды разных продавцов не объединяют.
  3. Владелец склада рассчитывает доступный запас после резервов, а коммерческий владелец задаёт распределение по предложениям; это проектное правило, не обещанная функция eBay.
  4. На одном SKU проверяют изменение количества, продажу и повтор обновления. Остатки разных рынков сверяют с общей физической базой, а ошибки отдельных записей не скрывают успехом всего пакета.

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

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

  • Готовый fulfillment-контракт не доказывает возможность менять старый листинг выбранным Inventory-методом.

Отмена, возврат и восстановление пропуска

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

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

  1. Перед сборкой и выдачей заново читают известный orderId через getOrder и проверяют cancelStatus, оплату и возвраты. Пустой cancelRequests из getOrders не является доказательством отсутствия запроса отмены; отменённая покупка остаётся в истории без нового задания.
  2. До выдачи снимают резерв по согласованному разрешению; после выдачи продавец определяет возвратный маршрут и ожидаемые строки.
  3. Склад принимает реальные единицы, проверяет вариант и состояние, выделяет брак. Финансовый возврат или спор не создают складской приход.
  4. Согласованный результат приёмки передают продавцу; отдельный API возврата/спора и его права выбирают после изучения контракта.
  5. После сбоя восстанавливают журнал по известным заказам и подтверждениям; денежные операции не повторяют по одному сетевому тайм-ауту.

Результат: Складская история, состояние заказа и финансовое решение остаются согласованными и раздельными.

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

  • Рабочие выплаты, refund и отмены не выполняются ради исследования документации.

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

ДанныеОтветственный источникПравило обмена
Заказ, оплата и отменаeBay и продавецПеред физической выдачей проверяется текущий коммерческий допуск.
Коммерческие суммы и валютаeBay и финансовый владелец продавцаИсходные значения сохраняются вместе с валютой; склад не конвертирует и не выводит выплату из количества товара.
Seller SKU и вариантКаталог продавцаSKU действует в области аккаунта, а offer связан с рынком.
Остаток и резервSkirbo выбранного физического складаРаспределение по листингам утверждает владелец продаж.
Упаковка и физическая выдачаСкладВнешнее подтверждение основано на реальных строках и количествах.
Shipping fulfillment и трекeBay + согласованный адаптерСохранять внешний ID/Location и проверять readback до повтора.
Возврат и расчётСклад — осмотр; продавец/eBay — решениеВозврат денег и поступление товара не отождествляются.

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

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

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

  • Указать торговые площадки eBay и аккаунты продавца.
  • Предоставить карту SKU, itemId и вариантов.
  • Определить правила консолидации и частичной отгрузки.
  • Страна регистрации аккаунта, рынки продаж, реальная страна склада и доступный маршрут доставки.
  • Подтверждённое право аккаунта продавать и, при необходимости, использовать зарубежный склад.
  • OAuth-согласие продавца и минимальные права по текущим методам; Sandbox отдельно от Production.
  • Обезличенный заказ с несколькими строками, действующий листинг и пример частичной отгрузки.
  • Действующий договор и доступ продавца для его страны, рынка и склада; владелец коммерческих сумм и валюты каждого заказа.
Границы сценария

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

  • Старые объявления могут использовать иной способ управления, чем новые записи Inventory API.
  • Идентификатор заказа не заменяет идентификатор его строки.
  • Набор прав и доступность продаж проверяются для страны аккаунта.
  • Не обещается доступ к eBay любой организации из любой страны; проверяются аккаунт, товар и склад.
  • В прочитанном руководстве есть ограничения разделения одной строки по трекам и изменения готового fulfillment.
  • Старые и новые API-модели листинга требуют отдельной оценки; автоматическая миграция не предполагается.
  • Историческая KB об отменах сопоставлена с текущим OpenAPI v1.20.7: запросы отмены читаются через getOrder. Возможность исправлять готовый fulfillment и финансовый маршрут остаются отдельными проверками.
  • Фактическое получение покупателем не выводится только из состояния отгрузки.
Стоимость и запуск

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

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

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

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

Подойдут уже существующие объявления?

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

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

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

Почему в список сборки попал отменённый заказ?

Выборка неисполненных не доказывает допуск. Кроме статуса оплаты проверяем отмену и возвраты; запросы отмены нужно читать через getOrder, поскольку массив cancelRequests списка getOrders всегда пуст.

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

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

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

Для пользовательских данных требуется согласие продавца и User access token с нужными scopes. Открытый справочник и application token не заменяют это согласие.

Склад в другой стране подключается так же?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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