Готовимся к ERP 2.6: 129 проблем в доработках, и 63 из них проверка применимости не покажет

Зачем я это проверял

1С выпустила ERP 2.6 на платформе 8.5. Сама 2.6.1 пока работает в режиме совместимости 8.3.27, обновиться на неё можно только с 2.5.27, а 2.5.27 как версия длительной поддержки (LTS) проживёт минимум до апреля 2027 года. Порядок перехода у 1С простой: перевести учёт со старых механизмов на актуальные, закрыть два отчётных периода и обновиться. По оценке самой 1С, это не сложнее обычного обновления между LTS-версиями.

Для учёта, может, так и есть. А вот про доработки в этом порядке ни слова, хотя у нас их немало: два больших расширения, в которых сидят основные доработки, и 517 файлов внешних отчётов и обработок. Да и сама конфигурация не типовая: в неё встроен отраслевой модуль. Поэтому я решил не ждать и заранее посмотреть, что из этого сломается на 2.6.1.

Проверял тремя способами. Сначала типовой формой готовности к переходу, потом проверкой применимости расширений средствами платформы и в конце сверкой кода расширений и внешних обработок со словарём изменений между 2.5.27.88 и 2.6.1.70.

В сумме вышло 129 проблем. 66 из них покажет проверка применимости, а 63 она не покажет. Из этих 63 восемнадцать не дадут открыть модуль, а остальные 45 всплывут, только когда пользователь дойдёт до нужной строки.

Что показала форма готовности

В 2.5.27 есть обработка "Готовность к переходу на редакцию 2.6 (11.6)". Для ERP она перебирает 12 механизмов: управление производством 2.1, давальческое сырьё 2.4, переработку на стороне 2.4, маршрутные карты, комиссионные продажи, взаиморасчёты, партионный учёт, внеоборотные активы, товарно-материальные ценности (ТМЦ) в эксплуатации, контроль лимитов, ввод остатков и ограничение доступа на уровне записей (RLS). По каждому смотрит функциональные опции, дату последнего документа и остатки.

Я открыл её на копии нашей рабочей базы. Красных строк с текстом "Нельзя переходить на редакцию 2.6" нашлось четыре из двенадцати:

• производство из давальческого сырья 2.4: опция включена, хотя последний документ был ещё в 2021 году;
• переработка на стороне 2.4: этот механизм у нас действительно в работе;
• маршрутные карты: форма предлагает помощник перехода на операции в ресурсных спецификациях;
• учёт ТМЦ в эксплуатации до применения стандарта бухгалтерского учёта ФСБУ 5: форма предлагает перейти к настройке.

Остальные восемь строк зелёные или "не используется". В том числе взаиморасчёты, ведь на новую архитектуру мы перешли давно.

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

Про код форма молчит. Ни расширения, ни внешние обработки она не смотрит, и упрекать её тут не за что: у неё просто другая задача. Дальше я смотрел сам код.

Проверка применимости: что скажет платформа

Платформа умеет проверить, применится ли расширение к конфигурации, и при этом не записывать его в базу. По-моему, этой возможностью пользуются редко, а зря. Сначала в рабочей базе на 2.5.27 выгружаем двоичные данные расширений в файлы:

// Рабочая база 2.5.27: двоичные данные всех расширений в файлы.
Для Каждого Расширение Из РасширенияКонфигурации.Получить() Цикл

    Расширение.ПолучитьДанные().Записать(КаталогВыгрузки + Расширение.Имя + ".cfe");

КонецЦикла;

Потом в базе на 2.6.1 (я брал демобазу из поставки) проверяем каждый файл:

// База на 2.6.1: проблемы применения расширения из файла, само расширение в базу не записывается.
Функция ПроблемыПримененияРасширения(ИмяФайла) Экспорт

    Результат = Новый Массив;
    Расширение = РасширенияКонфигурации.Создать();
    Проблемы = Расширение.ПроверитьВозможностьПрименения(Новый ДвоичныеДанные(ИмяФайла));

    Для Каждого Проблема Из Проблемы Цикл

        Результат.Добавить(Строка(Проблема.Важность) + ": " + Проблема.Описание);

    КонецЦикла;

    Возврат Результат;

КонецФункции

Нужны административные права, а на одно расширение уходит несколько секунд. Платформа насчитала 478 проблем у первого большого расширения и 108 у второго.

478 проблем, из них 396 ложных

Цифра пугает, но почти вся она состоит из сообщений "Не найден объект". Расширение заимствует наши справочники, реквизиты, роли, общие модули и объекты отраслевого модуля, а в чистой поставке 2.6.1 их, понятно, нет. После объединения нашей конфигурации с 2.6.1 всё это окажется на месте. По сути, это шум.

