При обновлении эта сторона в работе ERP особенно опасна: ошибка закрытия месяца
В процессе тестирования закрытия месяца в обновленной базе выполнение операции «Актуализация движений документов по данным взаиморасчетов» прерывалось ошибкой: «Временная таблица уже существует "ВтРучныеКорректировки"»
Данная исключительная ситуация блокировала выполнение указанного этапа и делала невозможным переход к последующим операциям закрытия месяца.
Слабое звено &Вместо
Для локализации проблемы был применен метод пошаговой отладки процедур закрытия месяца в контексте расширений. Установлено, что в обновленной базе в методе ВзаиморасчетыСервер.Выполнить_ФормированиеДвиженийПоРасчетамСПартнерамиИПереоценкаРасчетов переменная ТребуетсяПереоценка принимает значение Истина, а в базе до обновления — Ложь:
Из-за этого отладка в обновленной базе заходит в цикл “Пока НачалоРасчета <= ПараметрыОбработчика.ПараметрыРасчета.КонецПериода”, а в базе до обновления — нет, но именно в этом цикле и вызывается метод ОперативныеВзаиморасчетыСервер.ИсправитьРазвернутоеСальдо, расширенный аннотацией &Вместо, который и содержит ошибку.
Первичный анализ указывал на два вероятных источника различий: нарушение целостности данных после реструктуризации БД, так как после первого обновления выявились ошибки в данных и пришлось переобновлять тестовую базу, или новые типовые проверки в механизме закрытия месяца.
Но также в процессе отладки общих модулей мы заметили, что текст расширенного метода ИсправитьРазвернутоеСальдо напоминает текст другого типового метода, который тоже выполняется на данном этапе закрытия и выяснилось, что расширенный метод не являлся уникальной разработкой, а представлял собой некомментированную копию типовой процедуры ИсправитьОстаткиВзаиморасчетов с внесенными изменениями.
То есть после доработок клиента один метод выполнялся дважды, так как в типовом коде сначала вызывается метод ИсправитьОстаткиВзаиморасчетов, а сразу после ИсправитьРазвернутоеСальдо.
Проблема заключалась в том, что расширенный метод остался необновленным. Поскольку имя процедуры в расширении ИсправитьРазвернутоеСальдо не совпадало с именем фактически скопированного метода ИсправитьОстаткиВзаиморасчетов и не было никаких комментариев, оснований предполагать, что метод является копией другого метода, не было.
Как оказалось, в релизе 1С:ERP 2.5.22.129 в процедуре ИсправитьОстаткиВзаиморасчетов добавили текст уничтожения временной таблицы ВтРучныеКорректировки:
После обновления типовой код стал вызывать последовательно сначала актуализированный метод ИсправитьОстаткиВзаиморасчетов, а затем неактуальный расширенный метод ИсправитьРазвернутоеСальдо, в котором текст уничтожения ВТ отсутствует, что и вызывало конфликт имен временных таблиц.
Решение оказалось простым: код метода в расширении был обновлен в соответствии с актуальной типовой логикой ИсправитьОстаткиВзаиморасчетов из релиза 2.5.22.129, с последующим перенесением доработок клиента.
После приведения расширенного метода в соответствие с архитектурой релиза 2.5.22.129 операция актуализации движений документов по данным взаиморасчетов была выполнена успешно, переход к последующим этапам закрытия месяца стал возможен.
Ключевой вывод данной статьи заключается в том, что следует избегать «тихого» копирования типовых методов без фиксации версии источника, комментариев к изменениям и явного именования. Это усложняет последующее обновление конфигурации.
Чек-лист для обновления расширений с аннотациями &Вместо
Прикрепляем краткий чек-лист для обновления расширений 1С с аннотациями &Вместо, в которых расширенные методы являются копиями расширяемых:
- Контроль параметров: при обновлении конфигурации-поставщика в целевом методе могут появиться новые параметры, в том числе необязательные. Сверьте количество и состав параметров в расширении и в новой версии типовой конфигурации. Если параметры не совпадут, расширение просто не скомпилируется.
- Проверка контекста и экспортности: иногда при рефакторинге 1С переносит методы из одних модулей в другие или меняет признак Экспорт. Убедитесь, что заимствованный метод все еще находится в том же модуле и доступен для расширения.
- Анализ изменений в коде: это самое трудоемкое. Поскольку &Вместо полностью подавляет типовой код, вы обязаны знать, что именно изменил вендор внутри этого метода в новом релизе. Сравните текст типового метода «до» и «после» обновления. Например, если 1С добавила в метод важную проверку или регистрацию в новом регистре сведений, а ваше расширение об этом «не знает» и крутит старую логику — вы получите расхождение в данных.
- Поиск альтернатив (Рефакторинг в &ИзменениеИКонтроль): если вы видите, что типовой метод часто меняется, это повод для рефакторинга. Рассмотрите возможность замены &Вместо на аннотацию &ИзменениеИКонтроль. Так платформа сама подсветит вам места изменений в типовом коде при обновлении (через трехстороннее сравнение), и вам не придется вручную выискивать отличия в текстах модулей.
Вступайте в нашу телеграмм-группу Инфостарт