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

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

Комментарий от Артём Лыков 21 сентября 2022, 09:09

Радик Рахметов 15 сентября 2022, 12:16

Не уверен, что локализация будет дешевле миграции на российское ПО, с учетом тарифной политики SAP.  Даже с учетом всех рисков сепарации. Все нужно сравнивать предметно.

Радик, вы абсолютно правы, что нужно сравнивать предметно.  И по стоимости, и по возможностям, и по производительности систем. Тарифной политики SAP сейчас нет, т.к. SAP нет официально в России.

Комментарий от Радик Рахметов 15 сентября 2022, 12:16

Не уверен, что локализация будет дешевле миграции на российское ПО, с учетом тарифной политики SAP.  Даже с учетом всех рисков сепарации. Все нужно сравнивать предметно.

Комментарий от Алексей Еськин 22 августа 2022, 09:09

Алексей Еськин 21 августа 2022, 11:56

Игорь, добрый день.
1)Если упрощенно, то надо создать динамическое количество однотипных таблиц, на листе, чтобы они были друг под другом.  В них будут отличаться только названия колонок, незначительно. Например, мы заранее определили что будет 3 итерации, надо вывести 3 таблицы, друг под другом, где каждая таблица будет иметь два столбца например, дата и сумма. В каждой итерации, название столбца "дата" меняется на "дата + 1" те "дата1"..."датаN". Запуск не в диалоге, так что макросы нельзя.
В общем это как цикл внутри цикла. Такое возможно сделать?
2) Как окрашивать строку по условию. Например есть строка  с подитогами, в контексте мы будем иметь флаг, подитогов. Это делается через условное форматирование? Как мне использовать в условиях значение из контекста, если оно нигде не выводится(этот флаг).

2) Удалось сделать через вывод скрытого столбца+условное форматирование

Комментарий от Алексей Еськин 21 августа 2022, 18:37

Алексей Еськин 21 августа 2022, 11:56

Игорь, добрый день.
1)Если упрощенно, то надо создать динамическое количество однотипных таблиц, на листе, чтобы они были друг под другом.  В них будут отличаться только названия колонок, незначительно. Например, мы заранее определили что будет 3 итерации, надо вывести 3 таблицы, друг под другом, где каждая таблица будет иметь два столбца например, дата и сумма. В каждой итерации, название столбца "дата" меняется на "дата + 1" те "дата1"..."датаN". Запуск не в диалоге, так что макросы нельзя.
В общем это как цикл внутри цикла. Такое возможно сделать?
2) Как окрашивать строку по условию. Например есть строка  с подитогами, в контексте мы будем иметь флаг, подитогов. Это делается через условное форматирование? Как мне использовать в условиях значение из контекста, если оно нигде не выводится(этот флаг).

1)Удалось сделать через "патерны"+появление при наличии значения в поле

Комментарий от Алексей Еськин 21 августа 2022, 11:56

Игорь, добрый день.
1)Если упрощенно, то надо создать динамическое количество однотипных таблиц, на листе, чтобы они были друг под другом.  В них будут отличаться только названия колонок, незначительно. Например, мы заранее определили что будет 3 итерации, надо вывести 3 таблицы, друг под другом, где каждая таблица будет иметь два столбца например, дата и сумма. В каждой итерации, название столбца "дата" меняется на "дата + 1" те "дата1"..."датаN". Запуск не в диалоге, так что макросы нельзя.
В общем это как цикл внутри цикла. Такое возможно сделать?
2) Как окрашивать строку по условию. Например есть строка  с подитогами, в контексте мы будем иметь флаг, подитогов. Это делается через условное форматирование? Как мне использовать в условиях значение из контекста, если оно нигде не выводится(этот флаг).

Комментарий от Ирина Дауева 19 августа 2022, 08:02

Максим Столяров 10 августа 2022, 09:55

Всем добрый день.
 
Ваши вэбинары, Василий, конечно же познавательны, но на видео картинка с примерами программ и кодов вообще не читальбельна, т.е. практически ничего не видно.

Максим, добрый день!
Добавили презентацию и листинги прогамм.

Комментарий от Тим Иван 16 августа 2022, 15:46

Тим Иван 16 августа 2022, 15:39

Попробовал сделать с TABSTRIP т.е. есть экран селекционный и еще экран вывода. Не получилось. Не ловит событие.

И еще один момент что для вывода использовал splitter

Комментарий от Тим Иван 16 августа 2022, 15:39

Попробовал сделать с TABSTRIP т.е. есть экран селекционный и еще экран вывода. Не получилось. Не ловит событие.

Комментарий от Максим Столяров 10 августа 2022, 09:55

Всем добрый день.
 
Ваши вэбинары, Василий, конечно же познавательны, но на видео картинка с примерами программ и кодов вообще не читальбельна, т.е. практически ничего не видно.

Комментарий от Екатерина Ничик 02 августа 2022, 12:08

Добрый день. Картинки на статьях по расширениям не отображаются. Проверила на других циклах статей - все хорошо.

Комментарий от Владимир Костецкий 15 июля 2022, 12:00

В статье не отображаются рисунки. Проверил в настройках браузера у себя - показ картинок включен. Прошу помочь в решении проблемы.

Комментарий от Дмитрий Шульмин 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 считают неправильно"?
1 2 3 4 5
...
121