Skirbo +
iWENGO

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

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

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

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

Операция	Направление	Состав и готовность
Заказы продавца	iWENGO → Skirbo	Нужна проверка Подтвердить метод и права получения заказов именно нужного продавца.
Товарные соответствия	iWENGO → Skirbo	Обсудим в составе подключения Связать товар продавца и его вариант со складской номенклатурой.
Наличие для продавца	Skirbo → iWENGO	Нужна проверка Уточнить способ записи доступного количества и проверку принятого значения.

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

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

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

iWENGO MARKET рассматриваем как платформу маркетплейса с доступом конкретного мерчанта. Это отдельная предметная область от образовательных продуктов под брендом iWENGO. Фулфилменту нужны заказы, предложения продавца и остатки его складов с изоляцией клиентов.

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

Сохранённый документ описывает HTTP Basic, выдачу доступа администратором и merchant-фильтрацию. Нужны отдельные секреты/изоляция для клиентов и проверка области чтения; способ безопасного хранения — проектная мера.

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

Интеграционная роль получает заказы через описанный merchant-интерфейс. Доступ и фильтрация должны соответствовать одному продавцу; рабочие учётные данные не передаются через публичную форму.
Сохраняем системный id, видимый number, delivery_id, store_id, исходные basketItems и updated_at. Таблица допуска сопоставляет подтверждённые значения статуса, оплаты и отмены; числовые коды не угадываем.
Из basketItems выделяем физические товары, связываем offer_id и product_id со складским SKU данного клиента. Услуги и сертификаты не становятся заданиями на подбор.
Skirbo резервирует и комплектует товар на площадке, соответствующей store_id. При нескольких продавцах одинаковый артикул не объединяет право собственности на запас.
Фиксируем фактические строки и грузовые места. Способ обратной записи исполнения ещё требует контракта; до его подтверждения оператор передаёт результат в согласованном кабинете.
Приём результата отмечается чтением подтверждённого состояния либо операторской квитанцией с исходным заказом. Полученный список заказов сам по себе не является подтверждением приёма отгрузки.
При неизвестном статусе, чужом store_id, неоднозначном offer_id или отмене начатой сборки ставим исключение. Повторный опрос обновляет существующее задание, а не создаёт новое.

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

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

Получение заказов одного мерчанта и допуск физических строк

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

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

Интеграционная роль получает заказы через описанный merchant-интерфейс. Доступ и фильтрация должны соответствовать одному продавцу; рабочие учётные данные не передаются через публичную форму.
Сохраняем системный id, видимый number, delivery_id, store_id, исходные basketItems и updated_at. Таблица допуска сопоставляет подтверждённые значения статуса, оплаты и отмены; числовые коды не угадываем.
Из basketItems выделяем физические товары, связываем offer_id и product_id со складским SKU данного клиента. Услуги и сертификаты не становятся заданиями на подбор.
Skirbo резервирует и комплектует товар на площадке, соответствующей store_id. При нескольких продавцах одинаковый артикул не объединяет право собственности на запас.
Фиксируем фактические строки и грузовые места. Способ обратной записи исполнения ещё требует контракта; до его подтверждения оператор передаёт результат в согласованном кабинете.
Приём результата отмечается чтением подтверждённого состояния либо операторской квитанцией с исходным заказом. Полученный список заказов сам по себе не является подтверждением приёма отгрузки.
При неизвестном статусе, чужом store_id, неоднозначном offer_id или отмене начатой сборки ставим исключение. Повторный опрос обновляет существующее задание, а не создаёт новое.

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

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

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

Остатки оффера по складам

Задача: Не смешивать товар, коммерческое предложение и складской запас.

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

Склад рассчитывает доступность по клиенту и площадке; карта связывает её с product_id, offer_id и store_id.
Отправляем согласованный объём в операцию остатков, не меняя цену и статус предложения этим же решением.
Проверяем последующее чтение и ошибки конкретных записей; неизвестную комбинацию идентификаторов не повторяем бесконечно.

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

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

Различие префикса метода остатков и merchant-методов, семантику qty и частичные ошибки нужно проверить на тестовой среде.

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

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

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

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

Результат: Возврат не увеличивает доступность до физической приёмки.

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

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

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

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

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

