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

Skirbo +
MetaShip

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

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

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

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

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

Проект: shop.id/shop.number, warehouse.id, получатель и places[].items связывают один заказ клиента с фактически упакованными местами. Транспортный учёт не подменяет остатки склада.

Регистрация и трекMetaShip → SkirboОбсудим в составе подключения

Разбирать id и type ответа создания: HTTP 201 допускает FailedOrder. Получить состояние заказа и трек перевозчика; сообщение о создании и регистрация у службы — разные подтверждения.

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

Получить PDF по действующему заказу, сопоставить коробку и внешний номер. Акт партии и сканирование физической передачи подтверждаются отдельно.

Статусы и событияMetaShip → SkirboОбсудим в составе подключения

Обрабатывать StatusUpdate и OrderRegistered с защитой от повторов; при расхождении перечитать заказ и историю. state хранить отдельно от status и от складского события выдачи.

Клиентский возвратПокупатель / оператор → MetaShip → складОбсудим в составе подключения

Проект возврата с type=return и разрешённой службой. Внутренняя связь с первоначальным заказом нужна Skirbo, даже если перевозчик её не требует. Доступный запас меняется только после приёмки.

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

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

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

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

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

MetaShip рассматривается как API доставки для интернет-магазина и фулфилмента в России. Его магазин, склад отправления, транспортный заказ и партия — отдельные объекты. Этот материал не описывает API MetaShip.WMS, PIM.WMS или мультиклиентный складской биллинг; название PIM Solutions не означает систему управления товарным контентом.

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

Опубликован API v2 с bearer-токеном, чтением заказов и истории статусов, PDF-этикетками и webhook-событиями. Подключение требует проверки ключа клиента, магазина, склада и настройки конкретной службы. Сохранённая спецификация содержит ошибки; автоматическая генерация клиента без разбирательства не считается готовым подключением.

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

  1. Получить из учётного заказа SKU, количество, получателя, оплату, вес и габариты фактических мест; сохранить версию этих данных.
  2. Сопоставить клиента и магазин с shop.id, номер заказа с shop.number, склад с warehouse.id; проверить подключение выбранной службы и способ доставки.
  3. Сотрудник сканирует каждое место и завершает упаковку. Склады разных продавцов не объединяются по одинаковому названию.
  4. Передать заказ через согласованный API v2; сохранить id, type и исходный результат. HTTP 201 с FailedOrder оставить задачей разбора, выдачу не разрешать.
  5. Прочитать заказ или обработать OrderRegistered: сверить регистрацию, перевозчика и data.deliveryService.trackingNumber. Не путать состояние обработки с движением посылки.
  6. Получить этикетку для актуальной заявки, связать её с коробкой; при физической передаче сотрудник отдельно фиксирует места, время и документ передачи.
  7. Если ответ потерян, обнаружена ошибка регистрации или не совпал трек, остановить выдачу и проверить существующую заявку; автоматический повтор создания без сверки запрещён проектным правилом.

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

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

Оформление отправления без ложного успеха

Задача: Получить подтверждённую транспортную заявку для конкретных упакованных коробок.

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

  1. Получить из учётного заказа SKU, количество, получателя, оплату, вес и габариты фактических мест; сохранить версию этих данных.
  2. Сопоставить клиента и магазин с shop.id, номер заказа с shop.number, склад с warehouse.id; проверить подключение выбранной службы и способ доставки.
  3. Сотрудник сканирует каждое место и завершает упаковку. Склады разных продавцов не объединяются по одинаковому названию.
  4. Передать заказ через согласованный API v2; сохранить id, type и исходный результат. HTTP 201 с FailedOrder оставить задачей разбора, выдачу не разрешать.
  5. Прочитать заказ или обработать OrderRegistered: сверить регистрацию, перевозчика и data.deliveryService.trackingNumber. Не путать состояние обработки с движением посылки.
  6. Получить этикетку для актуальной заявки, связать её с коробкой; при физической передаче сотрудник отдельно фиксирует места, время и документ передачи.
  7. Если ответ потерян, обнаружена ошибка регистрации или не совпал трек, остановить выдачу и проверить существующую заявку; автоматический повтор создания без сверки запрещён проектным правилом.

Результат: У заказа сохраняется цепочка исходная версия → места → MetaShip id → трек → отдельный факт передачи.

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

  • Принятие записи MetaShip не доказывает, что служба доставки зарегистрировала отправление.
  • Синхронный метод создания помечен deprecated; новый обмен не строится на нём автоматически.

Повторное событие и частичное вручение

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

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

  1. Проверить отправителя уведомления по согласованным параметрам; сопоставить orderId с клиентом, магазином и внешней заявкой.
  2. Сохранить исходные status, statusTime, deliveryServiceStatusTime и время приёма отдельно от state.
  3. Повторный OrderRegistered обновляет сведения существующего заказа и не создаёт новую выдачу, накладную или списание.
  4. При неясной последовательности прочитать заказ и его историю; событие служит уведомлением, а сверка восстанавливает пропуск.
  5. Для partially-delivered открыть разбор по строкам и местам. До получения состава вручения не считать весь заказ доставленным и не оприходовать ожидаемый возврат.

Результат: Доставка и расхождения отражаются без двойного складского движения.

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

  • Документация прямо допускает повтор OrderRegistered при восстановлении заказа.
  • Формальный enum статуса не доказывает наличие построчного состава частичного вручения.

Клиентский возврат с отдельной приёмкой

