Обмен 1С с Битрикс24 и Telegram: регламент и 7 ошибок

Q: Можно ли принимать команды из Telegram в 1С?

Технически да: через метод getUpdates по опросу из регламентного задания либо через webhook, который требует публично доступного HTTP-сервиса с валидным сертификатом. Для регламента важнее другое – зафиксировать, какие действия боту разрешены, и исключить любые операции, меняющие учётные данные.

Автор: Михаил С., Архитектор 1С · Опубликовано: 29.10.2026

Обмен 1С с Битрикс24 и Telegram: регламент и 7 ошибок

📅 Опубликовано 29 октября 2026 г.

Коротко: регламент обмена 1С с Битрикс24 и Telegram – это документ из девяти разделов, который фиксирует состав передаваемых данных, расписание регламентных заданий, точки хранения логов, допустимое время простоя и ответственного за каждый контур. Без него сбой обмена обнаруживают по жалобе клиента через несколько дней. С ним – по сообщению бота в течение интервала, который вы сами записали в документ.

Обмен с «1С-Битрикс: Управление сайтом» идёт по стандарту CommerceML 2 через обработчик /bitrix/admin/1c_exchange.php: в опубликованном протоколе выгрузка каталога состоит из четырёх шагов – checkauth, init, file, import, а для заказов цепочка иная: checkauth, init, query, success, file. Режимы deactivate и complete – особенности серверной реализации 1С-Битрикс, а не шаги протокола.
Три точки диагностики: журнал обмена в административной панели Битрикс, журнал регистрации и технологический журнал 1С, HTTP-ответы Telegram Bot API.
Telegram в этой схеме работает как канал алертов: бот отправляет sendMessage, а код 429 с полем retry_after означает превышение лимита частоты.
Семь ошибок, которые ломают обмен чаще всего: от истёкшего пароля сервисного пользователя до молчаливого проглатывания исключений в Попытка…КонецПопытки.
Матрица ответственности и допустимое время простоя – обязательные разделы: без них регламент остаётся инструкцией, а не рабочим документом.

Зачем нужен регламент обмена 1С с Битрикс24 и Telegram?

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

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

Контур	Что фиксирует регламент	Где проверяют состояние	Ответственный	Реакция
Выгрузка каталога 1С → Битрикс24	Состав полей, свойства, картинки, расписание, размер файла выгрузки	Журнал обмена в админпанели портала	Администратор 1С	До конца рабочего дня
Загрузка заказов Битрикс24 → 1С	Соответствие статусов, правила сопоставления контрагентов, обработка дублей	Журнал регистрации 1С, событие обмена	Руководитель отдела продаж + администратор	1 час в рабочее время
Выгрузка остатков и цен	Вид цены, тип склада, частота, допустимое расхождение	Отчёт сверки остатков	Администратор 1С	2 часа
Алерты в Telegram	Какие события попадают в чат, формат текста, лимиты частоты	Лог HTTP-ответов Bot API	Разработчик расширения	1 час
Доступы и секреты	Сервисный пользователь, токен бота, срок ротации	Регистр настроек, парольный менеджер	Служба ИТ	Плановая ротация

Как устроен обмен 1С и Битрикс24 на уровне CommerceML?

1С выступает инициатором: она последовательно вызывает обработчик на стороне портала, передавая параметр type (catalog или sale) и параметр mode – текущий шаг сценария. Портал отвечает простым текстом, первая строка которого и есть результат. Понимание этой последовательности сокращает поиск причины сбоя до одного-двух шагов.

Шаг (`mode`)	Что происходит	Типовой ответ портала	Что означает сбой на этом шаге
`checkauth`	Авторизация сервисного пользователя, получение cookie сессии	`success` + имя и значение cookie	Неверный логин, истёкший пароль, нет права на обмен
`init`	Согласование параметров: архивирование, предельный размер файла	`zip=yes/no`, `file_limit=…`	Нет прав на запись в каталог обмена, не включён ZIP на сервере
`file`	Передача частей XML и картинок на сервер	`success`	Превышен лимит загрузки, нехватка места, обрыв по таймауту
`import`	Пошаговый разбор XML, запись в инфоблок	`progress` до завершения, затем `success`	Ошибка структуры XML, долгий шаг упал в лимит времени скрипта
`deactivate`	Деактивация элементов, которых нет в выгрузке	`success`	Отсутствие шага приводит к «вечным» снятым с производства товарам
`complete`	Завершение сеанса, очистка временных файлов	`success`	Мусор в каталоге обмена, рост занятого места

