После подключения второго расширения перестала открываться форма документа. Ошибка проявлялась не всегда: у одного пользователя форма открывалась, у другого падала после выполнения команды. В конфигурации ничего не меняли, оба расширения по отдельности работали нормально. Разбор занял несколько часов и в итоге свелся к одному методу формы, который оба расширения меняли разными способами.
Чтобы искать такие места заранее можно использовать «Аудитор конфликтов расширений 1С». Обработка выполняет статический анализ выгруженных исходников расширений и формирует список точек, которые стоит проверить до установки, обновления или выявлении причин уже возникших проблем.

Что именно проверяет обработка
Аудитор работает с выгрузками расширений в XML и с файлами модулей .bsl. Он ничего не устанавливает в базу, не выполняет анализируемый код и не изменяет исходные файлы.
В анализ попадают объекты метаданных, формы, реквизиты, табличные части, команды, подписки на события, модули объектов, менеджеров и форм, а также общие модули. Для кода отдельно разбираются процедуры и функции, в том числе изменения через &Перед, &После, &Вместо и &ИзменениеИКонтроль.
Для каждой строки пользователь видит:
- уровень риска;
- объект и конкретное место пересечения;
- имя метода, формы, команды, реквизита или другого элемента;
- какие расширения участвуют;
- каким способом изменяется код;
- почему строка попала в результат;
- что стоит проверить на стенде.
Найденное пересечение не объявляется гарантированной ошибкой. Оно показывает участок, где два расширения могут повлиять друг на друга и где ручная проверка принесет больше пользы, чем просмотр сотен файлов подряд.
Как подготовить расширения к анализу
Обработке нужен общий каталог, внутри которого каждое расширение находится в своей папке. Это обычная выгрузка исходников средствами разработки 1С.
C:\РасширенияДляПроверки\
РасширениеПродаж\
Configuration.xml
Catalogs\
Documents\
CommonModules\
РасширениеДокументооборота\
Configuration.xml
Catalogs\
Documents\
CommonModules\
После выбора каталога остается запустить сканирование. Для крупной выгрузки анализ может занять несколько минут. В тестовом прогоне два расширения содержали 981 файл и 5 556 найденных методов. Полный анализ завершился примерно за две минуты.
По умолчанию включен разбор кода модулей. Его можно отключить, если нужна только проверка XML-метаданных, но в этом случае точные конфликты процедур и функций найдены не будут.
Главная вкладка - «Точки проверки»
Технический анализ формирует гораздо больше данных, чем удобно читать вручную. В тестовом наборе было найдено 2 955 зон влияния и почти две тысячи основных воздействий. Выводить все это в одну таблицу бессмысленно. Можно быстро потеряется в повторяющихся строках по файлам, модулям и объектам.
Поэтому в обычном режиме остается только вкладка «Точки проверки». В ней собраны результаты, по которым действительно можно идти сверху вниз: сначала высокий риск, затем средний.

В текущем тесте обработка сформировала 14 точек:
- 9 высокого риска;
- 5 среднего риска;
- 0 ошибок чтения.
Среди них были изменения одного метода формы, пересечение по общему модулю, подключение к методу, добавленному другим расширением, одинаковые формы, команда, реквизиты, подписка на событие и табличная часть.
Почему недостаточно увидеть только имя модуля
Сообщение «два расширения изменяют модуль формы» полезно только в качестве отправной точки. Дальше все равно приходится открывать оба расширения и искать, пересекаются ли конкретные методы.
Аудитор строит ключ конфликта до уровня целевой процедуры или функции. Например, он может показать, что два расширения работают с методом ПриОткрытии формы элемента одного справочника. Для каждого расширения отдельно выводятся аннотация, имя процедуры расширения, строка объявления и фрагмент кода.

Для &ИзменениеИКонтроль обработка дополнительно показывает первую вставку или удаление. Это помогает быстро понять, куда смотреть. Если метод большой, фрагмент сокращается, а полный путь к исходному файлу остается в технических сведениях.
Отдельно определяется ситуация, когда одно расширение использует &После или другой способ подключения к методу, которого нет в типовой конфигурации, но который добавлен вторым расширением.
Как назначается риск для методов
Уровень риска зависит не только от того, что имя метода совпало. Учитывается сочетание способов изменения.
Высокий риск получают, например, сочетания с &Вместо, несколько изменений через &ИзменениеИКонтроль, а также зависимости от метода другого расширения. Средний риск назначается более мягким сочетаниям, например &Перед и &После.
Результат сопровождается объяснением. Вместе с уровнем риска выводится конкретная причина: несколько расширений критично затрагивают один целевой метод, один обработчик полностью заменяет другой сценарий или расширение зависит от метода, добавленного отдельно.
Пересечения метаданных
Не все проблемы находятся в коде. Два расширения могут добавлять или изменять одну форму, команду, подписку, реквизит или табличную часть. Такие совпадения извлекаются из XML выгрузки.
Для формы риск обычно выше, потому что пересекаются не только визуальные элементы. Внутри формы могут быть команды, обработчики событий и изменения доступности элементов. Для реквизита или табличной части риск чаще средний: важно проверить тип, назначение, обязательность заполнения, состав колонок и использование в коде.

