16.02.2026 
4 минуты 
159 Если вы столкнулись с ситуацией, когда менеджер вручную закрывает сделку в Битрикс24, и статус заказа в 1С меняется, а при автоматическом закрытии (роботом, бизнес-процессом или триггером) синхронизация не происходит — вы не одиноки. Это типичная ошибка штатной интеграции Битрикс24 (облако) и 1С:УТ по HTTPS. Причина кроется не в поломке обмена, а в том, как разные способы завершения сделки воспринимаются модулем синхронизации. В этой статье мы разберем причины и дадим пошаговые инструкции для исправления.
Почему автоматическое закрытие не синхронизируется: главная причина
Штатная интеграция Битрикс24 и 1С построена на отслеживании изменений в карточке сделки. Когда менеджер вручную переводит сделку на финальную стадию, система генерирует полноценное событие OnAfterCrmDealUpdate. Это событие помечает сделку как «измененную» для модуля обмена. При следующем сеансе обмена 1С видит этот флаг и обновляет статус заказа.
При автоматическом закрытии (робот, бизнес-процесс, REST) событие часто бывает «упрощенным». Оно меняет стадию в базе данных, но не инициирует флаг синхронизации. Для модуля обмена сделка остается неизменной, и обновление в 1С не происходит.
Как работает штатный обмен: схема и узкое место
Понимание механики обмена поможет быстрее диагностировать проблему. Процесс выглядит так:
- В Битрикс24 меняется стадия сделки.
- Внутренний обработчик модуля интеграции проверяет, является ли изменение «пользовательским».
- Если да — сделка помечается как требующая синхронизации.
- При следующем регламентном сеансе обмена данные уходят в 1С.
- В 1С по таблице соответствия стадий CRM и статусов заказов выполняется обновление.
Узкое место — шаг 2. Не все автоматические изменения проходят проверку на «пользовательское». Модуль обмена в 1С часто имеет настройку: «Выгружать только сделки, изменённые пользователями». Если флаг не выставлен, сделка игнорируется.
Диагностика: 2 шага для точного определения причины
Прежде чем исправлять, убедитесь, что проблема именно в механизме обмена, а не в настройках 1С.
Шаг 1. Проверка журнала регистрации обмена в 1С
- Перейдите в раздел Администрирование → Обмен с сайтом / CRM.
- Откройте Журнал регистрации обмена.
- Найдите проблемную сделку по её ID (номеру).
- Сравните две записи: после ручного закрытия и после автоматического.
Результат: Если в логе после автоматического закрытия сделка отсутствует или помечена как «не изменена» — причина найдена.
Шаг 2. Определение механизма автоматизации
Зафиксируйте, какой именно инструмент используется для закрытия:
- Робот CRM (например, «Сменить стадию»).
- Бизнес-процесс (действие «Изменить документ»).
- Триггер (например, после получения оплаты).
- REST API или вебхук (внешняя интеграция).
Это критично, так как каждый механизм по-разному взаимодействует с событием OnAfterCrmDealUpdate.
4 рабочих способа исправления ошибки
Выберите подходящий вариант в зависимости от ваших технических возможностей и используемого инструмента.
Вариант 1. Принудительное изменение сделки (самый надежный)
После автоматического перевода стадии добавьте дополнительное действие — изменение любого поля сделки. Это гарантированно вызовет полноценное событие обновления.
Пример настройки робота:
- Создайте робота, который срабатывает после перевода сделки в финальную стадию.
- Добавьте действие «Изменить поле сделки».
- Выберите любое неиспользуемое поле, например, «Комментарий» или служебное поле «UF_CRM_SYNC».
- Установите значение: текущая дата и время (например, с помощью переменной
{=work:date}).
Зачем это нужно: Даже пустое изменение поля создает событие изменения, которое модуль обмена воспринимает как сигнал к синхронизации.
Вариант 2. Смена инструмента автоматизации
Если вы используете бизнес-процесс, попробуйте заменить его на робота CRM. Роботы чаще корректно фиксируются в обмене, так как работают на уровне событий, а не через API.
Что делать:
- Вместо действия БП «Изменить документ (стадия)» используйте робота «Сменить стадию».
- Настройте робота на срабатывание по тому же триггеру (например, после оплаты).
Результат: В 80% случаев это решает проблему без дополнительных доработок.
Вариант 3. Доработка на стороне 1С (для программистов)
Если у вас есть доступ к конфигурации 1С, можно изменить логику отбора записей для выгрузки.
Действия программиста 1С:
- Убрать фильтр «Только изменённые пользователями» в модуле обмена.
- Или добавить условие: «Если стадия сделки изменилась → всегда обновлять статус заказа».
Это системное решение, но требует вмешательства в код.
Вариант 4. Использование регламентного задания
Если ни один из способов не подходит, настройте принудительную синхронизацию по расписанию. В 1С создается регламентное задание, которое каждые N минут проверяет все сделки, изменившие стадию, и обновляет статусы заказов.
Минус: Задержка синхронизации до N минут. Плюс: Не требует доработки логики событий.
Сравнение способов исправления
| Способ | Сложность | Надежность | Требует доступа к 1С |
|---|---|---|---|
| Принудительное изменение поля | Низкая | Высокая | Нет |
| Смена инструмента (робот вместо БП) | Средняя | Средняя | Нет |
| Доработка модуля обмена в 1С | Высокая | Высокая | Да |
| Регламентное задание | Средняя | Средняя | Да |
Часто задаваемые вопросы (FAQ)
Почему ручное закрытие работает, а автоматическое — нет?
Ручное закрытие генерирует полное событие OnAfterCrmDealUpdate, которое помечает сделку как измененную для модуля обмена. Автоматические методы часто используют упрощенные вызовы API, которые не выставляют этот флаг.
Какой способ исправления самый простой?
Самый простой — добавить робота, который после закрытия сделки меняет любое поле (например, «Комментарий»). Это делается за 5 минут без программирования.
Может ли проблема быть на стороне 1С?
Да, если в настройках модуля обмена включен фильтр «Только изменённые пользователями». Проверьте журнал регистрации обмена в 1С, чтобы исключить этот вариант.
Что делать, если я использую REST API для закрытия сделок?
При вызове REST API убедитесь, что вы передаете параметр REGISTER_SONET_EVENT = 'Y' или используете метод crm.deal.update с полным набором полей. В некоторых случаях требуется дополнительно вызвать метод crm.deal.fields, чтобы принудительно зарегистрировать изменение.
Поможет ли обновление модуля интеграции?
Иногда да. В новых версиях модуля «1С:Предприятие» и плагина для Битрикс24 исправляют ошибки, связанные с обработкой событий. Рекомендуется обновить оба компонента до актуальных версий.
Выводы и рекомендации
Проблема с автоматическим закрытием сделок — не ошибка интеграции, а особенность архитектуры обмена. В 90% случаев её можно решить без глубоких доработок, добавив принудительное изменение поля сделки или заменив бизнес-процесс на робота CRM.
Если вы не хотите тратить время на самостоятельную настройку, доверьте эту задачу профессионалам. LeadSpace — Платиновый партнёр Битрикс24, топ-30 из 12 000 партнёров. Мы настроим обмен под ключ за 1 день. Оставьте заявку на консультацию или посмотрите наши услуги.
