SAP_BC_ENDUSER - стаандартная роль, уровння компании...?

>>нет. получаемый ответ будет 604, а точный ответ 602.25.
>>PS. Слово "правильный" я бы заменил на точный/неточный. если требуемая точность - до сотен, то все варианты "правильные".
 
да, правильный/неправильный - плохая формулировка, но и точный/неточный тоже не хочу называть, потому что иногда в задаче требуется получить неточный результат, но он правильный по требованиям задачи.
 
Поясню, что я имел ввиду выше. В описанных примерах рассматривается ситуация когда из-за незнания как работает reduce можно получить несколько конвертаций и на каждой из них потерять точность сильнее, чем это ожидалось.
Грубо говоря конвертации у нас происходят:
  1. в строке next к типу переменной _rX_tot_am приводится тип переменной _ord_lineX-netwr;
  2. на выходе из reduce результат расчета в переменной _rX_tot_am приводится к типу указанному после reduce ...( );
  3. при присвоении переменной lv_total_amount результат шага 2 приводится к типу переменной lv_total_amount;
Предположим, что тип _ord_lineX-netwr и тип lv_total_amount у меня указан правильно(он может быть одинаковым, а может быть разным). Обычно моя задача выполнить все калькуляции и конвертацию с максимальной точностью. В таком случае хорошо, когда на шагах 1 и 2 и 3 все операции выполняются с одиним и тем же типом и лучше всего, когда это тип переменной lv_total_amount. Это важно потому что делает конструкцию менее капризной к смене типов переменных и таким образом избежать "детских" ошибок при модификации кода в будущем, когда в одном месте тип поменяли, а в другом забыли.
 
Иногда бывает, что нужно выполнять вычисления с большей точностью, чем мы потом будем хранить результат, в там случае в конструкции
    init _r4_tot_am = value #( )
я бы заменил # на явно заданный тип большей точности, но только там, а остальное оставил бы как есть, по той же самой причине, что бы конвертаций было как можно меньше.
 
>>нет. подсчет идет точный, но результат 6.0225000000000000E+02 уж очень странный для переменной total_amount )))
Почему? вполне нормальный результат, типичная экспоненциальная запись. В SAP в целом не часто используется тип float, но если в рамках задачи это требуется, то почему нет, в точности мы тут не потеряли, хотя могли и существенно.
 
>>а что подразумеваете под "2 и 3 считают неправильно"?
развернуто ответил выше, если кратко неправильным считаю, то что при смене типа его приходится менять в 3-х местах, что в будущем может привести к ошибкам.

Спасибо!
Ваш подход классный! и здорово дополняет копилку тонкостей reduce )
 
>>> lv_total_amount поменять тип на i, то тест 1 начинает работать правильно
нет. получаемый ответ будет 604, а точный ответ 602.25.
PS. Слово "правильный" я бы заменил на точный/неточный. если требуемая точность - до сотен, то все варианты "правильные".
 
>>> а 2 и 3 считают неправильно, а если меняем тип на f
нет. подсчет идет точный, но результат 6.0225000000000000E+02 уж очень странный для переменной total_amount )))
а что подразумеваете под "2 и 3 считают неправильно"?

я бы написал вот так
lv_total_amount = reduce #(
    init _r4_tot_am = value #( )
    for _ord_line4 in lt_order_line
    next _r4_tot_am = _r4_tot_am + _ord_line4-netwr
).
break-point.
 
потому что если в определении переменой lv_total_amount поменять тип на i, то тест 1 начинает работать правильно, а 2 и 3 считают неправильно, а если меняем тип на f, то все 3 варианта не работают. В данном же коде тип определяется на основании типа lv_total_amount.

в каком бы регистре не именовать counter - уже можно использовать конструкции вида
COUNTER += 1.