Что касается ауканья  - был прецедент, после "законных" действий программиста шла очень длительная активация, случись такое на продуктиве - была бы авария.
Всем материалам - не могу такого придумать, не верю. Длинный текст и так есть в ОЗМ, даже несколько. Более 12 лет работаем c R3 и как то без расширений.
Далее к нормализации данных - согласитесь, кроме минутной выгоды,в упрощении получения отчета,Вы оставили за бортом вопросы нормализации данных. После этого, все ОЗМ пожизненно награждены доп.аттрибутами, нужны они там, или не нужны. Далее велик соблазн еще и еще применить такое решение, и только потом дозреть до классификации.
За бортом остались вопросы архивации, средств поиска, экстракторов BW и других объектов SAP.
Резюме - если SAP пишет ноты, то кто-то ими пользуется. С моей точки зрения - расширение фундаментальных объектов SAP порочный путь

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

Судя по всему, у Вас нет опыта работы (не говоря уже о внедрении) с масштабными системами, где заводов может быть более 200 и в каждом из них до 50 складов (и они не материально ответственные). Подобная загрузка LSMW применима не только для решения реализации мат.ответственных лиц через ММ. А касательно, самого решения: оно простое и понятное.
 
Зато, судя по комментариям к другим статьям и к моей,  есть опыт ворчания с простановкой смайликов и знаков препинания в хаотичном порядке; и еще опыт работы, с каким-то загадочным местом. Боюсь, здесь тягаться не могу да и не хочу.

Ааааа, это вы увлекательный процесс реализации матответственных на ММ через склады реализовали, пропустил это предложение к сожалению, так как читал давно, а вопрос написал только на днях? Ну так это решение через одно место, не буду говорить какое, но слова счастье из него сложить сложно... хотя смотрю до сих пор многие этим и занимаются :-)
 
PS: По поводу точки после, хотелось бы знать причину, это все таки был вопрос, а не констатация факта :-)

А если перешли с компа на комп?
Жесткий диск с операционкой с собой брать? )))
Single Logon - это с помощью SNC ?

Для целей Copy-Paste привожу код скрипта elogon.txt в текстовом формате
 
// ----------------------------------------------------
// Очищаем поля от значений по умолчанию
// ----------------------------------------------------
Set F[RSYST-MANDT] // Делаем поле "Мандант" пустым
Set F[RSYST-LANGU] // Делаем поле "Язык" пустым
Set F[RSYST-BNAME] // Делаем поле "Пользователь" пустым
 
// ----------------------------------------------------
// Данные для входа в систему
// ----------------------------------------------------
 
offset (0,95) // Делаем одну отправную точку
box (0,0) (18,45) "Входе через флеш-накопитель" // Создаем набор опций-альтернатив для продуктивных пользователей
text (1,1) "Test MyUsers" // Делаем текст, что это мои пользователи
radiobutton (2,1) "MyUSER - Russian" F[RSYST-MANDT] 200 F[RSYST-BNAME] "MyUSER" F[RSYST-BCODE] "MyPassword" F[RSYST-LANGU] RU // Мой вход на RU
 
radiobutton (3,1) "MyUSER - English" F[RSYST-MANDT] 200 F[RSYST-BNAME] "MyUSER" F[RSYST-BCODE] "MyPassword" F[RSYST-LANGU] EN // Мой вход на EN
 
radiobutton (4,1) "MyUSER - German" F[RSYST-MANDT] 200 F[RSYST-BNAME] "MyUSER" F[RSYST-BCODE] "MyPassword" F[RSYST-LANGU] DE // Мой вход на EN
 
// Больше моих логинов нет
 
text (6,1) "Test users" // Начался набор тестовых пользователей
radiobutton (7,1) "TSTUSER01 - Закупка" F[RSYST-MANDT] 200 F[RSYST-BNAME] "TSTUSER01" F[RSYST-BCODE] "Password" F[RSYST-LANGU] RU // last edit 11/10/2011 +
 
radiobutton (8,1) "TSTUSER02 - Сбыт/фактуры" F[RSYST-MANDT] 200 F[RSYST-BNAME] "TSTUSER02" F[RSYST-BCODE] "Password" F[RSYST-LANGU] RU // last edit 11/10/2011 +
 
radiobutton (9,1) "TSTUSER03 - Сбыт/заказы" F[RSYST-MANDT] 200 F[RSYST-BNAME] "TSTUSER03" F[RSYST-BCODE] "Password" F[RSYST-LANGU] RU // last edit 11/10/2011 +
 
radiobutton (10,1) "TSTUSER04 - ДеблокЗкзПоста" F[RSYST-MANDT] 200 F[RSYST-BNAME] "TSTUSER04" F[RSYST-BCODE] "Password" F[RSYST-LANGU] RU // last edit 11/10/2011 +
 
