А вот тут никогда ни не попадали в режим просмотра переменной CODE, в этот режим можно попасть выбрав конкретную запись:

Далее уже попадаем в отладчик, но в новых системах мы попадаем в метод:

Вот в этом методе жмем F7 и попадаем уже в модуль с доступом к переменной CODE

 
В более ранних системах, до 7.40 вроде как сразу попадаешь в модуль где доступна переменная CODE.

>>Запустите браузер данных необходимой таблицы. (se16, se11).
С каких пор SE11 стало браузером данных? :)
 
В SE16 у меня это не сработало, не вижу переменную CODE. Базис 7.40.

Интересный вариант решения. Возьму в инструментарий.
Хотя конкретно данную задачу я решал бы добавлением в схему калькуляции своего вида условия (без последовательности) и написанием формулы для него. Новый вид условия имел бы приоритет над PB00. Такое решение более привычно (ожидаемо) для консультантов, особенно для сторонних, которым нужно разобраться с тем, что уже сделано. Видишь "левый" вид условия, смотришь формулу (или просишь абапера, если сам не разбираешься). В одном месте вся логика.
Впрочем, это мое мнение, за всех консультатов не отвечу.

Если идти по первому пути, то мы получим высокую связность между объектами: вью будет знать с какой он работает моделью. Передавая данные модели через контроллер, мы убираем эту связь. Только контроллер продолжает знать, с какой моделью он работает. По хорошему, конечно, я должен был получить ссылку на таблицу модели в контроллере и передать ее уже вью. Но я не вижу смысла в таком финте: создавать get метод в модели, запомнить ссылку на таблицу в контроллере, потом ее передать дальше. В случае нескольких моделей это имеет смысл...
На счет нарушения инкапсуляции, согласен. К сожалению, до версии 7.40 очень громосткий код получается, если писать все по канонам. Но опять же, это один из примеров реализации, который каждый может доработать под себя.

>>"Самое главное - это расположить инклуды с моделью и представлением до инклуда с контроллером"
 
А может проще написать в начале что-то типа:
CLASS: <имя> DEFINITION DEFERRED,
       <имя> DEFINITION DEFERRED,
       <имя> DEFINITION DEFERRED.
 
И тогда будет все равно как оно там дальше в инклудах находится.

Необходимости нет. По-хорошему во view должна быть ссылка на модель и view должна сама брать данные из модели. А из модели уж как угодно можно данные выдавать или как атрибут или через метод (зависит от того насколько надо абстрагироваться). Тогда и контроллер не будет зависеть от структуры модели. В контроллере должна быть только настройка связи между view и model.
 
Не совсем правильно, потому что такая передача нарушает инкапсуляцию внутренностей объекта модель, контроллер "знает" как устроена модель, хотя, по идее, ему должно быть всё равно, что внутри модели. Если конечно придерживаться концепции пассивной модели, то и передача через контроллер выглядит нормальной, так как вся бизнес логика всё равно будет сосредоточена в контроллере. А если делать контроллер по всем правилам, то в нём должна быть только логика управления связями между остальными объектами и маршрутизация сообщений в их обработчики. Для простого ALV отчета, это правда уже перебор.

Цифры получаются не после внедрения системы, а по итогам всего проекта (система, методология, служба, нормализация объектов НСИ).
Поделитесь опытом, какой профит по-вашему мнению от проекта НСИ, какими показателями его можно оценить?

Who "simply the best"?

Знаю, практически со всеми основными продуктами, представленными на рынке, работал.

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

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

Есть еще решения и других вендоров...

Опыт проектов + некоторые открытые данные.

Согласен, что нормализация начинается с методологии,но также необходимо понимание Бизнеса, что он хочет и для чего.
Параметрическая классификация - это Вы имеете ввиду свойства и значения ТМЦ? Тогда здесь хочу уточнить фразой из статьи:
"Невозможно поддерживать и развивать фасетную классификацию всего справочника ТМЦ, т.к. потребности бизнеса всегда будут расти и изменяться, следовательно, должен будет меняться и классификатор, и все позиции в нем."

Поиск аналогов как раз в MDM проще реализовать, чем в MDG.

На основе чего получены данные цифры?

НОрмализация ОЗМ начинается с грамотного методолога и выявления типовых проблем. Почему 2 года справочник чистили - вообще не понятно, работы для "маленького заводика" - максимум на полгода, за год весь Газпром можно вычистить, или корпорацию сопоставимого масштаба (был такой опыт).
А проблемы основные -
1. Дублирующиеся записи
2. Неполные записи
3. Некорректные записи
4. Противоречивые записи
5. "Абсурдные" записи
Хорошо помогает параметрическая классификация с прошитой в интерфейсе  обязательностью, а также хорошая трудовая дисциплина.