Интеграция 1С с Ozon 2026: заказы, остатки, возвраты и ошибки API

Интеграция 1С с Ozon нужна не для красивой кнопки «синхронизировать», а для контроля трёх контуров: что продано, сколько реально осталось на складе и какие возвраты уже нужно отразить в учёте. В одном из наших проектов по 1С и маркетплейсам основная проблема была не в API-ключе, а в расхождении складов: менеджеры выгружали остатки из 1С раз в несколько часов, параллельно меняли цены в личном кабинете Ozon, а возвраты закрывали вручную в конце недели. После этого невозможно понять, где ошибка: в 1С, Ozon Seller, складе или регламенте сборки.

Ниже — практический разбор по состоянию на 2026 год: какие методы Ozon Seller API участвуют в обмене, чем отличаются FBS и FBO для 1С, какие лимиты и задержки нужно учитывать, где чаще всего ломаются остатки, цены, заказы и возвраты.

Ключевые факты

• Для доступа к Ozon Seller API нужны Client-Id и API-ключ из личного кабинета продавца; Ozon требует использовать их в каждом запросе.
• Для FBS-заказов Ozon в документации указывает методы POST /v3/posting/fbs/list, POST /v3/posting/fbs/get и POST /v3/posting/fbs/unfulfilled/list.
• Остатки по нескольким складам обновляются через связку POST /v1/warehouse/list и POST /v2/products/stocks; в 1С важно заранее сопоставить склады Ozon и склады учётной базы.
• Новые или изменённые карточки товаров проходят модерацию, поэтому изменения описаний и характеристик могут появляться на Ozon с задержкой до нескольких дней.
• При загрузке товаров через API Ozon принимает до 100 позиций за один запрос POST /v2/product/import; это ограничение нужно учитывать при первичной выгрузке большого каталога.
• Для FBS/realFBS 1С обычно передаёт остатки со своего склада на Ozon; для FBO важнее получать остатки Ozon, планировать поставки и отражать продажи/возвраты в учёте.
• Возвраты FBS и FBO отображаются в кабинетных разделах Ozon по возвратам; для 1С их нельзя сводить только к отменённым заказам, потому что часть возвратов появляется после доставки.

Что должна делать нормальная интеграция 1С и Ozon

Минимальный контур обмена выглядит так:

Главное правило: 1С должна быть мастер-системой для номенклатуры, складов и себестоимости, а Ozon — каналом продаж и логистики. Если менеджер меняет цену в Ozon вручную, а 1С потом выгружает старую цену по расписанию, интеграция формально работает, но бизнес получает ценовой конфликт.

FBS, realFBS и FBO: что меняется для 1С

На FBS и realFBS продавец хранит товар у себя, поэтому для 1С критичны резервы, сборка, сроки отгрузки и остатки по собственным складам. Ozon показывает новые отправления в статусе awaiting_packaging; интеграция должна быстро создать заказ/резерв в 1С, чтобы этот же товар не продали в розницу или на другом маркетплейсе.

На FBO товар уже находится на складе Ozon. Здесь не нужно передавать ежедневный остаток собственного склада как доступный к продаже на Ozon, но нужно получать остатки маркетплейса, учитывать поставки, продажи, возвраты, списания и финансовые отчёты. Официальная страница 1С по Ozon отдельно указывает: для FBS/realFBS передаются остатки на складе продавца, а для FBO загружаются остатки с маркетплейса и планируются поставки на склады Ozon.

Поэтому одна настройка «интеграция Ozon» без уточнения схемы продаж опасна. Для FBS автоматизация строится вокруг заказов и склада продавца. Для FBO — вокруг поставок, остатков Ozon, возвратов, комиссий и сверки финансов.

Где чаще всего ломаются заказы

Типовой сценарий FBS в Ozon такой: заказ попадает в список отправлений, продавец собирает товар, подтверждает сборку, передаёт отправление в доставку и дальше отслеживает статус. В API это не один документ, а цепочка статусов. Если в 1С создать только «Заказ клиента», но не хранить номер отправления Ozon, потом сложно связать отмену, возврат и финансовую строку отчёта.

В нашем опыте лучше сразу хранить в 1С отдельные поля: номер отправления Ozon, posting_number, offer_id, Ozon SKU, склад Ozon, дедлайн сборки, текущий статус и признак частичной сборки. Тогда при повторном запросе из API интеграция не создаст дубль заказа, а обновит существующий документ.

