Всем добрый вечер.

Хотел спросить, можно ли инициировать заполнение таблиц CDHDR, CDPOS в момент удаления объекта (не МТКУ, а физически) из системы?
В AUT01 нашёл только возможность по опред. полям отслеживать изменения, а интересует именно запись о полностью удалённых объектах (для синхронизации с внешней системой).
Заранее спасибо.

...в частности по трассировке вижу, что ещё пишется в таблицы VBHDR, VBMOD, VBDATA, но сразу же и удаляется по ключу после удаления самого объекта из системы. Т.е. предположу, что их предназначение в возможности осуществления роллбэка, если что то пойдёт не так в процессе удаления. Как вариант, думаю, что можно было бы до логов БД добраться из open sql и там взять данные, но что то не нашёл примеров, чтобы так можно было сделать(не уверен, что это вообще возможно). Ещё нашёл интересную связку таблиц BALHDR, BALDAT, но как там выйти на конкретный объект - не понятно.

О каких объектах системы идет речь?
Для Z-объектов мы использовали свои объекты изменений и в модуле обновления фиксировали все операции - создание, изменение и удаление.

А поле CHANGE_IND разве это не показывает?
D - delete. В тестовой системе проверил. Объекты, которые журнализируются, прекрасно получают это значение.
В таких случаях в FNAME обычно красуется KEY (то есть удаление ключа самого объекта).
Пробежался чисто визуально по классам объектов - вижу очень много всего, что при удалении журнализируется (предварительно зарегистрированные документы, полномочия, группы МВП и пр.)

О стандартных PS - проекты (proj), СПП-элементы (prps), сетевые графики (afko), операции (afvc).

Часто показывает, но не всегда. Если объект удалился со статусом ОТКР (и других не устанавливалось), то не пишется запись.
Я подозреваю, что есть где то настройка, но в силу неопытности, не знаю, где.

Заметил также, что если объект с ACL, то пишется всегда (даже для ОТКР) в таблицу PSGUID, но это тоже не покрывает "не-ACL-ные" объекты.

Я нашёл ещё таблицу DBTABLOG, по идее там есть нужная информация.
По крайней мере туда вроде бы всегда записи попадают, но как их можно интерпретировать, чтобы понять какой конкретно объект удалялся?
В частности, нашёл, что поле LOGDATA используется в отчёте RADTTCHK, но это не очень помогает.
Вообще это же стандартные объекты - насколько знаю, достаточно "галочки" на ДокумИзменений в транзакции OPSA, но почему не отрабатывает с ОТКР?

Тут одно из 2-х - либо DBTABLOG(Галочка в технических свойствах таблицы), либо объекты изменений(отдельные ФМ при обновлении данных).
DBTABLOG обычно используется для небольших таблиц, т.к. сильно влияет на скорость записи в БД. И вытаскивать информацию из нее намного неудобнее, чем из CDHDR/CDPOS.

А можете подсказать, как это сделать? Какие то ФМ под неё есть? А то из CDHDR/CDPOS можно и простыми селектами обойтись, а там как быть - не очень понятно (т.е. кроме составного ключа я ничего не смогу узнать?).
Ну и ещё вопрос, насколько вообще оправдано использование журналирования через dbtablog в продуктивной системе? Мне кажется, это будет давать достаточно ощутимую загрузку в случае ведения нескольких таблиц.

См. транзакцию AUT10 в экспертном режиме. Она и из объектов изменений, и из dbtablog читает.

Неоправданно в случае журналирования переменных данных (таблиц с документами, основных данных).
В случае настроечных таблиц, которые изменяются редко, можно использовать.