Сайт, который живёт отдельно от учёта, рано или поздно начинает врать. Цена на сайте одна, в 1С другая. Товар заказали, а на складе его уже нет. Менеджер переносит заказы из почты в CRM руками и ошибается в телефоне. Интеграция сайта с 1С, CRM и складом нужна, чтобы данные вводились один раз и дальше расходились по системам сами.
Разберём, какие данные обычно передают между системами, какие есть способы обмена и чем они отличаются, как часто синхронизировать остатки, что ломается чаще всего и как подготовиться к проекту, чтобы он не растянулся на полгода.
Какие данные гоняют между сайтом, 1С и CRM
Набор зависит от бизнеса, но у интернет-магазинов и B2B-сайтов он почти всегда похож. Важно сразу зафиксировать не только что передаётся, но и в какую сторону.
- Каталог товаров. Наименования, артикулы, группы, свойства, характеристики (размер, цвет, объём), единицы измерения. Обычно идёт из 1С на сайт.
- Цены. Розничные, оптовые, по типам цен и группам клиентов, акционные. Тоже из 1С на сайт.
- Остатки. Общие или по складам и магазинам, иногда с учётом резервов. Направление то же.
- Заказы. Состав, сумма, доставка, оплата, комментарий. Идут с сайта в 1С и в CRM.
- Клиенты. Контакты, реквизиты юрлиц, персональные условия. Могут создаваться на сайте, в CRM и в 1С одновременно — отсюда главный источник дублей.
- Статусы. Оплачен, собран, отгружен, доставлен. Возвращаются из 1С или CRM на сайт и в личный кабинет покупателя.
Для B2B к этому добавляются документы: счета, акты, договоры, взаиморасчёты. Их часто показывают в личном кабинете клиента, и это отдельный поток данных со своими правилами доступа.
Способы обмена данными сайта и 1С
Технически связать системы можно несколькими способами. Выбор зависит от объёма каталога, того, насколько типовая у вас 1С, и сколько систем участвует в обмене.
Стандартный обмен по CommerceML
CommerceML — открытый XML-формат для обмена коммерческими данными, который поддерживают типовые конфигурации 1С, Битрикс и многие другие CMS и платформы. 1С выгружает каталог, цены и остатки в файлы и забирает с сайта заказы. Для типового магазина на типовой конфигурации это самый быстрый путь: обмен настраивается, а не программируется.
Ограничения проявляются, когда логика выходит за стандарт: нестандартные цены, сложные характеристики, несколько юрлиц, своя доработанная 1С. Тогда обмен начинают дописывать с обеих сторон, и он становится хрупким.
HTTP-сервисы и REST API 1С
В современной платформе 1С можно опубликовать собственные HTTP-сервисы, а также стандартный REST-интерфейс OData. Сайт или промежуточный сервис обращается к ним напрямую и получает только нужные данные: остаток конкретного товара, статус заказа, персональную цену. Это гибче CommerceML, но требует программиста 1С и опубликованной в интернете базы с продуманной защитой.
Промежуточный сервис (шина)
Между системами ставят отдельный сервис, который принимает данные, приводит их к общему виду, раскладывает по адресатам и хранит журнал обмена. Такой подход оправдан, когда систем больше двух: сайт, 1С, CRM, складская система, маркетплейсы. Каждая система интегрируется с шиной один раз, а не со всеми остальными попарно.
Файлы по расписанию
Самый простой вариант: 1С по расписанию выкладывает файл (XML, CSV, Excel) на сервер, сайт его забирает. Подходит для небольших каталогов и данных, которые меняются редко. Для заказов и остатков в реальном времени не годится.
| CommerceML | HTTP-сервисы / API | Промежуточный сервис | |
|---|---|---|---|
| Скорость запуска | Быстро для типовой 1С | Средне | Дольше всего |
| Гибкость | Низкая | Высокая | Высокая |
| Частота обмена | По расписанию, пакетами | По запросу, почти мгновенно | Как настроить |
| Когда подходит | Типовой магазин, сайт + 1С | Нестандартная логика, B2B | Три системы и больше |
На практике способы комбинируют: каталог раз в сутки идёт через CommerceML, а остаток в корзине проверяется запросом к API в момент оформления заказа.
Интеграция сайта с CRM: amoCRM и Битрикс24
CRM обычно отвечает за продажи: лиды, сделки, коммуникацию с клиентом. У amoCRM и Битрикс24 есть открытые REST API и вебхуки, поэтому заявки и заказы с сайта передаются в них без ручного переноса. С сайта уходят контакт, состав заказа, источник и UTM-метки, из CRM на сайт могут возвращаться статусы.
Сложность начинается, когда в схеме есть и CRM, и 1С. Заказ должен оказаться в обеих системах, а клиент — не задублироваться. Нужно заранее решить, кто создаёт заказ в 1С: сайт напрямую или CRM после того, как менеджер подтвердил сделку. Для CRM на заказ этот вопрос решается при проектировании, в готовых системах — настройкой и доработками коннектора.
Синхронизация остатков и цен: как часто и что будет, если отстают
Частота синхронизации — компромисс между нагрузкой на 1С и точностью данных. Полная выгрузка каталога может занимать заметное время и нагружать базу, поэтому её не запускают каждые пять минут. Остатки и цены обычно передают отдельно и чаще, чем описания и картинки.
Ориентиры такие:
- Описания, свойства, фото — раз в сутки или по изменению.
- Цены — несколько раз в день или по изменению; при акциях — сразу.
- Остатки — чем чаще, тем лучше; для ходовых товаров с малым запасом — с проверкой в момент заказа.
- Заказы и статусы — сразу или с минимальной задержкой.
Если остатки отстают, магазин продаёт то, чего нет. Дальше звонок с извинениями, отмена, возврат предоплаты и испорченное впечатление о компании. Ошибка в остатках стоит дороже, чем лишняя нагрузка на обмен. Если товар уходит быстро, а склад маленький, без проверки остатка при оформлении заказа не обойтись.
Что ломается чаще всего
Сам транспорт данных ломается редко. Проблемы обычно в данных и в договорённостях между людьми.
- Нет ответа, кто «мастер» данных. Если цену можно поменять и в 1С, и в админке сайта, через неделю никто не знает, какая правильная. Для каждого типа данных должна быть одна главная система, остальные только читают.
- Ручные правки с двух сторон. Контент-менеджер поправил название на сайте, следующий обмен его перезаписал. Нужно заранее решить, какие поля обмен обновляет, а какие сайт ведёт сам: SEO-тексты, фото, описания.
- Дубли. Товары без стабильного идентификатора, клиенты, которые сравниваются по имени, а не по телефону или ИНН. Каждый обмен создаёт новые записи вместо обновления старых.
- Разъехавшиеся справочники. Единицы измерения, склады, способы доставки и оплаты, статусы заказов называются по-разному в разных системах. Без таблицы соответствий заказ приходит в 1С с пустыми полями.
- Характеристики товаров. Размер и цвет в 1С заведены как характеристики номенклатуры, а сайт ждёт отдельные товары или наоборот. Это нужно разобрать до разработки, а не после первой выгрузки.
- Тихие ошибки. Обмен упал ночью, а заметили через три дня по жалобам клиентов. Нужен журнал обмена и уведомления о сбоях.
Для каждого типа данных должна быть одна главная система, остальные только читают.
Порядок работ
Интеграция с 1С — это прежде всего аналитика данных и договорённости, а уже потом код. Так выглядит последовательность, которой мы придерживаемся в проектах с интеграциями.
- Аудит систем. Какая конфигурация 1С и насколько она доработана, какая CRM, какая платформа у сайта, есть ли уже обмен и почему он не устраивает.
- Карта данных. Какие сущности передаются, в какую сторону, как часто, какая система главная для каждой. Таблица соответствий справочников и полей.
- Выбор способа обмена. CommerceML, API, шина или их сочетание — исходя из карты данных, а не из привычки подрядчика.
- Подготовка данных. Чистка дублей, проставление идентификаторов, приведение справочников к общему виду. Эту работу на стороне 1С ведут наши программисты 1С; если у вас есть свой программист, согласуем изменения с ним.
- Разработка и тестовый обмен. Сначала на копии базы 1С и тестовом сайте. Проверяем пограничные случаи: товар удалили, цену обнулили, заказ отменили после оплаты.
- Запуск и мониторинг. Первый боевой обмен под присмотром, журнал, уведомления об ошибках, инструкция для сотрудников, кто и где теперь правит данные.
Что подготовить заказчику
Чем больше из этого списка готово до старта, тем быстрее и точнее будет оценка.
- Название и версия конфигурации 1С, информация о доработках.
- Контакт программиста 1С или компании, которая обслуживает базу, если они есть, — чтобы согласовать с ними доработки.
- Доступ к копии базы 1С для тестирования.
- Доступы к CRM и админке сайта, описание текущего обмена, если он есть.
- Список данных, которые нужно передавать, и желаемая частота.
- Решение, какая система главная для товаров, цен, клиентов и заказов.
- Ответственный со стороны бизнеса, который принимает решения по спорным полям и статусам.
Из чего складываются сроки и цена
Назвать стоимость интеграции сайта с 1С без аудита нельзя: одинаково звучащие задачи отличаются по объёму в разы. На оценку влияют:
- Число систем и потоков. Сайт и 1С — одна история, сайт, 1С, CRM, склад и маркетплейсы — совсем другая.
- Типовая или доработанная 1С. Для типовой конфигурации многое настраивается штатно, для доработанной обмен часто пишут заново.
- Объём каталога и частота изменений. От этого зависит, хватит ли пакетной выгрузки или нужна работа с изменениями и API.
- Состояние данных. Чистка справочников может занять больше времени, чем программирование.
- Сложность ценообразования. Персональные цены, скидки по объёму, несколько складов и юрлиц.
- Требования к надёжности. Журнал обмена, повторная отправка при сбоях, уведомления, мониторинг.
Если интеграция — часть разработки нового сайта, её лучше закладывать с самого начала: структура каталога и карточки товара проектируются сразу под данные из 1С. Наши проекты интернет-магазинов и сервисов можно посмотреть на странице работ.
Частые вопросы
Что такое CommerceML?
Это открытый XML-формат для обмена коммерческими данными между учётными системами и сайтами. Его поддерживают типовые конфигурации 1С и многие CMS, поэтому для типового интернет-магазина обмен каталогом, ценами, остатками и заказами можно настроить без программирования с нуля.
Можно ли интегрировать с 1С сайт не на Битриксе?
Да. CommerceML поддерживают многие платформы, а для сайтов на собственном коде или фреймворках обмен делают через HTTP-сервисы 1С, REST-интерфейс OData или промежуточный сервис. Выбор зависит от задач, а не от CMS.
Как часто нужно синхронизировать остатки?
Зависит от скорости продаж и размера склада. Для редко меняющихся товаров достаточно нескольких обменов в день. Для ходовых позиций с малым запасом лучше проверять остаток в 1С в момент оформления заказа.
Нужен ли программист 1С, если сайт делает агентство?
Работа на стороне 1С нужна почти всегда: даже при стандартном обмене настраивают узел обмена, справочники и права, а при нестандартной логике пишут HTTP-сервисы или дорабатывают обработки обмена. В Sphere это делают наши программисты 1С, искать отдельного подрядчика не нужно. Если у вас есть свой программист 1С, согласуем изменения с ним.
Что делать, если заказы задваиваются в 1С или CRM?
Проверить, по какому идентификатору система определяет, что заказ или клиент уже существует. Дубли почти всегда возникают из-за отсутствия стабильного ID или сопоставления по имени. Решается правилами сопоставления и разовой чисткой базы.
