Добрый день.

В коде найден комментарий:
"The method saves the facility to which the transaction is assigned. There is one criticial point here. In the case of an reversal of the financial transaction, the data is still changed at this late event of the application. Since there is no other possibility to prevent bad data on the database, an error in this application state has to abort the whole technical transaction and force a database rollback."
И далее в коде в случае ошибки идет message X.

Почему не сделать ROLLBACK WORK. MESSAGE E. ?

Обычно запись в БД делается в модуле обновления V1, поэтому rollback нельзя вызвать

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

1) Если этот код внутри V1 модуля, тогда:
Если сменим тип сообщений, то БД останется консистентна, но не будет возможности узнать что была ошибка в ST22.
2) Этот код уже после запуска V1 модуля, тогда:
БД и сейчас приходит в неконсистентное состояние, не будет возможности узнать что была ошибка в ST22.

Как сделать более человеческий интерфейс без дампа с возможностью иметь данные об ошибке?

1) В общем случае консистентность может нарушиться (после вашего модуля с ошибкой могут идти еще и другие)
2) Так не должно быть, нигде такого не встречал
По уму надо делать все проверки до V1, не запускать V1 если выявлены ошибки

Не буду спрашивать кто и почему так сделал, наверное были причины реализовать именно так...
Судя по комментарию, похоже что у Вас случай 2. Мессадж Х по-моему нормальное решение. Альтернатива сливать сообщения в системный журнал SLG0 или может экспресс письмо отправить.
Как слить в журнал дампов и при этом не показать дамп не знаю, что то типа MESSAGE X004 DISPLAY LIKE 'E'. Насколько помню не работает.

А чем не нравится дамп?

Сделано это в стандарте: CL_IM_FTR_TR_FACILITY~EVT_TRANSACTION_SAVE_READY.

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

Судя по комментарию дамп обеспечивает возможность не сохранения кривых данных. Тогда это случай 1. Или я неправильно перевожу?

Так это еще и стандарт?? А может не надо ничего трогать?
Изначально я ориентировался на Ваш первый пост, я не знал и не знаю для чего бади FTR_TR_FACILITY CL_IM_FTR_TR_FACILITY~EVT_TRANSACTION_SAVE_READY, что делает и тд. НО я понимаю Вашу проблему так.
Этот метод, сохраняет какие то доп данные для какой то фин транзакции, этот метод содержит критическую точку(то есть по сути они сами понимают что, это не правильно, но другого решения нету, такое бывает(может БП специфичный какой то)). При этом дампе, основные данные по транзакции уже изменены и останутся измененными, но дополнительные не лягут в базу, откатятся.
Вы разве не проверили этот метод, точку прерывания в нем не ставили, разве видно что он выполняется в обновлении??\

Все имхо.

Если не нравится дамп - нужно устранить причину его появления, а не само сообщение.

Всем спасибо!

Я не могу запускать данные транзакции и проверять все сам, нет полномочий.

В итоге выдал рекомендацию как и Удав. Проверять ситуации в другом методе.