Практический минимум для заказов:

• загружать новые отправления по расписанию каждые 5-15 минут;
• создавать резерв в 1С только по свободному остатку;
• не перезаписывать вручную исправленные документы без проверки статуса;
• логировать каждую смену статуса Ozon;
• отдельно обрабатывать отмены покупателя, отмены продавца и возвраты после доставки.

Остатки: главный источник отмен и пересорта

Ozon в справке по API прямо рекомендует автоматизировать обновление остатков, если ассортимент хранится в ERP или другой базе. Для 1С это означает не просто «выгрузить число», а правильно посчитать доступный остаток:

Доступно для Ozon = Остаток на складе - Резервы - Брак - Внутренний страховой запас - Товары под другие каналы

Если в Ozon выгружать общий остаток склада, продавец быстро получает заказы на товар, который уже зарезервирован под розницу, опт или Wildberries. Поэтому в настройке Синхрон1С я обычно закладываю страховой запас по категориям: например, не выгружать последние 1-2 единицы дорогой электроники и последние 5-10 единиц ходового расходника.

Частая ошибка при нескольких складах — перепутанный warehouse_id. Ozon принимает остаток не «вообще по магазину», а по складу. Если в 1С склад «Москва FBS» сопоставлен со складом Ozon «СПБ FBS», API может технически принять запрос, но заказ уйдёт не туда, где лежит товар.

Цены и карантин цен

Цены нельзя обновлять без предохранителей. В Ozon есть «карантин цен»: если цена резко выросла или упала после обновления, товар может быть заблокирован для покупки до ручной проверки. Это полезная защита от ошибки, но для продавца она выглядит как внезапное пропадание товара из продажи.

Для интеграции с 1С нужны проверки до отправки цены:

Если цена меняется репрайсером, 1С не должна каждые 30 минут возвращать её назад. В таком случае в 1С лучше хранить базовую цену и минимальный порог, а оперативную цену отдавать репрайсеру.

Возвраты: не путать с отменами

Отмена заказа и возврат товара — разные события. Отмена может случиться до доставки, а возврат появляется после получения или отказа покупателя. В справке Ozon по возвратам указано, что список возвратов отображается в разделах FBO и FBS по возвратам, а статусы включают движение товара на склад Ozon, утилизацию и быстрый возврат.

Для 1С это значит:

• отмена до сборки снимает резерв и не создаёт реализацию;
• отмена после сборки требует проверки, был ли товар уже передан в доставку;
• возврат после доставки требует корректировки реализации, движения товара и финансовой сверки;
• быстрый возврат нельзя автоматически считать физическим поступлением товара на склад продавца;
• спорный возврат нужно вести отдельным статусом, пока нет решения Ozon.

Хорошая интеграция не просто пишет «возврат» в комментарий. Она создаёт отдельный регистр или документ с причиной, статусом, суммой, SKU, номером отправления и связью с исходной продажей.

Таблица рисков внедрения

Практический план запуска

Шаг 1. Инвентаризация. Сначала фиксируем схемы продаж: FBS, realFBS, FBO или смешанная модель. Затем выгружаем список складов Ozon, список SKU, offer_id, цены, остатки и активные статусы заказов. Без этого нельзя безопасно включать автоматическую выгрузку.

Шаг 2. Маппинг 1С и Ozon. Сопоставляем склады, номенклатуру, характеристики, типы цен, юридическое лицо, договор, способ доставки и статусы заказов. Для 1С:УТ 11.5 официальная инструкция 1С отдельно показывает настройку интеграции с маркетплейсами и соответствие складов FBS на Ozon складам в 1С.

Шаг 3. Тестовый обмен. Берём 3-5 товаров: один простой SKU, один с характеристикой, один дорогой товар с ограничением остатка, один товар в акции и один товар с нулевым остатком. Проверяем, как Ozon принимает остатки и цены, и не попадает ли товар в карантин.

Шаг 4. Заказы и резервы. Включаем загрузку новых FBS-отправлений, но сначала без автоматического изменения статусов. Сверяем: заказ Ozon = один документ 1С, позиции совпали, резерв создан, отмена снимает резерв.

Шаг 5. Возвраты и отчёты. После заказов подключаем возвраты, отчёты по продажам и комиссию. Это отдельный этап: если включить всё сразу, при первой расхожей сумме будет непонятно, ошибка в заказе, возврате, комиссии или ручной правке.

