Интеграция 1С с маркетплейсами: Wildberries, Ozon, Яндекс Маркет

Знакомая картина: продавец торгует на трёх площадках, выручка растёт, а в конце месяца он сидит с четырьмя вкладками Excel и не может ответить на простой вопрос — сколько он заработал. Деньги на счёт пришли не те, что в отчёте площадки; отчёт не сходится с 1С; по какому товару прибыль, а по какому убыток, не знает никто. Интеграция 1С с маркетплейсами нужна ровно за этим: чтобы заказы, остатки, комиссии и отчёты о реализации попадали в учёт сами.

Что вообще нужно передавать

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

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

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

Термины, без которых разговор не сложится

• FBO. Товар лежит на складе площадки, она же его хранит, собирает и доставляет. Для 1С это значит: остаток физически не у вас, но принадлежит вам, и его нужно учитывать отдельно.
• FBS. Товар лежит на вашем складе, площадка передаёт заказ, вы собираете и передаёте его в доставку. Здесь остаток общий с остальными каналами продаж — отсюда большинство проблем.
• Отчёт о реализации. Документ площадки за период: что продано, по какой цене, сколько удержано и сколько вам перечислят. Основа для выручки, НДС и расчёта прибыли.
• Комиссия и удержания. Всё, что площадка вычитает из вашей выручки: своё вознаграждение, доставку, хранение, приёмку, эквайринг, штрафы и компенсации.
• Личный кабинет и ключ API. Кабинет — то, куда заходит человек; ключ — то, чем пользуется программа. Ключ выдаёте вы, и он должен быть отдельным для обмена.

Схемы работы, состав удержаний и периодичность отчётов у Wildberries, Ozon и Яндекс Маркета различаются, причём площадки их регулярно меняют. Поэтому актуальные условия всегда смотрят в самом кабинете, а интеграцию проектируют так, чтобы она переживала эти изменения без переписывания с нуля.

Главная боль: один остаток, три витрины

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

Причина всегда одна из четырёх, и все они настраиваются.

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

Отдельно стоит договориться, что считать остатком для FBO. Товар, отгруженный на склад площадки, ещё ваш, но продать его через другой канал вы не можете. В 1С это решается отдельным складом на каждую площадку и документом перемещения при отгрузке партии — тогда и остаток виден, и деньги в товаре посчитаны.

Комиссии и реальная маржа

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

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

Технически для этого подходят 1С:Управление торговлей, 1С:Розница, УНФ для небольшого бизнеса и 1С:ERP, когда к торговле добавляется производство. Выбор конфигурации важнее, чем кажется: в программе, где нет нормального учёта себестоимости, маржу по товару не посчитать никакой интеграцией.

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

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

Границы готовых модулей проходят там, где начинается ваша специфика.

• Смешанные схемы. Одновременно FBO, FBS и собственная розница с общего остатка — нужна логика резервов и квот.
• Своё ценообразование. Разные цены по площадкам, автоматический пересчёт под акции и комиссии, минимальная цена, ниже которой продавать нельзя.
• Комплекты и наборы. На площадке продаётся набор, а в 1С это три отдельные позиции, которые нужно списать и собрать.
• Доработанная база. Если конфигурацию уже правили, коннектор может не встать без адаптации.
• Своя аналитика. Отчёты по рекламным расходам, по оборачиваемости на складах площадок, по возвратам.

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

Пошаговый план подключения

