Почему обмен между Bitrix24 и 1С перестаёт работать: основные причины и что делать

Интеграция Bitrix24 и 1С может стабильно работать месяцами, а затем внезапно начать давать сбои.

Менеджеры замечают, что:

• оплаты перестали появляться в CRM;
• новый заказ не создаётся в 1С;
• товары перестали обновляться;
• остатки показываются неправильно;
• клиенты дублируются;
• документы передаются с задержкой;
• часть сделок синхронизируется, а часть — нет.

Иногда проблема проявляется ещё опаснее: обмен формально работает, но передаёт неполные или устаревшие данные.

В результате сотрудники перестают доверять интеграции и возвращаются к ручной работе:

• проверяют оплату у бухгалтера;
• отправляют номера заказов через WhatsApp;
• повторно вводят информацию;
• сверяют остатки вручную;
• ведут дополнительные Excel-таблицы.

На этом этапе компания фактически теряет главное преимущество интеграции.

Почему так происходит?

Потому что интеграция Bitrix24 и 1С — это не один раз установленный «мост» между системами. Это работающий цифровой процесс, который зависит от конфигурации 1С, настроек Bitrix24, данных, серверов, прав доступа, бизнес-логики и действий пользователей.

Разберём основные причины, почему обмен между Bitrix24 и 1С перестаёт работать, как определить источник проблемы и когда интеграцию лучше не ремонтировать точечно, а провести полноценный аудит.

Как понять, что обмен Bitrix24 и 1С работает неправильно

Полная остановка обмена — только один из возможных симптомов.

Гораздо чаще интеграция продолжает работать частично.

Например:

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

Поэтому проблема может долго оставаться незаметной.

Основные признаки неисправности

Стоит проверить интеграцию, если:

• данные Bitrix24 и 1С регулярно расходятся;
• сотрудники стали чаще уточнять информацию вручную;
• сделки зависают на стадиях;
• появляются дубли;
• остатки вызывают сомнения;
• оплаты отображаются с большой задержкой;
• некоторые документы приходится создавать вручную;
• после обновления одной из систем появились ошибки;
• пользователи жалуются, что «раньше работало»;
• никто не может объяснить причину ошибки.

Особенно опасен последний сценарий.

Если интеграция не имеет нормальной диагностики и журналирования, даже небольшая проблема превращается в длительное расследование.

Причина №1. Обновилась конфигурация 1С

Одна из распространённых причин — изменение конфигурации 1С.

Компания обновляет:

• платформу;
• конфигурацию;
• релиз;
• отдельный модуль;
• расширение.

После этого может измениться:

• структура объектов;
• состав реквизитов;
• правила проведения документов;
• доступность методов;
• поведение справочников;
• механизм обмена.

Интеграция, разработанная под предыдущую структуру, может перестать корректно обращаться к нужным данным.

Как проявляется проблема

Например:

• документы больше не создаются;
• часть полей остаётся пустой;
• товары не обновляются;
• появляются системные ошибки;
• обмен останавливается после определённого объекта.

Что делать

Перед обновлением бизнес-критичной конфигурации желательно проверять совместимость интеграции.

После обновления необходимо провести тест:

• создание клиента;
• создание заказа;
• передачу товаров;
• оплату;
• отгрузку;
• изменение документа;
• повторную синхронизацию.

Для сложных проектов обновление сначала лучше проверять на тестовой копии.

Причина №2. Была выполнена доработка 1С

Даже если версия системы не менялась, программист мог доработать конфигурацию.

Например:

• изменить документ заказа;
• добавить обязательное поле;
• изменить алгоритм цены;
• добавить новый вид договора;
• изменить структуру номенклатуры;
• доработать проведение документа.

Для пользователя это может выглядеть как небольшое изменение.

Для интеграции оно может быть критичным.

Пример

Раньше заказ клиента можно было создать без указания конкретного склада.

После доработки склад становится обязательным.

Bitrix24 продолжает отправлять старый набор данных.

В результате заказ перестаёт создаваться.

Как избежать

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

Это требует документации:

• какие объекты участвуют;
• какие поля передаются;
• какие проверки выполняются;
• какие события запускают обмен.

Если документации нет, даже небольшая доработка превращается в риск.

Причина №3. Изменились настройки Bitrix24

Проблема может находиться не в 1С, а на стороне CRM.

Например:

• переименовали поле;
• удалили пользовательское поле;
• изменили тип поля;
• поменяли стадии;
• создали новую воронку;
• изменили карточку;
• отключили робота;
• поменяли права доступа.

Если интеграция использует конкретный идентификатор поля или стадию, изменение может нарушить сценарий.

Пример

Заказ передавался в 1С только после перехода сделки в статус:

«Договор подписан».

Администратор перестроил воронку и удалил этот этап.

Автоматический запуск больше не происходит.

С технической точки зрения интеграция исправна.

Но бизнес-сценарий перестал запускаться.

Причина №4. Истёк или изменился доступ к Bitrix24

Для обмена используются учётные данные, токены, вебхуки или другие механизмы авторизации.

Доступ может перестать работать после:

• изменения пользователя;
• увольнения сотрудника;
• изменения пароля;
• отключения учётной записи;
• изменения прав;
• удаления интеграционного подключения;
• изменения политики безопасности.

Как проявляется проблема

Интеграция начинает получать ошибки доступа.

При этом пользователям может казаться, что проблема находится в 1С.

Что делать

Нужно проверить:

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

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

Причина №5. Изменились права пользователя в 1С

Аналогичная ситуация может возникнуть на стороне 1С.

Интеграция работает под определённым пользователем.

После изменения ролей он может потерять доступ:

• к справочнику;
• к документу;
• к складу;
• к организации;
• к проведению;
• к чтению определённых данных.

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

Это объясняет ситуацию:

«Клиенты передаются, а заказы почему-то перестали».

Причина №6. Изменились реквизиты или структура данных

Интеграция строится на определённых правилах сопоставления.

Например:

• БИН клиента;
• внутренний ID;
• код товара;
• GUID;
• номер заказа;
• артикул.

Если сотрудники изменили структуру данных, связь может нарушиться.

Пример

Раньше товар идентифицировался по уникальному коду.

После переноса базы часть кодов изменилась.

Bitrix24 больше не находит существующие позиции и начинает:

• создавать новые;
• выдавать ошибки;
• пропускать товар.

Причина №7. Появились дубли

Дубли — не только проблема качества CRM.

Они способны нарушить автоматический обмен.

Представим, что в 1С существуют два контрагента:

• ТОО «Альфа»;
• Альфа ТОО.

Оба имеют похожие контактные данные.

При попытке передать заказ интеграция не всегда может однозначно определить нужного контрагента.

Аналогичные проблемы возникают с:

• контактами;
• номенклатурой;
• договорами;
• заказами.

Что делать

Необходимо установить правила идентификации и провести очистку.

Особенно важно использовать устойчивые системные ID после первичного сопоставления.

Причина №8. В 1С появились новые обязательные поля

Это особенно характерно для доработанных конфигураций.

Например, теперь для заказа обязательно нужно указать:

• подразделение;
• склад;
• договор;
• проект;
• вид цены;
• менеджера;
• организацию;
• источник финансирования.

Bitrix24 эти данные не передаёт.

Документ не создаётся.

Что делать

Нужно синхронизировать бизнес-логику.

Есть два варианта:

Передавать новое поле из Bitrix24

Если значение должен определять менеджер.

Определять значение автоматически в 1С

Если оно рассчитывается по правилам.

Самое опасное решение — вручную исправлять каждый не прошедший заказ.

Это маскирует проблему, но не устраняет её.

Причина №9. Изменился бизнес-процесс

Интеграция может технически продолжать работать, но перестать соответствовать реальной компании.

Например, раньше процесс был:

сделка → счёт → оплата → отгрузка.

Затем появилась предварительная заявка, согласование технологом и предоплата.

Новый процесс:

сделка → технический расчёт → согласование → договор → предоплата → производство → отгрузка.

Старая интеграция уже не знает:

• когда создавать заказ;
• какие данные обязательны;
• когда запускать производство;
• когда считать заказ готовым.

Результат

Сотрудники начинают обходить автоматизацию.

Это важный сигнал:

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

Причина №10. Слишком сложная двусторонняя синхронизация

Иногда интеграция построена по принципу:

«Пусть всё синхронизируется во все стороны».

Клиента можно редактировать в обеих системах.

Заказ тоже.

Цена меняется и там, и там.

Такой сценарий значительно увеличивает вероятность конфликтов.

Возможные проблемы

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

Правильный принцип

Для каждого типа информации нужно определить владельца.

Например:

