1С, CRM И САЙТ: как системы обмениваются данными

На схеме интеграция 1С, CRM и сайта часто выглядит элементарно:

На практике такая схема почти ничего не говорит о том, что именно происходит с данными.

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

Потому что задача заключается не в том, чтобы «соединить 1С с сайтом».

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

Зачем вообще нужны три системы

У каждой системы обычно своя зона ответственности.

1С может отвечать за:

Сайт отвечает за взаимодействие с покупателем:

CRM работает с клиентской и коммерческой частью:

Получается, что один и тот же бизнес-процесс проходит через несколько систем.

Например:

И здесь уже недостаточно знать адрес API каждой системы.

Нужно понимать жизненный цикл данных.

Главное правило: у каждого типа данных должен быть источник истины

Одна из самых частых ошибок — хранить одни и те же данные как независимые значения сразу в нескольких системах.

Например:

Пока значения одинаковые, кажется, что всё работает.

Но затем кто-то изменил цену в 1С.

Через час сайт всё ещё показывает старую.

CRM содержит третье значение.

И уже непонятно, какая цифра правильная.

Поэтому ещё до разработки интеграции нужно определить:

Какая система является владельцем конкретного типа данных?

Например:

Последняя строка особенно важна.

Заказ может появиться на сайте, но после оформления стать объектом CRM и затем документом в 1С.

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

Они должны хранить свои представления одного бизнес-объекта, связанные общими идентификаторами.

Не нужно синхронизировать всё со всем

На первый взгляд хочется построить такую архитектуру:

Каждая система напрямую общается с каждой.

Сначала это кажется удобным.

Потом появляется новая система.

Например, интернет-магазин, mobile приложение, сервис доставки и аналитическая платформа.

Связей становится всё больше:

Каждая новая интеграция добавляет новые зависимости.

Поэтому в крупных проектах часто появляется отдельный интеграционный слой:

Он может отвечать за преобразование данных, очереди, маршрутизацию, журналирование и повторную обработку.

Один товар в разных системах — это не три разных товара

Предположим, в 1С товар имеет идентификатор:

На сайте он может иметь:

В CRM:

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

Поэтому нужен устойчивый внешний идентификатор.

Например:

Система должна понимать:

10482, 7815 и 322 — это разные технические идентификаторы одного товара.

Такое сопоставление часто называют mapping.

И чем больше интеграций, тем важнее держать его под контролем.

Как передаются товары

Типичный сценарий может выглядеть так:

Например, в 1С хранится:

А сайту нужен другой формат:

Поэтому интеграция не просто «пересылает JSON».

Она выполняет преобразование:

Именно этот слой позволяет системам не зависеть напрямую от внутренней структуры друг друга.

Цена — не просто число

В реальном бизнесе цена редко является одним простым полем.

Могут существовать:

Например:

Если просто передать в CRM поле price, непонятно, какую именно цену мы передали.

Поэтому ещё на этапе проектирования нужно определить семантику каждого поля.

Интеграция должна передавать не просто значения.

Она должна передавать значения в понятном контексте.

Остатки — ещё сложнее

С остатками ситуация похожая.

В 1С может быть:

А сайту нужно показать:

Значит, сайт не обязательно должен получать все внутренние складские данные.

Для него может рассчитываться отдельный показатель:

Правила зависят от бизнеса.

И это хороший пример того, почему интеграция — не механическая пересылка полей.

Между системами существует бизнес-логика.

Заказ проходит обратный путь

С товарами поток часто идёт из 1С на сайт.

С заказом всё наоборот.

Покупатель оформляет его на сайте:

После этого информация должна попасть дальше.

Например:

Но в каждой системе заказ может получить собственный идентификатор:

И снова нужен mapping.

В системе важно хранить связь:

Тогда любой участник цепочки может однозначно понять, о каком заказе идёт речь.

Почему нельзя просто отправить заказ два раза

Представим:

Если нет защиты, в 1С появятся два заказа.

Поэтому интеграции должны учитывать идемпотентность.

Перед созданием документа можно проверить:

Если такой заказ уже существует:

а вернуть существующий объект.

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

Статус заказа тоже является данными

Заказ может пройти длинную цепочку:

Но разные системы могут использовать разные статусы.

Например:

Поэтому между системами нужен словарь соответствий:

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

Двусторонний обмен требует особенно аккуратной логики

Представим:

Цена изменилась в 1С, сайт получил новую цену.

Всё просто.

Но если сайт тоже может изменять цену:

возникает вопрос:

кто теперь главный?

