Вечер добрый! Имеется следующая задачка... и мое решение. Просьба проверить и тыкнуть носом в ошибки А то 1й проект, сами понимаете, волнуюсь.

Стандартный куб(ZIST): День, Месяц, Сеть, МагазинСети, ТипПродажи, Продукт, ПродуктоваяИерархия, Количество, Сумма, 0currency, 0unit.
Куб реального времени (ZIREAL): Месяц, Сеть, Продукт, ПродуктоваяИерархия, Версия, Количество, Сумма, 0currency, 0unit.
Эти два куба входят в мультипровайдер, на котором сделан уровень агрегации: Месяц, Сеть, ТипПродажи, Продукт, ПродуктоваяИерархия, Версия, Количество, Сумма, 0currency, 0unit.
На уровне агрегации построен запрос.
В запросе (Query Designer) автоматически рассчитывается план продаж, который пользователь должен иметь возможность менять вручную. Этот расчет производится на основе ограниченных и рассчитанных показателей. Так как нельзя сделать рассчитанный показатель (в терминах QD, formula) готовым к вводу, то требуется воспроизвести расчет query силами FOX. А т.к. BI IP видит только базовые показатели, то и все рассчитанные показатели, участвующие в расчете плана, тоже надо сделать на FOX. И вот здесь у меня возникла сложность.

Показатели из query (f-formula, s-selection) в формате Название ### Пояснение ### Расчет или Ограничения ### Спец.агрегация:
1) f113 ### среднее за интервал ### s113_1 ### Average по 0calmonth;
2) s113_1 ### продажи по сетям за интервал пред.года ### Сумма, ограничено:
Инфопровайдер: ZIST
Тип продажи: 1, 3
0currency: rur
Иерарахия: var_hier
Версия: var_vers
0calmonth: var_interval-12
Сеть (константа-выбор)
3) s114 ### продажи по сетям за месяц пред.года ###Сумма, ограничено:
Инфопровайдер: ZIST
Тип продажи: 1, 3
0currency: rur
Иерарахия: var_hier
Версия: var_vers
0calmonth: var_month-12
Сеть (константа-выбор)
4) f115 ### коэффициент по сетям ### f114/f113
5) f132 ### план ### (АтрибутПродукта==1)*f115 + (АтрибутПродукта==2)*f115*10

Эта задача сильно упрощена относительно реальной, т.к. мне важно понять суть, а дальше буду действовать по аналогии.
В наследство от предыдущего разработчика мне достался query с вводным показателем Сумма, ограничено:
Инфопровайдер: ZIREAL
Тип продажи:#
0currency: rur
Иерарахия: var_hier
Версия: 001
0calmonth: var_month

Так как коэффициент пользователь тоже должен иметь возможность менять, а в кубе только два показателя (для рублей и для штук), то готовым для ввода показателем Коэффициент я сделала Сумма, ограничено:
Инфопровайдер: ZIREAL
Тип продажи:#
0currency: AFA
Иерарахия: var_hier
Версия: 001
0calmonth: var_month

Формула FOX для расчета коэффициентов, где Operand:{KF, месяц, валюта, инфопровайдер, версия, сеть, продукт.иерархия, тип продажи}
DATA FMONTH TYPE 0CALMONTH.
DATA ZMONTH TYPE 0CALMONTH.
DATA Z_MONTH TYPE 0CALMONTH.
DATA ZVCHAIN TYPE ZCHAIN. //сеть
DATA ZVVERS TYPE 0VERSION.
DATA ZVHIER TYPE ZCHIER.
DATA NOM TYPE I.
DATA SUM113 TYPE F.
DATA SUM114 TYPE F.

NOM = VARC(var_interval). //число месяцев в интервале, напр.5
Z_MONTH = VARV (var_month). // получаю значение целевого месяца, например, 10.2011
ZMONTH = TMVL(var_month,-12). //смещение на год назад, (10.2010)
SUM113 = 0.
SUM114 = 0.

FOREACH ZVCHAIN IN SELECTION. // имитирую константу-выбор. Здесь еще нужно перечислить признаки?
FMONTH = VARI(var_interval,1). //1й месяц периода, напр. 03.2011
FMONTH = TMVL(FMONTH,-12). //смещение на год назад, (03.2010)
DO NOM TIMES . // т.к. показатели ограничены двумя значениями ТипПродажи, то получается 2 комбинации для суммирования
SUM113 = SUM113 + {KF, FMONTH, RUR, ZIST, ZVVERS, ZVCHAIN, ZVHIER, 01} + {KF, FMONTH, RUR, ZIST, ZVVERS, ZVCHAIN, ZVHIER, 03}.
FMONTH = TMVL(FMONTH,1). //переход к след. месяцу
ENDDO.