При разборе XML я отдельно исключил служебные элементы формы и команд, которые давали ложные совпадения. Лишние строки только мешали бы разбору, поэтому в итог попадают более значимые пересечения.
Обычный и технический режимы
В обычном режиме пользователю доступны три вкладки: «Точки проверки», «Расширения» и «Ошибки чтения». Этого достаточно для первичного анализа.
Флаг «Показывать технические данные» открывает дополнительные разделы:
- «Найденные изменения» - полный перечень воздействий, включая одиночные;
- «Пересечения метаданных» - технические XML-конфликты;
- «Конфликты методов» - точные совпадения процедур и функций;
- «Методы модулей» - реестр найденных методов;
- «Сводная матрица» - группировка по объектам, зонам и элементам.


Технический режим нужен разработчику, который хочет проверить, как обработка пришла к выводу, посмотреть все воздействия или разобрать конкретный ключ конфликта. Для передачи результата заказчику или руководителю лучше использовать основной список: он короче и понятнее.
Фильтры и поиск
После завершения анализа результаты можно отбирать по расширению, типу объекта, типу результата и уровню риска. Текстовый поиск помогает быстро найти конкретный справочник, форму, метод или команду.
Фильтры не запускают повторное чтение файлов. Можно сначала выполнить полный анализ, затем последовательно разбирать высокий риск, отдельное расширение или нужный объект.
Есть и защитные ограничения: максимальное количество файлов, размер одного файла и время анализа. Они нужны, чтобы случайный выбор большого каталога не превратился в бесконтрольное чтение всего диска.
Экспорт результата
Результат можно вывести в табличный документ. В него попадают общие итоги, точки проверки, сведения по расширениям, ошибки чтения и технические разделы, если они были включены.
Отдельно формируется диагностический отчет. В нем сохраняются параметры запуска, время по этапам, число прочитанных XML и BSL-файлов, сведения о кодировках, количество найденных методов, конфликты и возможные ограничения результата. Такой файл удобно прикладывать при разборе ошибки или передавать разработчику обработки.
Где обработка особенно полезна
Первый сценарий - приемка расширения от другого разработчика. До установки можно увидеть, какие объекты и методы оно пересекает с уже используемыми доработками.
Второй - обновление одного из расширений. Даже если предыдущая версия работала нормально, новый релиз может начать менять форму или метод, который уже затрагивается соседней доработкой.
Третий - подготовка регрессионного тестирования. Вместо общего требования «проверить документооборот» можно собрать конкретный список: открыть форму, выполнить команду, записать объект, проверить подписку и пройти сценарий метода с высоким риском.
Еще один практический случай - несколько подрядчиков. Когда каждый ведет свое расширение, знания о пересечениях часто остаются в переписке или у конкретного специалиста. Аудитор дает общий технический список, который можно сохранить вместе с результатами приемки.
Что остается за пределами анализа
Обработка не читает бинарные файлы .cfe напрямую. Нужны выгруженные исходники.
Статический анализ не знает фактические данные информационной базы, настройки функциональных опций, порядок действий пользователя и все динамические вызовы. Он также не может доказать, что два расширения полностью совместимы.
Обработка находит потенциальные точки конфликта и помогает определить приоритет ручной проверки. После анализа расширения все равно нужно запускать на тестовом стенде.
Безопасность работы
Аудитор работает в режиме чтения относительно выбранных исходников и информационной базы. Он не изменяет файлы, не записывает данные в конфигурацию, не выполняет найденный код, не использует COM, не запускает внешние программы и не отправляет сетевые запросы.
Итог
Когда расширений становится несколько, ручной поиск пересечений быстро упирается в объем исходников. Один и тот же объект может встречаться в десятках XML-файлов, а совпадение по модулю еще не говорит, какой метод затронут.
«Аудитор конфликтов расширений 1С» собирает эти данные в рабочий список: показывает объект, конкретное место, участвующие расширения, способ изменения, уровень риска и рекомендацию. Разработчик получает понятную карту мест, которые нужно проверить до релиза, без обещаний автоматической совместимости.
Проверено на следующих конфигурациях и релизах:
- Документооборот КОРП, релизы 2.1.37.5
- Бухгалтерия предприятия КОРП, редакция 3.0, релизы 3.0.201.24
- Управление нашей фирмой, редакция 3.0, релизы 3.0.13.374
Вступайте в нашу телеграмм-группу Инфостарт