Если оба источника могут менять одно поле, появляется конфликт.

Например:

Можно получить бесконечную борьбу изменений.

Поэтому для каждого поля необходимо определить:

Чем больше двусторонних связей, тем важнее эти правила.

Синхронизация бывает разной

Не все данные нужно передавать одинаково.

Периодический обмен

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

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

Событийный обмен

Если данные должны передаваться практически сразу:

Например, изменение остатка может практически сразу отразиться на сайте.

Комбинированный вариант

На практике часто используется оба подхода.

События обеспечивают оперативность, а периодическая сверка обнаруживает то, что по какой-либо причине не дошло.

Это гораздо надёжнее, чем рассчитывать только на один механизм.

А что если данные не дошли?

Ошибки обмена — нормальная часть любой интеграции.

Проблема не в том, что ошибка произошла.

Проблема — если система не умеет её обнаружить и обработать.

Например:

Сайт вернул:

Интеграция должна понимать:

Повторять нужно не все ошибки

Например:

могут быть временными ошибками.

Повторная попытка имеет смысл.

Но:

обычно требуют исправления данных.

Если автоматически повторять такой запрос сто раз, ничего не изменится.

Поэтому ошибки стоит классифицировать.

Для временных ошибок можно использовать увеличивающийся интервал между попытками.

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

Очередь позволяет не терять изменения

Для важных операций полезно использовать очередь сообщений или заданий.

Например:

Если сайт недоступна:

При этом основной процесс в 1С не обязательно должен ждать ответа сайта.

Это особенно важно для больших объёмов данных.

Полная синхронизация и обмен изменениями

Есть два принципиально разных подхода.

Первый:

Второй:

Для больших каталогов второй вариант значительно эффективнее.

Но тогда системе необходимо отслеживать изменения:

Например:

А если возникла ошибка:

Такой журнал позволяет контролировать не просто факт запуска обмена, а результат обработки каждого объекта.

Начальная загрузка и последующая синхронизация — разные задачи

Это часто упускают из виду.

Когда интеграцию запускают впервые, нужно передать большой объём данных:

Это начальная загрузка.

После запуска ежедневный процесс выглядит совершенно иначе:

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

Поэтому обычно существуют два режима:

У них разные требования к производительности, контролю и обработке ошибок.

Что делать при расхождении данных

Предположим:

Как определить, что правильно?

Если 1С является источником истины — ответ очевиден.

Но система должна не просто исправить значение.

Она должна уметь обнаружить расхождение.

Например:

А если расхождение не исчезло — отправить уведомление.

Такие сверки особенно полезны для критичных данных.

Логи нужны не только разработчику

Хорошая интеграция должна отвечать на вопрос:

Не через поиск по серверам и догадки.

А через историю:

Теперь причина понятна.

Можно исправить данные и повторить операцию.

Мониторинг должен смотреть на бизнес, а не только на сервер

Сервер может быть полностью «зелёным», а заказы при этом не передаваться.

Поэтому недостаточно контролировать:

Нужно видеть бизнес-показатели:

Это позволяет увидеть проблему до того, как её заметит клиент или менеджер.

Интеграция должна переживать изменения систем

1С, CRM и сайт не стоят на месте.

Меняются:

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

Именно здесь особенно полезен отдельный слой преобразования.

Если API CRM изменился, корректируется её адаптер.

Внутренняя модель и логика остальных систем при этом могут остаться прежними.

Что происходит, если сайт временно недоступен

Допустим, на сайте идут технические работы.

В 1С продолжают меняться:

После восстановления сайта нельзя просто сказать:

Нужно понять, какие изменения произошли за время простоя.

Поэтому полезно хранить состояние обмена:

После восстановления:

Так короткий простой одной системы не приводит к потере изменений.

Где заканчивается интеграция и начинается архитектура

Если бизнес говорит:

это ещё не техническое задание.

Нужно выяснить:

Только после этого можно выбирать конкретный механизм обмена.

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

Как выглядит нормальная архитектура

Для типового проекта это может выглядеть так:

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

Например:

Конкретная схема всегда зависит от бизнес-процесса.

Главное — не сделать три системы одним большим справочником

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

Наоборот.

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

Задача интеграции — обеспечить согласованность необходимых данных, а не создать три одинаковые базы.

Итог

Связать 1С, CRM и сайт технически можно довольно быстро.

Но построить между ними надёжный обмен данными — совсем другая задача.

Нужно заранее определить:

Тогда схема перестаёт выглядеть как набор соединённых API:

И превращается в управляемый процесс:

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

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

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).