Как правильно реализовать фиксацию даты создания и изменения документа в 1С:Бухгалтерия 2.0?

В процессе разработки часто возникает задача отслеживать время жизни документа: когда он был создан и когда последний раз подвергался изменениям. При работе в таких конфигурациях, как 1С:Бухгалтерия 2.0, важно найти баланс между функциональностью и производительностью системы. Давайте разберем, как реализовать этот механизм грамотно.

Анализ подходов к реализации

Многие разработчики на старте задумываются о добавлении дополнительных реквизитов непосредственно в объект Документ. Однако давайте проанализируем, почему этот путь может оказаться не самым лучшим:

1. Влияние на таблицу документа: Добавление новых реквизитов увеличивает размер таблицы базы данных для этого документа. При интенсивном проведении документов система будет тратить дополнительные ресурсы на обновление этих полей в рамках одной транзакции записи.
2. Производительность: Хотя в 3 раза время проведения не увеличится, любое лишнее поле в «тяжелых» объектах замедляет работу при массовых операциях.
3. Масштабируемость: Если данные хранятся внутри самого объекта, любые отчеты или поисковые запросы по этим полям будут нагружать таблицу документа, которая и так является наиболее часто используемой в системе.

Рекомендуемое решение: Использование регистра сведений

Оптимальным решением с точки зрения архитектуры является создание отдельного независимого непериодического РегистрСведений. Почему это лучше?

• Разделение данных: Мы выносим служебную информацию за пределы основной таблицы документа.
• Гибкость выборки: Нам становится гораздо проще искать измененные документы за период. Используя Запрос к регистру сведений, мы можем быстро отобрать только те документы, которые удовлетворяют условиям поиска, не сканируя при этом все документы подряд.
• Независимость: Использование РегистрСведений позволяет реализовать механизм фиксации дат без прямого изменения структуры метаданных самих документов, что облегчает последующее обновление конфигурации.

Почему Журнал регистрации не подходит?

Часто возникает соблазн использовать ЖурналРегистрации. Однако, рассмотрим подробнее, почему это плохая идея для бизнес-задач:

ЖурналРегистрации предназначен в первую очередь для аудита действий пользователей и административных целей. Его структура (часто файловая) и принципы хранения не рассчитаны на высокопроизводительные запросы, необходимые для автоматизированной работы системы. Попытки программно выбирать данные из ЖР в ходе работы алгоритмов могут привести к существенным «тормозам» всей системы.

Реализация через подписку на событие

Для того чтобы автоматизировать процесс фиксации даты, мы рекомендуем использовать механизм ПодпискиНаСобытия. Давайте разберем этот процесс по шагам:

1. Создайте РегистрСведений, где в качестве измерения будет выступать Ссылка на документ, а в ресурсах — ДатаСоздания и ДатаПоследнегоИзменения.
2. Создайте ПодпискуНаСобытие с событием ПриЗаписи для нужных видов документов.
3. В обработчике события реализуйте логику записи текущей даты в регистр:

Процедура ЗафиксироватьИзменениеДокументаПриЗаписи(Источник, Отказ) Экспорт
    Если Отказ Тогда Возврат; КонецЕсли;
    
    // Получаем набор записей регистра сведений
    НаборЗаписей = РегистрыСведений.ДатыИзмененияДокументов.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.Документ.Установить(Источник.Ссылка);
    
    // Записываем текущую дату
    Запись = НаборЗаписей.Добавить();
    Запись.Документ = Источник.Ссылка;
    Запись.ДатаИзменения = ТекущаяДата();
    
    НаборЗаписей.Записать();
КонецПроцедуры

Важные рекомендации по производительности

Чтобы реализация была максимально эффективной, следуйте этим советам:

Индексация: Если вы планируете часто делать выборки по дате изменения, обязательно установите признак Индексировать для поля ДатаИзменения в регистре сведений. Это позволит СУБД выполнять поиск практически мгновенно даже при наличии миллионов записей.

Минимизация блокировок: Старайтесь, чтобы логика записи в регистр была максимально лаконичной. Не производите внутри подписки тяжелых вычислений или обращения к другим объектам, так как это расширяет время блокировки транзакции записи документа.

Подводя итог, можно сказать, что использование РегистрСведений является стандартом для таких задач. Это решение масштабируемо, удобно в обслуживании и не создает избыточной нагрузки на основной объект системы.