Выкупы Ozon в 1С:Управление торговлей 11: товар у площадки, комиссия в учёте и одно УПД без ручного ввода

Аяз АдгамовБизнес-аналитик 1С, эксперт по автоматизации работы с маркетплейсами

11 сентября 2026 · 10 минут

Когда Ozon отправляет ваш товар покупателю за границу, он не продаёт его как комиссионер — он выкупает товар сам. В личном кабинете появляется отдельный документ «Детализация по выкупленным товарам», а в отчёт комиссионера эти отправления не попадают вовсе. Типовая УТ 11 об этом не знает, модуль интеграции с Ozon на УТ 11.4 тоже, и в API площадки этих данных нет — они живут только файлом в кабинете. Мы разобрали, как такая продажа должна ложиться в учёт, и собрали обработку, которая за два клика превращает файл Ozon в цепочку документов: возврат товара с комиссии, приходный ордер, заказ, реализация напрямую на Ozon и одно УПД на период. Сумма сходится с отчётом площадки до копейки. Ниже — почему это оказалось сложнее, чем звучит, и на каких пяти граблях лежит эта задача.

По темеFBS-обмен с 1С: схема со своего склада на всех площадках и Кабинет показывает оборот. Прибыль знает только ваш учёт: что маркетплейс не посчитает за селлера

Почему выкуп ломает комиссионную схему

Обычная продажа на Ozon в учёте выглядит просто: товар передаётся площадке документом «Передача на комиссию», раз в месяц загружается отчёт комиссионера, и он списывает проданное с комиссии и начисляет вознаграждение. Схема отлажена годами, и модули интеграции делают это автоматически.

Зарубежные отправления идут иначе. Ozon не может продать ваш товар покупателю в Беларуси или Казахстане от вашего имени по комиссионному договору — поэтому он покупает его у вас сам, как российское юрлицо ООО «Интернет Решения», а дальше продаёт за рубеж уже от себя. Для вас это не комиссия, а прямая продажа юридическому лицу с НДС 22 % и обязанностью выставить УПД.

Что это значит технически. Товар физически уже у Ozon и числится у вас на комиссии. Чтобы продать его напрямую, в учёте его сначала нужно вернуть с комиссии и только потом оформить реализацию. Отчёт комиссионера при этом остаётся правильным: выкупы в него не входят, задваивания выручки нет. Мы проверили это на 266 отчётах комиссионера одной базы — ни одной строки с ценами выкупа.

Объём таких продаж у среднего продавца электроники — два-три десятка отправлений в месяц. Слишком мало, чтобы строить отдельный контур, и слишком много, чтобы месяц за месяцем оформлять пять документов на каждое отправление руками.

Где на самом деле лежат данные о выкупах — и где их нет

Первое, что хочется сделать, — забрать выкупы по API, как забирается всё остальное. Мы прошли этот путь до конца, чтобы не гадать.

Позаказный отчёт о реализации (/v1/finance/realization/posting) за месяц вернул 443 строки — это тот же комиссионный отчёт. Наших выкупов в нём ноль. Поле legal_entity_document там есть, но оно про другое: про продажи юрлицам-покупателям через Ozon Бизнес, с документами вида «103902/18».

Реестр продаж юридическим лицам (/v1/finance/document-b2b-sales) сформировался, 118 строк — обычные покупатели-юрлица. Выкупов самого Ozon в нём тоже нет.

ЭДО. У клиента живой обмен с Ozon через СБИС — больше полутора тысяч документов. Исходящие — это передачи на комиссию, входящие — акты по услугам площадки. Документов с номерами или суммами выкупов среди них не нашлось.

Список отчётов кабинета (/v1/report/list) — доступные типы ровно те, что обёрнуты в модуле интеграции: товары, цены, остатки, возвраты, отправления, финансы. Про выкупы ничего.

Самое убедительное подтверждение косвенное: сам модуль Synchrozon для выкупов требует файл из личного кабинета, а не запрос к API. Если бы метод существовал, вендор бы им пользовался.

Итог: единственный источник — файл «Детализация по выкупленным товарам» из раздела Финансы → Документы, за половину месяца. Это не ограничение обработки, а устройство площадки. Два файла в месяц — весь ручной труд, который остаётся.

Что умеет модуль интеграции и почему этого мало