Роль выполняет разрешённое чтение списка и сохраняет границы выборки и страницы. Поле updated_at из ответа не объявляется фильтром или готовым курсором изменений: такой контракт в сохранённом документе не задан.
Каждая запись сопоставляется с ранее принятой записью в том же merchant и store_id; сохраняются исходный id, видимый number и delivery_id без предположения, что это один идентификатор.
Обновлённые признаки отмены, проблемы и оплаты проходят утверждённую таблицу допуска. Неизвестный статус или несовпадение склада отправляется ответственному и не создаёт новое задание.
Для разрешённой физической строки сравнивается уже исполненное количество; повтор чтения не запускает подбор второй раз. Новая редакция после отбора передаётся оператору.
Полнота обхода сверяется с согласованной контрольной выборкой. После сбоя сохраняется состояние обработки и выполняется повторное чтение перекрывающего участка по доступным документированным параметрам.
Оператор подтверждает найденные расхождения и принятое итоговое состояние. Пока актуальный контракт обратной записи не получен, подтверждение исполнения выполняется контролируемо в согласованном кабинете.

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

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

Инкрементальный фильтр, устойчивость сортировки и окончательная семантика списка отправлений должны быть проверены на актуальной среде; гарантии exactly-once не заявляются.

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

Данные	Ответственный источник	Правило обмена
Заказ и строки	iWENGO MARKET в области мерчанта	Коммерческий состав и допуск определяются статусной моделью конкретного маркетплейса.
SKU и варианты	Товар и оффер iWENGO + учёт клиента	product_id и offer_id сохраняются отдельно; xml_id/артикул используются после проверки уникальности.
Остатки и резерв	Skirbo физически; iWENGO для опубликованного оффера	Резерв и значение qty согласуются до записи по store_id.
Статусы	Маркетплейс и склад	Коды статусов необходимо получить из официальной модели; складской факт не подменяет оплату.
Документы	Учёт мерчанта/оператора	Наличие заказа не доказывает API юридических документов.
Возвраты	Заявка iWENGO и склад приёмки	Маршрут и разрешение принадлежат маркетплейсу, состояние принятого товара фиксирует склад.

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

Как записать частичную отгрузку и проверить её принятие?
Как трактуется qty, доступен ли метод с другим префиксом и как сообщаются частичные ошибки?
Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Как соотносятся id записи списка, вложенный order.id, number и параметр адресного GET заказа?
Есть ли стабильный инкрементальный фильтр, курсор или порядок сортировки, позволяющий не пропускать поздние изменения?

Перед оценкой

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

Администратор iWENGO, спецификация методов продавца и тестовый merchant-контур.
Карта SKU и разделение остатков при нескольких продавцах.
Правила допуска заказа, подтверждения результата и изменения после передачи.
Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Для опроса — подтверждённые правила пагинации, сортировки, повторного обхода и связи записи отправления с центральным заказом.

Границы сценария

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

Получение заказов и запись остатков описаны в сохранённом контракте; автоматическая запись исполнения и актуальная статусная модель требуют отдельной проверки.
Права одного продавца нельзя переносить на другого; учётные данные передаются только по согласованному защищённому каналу.
Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
Основной сценарий рассчитан на продавца в России. Для Казахстана и Узбекистана отдельно проверяются договор поставщика, локальные документы и правила обращения товара; российские ЭДО, касса и маркировка автоматически не переносятся.
Актуализация официальной страницы завершилась ошибкой инструмента; методы описаны по сохранённой редакции 03.09.2025, без выполнения запросов к merchant-среде.

Стоимость и запуск

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

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

Подойдёт ли один доступ для нескольких продавцов?

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

Подойдёт ли один доступ для нескольких продавцов?

Это нужно проверить у администратора: документация связывает доступные данные с merchant. До оценки нужны границы каждого продавца и его склада.

Что можно проверить до разработки?

Получение одного обезличенного заказа, сопоставление товарных идентификаторов и возможность подтвердить результат выбранным методом; наличие Basic Auth само по себе этого не доказывает.

Товар и оффер можно считать одним SKU?

Нет. В описании это отдельные идентификаторы; оффер привязан к коммерческому предложению, а складской обмен должен дополнительно сохранить store_id и владельца запаса.

Можно ли уже заявить автоматический возврат отгрузки?

Получение заказов и запись остатков документированы в сохранённом источнике. Контракт записи исполнения и его подтверждения ещё нужно получить; до этого допустим контролируемый операторский шаг.

Можно опрашивать только записи после последнего updated_at?

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

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

Нет. Документ различает id, number, delivery_id и store_id. Кроме того, список назван списком отправлений; соответствие записи центральному заказу и параметра адресного запроса требует проверки.

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

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

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

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

Техническая документация: Документация к API внешних интеграций, для продавцов — дата проверки: 2026-10-30
iWENGO MARKET — интеграция с маркетплейсом, сохранённая редакция 03.09.2025 — дата проверки: 2026-10-30

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

Весь каталог →

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

Skirbo +iWENGO

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

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

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

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

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

Получение заказов одного мерчанта и допуск физических строк

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

Остатки оффера по складам

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

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

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

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

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

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

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

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

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

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

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

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

Tilda

InSales

1С-Битрикс: Управление сайтом

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

Skirbo +
iWENGO