Получается, проверять применимость на чистой поставке можно, но результат придётся фильтровать. Типовые объекты от своих я отделял по файлу Ext/ParentConfigurations.bin из выгрузки конфигурации: в нём перечислены идентификаторы объектов поставщика.

После фильтра осталось 65 настоящих мест:

• 60 перехватчиков &ИзменениеИКонтроль из 562, которые есть в расширении. У исходных процедур в 2.6.1 изменился текст, а у части поменялись и параметры.
• 2 удалённых реквизита поставщика. Это УдалитьТипНалога у заявки на расходование денежных средств и УдалитьКодОКВЭД2 у номенклатуры. Оба были помечены "Удалить" ещё в 2.5, и сюрпризом это не стало.
• 3 реквизита поставщика сменили тип. У номера входящего документа во взаимозачёте и у номера первичного документа в реестре документов выросла длина, а строка платёжно-расчётных документов у счёта-фактуры стала неограниченной. Если расширение контролирует тип заимствованного реквизита, оно не применится.

Два сообщения про тип оказались нашими же доработками. Когда-то мы увеличили разрядность одного числового реквизита номенклатуры и длину номера в реестре документов. После объединения доработка останется, и сообщения уйдут сами.

Со вторым большим расширением проще. Настоящая проблема там всего одна: оно тоже заимствует удалённый реквизит номенклатуры. Всё остальное касается наших объектов и того же числового реквизита с нашей разрядностью.

Код, которого проверка применимости не видит

Проверка применимости смотрит только заимствования и перехватчики. Собственный код расширения она не компилирует, а внешние обработки не видит вовсе. Для кода пришлось собрать словарь изменений. Я выгрузил в файлы нашу 2.5.27.88 и чистую 2.6.1.70 одной и той же платформой, оставил только объекты поставщика (иначе все наши объекты оказались бы "удалёнными") и сравнил.

В 2.6.1 удалены 66 объектов и почти 900 экспортных методов, у части оставшихся методов поменялись параметры. Про сам словарь подробно расскажу во второй части.

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

Всё, что нашла платформа в двух больших расширениях, словарь нашёл тоже. Но сверх этого в коде обнаружились ещё 63 критичные находки, которых проверка применимости не покажет. Из них 19 в расширениях и 44 во внешних обработках. Критичным я считаю то, что в 2.6.1 не применится, не откроется или упадёт. Остальное словарь выдаёт как предупреждения и справочные находки, о них ниже.

Что ловит компилятор, а что нет

Чтобы не гадать, каждый вид поломки я проверил на демобазе 2.6.1 дважды. В первый раз строка стояла внутри Если Ложь Тогда, где она только компилируется. Во второй раз она выполнялась без всяких условий.

// Демобаза 2.6.1. Строка внутри "Если Ложь" не выполняется: видно только то, что ловит компилятор.
Выполнить("Если Ложь Тогда Ф = ПолучитьФункциональнуюОпцию(""НоваяАрхитектураВзаиморасчетов""); КонецЕсли;"); // компилируется
Выполнить("Если Ложь Тогда РаспределениеВзаиморасчетовВызовСервера.АналитикиРасчета(); КонецЕсли;"); // ошибка компиляции

Тексты ошибок привожу дословно.

• Удалённый общий модуль. Не компилируется, пишет "Переменная не определена (РаспределениеВзаиморасчетовВызовСервера)". Внешняя обработка с таким вызовом даже не откроется, будет "Ошибка инициализации модуля".
• Удалённая функциональная опция в ПолучитьФункциональнуюОпцию. Компилируется спокойно, а при выполнении получаем "Функциональная опция не найдена".
• Лишний параметр у метода менеджера. Тоже компилируется и падает только при выполнении с ошибкой "Слишком много фактических параметров".
• Удалённый метод общего модуля, который сам остался. Компилируется, а при выполнении выдаёт "Метод объекта не обнаружен (ВыполнитьЗаданияНеоперативнойОчередиПоСпискуДокументов)".
• Переименованный регистр в тексте запроса. Компилятору тут всё равно, и ошибка будет только при выполнении: Таблица не найдена "РегистрНакопления.РасчетыСКлиентамиПоДокументам".
• Менеджер переименованного регистра. Компилируется, а при выполнении сообщает "Поле объекта не обнаружено (ЗаданияКРаспределениюРасчетовСКлиентами)".

