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

Skirbo +
SelSup

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

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

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

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

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

Предлагается согласованный набор количеств с товарными ключами; SelSup получает данные сам.

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

Подтверждена Excel-выгрузка; автоматический API отчёта не заявляется.

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

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

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

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

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

Для продавца, уже ведущего ассортимент и маркетплейсы в SelSup, рассматриваются два подтверждённых контура: регулярное получение остатков через JSON API Core и отчёт по возвратам. В отчёте различаются организация, маркетплейс, FBO/FBS, заказ и возврат.

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

Подтверждён входящий для SelSup регулярный обмен JSON API Core и выгрузка отчёта в Excel. Это не доказательство универсального публичного API записи SelSup; совместимость источника Skirbo с JSON-конфигурацией требуется проверить.

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

  1. Выбрать клиента, организацию SelSup и целевой склад. Уточнить, передаётся физический или доступный к продаже остаток и где уже учтён резерв.
  2. Сопоставить SKU, артикул или штрихкод с карточкой SelSup; товары без связи выделить в отдельный разбор.
  3. Подготовить источник данных под подтверждённую конфигурацию API Core. SelSup получает значения в своём регулярном обмене; предполагаемый прямой POST в SelSup не используется.
  4. Склад продолжает хранить фактические движения, а ответственный проверяет завершение обмена и количество именно на выбранном складе SelSup.
  5. При разрешённой дальнейшей отправке проверить результат на нужном маркетплейсе. Статус успешной обработки не заменяет проверку конкретного SKU и целевого канала.
  6. Если товар не найден, исправить соответствие и повторно сверить его. Пустой ответ или недоступность источника не превращаются в массовой ноль без согласованного правила.
  7. Зафиксировать контрольную выборку: связанный товар, неизвестный SKU и одинаковый артикул в другой организации. Для каждой позиции сравнить ожидаемое и полученное количество и отдельно отметить непереданные записи.
  8. При недоступности источника сохранить последнее подтверждённое состояние и остановить неподтверждённую публикацию по согласованному правилу. После восстановления сверить свежую полную выборку, не принимая отсутствие строки за ноль.

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

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

Обновить остаток конкретного склада

Задача: Передать реальную доступность товара, не смешав склады разных клиентов.

Когда начинается: В Skirbo завершены складские операции и подготовлена согласованная версия количества для публикации.

  1. Выбрать клиента, организацию SelSup и целевой склад. Уточнить, передаётся физический или доступный к продаже остаток и где уже учтён резерв.
  2. Сопоставить SKU, артикул или штрихкод с карточкой SelSup; товары без связи выделить в отдельный разбор.
  3. Подготовить источник данных под подтверждённую конфигурацию API Core. SelSup получает значения в своём регулярном обмене; предполагаемый прямой POST в SelSup не используется.
  4. Склад продолжает хранить фактические движения, а ответственный проверяет завершение обмена и количество именно на выбранном складе SelSup.
  5. При разрешённой дальнейшей отправке проверить результат на нужном маркетплейсе. Статус успешной обработки не заменяет проверку конкретного SKU и целевого канала.
  6. Если товар не найден, исправить соответствие и повторно сверить его. Пустой ответ или недоступность источника не превращаются в массовой ноль без согласованного правила.
  7. Зафиксировать контрольную выборку: связанный товар, неизвестный SKU и одинаковый артикул в другой организации. Для каждой позиции сравнить ожидаемое и полученное количество и отдельно отметить непереданные записи.
  8. При недоступности источника сохранить последнее подтверждённое состояние и остановить неподтверждённую публикацию по согласованному правилу. После восстановления сверить свежую полную выборку, не принимая отсутствие строки за ноль.

Результат: В SelSup обновлён нужный склад, а непереданные товары видны как исключения.

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

  • Успех общего обмена не доказывает, что все позиции сопоставились.

Принять возврат по отчёту

Задача: Связать цифровое уведомление с физическим товаром.

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

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

Результат: Отчёт и физическая приёмка имеют проверяемую связку.

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

  • Цена или валюта в отчёте могут отсутствовать; их нельзя восстанавливать из случайного похожего заказа.

Догрузить старый период без повторной приёмки

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

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

  1. Обновить выбранный период и дождаться завершения задачи SelSup.
  2. Сопоставить записи по организации, площадке и номеру возврата с уже обработанными приёмками.
  3. Исправление причины или статуса оформить как новую версию сверки, а не новый физический приход.
  4. Записать организацию, фильтры, период и время выгрузки. Если выбраны все площадки, обрабатывать их раздельно; отсутствие старой строки в новой выборке сначала проверить по фильтрам и завершению задачи.

Результат: История дополняется без удвоения товара.

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

  • FBO-возврат на склад площадки не считается поступлением на собственный склад продавца.

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

ДанныеОтветственный источникПравило обмена
Заказ и внешний возвратПлощадка / SelSupСохраняются организация, схема и внешние номера.
SKU и соответствияСправочник клиентаАртикул и штрихкод сопоставляются до обмена, неоднозначность останавливает позицию.
Физический запас и резервSkirbo / выбранный владелец резерваНельзя вычитать один резерв дважды.
Публикуемый остаток и статус обменаSelSupОдин канал записи на площадку, результат проверяется по складу.
Документы и физический возвратУчётная система и складОтчёт служит основанием сверки, не доказательством приёмки или бухгалтерского документа.

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

  • Кто владеет резервом и какая формула остатка нужна для публикации?
  • Какие поля возвратной этикетки доступны при сканировании на складе?
  • Что означает отсутствующий SKU: исключён из выборки, удалён или реально имеет нулевой остаток?
  • Какой сотрудник подтверждает соответствие отчётного возврата осмотренной физической единице?
Перед оценкой

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

  • Организация, склад, JSON-конфигурация и контрольный набор SKU.
  • Определение доступного количества и единственного отправителя на площадку.
  • Доступ к дополнительной функции отчёта, действующие подключения площадок и ответственный за Excel-сверку.
  • Обезличенные примеры полного, частичного и пустого ответа источника API Core; правила полноты, отбора товаров и остановки обмена согласуются до автоматической публикации.
  • Отдельное соответствие организации, площадки, номера возврата и товарного варианта; результаты осмотра не смешиваются со статусами отчёта.
Границы сценария

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

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

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

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

Какой склад SelSup должен получать остатки и из каких организаций приходит возвратный поток?

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

Успешная выгрузка означает обновление всех товаров?

Нет: инструкция предупреждает, что ненайденный товар не обновится. Проверяют выбранный склад и конкретные позиции.

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

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

Возврат в отчёте уже лежит на складе?

Нет. Нужны физическая приёмка, количество и осмотр; также следует учитывать FBO/FBS и адрес возврата.

Как получить старые возвраты?

Инструкция предусматривает обновление выбранного периода. После выполнения проверяют выборку; повторная загрузка не должна создавать второй складской приход.

В отчёте нет возврата: что проверить до ручного прихода?

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

Достаточно ли передать ключ SelSup, чтобы подключить API Core?

Для этого сценария нужна конфигурация источника, из которого SelSup забирает количество, и проверенное сопоставление товаров. Описание API Core не задаёт универсальный контракт записи Skirbo в SelSup; ключи и доступ согласуются отдельно и не передаются через публичную форму.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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