При редактировании таблиц в se16n с активированным edit, sapedit и checkkey в некоторых случаях все равно не удается обойти проверку некоторых полей. Например, это поля tbcrt и tcdoc в pa3273. Есть какой-то способ окончательно и бесповоротно обойти эти проверки?

конечно есть - использовать нормальные ракурсы ведения, а не хакерскую SE16N

Не думаю что на таблицу pa3273 есть ракурс ведения. эта таблица инфотипов HR и должна вестись через транзакцию PA30

ну всегда же можно сварганить ракурс для Клуба любителей SM30, и даже Z-проверки в события ракурса натолкать какие надо.

просто сам подход, что в HR-е SE16N используется чуть ли не обычный рядовой инструмент пользователя, он видится печальным, и противоречащим немецкому "орднунгу". И к сожалению, наблюдаю его не на одном HR-овском проекте.
Походу, пора сапу в русский аддон специальную ноту выпускать, - рекомендации по использованию SE16N в ежедневной работе.

Коллеги, на стадии запуска проекта бывает полно ситуаций, из которых поддержка может выйти только в «ручном» режиме, особенно в HCM, особенно когда не у всех внедренцев руки прямые... В описываемом случае задним числом изменили временную привязку ит3273, в результате чего в таблице осталось множество записей с ненулевым seqnr. Исправить это можно двумя способами - абапить утилиту и исправить вручную. Выбор из двух зол, по-моему, очевиден.

а что, даже /h и отладчиком не обойти?


хз, в случае множества, предпочёл бы на z-ить (или сапквери сварганить быстро, и впилить в него по отобранному постобработку modify-commit).

В том и дело, что в отладке ставишь edit, sapedit и checkkey и все равно эти два поля продолжают чекаться по справочнику. Такая беда в reguh, там 5 таких косячных полей. Все бы ничего, можно эти поля скрыть в alv, и сохранять без них, но если в регухе эти поля не заполняются, то в ит3273 там могут быть данные, которые не надо потерять.

а разве se16n даст ключевое поле seqnr поменять?

Копировать-вставить в новую строку открывает все ключевые поля, меняешь как надо, старую запись удаляешь.