- Прикладное решение
- «1С:Управление торговлей»
- Применимость
- Концептуальный материал; состав функций проверяется для используемой версии продукта
- Автор
- BSG-IT
Интеграция 1С:Управление торговлей с маркетплейсами должна поддерживать полный операционный цикл, а не ограничиваться выгрузкой товаров. В рабочем контуре 1С становится центром данных по номенклатуре, ценам, доступным остаткам, заказам, отгрузкам, возвратам и сверке операций по каналам продаж. Если связать только один участок, например загрузку заказов, ручная работа быстро вернется через ошибки в остатках, статусах и ценах.
В реальном проекте важно начинать не с подключения модуля, а с вопроса, кто является владельцем данных. Цена может рождаться в УТ, в модуле маркетплейса или во внешнем сервисе. Остаток может быть физическим, доступным, зарезервированным или ограниченным для конкретного канала. Заказ может прийти из Ozon, Wildberries или Яндекс Маркета, но дальше он должен пройти понятный путь в 1С.
До разработки нужно описать минимум пять потоков: выгрузка номенклатуры, обновление цен, обновление остатков, загрузка заказов и обратная передача статусов. Отдельно фиксируются возвраты, отмены, комиссии, отчеты реализации и сценарии FBS/FBO. Если это не сделать, интеграция формально работает, но менеджеры все равно ведут контроль в таблицах.
Самое опасное место - остатки. На маркетплейс нельзя отправлять просто складской остаток из 1С без бизнес-правил. Нужно учитывать резервы, заказы в обработке, разные склады, товары не для продажи, минимальный страховой запас и задержку обмена. Для части компаний правильно выгружать не фактический остаток, а расчетную доступность по каналу продаж. Это снижает риск отмен и штрафов, но требует прозрачной формулы.
Второй риск - статусы заказов. Заказ с площадки должен попасть в 1С без дублей, получить ответственного, пройти комплектацию, отгрузку, отмену или возврат. При ошибке обмена нужна не фраза 'что-то не загрузилось', а журнал с номером заказа, площадкой, временем, причиной, попытками повтора и ответственным. Иначе поддержка каждый раз начинает расследование с нуля.
Третий риск - цены и акции. Маркетплейсы часто живут в логике акций, скидок, комиссий и разных схем поставки. Если в 1С нет правил, какая цена является базовой, какая выгружается на конкретный канал и кто согласует исключения, интеграция может быстро создать финансовую проблему. Помимо API-методов здесь важен управленческий контроль маржи.
BSG-IT обычно ведет такой проект поэтапно. Сначала аудит текущей УТ, номенклатуры, складов, цен и каналов продаж. Затем схема обмена и матрица владения данными. Потом подключение одного приоритетного маркетплейса, тестовая обработка заказов, журнал ошибок, сверка остатков и только после этого масштабирование на остальные площадки. Такой подход требует подготовки на старте, но быстрее приводит к стабильной эксплуатации.
Результат качественной интеграции - управляемый канал продаж: менеджеры видят заказы и статусы, склад понимает, что отгружать, финансовая служба может разбирать комиссии и возвраты, а руководство видит продажи маркетплейсов в общей аналитике.
Официальные источники
Частые вопросы
Можно ли сразу подключить несколько маркетплейсов к 1С:УТ?
Можно, но безопаснее сначала стабилизировать один канал: товары, цены, остатки, заказы, статусы, ошибки и сверки. После этого модель легче масштабировать на Ozon, Wildberries, Яндекс Маркет и другие площадки.
Что важнее всего проверить до интеграции?
Номенклатуру, правила цен, доступные остатки, склады, резервы, статусы заказов, возвраты, комиссии, права пользователей и журнал ошибок обмена.
Почему остатки на маркетплейсе не должны равняться остатку на складе?
Потому что для продажи важен доступный остаток: нужно учитывать резервы, заказы в обработке, страховой запас, доступность склада для канала и задержку обмена.
Что делает BSG-IT в таком проекте?
Мы описываем потоки данных, настраиваем обмены, добавляем контроль ошибок, тестируем жизненный цикл заказа и готовим интеграцию к регулярной поддержке.