Убрали ручные выгрузки: остатки в 1С, на сайте и на маркетплейсах сходятся за минуты

О клиенте

Оптовый дистрибьютор электротехники с оборотом около 1.2 млрд ₽ в год. Складская программа — 1С:Управление торговлей 11, развёрнутая on-premise, без внешнего IP. Продажи идут через три канала: сайт на Битрикс, оптовые менеджеры и маркетплейсы (Wildberries, Ozon). Каталог — 8 000 SKU с частым изменением цен и остатков.

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

Проблема

Как выглядел обмен

Связь 1С с каналами держалась на ручных выгрузках:

• Остатки и цены на сайт — выгрузка XLSX раз в сутки, ночью, скриптом, который написал уволившийся подрядчик. Формат прайса иногда «плыл», и сайт молча заливал нули.
• Остатки на маркетплейсы — менеджер вручную выгружал из 1С и загружал в кабинеты WB и Ozon «когда доходили руки», обычно раз в 1–2 дня.
• Заказы с маркетплейсов — оператор вручную переносил в 1С из личных кабинетов площадок, по 60–100 заказов в день.

В деньгах

Суточная задержка означала, что сайт и маркетплейсы торговали остатками, которых уже не было. Каждую неделю набегало несколько десятков овер-селлов — заказов на отсутствующий товар. На Ozon и WB это штрафы за отмену и просадка рейтинга продавца. По оценке коммерческого директора — до 400 тыс. ₽/мес прямых потерь на штрафах и отменах, плюс полторы ставки операторов, занятых только переносом данных.

Почему не взяли коробочный коннектор

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

Подход

Discovery: где на самом деле правда

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

Второе открытие: 1С задним числом корректирует документы поступления, поэтому «снимок остатков» на момент выгрузки быстро устаревал. Нужен был обмен, который переживает пересчёт истории.

Ключевые архитектурные решения

HTTP-сервисы на стороне 1С, а не файлы. Разработали на стороне 1С:УТ набор HTTP-сервисов для чтения остатков и цен и для приёма заказов. OData использовали для первичной выгрузки справочников, но всю бизнес-логику (расчёт оптовых цен, резервы) вынесли в HTTP-сервисы.

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

Справочник соответствия SKU как отдельная сущность. Собрали единую таблицу маппинга «1С ↔ сайт ↔ WB ↔ Ozon» с админкой, где менеджер сопоставляет новые позиции. Это стало ядром всей синхронизации.

Staging сырых данных. Все ответы 1С и площадок сохраняются как есть, витрины пересчитываются. Когда 1С корректирует документ задним числом, обмен переживает это без ручного разбора.

Решение в деталях

Синхронизация остатков и цен

Интеграционный слой на Python слушает очередь изменений из 1С. При изменении остатка или цены по позиции:

1. Находит соответствия по таблице маппинга (сайт, WB, Ozon).
2. Пересчитывает оптовую цену по уровням и вычитает резервы.
3. Отдаёт остаток на сайт (через REST Битрикс) и в кабинеты маркетплейсов (WB API, Ozon Seller API).

Средняя задержка от изменения в 1С до обновления на витрине — около 4 минут вместо суток. На маркетплейсах остаток обновляется с учётом их лимитов на частоту запросов — сложили изменения в пакеты, чтобы не упираться в throttling.

Приём заказов с маркетплейсов

Заказы с WB и Ozon забираются по API, маппятся на номенклатуру 1С и создаются документами реализации через HTTP-сервис. Оператор больше не переносит заказы руками — он только разбирает исключения (позиция без соответствия в маппинге), которых после первого месяца осталось единицы в неделю.

Наблюдаемость

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

Самое сложное

Лимиты частоты у маркетплейсов

Проблема. При массовом изменении цен (например, смена прайса на 2 000 позиций) прямая отправка каждого изменения упиралась в лимиты WB и Ozon — часть запросов отклонялась, остатки расходились.

Что сделали. Ввели буфер: изменения копятся несколько минут и уходят пакетами в пределах лимитов площадки. Критичные события (позиция ушла в ноль) отправляются вне очереди — чтобы не продать то, чего нет.

Расхождение из-за корректировок задним числом

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

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

Результаты

Через 60 дней после запуска

• Задержка актуализации остатков — с суток до ~4 минут. Сайт и маркетплейсы показывают то, что реально есть на складе.
• Овер-селлы и штрафы за отмены — −94%. Оставшиеся единичные случаи — из-за одновременных заказов в разных каналах, их закрывает суточная сверка.
• Ручные выгрузки — убраны полностью. Полторы ставки операторов переведены с переноса данных на работу с клиентами.
• Заказы с маркетплейсов попадают в 1С автоматически — оператор разбирает только исключения.

Клиент получил документацию обмена и обучение внутренней 1С-команды — поддержку они ведут сами, мы остались на связи для развития.

Что меняется для каждой роли

Интеграция — самый «невидимый» тип проекта: пока она работает, её не замечают. Вот что меняется у тех, кто с ней живёт.

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

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

IT-директор. Ключевое требование обычно звучит как «не открывать 1С в интернет», и оно выполнимо: 1С сама публикует изменения изнутри периметра через RabbitMQ. Безопасность on-premise сохраняется, входящих подключений извне нет.

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

Финансовый директор. Считать эффект стоит по прямым потерям: штрафы за отмены и овер-сейлы на площадках. Это единственная статья, где результат виден в первый же месяц и не требует сложной атрибуции.

Стек

• Backend / интеграция: Python 3.12, FastAPI, RabbitMQ, PostgreSQL, structlog
• 1С: 1С:УТ 11, HTTP-сервисы, OData, регламентные задания
• Каналы: Битрикс REST, Wildberries API, Ozon Seller API
• Инфра: on-premise 1С + VPN, Docker Compose, Grafana + алерты в Telegram

Когда такой подход подходит вашей компании

Подойдёт, если:

• 1С — основная учётная система, а связь с сайтом/CRM/маркетплейсами держится на ручных выгрузках.
• Есть овер-селлы и штрафы из-за неактуальных остатков на площадках.
• 1С стоит on-premise без внешнего IP, и открывать её наружу нельзя.
• Артикулы в 1С и на площадках не совпадают, а сопоставление живёт «в голове».

Не подойдёт, если:

• Хватает стандартного коробочного коннектора «Битрикс — 1С» без доработок.
• Каталог маленький и меняется редко — тогда достаточно регламентной выгрузки.