Сортировать:

Новое Популярное

Комментарий от Дмитрий Шульмин 15 июня 2022, 05:58

Сергей, добрый день!
Есть задача по отправке уведомлений автору заявки при создании заказа к этой заявке. Просматривая настройки видел что там существует множество различных ролей партнеров, в том числе несколько ролей "... автор заявки" которые теоретически можно прикрутить к механизму формирования выходного документа заказа но нигде не попадалось подобной инструкции или описания таких настроек. Не сталкивались с такой задачей?

Комментарий от Александр Колесников 12 мая 2022, 08:09

Иван Борунов 08 мая 2022, 17:40

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

Иван, судя по наполнению да. Это роль для некритичных фоновых процессов
help.sap.com/doc/saphelp_me61

Комментарий от Иван Борунов 08 мая 2022, 17:40

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

Комментарий от Сергей Разин 14 апреля 2022, 11:20

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

Комментарий от Олег Башкатов 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-х местах, что в будущем может привести к ошибкам.

Во 1ых, спасибо за развернутый комментарий.
 
Но в одном месте - я не совсем понял его.
Вы говорите, как я Вас понял (и я с Вами полностью согласен), что калькуляцию нужно выполнить с максимальной точностью, а вот дать результат в том формате, который запрашивается.
Но ведь, если мы будем зависеть от исходной переменной lv_total_amount, то мы как раз-таки и рискуем "понизить" нашу точность вычислений. и вот целочисленное решение задачи в статье должно быть 602, а не 604. Потому что точное 602.25  и из него int = 602, а если мы "унаследуем неявно" целочисленный тип из lv_total_amount, то получим 604.
 
Вы какой подход поддерживаете:
1) неявное наследование типа из запрашиваемой переменной
2) явное указание типизации при вычислениях
3) возвращаемый тип из reduce делаем наследуемым (после ключевого слова reduce берем из целевого результата через #), а внутри повышаем точность до разумного уровня явной типизацией.

Комментарий от Виталий Глущенко 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 считают неправильно"?

>>нет. получаемый ответ будет 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-х местах, что в будущем может привести к ошибкам.

Комментарий от Олег Башкатов 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.

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

Комментарий от Виталий Глущенко 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.

Комментарий от Олег Башкатов 06 февраля 2022, 12:40

случай undefined - интересный. жаль, что авторы дают рекомендации, но не дают решений.
 
мои решения такие.
1) Если необходимо различать true / false и undefined, то можно использовать:
'+' - Знак плюса
'-' - знак минуса
' ' - пробел
 
2) или (что чаще) - возникает ситуация undefined - делать Exception с соответствующим сообщением. true/false - оставлять как abap_true / abap_false.

Комментарий от Александр Носов 31 января 2022, 07:43

Забавно, информации об авторах больше чем полезной нагрузки.

Комментарий от Алексей Герасименко 07 января 2022, 14:36

Добрый день!
 
Подскажите, пожалуйста, не совсем понял: о какой проблеме хранения глобальных переменных, которую не решало Classic BAdI и смогло решить New BAdI, идёт речь.
 
И, если можно, более подробно вот об этом предложении про Classic BAdI: "...однако проблемы в одной из наследуемых реализаций могли поломать работу всех пользовательских расширений." Это же и для New BAdI справедливо, разве нет?

Комментарий от Олег Башкатов 26 декабря 2021, 21:29

Спасибо за интересную статью и Ваш опыт!
 
Если можете, то прокомментируйте, пожалуйста следующее:
>>> В первую очередь была проведена работа над оптимизацией и повышению стабильности периодических заданий.
 
Для того, чтобы сделать оптимизационное изменение в системе - нужно ли было проходить через "рутинные процедуры" заказчика или была какая-то упрощенная схема по этим изменениям?

Комментарий от Алексей Науменко 25 декабря 2021, 18:11

Добрый день! можно ли и если да то как - выгрузить в формате SQL запроса - схему составленную в SQVI ? (с учетом например ограничений  - задаваемых на селекционном экране для отмеченных галочками полей)? есть ли такая возможность?

Комментарий от Сергей Рязанов 17 декабря 2021, 11:35

Спасибо за информацию. А есть инструменты, чтобы отслеживать не просто историю потребления Page Area, а узнать какая программа потребляет больше всех? Чтобы идти не к программистам вообще, а к конкретному.

Комментарий от Ирина Степаник 07 декабря 2021, 20:04

Добрый день, Олеся, подскажите по активации Регистра материалов для Retail S4.

Комментарий от Олег Башкатов 26 ноября 2021, 00:04

Олег Башкатов 25 ноября 2021, 23:56

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

появляется с 754 (в том числе для строк && )
help.sap.com/doc/abapdocu_754_index_htm

Комментарий от Олег Башкатов 25 ноября 2021, 23:56

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

Комментарий от Елена Рыбакова 08 ноября 2021, 10:02

Максим Мельник 31 января 2020, 13:09

Назначение функционала мне понятен и часть его я уверен, что знаю. Полагал, что есть специфические настройки, которые на курсах и на Help-е SAP-а нет. Например столкнулся с событиями безопасности в SAP NW и HANA 2.0. Если мне администрация сайта даст возможность, то поделюсь с сообществом своими изысканиями.

Максим, добрый день! Немного запоздало пишу, но свяжитесь с администрацией сайта по поводу вашего желания поделиться своим опытом, написав на почту sapland@sapland.ru. Будем очень рады :)
1 2 3 4 5
...
121