Загрузка заказов из Озона в 1С 2026: автоматическая синхронизация без программиста

Селлер на Ozon с потоком 50–100 отправлений в день каждое утро открывает кабинет, копирует PostingNumber вида 39268230-0002-3, забивает товары в 1С вручную и резервирует остатки. На это уходит 2–3 часа, а просрочка хотя бы одного отправления FBS = штраф и просадка рейтинга. Параллельно остатки на Ozon отстают от 1С — приходят заказы на товар, которого уже нет, и площадка автоматически снижает индекс качества карточки. В 2026 году весь этот цикл собирается в Seller API за 15 минут — но только если знать, где спотыкаются типовые модули.

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

• FBO vs FBS vs realFBS — три разные модели и три разных набора методов API. По FBO склад держит Ozon, остатки обновлять не нужно — селлер только смотрит статусы через POST v2/posting/fbo/list. По FBS и realFBS товар лежит у селлера, остатки обязательны, отгрузки оформляет он сам.
• Лимиты Seller API: для метода обновления остатков /v2/products/stocks — до 100 товаров за один запрос и до 80 запросов в минуту. У других методов лимиты свои, но порядок тот же; самописные интеграции, гоняющие остатки в один поток без батчинга, легко упираются в throttling в пиковый сезон.
• Авторизация — пара Client-Id + Api-Key в HTTP-заголовках, ключ создаётся в ЛК Ozon Seller (Настройки → API-ключи → тип «Администратор»). Без типа «Администратор» часть методов отдаёт 403.
• Просрочка отгрузки FBS — Ozon учитывает отмены по вине продавца в показателях качества, а при непередаче отправления перевозчику в течение 7 дней после плановой даты может отменить заказ. Для 1С это не «косметический статус», а риск потери заказа и качества кабинета.
• PostingNumber ≠ номер заказа. Один заказ (order_number) может разъехаться на несколько posting_number — после ответа API нужно отдельно вызывать POST v2/posting/fbo/list или POST v3/posting/fbs/list по order_number, иначе часть постингов выпадет.
• Маркировка «Честный знак» для FBS — коды получаются методом POST v1/posting/marks по posting_number. Если код не передан, отгрузка не пройдёт приёмку на складе Ozon.
• Двусторонняя синхронизация Синхрон1С — 30 000 ₽ за проект, настройка за 15 минут.

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

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

В нашем внедрении мы не начинаем обмен с кнопки «подключить API». Сначала берём 20–30 реальных отправлений из кабинета Ozon: FBS в awaiting_packaging, FBS в awaiting_deliver, отменённые, доставленные и хотя бы один возврат или невыкуп. По ним сверяем, что 1С создаёт не абстрактный «заказ маркетплейса», а правильный документ: Заказ клиента с резервом для FBS, продажу через комиссионера или реализацию в пути для выбранной схемы учёта, отдельную операцию по возврату при PartialReturn.

На тесте обязательно проверяем две неприятные ситуации. Первая — один order_number разбивается на несколько posting_number: если модуль хранит только номер заказа, склад потом не понимает, какое отправление уже собрано. Вторая — частичный отказ при получении: исходное отправление может остаться доставленным, а возврат появляется отдельной записью. Поэтому в обмене должны быть отдельные журналы для постингов, возвратов и ошибок API, а не один общий лог «успешно/неуспешно».

Сравнение способов загрузки заказов

Типичные ошибки и обходы (по реальным кейсам 2024–2026)