CRM → клиентские коммуникации.
1С → цены и остатки.
CRM → коммерческий заказ.
1С → оплата и отгрузка.

Чем чётче ответственность, тем стабильнее обмен.

Причина №11. Изменился каталог товаров

Номенклатура — один из наиболее сложных объектов синхронизации.

Проблемы возникают после:

• изменения структуры групп;
• объединения позиций;
• удаления товаров;
• изменения артикулов;
• изменения характеристик;
• изменения единиц измерения;
• появления вариантов.

Пример

Раньше товар существовал как одна позиция:

Профиль металлический.

Затем в 1С появились характеристики:

• 2 метра;
• 3 метра;
• 6 метров.

Старая интеграция не умеет работать с вариантами.

Синхронизация начинает выдавать ошибки либо создавать неправильные товары.

Причина №12. Возрос объём данных

Интеграция, успешно работавшая при 1 000 товарах, может столкнуться с проблемами после роста каталога до 100 000 позиций.

То же касается:

• клиентов;
• заказов;
• платежей;
• складов;
• истории.

Возможные последствия

• обмен занимает слишком много времени;
• запросы завершаются по тайм-ауту;
• задания начинают пересекаться;
• сервер 1С перегружается;
• данные обновляются с большой задержкой.

Решение

Архитектуру необходимо масштабировать:

• передавать только изменения;
• использовать очереди;
• разбивать данные на пакеты;
• оптимизировать запросы;
• ограничивать ненужные объекты;
• корректировать расписание.

Причина №13. Перегружен сервер 1С

Обмен может замедляться или завершаться ошибками, если сервер:

• испытывает высокую нагрузку;
• не имеет достаточных ресурсов;
• выполняет тяжёлые фоновые задания;
• обслуживает большое количество пользователей.

Проблема может проявляться только в определённые часы.

Например:

днём обмен работает нестабильно, а ночью выполняется нормально.

Это важный диагностический признак.

Причина №14. Проблемы с сетью и интернетом

Если 1С работает внутри локальной инфраструктуры, а Bitrix24 находится в облаке, между системами должен существовать стабильный канал связи.

Сбои могут возникнуть из-за:

• интернета;
• VPN;
• маршрутизации;
• прокси;
• DNS;
• firewall;
• изменения сетевых правил.

В результате:

• часть запросов проходит;
• часть теряется;
• соединение периодически обрывается;
• обмен занимает слишком много времени.

Причина №15. Изменился адрес сервера

Компания могла:

• перенести 1С;
• сменить сервер;
• поменять домен;
• изменить IP;
• переехать в облако;
• изменить публикацию базы.

Если интеграция использовала старый адрес, обмен прекращается.

Это часто происходит после инфраструктурных работ, о которых команда интеграции просто не была уведомлена.

Причина №16. Проблемы SSL-сертификата

При защищённом соединении могут возникать ошибки сертификата.

Например:

• сертификат истёк;
• установлен новый;
• изменена цепочка доверия;
• неправильно настроен HTTPS.

Сайт или 1С могут визуально продолжать работать для пользователя, но программный обмен будет отклонять соединение.

Причина №17. Firewall блокирует запросы

После усиления безопасности системный администратор может закрыть:

• порт;
• IP;
• внешнее подключение;
• определённый тип запросов.

В результате Bitrix24 больше не может обращаться к интеграционному сервису или наоборот.

Поэтому изменения инфраструктуры необходимо согласовывать с владельцем интеграции.

Причина №18. Фоновое задание перестало выполняться

Некоторые сценарии обмена запускаются по расписанию.

Например:

• каждые пять минут;
• раз в час;
• ночью.

Фоновое задание может:

• отключиться;
• зависнуть;
• завершиться ошибкой;
• не запускаться после перезагрузки;
• конфликтовать с другим заданием.

Как проявляется

Данные вроде бы передаются, но только после ручного запуска.

Это важный диагностический признак.

Причина №19. Ошибка одного объекта останавливает весь пакет

Слабая архитектура может передавать большой набор данных одной операцией.

Если одна позиция содержит неправильное значение, весь пакет отклоняется.

Например:

из 1 000 товаров 999 корректны, но у одного отсутствует единица измерения.

Вместо передачи 999 позиций обмен полностью останавливается.

Более устойчивый вариант

Интеграция должна:

• зафиксировать ошибочную запись;
• продолжить обработку допустимых данных;
• уведомить ответственного;
• позволить повторить только проблемный объект.

