Добрый день, SAPфорум.RU.
Есть следующая проблема, при расчете Результатов в формуле.
Допустим, есть инфопровайдер:


Есть формула (ZFORMULA), которая рассчитывается как ZFORMULA = AMOUNT*PROV*0.01

В отчете "строю" по виду валют и получаю результат:

То есть, формула срабатывает так: ZFORMULA = (100 + 200 + 300) * (0.1 + 0.05 + 0.2) = (600)*(0.35) = 210
Хотя должно быть:

Т.е. ZFORMULA = 100*0.1 + 200*0.05 + 300*0.2 = 10 + 10 + 60 = 80.
Проблема распространенная, подскажите решение?
Копал в сторону "Расчет до агрегации" и "Расчет после агрегации". Что-то не получилось
Reference to Characteristic (Constant 1) ЧТО ЗА ЗВЕРЬ ТАКОЙ? Где он полезен? (В пункте 2, написано, но что-то не догнал)
Вот что пишут:
http://help.sap.com/saphelp_nw04/helpda ... ameset.htm
1. If you choose to calculate the formula before aggregation, this usually leads to bad performance as a large amount of data (single records) has to be calculated. Often in formula calculations, the single record information for only one or two specific characteristics is required and the rest of the InfoProvider data can be aggregated.

2. Therefore, we recommend that you use a formula variable that is replaced with the attribute Reference to Characteristic (Constant 1). Using this attribute, the reference to such a characteristic, which is not to be aggregated, can be created. The attribute Reference to Characteristic (Constant 1) is available for each characteristic.

If you use such a variable in a formula (instead of in a calculated key figure), it is replaced with a 1 but this has no effect on the aggregation behavior since formulas are always calculated after aggregation.
Выражение, что формулы ВСЕГДА расчитываются после агрегации, наталкивает на плохие мысли Или все таки можно решить эту проблему?

А почему вы храните именно процент (PROV)? Храните вместо него рассчитанное значение ZFORMULA. А процент вы вычислите всегда, его как раз и имеет смысл рассчитываеть после агрегации.

Добрый день, Alessandro.
Хранить рассчитанное значение ZFORMULA не совсем хорошее решение в моей ситуации, в иных случаях я уже использовал этот подход (предварительный расчет) (Советы Кимбала очень полезны). Здесь проблема состоит в том, что отчет строится на Мульти-провайдере. Данные в инфопровайдер содержащий показатель PROV загружаются раз в месяц.
Причем часто бывают случаи, что он рассчитываются тогда, когда уже загружены показатели в другом инфопровайдере, содержащего показатель AMOUNT.
К какой ситуации это приводит, если рассчитывать ZFORMULA при загрузке? - это приведет к тому, что необходимо из-за показателя PROV перегружать данные для рассчета ZFORMULA. (Показатель AMOUNT изменяется каждый день). Перегрузка данных для клиентов во время рабочего дня недопустима.

Приветствую, BORLAND.
Вероятно, может получиться решить вашу проблему следующим образом (проверить самостоятельно, к сожалению, в данный момент возможности нет):
1. Для показателя PROV настроить спец. агрегацию, отличную от Сум, скажем, Мин, со ссылочным признаком DOC_ID. При этом при обработке запроса OLAP-процессор будет обрабатывать массив данных в развертке по DOC_ID независимо от развертки в запросе.
2. Создать виртуальный показатель для расчета ZFORMULA. Соответственно, значение ZFORMULA будет рассчитано в разрезе DOC_ID.
3. При использовании в отчете данного виртуального показателя даже без развертки по DOC_ID, рассчитанные значения ZFORMULA в разрезе DOC_ID будут просуммированы, что и требуется.
Если даже этот подход сработает, то могут быть проблемы с производительностью при большом количестве DOC_ID.

Спасибо за совет. Да решения посредством виртуального показателя уже аппробировались, некоторые затруднения возникли в связи с тем, что используется Мультипровайдер. Касательно производительности, вопрос актуален, поскольку есть удаленные филиалы и параметры времени и прозводительности очень важны.
Как руки дойдут, будем разбираться с поведением на мультипровайдере. Здесь на сайте есть тема: Виртуальные признаки и показатели от VPU.
Также пригодились материалы:
Using Virtual Key Figure / Characteristics in an InfoSet ;
Implementing Virtual Key Figure/ Characteristics Makes Query More Dynamic.
How to… Indentify ‘Comparable’ Results within a Query
How To... work around the ‘Single Key Date’ limitation for time dependent master data