1. Расхождение PostingNumber и order_number. В ответе API на список постингов возвращаются не все отправления заказа — Ozon явно предупреждает об этом в документации. Если самописная интеграция не дёргает дополнительно POST v2/posting/fbo/list или v3/posting/fbs/list по order_number, часть постингов «теряется», а в 1С приезжает половина заказа. Лечится повторным запросом по order_number сразу после первичной загрузки.
2. Статус awaiting_packaging vs awaiting_deliver. В модулях встречался баг: заказ на Ozon уже в статусе «Доставляется», а в 1С висит «Ожидает сборки». Причина — модуль слушает только переход в awaiting_packaging и не подтягивает дальше. У RDV и аналогов есть отдельный флаг «Получать заказы FBS только после сборки» — он создаёт документ только из awaiting_deliver, чтобы оператор не делал двойную работу в ЛК и в 1С.
3. Отмена покупателем после сборки. Покупатель отказался от части товаров на пункте выдачи — головное отправление остаётся в статусе «Доставлено», а Ozon заводит дополнительный постинг со статусом «Отменено» и type: PartialReturn в v1/returns/list. Самописные интеграции, которые ждут изменения статуса исходного отправления, не видят возврат — деньги покупателю возвращаются, а в 1С остаётся реализация на полную сумму. Снимать резерв и оформлять возврат нужно по событиям из v1/returns/list, а не по статусу исходного posting.
4. Маркировка «Честный знак» не отдана. На FBS-отправлении с маркированным товаром нужно отдать коды через POST v1/posting/marks. Если интеграция не поддерживает этот метод (старые модули) — отгрузка падает на приёмке Ozon, штраф летит селлеру. Проверка: в 1С на стороне обмена с ИС МП должен быть включён обмен и заполнены РНПТ.
5. Валидация артикула при сопоставлении. Сторонние модули сопоставляют товары 1С↔Ozon по артикулу, коду или штрихкоду. Если в карточке Ozon стоит offer_id без ведущих нулей, а в 1С артикул 0001234 — товар «не находится», заказ создаётся с пустой номенклатурной строкой. Воркэраунд: либо нормализовать артикулы заранее, либо включить подбор по штрихкоду как основной ключ.
6. Остатки FBO ≠ остатки локального склада. Селлеры путают: для FBO склад держит Ozon, обновлять остатки через API не нужно (и нечего — Ozon учитывает свои). Передача собственных остатков на FBO-склад приводит к ошибкам валидации. Для планирования поставок есть отдельный метод POST v1/analytics/stocks — он отдаёт остатки на складе Ozon, а не наоборот.
7. Throttling по лимитам. Метод /v2/products/stocks — 80 запросов в минуту, до 100 SKU за запрос. Селлеры с ассортиментом 30k+ SKU при попытке обновить всё одним проходом ловят 429 и серверные ошибки. Решение: батчить по 100 SKU и держать паузу между запросами; высокооборотные SKU обновлять чаще, «длинный хвост» — раз в час.
8. Просрочка отгрузки FBS из-за асинхронного обмена. Если обмен идёт раз в час, заказ может прилететь в 1С уже за 30 минут до дедлайна сборки — оператор физически не успевает. Для FBS-селлеров критичен интервал не больше 15 минут, для пиковых дней — 5 минут. Параллельно держим Telegram-уведомления о новых отправлениях, чтобы склад не упустил.
9. Ключ API без типа «Администратор». При создании ключа в ЛК Ozon легко выбрать тип «Только чтение» — часть методов обмена (создание этикеток, передача статусов) будет отдавать 403. Лечится пересозданием ключа с типом «Администратор».
10. Мультиаккаунт в одной базе 1С. Селлеры с двумя юрлицами часто пытаются завести оба Client-Id в один блок настроек — модуль начинает грузить заказы вперемешку. В Синхрон1С каждое юрлицо привязывается к своей организации в 1С, заказы помечаются префиксом, остатки разводятся по складам.

Риск-матрица для обмена Ozon → 1С

Как настроить за 3 шага

Шаг 1. В ЛК Ozon Seller: Настройки → API-ключи → «Создать ключ», тип «Администратор». Скопируйте Client-Id и Api-Key. Проверить ключ можно сразу через консоль на dev.ozon.ru — например, методом получения списка складов.

Шаг 2. Напишите @onoutnoxon: «Хочу загружать заказы из Ozon в 1С». Укажите конфигурацию (УТ 11, ERP 2, КА 2, УНФ 1.6, Бухгалтерия 3.0), модель работы (FBO / FBS / realFBS) и передайте ключи. Для УТ 11.5 проверим, что релиз ≥ 11.4.6.166 — иначе типовой обмен с Ozon просто не включится.

Шаг 3. Выберите расписание: 5 минут для FBS-селлеров в пик, 15 минут для штатной работы, час — для FBO. Укажите склад отгрузки в 1С, схему оформления (передача комиссионеру или «реализация в пути»), включите автозарезерв и Telegram-уведомления.

