Задача: при изменении (удалении) записи в РС необходимо производить запись в журнал регистрации об изменении (удалении).
Метод решения: сравниваем запись до изменения и измененная запись. Если есть изменения, то записываем в журнал информацию. Если запись удаляется, то записываем в журнал.
Проблема: Запись происходит в два этапа. В первый этап записывается пустая запись, во второй измененная запись.
Вопрос: как отследить что происходит: изменение или удаление?

Всегда происходит удаление, потом запись.

Т.е. задача нереализуема?

ДополнительныеСвойства?

ДополнительныеСвойства при втором этапе оказываются пустыми. Переменная, объявляемая в модуле набора записей тоже "обнуляется"

В БСП есть сериализация и в платформе с 13 вроде релиза есть сериализация....

Запись в журнал через подписку...

+(5) История данных в закладке Свойства в конфигураторе...

А почему именно в журнал?

(5) Если запись удаляется, где смотреть историю?

+(6) А нет ,подписки нет, только в модуре набора записей

(0) (1) перед записью набора сделать дополнительное чтение по отбору записываемого набора записей и сравнить записи.
удаление это запись очищенного набора(значит было чтение с отбором)

В БСП остается, там кроме гуида ещё есть поле Представление.

если сотрешь Справочник, написер, сохранится в БСП его стандартное представление.

(8) Есть другие предложения? Принимаются.

1.БСП - версионирование
2.РС- свойства -История данных
3. Самому в XML выгружать как и в БСП.
4. Машина времени. Я когда-то делал.

Машина времени - предполагается что РС новый, иначе запросы переписывать придется.
В измерения твоего РС добавляешь ВерсияЗаписи(Чип число, целое).

Регистр никогда не стирается, а дополняется новыми записями. В измерении ВерсияЗаписи указываешь номер текущей версии записи плюс один.
Добавляешь ПВХ КлючАналитикиИзмерений,
Добавляешь РС: КлючАналитикиИзмерений, НомерВерсииЗаписи (периодический) - из него будешь получать актуальные версии на свою дату и по номерам версий узнаешь какие записи РС актуальны на любой момент.
Можно применять для больших загружаемых объемов если в них не очень много правят.
Плюс сможешь формировать любой отчет прошлым не поднимая бэкапа.
Минус решения - не работают СрезПервых и СрезПоследних.
Система хранит все состояния РС на любой момент. Т.е. можно формировать отчет как "из настоящего", так и вернуться в 9 утра и оттуда сформировать. В запрос все равно надо передавать момент, на который определяешь  актуальные версии записей.

"из него будешь получать актуальные версии на свою дату" - СР.Срезпоследних(ТекущаяДата()) ну или любой другой момент времени.
Потом по этому набору вытаскиваешь записи из основного РС

Да, основоной РС не периодический, если основной РС периодический ,то можно просто измерение добавить и в самом запросе вычислить какие записи РС актуальны соединяя РС с самособой. Немного ресурсоемко, но зато без бэкапов ныряешь в любую точку времени.

Т.е. для периодического основного РС второй периодический РС и ПВХ КлючАналитикиИзмерений не нужны.

Хех :) Если при записи в модуле набора записей количество записей равно нулю, а модифицированность = Истина - то это удаление.

Нужно только написать небольшой запрос, который вычисляет данные как в срезеполседних и какв срезе первых и помещает их а МенеджерВТ

*(20) Тьфу оговорился :) - перед записью.

Гопнический вариант предлагаю - завести реквизит в регистре, в него писать ссылку на справочник, заполнять элемент справочника значениями полей записи регистра. И версионирование на этот справочник повесить.

В (1) правильно написано. Но: удаление выполняется записью "пустого" набора. Почему автор решил, что миссия не выполнима? Пустой набор не означает пустой отбор.

(23) Версионирование хоть в БСП, хоть в Истории значений сжатое или поэксемеленое.
Совреиенные запросы 1С не умеют с этим работать. Потом обрабатывать записи как? Распаковывать версионирование? Очень медленно

(25) А зачем распаковывать да еще и быстро? Какой кейс решается?

Задача автора решается промежуточным буфером: при записи пустого набора пиши в него что запись с таким-то ключом (отбором) удалена. Если это действительно удаление, то инфа в буфере будет истинной.
Если это обновление, то в буфер запишешь еще одну запись и таким образом там тоже будет истинная информация содержаться.

Но изменение ключа у записи таким образом не отловишь. А вот по варианту (23) - легко )

Ну и (16) что-то такое тоже предлагает, полагаю - хранить где-то отдельно исходный ключ

(26) Поработать с историей данных полноценно.  первоначально, если речь о журнале - момент появления записи.
Второе - момент любой модификации записей с произвольным отбором по свойствам и/или категориям.
Третье - удаление
Четвертое - повторная запись того же набора.
например с периферии льют эксели или xml или вебсервисами. Или даже через интерфейс операторы бьют. Но потом удаляют или подправляют. От этого меняется общий результат. На 10 утра было так ,а на 12 стало иначе. Вот надо знать что где меняли и сколько раз.
Написать запрос в РС. Ну просто перебором в цикле всех записей не вариант, количество записей - это перемножение активной аналитики разных измерений. Это много очень.

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

Или сам сидишь и следишь как загрузки идут, или в обед формируешь отчет с периодичностью каждые 15 минут. И знаешь когда что кто загружал.

Плюс просто можно посмотреть записи, у которых версия больше 1

Спасибо всем.
Историю данных пытался включить, но почему-то вываливается с ошибкой что нет реквизита РазделениеДанных. При чем тут он еще не разбирался.