Задача: Принять возвращённый товар по проверенной цепочке доставки и осмотра.

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

  1. В Skirbo открыть собственную заявку возврата со ссылкой на исходный заказ, SKU, ожидаемое количество и склад назначения.
  2. Выбрать разрешённую службу и условия договора. В документе MetaShip возврат обозначается type=return; прямая отправка и обратный маршрут могут использовать разные службы.
  3. Уточнить пункт сдачи: для 5Post сохранённая инструкция не требует intakePointCode; для Почты России указаны имя отправителя в comment и отдельная опция упаковки. Эти особенности не переносить на другие службы.
  4. Сохранить номер обратного отправления и сообщить покупателю согласованные действия; передача товара покупателем в пункт — отдельный физический шаг.
  5. По результату обратной перевозки склад принимает и пересчитывает товар, фиксирует состояние и недостачу; только разрешённые после проверки единицы возвращаются в доступный запас.
  6. Сверить ожидаемые и фактические строки. Возмещение денег решается отдельным процессом продавца, транспортный статус его не выполняет.

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

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

  • Поддержка CSE расходится между wiki и описанием поля в YAML: до проверки не обещается.
  • Повторное уведомление о возврате не создаёт повторное оприходование.

Отмена до выдачи и отдельная судьба забора

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

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

  1. Заблокировать выдачу и определить текущую регистрацию заказа и наличие отдельного забора.
  2. Выполнить разрешённое для текущего состояния изменение либо удаление заказа; конфликт 409 передать оператору, а не трактовать как отмену.
  3. Если назначен забор, отдельно проверить его отмену через описанный PATCH с status=cancelled или согласованную операторскую процедуру.
  4. Перечитать результат. Только после подтверждения судьбы старого заказа и забора создавать замену, связывать старый и новый номера и менять этикетку.

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

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

  • DELETE заказа и отмена забора — разные операции.
  • Фактическую передачу уже выданного груза нельзя отменить удалением API-записи.

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

ДанныеОтветственный источникПравило обмена
Заказ и состав SKUПродавец / система заказовСохранять клиента, внутренний заказ и версию; артикул товара и штрихкод грузового места — разные идентификаторы.
Физические места и доступный запасСклад SkirboСостав и вес подтверждает упаковка. Создание отправления не выполняет складское списание или приёмку.
Магазин, склад и подключение службыАккаунт клиента MetaShipshop.id и warehouse.id сопоставляются в области клиента/договора; совпадение названий не разрешает доступ другому продавцу.
Регистрация и трекMetaShip и выбранная служба доставкиХранить MetaShip id, номер перевозчика и историю замены; различать техническую регистрацию и физическое движение.
state и statusMetaShip — состояние обработки; перевозчик — транспортные событияПоля и два времени статуса сохраняются раздельно; складское подтверждение не выводится из одного статуса.
Возврат и деньгиПеревозчик — обратный маршрут; склад — приёмка; продавец — возврат средствТранспортное завершение не делает все единицы годными к продаже и не подтверждает денежное возмещение.

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

  • Какой магазин, склад, договор и служба будут проверены первыми?
  • Как выглядит FailedOrder и что подтверждает регистрацию у службы в этом аккаунте?
  • Как сопоставить строки частичного вручения и фактически вернувшиеся единицы?
  • Какая версия схемы устраняет 13 унаследованных ошибок и где отдельный список диагностики?
  • Поддерживается ли CSE-return в выбранном договоре и как подтверждается отмена забора?
Перед оценкой

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

  • Один клиент, его юридическое лицо, согласованный магазин и склад отправления; сопоставление внутренних ID с MetaShip shop.id и warehouse.id.
  • Разрешённый доступ API и договорный режим конкретной службы; секреты передаются через защищённый процесс, не через форму на странице каталога.
  • Обезличенные примеры ответа Order и FailedOrder, этикетки, события OrderRegistered и случая частичного вручения.
  • Правило проверки повторов, возврата и отмены забора; отдельный владелец разбора неясной регистрации.
Границы сценария

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

  • Исходный OpenAPI v2 сохранён с 13 ошибками прежнего валидаторного аудита. Разрешение ссылок и чтение YAML не исправляют эти ошибки и не подтверждают работу API.
  • POST /v2/orders/sync помечен устаревшим; его нельзя выбирать основой нового сценария без согласования с поставщиком.
  • В wiki возврат описан для CDEK, Почты России, 5Post и CSE, а описание поля type в сохранённом YAML перечисляет первые три. Возврат CSE требует отдельного подтверждения.
  • Статус partially-delivered сам по себе не раскрывает, какие SKU и количества вручены. Для складской и денежной сверки нужен предметный документ или расширенный ответ.
  • Универсальность отмены, лимит запросов, гарантированный срок доставки webhook и серверная идемпотентность создания по выбранному договору не установлены.
  • Рассмотрен российский процесс. Поддержку Казахстана, Узбекистана, местных налоговых правил и маркировки нужно проверять отдельно.
Стоимость и запуск

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

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

Начнём с одного магазина, склада и службы: нужны обезличенные Order/FailedOrder, пример этикетки, события регистрации и один случай возврата.

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

Почему ответ 201 не означает успешное оформление?

Сохранённая схема допускает ответ с type=FailedOrder. Нужно проверить тип созданной записи и регистрацию у выбранной службы; коробка остаётся на складе до выполнения контрольных условий.

Чем отличаются state и status?

State описывает обработку заявки, например external-processing или failed; status описывает событие доставки, например intransit или partially-delivered. Их следует хранить раздельно и сопоставлять с фактом передачи на складе.

Нужно ли при каждом OrderRegistered повторно списывать товар?

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

Можно ли создать возврат другой службой?

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

Отмена отправления автоматически отменяет приезд курьера?

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

Это подключение MetaShip.WMS и передача всех остатков?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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