Увы. Такова логика работы всей системы.
Впринципе подойдет реализация через события для workflow

Галка отслеживается на уровне ядра AS, а не на уровне ABAP.

Тригера по изменению/удалению/вставке записи в SAP-е, как уже говорилось, нет.
Однако, правильная идеология написания программ состоит в том, чтобы не писать INSERT/UPDATE непосредственно в программах, где требуется сохранить данные в таблицу. Вместо этого следует вызывать специально изготовленный Функциональный модуль (т.н. API), внутри которого и будет реализована логика записи в БД.
Тогда именно этот модуль и будет выполнять функции того тригера, о котором Вы говорите. Туда Вы всегда сможете дописать и заполнение TIMESTAMP и вызов события WORKFLOW и всё, что потребуется.

В общем, читайте курс BC414

Как я понимаю, необходимость заполнения данного поля TIMESTAMP требуется для некого дальнейшего z-анализа, поэтому оперативность заполнения в данном случае не является приоритетной.

Если так и есть, то как вариант решения.
1. Как уже писалось в обсуждении - в тех.настройках Z-таблицы проставляется опция "Запись в журнал изменений".
2. Пишется z-отчет - анализ таблицы журнала DBTABLOG для данной z-таблицы с заполнением поля TIMESTAMP
3. Создается Job на основе этого отчета, с необходимой периодичностью.

Что-то жестко. Зачем тогда вообще это поле нужно, если есть DBTABLOG? Это сложнее и менее надежно, чем найти INSERT/UPDATE и вставить там свой код. К тому же DBTABLOG будет расти...

Ну я отдельно выделил "необходимость заполнения данного поля TIMESTAMP", так как полностью процесс не был озвучен ТС. Понятно, что для учета изменений, галка в свойствах таблицы и SCU3 решают.
А почему Вам кажется, что это решение менее надежно? INSERT и UPDATE вполне могут вызываться динамически, и найти такие вызовы очень затрудительно. Данное же решение работает по факту изменения данных, неважно в каком процессе эти данные были изменены. При этом является автономным.
DBTABLOG действительно всегда увеличивается, но так как задание будет периодическим, кто мешает обрабатывать дельту ?

1.Потому что job.
2.Потому что анализировать dbtablog долго. Пока считывается информация, данные могут обновиться.

Хотел бы я посмотеть в глаза разработчику, который сохраняет данные с помощью динамического INSERT

А что с Job не так? Корректность же обработки анализа dbtablog зависит от логики отчета - все в руках разработчика.
Имелась ввиду конструкция вида, INSERT (dbtabname) FROM wa, где имя таблицы определяется динамически.

То, что момент запуска отличается от момента записи в таблицу. И анализ dbtablog - зачем все усложнять?

Я в курсе, что имелось в виду
Только зачем так делать в случае со своей таблицей?

Я уже писал, что это решение применительно конкретно к задаче "записать timestamp-поле при изменении z-таблицы".
Про разницу моментов не понял. Ну если есть такая техническая возможность, почему нет? Может гдето и удобно такую конструкцию выхова использщваоть. Ну это отвлечение от темы.