Добрый день,

Появилась проблема - надо отследить "на лету" изменение данных в таблице, открытой на редактирование в SM30/SM31.
В САПовском конструкторе есть "Событие 5 - Creating New Entries", выстреливает оное просто отлично, а вот с изменением данных в уже введенных записях есть проблемы.
В конструкторе есть события 7 и 8 - Before/After Correcting the Contents of a Selected Field, но они, вопреки названию, срабатывают не при привычном изменении содержимого поля внутри редактора, а при весьма специфическом способе редактирования - Edit -- Change Field Content.

Есть ли способ перехватить событие редактора?

То есть, для примера, таблица из 3 полей:
VBELN RESULT CHANGED_BY

В SM31 есть возможность править поля VBELN / RESULT у записи. Как только поле изменено и нажат Enter - чтобы программным путем сразу изменялось и значение поля CHANGED_BY.

В Вашем случае это как бы системное поле, обычно их не показывают. Имхо, справедливо заполнять это поле при самом сохранение записи в БД. Еще вариант(может подойдет), смотреть в сторону документов изменения. Если включен аудит системы(а в продуктиве он скорее всего включен), то Вашей табличке нужно проставить опцию Log Data Changes, тогда будет видно кто, что и когда делал с таблицей (тр SCU3).

Да нет, поле CHANGED_BY было взято с потолка для примера, там на самом деле никак не связано с логином меняющего.

Просто надо на лету менять содержимое колонки А на основе изменений в колонке Б (эксель-стайл
Возможно ли это?

Вообще кто-нибудь работал с событиями в maintenance view?
Почему-то срабатывает только событие BEFORE SAVING TO DATABASE, а вот AFTER SAVING TO DATABASE - нет. Хотя таблица обновляется
(((

Заранее благодарю за любую помощь!

Да, работал. Конкретно для Вашей ситуации не использовал события. В моих случаях достаточно было завязать поля через внешний ключ. Может и в Вашем случае решается этим ? http://sapboard.ru/forum/viewtopic.php?f=13&t=70462&start=0

Попробуйте к 21-у событию прикрутить

Спасибо за ответы!



Да, но это же "fill hidden fields"?

По теме - пока что решил проблему топорно: сравнением таблицы после AFTER SAVE (оно таки выстреливает) с состоянием BEFORE SAVE, благо число записей будет невелико. Метод с созданием View интересный, но не подходит, там не только Foreign Key, но еще и калькуляции.

Срабатывает по ентеру, на hidden fields не обращайте внимания, можно любые поля перезаписывать. Вам ведь это и нужно если я правильно понял

Фантастика!
Никогда бы сам не догадался, что сумрачный немецкий гений именно так обозвал обработку измененных записей

Спасибо!