При активном использовании расширений в 1С программисты часто сталкиваются с необходимостью наделить новые документы или справочники расширения стандартными функциями, такими как версионирование. Однако попытка использовать привычную подсистему «Версионирование объектов» из Библиотеки Стандартных Подсистем (БСП) наталкивается на серьезное архитектурное ограничение платформы. Рассмотрим подробнее, почему стандартный путь не работает и как решить задачу современными средствами платформы.
Давайте проанализируем, как устроено версионирование в БСП. В основе механизма лежит регистр сведений ВерсииОбъектов, где измерение Объект имеет составной тип данных. В этот составной тип через ОпределяемыйТип.ВерсионируемыйОбъект должны быть включены все метаданные, для которых требуется хранение истории.
Проблема заключается в том, что в архитектуре «1С:Предприятие» определяемые типы из основной конфигурации нельзя расширять типами из расширения. Это сделано для обеспечения целостности базы данных: если расширение будет отключено, записи в регистре основной базы с типами расширения стали бы «битыми» ссылками, что недопустимо. Таким образом, добавить документ, созданный в расширении, в стандартный список версионируемых объектов БСП без снятия основной конфигурации с поддержки невозможно.
Выяснив причину ограничения, разберем наиболее эффективный способ решения — переход на использование встроенного механизма платформы «История данных» (Data History). Этот механизм появился в версии 8.3.11 и значительно развился в последующих релизах. В отличие от БСП, он работает на уровне ядра платформы и полностью поддерживает объекты расширений.
Посмотрим на шаги, которые необходимо выполнить для включения истории:
Документ или Справочник), созданный в расширении.Использовать.История данных (по умолчанию оно обычно установлено в значение Использовать).Этот подход позволяет избежать модификации основной конфигурации и корректно работает даже в том случае, если база данных является частью РИБ (Распределенной Информационной Базы), так как история данных по умолчанию не передается в другие узлы, если это не настроено специально.
Так как интерфейс просмотра истории данных платформы отличается от форм БСП, нам может потребоваться программно вызвать форму истории для пользователя. Разберем, как это сделать в модуле формы объекта расширения. Мы можем добавить команду на форму и прописать следующий код:
&НаКлиенте
Процедура ПоказатьИсториюИзменений(Команда)
ПараметрыФормы = Новый Структура;
ПараметрыФормы.Вставить("Данные", Объект.Ссылка);
ОткрытьФорму("ОбщаяФорма.ИсторияДанных", ПараметрыФормы);
КонецПроцедуры
Важно помнить, что форма ИсторияДанных является стандартной, но если в вашей конфигурации (на базе БСП) она переопределена, путь может отличаться. Тем не менее, платформа предоставляет доступ к таблицам истории через встроенный язык, что позволяет при необходимости создать полностью кастомный отчет по изменениям.
Проанализируем ситуацию, когда у нас есть выбор между двумя механизмами. Если объект находится в основной конфигурации, использование БСП оправдано привычным интерфейсом и интеграцией с правами доступа БСП. Однако для объектов расширения «История данных» обладает неоспоримыми преимуществами:
Рассмотрим важный нюанс, упомянутый участниками форума: использование расширений в распределенных базах. Если ваша задача — внедрить функционал, который не должен попасть в другие узлы РИБ, расширение является лучшим инструментом. Объекты метаданных, созданные в расширении, по умолчанию не участвуют в обмене данными. Вместе с механизмом истории данных это создает изолированную подсистему, которая работает только там, где она подключена, не «засоряя» обмены и не требуя изменения правил синхронизации.
Таким образом, мы выяснили, что попытка «малой кровью» внедрить объекты расширения в БСП-версионирование нецелесообразна из-за ограничений платформы на составные типы. Использование системной Истории данных является штатным, надежным и наиболее современным способом решения данной задачи.