Интеграция с Ozon по API связывает кабинет продавца с ERP, PIM, магазином или внутренним сервисом. Определяем, какие операции относятся к FBS, какие данные нужны по FBO и кто управляет каталогом. Настройка нескольких вызовов Seller API не заменяет модель обмена: товар, отправление и финансовая операция имеют разные идентификаторы и жизненный цикл.
Загрузка и обновление ассортимента
Сопоставляем offer_id продавца, product_id площадки, штрихкоды и внутреннюю номенклатуру. Проверяем категории, обязательные атрибуты, варианты и единицы. Существующий ассортимент сначала связываем с внутренним каталогом, затем добавляем недостающие позиции.
Для импорта сохраняем идентификатор обработки и ошибки по товарам. Задаём порядок исправления: некорректная категория, отсутствующий атрибут и проблема изображения требуют разных действий. Массовая повторная отправка всего каталога без разбора результата не должна быть единственным способом восстановления.
Цены и остатки по складам
Источник базовой цены, скидок и минимально допустимого значения фиксируем до запуска. Проверяем округление, валюту и ситуации, когда цена не должна изменяться автоматически. Отдельно рассматриваем участие в акциях: обычная синхронизация цены не означает управление всеми рекламными механиками.
Для FBS связываем склады Ozon с внутренними складами и рассчитываем доступный запас с учётом резерва. При FBO продавец работает с данными о товаре на стороне площадки по доступным интерфейсам, а не произвольно заменяет их остатками своего склада. Несколько кабинетов и складов требуют раздельных соответствий.
Единый магазин и несколько маркетплейсов
Когда Ozon подключается вместе с другими каналами продаж, отдельно определяем общий источник каталога, цены и свободного запаса.
Интеграция магазина с маркетплейсамиОтправления FBS и складская обработка
Разбираем получение отправлений, резервирование позиций, сборку, упаковку и доступные операции подтверждения. Внутренний заказ хранит связь с номером отправления и составом. Заказ покупателя и отдельное отправление не всегда совпадают по структуре, поэтому не объединяем их только по похожему номеру.
Интеграция Ozon с учётной системой должна учитывать отмену и изменение доступных действий на площадке. Печать этикетки и передача статуса проверяются на выбранной схеме исполнения. Повтор обработки не создаёт второй складской расход, а старое событие не отменяет уже подтверждённый результат.
FBO, возвраты и финансовые данные
Для FBO определяем нужный состав сведений о продажах, остатках, движениях и поставках из доступных методов. Не переносим в этот сценарий маршрут сборки FBS. Возврат связываем с исходной продажей и согласованным отражением в учёте; получение уведомления ещё не подтверждает физическую приёмку товара вашим складом.
Для финансовой сверки разделяем заказ, продажу, услуги площадки, удержания и выплату. Определяем дату признания и правила корректировок прошлых периодов. Клиент получает объяснимую загрузку отчётных данных, а не обещание, что любой отчёт Ozon автоматически совпадёт с внутренней управленческой формой.
Запуск, контроль и сопровождение
Доступы Client ID и API Key используются только на сервере и в необходимом составе. Для обмена задаём очередь, контроль частичной обработки и повтор после ограничения API. Пагинация и сохранение контрольной точки нужны, чтобы большой объём отправлений не обрывался на первой странице.
Проверяем создание товара, отказ импорта, смену цены, остаток, получение отправления, отмену и восстановление после сбоя. Для оценки интеграции с Ozon нужны схемы продаж, число кабинетов и складов, выбранная система и перечень объектов. Результат включает карту соответствий и инструкцию по разбору недоставленных операций.
Вопросы перед началом работ
Чем различаются интеграции FBS и FBO?
При FBS важны остатки и исполнение со склада продавца. Для FBO акцент другой: сведения о товаре и операциях на стороне площадки. Нужные методы и состав данных определяем отдельно по действующей схеме.
Можно связать Ozon с собственной ERP?
Да, если ERP позволяет получать и записывать согласованные объекты. Иногда нужен промежуточный сервис, который сопоставляет структуры и хранит очередь. Наличие доступа к Seller API не гарантирует доступность нужной записи в ERP.
Как избежать двойного списания товара?
Сохраняем внешний идентификатор отправления и результат обработки. Перед повторной записью проверяем существующий внутренний документ. Повтор получения сообщения не считается новой продажей.
Можно загрузить продажи за прошлый период?
Это зависит от доступной истории конкретного метода и данных кабинета. Период и состав сначала проверяем. Историческую загрузку отделяем от текущего обмена и сверяем на ограниченном интервале.
Нужно заменять действующий модуль 1С?
Не обязательно. Если он поддерживает необходимые сценарии, его можно настроить или доработать. Перед новой интеграцией проверяем существующий маршрут, чтобы не запустить два независимых обработчика одного отправления.