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

Skirbo +
Mirakl Marketplace

Принять к сборке только свою согласованную часть заказа. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

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

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

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

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

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

Наличие offerSkirbo → Mirakl MarketplaceНужна проверка

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

Отправление продавцаSkirbo → Mirakl MarketplaceНужна проверка

Проверить контракт подтверждения отгрузки и разрешённые перевозчики этого оператора.

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

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

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

Mirakl Marketplace рассматриваем со стороны продавца конкретного оператора площадки. Это не универсальный доступ ко всем клиентам Mirakl: Marketplace, Dropship, Connect и Catalog Manager имеют собственные роли. Фулфилменту нужна привязка seller/shop, offer, заказа и разрешённого отправления.

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

В прочитанном MMP Rest Seller API ключ передаётся в Authorization по HTTPS; для нескольких shops выбирается shop_id. Нужны marketplace URL, выданная seller/shop-роль и правила оператора. Operator credentials и доступ Mirakl Connect не считаются взаимозаменяемыми с этим контрактом.

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

  1. Фиксируем адрес площадки, продукт Mirakl, роль seller и разрешённый shop. Наличие аккаунта другой площадки не считается разрешением на этот контур.
  2. Получаем заказ и строки по документации выданного доступа; отдельно проверяем, требуется ли принятие или отказ продавца до складского допуска.
  3. Сопоставляем товарное предложение и исходную строку со SKU клиента фулфилмента. Offer сохраняется отдельно от каталожного товара, потому что коммерческие условия продавца не равны описанию общей карточки.
  4. Skirbo резервирует и комплектует только разрешённые строки на выбранном складе. Чужие sellers и неутверждённые предложения не включаются в задание.
  5. Возвращаем фактическую партию и трек по подтверждённому методу данного оператора. Частичную отправку используем только если её допускают правила и контракт площадки.
  6. Читаем принятое состояние заказа/отправления или получаем операторское подтверждение, сохраняя связь с исходной строкой. Изменение общего статуса не заменяет проверку количества.
  7. Если предложение не сопоставлено, срок допуска истёк или отмена пришла после отбора, оператор разбирает исключение по правилам площадки. Повторное событие обновляет существующую связь, а не создаёт новую сборку.

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

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

Заказ продавца одной площадки Mirakl

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

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

  1. Фиксируем адрес площадки, продукт Mirakl, роль seller и разрешённый shop. Наличие аккаунта другой площадки не считается разрешением на этот контур.
  2. Получаем заказ и строки по документации выданного доступа; отдельно проверяем, требуется ли принятие или отказ продавца до складского допуска.
  3. Сопоставляем товарное предложение и исходную строку со SKU клиента фулфилмента. Offer сохраняется отдельно от каталожного товара, потому что коммерческие условия продавца не равны описанию общей карточки.
  4. Skirbo резервирует и комплектует только разрешённые строки на выбранном складе. Чужие sellers и неутверждённые предложения не включаются в задание.
  5. Возвращаем фактическую партию и трек по подтверждённому методу данного оператора. Частичную отправку используем только если её допускают правила и контракт площадки.
  6. Читаем принятое состояние заказа/отправления или получаем операторское подтверждение, сохраняя связь с исходной строкой. Изменение общего статуса не заменяет проверку количества.
  7. Если предложение не сопоставлено, срок допуска истёк или отмена пришла после отбора, оператор разбирает исключение по правилам площадки. Повторное событие обновляет существующую связь, а не создаёт новую сборку.

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

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

  • Конкретные методы и сроковые правила ещё нужно получить у выбранного оператора; срок исполнения не обещается.

Наличие предложения продавца

Задача: Не опубликовать физический запас как общий запас всех площадок.

Когда начинается: Изменился доступный объём SKU на обслуживаемых складах.

  1. Карта связывает SKU клиента, offer продавца и площадку; физический stock pool выбирается явно.
  2. Согласованное правило распределяет свободное количество между предложениями разных площадок, сохраняя один владелец резерва.
  3. После публикации по подтверждённому контракту сверяем приём конкретного offer и ошибки, не перезаписывая каталожное описание.

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

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

  • Роль seller может не давать права менять общую каталожную карточку.

