Маркетплейсы в одном контуре с сайтом, 1С и складом

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

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

Отдельный блок работ — штрихкоды и маркировка. На FBS и realFBS этикетку нужно печатать под конкретный заказ, а для маркированных групп товаров — передавать коды в ГИС МТ. Без этого отгрузка тормозит, а расхождения по кодам приходится закрывать вручную уже после отгрузки.

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

Мы собираем отчёты всех площадок в один реестр и считаем маржу по каждому SKU: закупочная цена, комиссия категории, стоимость логистики, удержания за акции и возвраты. Видно, где цена ниже точки безубыточности, а где можно участвовать в промо без потери маржи. Отдельно считаем стоимость хранения на складе площадки, потому что медленная оборачиваемость съедает прибыль незаметнее всего. Расчёт обновляется по мере загрузки отчётов площадок.

• сверка отчётов о реализации и комиссий по площадкам;
• учёт логистики, хранения и удержаний за акции;
• юнит-экономика по товару, бренду и категории;
• план участия в акциях с расчётом размера скидки.

Эти же данные полезны закупке: по ним видно, какие позиции оборачиваются быстро, какие зависают на складе площадки и сколько стоит хранение неликвида. Планировать поставки FBO становится возможным по расчёту, а не по интуиции: сначала объём продаж по каждой позиции, затем лимиты склада и сроки поставки.

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

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

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