Экспорт остатков из 1С в Ozon 2026: как не продать товар дважды

Экспорт остатков из 1С в Ozon нужен не для формальной галочки «есть интеграция», а для защиты от продаж товара, которого уже нет на свободном складе. В 2026 году рабочая схема строится вокруг трёх вещей: постоянный ключ товара (offer_id), правильный склад Ozon (warehouse_id) и расчёт свободного остатка в 1С с учётом резервов, брака и страхового запаса.

Эта статья про практический запуск выгрузки остатков для FBS/realFBS. Для FBO логика другая: продавец не выгружает собственный склад как доступный остаток Ozon, а получает остатки маркетплейса, планирует поставки и сверяет продажи/возвраты. Поэтому перед настройкой важно сначала зафиксировать схему продаж, а уже потом выбирать Excel, готовую обработку или обмен через Ozon Seller API.

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

• Ozon Seller API предназначен для автоматизации работы с товарами, заказами, ценами и остатками; для запросов нужны Client-Id и API-ключ из кабинета продавца.
• Для обновления остатков Ozon в документации указывает метод POST /v2/products/stocks, а список складов берётся через POST /v1/warehouse/list.
• Для чтения текущих остатков по FBS и realFBS используется метод POST /v4/product/info/stocks; его полезно запускать после тестовой выгрузки, чтобы сверить принятый результат.
• В 1С:Предприятии 8 есть штатные средства интеграции: REST/OData, HTTP-сервисы, web-сервисы, XML и JSON. Но это не отменяет проектирования правил обмена.
• Ручной Excel подходит только для маленького ассортимента и редких изменений. При активных продажах остаток устаревает уже между выгрузкой из 1С и загрузкой в Ozon.
• Главная практическая ошибка — отправлять в Ozon общий остаток склада, а не свободный остаток с вычетом резервов, брака, витринного остатка и продаж в других каналах.
• Перед боевым запуском достаточно теста на 5-10 SKU, но эти SKU должны покрывать нулевой остаток, товар с резервом, товар на нескольких складах и товар с изменённым артикулом.

Как считать остаток для Ozon

Для FBS и realFBS Ozon продаёт товар со склада продавца, поэтому 1С должна передавать не бухгалтерский остаток «всего есть», а доступное к продаже количество. Практическая формула выглядит так:

Остаток для Ozon = остаток на складе 1С - резервы - брак - внутренний страховой запас - остаток под другие каналы

Если в 1С на складе лежит 12 штук, 3 уже зарезервированы под розницу, 1 отложена как брак, а 2 оставлены как страховой запас, в Ozon нужно отправлять не 12, а 6. Иначе интеграция формально успешна, API ответил без ошибки, но склад получает заказ на товар, который уже занят.

Для разных категорий страховой запас отличается. По нашим внедрениям для дорогих штучных товаров часто достаточно не выгружать последние 1-2 единицы. Для ходовых расходников запас может быть 5-10 единиц, особенно если тот же склад одновременно кормит розницу, сайт, Wildberries и опт.

Способы выгрузки остатков

Я не советую начинать с обещания «подключим за 15 минут». Быстрая авторизация в API действительно занимает немного времени, но безопасная выгрузка остатков требует сверки складов, ключей товаров и расчёта свободного остатка. Именно там обычно находятся ошибки, а не в самом HTTP-запросе.

Практическая диагностика перед первым обменом

В нашем чек-листе первая выгрузка в Ozon никогда не идёт сразу по всему каталогу. Мы берём 5-10 контрольных SKU и отдельно фиксируем: товар в 1С, offer_id в Ozon, склад 1С, склад Ozon, текущий остаток, резерв, страховой запас и ожидаемое число для выгрузки.

1. Проверяем ключ товара. Если в 1С артикул менялся, нельзя молча считать его новым offer_id. Сначала нужна таблица соответствия: номенклатура 1С -> offer_id -> Ozon SKU.
2. Сверяем склады. Метод списка складов Ozon возвращает идентификаторы складов; в 1С каждому складу FBS нужен явный маппинг. Название «Основной» в 1С и «Основной» в Ozon не является надёжной связью.
3. Считаем свободный остаток. На тестовых SKU вручную сверяем остаток, резерв и страховой запас. Если расчёт не сходится на одном товаре, автоматизация всего каталога преждевременна.
4. Делаем сухой прогон. Интеграция формирует пачку для API, но сначала пишет её в лог: offer_id, warehouse_id, старый остаток, новый остаток, причина изменения.
5. Отправляем маленькую пачку. После POST /v2/products/stocks читаем результат и проверяем историю обновления остатков в кабинете Ozon.
6. Проверяем нулевой остаток. Товар с нулём должен корректно уходить в 0, а не пропускаться как «пустое значение».
7. Повторяем тот же обмен. Повторная отправка тех же чисел не должна создавать ошибки, дубли задач или лишние уведомления.

