Обновление нетиповой конфигурации 1С — это всегда ответственный процесс, требующий внимательного анализа зависимостей. Одна из самых острых проблем заключается в том, что разработчики фирмы «1С» в новых релизах могут изменять названия процедур, состав их параметров или вовсе удалять устаревшие функции. Если ваш доработанный код обращается к таким методам, после обновления система выдаст ошибку в самый неподходящий момент. Рассмотрим подробно, как выявить такие связи и минимизировать риски.
Этот метод основан на использовании штатного механизма поиска неиспользуемых процедур. Разберем по шагам, как превратить этот инструмент в средство поиска зависимостей:
Проанализируем логику: если после ваших доработок количество «неиспользуемых» функций уменьшилось по сравнению с чисто типовой конфигурацией, значит, именно эти «недостающие» в списке функции вы и используете в своем коде. Это позволяет локализовать список критичных вызовов.
Если нам нужно максимально быстро понять, от чего зависит конкретный добавленный модуль или обработка, воспользуемся методом временного удаления. Выполним следующие действия:
Ctrl + F7) или попробуем сохранить конфигурацию (F7).Рассмотрим пример ситуации: у вас есть добавленная кнопка в типовой форме, которая вызывает функцию ОбщегоНазначения.ОпределитьСтатусДокумента(). При удалении общего модуля ОбщегоНазначения конфигуратор сразу подсветит это место как ошибку.
Современный подход подразумевает использование среды EDT, которая строит полный индекс проекта и позволяет работать с графом вызовов. Выясним, почему это удобнее стандартного Конфигуратора:
В EDT мы можем воспользоваться функцией Find References (Поиск ссылок) или Call Hierarchy (Иерархия вызовов). Выделив измененный модуль, мы увидим все исходящие вызовы в типовые модули. Проанализируем преимущества:
Для глубокого анализа зависимостей часто эффективнее работать не с бинарным файлом конфигурации, а с текстовым представлением кода. Разберем этот алгоритм:
ИмяВашегоМодуля\. или обращения к стандартным библиотекам.Проанализируем ситуацию с помощью Git. Если вести разработку в репозитории, то при слиянии (merge) нового типового релиза с вашей веткой, инструменты контроля версий наглядно покажут конфликты в тех местах, где типовой код изменился, а ваш код на него опирается.
Самый правильный стратегический путь — это вынос всех доработок в Расширения конфигурации. Рассмотрим, как это помогает при обновлениях:
Когда мы используем расширение, мы можем перехватывать вызовы типовых функций с помощью аннотаций &Вместо, &Перед или &После. Посмотрим на пример кода в расширении:
&После("ЗаполнитьРеквизитыПродажи")
Процедура Мой_ЗаполнитьРеквизитыПродажи(Параметры)
// Наша логика, которая опирается на типовой контекст
Если Параметры.Свойство("СпецУсловие") Тогда
// Действие
КонецЕсли;
КонецПроцедуры
После наката обновления основной конфигурации в 1С есть штатный механизм: Конфигурация — Расширения конфигурации — Проверить применимость. Система сама проанализирует, не изменилась ли сигнатура (название или параметры) типовой процедуры ЗаполнитьРеквизитыПродажи. Если изменения критичны, расширение просто не применится, и вы получите четкий список мест, требующих адаптации.
Не стоит забывать и о самом простом, но действенном методе. Сразу после того, как вы объединили конфигурации (выполнили Сравнение/Объединение):
Важный момент: синтаксический контроль не всегда ловит ошибки в динамических вызовах (например, через Выполнить() или Вычислить()), поэтому ручной анализ критических узлов всё равно необходим.
Для качественного обновления нетиповой конфигурации мы рекомендуем комбинированный подход: используйте расширения для изоляции своего кода, EDT для быстрого анализа связей и обязательную полную проверку конфигурации после каждого этапа обновления. Это позволит избежать ситуаций, когда после обновления пользователи сталкиваются с ошибками вида {ОбщийМодуль...}: Процедура или функция с указанным именем не определена.