Добрый день!

Есть Дата прогона и идентификатор. Предложения нет и не было, прогона тоже нет. Задача - идентифицировать юзера, который ввёл параметры.

Спасибо!

Таблица REGUV. А вот как посмотреть, кто в нее влезал последним... Может быть через системный журнал посмотреть? Если искомое событие случилось не очень давно - то шансы есть.

Таблица REGUA. В ней приведена вся последовательность изменений от самого создания.

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

Если БЫ было предложение или прогон, то в SM37(журн.фон.заданий по-русски?) я бы юзера нашел. Но это если БЫ...

Тоже неверно. Если предложение удалено, то его следы в SM37 тоже удаляются. Вот такая ерундовина.

Вы правы, так что вопрос остаётся открытым.

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

Все равно ведь добьем.
Автор, как насчет таблицы FIALOG? У меня она пустая, к сожалению. Думаю, у всех также.
Но структура полей явственно говорит о том, что это то, что нужно.
В ключе PROGT, который может принимать значение "программа платежей" или "программа напоминаний".
Время, пользователь.
А первые три значения в справочнике к полю ACTION - это просто песня.
01 Параметры введены
02 Параметры изменены
03 Параметры удалены
Но шансов не очень много.

Тоже включал трассировку, никакие более или менее осмысленные таблицы в трэйсе вообще не затронуты.

Кроме вот такой.
Сами параметры лежат в таблице RFDT с ключом:
relid = 'FB'
srtfd = 'F110+дата+ид прогона<пробел>PARM'
Если сможете раскодить значение в CLUSTD, то там почти точно юзер будет.

FIALOG - Ну это и есть системный журнал, только он должен быть включен, и событие не должно происходить очень давно, т.к. он регулярно обновляется, там стек тоже ограниченный.
А по поводу RFDT-SRTFD - судя по всему, в таком же виде данных лежат в таблице STXL, и в фмнике READ_TEXT есть form convert_lines_bin_2_text, который умеет это читать. Я не настолько силен в абапе, чтобы сказать точно, что надо сделать, но любой абапер должен смочь адаптировать этот форм под чтение из другой таблицы. Попробуйте, может быть действительно там лежит имя пользователя.

Да, тоже так подумал. Только бы знать, как его включить. Судя по тому, что под это вынесена отдельная таблица, эта журнализация не имеет ничего общего с включением лога для CDHDR и CDPOS. И включается, видимо, где-то отдельно. Но как...?

А вот тут без понятия. Думаю - базнисники должны знать про включение.

Как думаешь, может ли прятаться в составе какой-либо функции в EHP, активируемой в IMG?