Можно и мне высказать сове мнение? По большей части касательно сути вопроса, а не самой разработки.

У всяких EY/PWC/KPMG все эти инструменты есть. Вряд ли они будут использовать непонятный Z для этого Хотя, какие-нибудь мелкие аудиторы...но все же, делать аудит SAP на Z выгрузке из таблиц, это конечно треш еще тот, имхо


[/quote]
Именно...
Я не против и не за Z велосипеды, обстоятельства бывают очень разные.
Данный инструмент, вполне вероятно полезен, на "колхозных" проектах (каких не мало, без обид), про что ты и пишешь - "нерабочие условия".

Позиция простая(имеется ввиду ABAP) - не можете предоставить тестовые сценарии, это Ваши проблемы, несите в продуктив под свою ответственность и там тестируйте, или решайте вопрос с руководством, пусть спускают задачу на базисников и тд.
На одном проекте, была "пустая" разработка, и без тестовой системы, сразу продуктив. Ну ничего, носили все в прод под свои риски. И не удивительно, ведь у них до этого, просто был только продуктив открытый для АБАПинга.
Вот в таком колхозе, твоя разработка бы и пригодилась
А в целом, не уже ли это такая проблема для базиса организовать тестовую систему с данными?

Касательно "носить запросы в тестовую систему", solman-charm, вроде это уже давно must have. Так там просто по кнопке переносится копия твоего транспорта и базисник не нужен. Я это к тому, что вполне допускаю, что в тестовой системе могут находится сложные тестовые сценарии, которых нет в разработке и это нормально, для таких случаев можно оперативно переносить.

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

В целом, то хорошо, что люди пишут Z утилиты и выкладывают их, как готовое решение или просто как идею, но все таки, как я писал ранее, закатить в SAP "левую" Z разработку для общего пользования, на больших проектах, это практически нереально. Никакой нормальный руководитель не пропустит 10-20-50 тыс строк непонятного Z в систему заказчика. Люди отвечают за каждую строку Z, и эта написанная строка является собственностью заказчика.

Аполитично рассуждаешь! Иногда даже в самых продвинутых средах бывается чего нить скосячило в проде, а на тесте повторить не могут. И чтобы перенести вот именно такой документик из прода в тест каждый раз бекап-рестор делать?

Давай не путать
Если не могут повторить, эту уже другой класс ошибок, с такими плавающими ошибками это отдельная тема как их решать.

Всё правильно говоришь, это не системное решение, а "колхоз". Собственно, с этого я и начал.
Эта утилита исключительно для личного пользования, когда разработчик с головой и понимает что делает.
Кроме того, это утилита для выполнения онлайн-запросов на Open SQL!

p.s.
Однако я не припомню проекта, где была бы сколько-нибудь вменяемая "песочница". А ведь в SAP такой ландшафт не зря придумали, понимали что делали. У нас же каждому ПМ-у и консалтеру приходится объяснять, что речь идёт не о тестировании, а о разработке и отладке, что программы вслепую не пишутся. И все эти Solman-ы не решают проблему. Я раз 50 запущу программу для отладки, прежде чем перенести её в тест. А если это будет 50 переносов с интервалом 10-15 минут (как настроен обычно Solman), это не работа, а издевательство.
Ну, а если попадётся совсем "непуганный" заказчик, как в нашем случае, то приходится брать в руки лом. Разумеется, потом и учётки выдадут, и полномочия, особенно когда их реально прижмёт. Но на это "отрезвление" уходят иногда месяцы, а потом начинается гонка - и крайний опять ты!

upd:
Переименовал тему.