У дистрибутора из B2B была обычная на вид связка: продажи в CRM, учет в 1С, склад отдельно. Менеджер видел оплаченный заказ, бухгалтер - просроченный счет, склад не понимал, можно ли отгружать. API был живой, вебхуки ходили, интеграция формально работала. Ломалось в другом месте: никто не определил, какая система главная по клиенту, заказу, оплате и отгрузке.
Короче, если CRM и ERP уже спорят между собой, чинить нужно не коннектор. Сначала фиксируют правила, потом убирают двустороннее создание сущностей, и только после этого настраивают обмен.
Дубли появляются не из-за API, а из-за бесхозных данных
Самая частая причина дублей - у записи нет хозяина. Пока и CRM, и ERP могут создать одного клиента, каждая система считает свою версию правильной, а обмен потом честно размножает путаницу.
У нас был проект на связке Bitrix24 и 1С:УТ 11.5. За первый месяц 12% карточек контрагентов задвоились. Менеджеры заводили клиента в CRM, бухгалтерия - в 1С, обмен шел в обе стороны, и через пару недель уже никто не понимал, какая карточка живая.
Мы ввели простое правило: клиент создается только в CRM, в учетную систему уходит подтвержденная запись с external_id. Через 3 недели доля дублей снизилась до уровня ниже 1%.
Мини-диалог тут обычно такой:
- "У нас интеграция есть, почему все равно дубли?"
- "Кто главный по клиенту?"
- "И CRM, и 1С могут создать карточку".
- "Тогда у вас идет гонка двух систем".
Если и CRM, и ERP могут создать одного клиента, у вас не интеграция, а гонка двух систем.
Первый релиз должен закрывать путь денег
Я бы сделал так: в первом релизе брать только то, что двигает продажу до отгрузки. Не весь учет, не архив документов, не маркетинг. Путь денег тут простой: продали, выставили счет, получили оплату, отгрузили.
Для старта почти всегда хватает такого набора:
- клиенты и контрагенты
- товары и номенклатура
- заказы
- счета и оплаты
- статусы отгрузки
У компании с 40 менеджерами мы взяли только клиента, заказ, счет и статус отгрузки. Подняли рабочий контур за 8 недель вместо ожидаемых 5-6 месяцев. Ручная работа у продаж сократилась примерно на 30 часов в неделю.
| Что передавать | Как в первом релизе | Почему |
|---|---|---|
| Заказы, оплаты, резервы | API / вебхуки | нужна реакция почти сразу |
| Прайсы, остатки, справочники | batch по расписанию | дешевле и спокойнее |
| Архив, акты, вторичные поля | отложить | не влияет на продажу |
Все, что не влияет на этот путь, можно спокойно отложить.
С 1С сначала сводят справочники, потом пишут код
Когда слышу фразу "нужна интеграция с 1С", почти всегда жду одни и те же сюрпризы: разные артикулы, единицы измерения, типы цен, НДС, статусы документов. На бумаге обмен работает, по факту учет разъезжается.
Тут нужен минимум из четырех вещей: внешний ID, таблица соответствий, журнал обмена и нормальная обработка ошибок. Часто еще нужен промежуточный слой. Мы обычно ставим что-то простое и понятное - Node.js 20 + NestJS, PostgreSQL 16, Redis для очередей или кеша. Такой слой потом легче расширять, чем прямую связку CRM с 1С.
У нас был и неудачный заход. Сначала пошли в прямую интеграцию CRM + 1С по API, обмен раз в 15 минут. Не сработало: один товар жил в трех вариантах - по артикулу, внутреннему коду и названию. Синхронизация номенклатуры падала в 18% случаев. После перехода на GUID, таблицу соответствий и журнал ошибок падение снизилось до 2%.
{
"external_id": "cust_9f2a1c",
"idempotency_key": "order_48192_v3",
"source_system": "crm",
"entity": "order",
"event": "confirmed",
"updated_at": "2026-02-14T10:21:00Z"
}
Обмен каждые 15 минут уже может быть поздно
Для прайсов и справочников пакетный обмен часто нормален. Для оплат, резервов и статусов заказа этого уже мало. За 10-15 минут менеджер спокойно продаст то, чего на складе нет, или пообещает цену, которая уже изменилась в ERP.
На одном e-commerce/B2B проекте остатки ходили пакетно раз в 15 минут. Перепродажи были регулярные, особенно в пиковые часы. Перевели заказы и резервы на событийный обмен через RabbitMQ 3.13, а потребителей сделали на Laravel 11. За квартал число таких инцидентов сократилось на 70%.
Нужен ли обмен в реальном времени везде? Нет. Для оплат, резервов и подтверждения заказа - да, часто без вариантов. Для прайсов, истории и старых документов пакетный режим обычно дешевле и надежнее.
Хорошая интеграция видна в логах и метриках
Пользователь не должен гадать, какая система сейчас победила. Он открывает карточку и видит актуальное состояние. Команде при этом нужны цифры: сколько сообщений ушло, сколько обработано, где задержка, где конфликт, где ручная правка.
На одном проекте после настройки Grafana, Prometheus и Sentry выяснилось, что проблема была не в API. Терялось 7-9% сообщений об оплатах во время преобразования формата между CRM и ERP. Поправили одно правило сопоставления, и ручные сверки бухгалтерии сократились примерно на 80%.
В ближайшие 6-12 месяцев я бы смотрел не на "интеграцию под ключ", а на дисциплину данных: владелец сущности, внешний ID, журнал обмена и метрики по конфликтам. Самый дорогой дубль - тот, который попал в отгрузку, а не в лог.
