Механизм История данных, появившийся в платформе 1С:Предприятие 8.3, представляет собой мощный встроенный инструмент для автоматического протоколирования изменений объектов. Однако при попытке внедрить его для регистров сведений, особенно в типовых конфигурациях вроде «Управление торговлей 11», разработчики часто сталкиваются с трудностями. Одной из самых коварных является ошибка в системной форме: {mngbase/DataHistoryChangeHistoryRuForm.lf(401)}: Поле объекта не обнаружено (ОбщийРеквизитИспользованиеРазделяемыхДанных).
В этой статье мы подробно разберем, почему возникает эта ошибка, как она связана с режимом совместимости и что нужно сделать, чтобы история изменений в регистрах начала работать корректно.
Проанализируем ситуацию: ошибка возникает не в коде конфигурации, а в системной форме платформы DataHistoryChangeHistoryRuForm. Это происходит в тот момент, когда система пытается отобразить отчет об изменениях. Рассмотрим фрагмент кода, на который жалуется конфигуратор:
Если ОбщийРеквизит.РазделениеДанных <> Метаданные.СвойстваОбъектов.РазделениеДанныхОбщегоРеквизита.Разделять
Суть проблемы заключается в несоответствии версии используемой платформы и режима совместимости конфигурации. Даже если вы установили современную платформу (например, 8.3.13.1644), но в свойствах конфигурации стоит Режим совместимости: Версия 8.3.12, система ограничивает доступ к определенным метаданным. В частности, свойство РазделениеДанныхОбщегоРеквизита в том виде, в котором его ожидает системная форма истории, в режиме совместимости 8.3.12 может быть недоступно или обрабатываться иначе.
Важно понимать, что механизм истории данных для регистров сведений полноценно «задышал» только в версии 8.3.13. Если ваша конфигурация имитирует поведение версии 8.3.12, платформенные формы отрисовки истории просто «не видят» нужных полей в структуре метаданных разделения данных.
Многие программисты ошибочно полагают, что использование новой платформы автоматически включает все ее возможности. Это не так. Режим совместимости — это инструкция платформе «веди себя так, как вела себя версия Х». Проанализируем последствия этого для истории данных:
mngbase/...) обновляются вместе с платформой. Если форма рассчитана на логику 8.3.13, а метаданные обрезаны совместимостью 8.3.12, возникает исключение Поле объекта не обнаружено.Прежде чем бороться с ошибками отображения, убедимся, что сама история данных настроена верно. Разберем по шагам процесс включения для независимого регистра сведений:
История данных установим значение Использовать.История данных также установить Использовать. По умолчанию там может стоять Авто, что не всегда срабатывает корректно в старых режимах совместимости.Иногда платформа «забывает» инициализировать таблицы истории, особенно после изменения состава метаданных. Проанализируем ситуацию, когда флаги стоят, но история не пишется или выдает ошибки. В таких случаях рекомендуется выполнить программный вызов обновления метаданных истории. Создадим небольшую обработку со следующим кодом:
// Обновляем состав метаданных, для которых включена история
ИсторияДанных.ОбновитьОбновляемыеДанные();
// Если нужно программно включить историю для конкретного объекта
МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип("РегистрСведенийКлючЗаписи.НазваниеВашегоРегистра"));
ИсторияДанных.УстановитьНастройки(МассивТипов);
После выполнения этого кода платформа принудительно пересоберет внутренние структуры, отвечающие за версионирование регистра.
Если режим совместимости поднять нельзя (например, вы работаете на типовой УТ 11.4), а стандартная форма выдает ошибку ОбщийРеквизитИспользованиеРазделяемыхДанных, рассмотрим вариант использования собственной формы. Посмотрим на рекомендации опытных разработчиков: в свойствах конфигурации есть пункт «Основная форма истории изменений данных».
Мы можем создать свою форму, которая будет использовать программный интерфейс ИсторияДанных.Выбрать() для получения данных об изменениях, вместо того чтобы полагаться на стандартный отчет платформы. Рассмотрим пример получения версий программно:
Выборка = ИсторияДанных.Выбрать(КлючЗаписиРегистра);
Пока Выборка.Следующий() Цикл
// Проанализируем каждую версию
ДанныеВерсии = Выборка.ПолучитьДанные();
// Здесь можно вывести данные в свою таблицу или отчет
КонецЦикла;
Этот метод позволяет полностью избежать обращения к проблемному общему реквизиту в системных формах, так как вы сами контролируете процесс чтения и вывода данных.
Важно не путать механизм Истории данных платформы и подсистему Версионирование объектов из состава БСП. Выясним основные отличия, чтобы выбрать правильный путь:
ОбъектыГотовыхДанных в формате XML/FastInfoset.Если ваша задача — отслеживать изменения именно в регистре сведений в старой конфигурации, то использование платформенного механизма — единственный штатный путь, но он требует либо повышения режима совместимости до 8.3.13, либо разработки своих форм отображения.
Проанализировав проблему, мы можем предложить следующий алгоритм действий:
Поле объекта не обнаружено в системных формах является ожидаемой при работе с регистрами.История данных включено не только у регистра, но и у его ресурсов.ИсторияДанных.Выбрать() для формирования собственного отчета об изменениях. Это позволит обойти баг в стандартной форме DataHistoryChangeHistoryRuForm.Помните, что механизм истории данных — это мощный инструмент, но его стабильность напрямую зависит от того, насколько «современным» считает себя ядро вашей конфигурации.