В новой версии XLSX Workbench VBA-макросы поддерживаются. Вместо XLSX будет формат XLSM. Подробности здесь: sites.google.com/site/sapxlwb

Макросы могут использоваться не только для формирования :-)
но и дальнейшего использования.

Полезная статья, но пример, на мой взгляд, выбран не совсем удачно.
 
Для поставленой задачи (создание материала только определённого вида) существует набор стандартных транзакций (например, MMF1 для FERT). Поэтому использование вариантов транзакций для этой цели, выглядит избыточным и не совсем жизненным.
 
Было бы интересно прочитать, какие ещё реальные задачи решались с использованием этой методики и есть ли у нёё какие-то ограничения?
 
Например, можно ли её использовать в транзакциях несколькими экранами (MIGO, ME21N и подобные)?

С несколькими экранами все не так радужно. Например, прописали значение по умолчанию на третьем экране. Если пользователь вызовет этот экран, то логика отработает. Если не вызовет, ограничившись в работе только первым экраном - значение не подставится.

Прямой апдейт для добавления записи условия - плохой вариант.
1. Как минимум, не учтено отражение записи стандартном журнале изменений.
2. Если продолжать - не учитывается возможное перекрытие записи по периодам, их удаление и корректировка, как это работает в MEK1.
 

В этой конкретной задаче пожалуй можно игнорировать эти допущения. Но в общем случае - так делать нельзя. Был печальный опыт. Единственное известное мне гарантированно рабочее решение - это использовать пакетный ввод к MEK1 для ввода записей условий.

Полезная статья, но пример, на мой взгляд, выбран не совсем удачно.
 
Для поставленой задачи (создание материала только определённого вида) существует набор стандартных транзакций (например, MMF1 для FERT). Поэтому использование вариантов транзакций для этой цели, выглядит избыточным и не совсем жизненным.
 
Было бы интересно прочитать, какие ещё реальные задачи решались с использованием этой методики и есть ли у нёё какие-то ограничения?
 
Например, можно ли её использовать в транзакциях несколькими экранами (MIGO, ME21N и подобные)?

Полезная статья, но пример, на мой взгляд, выбран не совсем удачно.
 
Для поставленой задачи (создание материала только определённого вида) существует набор стандартных транзакций (например, MMF1 для FERT). Поэтому использование вариантов транзакций для этой цели, выглядит избыточным и не совсем жизненным.
 
Было бы интересно прочитать, какие ещё реальные задачи решались с использованием этой методики и есть ли у нёё какие-то ограничения?
 
Например, можно ли её использовать в транзакциях несколькими экранами (MIGO, ME21N и подобные)?

>>> в качестве базы данных поддерживается только Oracle
 
а базу данных нужно отдельно приобретать? :-)

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

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

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

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

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

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

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