Причина №20. Ошибки не контролируются

Самая опасная проблема — не само наличие ошибок.

Ошибки неизбежны в любой сложной системе.

Проблема возникает, когда никто о них не знает.

Например:

в 14:32 заказ не передался.

Пользователь увидел зелёную стадию и решил, что всё успешно.

Производство заказ не получило.

Через три дня клиент спрашивает о готовности.

Только тогда начинается расследование.

Правильный подход

Для важных операций должны существовать:

• статус передачи;
• журнал;
• уведомление;
• повторная попытка;
• эскалация.

Причина №21. Нет очереди повторной отправки

Допустим, в момент передачи 1С была недоступна пять минут.

Если интеграция просто фиксирует ошибку и останавливается, заказ останется непереданным.

Более надёжная система должна:

1. сохранить операцию;
2. повторить попытку;
3. контролировать количество попыток;
4. уведомить ответственного, если проблема сохраняется.

Так кратковременный технический сбой не превращается в потерянный заказ.

Причина №22. Пользователь вручную вмешался в связанный документ

После синхронизации сотрудник может:

• изменить заказ;
• удалить его;
• изменить номер;
• изменить клиента;
• сменить организацию;
• отменить проведение.

Связь между системами нарушается.

Особенно опасно, когда пользователи не понимают, какие поля участвуют в обмене.

Решение

Необходимо:

• ограничить отдельные действия;
• описать правила;
• обучить пользователей;
• логировать изменения.

Причина №23. Один из связанных объектов был удалён

Например:

• компания удалена в Bitrix24;
• контрагент помечен на удаление в 1С;
• товар деактивирован;
• договор закрыт.

Связанная запись другой системы продолжает существовать.

При следующей синхронизации возникает ошибка.

Интеграция должна иметь правила обработки:

• удаления;
• архивирования;
• деактивации;
• восстановления.

Причина №24. Слишком много ручных исключений

В начале компания создаёт автоматизированный процесс.

Постепенно появляются пожелания:

• для клиента А делать иначе;
• для менеджера Б не запускать робота;
• этот товар передавать по другой схеме;
• этот склад исключить;
• для такого договора использовать специальное правило.

Через несколько лет интеграция превращается в десятки исключений.

Последствия

• сложно тестировать;
• сложно обновлять;
• изменение одного правила ломает другое;
• никто не понимает всю архитектуру.

Что делать

Периодически проводить рефакторинг:

• удалить неактуальные исключения;
• унифицировать правила;
• упростить процесс;
• обновить документацию.

Причина №25. Интеграцию никто не сопровождает

Типичная ситуация:

интегратор внедрил решение несколько лет назад.

После запуска:

• разработчик ушёл;
• документации нет;
• 1С несколько раз доработали;
• Bitrix24 перестроили;
• появились новые подразделения.

При этом обмен продолжает работать «как-то».

До первого серьёзного сбоя.

Интеграция — это живой цифровой продукт

У неё должен быть владелец.

Необходимо контролировать:

• работоспособность;
• ошибки;
• изменения систем;
• обновления;
• производительность;
• документацию.

Что делать, если обмен уже перестал работать

Не стоит сразу переписывать интеграцию с нуля.

Сначала необходимо провести диагностику.

Шаг 1. Определить масштаб проблемы

Нужно понять:

• обмен полностью остановился;
• не работает один объект;
• проблема появляется периодически;
• затронуты все пользователи;
• проблема относится к одному подразделению;
• ошибка появилась после определённого события.

Чем точнее симптом, тем быстрее диагностика.

Шаг 2. Определить последнее успешное событие

Например:

последний успешный заказ передался в 11:43.

Следующий в 11:48 уже не прошёл.

Нужно определить, что произошло между этими событиями:

• обновление;
• изменение настроек;
• перезапуск сервера;
• изменение прав;
• новый тип заказа;
• нестандартный клиент.

Шаг 3. Проверить журнал обмена

Журнал должен показать:

• время;
• объект;
• направление;
• запрос;
• результат;
• код ошибки;
• ответ системы.

Если журнал отсутствует — это уже отдельная проблема архитектуры.

Шаг 4. Проверить доступность систем

Необходимо проверить:

• Bitrix24;
• сервер 1С;
• публикацию;
• API;
• интернет;
• сертификаты;
• firewall.