SUM114 = SUM114 + {KF, ZMONTH, RUR, ZIST, ZVVERS, ZVCHAIN, ZVHIER, 01} + {KF, ZMONTH, RUR, ZIST, ZVVERS, ZVCHAIN, ZVHIER, 03}.

// имитация f115
IF SUM113 = 0. // Условие, чтобы не было деления на 0
EXIT.
ENDIF.
{KF, Z_MONTH, AFA, ZIREAL, 001, ZVCHAIN, ZVHIER, #} = SUM114*NOM/SUM113.
FMONTH = TMVL(FMONTH,1)
ENDFOR.
В системе разработки нет данных, а в тесте и продуктиве после нажатия кнопки с командой "Выполнить функцию планирования" или "Выполнить последовательность" появляется диалоговое окошко с ошибкой: «The initial exception that caused the request to fail was: java.lang.NullPointerException».
Готовый для ввода показатель (коэффициент) остается пустым. Из чего я делаю вывод, что формула FOX некорректная и/или это что-то базисное (простые формулы, типа записи в столбец константы какой-нибудь, также сваливаются с ошибкой). Проверку на синтаксис формула проходит. На трассировку в тесте и продуктиве у меня нет авторизации, поэтому пишу формулы вслепую.

Собственно вопросы к форумчанам:
1) Правильно ли, что вводной показатель ограничивается признаком ТипПродажи (ведь этого признака нет в кубе реального времени)?
2) Правильно ли я имитирую константу-выбор? Может, надо дополнить признаком 0calmonth в Foreach?
3) Query является провайдером для веб-шаблона (WAD7), т.е. пользователь работает с отчетами на портале. Как стереть заголовок "AFA" (это левая валюта) из столбца - вводного для коэффициентов? Я правильно понимаю, что это возможно только силами JavaScript?
Предчувствуя ответ на 3 вопрос, я уже попыталась подтереть JS'ом. Более того, изначально я вообще хотела рассчитывать все в query, а в вводные ячейки просто копировать, но не получается обратиться к ячейкам таблицы. Вот пример копирования столбца (сразу скажу, что не работает):
function MyFunc ()
{
var my_tab= document.getElementById("MY_ANALYSIS_interactive_pivot_a"); // нахожу по ID таблицу, формируемую веб-элементом ANALYSIS_ITEM
var my_rows = my_tab.getElementsByTagName("tr"); // нахожу по тегу все строки таблицы
var numrows = my_rows.length; //вычисляю количество строк таблицы
//копирую 2й столбец в 3
for(var i=2;i<numrows;i++){ // перебор начинаю с 3й строки, т.е. пропускаю шапку
document.all.my_tab.rows.cells[2].innerHTML=document.all.my_tab.rows[i].cells[1]; [i]// также пробовала innerText
document.all.my_tab.rows.cells[1].hidde(); [i]//скрываю ячейку
}
for(var j=0;j<2;j++){ // скрываю шапку
document.all.my_tab.rows[j].cells[1].hidde();
}
}
Обращаться по ID к столбцам невозможно, т.к. отчет дает возможность пользователю сворачивать столбцы, а при этом действии их ID меняются.

П.С. спасибо, что дочитали досюда. Буду очень благодарна любой подсказке!

в ТЗ есть обязательное требование к решению именно на Web Template или Вы сами пустились "во все тяжкие" ?

По ТЗ так. Понимаю, что Аналайзер+макрос было бы лучше.

дружище, вы лучше для начала закройте вопрос с планированием. неважно, какая реализация UI выбрана (web или office) - пока
вы не оттестируете планирование, приступать к реализации интерфейсной части не рекомендую.
учитывая ваш опыт, да и вообще опыт работы с IP, никак вы без отладки не сможете. не поленитесь, наколотите в разработке хоть какой-то факт в стандартный куб.

1) Правильно, т.к. в целевом кубе этого признака нет вообще.
2) Что значит имитируете константу-выбор в контексте FOX? В вашем случае в принципе все равно какую конструкцию FOREACH ZVCHAIN IN SELECTION. или FOREACH ZVCHAIN. использовать. Также надо добавить в цикл "продукт.иерархия" и "версия" ведь они указаны как переменные в операнде, но их значения не инициализируются и не меняются. Либо "выбросить" признаки "сеть", "продукт.иерархия" из признаков для изменения, т.к. они и в источнике и в цели имеют одни и теже комбинации и оставить в цикле только версию.
По версии не ясен такой момент: в начале поста перечислены признаки участвующие в инфо-кубах, но версия не указана для Стандартный куб(ZIST), это опечатка?



