Интеграция 1С с сайтом и маркетплейсами: как устроена

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

Какие данные обычно синхронизируют

Набор зависит от бизнеса, но типовой состав такой:

Товары и каталог — наименования, артикулы, характеристики, группы, изображения.
Цены — розничные, оптовые, акционные; если видов цен несколько, нужно заранее решить, какой показывать на сайте и каким покупателям.
Остатки — по складам или суммарно.
Заказы — с сайта в 1С, с составом, суммой, способом оплаты и доставки.
Контрагенты — покупатели, особенно для B2B, где у клиента договор и свои условия.
Статусы — изменения заказа в 1С (собран, отгружен, отменён) обратно на сайт и в личный кабинет.

Главное правило: у каждого вида данных должна быть одна «главная» система. Обычно каталог, цены и остатки ведутся в 1С, а сайт их только показывает. Если одни и те же поля правят и в 1С, и в админке сайта, расхождения неизбежны.

Способы обмена

Стандартный обмен через CommerceML. Для типовых торговых конфигураций 1С есть штатный механизм обмена с сайтами в формате CommerceML — XML-выгрузки каталога и предложений и загрузка заказов. Многие готовые платформы интернет-магазинов умеют его принимать. Это самый быстрый путь, если конфигурация типовая, а структура каталога укладывается в стандарт.

HTTP-сервисы и OData. В 1С можно опубликовать собственные HTTP-сервисы или использовать стандартный REST-интерфейс OData. Сайт или промежуточный сервис обращается к ним по API и получает только нужные данные. Этот вариант гибче, но требует доработки на стороне 1С и публикации базы через веб-сервер.

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

Выгрузка файлами. 1С по расписанию выгружает файлы (XML, CSV, Excel), сайт их забирает. Просто и надёжно для каталога и цен, но плохо подходит для остатков, которые должны обновляться часто.

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

Частота обновления и конфликты данных

Не все данные нужно синхронизировать одинаково часто:

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

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

Типичные проблемы

Дубли товаров и контрагентов. Возникают, когда у товара нет стабильного идентификатора: сопоставление по наименованию ломается при любом переименовании. Решение — связывать записи по уникальному коду из 1С.

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

Остатки «не в реальном времени». Если остатки обновляются раз в несколько часов, покупатель может оплатить товар, которого уже нет. Помогает более частый обмен изменений и резерв на время оплаты.

Нагрузка на базу. Полная выгрузка большого каталога каждые несколько минут может тормозить работу пользователей 1С. Выгружать нужно только изменения и в согласованное время.

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

Интеграция с маркетплейсами

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

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

Как оценивается проект интеграции

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

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

После первых двух шагов обычно понятно, хватит ли стандартного обмена или нужна своя логика.

Чек-лист перед интеграцией

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

Когда нужна помощь разработчиков

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

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