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

Skirbo +
ROZETKA

Предлагаем начать с подтверждённых заказов для вашего склада: фиксировать состав до сборки, возвращать номер отправления и отдельно принимать возвраты с осмотром товара.

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

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

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

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

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

Наличие предложенияSkirbo → Pricecreator/ROZETKAОбсудим в составе подключения

Утвердить offer id, единицу и единственного владельца количества; XML и API не считать одним контрактом.

Номер отправления и этап исполненияSkirbo → ROZETKAОбсудим в составе подключения

Возвращать принятый номер ТТН и подтверждать отображение; передачу перевозчику фиксировать отдельно.

Фактический возвратСклад → продавец ROZETKAОбсудим в составе подключения

Состав и состояние принятых единиц; финансовое действие согласует продавец.

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

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

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

ROZETKA Marketplace: кабинет продавца в Украине. Основной сценарий — исполнение заказов на своём складе или складе фулфилмента, использующего Skirbo. Фулфилмент самой ROZETKA и товарный контур Pricecreator рассматриваются отдельно.

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

Официальная справка описывает работу через кабинет и XML/Excel в Pricecreator. На страницах есть ссылка на Seller API, но доступное чтение портала API не раскрыло схемы методов. Автоматический обмен заказами оценивается после их получения; интерфейс кабинета не объявляется API-контрактом.

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

  1. Получают номер заказа, товарные строки, получателя, доставку и статус оплаты из выбранного кабинета. До проверки API используется согласованный операторский маршрут с той же внешней ссылкой.
  2. Отбирают схему собственного исполнения, определяют клиента Skirbo и склад. Заказы фулфилмента ROZETKA не должны создавать второе задание на вашем складе.
  3. Каждую строку связывают с предложением и конкретным SKU/вариантом. Менеджер подтверждает количество и единицу; цена и валюта сохраняются как исходные коммерческие данные.
  4. Склад резервирует и собирает принятую редакцию. Изменившийся состав или адрес ставит выдачу на паузу до согласования с менеджером.
  5. Один выбранный контур создаёт отправление; номер ТТН связывают с заказом и коробкой, затем вносят в ROZETKA разрешённым способом.
  6. Проверяют, что номер и ожидаемый этап отражены в заказе, после чего физически передают коробку перевозчику и сохраняют складской факт передачи.
  7. При потере ответа перечитывают или проверяют кабинет до повтора. Расхождение состава, трека или модели исполнения разбирают по исходному заказу без новой сборки.

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

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

Подтверждённый заказ своего склада

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

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

  1. Получают номер заказа, товарные строки, получателя, доставку и статус оплаты из выбранного кабинета. До проверки API используется согласованный операторский маршрут с той же внешней ссылкой.
  2. Отбирают схему собственного исполнения, определяют клиента Skirbo и склад. Заказы фулфилмента ROZETKA не должны создавать второе задание на вашем складе.
  3. Каждую строку связывают с предложением и конкретным SKU/вариантом. Менеджер подтверждает количество и единицу; цена и валюта сохраняются как исходные коммерческие данные.
  4. Склад резервирует и собирает принятую редакцию. Изменившийся состав или адрес ставит выдачу на паузу до согласования с менеджером.
  5. Один выбранный контур создаёт отправление; номер ТТН связывают с заказом и коробкой, затем вносят в ROZETKA разрешённым способом.
  6. Проверяют, что номер и ожидаемый этап отражены в заказе, после чего физически передают коробку перевозчику и сохраняют складской факт передачи.
  7. При потере ответа перечитывают или проверяют кабинет до повтора. Расхождение состава, трека или модели исполнения разбирают по исходному заказу без новой сборки.

Результат: Заказ, коробка и отправление связаны; созданная ТТН не подменяет факт отгрузки.

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

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

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

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

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

  1. Передают запрос менеджеру и проверяют, допускает ли текущий этап редактирование. Склад сам не меняет коммерческие условия.
  2. До выдачи менеджер утверждает новую редакцию, а склад пересчитывает резерв и проверяет ранее упакованные единицы.
  3. Если отправление в магазины ROZETKA уже создано, используют предусмотренный маршрут изменения отправления/обращения в поддержку. Не имитируют разрешение сменой статуса в локальной системе.
  4. После принятого изменения повторно сверяют заказ и этикетку. В журнале сохраняют прежнюю и новую редакции и подтверждение ответственного.

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

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

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

Остаток Pricecreator без двойного вычитания

