если на то пошло, то можно использовать OOP подход при создании транзакции, и забыть про include как таковой и про их расположение в том числе :-)
 
пример описан здесь:
sapland.ru/blogs/phaizullin

Просто как статья про ADBC - отлично!
 
Только объясните, пожлста, след.момент: Если система на HANA, т.е. скорее всего базис будет 7.4, а м.б. и 7.5, соответственно, есть более удобный инструментарий - можно пользоваться новым синтаксисом Open SQL, CDS-view или AMDP, для вызова процедур или вьюшек созданных непосредственно в HANA (минуя ABAP-словарь), можно создавать прокси и вызывать через них.
Зачем ADBC в контексте HANA?
 
И, как мне кажется, к ADBC относятся те же рекомендации, что и к Native SQL - по возможности предпочитать Open SQL, в связи с тем, что NW оптимизирован под использование Open SQL.

В новой версии 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
 
а базу данных нужно отдельно приобретать? :-)