Функции VARC и VARV насколько помню не работают на интервальных переменных. Они предназначены, только для работы со списком значений (могу ошибаться).




Не совсем ясно для каких целей нужен второй цикл Do.
ZCSFP - это целевой инфо-куб? В начале поста указан другой (ZIREAL).
Переменную FMONTH надо инициализировать внутри цикла FOR, т.к. потом она увеличивается сразу в двух внутренних циклах DO и на следующей итерации по FOR не сбрасывается к первоначальному значению.

Air_demon,
1) Константа-выбор в ограничении показателя, как я понимаю, делает агрегацию. Т.е. есть сеть, состоящая из магазинов. Магазины - слишком мелко для анализа, хотят видеть данные по сетям. Первым циклом DO я имитирую эту агрегацию.
2) В Операнд FOX я запихнула признаки из ограниченных показателей query. Сейчас там все рассчитывается автоматом, и мне нужно "лишь" дать возможность пользователю изменять эти автоматически рассчитанные числа. Не ясно, как можно выбросить признак, пусть он даже не изменяется. Ведь он дает комбинацию. Т.е например, {KF, ZMONTH, RUR, ZIST, ZVVERS} и {KF, ZMONTH, RUR, ZIST, #} - это же разные вещи.
3) Признак "версия" есть только в кубе реального времени. Во всех остальных - данные по продажам.
4) По второму DO и FMONTH - каюсь, моя ошибка. ZIREAL - целевой, ZCSFP - опечатка. Отредактировала.

bwbams, Вы прямо зрите в корень. Данные набила еще на прошлой неделе, но запускала всю функцию. Сейчас по Вашей наводке разбила на составные части. Проверю, VARC и VARI на интервале. А то я теперь сомневаюсь.

1) BW305 Урок: Ограниченные показатели

Аналогом (с некоторыми нюансами) константы-выбор в FOX-формуле является обращение к ссылочным данным с помощью "|".

Агрегацию Вы осуществляете путем добавления признака "Сети" в уровень агрегации, без детализирующего признака "Магазины".

2) Если признак включен в уровень агрегации, на котором построена функция, то в любом случае, находится он в операнде или нет, по нему будет сделана выборка данных и составлены комбинации.
Поищите документ "Tips and Tricks for Implementing and Optimizing Formulas in SAP NetWeaver BI Integrated Planning".

3) В таком случае стоит его сразу ограничить # в операндах обращающихся к исходным данным.

Спасибо Вам большущее!
1)Оказывается, в корне неверно смотрела на принцип определения признаков, которые должны быть в операнде и в FOREACH. Я предполагала, что если не указать признак в операнде, то присваиваемое значение ляжет на #. А на деле, значение кладется "на все". Т.е например:
{KF, месяц, валюта, клиент} = 123. // значение "123" присвоится указанному клиенту
{KF, месяц, валюта, #} = 123. //значение ляжет на "пустого" клиента
{KF, месяц, валюта} = 123. //значение присвоится всем клиентам, в том числе #
Так ведь?
2) Я некорректно "перевела" реальную задачу в термины здесь размещенной задачки. Там под сетью подразумевается партнер, т.е. говоря про агрегацию и константу-выбор, я имела ввиду такое (так отрабатывает query):
строка | есть константа-выбор | нет константы-выбор
сеть1 | 18 | 3
сеть2 | 18 | 5
сеть3 | 18 |
сеть4 | 18 | 10
Итого | 18 | 18
Переменные в фильтре: Сеть
Переменные в ограничениях показателей: ПродуктоваяИерархия, Версия, Месяц, Интервал

3) Выводы, которые я сделала после прочтения мануала и Ваших замечаний:
а - Берем показатель целевого куба. Ограничиваем его признаками, которые есть в целевом кубе и в уровне (переменными и/или константами), а также теми признаками, которых нет в кубе, но которые есть в уровне агрегации (ставим на них #). Если значения признаков одинаковые в исходном и целевом кубе, то удаляем их из "Изменяемых признаков". Таким образом, мы получили Операнд FOX.
б - В операндах показателей исходных данных, у которых в инфопровайдере нет признака из Операнда (пункт а), на месте этого признака ставим #.
Верно?
4) На тестовых данных проверила: VARC, VARI для интервала работают. А вот Foreach мой совершенно неправильный.

В общем случае верно.