В одном из проектов проблема выглядела как «Ozon не принимает остатки», но фактически в 1С был выбран склад «Основной», а отправлялся warehouse_id другого FBS-склада. API-запрос был технически корректным, только бизнес-смысл был неверным. После явной таблицы складов и тестового набора из 7 SKU ошибка перестала повторяться.

Риски и диагностика

Эта таблица важнее рекламного сравнения сервисов. Если интеграция не показывает, какой SKU не выгрузился и почему, менеджер всё равно вернётся к Excel и ручной сверке.

Как часто обновлять остатки

Для маленького каталога можно начать с расписания раз в 15-30 минут. Для активного FBS лучше отправлять изменения по дельте: изменился свободный остаток в 1С, появилась отмена, создан резерв, проведена отгрузка — интеграция ставит задачу на обновление конкретного SKU.

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

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

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

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

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

Когда Excel ещё нормален

Excel не нужно демонизировать. Если у продавца 30 SKU, 1-2 заказа в неделю и один склад, ручная выгрузка может быть дешевле автоматизации. Но Excel должен быть управляемым: шаблон с фиксированными колонками, дата формирования файла, ответственный сотрудник, контрольная сверка 3-5 SKU после загрузки.

Автоматизация становится оправданной, когда есть хотя бы один из признаков:

• больше 100 SKU;
• продажи идут каждый день;
• один склад обслуживает несколько каналов;
• есть резервы в 1С;
• менеджеры регулярно ловят отмены из-за остатков;
• нужно видеть ошибки в Telegram, а не искать их в кабинете раз в неделю.

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

Где взять API-ключи Ozon?

В личном кабинете продавца Ozon в разделе настроек API. Для запросов Seller API используются Client-Id и Api-Key; их нельзя хранить в открытых обработках, Excel-файлах или отправлять в чат без необходимости.

Можно ли выгружать остатки без цен и заказов?

Да. Остатки можно запускать отдельным контуром. Это часто правильный первый этап: сначала стабилизировать склад, затем подключать заказы, цены, возвраты и финансовые отчёты.

Что использовать как главный ключ: артикул, SKU или штрихкод?

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

Нужно ли обновлять остатки FBO из 1С?

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

Как понять, что выгрузка реально прошла?

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

Можно ли запускать выгрузку каждую минуту?

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

Что делать, если часть товаров ведётся вручную в кабинете Ozon?

Нужно явно разделить зоны ответственности. Если 1С мастер остатков, ручные правки остатков в Ozon запрещаются регламентом. Если отдельные товары ведутся вручную, они должны быть исключены из автоматической выгрузки.

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

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

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

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

Источники:

• Ozon Help, «Работа с API»: https://docs.ozon.com/global/api/intro/
• Ozon Help, «Stock Management»: https://docs.ozon.com/global/en/fulfillment/stock/
• Ozon Seller API, метод обновления остатков POST /v2/products/stocks: https://docs.ozon.ru/api/seller/#operation/ProductAPI_ProductsStocks
• Ozon Seller API, метод чтения остатков POST /v4/product/info/stocks: https://docs.ozon.ru/api/seller/#operation/ProductAPI_ProductInfoStocks
• Ozon Seller API, список складов POST /v1/warehouse/list: https://docs.ozon.ru/api/seller/#operation/WarehouseAPI_WarehouseList
• 1С:Предприятие 8, «Интеграция»: https://v8.1c.ru/platforma/integraciya/
• 1С:Предприятие 8, «REST интерфейс»: https://v8.1c.ru/platforma/rest-interfeys/

Для статьи использован AI-ассистент для черновой структуры и проверки источников. Факты о Seller API, методах остатков, складах Ozon и средствах интеграции 1С перепроверены по документации Ozon и 1С 2026-05-04. Практический диагностический блок, формула свободного остатка, риск-таблица и рекомендации по Telegram-алертам основаны на внедрениях habab.ru/Noxon; финальную редактуру выполнил Александр Руин.