При работе с механизмом расширений в платформе «1С:Предприятие 8.3» (особенно версий 8.3.13–8.3.14) разработчики часто сталкиваются с необъяснимым поведением системы. Одной из самых коварных проблем является ситуация, когда после добавления нового реквизита в расширение, стандартный программный код начинает выдавать ошибки типизации. Например, при передаче объекта справочника Номенклатура в метод модуля менеджера, платформа внезапно начинает считать, что передана не ссылка или объект целиком, а одна из его табличных частей (например, ДополнительныеРеквизиты или ДрагоценныеМеталлы).
В этой статье мы подробно разберем, почему возникает этот «мистический» сбой, проанализируем внутренние механизмы платформы и подготовим пошаговый план по устранению проблемы.
Рассмотрим типичный сценарий на примере конфигурации «Управление торговлей 11». Допустим, мы добавили новый реквизит в расширение для справочника Номенклатура. В модуле объекта существует стандартный вызов функции для проверки заполнения или получения списка исключений:
// Модуль объекта справочника Номенклатура
Процедура ПередЗаписью(Отказ)
МассивНепроверяемыхРеквизитов = Справочники.Номенклатура.НепроверяемыеРеквизиты(ЭтотОбъект);
КонецПроцедуры
Проанализируем ситуацию через отладчик. В момент вызова переменная ЭтотОбъект имеет тип СправочникОбъект.Номенклатура. Однако, как только мы нажимаем F11 и проваливаемся в модуль менеджера:
// Модуль менеджера справочника Номенклатура
Функция НепроверяемыеРеквизиты(Объект, РеквизитыВидаНоменклатуры = Неопределено) Экспорт
// Здесь параметр "Объект" внезапно становится типом "СправочникТабличнаяЧасть.Номенклатура.ДополнительныеРеквизиты"
КонецФункции
Выясним причину такого поведения. Это связано с так называемым смещением индексов метаданных (Metadata Mapping). В старых версиях платформы 8.3.13 при динамическом объединении основной конфигурации и расширения внутренние идентификаторы объектов могли «съезжать». Указатель в памяти, который должен ссылаться на начало структуры объекта, из-за ошибки в расчете смещения начинает указывать на начало первой или случайной табличной части этого же объекта.
Как показывает практика, часто проблема решается простым сбросом регистрации расширения в информационной базе. Это заставляет платформу заново пересчитать все внутренние соответствия типов данных.
.cfe) на всякий случай.Важно: Если ваше расширение содержит данные в добавленных реквизитах, полное удаление расширения приведет к потере этих данных. В этом случае используйте только отключение или способы, описанные ниже.
Если простое переподключение не помогло, значит, некорректные индексы «застряли» в серверном кэше. Обычная очистка кэша пользователя здесь не поможет. Разберем шаги по очистке на стороне сервера:
C:\Program Files\1cv8\srvinfo).snaccfg — именно здесь хранятся скомпилированные метаданные расширений.Проанализируем настройки совместимости. Ошибки типизации часто возникают, когда Режим совместимости расширения отличается от режима совместимости основной конфигурации или когда платформа работает в режиме совместимости ниже 8.3.12.
Рекомендуем установить режим совместимости в расширении «Не использовать» (если платформа позволяет) или строго в соответствии с версией основной конфигурации. В версии 8.3.13 механизм хранения данных расширений был изменен (разделение таблиц), и несоответствие режимов провоцирует ошибки в Type Union (объединении типов данных).
Почему это чаще всего происходит именно с Номенклатурой в УТ 11, ERP или КА? Ответ кроется в сложности объекта. Справочник Номенклатура является одним из самых «тяжелых» в системе:
ЭтотОбъект.При добавлении даже одного простого реквизита типа Булево, объем метаданных, который платформе нужно динамически «склеить» (merge) с основной конфигурацией в оперативной памяти, возрастает критически. Если в основной конфигурации объект уже находится на грани допустимого количества полей для SQL-таблицы, расширение может спровоцировать некорректную адресацию.
Чтобы избежать подобных ситуаций в будущем, рассмотрим следующие правила гигиены разработки:
Расширение_Данные и Расширение_Логика). Это упростит платформе процесс построения карты метаданных.Подводя итог, отметим: если вы увидели, что ЭтотОбъект внезапно превратился в ТабличнуюЧасть, не ищите ошибку в своем коде. Это внутренний сбой платформы, который лечится «встряской» метаданных через переподключение расширения или очистку серверных кэшей.