Ошибка при обновлении на новый релиз

В связи с тем, что все продукты разрабатываемые нашим отделом базируются на типовых конфигурациях: 1С:УНФ, 1С:Бухгалтерия, 1С:Розница, то при выходе их новых версий нам приходится на них обновляться.

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

Однако есть и ряд минусов: архитектурно/стековая зависимость, возможные пересечение по блокам и конечно постоянные обновления.

Про один из таких кейсов с обновлением сегодня и поговорим.

Немного теории

На всякий случай уточню, что под обновлением конфигураций понимается процесс обновления со старого релиза продукта, но новый.

Если используется не доработанные конфигурации, то процесс обновления выглядит как классическая установка программ: "далее, далее, готово". В случае же внесения своих доработок, так называемых отраслевых/проектных, система будет запускать окно сравнения/объединения конфигураций с возможностью выбора поведения: взять вариант из новой конфигурации, из старой, или внести доработки самостоятельно. Например,c помощью внешних программ.

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

1. Классическое обновление через конфигуратор с ручным управлением правил. Данный вариант хорошо подходит для конфигураций с небольшим количеством изменений. При большом же количестве пользователю потребуется вносить множество ручных действий, что может приводить к неудачным обновлениям.
2. Обновлением через выгрузки конфигураций и Git. Данный вариант требует определенных навыков и знаний, но зато справляется и с более сложными доработками, а также бесплатен. К сожалению, оценить его выгоду и удобство я не могу, т.к. знаю о нем лишь теоретически по вебинару Желтого клуба.
3. Обновлением с помощью специализированных программ или своих наработок. Из недостатков: программы сторонних фирм требует затрат, но зато обновления происходит проще и быстрее.
4. Обновлением сторонними компаниями. В случае если в компании отсутствуют специалисты с нужными навыками или же проще и выгоднее передать обновление сторонним компаниям, то такие есть.

В среднем нам приходится обновляться по 2, 3 раза в месяц. Потому в свое время наша команда разработала продукт 1С-Рарус:СОК, который значительно упрощает процесс обновления и который является нашей спасательной палочкой.

Так что там за ошибка

При обновлении с помощью 1С-Рарус:СОК выполняется определенная последовательность действий: обновление средствами платформы, обработка специальными скриптами, предоставление отчетов для проверки корректности обновления и финализируется запуском проверок конфигураций на наличие приобретенных ошибок: синтаксических, лексических и т.п.. Данные проверки не заменяют сценарное или хотя бы обычное тестирование после обновления, но зато являются более широкомасштабными и позволяют убедиться в целостности конфигурации.

В результате обновления на релиз 3.0.4.65 конфигурации 1С:УНФ после выполнения проверок система нам выдала следующий текст ошибки: "Имя реквизита или поля ЕдиницаИзмерения не уникально".

К сожалению, данный текст не дает понимание в каком именно объекте произошла ошибка, а т.к. реквизит "Единица измерения" уж больно популярный, то сразу пойти в нужный объект у нас не удалось.

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

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

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

Как же понять в каком объекте беда?

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

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

По появлению ошибки останавливаем видео и смотрим на виновника:

Как можно заметить в нашем случае это оказался объект "Акт вскрытия тары алкогольной продукции". Перейдя на его форму, мы действительно обнаружили задублированный реквизит "Единица измерения".

Судя по всему, изначально его добавили на форму, а спустя время в объект. Прежде всего, на это указывает тот факт, что если попробовать добавить реквизит в обратном порядке, то система выдаст предупреждение о занятости наименования.

Удалив реквизит на форме - ошибка пропала.

Раньше же работало

Данный объект не дорабатывался при обновлении, а раньше таких ошибок не было. Что легко подтверждается проверкой на предыдущем релизе. Что же привело к данному поведению?

Если объект не менялось, а проверка стала выдавать ошибку, то логично предположить, что изменилось поведение платформы. А оно при использовании одинаковых условий прежде всего меняется при изменения режима совместимости, которое как оказалось разработчики 1С:УНФ изменили с 8.3.17 на 8.3.21.

В описании изменений изменений технологической платформы релиза 8.3.21 раздела "Изменения, требующие изменений в конфигурациях и административных установках" разработчики действительно изменили данное поведение.

Заключение

Таким образом, в результате обновления на новый релиз изменилось свойство режим совместимости, что спровоцировало изменение проверки синтаксического контроля и выдачу сообщения "Дублирование ...наименования реквизита".

Так как наименование реквизита "Единица измерения" слишком общее, то для поиска проблемного объекта потребовалось слегка попрыгать с бубном и запускать проверку с параллельной записью экрана.

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

С нашей же стороны можем лишь надеяться, что разработчики технологической платформы придут к более подробному тексту ошибки. Хотя бы с указанием проблемного объекта, а в идеале откажутся и от падения. Все таки падения в конфигураторе умудряются совпасть с каким-нибудь не сохраненным, но долго разрабатываемым блоком. Что вызывает боль и страдание разработчиков.

Больше полезных материалов на официальном канале 1С и точка.