Заказ из CRM
После согласованного события передаём контрагента, позиции, количества, цены и другие обязательные данные.
CRM + учётная система: продажи и исполнение работают с одними данными
Связываем CRM с 1С, складской или бухгалтерской системой так, чтобы менеджер не переносил заказ вручную, учётный контур получал согласованный набор данных, а оплаты, документы и важные статусы возвращались в правильную сделку.
Продажи ↔ учёт
CRMсделка, клиент, заказ
→ОбменID и согласованные данные
→Учётная систематовары, документы, оплаты
→Статус обратнорезультат у менеджера
→Граница систем
CRM отвечает за работу с клиентом, учётная система — за свои операционные данные
Не пытаемся сделать обе системы одинаковыми. Для каждого объекта и поля определяем, где он создаётся, где редактируется и куда только передаётся для использования.
Учёт и исполнение
Товары, остатки, документы, платежи и хозяйственные операции остаются в системе, где их ведёт соответствующий отдел.
Документы и оплаты
Нужный факт проведения, подписания или оплаты возвращается менеджеру без ручной проверки второго интерфейса.
Статусы для процесса
В CRM возвращаем только те операционные состояния, которые влияют на следующий шаг продажи или обслуживания клиента.
Один заказ
Связь строится по идентификатору заказа, а не по похожему названию клиента
После первого обмена сохраняем соответствие объектов между системами и используем его во всех последующих событиях.
Сделка готова→Проверка данных→Заказ в учёте→Внешний ID→Оплата / документ / отгрузка→Статус в CRM
Данные
Не синхронизируем весь справочник и все поля автоматически
Состав обмена определяется реальным процессом. Чем меньше неоднозначных владельцев данных, тем устойчивее интеграция.
Контрагент
Определяем правила создания и сопоставления компании, реквизитов и контактных данных.
Товары и позиции
Фиксируем ключи номенклатуры, модификации, единицы измерения, количества и правила цены.
Заказ
Передаём номер, состав и необходимые дополнительные признаки только после проверки обязательных полей.
Оплата и реализация
Возвращаем подтверждённый факт и сумму по связанному заказу, а не по первому совпадению номера в тексте.
Документы
Статусы формирования, проведения или подписания отражаем в CRM только в объёме, который нужен следующему участнику процесса.
Конфликты
Одно значение не должно одновременно редактироваться независимо в двух системах
Для цены, реквизитов, статуса и других важных данных заранее выбираем владельца и направление передачи.
Источник истины
Для каждого поля определяем систему, в которой изменение считается основным.
Связь объектов
Храним идентификаторы CRM и учётной системы в интеграционном слое или согласованном поле.
Повтор события
Повторная передача не создаёт второй заказ и не дублирует оплату.
Проверка суммы
Когда бизнес-правило зависит от суммы, сравниваем нормализованные числовые значения по связанным объектам.
Способ обмена
API, webhooks, база или файлы — выбираем по возможностям конкретного контура
Не навязываем один транспорт. Для 1С и других систем способ обмена зависит от версии, инфраструктуры, доступных интерфейсов и требований к скорости.
Описываем объекты
Что именно передаётся между системами.
Выбираем владельца
Где создаётся и изменяется каждое значение.
Фиксируем события
Что запускает передачу и возврат статуса.
Защищаем повтор
ID, журнал обмена и правила обновления.
Проверяем на реальном заказе
Включая исправления, повторные события и ошибки.
Дальнейший процесс
Учётный контур часто находится в середине цепочки, а не в её конце
После заказа могут подключаться ЭДО, производство, закупки и логистика; нужные результаты этих этапов также можно вернуть менеджеру.
Сквозной процесс
CRM остаётся окном менеджера, даже если исполнение идёт в других системах
Это не означает перенос всего учёта в CRM — только возврат фактов, которые нужны для работы с клиентом.
Вопросы
Частые вопросы
Интеграция обязательно двусторонняя?
Нет. Направление определяем отдельно для каждого объекта и поля. Например, заказ может идти из CRM в учёт, а оплата и реализация — возвращаться обратно.
Можно связать уже существующие заказы?
Да, если есть надёжный способ сопоставления. Для исторических данных сначала определяем ключи и проверяем неоднозначные совпадения.
Что делать, если один и тот же заказ изменили в обеих системах?
Для важных данных заранее выбираем систему-владельца и правило конфликта. Автоматическое «последнее изменение побеждает» используем только когда это действительно безопасно.
Можно передавать товары и остатки?
Да, если они нужны процессу и доступны через выбранный интерфейс учётной системы. Состав и направление обмена определяем отдельно.
Как не создавать дубли заказов?
После первого создания сохраняем внешний идентификатор и при повторном событии обновляем связанный объект либо ничего не делаем — в зависимости от бизнес-правила.
Можно подключить ЭДО и логистику после учётной системы?
Да. Эти этапы можно связать в один процесс, при этом каждый внешний сервис остаётся отдельным адаптером с собственными идентификаторами и статусами.
Где сейчас данные заказа переносятся между CRM и учётом вручную?
Покажите один заказ от сделки до оплаты или реализации. Зафиксируем владельцев данных, события обмена и статусы, которые действительно нужны менеджеру.