Товары и управление заказами
Ensi
Связь складского исполнения с заказами и товарными данными платформы Ensi.
Предложить передачу складского количества в настроенный обмен 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-конфигурацией требуется проверить.
Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.
Задача: Передать реальную доступность товара, не смешав склады разных клиентов.
Когда начинается: В Skirbo завершены складские операции и подготовлена согласованная версия количества для публикации.
Результат: В SelSup обновлён нужный склад, а непереданные товары видны как исключения.
Задача: Связать цифровое уведомление с физическим товаром.
Когда начинается: На склад пришла возвратная посылка.
Результат: Отчёт и физическая приёмка имеют проверяемую связку.
Задача: Разобрать запоздалые сведения маркетплейса.
Когда начинается: В отчёте появились данные за уже закрытый складской период.
Результат: История дополняется без удвоения товара.
| Данные | Ответственный источник | Правило обмена |
|---|---|---|
| Заказ и внешний возврат | Площадка / SelSup | Сохраняются организация, схема и внешние номера. |
| SKU и соответствия | Справочник клиента | Артикул и штрихкод сопоставляются до обмена, неоднозначность останавливает позицию. |
| Физический запас и резерв | Skirbo / выбранный владелец резерва | Нельзя вычитать один резерв дважды. |
| Публикуемый остаток и статус обмена | SelSup | Один канал записи на площадку, результат проверяется по складу. |
| Документы и физический возврат | Учётная система и склад | Отчёт служит основанием сверки, не доказательством приёмки или бухгалтерского документа. |
На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.
Какой склад SelSup должен получать остатки и из каких организаций приходит возвратный поток?
Нет: инструкция предупреждает, что ненайденный товар не обновится. Проверяют выбранный склад и конкретные позиции.
Для одного магазина и склада выбирают одного ответственного отправителя. Два независимых писателя могут вернуть устаревшее количество.
Нет. Нужны физическая приёмка, количество и осмотр; также следует учитывать FBO/FBS и адрес возврата.
Инструкция предусматривает обновление выбранного периода. После выполнения проверяют выборку; повторная загрузка не должна создавать второй складской приход.
Сначала проверьте организацию, площадку, период и действующую связь с API маркетплейса. Для старого периода запустите обновление, дождитесь задачи и обновите таблицу. Само отсутствие строки не подтверждает потерю или отсутствие физического товара.
Для этого сценария нужна конфигурация источника, из которого SelSup забирает количество, и проверенное сопоставление товаров. Описание API Core не задаёт универсальный контракт записи Skirbo в SelSup; ключи и доступ согласуются отдельно и не передаются через публичную форму.
Изучаем возможность связи со Skirbo. Рабочий коннектор и сроки подключения не подтверждены; сначала согласуем описанный ниже процесс и проверим доступный интерфейс. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.
Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.
Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.
Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.
Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.