radiobutton (11,1) "TSTUSER05 - ДеблокирПроекты" F[RSYST-MANDT] 200 F[RSYST-BNAME] "TSTUSER05" F[RSYST-BCODE] "Password" F[RSYST-LANGU] RU // last edit 11/10/2011 +
 
// ----------------------------------------------------
// Создаем кнопку для заполнения полей и входа
// ----------------------------------------------------
 
offset (7,25) // отправная точка для кнопки
//По нажатию на кнопку будет происходить заполнение полей и вход в систему
pushbutton (0,0) "  OK  " "/0" size=2

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

0. Все то оно конечно правильно, но я бы первым пунктом поставил отсутствие консультантов у интегратора, выполнявших первое внедрение, к моменту продажи второго. Консалтинг это прежде всего люди, а они имеют свойство перемещаться, поэтому если компания А внедрила успешно продукт в компании В, то это не значит, что она седлает это так же успешно у вас, по причине того , что консультанты внедрявшие это решение уже давно сменили место своей работы, поэтому я бы рекомендовал прежде всего узнать кто внедрял решение в компании В и будут ли эти же специалисты делать внедрение у вас. Поверьте чаще всего это уже будут другие люди и 99% что и другие знания.
 
1. Платим дважды, да к сожалению это наверное 95% внедрений, а потому что так проще и идем по накатанной схеме, чем разбираться как же оно на самом деле работает. Кстати, тут так же большая проблема интегратора, так как консультанта стараются загрузить на 120% и соответственно времени на изучение функциональности, исследования системы, у человека просто нет времени, поэтому и заталкивают консультанты, то что уже где-то было проверено и фиг с ним что криво или пусть абапер допилит, потому что - ВРЕМЕНИ НЕТ!
 
2. Ну тут ответ один, требуйте документацию, причем если вы ее получили и ничего не поняли, требуйте чтобы ее привели в понятный вид, чтобы было описано, что сделано, как сделано и зачем было сделано. Пригласите специалиста со стороны, если не имеете своих, чтобы он оценил написанное и сказал ясно было ему это или нет. Денег это потребует не много, а пользы дальше вам же будет вагон.
 
3. А вот это вот про баги не надо и про отделы тестирования больших компаний тоже.. как говорится, кто не видел абаповский код стандарта, тот пусть постоит и покурит в стороне, а потому что нервных просим не смотреть :-).
 
4. Ну это опять же проблемы из пункта 0  и 1, времени на приведение разработки к вменяемому виду нет, разрабатывали действительно под одного клиента и т.д. Мне в свое время как-то предложили поучаствовать в реализации одного пакетного отраслевого решения, после внедрения на одном из проектов. Отказался, объяснив, что отраслевое решение, могу начать делать, после внедрения этой функциональности ну как минимум после 3-4 клиента, тогда у меня будет опыт и представление, а один клиент это никакое не отраслевое, а частные докрутки.

Путано получается, надо проще! Да и название Лабораторные/Полевые - неправильное. Все же не Полевые а Боевые.
 
Лабораторные / Боевые
 
Ассоциативно может показаться, что боевые обязательно должны быть лучше, но чтобы лучше представить я уточную параллель.
 
Допустим бизнес – это пушка, а ERP система – это конвейер для быстрой подачи снарядов (по техническим причинам снаряды лежат не совсем рядом). В этом случае вид и форма боевого конвейера зависит от рельефа местности. Но обратите внимание, что для другой пушки тот же самый конвейер может не подойти. Если мы воюем на ровной поверхности, то всегда подойдет, но даже в той же отрасли новая компания находится на другом месте и там другой рельеф.
Боевой конвейер можно переместить к другой пушке, отпилив все лишнее и укрепив дополнительными подставками, однако есть шанс, что после того как мы отпилим все лишнее выясниться, что у этой самоделки нет каркаса и она не жизнеспособна.
Лабораторный конвейер, конечно разрабатывался на ровной местности, но его сразу пытались сделать таким, чтобы и в овраге при небольшой допилке, он бы смог работать. Конечно жизнь преподнесет нам совсем другой овраг, и все конструкция лабораторного решения имеет жесткий хребет и есть шанс заставить его работать в новой местности.
 
Второй вариант анологии – это вакцина. Бизнес – живое существо, болезнь – это человеческий фактор. Боевая вакцина конечно эффективна, но только для конкретного штамма вируса. Другая фирма – это другие особенности и люди используют их иначе в свою пользу. Это тоже человеческий фактор, но он имеет другие проявления – другой штамм. Боевую вакцину исправить сложно, вот новую лабораторную, которая сразу делалась для уничтожения различных вирусов натравить на новый вирус проще…

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