Обсудить задачу
Доставка

Skirbo +
SafeRoute

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

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

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

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

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

cmsId + shopId + внешний id; количество и артикулы сопоставляются внутри магазина.

Подтверждение и резервSkirbo ↔ SafeRouteОбсудим в составе подключения

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

KitSkirbo ↔ SafeRouteОбсудим в составе подключения

Уникальный vendorCode в магазине и products с внешними ID; состав хранится по версии.

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

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

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

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

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

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

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

Прочитана документация API v2: Order, создание и чтение заказа, подтверждение, проверка остатков, комплекты и возвратные заявки. Доступ аккаунта и действующие справочники статусов проверяются до разработки.

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

  1. Получить строки заказа, продавца, склад и доступное количество; зафиксировать версию состава.
  2. Сопоставить shopId, SKU и внешний Order. При shopId адрес и настройки забора берутся из склада магазина — переданный вручную адрес не должен маскировать неправильную привязку.
  3. Создать черновик, сохранить его id и проверить остатки; проверка check-rests относится к черновикам.
  4. Согласовать подтверждение и при необходимости разрешение предзаказа; физический склад собирает только принятое задание.
  5. После комплектования вернуть фактические количества и связать их с isPacked и доступным результатом внешнего заказа.
  6. Повторно прочитать Order: проверить подтверждённый состав, trackNumber и ошибки, отдельно записать передачу коробок.
  7. Если часть партии не подтверждена, не считать весь список успешным: проверить каждый заказ и направить дефицит ответственному.

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

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

Подтверждение заказа конкретного магазина

Задача: Исключить неправильный адрес забора и преждевременное комплектование.

Когда начинается: Заказ согласован продавцом для отправки через SafeRoute.

  1. Получить строки заказа, продавца, склад и доступное количество; зафиксировать версию состава.
  2. Сопоставить shopId, SKU и внешний Order. При shopId адрес и настройки забора берутся из склада магазина — переданный вручную адрес не должен маскировать неправильную привязку.
  3. Создать черновик, сохранить его id и проверить остатки; проверка check-rests относится к черновикам.
  4. Согласовать подтверждение и при необходимости разрешение предзаказа; физический склад собирает только принятое задание.
  5. После комплектования вернуть фактические количества и связать их с isPacked и доступным результатом внешнего заказа.
  6. Повторно прочитать Order: проверить подтверждённый состав, trackNumber и ошибки, отдельно записать передачу коробок.
  7. Если часть партии не подтверждена, не считать весь список успешным: проверить каждый заказ и направить дефицит ответственному.

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

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

  • Подтверждение списка может вернуть ошибку из-за одного заказа.
  • Два контура резерва требуют единого владельца, иначе доступный остаток будет уменьшен дважды.

Комплект из нескольких SKU

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

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

  1. Сопоставить vendorCode комплекта внутри одного shopId и состав products по ID товаров.
  2. Склад разукомплектовывает задание в компоненты по согласованной версии набора и проверяет количество.
  3. Результат сборки связывается с комплектом и компонентами; изменение набора после заказа требует новой версии.

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

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

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

Заявка на возврат и обратная приёмка

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

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

  1. Связать заявку return с исходным Order и причиной; отдельно определить, нужна ли заявка перевозчику или новый обратный заказ duplicate-back.
  2. Проверять результат обработки заявки и события перевозки; успешный запрос сам по себе не доказывает возврат.
  3. Склад принимает фактические позиции, фиксирует состояние и расхождения; только после разрешения меняется доступный остаток.

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

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

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

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

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

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

  • Какой склад связан с каждым shopId и кто меняет эту настройку?
  • Допускается ли preOrder при нехватке товара?
  • Что нужно бизнесу: return действующего отправления или новый обратный заказ?
Перед оценкой

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

  • Аккаунт с подходящей ролью, список shopIds и warehouseIds.
  • Таблица SKU и комплектов по каждому магазину, правила резерва и предзаказа.
  • Согласованные справочники статусов и образцы дефицита, подтверждения списка и возврата.
Границы сценария

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

  • Дата фильтра dateFrom/dateTo зависит от выбранного списка заказов: единая дата обновления не подтверждена.
  • PATCH разрешён только для перечисленных документацией полей; произвольную замену состава нельзя предполагать.
  • Заявки на возврат и продление хранения не гарантируют исполнение перевозчиком. Международные поля не подтверждают доступность всех стран.
Стоимость и запуск

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

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

Для оценки нужны один магазин SafeRoute, его склад, пример набора и один заказ с дефицитом или возвратом.

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

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

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

Пустой check-rests означает резерв?

Это результат проверки достаточности для черновиков. Резерв и подтверждение — отдельные операции; между проверкой и действием запас может измениться.

Когда считать возврат законченным?

После фактической приёмки и осмотра нужных позиций. Ответ return означает создание заявки, а не возвращённый товар.

Можно одним артикулом описать набор для двух продавцов?

Сопоставление включает магазин. vendorCode комплекта уникален в пределах магазина; его состав нельзя переносить другому владельцу автоматически.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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