Шаг 5. Проверить конкретный проблемный объект

Иногда интеграция работает, но конкретный заказ содержит некорректные данные.

Например:

• пустой БИН;
• неправильный товар;
• закрытый договор;
• отсутствующий склад.

Нужно сравнить проблемный объект с успешно переданным.

Шаг 6. Проверить изменения последних дней

Полезно составить список:

• обновлений;
• доработок;
• изменений прав;
• новых пользователей;
• изменений CRM;
• изменений серверов.

Очень часто причина находится именно здесь.

Шаг 7. Восстановить обмен и повторить операции

После устранения причины нужно определить, какие данные не были переданы во время сбоя.

Например:

• 27 заказов;
• 14 оплат;
• 600 обновлений остатков.

Их необходимо безопасно передать повторно без создания дублей.

Почему нельзя просто нажать «синхронизировать всё»

Массовый повторный обмен после сбоя может создать дополнительные проблемы:

• дубли;
• старые данные перезапишут новые;
• изменятся статусы;
• повторно создадутся документы;
• возникнет высокая нагрузка.

Восстановление должно выполняться контролируемо.

Как предотвратить остановку обмена

Полностью исключить технические ошибки невозможно.

Но можно сделать их управляемыми.

1. Вести журнал обмена

Должно быть понятно, что произошло с каждой критичной операцией.

2. Использовать уведомления

При серьёзной ошибке ответственный получает сообщение.

3. Настроить повторные попытки

Кратковременный сбой не должен приводить к потере данных.

4. Использовать уникальные идентификаторы

Повторная отправка не должна создавать дубли.

5. Создать тестовый контур

Обновления сначала проверяются там.

6. Документировать архитектуру

Нужно знать:

• какие объекты связаны;
• кто владелец данных;
• какие поля участвуют;
• как запускается обмен.

7. Согласовывать изменения

IT-специалисты должны понимать, какие объекты нельзя менять без проверки интеграции.

8. Проводить периодический аудит

Особенно после значительных изменений компании.

Мониторинг интеграции: что стоит контролировать

Для критичной интеграции полезно отслеживать:

• время последнего успешного обмена;
• количество успешных операций;
• количество ошибок;
• количество записей в очереди;
• длительность синхронизации;
• повторные попытки;
• недоступность систем.

Можно настроить уведомления:

«За последние 30 минут не передано ни одного заказа».

Или:

«В очереди накопилось более 20 ошибок».

Тогда проблема обнаруживается системой, а не клиентом.

Когда достаточно ремонта, а когда лучше перепроектировать интеграцию

Не каждый сбой требует нового проекта.

Достаточно локального исправления, если

• проблема появилась после обновления;
• известна конкретная ошибка;
• архитектура остаётся актуальной;
• документация существует;
• процессы практически не изменились.

Лучше провести аудит и перепроектирование, если

• интеграции несколько лет;
• документации нет;
• никто не знает архитектуру;
• 1С сильно доработана;
• структура Bitrix24 изменилась;
• появился новый бизнес;
• много ручных исключений;
• сотрудники не доверяют данным;
• ошибки возникают регулярно.

В этом случае постоянный ремонт отдельных симптомов может стоить дороже, чем системное исправление.

Как проходит аудит обмена Bitrix24 и 1С

В Profi Soft аудит можно разделить на несколько блоков.

1. Анализ бизнес-процесса

Изучаем путь:

клиент → сделка → заказ → счёт → оплата → исполнение → отгрузка.

2. Анализ Bitrix24

Проверяем:

• воронки;
• поля;
• роботов;
• пользователей;
• права;
• карточки;
• связи объектов.

3. Анализ 1С

Проверяем:

• конфигурацию;
• версию;
• доработки;
• справочники;
• документы;
• права;
• фоновые задания.

4. Анализ архитектуры обмена

Определяем:

• объекты;
• направления;
• идентификаторы;
• события;
• расписание;
• правила сопоставления.

5. Анализ ошибок

Изучаем:

• журналы;
• повторяющиеся сбои;
• проблемные данные;
• потерянные операции.

6. Сценарное тестирование

Проверяем:

• клиента;
• заказ;
• частичную оплату;
• отгрузку;
• возврат;
• изменение заказа;
• повторную отправку;
• недоступность системы.

7. Подготовка плана исправлений

Задачи разделяются на:

Критические

Влияют на деньги, заказы и клиентов.

