Есть непереодический регистр сведений, не подчиненный регистратору. У него есть реквизит Дата актуальности записи, который отображает дату последнего изменения данных записи в регистре. Я бы хотел централизованно устанавливать эту дату, каждый раз, когда в регистре что-то меняется извне. Обычно это происходит, когда загружается свежий набор записей, либо редактируются существующие записи. Мне бы не хотелось чтобы программисты в системе думали о том что им надо как-то контролировать изменилась ли запись и обновлять эту дату актуальности. Может я вообще захочу ввести другие правила учета этой даты актуальности?

Идеальным решением я видел перехват момента записи в обработке "ПередЗаписью" в модуле регистра и проверка записи на изменения. Как это, например, делается с объектом справочника или документа, но этот вариант несостоятелен, потому что при записи набора сначала записи удаляются, попадая второй раз в обработчик "ПередЗаписью" - у меня уже нет слепка предыдущей записи.

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

Еще есть вариант перед очисткой записей в момент записи сохранять куда-то состояние всего регистра, а потом вычитать его состояние в момент записи, получая таким образом состояние удаленных записей, но это порнографией попахивает уже.
И это я еще про блокировки не думал...

Может у кого будут еще мысли на этот счет, либо опровергните/подтвердите вариант с регистратором. Как методологически было бы верно поступить в такой ситуации?

(0) для объектных сущностей, вроде Спр или Док, очевидно как контролировать дату актуальности и как сравнивать историю изменений.
а для наборов записей по отборам задача становится нетривиальной на низком уровне. проще всего, поднять уровень абстракции и написать программный интерфейс в общих модулях и общих формах, чтобы в РС записи падали не наборами из хз откуда, а вызовами твоего общего модуля, ну или модуля менеджера РС и свои самопальные формы (не автоматической генерации).
...
и через 3-5 итераций мы получим кривой прообраз ЗУПа. оно вам надо?

(1) Про подъем уровня абстракции я тоже думал, но ведь всегда найдется умелец, который наворотит своих велосипедов и тут остается надеяться только что он с этим ревью не пройдет, но тут уж как повезет.

На счет ЗУПа ничего не могу сказать, но видимо они к этому пришли. И похоже это один из способов решения задачи. Что в этом плохого?

Для чего нужна эта дата последнего изменения?
Подними уровень постановки задачи, и опиши бизнес задачу.

А так да, напрашивается объектная сущность, например документ.

Странные вопросы. Не описал даже структуру регистра. Есть ли ресурс, сколько измерений и т.п. А уж про описание изначальной задачи я молчу. Выдрал кусок мучений без контекста и ждёт ответа. Без кофе гадать сложно

(0) Вы можете "Перед Записью" сравнивать данные, которые будете вносить, с имеющимися наборами. Если такие данные уже есть в регистре - можно ничего и не вносить.
Регистратор для этого не нужен

(0) Может историю данных включить? А там ВыполнитьОбработкуПослеЗаписиВерсий()