Интеграции сайта с 1С, CRM и оплатой: как это работает

Интеграция сайта с 1С — это не «подключить 1С», а договориться о трёх вещах: что считается источником правды, как часто данные обновляются и что происходит, когда обмен не прошёл. Технически всё сводится к двум режимам: пакетная выгрузка по расписанию и онлайн-запрос в момент действия пользователя. Дальше — детали, из-за которых проекты и разъезжаются по срокам.

Как вообще устроен обмен

Между сайтом и учётной системой всегда есть посредник — наш слой на Node.js, который принимает данные, проверяет их, приводит к своему формату и складывает в MongoDB. Сайт читает только из своей базы и никогда не ходит в 1С за каждым чихом. Это принципиально: 1С в рабочее время занята закрытием месяца и не обязана держать нагрузку от посетителей сайта.

Кто источник правды, определяется по каждому типу данных отдельно, и это стоит зафиксировать письменно до начала работ. Обычно так: товары, цены и остатки — 1С; контент, описания, фотографии для сайта и адреса страниц — сайт; заявки и клиенты — CRM. Каждое поле принадлежит одной системе. Как только два места начинают редактировать одно поле, у вас появляется вечная работа по разбору расхождений.

Выгрузка против онлайн‑обмена

Выгрузка — это когда 1С по расписанию формирует пакет данных и отдаёт его на сайт: обычно XML в формате CommerceML, реже JSON, если обмен пишется с нуля. Онлайн-обмен — это когда сайт в момент действия дёргает 1С через веб-сервис или OData и ждёт ответ. Оба режима нужны, но для разных данных.

Рабочая схема на большинстве каталогов гибридная: номенклатура и цены приезжают выгрузкой каждые 15–60 минут, а остаток по конкретной позиции запрашивается онлайн в момент оформления заказа — с таймаутом в 2–3 секунды и понятным поведением, если ответа нет. Так каталог быстрый, а обещание «есть на складе» не превращается в звонок с извинениями.

CRM: что и когда туда отдавать

С CRM всё проще технически и сложнее организационно. Технически — заявка уходит вебхуком в Битрикс24 или amoCRM за пару секунд. Организационно — надо решить, что делать, когда CRM не ответила, и не потерять заявку.

• Заявка сначала пишется в свою базу, и только потом уходит в CRM. Если CRM недоступна, заявка не пропала — она уйдёт при следующей попытке.
• Повторные попытки по нарастающему интервалу: через минуту, пять, пятнадцать. После трёх неудач — письмо ответственному, а не тишина.
• Вместе с заявкой передаём источник: utm-метки, страницу, с которой пришёл человек, и клиентский идентификатор. Без этого через полгода нельзя ответить, какой канал приносит сделки.
• Обратный поток — статус сделки из CRM на сайт — нужен, только если есть личный кабинет. Иначе это лишняя связь, которую придётся чинить.

Оплата

Приём платежей — самая зарегулированная часть, и одновременно самая предсказуемая: ЮKassa, Т-Касса и CloudPayments работают по одной логике. Сайт создаёт платёж и отправляет человека на защищённую страницу оплаты, а результат узнаёт не от вернувшегося браузера, а из вебхука от платёжного сервиса.

1. Никогда не считайте заказ оплаченным по факту редиректа обратно на сайт. Человек мог закрыть вкладку, а платёж прошёл — и наоборот.
2. Вебхук обязан быть идемпотентным: сервис пришлёт одно и то же уведомление несколько раз, и второй раз отгружать товар не надо.
3. Проверяйте подпись уведомления. Открытый вебхук без проверки подписи — это кнопка «пометить заказ оплаченным» для всего интернета.
4. Чек по 54-ФЗ формирует платёжный сервис, но состав корзины и ставку НДС передаёте вы. Ошибка в ставке всплывает у бухгалтера через месяц.
5. Возвраты делаются через тот же сервис и должны отражаться и в 1С, и на сайте. Про них забывают в 8 проектах из 10.

Что ломается чаще всего

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

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

Как не убить SEO каталогом из 1С

Вот здесь мы видим больше всего потерь. 1С — учётная система, её данные оптимизированы под склад и бухгалтерию, а не под поиск. Если выгрузить их на сайт как есть, получится каталог, который не находят.

• Адрес страницы не должен зависеть от названия в 1С. Складское наименование меняется, а вместе с ним меняется адрес — и все накопленные позиции обнуляются. Мы фиксируем slug в MongoDB один раз при создании товара и больше не пересчитываем.
• Заголовок и описание для людей живут на сайте и не перезатираются выгрузкой. Название вида «Кабель ВВГнг 3х2.5 ГОСТ /бухта 100м/» не должно быть H1.
• Товар кончился — не 404. Страница остаётся, показываем «нет в наличии», предлагаем аналоги. Удаление страницы каждый раз стоит трафика.
• Автогенерация фильтров без ограничений плодит десятки тысяч почти одинаковых страниц. В индекс пускаем только те комбинации, у которых есть спрос, остальное закрываем canonical.
• Массовые изменения адресов — это уже переезд, и делается он с картой редиректов, а не «мы просто перевыгрузили каталог».

На каталоге в 12 000 позиций с выгрузкой из 1С органика выросла на 68% именно за счёт этого разделения: 1С отвечает за наличие, цены и характеристики, а тексты, адреса, заголовки и структура разделов принадлежат сайту и живут своей жизнью. Никакой магии, просто данные перестали перетирать друг друга при каждой выгрузке.

Сроки и бюджет

Интеграция редко продаётся отдельно — она часть проекта. Но в смете это отдельная строка, и вот честные ориентиры по нашим работам.

Сроки сильно зависят не от нас, а от того, есть ли у вас программист 1С и как быстро он отвечает. Реальная причина срыва сроков в интеграциях почти всегда одна: со стороны учётной системы никого не выделили, и запрос «добавьте, пожалуйста, поле в выгрузку» висит три недели. Мы это заранее проговариваем и закладываем в план.

Каталог с обменом мы делаем в рамках корпоративных сайтов, онлайн-обмен для кабинетов — в веб-сервисах. Пример второго — кабинет логистической компании, где статусы отгрузок подтягиваются в реальном времени: обращений в поддержку стало на 60% меньше, но работает это только потому, что данные свежие. Кабинет с устаревшими данными раздражает сильнее, чем его отсутствие.

И последнее про скорость: тяжёлый каталог из 1С с сотнями характеристик легко превращает страницу в мегабайт данных и убивает загрузку на мобильных. Что с этим делать — в статье про Core Web Vitals.

Короткие ответы

• 1с
• crm
• интеграции
• каталог