Архитектура интеграций9 минут

Интеграция CRM и 1С: схема, этапы и риски

Основные проблемы интеграции появляются до написания API: CRM и 1С одновременно меняют одну сущность, статусы называются по-разному, а ошибка обмена остаётся только в техническом журнале.

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

Коротко

  • Сначала назначьте владельца каждой сущности, потом проектируйте обмен.
  • Критичные операции проводите через очередь с повтором и журналом ошибок.
  • Запускайте интеграцию по одному бизнес-маршруту, а не по всем справочникам сразу.

Начните с карты владения данными

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

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

  • Сущность и её владелец
  • Уникальный идентификатор
  • Направление и частота обмена
  • Правила конфликта и удаления

Выберите режим обмена для каждого события

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

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

  • Онлайн-запрос для проверки критичного факта
  • События для изменений статуса
  • Пакетный обмен для объёмных справочников
  • Dead-letter очередь для необработанных сообщений

Сделайте ошибки видимыми бизнесу

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

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

Запускайте вертикальный маршрут

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

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

  • Тестовые данные и стенд
  • Параллельный контроль старого и нового процесса
  • План отката
  • Ответственные за бизнес-исключения

Как применить это
в вашей работе?

Обсудить задачу