Интеграция CRM и 1С начинается с ответа на вопрос, какие сведения и зачем должны передаваться. Требование «синхронизировать всё» не определяет главную систему, момент обновления и правила конфликтов. Ошибка в этих правилах может создать дубли контрагентов или неверный статус оплаты.
Уточните исходные системы
Запишите CRM, способ её размещения, конфигурацию и релиз 1С, используемые доработки и действующие обмены. Назначьте специалиста, который отвечает за учётную систему. Совместимость готового модуля проверяйте на этой конкретной связке.
Не считайте все коннекторы взаимозаменяемыми. Даже официальная интеграция имеет определённый состав возможностей и условия работы. До оценки проекта нужно подтвердить нужные сценарии документацией и пробным обменом.
Назначьте владельца каждого поля
Таблицу можно прокрутить вправо →
| Данные | Пример правила владения | Вопрос для согласования |
|---|---|---|
| Контакт клиента | Создаётся в CRM | Как передаётся изменение телефона? |
| Реквизиты организации | Подтверждаются в учётной системе | Как различать филиалы и юрлица? |
| Товар и цена | Приходят из 1С | Как обрабатываются разные виды цен? |
| Заказ | Передаётся из согласованной сделки | Как передать изменение состава? |
| Оплата | Подтверждается данными учёта | Что делать с частичной оплатой и возвратом? |
Это пример распределения, а не обязательная схема. Главное — не разрешать двум системам бесконтрольно перезаписывать одно поле друг у друга.
Определите идентификаторы и повторы
У объекта должен быть устойчивый ключ для сопоставления. Название компании или товара может измениться и не подходит как единственный способ поиска. Сохраните соответствие идентификаторов CRM и 1С.
Одна и та же операция может быть отправлена повторно после сбоя связи. Согласуйте, как обмен распознаёт такую попытку и не создаёт второй заказ. Проверьте также порядок событий: обновление не должно потеряться, если объект ещё не создан в принимающей системе.
Разделите сумму сделки и подтверждённые деньги
Сумма предложения, выставленный счёт и фактическая оплата — разные состояния. Определите, какое из них меняет этап сделки и какие данные попадают в аналитику. Для частичной оплаты храните понятный остаток или другое согласованное представление.
Учебный пример: заказ на 100 000 ₽ оплачен на 30 000 ₽. Нельзя автоматически трактовать это как полностью завершённую продажу, если процесс требует полной оплаты. Правило перехода и отчёт должны учитывать один и тот же смысл.
Подготовьте приёмочные сценарии
Проверьте создание, изменение, отмену, частичную оплату, возврат, дубль и повтор после недоступности системы. Для каждого случая нужны исходные данные и ожидаемый результат в обеих системах. Тестирование выполняйте на согласованных объектах и копиях, не затрагивая действующий учёт экспериментами.
В результате должны остаться схема обмена, журнал ошибок, порядок повторной отправки и ответственные за восстановление. Эти требования включите в ТЗ на CRM, чтобы сопровождение не зависело от памяти одного разработчика.
Официальные материалы
Возможности и интерфейсы сервисов меняются. Перед настройкой проверьте условия вашего тарифа и документацию выбранной интеграции.
От инструкции к рабочей системе
Нужна помощь с вашей CRM?
Расскажите о процессе и текущей задаче. Обсудим состав работ и подходящий следующий шаг. Работаем удалённо с компаниями по всей России.