• 1. Навести порядок в номенклатуре. Артикулы, штрихкоды, единицы измерения, характеристики. Ключ сопоставления должен быть один и уникальный — чаще всего артикул или штрихкод.
• 2. Описать склады. Какие склады участвуют в продажах на площадках, отдельный склад под каждый FBO, что считается свободным остатком.
• 3. Решить вопрос цен. Какие типы цен уходят на какую площадку и кто их меняет — 1С или кабинет. Двух хозяев у цены быть не должно.
• 4. Получить доступы. Ключи API в каждом кабинете, отдельные для обмена, с нужными правами.
• 5. Обновить конфигурацию. Поддержка площадок приходит с релизами — очередными версиями конфигурации. На старом релизе нужных настроек может просто не быть.
• 6. Сделать копию и настроить на ней. Перед любыми работами делается резервная копия базы; первый обмен при неверной настройке умеет наплодить документов очень быстро.
• 7. Сопоставить товары. Таблицу соответствия первый раз заполняют полуручным способом — это нормальная разовая работа.
• 8. Запустить пилот. Одна площадка, одна группа товаров, несколько заказов от начала до конца: заказ приехал, собрали, отгрузили, статус ушёл, отчёт о реализации загрузился.
• 9. Настроить расписание и мониторинг. Заказы и остатки — каждые несколько минут, отчёты — по мере появления. И обязательно ответственный, который видит ошибки обмена.

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

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

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

Если сформулировать одной фразой: «обмен валится, и никто не понимает почему» на практике означает «никто не открывал протокол обмена». Ошибка там есть, и написана она человеческим языком.

Маркировка: отдельный слой, который нельзя забыть

Если вы торгуете маркированным товаром — одеждой, обувью, парфюмерией и другими товарными группами, — площадка потребует коды маркировки, и они должны сходиться с тем, что у вас в 1С и в системе «Честный знак». Расхождение здесь стоит дорого: за нарушения правил маркировки предусмотрены штрафы до 300 тысяч рублей с конфискацией товара, а по алкоголю и табаку — до 1,5 миллиона. Как это настраивается, разобрано в статье «Маркировка, Честный знак, ЕГАИС и Меркурий в 1С».

Где вы увидите результат

• Заказы с площадок появляются в 1С сами и сразу попадают в сборку.
• Остатки на Wildberries, Ozon и Яндекс Маркете совпадают со складом, отмен из-за отсутствия товара больше нет.
• Отчёты о реализации загружаются документом, а не переносятся в Excel руками.
• Поступление денег на счёт сходится с выручкой и удержаниями в учёте.
• В отчёте по прибыли видна маржа по каждой площадке и каждому товару — с учётом комиссии, логистики и возвратов.
• Решение «что вывести из ассортимента» принимается по цифрам, а не по ощущениям.

Сколько это стоит и кто это делает

Наша модель простая: 8 900 ₽ в месяц с десятью включёнными часами — это 890 ₽ за час — и 2 500 ₽ за каждый следующий час по факту. Для сравнения, рекомендованная фирмой «1С» ставка специалиста — от 3 000 ₽ за час. Настройка типового обмена обычно укладывается в небольшой объём часов, индивидуальная интеграция считается после обследования. Фиксированную смету мы честно не обещаем: вы платите за фактически отработанные часы, а оценку получаете до начала работ — подробнее в ответе «Сколько стоит интеграция 1С».

Работаем удалённо по всей России, в команде 250 специалистов. Это ответ на самую частую жалобу в нашей теме: «предыдущий специалист недоступен, а проблема срочная». Настройки обмена описаны, задачу подхватит другой человек, перед любыми изменениями делается резервная копия базы. Мы подписываем NDA, свои ошибки исправляем за свой счёт. Дальше обмен лучше держать на сопровождении: кто-то должен видеть ошибки раньше вашего менеджера.

Каждый месяц без интеграции — это ручная сверка отчётов, отменённые заказы из-за неверных остатков и ассортимент, который вы ведёте вслепую. Напишите, на каких площадках вы торгуете, по каким схемам и в какой конфигурации ведёте учёт, — посмотрим, что закроет типовой обмен, где нужна доработка, и назовём объём работ в часах. Подробнее об услуге — на странице интеграция 1С; короткий ответ про площадки — в статье «Можно ли интегрировать 1С с Wildberries и Ozon», а общая механика обменов — в статье «Интеграция 1С с другими системами».