А вот что интересно, в спец агрегации... у меня хорошо заработал подсчет ненулевых значений (типа для distinct count по определенному признаку). А вот с, например, средним - какая-то неувязка, которая заключалась в том, что если выведен признак, по которому проводится агрегация, то оно так и получалось. А вот если не выведен, то тупо суммировала все. Это так и должно быть или глюк или мне показалось тогда? Попробую сделать иллюстрацию:


Имеем в источнике для отчета
Ном контракта, ном дог., ном. позиции, кол-во материала
1, 1, 1, 10
1, 1, 2, 20
1, 2, 1, 100
1, 2, 2, 200

Со средним по номеру договора могу получить такой отчет:
Ном контракта, ном дог., кол-во
1,1, 15
1,2, 150

Но стоит убрать ном договора, как получается
1, 330

А хотелось бы - 1, 165

Или это нереализуемо?

периодически возникают на форуме вариации на эту тему... ответов на них так и нет...

Но ведь существует же для чего то метод рачета "Перед агрегацией"... Добиться от него работы мне так и не удалось.

Договор
1 2 Итого
Контракт 1 Позиция 1 10 100 110 Общая агрегация
1 2 20 200 220 Общая агрегация
Итого 15 150 165
Спецагрегация Спецагрегация Спецагрегация

Убираем договор
Позиция
1 2 Итого
Контракт 1 110 220 330 Общая агрегация

Может у инфо-объекта - показателя сделать спецагрегацию AVG по договорам? Тож самое наверное будет. Надо добавлять признак на ось и скрывать его

Lench: Очень страрался, но не понял ничего в первом Вашем примере.

А по второму сообщению - как раз я и говорил про то, что AVG на показателе с ссылкой на "договор" и не работает, если признак не в отчете, а если его добавить в отчет и потом скрыть, то там так и останутся две строки, не станут суммироваться.

Чет табуляция не поддерживается в сообщениях
_____________________Договор
_____________________1___2 Итого
Контракт 1 Позиция _1_10 100 110 Общая агрегация
________1_________ 2_20 200 220 Общая агрегация
_______________ Итого 15 150 165 Спецагрегация

Убираем договор
____________Позиция
___________1__2__Итого
Контракт 1: 110 220 330 Общая агрегация

А насчет скрытия тут уж зависит от конкретной ситуации, в конце концов есть рабочие книги с VBA...

А вы посмотрите внимательно на ваши же примеры:






В данном случае усреднённое значение показателя для номера договора 1 = (10+20)/2 = 15, а для номера договора 2 = (100 + 200)/2 = 150.




А вданном случае вы хотите видеть среднее по номеру контракта. Номер договора вы вообще убрали из развёрстки.

И расчёт до агрегации здесь вообще ни к месту. Так как средние значения могут быть посчитаны только после агрегации.

В том случае я хотел видеть не среднее по контракту, а все же среднее по договору. Т.е. - раз я задал, что среднее по договору, я расчитывал, что сначала система рассчитает среднее по специальной агрегации, а потом свернет по обычной агрегации (т.е. в примере я ожидал, что она расчитает среднее на уровне "договор" для каждого договора, а потом просуммирует показатели всех этих договоров, которые входят в один контракт). На самом деле, я сейчас уже не помню, зачем мне это было нужно (вроде бы я потом сумму этих средних хотел разделить на какое-то количество и получался показатель, который клиент хотел, и даже не среднее, а как раз минимум или максимум, не помню сейчас уже), просто непонятно было на тот момент. Да и сейчас непонятно такое "самоуправство" системы - ведь задано, что агрегация - суммирование, специальная агрегация - среднее по договору, я как бы и жду, что система вычислит специальную агрегацию, а потом проагрегирует согласно построения отчета, но вот нет... Теперь просто как факт принял и все.

Lench: Понятно, только все равно напутано.
В моем примере контракт один на несколько договоров, каждый из которых может иметь несколько позиций. А Вы привели пример, что в строках контракт и потом сразу позиции договора, а в столбцах развернуты договоры... это нечитабельно, непонятно и неправильно, т.к. может быть и 1000 договоров, а кому нужен отчет с тысячей столбцов?

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

Вы слишком много хотите от системы. Она "тупая". Системе пофигу, она "видит", что у вас в развёрстке присутствует только номер контракта и соответственно вычисляет показатели. И в данном случае систем права. С математической точки зрения это правильно.

Попробуйте в свойствах показателя в BEх в поле "Расчет результата как" поставить значение "Суммирование".

В целом понятно. Просто с подсчетом количества оно работает и при отсутствии признака (впрочем наоборот было бы странно, т.к. если вынести признак, по которому делается эта специальная агрегация, то там всегда = 1 будет), расчитывал на одинаковый алгоритм поведения.
2 RSA1 & Lench - спасибо за объяснения
2 Евросетянин - это Вы проверяли, что оно будет работать или просто предложили? Потому что как раз "претезия" состояла в том, что система, в описываемом случае, не считает специальную агрегацию, а просто суммирует. Как мне кажется, если я дополнительно установлю в результате "суммирование", то суммировать в агрегации запроса оно от этого не перестанет. Да и ценность всех этих "расчет резульатата как..." несколько сомнительна для меня - все равно при попытке использовать значение ячейки в формуле система берет то значение результата, которео выводится при "неопределено".