Перед интеграцией CRM с 1С нужно согласовать, какие объекты передаются, какая система отвечает за каждое поле и что делать при повторе или ошибке. Начинать с выбора модуля рано, если «заказ», «клиент» и «оплата» у участников проекта означают разные вещи.
Практический результат подготовки — паспорт интеграции. Это документ, по которому специалисты CRM и 1С могут настроить обмен, а руководитель — принять его на контрольных примерах. Ниже — структура паспорта и учебная схема, которую можно адаптировать под свой процесс.
Что описать до выбора решения
Зафиксируйте название и версию конфигурации 1С, версию платформы, внесённые доработки, способ размещения, CRM и используемые приложения. Укажите ограничения доступа, расписание обслуживания и ответственных специалистов с обеих сторон. Фраза «у нас 1С» не позволяет проверить совместимость модуля.
Затем опишите один законченный процесс. Например: менеджер согласовал состав заказа, данные переданы в учётную систему, заказ принят, оплата и отгрузка возвращены в CRM. Для каждого шага нужен наблюдаемый результат и человек, который подтверждает его правильность.
Уточните объём первичной загрузки, обычное число изменений и допустимое запаздывание данных. Отдельно решите, переносится ли история. Обмен новыми документами и загрузка старых записей требуют разных проверок и не должны подразумеваться одним словом «синхронизация».
Какие данные передавать
Включайте объект в обмен, если он нужен процессу в принимающей системе. Необязательно копировать весь справочник или все бухгалтерские сведения, чтобы менеджер увидел состояние заказа. Вместе с владельцем процесса определите минимальный достаточный состав.
| Объект | Возможное направление | Что согласовать |
|---|---|---|
| Контактное лицо | CRM → 1С, если нужно для обработки заказа | Какие контакты передавать и кто исправляет телефон или email |
| Реквизиты покупателя | Из системы, где их проверяет ответственный сотрудник | Юрлицо, набор реквизитов, идентификатор и порядок исправления |
| Номенклатура | 1С → CRM в этой учебной схеме | Идентификаторы товаров, варианты, единицы измерения, архивные позиции |
| Цены и остатки | 1С → CRM в этой учебной схеме | Тип цены, склад, валюта, время актуальности и смысл доступного количества |
| Согласованный заказ | CRM → 1С | Событие отправки, состав, организация, скидки и допустимые изменения |
| Оплаты и отгрузки | 1С → CRM | Частичное исполнение, возвраты, отмены и связь с конкретным заказом |
Таблица — пример проектирования, а не описание возможностей любого коннектора. В вашей конфигурации объекты и направления могут отличаться. Для каждого поля дополнительно запишите тип, обязательность, допустимые значения и поведение при пустом значении: очистить, оставить прежнее или сообщить об ошибке.
Не приравнивайте этап продажи к статусу оплаты. Заказ может быть частично оплачен и частично отгружен одновременно. Если свести всё к одному полю, менеджер потеряет часть информации. Согласуйте отдельные признаки и правила перехода коммерческого этапа.
Где хранить главный справочник клиентов
Выбирать единственную главную систему для всех сведений о клиенте необязательно. Можно закрепить владельца по группе данных: контакты и коммуникации ведёт отдел продаж, проверенные реквизиты — учётная служба. Важно, чтобы одно поле не исправляли независимо с обеих сторон без правила разрешения конфликта.
Для связи записей храните устойчивое соответствие идентификаторов двух систем. Название компании не подходит как единственный ключ: оно меняется и может повторяться. ИНН помогает проверять организацию, но правило сопоставления должно учитывать тип клиента и структуру реквизитов; один контакт может представлять несколько юридических лиц.
- Определите, где создаётся новая запись и кто проверяет её перед передачей.
- Опишите поиск существующего объекта и действие при нескольких совпадениях.
- Зафиксируйте связь идентификаторов после первого успешного сопоставления.
- Назначьте систему, которая имеет право менять каждое передаваемое поле.
- Определите обработку конфликта: отклонение, ручной разбор или явное правило приоритета.
Правило «берём последнюю запись» допустимо только после согласования последствий. Поздно пришедшее сообщение не обязательно содержит более свежие данные. В паспорте нужно различать время изменения объекта и время доставки события.
Паспорт интеграции: рабочая заготовка
Скопируйте эти разделы в документ и заполните их вместе со специалистами обеих систем. Не помещайте пароли и токены в паспорт: укажите защищённое место хранения и ответственного за доступ.
- Цель и границы: какой ручной шаг устраняем, какие организации, базы и воронки участвуют, что остаётся вне обмена.
- Системы: конфигурации, версии, доработки, модуль или обработчик, способ размещения.
- Объекты и поля: источник, получатель, идентификаторы, обязательность и правила преобразования.
- События: условие первой отправки, последующих изменений, отмены и первичной загрузки.
- Повторы и конфликты: как исключается повторное создание и какое изменение имеет приоритет.
- Сроки: расписание обмена, допустимое запаздывание, признаки просрочки и порядок восстановления после перерыва.
- Контроль: журнал, уведомления, периодическая сверка объектов и итогов.
- Ответственность: владелец процесса, специалисты CRM и 1С, координатор инцидентов, принимающий результат.
- Приёмка: примеры данных, ожидаемые результаты, ограничения и порядок остановки ошибочного обмена.
Учебный пример заполнения для заказа. CRM отправляет согласованный заказ после проверки обязательных полей. В 1С создаётся один документ, его идентификатор сохраняется в связи с исходной сделкой. Повтор той же отправки не создаёт второй документ. После принятия заказа изменение состава проходит отдельное согласование; CRM не перезаписывает его незаметно. Статусы оплаты возвращаются из 1С. Это проектное требование, которое ещё нужно подтвердить в выбранном решении.
Для такого примера обязательно решите, может ли одной сделке соответствовать несколько заказов. Если да, связь должна храниться по каждому заказу: одного поля «номер заказа» будет недостаточно.
Готовый модуль или разработка
Сначала сопоставьте паспорт с возможностями готового решения. Запросите подтверждение совместимости с вашей конфигурацией и версией, поддерживаемые объекты, направления, правила повторов и порядок обновлений. Проверьте ограничения на тестовых данных до покупки и запуска.
Например, в описании приложения «Синхронизация сделок и заказов в 1С:Предприятие 8» разработчика «Активные Технологии» в Маркетплейсе Битрикс24 прямо указано, что товары из сделки в 1С не передаются. Название приложения само по себе не гарантирует передачу всего состава заказа. Это ограничение конкретного продукта, а не всех интеграций Битрикс24. Описание разработчика.
Собственная разработка оправдана, когда обязательные правила не покрываются доступным модулем или требуют несоразмерных обходных действий. Платформа 1С поддерживает web- и HTTP-сервисы, а также доступ через OData. Это технические механизмы обмена; правила заказа, сопоставления и обработки ошибок всё равно нужно спроектировать. Возможности интеграции 1С.
Сравнивайте полную стоимость: лицензии и инфраструктуру, внедрение, обновления обеих систем, поддержку и восстановление после сбоев. Для разработки заранее определите передачу исходников, документации и тестов. Для модуля — кто отвечает за совместимость после обновления и как проверить новую версию до рабочего запуска.
Кто отвечает за ошибки обмена
У обращения должен быть один координатор, который доводит его до проверенного результата. Исправлять причину могут разные специалисты: CRM, 1С, разработчик модуля или администратор инфраструктуры. Такая схема помогает избежать ситуации, когда каждый видит только свою часть и считает задачу чужой.
В журнале полезно видеть время, исходный и целевой объект, действие, результат, причину ошибки и последнюю попытку. Не включайте туда секреты и лишние персональные данные. Отдельно контролируйте объекты, которые вообще не дошли до отправки: отсутствие сообщения об ошибке ещё не подтверждает полноту обмена.
Разделите временную недоступность и ошибку данных. При недоступности может помочь повтор, но он должен быть безопасным для уже созданных объектов. Если не заполнен обязательный реквизит, бесконечные повторы ничего не исправят: нужен владелец данных и понятная задача. После восстановления связи сверяют накопившиеся изменения, а не только статус «подключено».
Что проверить перед приёмкой
- Создание: новый заказ появился один раз и связан с нужным клиентом.
- Повтор: повторная доставка того же сообщения не создала дубль.
- Ошибка данных: объект с отсутствующим реквизитом попал в разбор с понятной причиной.
- Конфликт: изменения с двух сторон обработаны по согласованному правилу.
- Частичное исполнение: оплата и отгрузка отражаются отдельно и относятся к нужному заказу.
- Отмена: отменённый объект не восстановился сам после очередного обмена.
- Перерыв: после тестового сбоя накопившиеся события обработаны без пропусков и дублей.
- Сверка: количества, суммы и связи совпадают в согласованной выборке и периоде.
Проверки выполняйте в тестовом контуре. Для сумм заранее согласуйте валюту, округление, налоги и момент фиксации данных; сравнение разных срезов даст ложные расхождения. Успешная передача одного заказа не подтверждает правильность всей интеграции.
Если паспорт содержит открытые вопросы, сначала закройте их с владельцами процессов. Для нового обмена это основа проекта интеграции amoCRM с 1С. Для действующей связки согласуйте проверки и ответственность в рамках сопровождения; структуру такого соглашения разбираем в статье о результате сопровождения CRM.