В Synchrozon механизм выкупов есть, и он даже удобно спрятан: команда «Выкуп товаров, УПД», регистр с историей загрузок, кнопка «Загрузить из шаблона УПД». Модуль разбирает XML УПД, находит аккаунт продавца и создаёт реализацию со счётом-фактурой.

Три вещи мешают этим пользоваться.

Первая — версия. Кнопка доступна только на УТ 11.5.20.75 и выше; на 11.4, где живёт большинство торговых баз, она отключена с надписью «Версия не поддерживается». Переход на 11.5 — отдельный проект, а не способ закрыть выкупы.

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

Третья, и главная, — модуль не делает возврат с комиссии. Без него товар в учёте остаётся у Ozon на комиссии, и реализация либо не проводится, либо списывает то, чего на складе нет.

Так что на УТ 11.4 путь один — своя обработка. Хорошая новость: она получается небольшой, потому что весь тяжёлый учёт делает типовая конфигурация. Обработка только правильно её просит.

Цепочка документов, которая сходится

На каждый «Отчёт о выкупленных товарах» из файла площадки — или один на весь период, это переключатель — обработка создаёт пять документов, строго в таком порядке и с разнесённым временем внутри дня:

1. Возврат товаров от клиента с операцией «Возврат от комиссионера» — снимает товар с комиссии. Основание — конкретная передача на комиссию, цена — цена передачи, а не выкупа.
2. Приходный ордер на товары — ставит возвращённый товар на склад. Нужен, потому что склад ордерный; без него реализация упирается в «недостаточно товара».
3. Заказ клиента — в этой базе реализация клиенту всегда идёт от заказа, и доработка СМС-оповещений при проведении обращается к заказу напрямую.
4. Реализация товаров и услуг с операцией «Реализация» на ООО «Интернет Решения», по цене реализации из отчёта площадки, с НДС 22 %.
5. Счёт-фактура выданный — создаётся типовым механизмом при проведении реализации; обработка находит его, а не создаёт второй. Печатная форма — УПД.

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

Результат на реальных данных: за месяц — два с половиной десятка отправлений, полтора десятка отчётов о выкупе, сумма реализаций до копейки равна итогу файлов площадки, УПД на весь период с корректным НДС и заполненными графами страны происхождения и номера декларации — они подтягиваются из номенклатуры сами.

Пять граблей, на которых лежит эта задача

Каждая из них стоила отдельного прогона. Ни одна не видна из кода — только из живой базы.

1. Одинаковое время документов. Если возврат и реализация созданы одной секундой, реализация не видит товар, который возврат только что поставил на склад: контроль остатков работает на момент времени документа. Семь комплектов из двенадцати падали с «Недостаточно товара в наличии на складе». Лечится разнесением внутри дня: возврат 12:00, ордер 12:00:30, заказ 12:01, реализация 12:02.

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

3. Приходный ордер на складе с адресным хранением требует трёх реквизитов, и каждый валит проведение своим текстом: без зоны приёмки — «значение поля Ячейка не может быть пустым», без хозяйственной операции — «отражение операции в регистр Товары к поступлению не поддерживается», без отправителя — «запись пустого отправителя поддерживается только для приёмки по прочему оприходованию». Зону приёмки берём из последнего проведённого ордера склада, операцию — у документа-распоряжения, отправитель — партнёр Ozon.

4. Типовая конфигурация не считает НДС и сумму документа при программном создании. Расчёт живёт в форме документа. Реализация из кода проводится с нулевым НДС и пустой суммой в списке — и УПД уходит с нулями. Суммы НДС в строках и сумму документа обработка заполняет сама.

5. Квадратные скобки в ПОДОБНО. Маркер обработки в комментарии документов был вида [ИТ_...]. В языке запросов 1С скобки — это диапазон символов, и поиск «своих» документов возвращал 107 тысяч чужих. Отсюда и медленный запуск, и риск задеть чужое при очистке. Экранирование через СПЕЦСИМВОЛ решает; сухой прогон перед пометкой на удаление — спасает.

Отдельно стоит режим проверки: он честен по каждому комплекту, но не по сумме. Каждый комплект откатывается, и следующий видит исходные остатки, поэтому в проверке пройдёт и то, что при реальной записи упрётся в нехватку на комиссии. Протокол про это предупреждает — потребность считается по номенклатуре за весь файл, а не по комплекту.

Что остаётся ручным — и почему это правильно

Всё остальное — разбор файла, сверка, поиск товара, возврат, ордер, заказ, реализация, УПД, защита от дублей при повторной загрузке — делает обработка.

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