Добро пожаловать
Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Развитие в экосистеме SAP
Сортировать:
Комментарий от Дмитрий Шульмин 15 июня 2022, 05:58
Комментарий от Александр Колесников 12 мая 2022, 08:09
Иван Борунов 08 мая 2022, 17:40
SAP_BC_ENDUSER - стаандартная роль, уровння компании...?
Комментарий от Иван Борунов 08 мая 2022, 17:40
Комментарий от Сергей Разин 14 апреля 2022, 11:20
Комментарий от Олег Башкатов 03 апреля 2022, 23:07
Виталий Глущенко 03 апреля 2022, 21:13
>>нет. получаемый ответ будет 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-х местах, что в будущем может привести к ошибкам.
Комментарий от Виталий Глущенко 03 апреля 2022, 21:13
Олег Башкатов 31 марта 2022, 20:57
Спасибо! Ваш подход классный! и здорово дополняет копилку тонкостей reduce ) >>> lv_total_amount поменять тип на i, то тест 1 начинает работать правильно нет. получаемый ответ будет 604, а точный ответ 602.25. PS. Слово "правильный" я бы заменил на точный/неточный. если требуемая точность - до сотен, то все варианты "правильные". >>> а 2 и 3 считают неправильно, а если меняем тип на f нет. подсчет идет точный, но результат 6.0225000000000000E+02 уж очень странный для переменной total_amount ))) а что подразумеваете под "2 и 3 считают неправильно"?
Комментарий от Олег Башкатов 31 марта 2022, 20:57
Виталий Глущенко 31 марта 2022, 20:09
я бы написал вот так 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.
Комментарий от Виталий Глущенко 31 марта 2022, 20:09
Комментарий от Олег Башкатов 06 февраля 2022, 12:40
Комментарий от Мария С 01 февраля 2022, 10:56
Комментарий от Александр Носов 31 января 2022, 07:43
Комментарий от Алексей Герасименко 07 января 2022, 14:36
Комментарий от Олег Башкатов 26 декабря 2021, 21:29
Комментарий от Алексей Науменко 25 декабря 2021, 18:11
Комментарий от Сергей Рязанов 17 декабря 2021, 11:35
Комментарий от Ирина Степаник 07 декабря 2021, 20:04
Комментарий от Олег Башкатов 26 ноября 2021, 00:04
Олег Башкатов 25 ноября 2021, 23:56
в каком бы регистре не именовать counter - уже можно использовать конструкции вида COUNTER += 1.
Комментарий от Олег Башкатов 25 ноября 2021, 23:56
Комментарий от Фуркат Юсупов 22 ноября 2021, 13:21
Комментарий от Елена Рыбакова 08 ноября 2021, 10:02
Максим Мельник 31 января 2020, 13:09
Назначение функционала мне понятен и часть его я уверен, что знаю. Полагал, что есть специфические настройки, которые на курсах и на Help-е SAP-а нет. Например столкнулся с событиями безопасности в SAP NW и HANA 2.0. Если мне администрация сайта даст возможность, то поделюсь с сообществом своими изысканиями.