Задача: Согласовать складское количество и автоматические изменения канала.

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

  1. По offer id и карте варианта выбирают нужное предложение; отдельно фиксируют, включено ли в Pricecreator автообновление при заказе.
  2. Владелец учёта определяет, кто рассчитывает доступный остаток и как учитываются уже принятые резервы. Два контура не вычитают одну продажу повторно.
  3. Готовят обновление в подтверждённом формате для нужного магазина; для исчезнувших SKU явно выбирают нулевое наличие или согласованное отключение.
  4. Проверяют результат в Pricecreator и на стороне ROZETKA после принятия обновления. Неуспешная либо частичная выгрузка не обнуляет весь ассортимент.

Результат: Витрина получает осмысленное количество, а повтор выгрузки не уменьшает остаток второй раз.

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

  • Файл каталога не подтверждает получение заказов и не заменяет договор API.

Возврат по строкам после осмотра

Задача: Сопоставить возвратное оформление с фактически прибывшими единицами.

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

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

Результат: История возврата отражает реальные единицы и отдельное финансовое решение.

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

  • Возврат комиссии на баланс магазина не доказывает возврат денег покупателю.

Свой склад и фулфилмент площадки

Задача: Сохранить две разные цепочки исполнения без двойной сборки.

Когда начинается: Магазин продаёт товары из собственного запаса и со склада ROZETKA.

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

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

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

  • Страница интеграции не обещает доступность новых поставок на фулфилмент ROZETKA.

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

ДанныеОтветственный источникПравило обмена
Заказ, цена и оплатаПродавец в ROZETKAСклад получает принятую редакцию и не переписывает коммерческие условия.
Предложение и вариантКаталог/Pricecreator + карта SKUoffer id не заменяет SKU клиента склада.
Физический остаток и резервСклад фактического исполненияЗапасы площадки и собственного склада не суммируются без модели.
Публикуемое наличиеОдин согласованный контурУчесть автоизменение Pricecreator при заказе/отмене.
ТТН и перевозкаВыбранный отправитель и перевозчикСоздание документа, передача и доставка — разные факты.
Возврат и деньгиСклад — осмотр; продавец — подтверждение и расчётВозврат товара, комиссии и оплаты покупателю различаются.

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

  • Какие методы и права разрешены вашему магазину для чтения заказов и записи статусов?
  • Как в ответе API определяется собственный склад и фулфилмент площадки?
  • Включено ли автообновление Pricecreator и какой контур пишет доступное количество?
  • Возобновлена ли приёмка новых поставок на фулфилмент ROZETKA для вашего магазина?
  • Каким API-методом отражаются осмотр, частичное подтверждение и повтор?
Перед оценкой

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

  • Указать магазин и модель исполнения ROZETKA.
  • Подготовить соответствие артикулов и товарных предложений.
  • Описать порядок подтверждения, изменения и упаковки заказа.
  • Обезличенные заказы обеих моделей исполнения, пример корректировки и возврата.
  • Состояние автообновления остатка Pricecreator и пример действующего XML/Excel-обмена.
  • Доступная роль кабинета и отдельно документация методов Seller API; публичная заявка не предназначена для ключей.
  • Кто подтверждает заказ, создаёт отправление и оформляет возврат денег.
Границы сценария

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

  • Не все поля заказа можно менять после перехода к отгрузке.
  • Для фулфилмента ROZETKA действуют отдельные ограничения редактирования.
  • Товарная выгрузка и API заказов требуют самостоятельной проверки.
  • Портал Seller API не раскрыл читаемую схему при проверке; endpoint, авторизация и лимиты не заявляются.
  • ТТН может появиться до физической передачи коробки перевозчику.
  • Исчезновение товара из XML не должно молча трактоваться как нулевое наличие.
  • В прочитанной справке приёмка на фулфилмент площадки временно приостановлена; требуется актуальное подтверждение для новых поставок.
  • Страна продавца, расчёты и документы проверяются в украинском контуре; российские правила автоматически не применяются.
Стоимость и запуск

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

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

Подготовьте заказ ROZETKA со своего склада, карту offer id → SKU, пример возврата и настройки остатка Pricecreator — по ним оценим обмен без двойной сборки и списания.

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

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

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

Склад может получать только собственные заказы?

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

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

Это зависит от настройки импорта Pricecreator. В проекте согласуем явное отключение или нулевое наличие и проверим отражение на площадке.

Созданная ТТН означает, что заказ уже отгружен?

Нет. Склад отдельно фиксирует передачу коробки перевозчику, а ROZETKA использует соответствующие этапы и дальнейший трекинг.

Когда возврат снова доступен к продаже?

После физической приёмки, проверки варианта и оценки качества. Возвратное оформление или его трек сами по себе остаток не создают.

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

Сначала требуется подтверждение площадки: прочитанная инструкция содержит уведомление о временной приостановке приёмки. Возможности собственного склада оцениваются отдельно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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