СУС я как понял тут не подойдет.
Если не рассматривать вопрос функциональности, а только тех часть, то в целом, думаю да, можно рассмотреть вариант с расширением, то есть:
Смотрите экран который будете расширять (в MM01, например), там наверняка будет subscreen для пользовательских расширений, на который можно нарисовать любой контрол (alv или просто экранную таблицу), после того как данные будут заполнены, где-нибудь в BADI при сохранении ОЗМ, запустить свой api ФМ in update task который запишет данные в Вашу Z таблицу при успешном общем commit. По технической части, примерно вот такой подход, есть в нем некоторые не ровности, но как вариант если очень хочется.
Почему не сделать проще, не создать обычную настроечную таблицу и не вести ее в sm30 или не написать Z программку для ведения - это вопрос к Вам, хотя это тоже вариант.
Классификация, как тут уже упомянули, тоже вариант, есть там у признака свойство множественное значение. Только, честно сказать не помню уже когда я использовал такой признак.
Соседняя ветка по классификации ОЗМ
https://sapboard.ru/forum/viewtopic.php?f=13&t=96950Теперь, нужно ли это делать - большой вопрос. Коллегам, кто имеет серьезный опыт в ММ (
LKU), виднее, возможно они подскажут, как правильно с точки зрения функционала.