При переходе на S/4HANA необходимо учесть, какие из используемых функций относятся к разряду Compatability Pack, которые ограничены в использовании 2027 годом, с исключениями 2030-м. Среди таких WM, на смену которому пришёл EWM, при этом очень простые процессы все же возможны в Stock Room Management (старый WM с большими ограничениями). Некоторые функции просто больше не существуют, либо сильно упрощены (global trade, gATP, CRM и др.), также имеются существенные отличия при выборе S/4HANA embedded EWM. Управление транспортом следует рассматривать в уже новом модуле TM, так как LE-TRA не является стратегическим.

При переходе на S/4HANA необходимо учесть, какие из используемых функций относятся к разряду Compatability Pack, которые ограничены в использовании 2027 годом, с исключениями 2030-м. Среди таких WM, на смену которому пришёл EWM, при этом очень простые процессы все же возможны в Stock Room Management (старый WM с большими ограничениями). Некоторые функции просто больше не существуют, либо сильно упрощены (global trade, gATP, CRM и др.), также имеются существенные отличия при выборе S/4HANA embedded EWM. Управление транспортом следует рассматривать в уже новом модуле TM, так как LE-TRA не является стратегическим.

Добрый день коллеги,
1) Подскажите когда ждать SAP GUI 7.70 для MAC ?
2) Не могу поставить SAP Hana Studio на Big Sur, не подскажите как это сделать ? Прочитал все ноты но не смог запустить установку.

дополнительно:
в системе DEV устанавливал SAP Note не из 000 Манданта и языком RU. В общем то именно это меня и насторожило сейчас )))

Чуть дополню. Функциональный метод в ABAP это именно метод с RETURNING параметром, это важно, т.к. результат работы функциональных методов можно использовать как READ позицию для передачи результата например в другие методы.
 
Т.е. метод с одним EXPORTING параметром не является функциональным. Подробнее тут: help.sap.com/doc/abapdocu_latest_index_htm

Смысл Unit-тестов заключается в том, чтобы автоматически тестировать код бизнес логики на простых сценариях. Вы же предлагаете изменить бизнес логику так, чтобы для тестов код проходил по одному сценарию, а для продуктива по другому.

Да нет,, просто не часто приходится переписывать систему, так что ну совсем не хватает производительности. Если случился дамп, то вряд ли перезапуск поможет, так как это что-то серьзное, ну у меня так обычно происходит. Осталное если честно времени особо не занимает, обычно больше времени, опять же у меня, занимает, это перепроектирование программы, которая изначально была расчитана на одни поток, чтобы она стало многопоточной.  Ну или изначальное проектирование мультипоточной программы.
 
Опять же если у вас все время пишутся мультипоточные программы, то конечно предложенный вариант удобен. Мне просто, за последние 3 года, адЫн раз пришлось такое делать и то связано это не с ускорением работы, а там просто параллельно процессы в мультимандантной среде запускались из мастер манданта, ну чтобы не тормозить процесс, все запускалось в параллельных процессах.
 
Но еще раз, в целом если вы делаете это раз в зеленую луну, как я например, то  проще выучить синтаксис стандарта и этого вполне достаточно.

Олег, да, перед созданием этого API мне действительно не нравилось то, что вы назвали: для каждого нового отчета приходится создавать RFC ФМ, писать метод/процедуру, обработку ошибок, попытку перезапуска задачи, если, например, случился дамп.
Т.е. каждый раз приходится реализовывать процесс распараллеливания заново. А если использовать предложенную разработку, этого делать уже не нужно. По большому счету нужно только описать бизнес логику и все.
Может быть как раз из-за описанных проблем вы и использовали параллельное выполнение не так часто? ;-)