Возврат по правилам оператора

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

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

  1. Сохраняем ссылку на площадку, shop, заказ, offer и разрешённое количество.
  2. Склад принимает товар и фиксирует состояние; иной товар или недокомплект выделяется как расхождение.
  3. Передаём результат в разрешённый процесс оператора, а финансовое решение и восстановление доступности подтверждаем раздельно.

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

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

  • API возврата, претензии и документы нельзя выводить из общего портала Mirakl.

Повторная выборка и частично принятый результат отправки

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

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

  1. Для каждой marketplace URL и shop сохраняем собственное окно сверки. Полученные OR11 страницы записываем в долговечный журнал, привязывая order/line ID к клиенту и offer; новое окно закрываем только после обработки всей выборки.
  2. Повторно пришедший заказ сравниваем с сохранённым состоянием и коммерческим допуском. Расширение границы времени или повтор страницы не создаёт второй резерв и не запускает вторую сборку.
  3. Решение о принятии принадлежит продавцу. Если его workflow требует OR21, подтверждаем разрешённые строки и перечитываем заказ; ошибка запрета частичного принятия попадает продавцу, а не обходится приёмом всего объёма.
  4. Склад фиксирует реальные партии и передачу перевозчику. Выбираем подтверждённый оператором маршрут целого заказа либо multiple shipments; нельзя смешать общий ship и неполную физическую партию.
  5. До записи отправления сохраняем order/line, количество, package reference и внутренний ключ операции. При пакетном результате сопоставляем каждую созданную партию с её ответом, а непринятые позиции сохраняем отдельно с причиной.
  6. При потерянном ответе сначала сверяем существующие отправления доступным оператору способом. Не повторяем весь пакет вслепую и не создаём новое физическое отправление только ради исправления API.
  7. После подтверждения сверяем принятые количества, tracking и ещё не исполненные строки. Отмена или возврат идут отдельным процессом продавца и склада; денежный исход подтверждает площадка/учёт.

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

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

  • Новый неизвестный enum не должен разрушать загрузку всей очереди; спорное состояние блокирует только затронутый переход до решения продавца.
  • Права, повтор записи, partial acceptance, multiple shipments и возврат должны быть проверены у конкретного оператора.

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

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

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

  • Какие методы и права доступны конкретному seller/shop?
  • Разрешены ли частичные отправки и как подтверждается результат возврата?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Перед оценкой

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

  • Адрес площадки Mirakl, seller/shop и документация выданного доступа.
  • Карта offers, товаров и складских SKU.
  • Правила принятия заказов, отмен и частичной отгрузки конкретного оператора.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

  • Marketplace, Dropship, Connect и Catalog Manager не считаются одним взаимозаменяемым API.
  • Разрешения и обязательные действия оператора нужно проверить; готовый доступ к одной площадке не переносится на другую.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Общая документация MMP Seller подтверждает названные контракты, но не включение partial acceptance, multiple shipments, возвратов и нужных прав на конкретном marketplace. Метод записи offers требует отдельного предметного чтения.
Стоимость и запуск

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

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

Чем offer отличается от карточки товара?

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

Чем offer отличается от карточки товара?

Карточка описывает продукт площадки, а offer — предложение конкретного продавца. Для остатка и исполнения нужна связь предложения с его физическим SKU.

Нужно ли отдельно оценивать второй marketplace на Mirakl?

Да: его адрес, права продавца, статусы и правила доставки могут отличаться. Общая платформа не отменяет проверки каждого оператора.

Нужно ли сначала принять заказ продавцом?

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

Можно отдать полный остаток одному offer на каждой площадке?

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

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

Фильтр OR11 по start_update_date использует временной допуск поставщика. В проекте заказ сверяется по области площадки/shop и устойчивому ID; появление в следующей порции не создаёт новый складской заказ.

Можно ли закрыть все партии после HTTP 201 на создание отправлений?

Сначала проверим результат каждой партии: контракт ST01 разделяет успешные элементы и ошибки. Принятые сохраняем, непринятые разбираем отдельно; при потере ответа сверяем состояние перед повтором. Доступность этого workflow подтверждает оператор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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