Трёхуровневая архитектура (разработка, тест, продуктив). Есть актуальные данные в продуктиве. В систему тест заносятся данные с опозданием на месяц. К актуальным данным в продуктиве мне закрыли доступ транзакциям se11 и se16. А в тесте нету последних данных чтобы протестировать. Есть какая нибудь транзакция вместо se11 и se16 для просмотра таблиц? Как можно обойти?

Еще можно проверить SQ00, SQVI, SE16N, SM30, SM31

se12, se16n, se17
Но лучше объяснить, что вам важны свежие данные для тестирования.

по-моему проще поменять работу из-за таких дебилоидных практик.

По всей видимости лениво (или объемно) делать свой тестовый пример в тестировочном манданте

На все перечисленные транзакции закрыты доступы.
В тесте не могу завести проводку, не получается. Все делаю по инструкции, все равно не получается.

Ну так а в чем проблема? Елси это ваши должностные обязанности - вперед к своему начальнику со скрином su53 и вперед садиться на шею базисникам чтобы дали полномочия.
А если и протестить нельзя как работать-то?

Содержимое таблицы когда закрыт доступ еще иногда можно посмотреть через search help (список доступных значений для ввода). Еще можно спросить про ошибку при проводке (может быть закрыт период, контировка и пр.)

Добрый день!
А вот попытайтесь объяснить, зачем разработчикам доступ в продуктивную систему? Но если вы там есть , то у вас права должны быть как у конечных пользователей + права на настройки, которые делаются только в продуктивной системе, а так все импортом в продуктив. Есть график обновления тестовой системы (надеюсь), а если считаете устаревшими данные, то создайте свой тестовый пример и протестируйте свое творение в тестовой системе, а не перекладывайте свои проблемы на базис и не засоряя продуктив лишними транспортными запросами.
Не спорю, что иногда необходимо прямое и неотложное вмешательство на продуктивной системе, но для этого у вас должно быть особое разрешение от руководства . Иначе, как потом будет отчитываться базисник за неделеные вам права. Конечно проще все свалить на базис, мол права урезают и прочее......., а если бы не было такого , то во чтобы превратилась продуктивная система..........

Легко. Количество документированных вещей в системе и недокументированных находится в соотношении типа 1 к 1000000. Т.е. практичски без вариантов нужно смотреть код, чтобы понять почему в данном месте системе поступает именно так. Тот кто смотрит код - разработчик (хотя понятно. что и консультанты это делают - можно сказать в этот момент они выполняют роль разработчика). Конкретного примера в тесте месячной давности нет. Искать аналогичный - нет не лень, просто долго (я могу хоть 10 лет на это потратить - но руководство же первым взвоет, что остальные задачи стоят).

На базисников никто и не наезжает

плохо кончите

Скиф, ты не пробовал чинить сложную проблему в системе без доступа к самой системе? Вот тут примерно также - как бы не старались консультанты смоделировать проблему в тесте, однако есть ситуации когда без доступа никак. Да и угадай с трех раз, что скажет клиент, если в ответ на 'срывается сдача налоговой отчетности' или 'встали платежи' сказать 'сейчас помоделируем ситуацию, посмотрим...'
А проблемы безопасности решают грамотным разделением полномочий

это не должно быть "легко", это форсмажор.
"грамотным разделением полномочий" - улыбнуло

p.s. сабж о se11/se16 то был. типовой собственно вопрос. и решается (если поискать) созданием ограничений по таблицам, записям (если ERP), и ручных авторизационных закладок.
"но попадаются нечестивые граждане которые кладут в этот..., не в вот в этот карман" (не помню откуда)
if sy-uname = 'Vasja'....

таких форсмажоров может быть за одно закрытие периода не один и не два. Там где я работал - закрытие периода это всегда аврал, и проблемы решаются в авральном таки порядке (а уж если годовое закрытие...). Виновата здесь организация работ, наше российское самосознание или Путин - не знаю, приходится просто жить со сложившимся положением вещей


Я имею ввиду что роль разработчика в проде в принципе должна быть только с ACTVT = 03, плюс доступ не у всех подряд. Понятно что это не спасет от просмотра зарплаты начальства напрямую в инфотипах HR, но HR вообще немного отдельный вопрос

Контроль качества разработок со стороны команды поддержки плюс показательная порка для пойманных снижает эти риски до некоего приемлемого минимума

[quote="ArmAnn"][/quote]
скучно обсуждать сабж - жевано-пережевано столько раз...
p.s. просто недавно проводил тренинг по ограничениям просмотра таблиц