Ответ failure всегда сопровождается текстом ошибки во второй строке – именно его стоит пересылать в Telegram целиком, без сокращений. Ответ progress на шаге import нормален: портал обрабатывает файл порциями и просит повторить вызов. Если обмен «висит» в progress часами, разбор упирается в ошибку, которую портал не отдаёт наружу, и дальше надо идти в лог веб-сервера.

Что должно быть в шаблоне регламента обмена?

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

Область действия. Конфигурация и релиз 1С, редакция портала, адреса продуктивной и тестовой площадок, перечень подключённых каналов Telegram.
Состав данных. Таблица «объект 1С → сущность портала → направление → ключ сопоставления». Отдельной строкой – поля, которые не передаются, и причина.
Расписание. Имена регламентных заданий, интервалы, окно технического обслуживания, запрет на обмен во время закрытия месяца.
Правила сопоставления. По какому реквизиту ищется контрагент, что делать при совпадении по телефону и расхождении по ИНН, как помечается заказ-дубль.
Логирование. Где хранятся журналы, глубина хранения, кто имеет к ним доступ, какие события пишутся в журнал регистрации с уровнем «Ошибка».
Мониторинг и алерты. Перечень контролируемых метрик, пороги, адресаты уведомлений, правила подавления шума.
Матрица ответственности и сроки реакции. Кто диагностирует, кто исправляет, кто информирует клиентов, какие сроки считаются нарушением.
Порядок изменений. Любая правка правил обмена проходит через задачу с описанием; удобно опираться на готовый шаблон технического задания для 1С-разработчика, чтобы не ловить расхождения формулировок.
Секреты и доступы. Сервисный пользователь портала, токен бота, периодичность ротации, запрет на хранение токена в коде модуля и в переписке.

Формулировка для раздела 7 (можно копировать). «Отсутствие успешного завершения сеанса обмена типа sale более 60 минут в интервале 09:00–20:00 (МСК) считается инцидентом уровня 1. Бот направляет сообщение в канал «1С-Битрикс-алерты». Администратор 1С подтверждает приём реакцией на сообщение в срок, зафиксированный в регламенте, выполняет диагностику по чек-листу раздела 5 и фиксирует результат в задаче. Если причина на стороне портала, задача эскалируется подрядчику по порталу; при этом менеджеры переходят на ручную регистрацию заказов по инструкции И-04.»

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

Как настроить уведомления в Telegram о сбоях обмена?

Техническая часть простая: HTTP-запрос к Bot API методом POST. Важнее то, что вокруг него – хранение токена, обработка исключения и запись результата в журнал регистрации. Приведённая функция размещается в общем модуле расширения с признаком «Сервер».