Что настраивает Синхрон1С

Обычно для первой версии достаточно связки «заказы + остатки + цены + ошибки». Возвраты и финансовые отчёты лучше подключать вторым этапом, когда склад уже перестал жить в ручном режиме.

Часто задаваемые вопросы

Можно ли подключить Ozon к 1С без доработки конфигурации?

Иногда да: если у вас типовая 1С:УТ 11.5 и подходит штатный сценарий интеграции. Но в реальных проектах почти всегда нужны правила сопоставления складов, цен, статусов, характеристик и возвратов.

Что важнее автоматизировать первым: заказы или остатки?

Для FBS — остатки и заказы вместе. Если загрузить заказы без актуальных остатков, склад всё равно будет ловить отмены. Если выгружать остатки без резервов по заказам, можно продать один товар дважды.

Подходит ли один сценарий для FBS и FBO?

Нет. На FBS 1С управляет остатком собственного склада и сборкой. На FBO 1С должна учитывать поставки, остатки Ozon, продажи, возвраты и финансовые отчёты. Смешанная модель требует отдельных правил по каждому складу.

Какие типовые ошибки API стоит отслеживать в Telegram?

Неверный warehouse_id, неизвестный offer_id, пустая цена, резкое изменение цены, ошибка модерации карточки, превышение частоты запросов, частично принятая пачка остатков, отмена заказа после резерва, возврат без связанной реализации.

Можно ли обновлять остатки каждые 1-2 минуты?

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

Что делать, если менеджеры уже меняют товары в Ozon вручную?

Перед запуском нужно решить, что остаётся ручным, а что становится зоной 1С. Иначе интеграция будет постоянно «чинить» ручные правки или перетираться ими.

Смотрите также

• Загрузка заказов из Озона в 1С: автоматическая синхронизация
• Экспорт остатков из 1С в Озон: синхронизация номенклатуры и цен
• Интеграция с маркетплейсами 1С: Озон, Wildberries, Авито
• Интеграция 1С с Wildberries: синхронизация остатков и цен
• Сколько стоит интеграция 1С с маркетплейсами

Интеграция 1С с Ozon FBS/FBO — от 30 000 ₽ за проект. Напишите мне в @onoutnoxon, пришлите конфигурацию 1С, схему продаж, количество SKU и список складов — верну короткий план запуска: что подключать первым, какие риски проверить и где лучше не автоматизировать до сверки.

Подробнее о возможностях — на странице Синхрон1С.

Источники:

• Ozon Help, «Работа с API»: https://docs.ozon.com/global/api/intro/
• Ozon Help, «Загрузка товаров через API»: https://docs.ozon.com/global/api/via-api/
• Ozon Help, «Информация о заказах» для FBS: https://docs.ozon.ru/global/fulfillment/fbs/ozon-logistics/upravlenie-zakazami/
• Ozon Help, «Работа с возвратами от покупателей»: https://docs.ozon.com/global/fulfillment/returns-utilization-fbs-fbo/customer-returns/
• Ozon Help, «Карантин цен»: https://docs.ozon.com/global/prices/price-quarantine/
• Ozon Help, «Работа со складом, заказами и возвратами»: https://docs.ozon.com/global/fulfillment/
• 1С Интеграции, «Ozon»: https://ext.1c.ru/integration/59
• 1С для торговли, «Как в 1С:Управлении торговлей 11.5 работать на Ozon по модели FBS»: https://torg.1c.ru/articles/kak-v-1s-upravlenii-torgovley-11-5-rabotat-na-ozon-po-modeli-fbs/
• Точка Банк, «Как управлять остатками на складе Ozon: FBS и FBO»: https://tochka.com/knowledge/marketpleisy/kak-upravlyat-ostatkami-na-sklade-ozon-fbs-i-fbo/

Для статьи использован AI-ассистент для структуры, черновой редакции и поиска источников. Практические выводы по маппингу складов, резервам, offer_id, ценовым предохранителям и возвратам проверены по документации Ozon/1С и по нашему опыту настройки обменов 1С с маркетплейсами. Из блока источников удалены самоссылки и нерелевантные SEO-мета-источники. Финальную редактуру выполнил Александр Руин. Обновлено: 2026-05-04.