В практике разработки на платформе 1С нередко возникает задача отслеживания изменений в данных. Традиционно пользователи привыкли видеть историю изменений в документах, однако для справочников этот функционал также критически важен, особенно если справочник заменяет собой документ (как в случае с объектом Инвентаризация). В данной статье мы подробно разберем, какими методами можно реализовать хранение истории изменений справочника, проанализируем разницу между платформенными и прикладными механизмами, а также выясним, как избежать проблем с производительностью.
Прежде чем приступать к реализации, нам необходимо четко разделять два существующих в современной экосистеме 1С механизма. Несмотря на схожую цель, они работают по-разному. В зависимости от архитектуры вашей системы, в будущем может потребоваться переход с платформенного механизма История данных на механизм Версионирование объектов БСП:
Рассмотрим подробнее каждый из этих способов, чтобы выбрать оптимальный для вашей задачи.
Проанализируем ситуацию, когда нам требуется максимально быстрое и современное решение. Платформенный механизм включается непосредственно в Конфигураторе. Выполним следующие шаги:
Инвентаризация).Использовать.Важно помнить, что если данные в справочник записываются программно (например, через внешнюю обработку или интеграцию), история будет фиксироваться только в том случае, если в коде используется правильный режим записи. Рассмотрим пример кода:
ОбъектСправочника = Справочники.Инвентаризация.СоздатьЭлемент();
// Заполнение реквизитов
ОбъектСправочника.Наименование = "Инвентаризация №1 от " + ТекущаяДата();
// Устанавливаем режим записи для фиксации истории
ОбъектСправочника.Записать(РежимЗаписиДанных.Запись);
В этом случае платформа автоматически создаст новую версию в системных таблицах. Для просмотра истории пользователю достаточно будет нажать стандартную кнопку в форме объекта (в подменю «Еще»).
Если ваша конфигурация построена на базе БСП (например, 1С:ERP, 1С:УТ 11 или 1С:Бухгалтерия 3.0), целесообразно использовать встроенный интерфейс настройки.
Разберем алгоритм действий в пользовательском режиме:
Инвентаризация и установим для него режим версионирования: Версионировать при записи или Версионировать при проведении (последнее актуально, если у справочника есть логика «статусов»).Проанализируем преимущество этого метода: здесь же можно задать Срок хранения версий (например, за последний год или бессрочно). Это критически важно для предотвращения раздувания базы данных.
Выясним причину, по которой справочник «Инвентаризация» может стать «тяжелым». Как было отмечено в обсуждении, если в инвентаризации тысячи строк номенклатуры, запись каждой версии может занимать значительное время. В таких случаях разработчику необходимо провести замер производительности контура 1С и поиск узких мест.
Рассмотрим рекомендации по оптимизации:
История данных в этом плане эффективнее, так как он сохранит только факт изменения конкретного реквизита.Иногда требуется не просто хранить историю, но и использовать её в бизнес-логике. Например, выяснить, кто изменил количество товара в описи. Для платформенного механизма мы можем использовать объект ИсторияДанных. Посмотрим на пример получения версий:
ВыборкаВерсий = ИсторияДанных.Выбрать(СсылкаНаСправочник);
Пока ВыборкаВерсий.Следующий() Цикл
Сообщить("Версия №" + ВыборкаВерсий.НомерВерсии +
", Автор: " + ВыборкаВерсий.Пользователь +
", Дата: " + ВыборкаВерсий.ДатаВерсии);
КонецЦикла;
Такой подход позволяет создавать кастомные отчеты по изменениям, минуя тяжелый ЖурналРегистрации, который предназначен для аудита событий всей системы, а не для анализа состояний конкретных данных.
История изменений — самый быстрорастущий раздел базы. Разберем, как держать ситуацию под контролем. В типовых конфигурациях за это отвечает регламентное задание ОчисткаУстаревшихВерсийОбъектов.
Важные настройки:
Подводя итог, выбор между встроенной Историей данных платформы и Версионированием БСП зависит от вашей конфигурации и требований к детализации. Если же вам требуется реализовать подобный контроль для подключаемых модулей, вы можете использовать шаблон внешней обработки с историей изменений и сохранением параметров. В большинстве случаев для новых разработок мы рекомендуем использовать платформенный механизм из-за его экономичности и высокой скорости работы с дельтами изменений.