По запросу
Автоматизация
n8n
Оркестрация согласованного обмена между внешними системами и Skirbo.
АвтоматизацияSkirbo +
Skirbo +
RDV Маркет / RDV API
Получать заказ из согласованного кабинета через RDV API, собирать его на складе Skirbo и возвращать состав мест и результат отгрузки с проверкой принятого состояния.
Какой обмен обсудим
Зафиксируем нужные операции, направление данных и условия приёмки.
| Операция | Направление | Состав и готовность |
|---|---|---|
| Заказ и его строки | Кабинет маркетплейса → RDV API → проектный адаптер Skirbo | Обсудим в составе подключения v2/order/list: accountApiId, apiId заказа, positionApiId, itemApiId, skuApiId. Идентификатор клиента и склад добавляются в локальный ключ; название товара не является ключом. |
| Два вида склада | RDV API ↔ таблица сопоставления клиента | Обсудим в составе подключения accountWarehouseApiId обозначает склад кабинета, stockWarehouseApiId — место хранения. Привязку к складу Skirbo утверждает владелец запаса. |
| Остаток и погашение резерва | Складской учёт → RDV API → кабинеты | Обсудим в составе подключения v1/stock/set передаёт stocks; список reserves используется только для резервов заказов, уже отражённых в учёте. Ответ проверяется по каждой паре SKU/склад. |
| Состав упаковки | Оператор склада → Skirbo → RDV API | Обсудим в составе подключения v2/order/pack связывает orderApiId, cargoUnits и orderItems. Коды CIS/IMEI/GTD передаются лишь при применимости к товару и выбранному каналу. |
| Отгрузка и печатные формы | RDV API ↔ склад | Обсудим в составе подключения Идентификатор отгрузки и печатные формы связываются с конкретными заказами и местами. Подтверждение API отделено от физической передачи перевозчику. |
| Отмена и возврат | Канал через RDV API → обработка исключений склада | Обсудим в составе подключения order/cancel описан только для неупакованных заказов. returns в заказе даёт состояние по cargoUnitApiId; складская приёмка и возврат денег выполняются отдельно. |
На узком экране таблицу можно прокрутить в сторону.
Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.
Для какой задачи подходит сервис
Материал посвящён внешнему RDV API для продавца с собственной ERP/WMS и несколькими кабинетами. RDV Маркет также предлагает расширение типовой 1С; функции расширения и конвейера 1С не переносятся автоматически на внешний API. Начальная область — российские FBS-заказы и согласованные склады. Функции FBO/FBM и DBS оцениваются отдельно по площадке.
Как организовать обмен
HTTP API по выданному поставщиком адресу. В сохранённой спецификации v.20260414 запросы используют token и clientKey; чтение изменений v2 передаёт boundary, после которого объекты загружаются профильными методами. Webhook и гарантированная доставка не заявлены.
Предлагаемый порядок работы
- Адаптер читает изменения v2 с сохранённой границы и получает сам заказ через v2/order/list; при первом запуске выполняет согласованную выборку заказов за период.
- Проверяет клиентский контур, accountApiId, оба вида склада и связи SKU/позиции/экземпляра. Неизвестные SKU и ошибки hasError/errorText уходят оператору.
- На складе создаётся одно задание по внешнему заказу. До подтверждения проверяются фактическое наличие, резерв и допустимая стадия канала.
- Оператор подбирает товар, сканирует экземпляры и упаковывает места. Состав заказа не подменяется названием карточки или количеством мест.
- В разрешённой стадии передаётся состав v2/order/pack, затем читается актуальный заказ и сверяются места, позиции и статус. Запуск адаптера сам по себе не считается подтверждением.
- Этикетки привязываются к принятой версии упаковки. Отгрузка оформляется согласованным методом, после чего оператор отдельно фиксирует реальную передачу.
- Если ответ потерян, сначала перечитывается заказ/отгрузка. Повторное создание или упаковка разрешается только после проверки уже сохранённого результата; спорная операция остаётся в журнале разногласий.
Практические сценарии
Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.
FBS-заказ от кабинета до подтверждённой упаковки
Задача: Связать версии заказа, экземпляры и грузовые места с одной физической сборкой.
Когда начинается: Появился или изменился заказ согласованного кабинета.
- Адаптер читает изменения v2 с сохранённой границы и получает сам заказ через v2/order/list; при первом запуске выполняет согласованную выборку заказов за период.
- Проверяет клиентский контур, accountApiId, оба вида склада и связи SKU/позиции/экземпляра. Неизвестные SKU и ошибки hasError/errorText уходят оператору.
- На складе создаётся одно задание по внешнему заказу. До подтверждения проверяются фактическое наличие, резерв и допустимая стадия канала.
- Оператор подбирает товар, сканирует экземпляры и упаковывает места. Состав заказа не подменяется названием карточки или количеством мест.
- В разрешённой стадии передаётся состав v2/order/pack, затем читается актуальный заказ и сверяются места, позиции и статус. Запуск адаптера сам по себе не считается подтверждением.
- Этикетки привязываются к принятой версии упаковки. Отгрузка оформляется согласованным методом, после чего оператор отдельно фиксирует реальную передачу.
- Если ответ потерян, сначала перечитывается заказ/отгрузка. Повторное создание или упаковка разрешается только после проверки уже сохранённого результата; спорная операция остаётся в журнале разногласий.
Результат: По одному заказу можно проследить складское задание, состав мест, принятый результат канала и фактическую передачу.
Если возникло исключение
- Полнота истории изменений, срок хранения очереди и безопасная граница подтверждения уточняются до запуска.
- Шаблон печатной формы в сохранённом документе требует проверки по текущей схеме.
Остатки без двойного вычитания резерва
Задача: Не занижать доступность, когда заказ уже принят складским учётом.
Когда начинается: Учётная система применила заказ или изменила остаток SKU на складе.
- Владелец учёта определяет количество, уже учитывающее локальные резервы, и сопоставляет SKU/место хранения с RDV.
- Адаптер сопоставляет резерв RDV с реально применённым заказом и сохраняет подтверждение локальной операции.
- В stock/set отправляются согласованный остаток и только идентификаторы учтённых резервов. Неизвестные резервы остаются для разбора.
- Проверяются success и поэлементные errors. Неуспешная пара SKU/склад остаётся непереданной; затем отдельно проверяется состояние в согласованном кабинете.
- После тайм-аута состояние сверяется до повторной отправки. Пересчёт не меняет резерв повторно и не затрагивает другой кабинет.
Результат: Канал получает согласованное количество без двойного вычитания одного заказа.
Если возникло исключение
- В примере reserve/list список описан словами, а data показан объектом: точную кардинальность ответа нужно подтвердить.
- Единый аккаунт RDV не отменяет изоляцию клиентов фулфилмента.
Отмена после начала сборки и ожидание возврата
Задача: Сохранить различие между отказом от заказа и возвращением уже выданного товара.
Когда начинается: Канал сообщил отмену или состояние возврата.
- Сверить актуальную стадию заказа в RDV и физическую стадию склада, остановить дальнейшие действия по спорному заказу.
- Для ещё неупакованного заказа проверить применимость order/cancel и после выполнения перечитать состояние. Освобождение локального резерва фиксируется один раз.
- Для упакованного или переданного заказа согласовать разрешённый канал отмены/возврата; метод для неупакованного заказа не использовать автоматически.
- Состояние returns по грузовому месту связывается с исходным заказом и создаёт ожидание возврата.
- После физического поступления оператор сверяет экземпляры, количество и состояние. Учётная система отдельно отражает товар и финансовое решение.
Результат: Отмена не создаёт фиктивную приёмку, а уведомление о возврате не увеличивает доступный запас.
Если возникло исключение
- Полный словарь returnStatus и поддержка частичного возврата уточняются для конкретного маркетплейса.
Кто управляет данными
| Данные | Ответственный источник | Правило обмена |
|---|---|---|
| Заказ и коммерческие условия | Маркетплейс и кабинет продавца | RDV передаёт состояние; локальное задание хранит внешний ID, кабинет и исходную версию. |
| SKU и соответствия | Владелец каталога продавца | Утверждает связь skuApiId, карточки канала, варианта и внутреннего товара; неоднозначность останавливает автоматическую сборку. |
| Наличие, резерв и фактический расход | Назначенная система складского учёта | Выбирается один автор остатков. Резерв RDV снимается лишь после отражения соответствующего заказа в этой системе. |
| Упаковка и физическая передача | Оператор склада | Факт сканирования экземпляра/места и передачи фиксируется на складе; ответ API хранится отдельно. |
| Статус канала и этикетка | Маркетплейс через RDV | Сохраняется исходный статус, канал, время и версия документа; печать не равна отгрузке. |
| Возврат | Канал — уведомление; склад — приёмка; учётная система — деньги | Состояние returns создаёт задачу ожидания. Доступный запас увеличивается после проверки товара, возмещение не выводится из статуса места. |
Что обсудить перед пилотом
- Какой экземпляр RDV API и версия используются у клиента?
- Кто сейчас пишет остатки и как учитывает резервы RDV?
- Какой кабинет и FBS-склад берем для первого сценария?
- Как подтвердить неизвестный результат упаковки и что делать при разрыве истории изменений?
Перед оценкой
Что нужно уточнить
- Договор и доступ именно к RDV API, адрес экземпляра сервиса, отдельные token/clientKey для тестовой и рабочей системы.
- Разрешённые кабинеты, схема FBS и таблица соответствия accountApiId, складов, SKU, вариантов и единиц.
- Один владелец записи остатков и правило погашения резервов; запрет одновременного управления тем же каналом вторым адаптером.
- Обезличенные примеры заказа с несколькими местами, ошибки упаковки, отмены и возврата; разрешение на тестовые операции.
- Актуальные ограничения частоты, объёма и времени хранения изменений, регламент восстановления; секреты передаются через согласованный защищённый канал.
Границы сценария
Что учесть заранее
- Снимок v.20260414 не доказывает, что тот же контракт включён в экземпляре клиента.
- В образце Production указан адрес с переменным ibname; реальную базу нельзя угадывать или брать из демонстрационного примера.
- Не установлены гарантии идемпотентности mutating-методов, срок хранения событий и полный backfill.
- В сохранённом примере printform/getform повторно вложены printform/format/object; структуру нужно сверить с действующей схемой.
- Отмена описана для неупакованного заказа; это не универсальная операция отмены после выдачи.
- Коды CIS и российская маркировка применяются адресно. Правила РФ не переносятся на Казахстан/Узбекистан; международная доступность отдельно не исследована.
Стоимость и запуск
Оценим ваш набор операций
На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.
Укажите один кабинет, FBS-склад, действующий способ учёта резервов и обезличенный заказ с местами — оценим полный цикл чтения, сборки и обратного подтверждения.
Вопросы о подключении
Это подключение к расширению 1С?
Здесь рассматривается внешний RDV API для собственной системы учёта. Если клиент работает через расширение 1С, его объём и владельца операций оценивают отдельно.
Зачем различать два склада?
У кабинета маркетплейса свой склад, у продавца — место хранения. Сопоставление определяет, куда отправится остаток и откуда нужно собрать заказ; один текстовый адрес этой связи не заменяет.
Почему резерв нельзя просто вычесть ещё раз?
Один заказ мог уже уменьшить доступность в учётной системе. Предлагаемый процесс сначала подтверждает его отражение, затем передаёт согласованный остаток и погашает соответствующий резерв RDV.
Можно сразу повторить запрос упаковки после тайм-аута?
Сначала следует прочитать заказ и проверить состав мест. Потерянный ответ не означает, что действие не выполнено; гарантия безопасного повтора требует отдельной проверки.
Возврат в заказе сразу возвращает товар в продажу?
Для проектируемого процесса он создаёт ожидание. Продажный запас восстанавливает склад после физической приёмки и проверки, а денежный возврат выполняет учётный контур.
Интеграция уже готова?
Изучаем подключение. Ни пилот Skirbo, ни приёмка коннектора на заказах клиента не подтверждены. Методы поставщика описывают возможность разработки, а её объём согласуется для конкретного кабинета. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.
Официальные материалы сервиса
Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.
- RDV API Reference v.20260414 — дата проверки: 2026-10-30
- RDV API: назначение внешнего интерфейса — дата проверки: 2026-10-30
Посмотрите другие сценарии
Весь каталог →Ваш процесс → следующий шаг
Что хотите связать со Skirbo?
Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.
- Разберём задачуУточним роли, склады и операции.
- Проверим возможностьОпределим доступы, ограничения и состав работ.
- Согласуем запускОбсудим стоимость, сроки и критерии готовности.
Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.