В данном случае передача таблицы в display скорее необходимость. Т.к. в конструктор передать changing параметр невозможно.
 
Вывод не только таблицы будет показан в дальнейшем.
 
"Не совсем правильно с точки зрения ООП" - хотелось бы немного аргументации...

1. Иван, разве обновление данных не должно происходить через контроллер (рис.1)?
2. Не описана обработка действий пользователя VIEW. Хочется видеть хотя бы самый простой пример.

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

у Вас в разработке по сути 2 view, независимых друг от друга:
1) это селекционный экран отчета
2) и экран ALV на базе класса cl_salv_table
и эти два view контролируются разными controller (1 - создается стандартно за кадром; 2 - создался Вами).
 
кроме того, Вы говорите
"данный шаблон отлично подходит (масштабируется) для отчетов с большим количеством всевозможных enjoysap control'ами с реализацией их взаимодействия.", а при этом используете упрощенный класс cl_salv_table.
почему?

Оно может конечно и зря сейчас напишу, но данная статья как мне кажется яркий пример интернет-ньюс-копирйтинга, ну т.е. вроде как и буквы все знакомые, и картинки есть, а вот в чем смысл? Не ну, что мыть руки после улицы перед едой и после туалета, это как бы мы все знаем, спасибо, что напомнили еще раз, может кому-то это помогло в этой жизни на этот раз. Хотя и тут, автор подошел, не без интересного подхода к процессу освещения проблемы, вот возьмем например - картинки. Берем первую картинку, я так понимаю, что если у филиала 3 бизнес процесс заключается в ведении договоров, то у филиала 2 это ведение 1С-а, а у филиала 1 ведение ERP, вопрос в студию и автору, куда они ведут 1С и ERP? В светлое будущее, хоть надеюсь?!
 
Лично меня бы в теме НСИ, особенно если учесть опыт автора в 9 лет, то интереснее было бы послушать какие-то примеры по решению проблем, с которыми сталкивался автор, как они были решены, чем были вызваны и т.д. Причем это может быть и локальная проблема конкретной организации, но это все же интересный реальный опыт и знания. Не поверю, что внедрение централизованного НСИ не вызывало никаких вопросов и шло всегда гладко и обыденно. В бытности, лет 17 кажется уже назад, вот один очень не маленький заводик сначала внедрения разрешил всем создавать ОЗМ кому какие надо, а через пару лет там в системе было такое, что пришлось начинать новый проект по нормализации данных ОЗМ, проект длился что-то под два года, пока привели в чувства справочник ОЗМ. Вот это было бы интересно послушать/почитать как нормализовали ОЗМ-ы.

Рафаиль, в плане показателей можно использовать:
 
• Уменьшение затрат на обеспечение качества НСИ (уменьшение количества корректировок в документах с 5 до 0,1%)
• Уменьшение затрат на ведение НСИ путем организации единой точки входа (сокращение затрат на ведение НСИ 10 - 50%)
• Уменьшение затрат на обмен данными между системами (в зависимости от кол-ва систем)
• Уменьшение затрат на подготовку отчетности (сокращение затрат на формирование консолидированной отчетности до 50%)
• Уменьшение складских запасов (снижение складских запасов на 0,5%)
• Уменьшение уровня пересортицы (снижение затрат на закупку 1—3%, снижение числа заявок на закупку аналогичных материалов  на 10%)
• Уменьшение сроков работ на разработку по выводу новых продуктов на рынок
• Уменьшение количества и масштабов хищений
• Уменьшение репутационных и финансовых рисков
• Повышение прозрачности и привлекательности компании
 
Окупаемость внедрения подобных систем 1-3 года. Рентабельность инвестиций (ROI) может достигать 150% за два года.

Кирилл, спасибо за статью. Для концептуальности статья тоже не дотягивает. В статье верно отмечено, новый подход гораздо шире смотрит на управление НСИ. Это не ряд автоматизированных функций для транзакционных справочников, а целый процесс, которых охватывает управлению совокупностью всех справочников. Очень правильно отмечена важность централизации и  интеграция. Но что значит управлять бизнес справочниками, как и что для этого нужно сделать, по моему мнению, в статье не раскрыто, а лишь обозначено.

Кирилл, спасибо за статью!
Хотел бы по последнему предложению в статье уточнить: Получилась очень абстрактная фраза - не хватает конкретных рекомендаций по расчетам прогнозного ROI подобного инвестпроекта и качественных показателей.

"Оно может конечно и зря сейчас напишу..."- Зря. Никакого копирайтинга здесь нет. Статья про концептуальный подход ведения НСИ, а не нормализацию ОЗМ.

у Вас в разработке по сути 2 view, независимых друг от друга:
1) это селекционный экран отчета
2) и экран ALV на базе класса cl_salv_table
и эти два view контролируются разными controller (1 - создается стандартно за кадром; 2 - создался Вами).
 
кроме того, Вы говорите
"данный шаблон отлично подходит (масштабируется) для отчетов с большим количеством всевозможных enjoysap control'ами с реализацией их взаимодействия.", а при этом используете упрощенный класс cl_salv_table.
почему?

Вы или не слышите или не хотите услышать...

Замечательно, т.е. не используйте стандартный подход MDM|MDG (кстати сейчас вроде как сама функциональность стала бесплатной), а используйте что? Ну вы же говорите изложили концепцию? Расшифруйте, я вот не смог вычитать принципов вашей концепции. Кстати, хотелось бы услышать, из тех кто прочитал, и такие ее, концепцию, увидел, что за концепцию они увидели?