Заказы, возвраты и выплаты с маркетплейсов в учёт: без ручного переноса

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

Что именно переносим из кабинета площадки

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

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

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

Куда идут данные: 1С, МойСклад или таблица

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

Готовый модуль или своя интеграция

Для 1С и МойСклад есть готовые модули связи с маркетплейсами. Если ваш учёт типовой и модуль закрывает задачу, берите его. Он уже учитывает многие особенности площадок и обновляется, когда площадка меняет API.

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

Где чаще всего ломается

Первое — артикулы. На площадке у товара свой артикул и свой штрихкод, а в учёте своя номенклатура. Если связи нет, продажа не найдёт товар. Поэтому в начале работы мы составляем таблицу соответствия. Новые товары без пары скрипт не проводит молча, а показывает списком.

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

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

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

Почему бухгалтер всё равно проверяет

Скрипт переносит данные, но не отвечает за налоги. Как отражать продажи через площадку, какие документы нужны и как учитывать удержания — решает ваш бухгалтер. Правила зависят от системы налогообложения и договора с площадкой, так что спорные моменты стоит обсудить с ним заранее.

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

Как это выглядит, когда настроено

Утром бухгалтер открывает учёт. За вчерашний день уже созданы документы продаж по каждой площадке. Возвраты лежат отдельно, у каждого есть ссылка на исходную продажу. Остатки на складе площадки уменьшились на проданные товары.

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

Никто не переносит цифры из кабинета руками. Бухгалтер проверяет, а не набирает.

Как заказать такую задачу

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

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

Если площадки и учёт стабильны, это разовая задача. Если вы часто добавляете площадки или юрлица, а площадки меняют API, удобнее абонентка. Формат разовых работ описан на странице разовые задачи: скрипты, парсеры, выгрузки.

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

Можно ли подключить сразу Wildberries и Ozon?

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

Что если площадка поменяет API?

Скрипт перестанет получать данные и пришлёт уведомление. Правку делаю в рамках абонентки или отдельной задачей.

Можно ли загрузить продажи за прошлые месяцы?

Обычно да, в пределах того, что площадка отдаёт по API. Глубину истории проверяю на старте.

Нужен ли свой сервер?

Для скрипта нужен сервер или облако, где он будет работать по расписанию. Лучше, если это ваш сервер.

Какие доступы нужны?

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

Коротко о главном

Заказы, продажи, возвраты и выплаты с маркетплейсов можно переносить в 1С, МойСклад или таблицу автоматически. Данные берутся по API площадок, а возвраты и удержания идут отдельными потоками.

Работа держится на таблице соответствия артикулов, защите от двойного учёта и регулярном заборе возвратов. Правила отражения в учёте задаёт бухгалтер, и он же проверяет результат.

Если у вас кто-то каждую неделю переносит цифры из кабинета площадки руками, напишите, где продаёте и где ведёте учёт. Скажу, хватит ли готового модуля или нужна своя связка. Напишите в Telegram, MAX или VK.