Итого из шести видов до запуска виден только один. Остальные пять вылезут уже у пользователя.

Что сломается и чем заменить

Теперь конкретика: что встречалось чаще всего и на что это менять. Замены смотрел в коде 2.6.1, что вызывают те же места в новой версии.

1. Удалена функциональная опция "НоваяАрхитектураВзаиморасчетов". У нас она встречается в менеджерах реализации и счёта-фактуры и в модуле проведения документов расширения, а во внешних обработках попадается в печати универсального передаточного документа (УПД), счёта-фактуры, ТОРГ-12 и в справке по переоценке валютных средств. В 2.6 онлайн-взаиморасчёты единственные, поэтому проверку можно смело убирать и оставлять ветку для значения "Истина".
2. Удалён общий модуль РаспределениеВзаиморасчетовВызовСервера. Его вызывают менеджер счёта-фактуры в расширении и печать УПД, счёта-фактуры и ТОРГ-12 во внешних обработках. Метод АналитикиРасчета переехал в ВзаиморасчетыСлужебный, параметры надо сверить. На месте РаспределитьВсеРасчетыСКлиентами в 2.6.1 чаще всего вызывается НеоперативнаяОчередьЗаданий.ВыполнитьЗаданияПоДокументамОднопоточно. Имя нашлось, но работает новый метод по-своему, и его придётся почитать.
3. Регистры РасчетыСКлиентамиПоДокументам и РасчетыСПоставщикамиПоДокументам в 2.6.1 получили префикс "Удалить", их оставили только для переноса данных. Долг и предоплату по расчётным документам в 2.6 дают РасчетыСКлиентамиПоСрокам и РасчетыСПоставщикамиПоСрокам (измерения "ОбъектРасчетов" и "РасчетныйДокумент"). Обращения к старым регистрам у нас сидят в текстах запросов, и компилятор их не увидит.
4. У Документы.УпаковочныйЛист.ПолучитьКодНового убрали параметр "ВызовИзТСД". Его передают во втором расширении и во внешних обработках упаковочного листа, этикетки и интеграции, а в первом расширении на этот метод стоит перехватчик. Вызов с лишним параметром упадёт только при выполнении.
5. 13 перехватчиков, у исходных процедур которых поменялись параметры. Например, из ТранспортнаяНакладная.ЗаполнитьТабличныйДокументТНВерсияС2022 убрали параметр "ВыборкаДанныеЗаказов", из СкладыСервер.ТекстЗапросаДанныхОтгружаемыеТовары убрали "ЭтоОрдера", а из РеглУчетПроведениеСервер.ВернутьДокументыКОтражению убрали "ПривРежим". Конфигуратор их покажет, но код всё равно переносить руками.
6. Удалённый метод, у которого нашлась замена. Вместо НеоперативнаяОчередьЗаданий.ВыполнитьЗаданияНеоперативнойОчередиПоСпискуДокументов почти во всех тех же местах 2.6.1 вызывается ВыполнитьЗаданияПоДокументамОднопоточно.

По первому пункту правка схематично выглядит так:

// Было: отдельная ветка для офлайн-взаиморасчётов
Если ПолучитьФункциональнуюОпцию("НоваяАрхитектураВзаиморасчетов") Тогда
    ДанныеРасчетов = РасчетыПоСрокам(Параметры);
Иначе
    ДанныеРасчетов = РасчетыПоДокументам(Параметры);
КонецЕсли;

// Стало: в 2.6 онлайн-взаиморасчёты единственные
ДанныеРасчетов = РасчетыПоСрокам(Параметры);

Со справкой по переоценке вышла отдельная история. В ней есть ветка для офлайн-режима, которая читает регистры старой архитектуры, а их в нашей базе не пишут с конца 2019 года. Ветка давно мёртвая и годами никому не мешала. Только перед ней стоит проверка опции, и в 2.6.1 отчёт будет падать на ней при каждом формировании.

Внешние обработки: 44 находки, 7 причин

Большая часть внешних обработок оказалась чистой, а критичные находки нашлись только в 10. Почти две трети этих находок опять про офлайн-взаиморасчёты: печать УПД, счёта-фактуры, ТОРГ-12 и та самая справка по переоценке.

Одна и та же причина вдобавок размножается копиями. Справка по переоценке у нас лежит в двух версиях, а упаковочный лист и этикетка к нему повторяются в трёх обработках. Перед переходом каталог внешних обработок стоит почистить, иначе каждая лишняя копия превращается в ещё одну правку.

Около половины критичных находок сидит в строках, то есть в текстах запросов и в именах функциональных опций. Компилятор их не видит, поиск вызовов общих модулей тоже не найдёт, так что нужен разбор текста запроса.

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

