Экспорт/импорт и интеграции сторонних сервисов: отчёт комиссионера, 1С и «единая правда» по продажам в 2026

Когда продажи идут через маркетплейсы, у бизнеса появляется сразу несколько "источников истины": личный кабинет площадки, бухгалтерия в 1С, складской учёт, выгрузки в Excel и переписки с поддержкой. Пока обороты небольшие, это терпимо. Но при росте ассортимента и числа заказов расхождения становятся системными: не сходятся суммы выплат, "плывут" комиссии и логистика, возвраты отражаются не в том периоде, а по одному и тому же заказу появляются разные цифры в разных файлах.

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

Что такое экспорт/импорт в контексте маркетплейсов и 1С

Экспорт/импорт здесь - это не "разово выгрузили файл", а регулярный контур обмена данными между системами:

маркетплейс формирует первичные финансовые документы (реализация, комиссии, услуги, возвраты, удержания);
селлер получает эти данные через личный кабинет или API;
данные загружаются в 1С в виде документов (чаще всего - отчёты комиссионера, поступления услуг, корректировки);
затем происходит сверка: заказы ↔ отгрузки ↔ выплаты ↔ документы.

Ключевая развилка - чем грузить:

файлами (Excel/CSV): проще стартовать, больше ручной работы, выше риск ошибок;
через API: быстрее и регулярнее, но нужна настройка ключей и контроль безопасности;
через "промежуточный сервис": когда стороннее решение берёт на себя получение данных, преобразование форматов и подготовку документов для 1С.

Почему "отчёт комиссионера" - центр учёта маркетплейсов

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

Практический момент: в 1С типовой алгоритм отражения комиссионных продаж опирается на документ "Отчёт комиссионера", а также различает сценарии продаж физлицам/юрлицам и особенности НДС/счетов-фактур. Это подробно разбирается в методических материалах по учёту продаж через Ozon, где подчёркивается, что при работе с площадкой заключается договор комиссии (посреднический договор) и что документ "Отчёт комиссионера" используется как базовый в учёте продаж.

"ООО Интернет Решения" и Ozon: почему это всплывает в поиске и в 1С

Селлеры регулярно вводят запрос "отчет комиссионера интернет решения", потому что в настройках интеграции и при загрузке отчётов в 1С в качестве контрагента часто фигурирует ООО "Интернет Решения" - юридическое лицо, через которое оформляется взаимодействие по документам в ряде сценариев.

На практике это важно не "для галочки", а для корректной настройки:

контрагент в 1С должен соответствовать вашему договору/оферте;
документ "Отчёт комиссионера" должен подтягиваться на нужный договор (вид договора "с комиссионером/агентом");
при интеграции по API обычно запрашиваются Client ID и API key.

В инструкциях по загрузке отчётов комиссионеров в 1С через рабочее место "Маркетплейсы и комиссионеры" как раз приводится логика: для Ozon при прямом обмене по API в поле "Контрагент" указывается ООО Интернет Решения, а также настраиваются идентификатор клиента и ключ API.

Какие данные нужно "гонять" между маркетплейсом и 1С: минимальный набор для контроля денег

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

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

продажи (строки реализации с товарами, количеством, ценой);
комиссии и удержания (вознаграждение, логистика, хранение, эквайринг/сервисы площадки - по структуре отчёта);
возвраты и отмены (в разрезе периода и причин);
взаиморасчёты (выплаты/зачёты/удержания);
закрывающие документы (если применимо: УПД/акты/сводные справки).

Если хотя бы один блок отсутствует, селлер может "видеть оборот", но не видеть прибыль и не понимать, почему "денег меньше, чем продаж".

Где брать данные по Ozon для учёта: кабинет, файлы, API и типовые документы

На практике селлеры используют комбинацию:

отчёты о реализации и финансовые документы из раздела "Финансы" личного кабинета;
выгрузки в Excel для последующей загрузки в 1С;
API (когда нужен регулярный обмен без ручных скачиваний).

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

Synchrozon и отчёт комиссионера: что важно понимать до настройки

Запросы "синхрозон отчет комиссионера" и "synchrozon отчет комиссионера" обычно возникают у селлеров, которые хотят автоматизировать связку Ozon ↔ 1С без ручных Excel.

Ключевая практическая мысль: даже при наличии инструмента обмена отчёт комиссионера всё равно требует "правильных исходных условий" в 1С:

номенклатура должна быть сопоставлена (SKU/артикул/штрихкод - что выбрано опорным ключом);
единицы измерения и упаковки должны быть настроены одинаково;
договоры и контрагенты заведены корректно;
периоды отчётов и "границы месяца" понятны (иначе возвраты и корректировки будут "скакать" по периодам).

В инструктивных материалах по загрузке отчётов комиссионеров подчёркивается, что при первой загрузке требуется сопоставление номенклатуры, а в дальнейшем - только для новых позиций; после сопоставления создаётся документ "Отчёт комиссионера".

Таблица: 3 схемы интеграции и что выбрать в 2026

