Интеграция: ERP и учёт + amoCRM

Учётный контур: номенклатура, цены, остатки, заказы, резервы, документы и себестоимость. Для магазина это источник правды по товару и главный потребитель заказов.

Типовые системы на этом конце: 1С:УТ, 1С:ERP, 1С:КА, «МойСклад», SAP, Microsoft Dynamics.

amoCRM — CRM с воронками продаж и цифровыми воронками: сделки, этапы, задачи, интеграции с телефонией и мессенджерами.

Как с ней работать технически: API v4 с OAuth-авторизацией, вебхуками и подписками на события. Лимиты по частоте запросов привязаны к аккаунту, а превышение приводит к временной блокировке — нужен ограничитель и повторные попытки.

Из учётной системы идут номенклатура, характеристики, цены и остатки; в неё уходят заказы, оплаты, отгрузки и данные для документов (счёт, УПД, накладная).

Мы всегда описываем обмен в виде таблицы «сущность — направление — частота — владелец данных». Без этого документа интеграция работает до первой нештатной ситуации, после чего расхождения ищут вручную.

«ERP и учёт» и «amoCRM» отвечают за разные участки процесса, поэтому прямой коннектор между ними нужен не всегда — чаще они сходятся в одной из систем контура. CRM не хранит товарные остатки, платежи и чеки — она отвечает за отношения с клиентом. Обмен строим по единому ключу (телефон, e-mail или ID клиента), иначе появляются дубли контактов, а синхронизацию запускаем очередями с ограничителем частоты запросов.

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

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

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

Как и любая CRM, amoCRM не хранит остатки и не формирует чеки: это система про отношения и сделки. Товарные позиции поддерживаются, но не являются учётным регистром.

Часть ограничений обходится архитектурой (кэш, очередь, разделение каналов обмена), часть — нет: тогда мы предлагаем изменить процесс, а не имитировать его в коде.

На стоимость влияют: наличие и качество API, количество сущностей в обмене, требования к истории (загружать ли прошлые заказы), необходимость синхронизации в реальном времени, требования к маркировке и чекам, а также готовность данных на обеих сторонах.

Сроки обычно определяет не разработка, а согласования: доступы к системе, тестовый контур, договор с провайдером, правила расчёта и требования бухгалтерии. Мы выносим эти пункты в чек-лист подготовки, чтобы они не останавливали работы в середине проекта.

Первый шаг — обследование: смотрим, какие данные уже ведутся, кто владелец каждой сущности и какие ограничения есть у API. Затем делаем прототип обмена на тестовом контуре, проверяем нештатные сценарии (повтор, отмена, частичное выполнение) и только после этого выводим интеграцию в продуктив.

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