Обычно запрос звучит просто: «нужно связать сайт, CRM и 1С, чтобы все работало автоматически». Потом открываешь проект, а там сайт живет с ночными остатками, CRM держит свои статусы, в 1С заказ появляется через 40 минут, бухгалтер сверяет оплаты руками. Я заходил в такие истории много раз, и причина почти всегда одна: системы есть, правил между ними нет.
Бизнесу редко нужна «интеграция вообще». Ему нужно убрать ручной труд, перестать терять заказы и добиться одной версии данных для всех. Для этого сначала надо понять, где ошибка обходится дороже всего.
Сначала чинят то, на чем бизнес уже теряет деньги
В SMB основную пользу обычно дают не десять интеграций, а 2-3 базовых сценария. Сайт и 1С, CRM и контрагенты, банк и оплаты, склад и остатки. Сущности почти всегда одни и те же: номенклатура, цены, остатки, заказы, статусы, контрагенты, оплаты, возвраты.
У нас был интернет-магазин с каталогом примерно 2400 SKU. Клиент хотел бонусную систему и более сложный личный кабинет, но деньги терял совсем в другом месте: менеджеры тратили по 2-3 часа в день на правку остатков и объяснения клиентам, почему товар «был в наличии», а потом исчез. На первом этапе мы связали сайт с 1С по остаткам и статусам заказов через CommerceML. Ручная работа сократилась до 20-30 минут в день.
Смотрите: приоритет здесь определяется не красотой схемы, а ценой ошибки.
- теряете продажи из-за ложных остатков - первым идет товарный и складской контур;
- дублируются клиенты и сделки - сначала CRM и контрагенты;
- менеджеры вязнут в актах и оплатах - начинайте с документов и взаиморасчетов.
API нужен там, где задержка реально бьет по деньгам
Я бы не стал тащить все в real-time только потому, что это звучит современно. Прайс на 50 000 позиций пакетно раз в ночь или раз в 15 минут часто дешевле и устойчивее, чем тысячи вызовов в минуту. А кредитный лимит в B2B-кабинете или подтверждение оплаты в момент заказа - уже нормальный сценарий для API.
Один проект из прошлого года это хорошо показал. Оптовая компания хотела «только API». В итоге для заказов и оплат мы оставили HTTP-сервисы 1С и webhooks, а цены и остатки гоняли пакетно в JSON раз в 15 минут. Поддержка стала проще, инцидентов стало меньше.
| Режим | Где работает | Что по рискам |
|---|---|---|
| По запросу | лимиты, оплаты, статус сейчас | быстро, но дороже в поддержке |
| По событию | новый заказ, отмена, смена статуса | нормальный баланс |
| По расписанию | цены, остатки, каталог | проще и спокойнее |
Сайт -> webhook -> интеграционный слой -> очередь -> 1С
|
PostgreSQL 16 + Redis
Когда обменов мало, хватает webhook + polling. Когда 1С недоступна, а платеж уже прошел, без очереди, retry и логов вы начинаете восстанавливать заказы вручную.
Самая дорогая ошибка - когда у данных нет хозяина
Главный вопрос интеграции простой: кто главный по данным. Если карточку клиента можно менять в CRM, в 1С и частично на сайте, конфликт прилетит в первую же неделю. Дальше появляются дубли контрагентов, старые реквизиты в документах и бесконечные вопросы, почему система опять «сломалась».
На интеграции дороже всего обходится не код, а неоговоренные правила владения данными.
У нас был B2B-клиент в дистрибуции. Менеджеры правили компании в CRM, бухгалтерия - в 1С, сайт подтягивал обе версии в разное время. Через месяц нашли 147 дублей, а часть реализаций ушла на старые реквизиты. После этого мы зафиксировали матрицу: CRM - лиды и сделки, 1С - юрлица, документы и взаиморасчеты, сайт - витрина и кабинет, складская система - движения по складу.
Мы сами однажды заходили в проект без такой матрицы, и это была наша ошибка. Формально обмен работал, но каждую неделю всплывал новый «баг», который багом не был. Системы просто спорили, кому верить.
Малому бизнесу не нужна тяжелая схема, ему нужен контроль
Когда систем 3-4, прямых связей быстро становится 6 и больше. В этот момент начинается ручной поиск: кто что отправил, где потерялось, почему появился дубль, почему статус не дошел. Поэтому я предпочитаю один интеграционный слой на Laravel 11 или Node.js 20 + NestJS, очередь, единый лог и контроль дублей.
Нужна ли вам шина и сложная архитектура?
Если у вас сайт, CRM, 1С и банк с умеренной нагрузкой, почти никогда. Хватает аккуратного промежуточного слоя, где видно что передали, когда передали и почему не дошло.
Это не попытка сэкономить на архитектуре. Это попытка не купить себе лишние 300-800 тыс. ₽ сложности на запуске и потом не платить за ее обслуживание каждый месяц.
До оценки нужна карта обмена, а не список систем
Когда мне говорят «подключите сайт к 1С», я сначала задаю скучные вопросы. Где создается заказ, кто меняет цену, как часто обновляются остатки, сколько документов в день, что делать при ошибке, кто отвечает со стороны 1С. Без этого оценка будет пальцем в небо.
Еще до старта я бы проверил вот это:
- типовая 1С или нетиповая, и какая платформа - например 1С 8.3;
- есть ли старые доработки и кто их реально поддерживает;
- какие сценарии критичны в первый релиз;
- какой объем данных идет в обмене;
- кто принимает решение при конфликте данных.
Обычно мы запускаем такие проекты этапами: сначала заказы и статусы, потом остатки и цены, потом возвраты, акты и сверки. В одной компании за 6 недель этого хватило, чтобы убрать ложные остатки и потерянные оплаты. Хотя изначально там тоже хотели, чтобы «все работало автоматически».
Если в вашем проекте сайт, CRM и 1С уже спорят между собой, не начинайте с выбора протокола. Сначала решите, кто из них имеет право говорить правду. Иначе получите ту же картину из начала статьи, только дороже.