Схема	Как работает	Плюсы	Риски/минусы	Кому подходит
Ручной импорт из Excel/CSV	Скачали отчёт → загрузили в 1С	Быстрый старт, минимум требований	Ошибки руками, «разные версии файла», нет регулярности	Небольшие обороты, тест ниши
Обмен по API	1С/модуль получает данные автоматически	Регулярность, меньше ручного труда	Нужны ключи, контроль доступа, поддержка обновлений	Стабильные продажи, регулярные отгрузки
Через промежуточный сервис	Сервис получает данные, преобразует и передаёт в 1С	Меньше техработ, часто есть «маппинг» и проверки	Важно понимать, что и как хранится, кто отвечает за расхождения	Команды/несколько юрлиц/много SKU

Пошаговая логика настройки импорта отчёта комиссионера в 1С (без привязки к одной конфигурации)

Ниже - универсальная логика, которая совпадает по смыслу в большинстве конфигураций 1С (БП/УТ/КА/ERP/УНФ), даже если названия кнопок отличаются.

Шаг 1. Подготовить "учётную основу" в 1С

В 1С должны быть:

организация (или несколько, если ведётся раздельный учёт);
контрагент маркетплейса и договор с видом "с комиссионером/агентом";
номенклатура с корректными единицами и штрихкодами/артикулами.

Шаг 2. Определить, что является ключом сопоставления товаров

На практике выбирают один опорный ключ и придерживаются его:

штрихкод (часто самый надёжный),
артикул продавца,
SKU площадки (если он стабилен).

Шаг 3. Настроить источник данных: файл или API

Если это файл - фиксируют "правильный тип отчёта" и формат выгрузки. Если это API - настраивают Client ID/API key и права доступа.

Шаг 4. Выполнить первичное сопоставление номенклатуры

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

Шаг 5. Создать документ "Отчёт комиссионера" и проверить контрольные суммы

Минимальные проверки:

сумма реализации (валовая),
сумма вознаграждения/удержаний,
сумма к выплате,
количество строк и товаров.

Шаг 6. Закрепить регламент (кто, когда и в каком периоде грузит отчёты)

Без регламента отчёты начинают "догружаться задним числом", и бухгалтерия перестаёт понимать, где финальная версия.

Типовые ошибки при импорте и как их быстро диагностировать

Ошибка 1. "Не нашлось номенклатуры" или "создались дубли"

Причина: разные ключи сопоставления в разных местах (например, где-то артикул, где-то штрихкод).

Решение: утвердить один ключ и массово привести карточки к нему, затем пересопоставить.

Ошибка 2. Комиссии/логистика не там, где ожидается

Причина: разные типы отчётов (сводный vs позаказный), разные периоды, смешение продаж и корректировок.

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

Ошибка 3. Возвраты "переезжают" между месяцами

Причина: возврат мог пройти в другом периоде, чем реализация, и отчёт отражает это по правилам площадки.

Решение: вести сверку по заказам и периодам, а не только по сумме месяца.

Ошибка 4. НДС/счета-фактуры и юрлица/физлица "встают криво"

Причина: неверно выбран вид операции в отчёте комиссионера, либо не учтены особенности отражения продаж.

Решение: опираться на методическую логику 1С по отчёту комиссионера и разделению операций (розница/опт) там, где это необходимо.

Экспорт/импорт в связке с другими сервисами: безопасность, доступы и юридические нюансы

Интеграции почти всегда связаны с доступом к данным:

токены API,
финансовые отчёты,
сведения о заказах и покупателях (в пределах того, что даёт площадка),
документы, которые могут содержать персональные данные (например, при реальных отправках).

Что важно предусмотреть в 2026 году:

хранить ключи доступа в защищённом контуре (минимальный круг лиц);
выдавать доступ по ролям, а не "всем менеджерам";
фиксировать регламент обновлений и резервного копирования;
проверять, где и как сервис хранит данные (особенно если выгрузки делаются через сторонние решения).

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

Как понять, что интеграция настроена правильно: 6 контрольных точек

Заказы и реализации сходятся по количеству (в штуках).
Возвраты отражаются и объяснимы по периодам.
Комиссии и удержания совпадают с отчётами площадки.
Выплаты и взаиморасчёты закрываются без "висяков".
Номенклатура не плодится дублями.
Любой показатель можно подтвердить первичкой (не только отчётом, но и детализацией).

Если хотя бы 2-3 пункта "плавают", бизнес будет постоянно тратить время на ручные сверки вместо роста.

Когда ручных выгрузок и "папки с Excel" становится недостаточно

С ростом продаж появляется типичная ситуация: отчёты скачиваются в разном формате, загружаются в 1С не всегда одинаково, а сверка превращается в бесконечную переписку между менеджером, бухгалтером и логистом. На этом этапе важнее не "ещё один файл", а единое место, где видно:

что именно загружено и за какой период;
какой отчёт комиссионера является финальным;
где расхождение и кто ответственен за исправление;
как это влияет на прибыль и остатки.

Сервис TotalCRM помогает выстроить управляемый контур учёта маркетплейсов: единые справочники, контроль загрузок и статусов, связка продаж/комиссий/возвратов, прозрачная сверка и понятная аналитика. Когда данные собираются в одном месте, бизнес перестаёт "жить между кабинетами" и начинает управлять цифрами, а не угадывать их.