Восстановление Bitrix24: молча вставший обмен с 1С и данные, которым не верили

Я принял портал Bitrix24, с которым до меня работали несколько команд подрядчиков. Обмен с 1С молча встал. Я провёл аудит, нашёл первопричины и навёл порядок в данных — скрипты аудита и код писали ИИ-агенты, решения и боевые шаги были мои.

~1.8Mзаписей в очереди для неработающих адресов — очередь разобрана (сентябрь 2026)
159 → 54подписок на события, мёртвые удалены с бэкапом
1,659 → 681карточек штучного товара после чистки фантомов

Меньше созвонов и разрозненной переписки — единые данные для планирования

Было
У дистрибьютора медтехники коммуникации были разрознены: не было цепочки взаимодействия, много лишних созвонов, не было единой базы актуальных данных, отслеживания и прогноза.
Сделал
С середины 2024 года внедрял корпоративный портал Bitrix24 — сначала вместе с подрядчиком, затем взял внедрение на себя: настроил процессы, автоматические действия, мобильные рабочие места, инструкции для каждой роли.
Стало
Работа стала видимой и отслеживаемой, у каждого сотрудника — понятные задачи и своя инструкция. По моей оценке, складские остатки снизились более чем вдвое; сейчас деньги в обороте, планирование стало возможным.

Обмен CRM с бухгалтерской системой восстановлен: очередь из ~1,8 млн записей разобрана

Было
В 2026 году обмен между порталом и учётной системой 1С был нарушен: очередь на отправку заполнялась записями для старых, неработающих адресов и росла примерно на 50 тысяч в день.
Сделал
Провёл аудит вместе с ИИ-агентами — по моим задачам они искали причину и писали скрипты; решения и действия на рабочей системе — мои: убрал неработающие подписки с резервной копией, настроил передачу в учёт только завершённых документов.
Стало
Обмен снова работает (проверено опросом со стороны 1С); в учёт передаются только завершённые сделки, заявки, приёмки и отгрузки.

Контекст и масштаб

Коробочный Bitrix24: продажи, закупки, склад и сервис на смарт-процессах, ~30 приложений портала и модули подрядчиков; обмен с 1С:УНФ через закрытый коннектор. Документированный период: август–октябрь 2026.

Задача

1,88 млн событий стояли в очереди на мёртвые адреса 1С и росли на ~50 тыс. в сутки; три параллельных канала Bitrix24 → 1С; авария породила 329 тыс. пустых элементов и ~358 тыс. незавершённых процессов; 1659 фантомных карточек штучного товара; приёмки связаны со сделкой в 5 случаях из 176.

Анализ и альтернативы

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

Ключевые решения и компромиссы

  1. Снять мёртвые подписки, а не переигрывать. События для адресов, которые никто не читает, ценности не несут. Бэкап снятых подписок оставляет шаг обратимым.
  2. В 1С — только готовые документы. Свой фильтр: сделки, заявки, приёмки и отгрузки уходят в учёт только готовыми или проведёнными. Меньше конфликтов ценой чуть более позднего появления данных в 1С.
  3. Корзина вместо удаления. Сначала сухой прогон, перепроверка условия перед каждой записью, JSON-бэкап; 14 карточек оставлены — на них ссылались живые сделки.

Что сделано

  • Подписки 159 → 54; очередь пуста, новые события забираются сразу; исправлена потеря событий в обработчиках.
  • Фантомы 1659 → 681 (978 в корзину), карточек «без склада» 1079 → 101, фантомных резервов 16 → 0, сверка склада с документами прихода и откатом.
  • Последствия аварии разобраны: процессов ~358 тыс. → 2,5 тыс., пустых элементов 329 тыс. → 529.
  • Синхронизация договор ↔ сделка в обе стороны, воронка из 5 фаз и отчёт руководителю, стадия приёмки при проведении, страница здоровья портала.
  • Рабочие места сервиса и склада с мобильными PWA, маршруты, инвентаризация, автоприёмки.

Результат

Обмен с 1С снова работает и несёт только готовые документы; склад сверен с документами прихода, у каждого шага есть откат.

Как проверено

До исправления размер очереди замерен дважды с интервалом 45 с; после — живой опрос 1С и пакетные проверки; каждому удалению предшествовал сухой прогон, всё записано с бэкапом. Сам аудит проверен независимым LLM-судьёй.

Что сделал бы иначе

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