Три разных обмена, которые путают
В разговоре «интеграция с CRM и 1С» звучит как одна задача, но это минимум три разных обмена. Первый — заявки с сайта в CRM. Второй — товары, цены и остатки из учётной системы на сайт. Третий — заказы и документы с сайта в учётную систему и статусы обратно.
Смешивать их в одном этапе рискованно: у каждого свой источник истины, своя частота и свои правила при расхождении. Когда всё делается сразу, сбой в одном обмене выглядит как поломка всей системы, и искать причину приходится наугад.
Практический совет: начинайте с обмена, который снимает самую заметную ручную работу. Чаще всего это заявки — они идут каждый день и легко проверяются по факту появления записи в системе.
Что подготовить до старта
Интеграция тормозит не из-за кода, а из-за организационной части. До старта нужен человек на стороне заказчика, который отвечает за учётную систему и может подтвердить правила обмена.
Дальше — доступы. Нужны тестовый контур или копия базы, учётная запись с правами на нужные операции, документация по API или описание формата обмена. Если API нет, обсуждается другой способ: файлы по расписанию, промежуточная база, ручная выгрузка.
Отдельно договоритесь о том, кто в компании принимает решения по спорным случаям. Практика показывает: обмен готов, а вопрос «что считать одной заявкой, если клиент написал дважды за минуту» остаётся без ответа и решается уже в рабочем порядке. Один такой вопрос способен переделать логику после запуска.
- Ответственный за CRM и ответственный за 1С со стороны заказчика
- Тестовая база или копия, на которой можно прогонять сценарии
- Доступы: ключи API, учётные записи, права на чтение и запись
- Описание справочников: товары, контрагенты, статусы, склады
- Перечень обязательных полей заявки и заказа
- Правило, кто главный по каждой сущности
Правила обмена: направление и частота
Для каждой сущности определяют источник истины. Цена и остаток живут в учётной системе, описание товара может редактироваться на сайте, статус заказа — в CRM или в учётной системе. Если правило не задано, системы начинают перезаписывать данные друг друга.
Частота обмена — компромисс. Обмен по событию быстрее, но требует, чтобы система умела сообщать об изменениях. Обмен по расписанию проще, но данные отстают. Для остатков частота обычно важна, для описаний — нет.
Отдельно фиксируют, что происходит при массовом изменении: переоценка, смена статусов, загрузка нового каталога. Именно такие события чаще всего создают расхождения, которые потом ищут неделями.
Ключи сопоставления и конфликты
Чтобы связать записи, нужен устойчивый идентификатор: артикул, GUID, ИНН, номер заказа. Название для этого не подходит: оно меняется, содержит лишние символы и повторяется у разных позиций.
Правила конфликтов описывают заранее. Что делать, если товар есть на сайте, но удалён в учётной системе? Если заказ пришёл дважды? Если цена изменилась между оформлением и оплатой? Ответы на эти вопросы — часть технического задания, а не деталь реализации.
Ещё один слой — единицы и форматы: штуки, упаковки, вес, НДС, валюта, часовой пояс. Расхождение в единицах измерения обнаруживается не сразу, а на сверке сумм, когда документы уже ушли клиентам.
Что ломается чаще всего
Первое — дубли. Повторная отправка заявки или повторный запуск обмена создаёт вторую запись. Лечится это идемпотентностью: у операции есть ключ, и повтор с тем же ключом не создаёт новую сущность.
Второе — молчаливые сбои. Обмен упал, никто не заметил, данные разошлись. Поэтому журнал операций и уведомление ответственному — не дополнительная функция, а обязательная часть работы.
Третье — изменения на стороне учётной системы: обновилась конфигурация, поменялся формат, закрыли доступ. Интеграция должна падать заметно и сообщать об этом, а не тихо переставать передавать данные.
Четвёртое — человеческий фактор. Сотрудник меняет заказ в двух местах сразу, потому что привык работать и в CRM, и в учётной системе. Сколько бы правил ни было в обмене, привычку придётся менять: обычно это вопрос регламента, а не кода.
Поведение при сбое
Сбой — нормальная ситуация, а не исключение. Плановое обновление, недоступность сети, ограничение на количество запросов — всё это происходит регулярно. Вопрос в том, что видит пользователь и что происходит с данными.
Хорошее поведение: заявка сохраняется у вас и ставится в очередь, клиент получает подтверждение, ответственный — уведомление, обмен повторяется автоматически. Плохое: форма показывает ошибку, данные теряются, а узнать об этом можно только по жалобе клиента.
Проверять это нужно на тестовом контуре: отключите приёмник и посмотрите, что произойдёт. Если сайт просто перестаёт принимать заявки, интеграция спроектирована плохо.
Приёмка интеграции
Приёмка идёт по сценариям, а не по факту «обмен настроен». Сценарии описывают заранее и прогоняют на тестовой базе, фиксируя результат: что появилось, где, с какими данными.
Стоимость такой работы начинается от 39 990 ₽ — это стартовая цена автоматизации одного сценария. Итог зависит от количества систем, качества их API и сложности правил, поэтому называется после проверки документации.
- Заявка с сайта появляется в CRM с корректными полями и без дублей
- Повторная отправка той же заявки не создаёт вторую запись
- Товар, цена и остаток обновляются на сайте и совпадают с учётной системой
- Заказ уходит в учётную систему и возвращается со статусом
- При недоступности системы заявка не теряется, а ждёт отправки
- Ответственный получает уведомление о сбое
- Журнал операций позволяет понять, что и когда передавалось
- Есть инструкция для сотрудников: что делать при сбое