Важные

Увеличивают ручную работу и риск ошибок.

Развивающие

Повышают удобство, аналитику и автоматизацию.

Что получает компания после аудита

Результатом может стать:

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

Компания понимает не только:

«почему сегодня не передался заказ»,

но и:

«что необходимо изменить, чтобы проблема не повторялась».

Как Profi Soft восстанавливает обмен Bitrix24 и 1С

Profi Soft работает с интеграцией как с частью единого бизнес-процесса.

Мы можем:

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

Если текущая архитектура устарела, мы можем спроектировать новую схему обмена.

Когда компании особенно нужен аудит интеграции

Провести аудит стоит, если:

• обмен периодически останавливается;
• никто не понимает причины;
• после обновлений возникают сбои;
• сотрудники вводят данные вручную;
• CRM и 1С показывают разные цифры;
• появляются дубли;
• заказы теряются;
• интеграция была создана несколько лет назад;
• подрядчик больше не сопровождает проект;
• отсутствует документация;
• компания существенно выросла.

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

Главный вывод

Интеграция Bitrix24 и 1С редко перестаёт работать «сама по себе».

Почти всегда что-то изменилось:

• версия;
• конфигурация;
• права;
• данные;
• сервер;
• бизнес-процесс;
• структура CRM.

Если обмен является критичным для продаж и производства, компания должна относиться к нему не как к однажды установленному модулю, а как к полноценной части цифровой инфраструктуры.

Надёжная интеграция — это не интеграция без ошибок.

Это система, которая:

• обнаруживает ошибку;
• фиксирует её;
• уведомляет ответственного;
• не теряет данные;
• безопасно повторяет операцию;
• позволяет быстро определить причину.

Закажите диагностику обмена Bitrix24 и 1С

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

Сначала необходимо определить реальную причину.

Команда Profi Soft проведёт аудит существующей интеграции и проверит:

• Bitrix24;
• 1С;
• бизнес-процесс;
• объекты обмена;
• права;
• журнал ошибок;
• настройки;
• инфраструктуру;
• пользовательские сценарии.

По результатам вы получите:

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

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

Чек-лист: что проверить, если Bitrix24 перестал обмениваться с 1С

Проверьте:

• обновлялась ли 1С;
• выполнялись ли доработки;
• менялись ли настройки Bitrix24;
• активна ли техническая учётная запись;
• изменялись ли права;
• доступен ли сервер;
• работает ли интернет;
• действителен ли SSL-сертификат;
• не изменился ли адрес сервера;
• выполняются ли фоновые задания;
• есть ли ошибки в журнале;
• изменялась ли номенклатура;
• появились ли новые обязательные поля;
• не накопились ли дубли;
• работает ли повторная отправка;
• нет ли очереди непереданных объектов.

Этот список не заменяет техническую диагностику, но помогает быстро определить направление поиска.

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

Почему Bitrix24 перестал передавать заказы в 1С?

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

Почему часть заказов передаётся, а часть нет?

Часто проблема находится в данных конкретного заказа: клиенте, реквизитах, товаре, договоре, складе или другом обязательном поле.

Почему после обновления 1С перестала работать интеграция?

Обновление могло изменить объекты, структуру данных, алгоритмы или интерфейсы, на которые опирался обмен.

Можно ли восстановить интеграцию без полной переделки?

Во многих случаях да. Сначала проводится диагностика и определяется конкретная причина сбоя.

Почему не обновляются оплаты?

Необходимо проверить документы оплаты в 1С, правила привязки к заказу, запуск обмена и журнал ошибок.

Что делать с заказами, которые не передались во время сбоя?

После восстановления нужно определить потерянные операции и безопасно повторить передачу с защитой от дублей.

Как узнать, работает ли обмен прямо сейчас?

Для надёжной интеграции должен существовать журнал и контроль времени последней успешной операции. Также можно настроить автоматический мониторинг.

Кто должен контролировать обмен?

Желательно назначить технического владельца интеграции и владельца бизнес-процесса. Для критичных ошибок должны работать автоматические уведомления.

Нужно ли проверять интеграцию после каждого обновления?

Если обновление затрагивает используемые объекты, модули или инфраструктуру, сценарное тестирование желательно провести до промышленного запуска.

С чего начать диагностику?

С определения последнего успешного обмена, анализа журнала ошибок и проверки изменений, которые произошли непосредственно перед появлением проблемы.