1С:Розница и Ozon: как организовать учёт продаж маркетплейса

Магазины, которые торгуют через Ozon, рано или поздно сталкиваются с двойным учётом: заказы приходят в личный кабинет маркетплейса, а остатки, цены и кассовая дисциплина живут в 1С:Рознице. Без интеграции менеджеры вручную переносят заказы, остатки расходятся, и возникают отмены по причине «нет товара» — а они напрямую снижают рейтинг продавца и видимость карточек.

1С:Розница не имеет встроенного штатного модуля обмена с Ozon во всех редакциях, поэтому на практике применяют три подхода: готовые внешние обработки и расширения, обмен через API Ozon Seller силами программиста или сторонние сервисы-коннекторы. Выбор зависит от объёма заказов, схемы работы (FBS, FBO, realFBS) и того, какая конфигурация у вас развёрнута — базовая, ПРОФ или КОРП.

Ниже разобраны практические шаги: как выбрать схему учёта, что настроить до подключения, как вести заказы и возвраты, как сверять выплаты Ozon с учётом и какие ошибки чаще всего ломают интеграцию.

Выберите схему работы: от неё зависит учёт

Ozon поддерживает несколько логистических схем, и каждая по-разному отражается в учёте. При FBS ( fulfillment by seller) товар хранится на вашем складе, вы сами собираете и отгружаете заказы — в 1С это обычная реализация с резервированием. При FBO товар лежит на складе Ozon, и в 1С нужно вести отдельный «склад Ozon», на который делается перемещение, а продажи фиксируются по отчётам маркетплейса о реализации.

Схема realFBS (продажа со своего склада с доставкой силами продавца) в учёте близка к FBS, но статусы заказов обновляются иначе, и обмен должен уметь передавать трек-номера и подтверждать отгрузку. Если вы совмещаете схемы, в 1С потребуется минимум два склада: основной и «FBO Ozon», иначе остатки будут путаться.

Подготовьте справочники до подключения

Главная причина сбоев интеграции — рассинхрон номенклатуры. Ozon идентифицирует товар по offer_id (артикул продавца) и штрихкоду, поэтому до настройки обмена проверьте, что в 1С у каждой товарной позиции заполнены артикул и штрихкод, а они совпадают с данными карточек в личном кабинете Ozon. Разночтения вида «АРТ-001» в 1С и «art_001» на Ozon приведут к тому, что заказы не найдут свой товар.

Также заранее создайте в 1С: контрагента «Ozon» (или нескольких, если нужен раздельный учёт по схемам), договор с типом «с комитентом» либо обычный договор реализации — в зависимости от того, как вы отражаете агентскую схему, отдельные склады под FBO и под резерв заказов, а также статью расходов для комиссий и услуг маркетплейса.

1. 1
   Проверьте заполнение артикулов и штрихкодов у всей номенклатуры, которая выставлена на Ozon
2. 2
   Создайте контрагента Ozon, договор и склады: основной, резерв, FBO при необходимости
3. 3
   Сгенерируйте API-ключи в личном кабинете Ozon Seller (раздел настроек API)
4. 4
   Установите и настройте модуль обмена: расширение, коннектор или собственную обработку
5. 5
   Проведите тестовую выгрузку остатков и загрузку одного заказа, сверьте результат вручную

Настройте обмен по API

Ozon предоставляет Seller API: через него получают список отправлений (postings), подтверждают сборку, обновляют остатки и цены, скачивают отчёты о реализации. Ключи API создаются в личном кабинете продавца; для работы нужны Client ID и API Key с правами на заказы, товары и финансы. Храните ключи в защищённом хранилище 1С или в настройках расширения, не прописывая их в открытом коде общих модулей.

Типовой цикл обмена выглядит так: регламентное задание каждые 5–15 минут запрашивает новые отправления в статусе «ожидают сборки», создаёт в 1С заказ покупателя или документ реализации, резервирует товар. После сборки в 1С статус передаётся обратно на Ozon. Отдельное задание выгружает остатки и цены — при FBS это критично, потому что просроченные остатки означают заказы на отсутствующий товар.

POST https://api-seller.ozon.ru/v3/posting/fbs/list
Headers: Client-Id: <ваш_client_id>, Api-Key: <ваш_api_key>
Body: {"filter": {"status": "awaiting_packaging"}, "limit": 100}

Если используете готовое расширение, большая часть этого уже реализована: вам нужно указать ключи, расписание и правила сопоставления статусов. При собственной разработке закладывайте обработку ошибок API (лимиты запросов, таймауты) и журналирование — без журнала обмена поиск потерянного заказа превратится в ручную сверку сотен записей.

Ведите заказы и отгрузки в 1С

Для FBS-заказов удобна схема «заказ покупателя → реализация товаров и услуг». Заказ создаётся при получении отправления с Ozon, товар резервируется, после сборки оформляется реализация. Номер отправления Ozon сохраняйте в дополнительном реквизите документа — он понадобится для возвратов и разбирательств.

Оплата по FBS/FBO приходит не от покупателя, а от Ozon единым платежом по итогам периода за вычетом комиссий. Поэтому розничные чеки на каждый заказ, как правило, не пробиваются: продажа проходит через маркетплейс как агента, и кассовый чек покупателю формирует Ozon. Уточните у своего бухгалтера, как именно в вашей схеме отражается выручка и нужен ли вам отчёт комиссионера — это влияет на настройку документов.

Учитывайте возвраты и отмены

Возвраты на Ozon делятся на отмены до отгрузки (заказ просто снимается с резерва в 1С) и возвраты после получения покупателем. Вторые приходят с задержкой: товар едет обратно, статус меняется в личном кабинете. Обмен должен отслеживать статусы возвратов и создавать в 1С документ возврата от покупателя с привязкой к исходной реализации.

Отдельно контролируйте состояние возвращённого товара: часть приходит продажабельной, часть — с повреждениями. Практичное решение — склад «Возвраты Ozon», с которого товар после проверки перемещается либо обратно в продажу, либо списывается. Без этого разделения брак будет автоматически улетать обратно в доступные остатки маркетплейса.

Сверяйте выплаты и комиссии

Ozon выплачивает выручку по расписанию, удерживая комиссию за продажу, логистику, хранение (при FBO) и прочие услуги. Для сверки используйте отчёт о реализации и финансовый отчёт из личного кабинета: сумма реализованных товаров должна сойтись с реализациями в 1С за период, а разница между выручкой и выплатой — с начисленными комиссиями.

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

Ограничения и когда нужна доработка

Стандартная 1С:Розница ориентирована на кассовую торговлю, а не на мультиканальные продажи, поэтому для полноценной работы с Ozon почти всегда требуется расширение или внешний сервис. Если у вас несколько маркетплейсов (Ozon, Wildberries, Яндекс Маркет), задумайтесь о коннекторе, который агрегирует все каналы в одну точку обмена, либо о переходе на 1С:Управление торговлей/Комплексную автоматизацию, где учёт заказов гибче.

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

Частые вопросы