При обновлении конфигураций уровня ERP, Комплексная автоматизация или Управление торговлей на новые релизы платформы 1С:Предприятие 8.3.24, многие специалисты столкнулись с неприятной ситуацией. После успешного, казалось бы, обновления, пользователи обнаруживают, что из отчетов и форм списков документов пропали дополнительные реквизиты. При этом сами данные (значения реквизитов) в базе могут присутствовать, но система их «не видит».
В этой статье мы подробно разберем, почему возникает данная проблема, как диагностировать ее в Конфигураторе и рассмотрим пошаговый алгоритм восстановления работоспособности базы без потери данных.
Первым делом нам необходимо убедиться, что проблема действительно кроется в метаданных конфигурации, а не в пользовательских настройках видимости или правах доступа. Для общего контроля здоровья системы на данном этапе не лишним будет выполнить анализ конфигураций, расширений, отчетов и обработок на наличие ошибок, чтобы исключить влияние сторонних доработок. Однако симптомы нашей конкретной проблемы обычно следующие: в режиме 1С:Предприятие при попытке настроить отчет или изменить форму списка, дополнительные реквизиты просто отсутствуют в дереве доступных полей.
Давайте перейдем в режим Конфигуратора и проверим настройки объектов. Проблема чаще всего касается справочников и документов, для которых включено использование дополнительных реквизитов и сведений (механизм БСП).
Разберем процесс диагностики на примере справочника:
Номенклатура или Партнеры.В открывшемся окне «Дополнительные характеристики объекта метаданных» мы должны увидеть заполненные поля. Для типовых конфигураций (ERP, КА, УТ) эти поля обычно заполняются ссылками на План Видов Характеристик (ПВХ).
Правильное состояние (примерное):
ПланВидовХарактеристик.ДополнительныеРеквизитыИСведенияЕсли же вы открыли это окно и увидели, что поля пусты, хотя объект находится на поддержке или частично на поддержке — вы столкнулись с ошибкой платформы. Именно очистка этих свойств приводит к тому, что подсистема свойств БСП перестает понимать, что к данному объекту можно "прикрепить" дополнительные реквизиты.
В ходе анализа и обсуждений сообщества было выявлено, что данное поведение не является ошибкой в коде конфигурации ERP или Библиотеки Стандартных Подсистем (БСП). Корнем зла является ошибка платформы 1С:Предприятие.
Ошибка зарегистрирована в баг-трекере 1С под номером 000133939 (иногда фигурирует как 10237072). Суть ошибки заключается в некорректной сериализации метаданных при обновлении конфигурации базы данных. Проще говоря, в момент применения изменений (нажатие F7 или кнопки "Обновить конфигурацию базы данных"), платформа самопроизвольно очищает настройки характеристик у объектов метаданных.
Стоит отметить, что процесс обновления на новые релизы часто сопряжен с рисками. Помимо исчезновения свойств, изменение структуры метаданных может привести к ошибкам в коде, поэтому параллельно с решением текущей задачи мы рекомендуем искать "битые" запросы после обновления релиза, чтобы убедиться в отсутствии других скрытых проблем.
Условия проявления ошибки:
Мы рассмотрим два направления действий: как устранить причину появления ошибки и как исправить последствия (вернуть настройки), если база уже повреждена.
Самым надежным способом предотвратить повторение ситуации в будущем является обновление технологической платформы. Фирма 1С исправила эту ошибку в следующих версиях (и более новых):
Рекомендуем обновить сервер 1С и клиентские лицензии до указанных версий перед проведением обновлений конфигураций.
Если вы уже обновились и обнаружили, что свойства слетели, ни в коем случае не нужно восстанавливать всю базу из бэкапа, теряя введенные пользователями документы. Мы можем восстановить только метаданные конфигурации.
Разберем пошаговый алгоритм восстановления:
Шаг 1: Подготовка эталонного файла конфигурации (.cf)
Вам понадобится файл конфигурации (.cf) именно того релиза, который сейчас установлен у вас в базе (но с корректными настройками). Его можно взять из дистрибутива обновления (шаблонов) или, если вы делали выгрузку .cf перед обновлением БД, использовать её.
Шаг 2: Сравнение и объединение
Зайдите в Конфигуратор поврежденной базы. Выполните команду:
Конфигурация -> Сравнить, объединить с конфигурацией из файла...
Выберите подготовленный корректный .cf файл.
Шаг 3: Настройка фильтра объединения
Это самый важный этап. Нам не нужно объединять всё подряд.
Номенклатура).Если объектов много, процедуру придется повторить для всех пострадавших справочников и документов. Работа с окном сравнения может быть утомительной, особенно если вы обновляете подсистемы БСП или меняете режимы поддержки — в таких случаях для ускорения процесса часто используют групповое изменение режима поддержки по подсистеме, но в нашем случае главное — аккуратно выбрать только свойство "Характеристики".
Шаг 4: Применение изменений
Нажмите кнопку "Выполнить". После этого сохраните конфигурацию и обновите конфигурацию базы данных (F7). Поскольку мы меняем только метаданные в Конфигураторе (восстанавливаем связи), данные в базе не пострадают и снова станут видны в пользовательском режиме. После того как поля снова станут видимыми, если вам потребуется массово отредактировать их значения, можно использовать пакетное изменение дополнительных реквизитов и сведений.
В ходе обсуждения проблемы специалистами были выработаны временные меры и наблюдения, которые могут быть полезны, если оперативное обновление платформы невозможно.
Замечено, что при работе через Хранилище конфигурации вероятность "слета" настроек ниже, но не исключена полностью. Один из участников предложил следующий алгоритм обхода ошибки на уязвимой платформе:
Даже если в основной конфигурации локальной базы свойства очистятся при обновлении БД, в Хранилище они останутся корректными. После этого можно "переполучить" объекты из хранилища.
Особое внимание обратите на операцию Конфигурация -> Загрузить конфигурацию из файла. На проблемных релизах платформы именно полная замена конфигурации с последующим обновлением БД наиболее часто приводит к очистке характеристик. Старайтесь использовать последовательное обновление через файлы обновлений (.cfu) или механизм сравнения/объединения.
Изначально подозрение падало на конфликт с БСП (Библиотекой Стандартных Подсистем), так как именно она управляет логикой дополнительных реквизитов. Однако, как мы выяснили, БСП здесь выступает "пострадавшей стороной". Если платформа стирает привязку объекта к Плану Видов Характеристик, код БСП просто считает, что для данного объекта функционал отключен. Поэтому попытки "чинить" или обновлять саму БСП отдельно от платформы не принесут результата.
Если у вас пропали дополнительные реквизиты после обновления на платформе 8.3.24:
Своевременное обновление платформы и создание резервных копий перед каждым этапом изменений — залог стабильной работы вашей системы ERP.