Предупреждения, которые не подождут до 2.6.3

Кроме критичных, словарь выдал 338 предупреждений. Почти все они про устаревшие механизмы, объекты которых в 2.6.1 ещё живы, и три четверти приходятся на переработку на стороне и давальческое сырьё 2.4.

Соблазн понятный: записать их в долг до 2.6.3, когда механизмы удалят совсем. Но форма готовности говорит другое. Пока в базе работают переработка и давальческое сырьё 2.4, на 2.6 не перейти, а значит, предупреждения по этим двум механизмам придётся разбирать вместе с переводом учёта на версии 2.5, то есть до обновления. И ещё момент: печатные формы и отчёты, которые читают документы 2.4, после перевода будут показывать только старые данные.

С управлением производством 2.1 ровно наоборот. База давно на 2.2, и эти находки касаются объектов механизма, которым никто не пользуется. Их можно убирать без спешки.

Объём работы

Если свести всё вместе, в доработках 129 проблем в 105 местах:

• 66 мест в заимствованиях и перехватчиках, их покажет проверка применимости, из них 60 перехватчиков;
• 39 мест в коде расширений и внешних обработок, которых проверка применимости не покажет. По 8 мест приходится на функциональную опцию и на удалённый общий модуль, по 7 на тексты запросов и на вызовы с новыми параметрами, остальные на удалённые методы, формы в строках и менеджеры переименованных регистров.

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

Что удивило и где я ошибся

Несколько вещей меня удивили. Больше всего критичного в коде нашлось не в расширениях, а во внешних обработках, хотя большинство обработок при этом чистые. Проверка применимости на чистой поставке без фильтра почти бесполезна, потому что настоящие проблемы тонут в сообщениях про свои объекты. А давно мёртвая ветка в 2.6.1 начнёт ронять живой отчёт.

Был и промах с моей стороны. Первая версия словаря нашла только 47 из 66 проблем, которые платформа показала в двух больших расширениях. Она не учитывала строки и тексты запросов в перехваченных процедурах, модули общих форм и тип заимствованных реквизитов. Эти дыры вскрылись, только когда я сверил словарь с платформой, и после доработки он находит все 66. Но проблем в коде платформа не видит совсем, поэтому нужны обе проверки.

Где проверка заканчивается

• Сравнивал я 2.5.27.88 и 2.6.1.70. Уже вышла 2.6.2, в будущем планирую переписать словарь под нее, а следующие версии могут удалить что-то ещё. Версия 2.6.3, в которой уходят старые механизмы, пока не вышла.
• Применимость я проверял на чистой демобазе 2.6.1. По-честному это надо делать на своей конфигурации, объединённой с 2.6.1.
• Проверка кода статическая. Она не видит Выполнить(), имена, собранные из строк, и методы объекта, который лежит в переменной.
• Пользовательские настройки, варианты отчётов, обмены и права я не проверял.

Что сделать до апреля 2027

Порядок у меня получился такой:

1. Открыть "Готовность к переходу на редакцию 2.6 (11.6)" и перевести механизмы с красными строками. Доработки под эти механизмы переписывать там же, в одном проекте.
2. Выгрузить двоичные данные всех расширений и проверить применимость к 2.6.1 кодом выше, отфильтровав свои объекты.
3. Пересмотреть перехватчики &ИзменениеИКонтроль с изменённым текстом, и те, где поменялись только строки, тоже.
4. Сверить код расширений и внешних обработок с 2.6.1: функциональные опции, общие модули, методы менеджеров, тексты запросов. Начинать с того, что упадёт при выполнении.
5. Выкинуть мёртвые ветки офлайн-взаиморасчётов.
6. Почистить копии внешних обработок.
7. Прогнать всё на копии базы, объединённой с 2.6.1.

Итог

Форма готовности говорит про учёт. Проверка применимости говорит про заимствования и перехватчики. А про собственный код расширений и внешние обработки не говорит никто, хотя у нас именно там 63 проблемы, которые иначе нашли бы пользователи.

Сверку кода по словарю я в итоге оформил во внешнюю обработку "Проверка расширений и обработок перед переходом на 1С:ERP 2.6". Она разбирает расширения и внешние обработки и по каждой находке пишет, чем заменить.

Если вы уже анализировали переход на ветку 2.6 и я что-то упустил, поправляйте, не стесняйтесь

В следующей части разберу, что на самом деле удалили в 2.6.1 (или уже 2.6.2...), по объектам и механизмам.