// Отправка уведомления в Telegram через Bot API.
// Токен и идентификатор чата читаются из регистра сведений расширения.
Функция ОтправитьСообщениеВTelegram(ТекстСообщения) Экспорт
	
	Настройки = ПараметрыИнтеграцииTelegram();
	
	Если ПустаяСтрока(Настройки.Токен) Тогда
		ЗаписьЖурналаРегистрации("ОбменССайтом.Telegram",
			УровеньЖурналаРегистрации.Ошибка, , ,
			"Не заполнен токен бота в настройках интеграции");
		Возврат Ложь;
	КонецЕсли;
	
	// Формируем тело запроса средствами платформы, без ручной сборки строки
	ЗаписьJSON = Новый ЗаписьJSON;
	ЗаписьJSON.УстановитьСтроку();
	ЗаписьJSON.ЗаписатьНачалоОбъекта();
	ЗаписьJSON.ЗаписатьИмяСвойства("chat_id");
	ЗаписьJSON.ЗаписатьЗначение(Настройки.ИдентификаторЧата);
	ЗаписьJSON.ЗаписатьИмяСвойства("text");
	ЗаписьJSON.ЗаписатьЗначение(ТекстСообщения);
	ЗаписьJSON.ЗаписатьИмяСвойства("disable_web_page_preview");
	ЗаписьJSON.ЗаписатьЗначение(Истина);
	ЗаписьJSON.ЗаписатьКонецОбъекта();
	ТелоЗапроса = ЗаписьJSON.Закрыть();
	
	Соединение = Новый HTTPСоединение("api.telegram.org", 443, , , ,
		30, Новый ЗащищенноеСоединениеOpenSSL);
	
	Запрос = Новый HTTPЗапрос("/bot" + Настройки.Токен + "/sendMessage");
	Запрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	Запрос.УстановитьТелоИзСтроки(ТелоЗапроса, КодировкаТекста.UTF8);
	
	Попытка
		Ответ = Соединение.ОтправитьДляОбработки(Запрос);
	Исключение
		ЗаписьЖурналаРегистрации("ОбменССайтом.Telegram",
			УровеньЖурналаРегистрации.Ошибка, , ,
			ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
		Возврат Ложь;
	КонецПопытки;
	
	Если Ответ.КодСостояния = 200 Тогда
		Возврат Истина;
	КонецЕсли;
	
	// Код 429 означает превышение частоты: Telegram вернёт retry_after в секундах
	ЗаписьЖурналаРегистрации("ОбменССайтом.Telegram",
		УровеньЖурналаРегистрации.Ошибка, , ,
		"Код состояния " + Ответ.КодСостояния + ": " + Ответ.ПолучитьТелоКакСтроку());
	
	Возврат Ложь;
	
КонецФункции

Вторая часть – задание-сторож. Оно выполняет узкую задачу: смотрит, когда последний сеанс завершился успешно, и поднимает тревогу при превышении порога. Сам обмен запускают другие задания. Регистр сведений СостояниеОбменаССайтом здесь создаётся в расширении: периодический, с измерением «ТипОбмена» и ресурсами «Результат» и «Комментарий».

Часто задаваемые вопросы

Нужен ли отдельный регламент, если обмен настроен типовой обработкой?

Да. Типовая обработка закрывает механику передачи, но не отвечает на вопросы о сроках реакции, ответственных и порядке изменений. Минимальная версия документа для типового обмена – разделы 1, 2, 3, 6 и 7, это примерно две страницы.

Сколько разделов должно быть в регламенте обмена?

В предложенном шаблоне девять разделов. Сокращать ниже пяти смысла нет: без состава данных, расписания, логирования, мониторинга и матрицы ответственности документ не поможет при разборе инцидента.

Какой интервал простоя считать инцидентом?

Универсального норматива нет, порог задаёт бизнес. Ориентир из практики: для загрузки заказов в рабочие часы – 30–60 минут, для выгрузки каталога – до конца суток. Главное условие – порог должен быть записан числом и совпадать с настройкой задания-сторожа.

Почему Telegram возвращает код 429?

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

Можно ли принимать команды из Telegram в 1С?

Технически да: через метод getUpdates по опросу из регламентного задания либо через webhook, который требует публично доступного HTTP-сервиса с валидным сертификатом. Для регламента важнее другое – зафиксировать, какие действия боту разрешены, и исключить любые операции, меняющие учётные данные.

Где хранить сам документ?

В системе, где его увидят все участники: база документооборота, корпоративная вики или раздел портала. Требования – версионность, дата последнего пересмотра и ссылка на регламент из описания каждого регламентного задания в комментарии к коду.

Что делать, если портал отвечает `progress` и обмен не завершается?

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

Что в итоге

Ценность регламента обмена 1С с Битрикс24 и Telegram в связке трёх вещей: описанного состава данных, измеримых порогов простоя и конкретных фамилий напротив каждого контура. Сами формулировки документа при этом вторичны. Девять разделов шаблона выше дают такую связку, а задание-сторож с отправкой в Telegram превращает документ в работающий механизм: отклонение фиксируется автоматически, реакция запускается по заранее согласованной схеме. Остальное – дисциплина квартального пересмотра и честный разбор каждого инцидента с правкой документа по его итогам.

Начните с таблицы состава данных и матрицы ответственности: эти два раздела снимают большую часть споров между 1С, порталом и продажами. Затем добавьте мониторинг содержательных метрик, чтобы «тихий ноль» не проходил мимо. Найдите специалиста для решения этой задачи на koderion.ru