Интеграция сайта и CRM с 1С: как обмен данными работает на практике

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

Какие данные обычно передают

Начните с инвентаризации: какие сущности есть в каждой системе и кто для них главный. Типичный набор для интернет-магазина или сервисной компании выглядит так.

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

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

Стандартный обмен CommerceML

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

HTTP-сервисы и REST API на стороне 1С

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

OData

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

Промежуточная база или очередь

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

Почему интеграции ломаются

Интеграция, которая отлично работала при запуске, через полгода часто начинает сбоить. Причины повторяются от проекта к проекту.

• Обновление конфигурации 1С. Изменилась структура справочника, и выгрузка начала падать или отдавать пустые поля.
• Ручные правки на сайте. Менеджер поменял название товара в админке, а следующая выгрузка затёрла правку или создала дубль.
• Отсутствие идентификаторов. Товары сопоставляются по названию или артикулу, а не по уникальному коду. Достаточно одного переименования, чтобы связь потерялась.
• Нет обработки ошибок. Заказ не загрузился в 1С, но никто об этом не узнал — менеджер увидел его только после звонка клиента.
• Рост объёма. Полная выгрузка каталога раз в 10 минут работала на 500 товарах и перестала успевать на 20 000.

Что описать в задании

Хорошее задание на интеграцию отвечает на конкретные вопросы, а не просто говорит «синхронизировать с 1С».

1. Какие сущности передаются, в каком направлении и кто источник истины.
2. Как сопоставляются записи: по какому идентификатору.
3. Как часто идёт обмен и что должно происходить в реальном времени.
4. Что происходит при ошибке: повтор, уведомление, журнал.
5. Как обрабатываются удаления: товар снят с продажи, клиент удалён.
6. Какая конфигурация 1С и её версия, кто её дорабатывает.
7. Кто отвечает за интеграцию после запуска: программист 1С, разработчик сайта или оба.

Последний пункт часто забывают, а он самый важный. Интеграция находится на стыке двух команд, и при сбое каждая уверена, что проблема на другой стороне. Нужен один ответственный, который видит обе части и журнал обмена.

Пример: заказ с сайта в 1С по шагам

Чтобы было понятно, где обычно возникают проблемы, разберём путь одного заказа в типовой схеме интернет-магазина.

1. Покупатель оформляет заказ на сайте. Сайт сохраняет его со статусом «новый» и присваивает собственный номер.
2. Модуль обмена раз в несколько минут собирает новые заказы и передаёт их в 1С. В каждой строке заказа — не название товара, а его код из 1С, полученный при выгрузке каталога.
3. 1С создаёт документ «Заказ клиента», находит или создаёт контрагента и возвращает сайту свой номер документа.
4. Сайт сохраняет номер 1С в заказе. С этого момента заказ считается загруженным, и повторная выгрузка его не дублирует.
5. Менеджер в 1С подтверждает заказ, резервирует товар, выставляет счёт. Статус меняется.
6. При следующем обмене сайт получает новый статус и показывает его покупателю в личном кабинете.

Типичные сбои на этом пути: на шаге 2 товар без кода 1С (его добавили на сайте вручную) — заказ не загружается; на шаге 3 контрагент дублируется, потому что покупатель указал телефон в другом формате; на шаге 4 номер не вернулся из-за таймаута, и при следующем обмене заказ загружается второй раз. Каждый из этих сбоев решается заранее: запретом ручного создания товаров, нормализацией телефонов и проверкой на повторную загрузку по номеру заказа сайта.

Безопасность обмена

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

• доступ к сервисам обмена только с IP-адреса сервера сайта или через защищённый туннель;
• отдельная учётная запись для обмена с правами только на нужные объекты, а не администратор базы;
• шифрование соединения;
• журнал обращений и уведомление о всплеске ошибок авторизации.

Эти пункты стоит записать в задание так же явно, как список передаваемых полей.

Журнал обмена — обязательная часть

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

С чего начать

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

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