Telegram-бот Синхрон1С — автоматический импорт заказов из Озона в 1С

Что синхронизируется между Озоном и 1С

FAQ

Какие конфигурации 1С поддерживают загрузку заказов из Ozon? Типовой сценарий Ozon описан для 1С:Управление торговлей 11.5: в ней есть рабочее место управления продажами на Ozon, настройка FBS-складов, загрузка отправлений, резерв и печать этикеток. Для ERP, КА, УНФ, Бухгалтерии 3.0 и старых нетиповых баз нужно отдельно смотреть релиз, включённые подсистемы и доработки обмена.

Чем отличается загрузка по FBO, FBS и realFBS? По FBO склад держит Ozon — приезжают только статусы и отчёты, остатки обновлять не нужно. По FBS и realFBS товар у селлера: грузятся отправления, нужно передавать остатки и оформлять отгрузку самостоятельно. realFBS отличается от FBS логистикой (доставка силами селлера), но методы API общие с FBS.

Что делать при отмене заказа покупателем после сборки? Подписаться на v1/returns/list и обрабатывать type: PartialReturn — Ozon заводит отдельный постинг в статусе «Отменено», а исходный остаётся «Доставлено». Синхрон1С автоматически снимает резерв и шлёт уведомление в Telegram.

Как быть со штрафами за просрочку FBS? Сократить интервал обмена до 5–15 минут и поставить Telegram-уведомления на новые отправления. Ozon прямо указывает, что отмены по вине продавца влияют на показатели качества, а просроченная передача перевозчику может привести к отмене заказа. На больших объёмах лучше разделять процессы: в 1С грузить только те статусы, с которыми реально работает склад.

Можно ли загружать заказы с нескольких аккаунтов Ozon в одну базу 1С? Да. Каждый Client-Id привязывается к своей организации в 1С, заказы маркируются префиксом, остатки разводятся по складам. Без такого разведения мультиаккаунт ломает учёт.

Что с маркированным товаром «Честный знак»? Коды получаются методом v1/posting/marks по posting_number и передаются в отгрузке. На стороне 1С должен быть включён обмен с ИС МП и заполнены РНПТ — иначе отгрузка не примут на складе Ozon.

Какие лимиты у Seller API? У каждого метода свои. Для остатков /v2/products/stocks — 100 SKU за запрос, 80 запросов/минуту. Селлерам с большим ассортиментом нужно батчить и расставлять приоритеты по оборачиваемости SKU.

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

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

Стоимость интеграции — 30 000 ₽ за проект, включая разбор текущих ошибок обмена и настройку разделения FBO/FBS/realFBS. Напишите в Telegram: @onoutnoxon — настроим синхронизацию под ваши задачи.

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

Источники:

• Ozon Help — Работа с API — API-ключ и Client ID, методы для FBS-отправлений, обновления цен и остатков.
• Ozon for dev — Как работает Seller API — авторизация Seller API через заголовки Client-Id и Api-Key.
• Ozon for dev — Справочник методов Seller API для логистики — методы FBO/FBS, возвратов, маркировки и логистических операций.
• Ozon Help — Продажа со своего склада FBS — схема FBS, сборка и отгрузка со склада продавца.
• Ozon Help — Отмена продавцом — влияние отмен по вине продавца на показатели качества и отмена при просроченной отгрузке.
• Ozon Help — Работа с возвратами от покупателей — типы возвратов, невыкупы, частичный отказ при получении и статусы возвратов.
• Ozon Help — Возвраты realFBS и FBP — обработка заявок на возврат, сроки решений и споры.
• 1С:УТ 11.5 — работа на Ozon по модели FBS — настройка подключения, загрузка заказов, резерв, документы отгрузки и статусы.
• 1С:УТ 11.5.26.106 — изменения релиза — актуальный релизный контекст 1С:УТ на апрель 2026.

Для статьи использован AI-ассистент для структурирования и подбора источников; конкретные методы API, лимиты, форматы PostingNumber и поведение при PartialReturn сверены вручную с документацией dev.ozon.ru и обсуждениями реальных внедрений. Финальную редактуру выполнил Александр Руин, основатель habab.ru. Обновлено: 2026-05-04.