В кубе OLAP неверный общий итог при фильтрации атрибута
Пользователь пытается проверить сумму продаж на одного продавца. Пример данных:
Salesperson Sales Amount
001 1000
002 500
003 750
Grand Total: 2250
Это выглядит нормально, но у нас есть следующая иерархия Company > Class > Group > Subgroup
в кубе, и если пользователь пытается использовать эту иерархию в фильтрах - общий итог завершается неудачно (если какой-либо атрибут не проверен в этой иерархии). Образец:
Salesperson Sales Amount
001 1000
002 500
003 750
Grand Total: 350
Я уже сталкивался с той же проблемой, когда пытался отфильтровать атрибут Date: если не каждый день месяца был выбран, он тоже показывал неверный общий итог.
У вас есть идея, почему это происходит и как это исправить?
Объем продаж - это физическая мера (не рассчитанная мера), она выбирается из представления SQL (то же самое происходит с каждым фактом).
Я задавал тот же вопрос здесь, но никто не мог ответить на него.
Я пытался удалить все вычисления MDX (области), но все же общий итог был неверным.
РЕДАКТИРОВАТЬ
Я заметил, что проблема возникает при такой фильтрации:
1 элемент выбран на первом уровне иерархии, 1 элемент на 2-м уровне и 1 элемент на 3-м уровне иерархии, как на рисунке выше.
Если 3-й уровень не отфильтрован, он показывает хороший общий итог.
РЕДАКТИРОВАТЬ 2
Я пытался отследить на SSAS, он возвращает точно такой же вывод, как в Excel. При использовании измерения Salesperson в строках было создано следующее MDX:
SELECT NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS,
NON EMPTY { ([Salesperson].[Salesperson].[Salesperson].ALLMEMBERS ) }
DIMENSION PROPERTIES MEMBER_CAPTION,
MEMBER_UNIQUE_NAME ON ROWS FROM (
SELECT ( { [Item].[Class - Group - Subgroup].[Class].&[XXX]&[1.],
[Item].[Class - Group - Subgroup].[Group].&[XXX]&[2.]&[2.2.],
[Item].[Class - Group - Subgroup].[Subgroup].&[XXX]&[2.]&[2.3.]&[2.3.1.] }
) ON COLUMNS FROM ( SELECT ( { [Company].[Company].&[XXX] } ) ON COLUMNS
FROM [Sales]))
WHERE ( [Company].[Company].&[XXX], [Item].[Class - Group - Subgroup].CurrentMember ) CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS
Этот MDX сгенерирован без измерения Salesperson:
SELECT NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS
FROM ( SELECT ( { [Item].[Class - Group - Subgroup].[Class].&[XXX]&[1.],
[Item].[Class - Group - Subgroup].[Group].&[XXX]&[2.]&[2.2.],
[Item].[Class - Group - Subgroup].[Subgroup].&[XXX]&[2.]&[2.3.]&[2.3.1.] } ) ON COLUMNS
FROM ( SELECT ( { [Company].[Company].&[XXX] } ) ON COLUMNS
FROM [Sales])) WHERE ( [Company].[Company].&[XXX], [Item].[Class - Group - Subgroup].CurrentMember ) CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS
Я заметил, что даже если я не использую какое-либо измерение в строках (в примерах выше я использовал измерение Salesperson), оно показывает неверный общий итог.
Например, это показывает:
Sales Amount
350
А при использовании измерения Salesperson в строках:
Salesperson Sales Amount
001 1000
002 500
003 750
Grand Total: 350
Ответы
Ответ 1
Пожалуйста, проверьте ваши варианты поворота:
Данные | Сохранить исходные данные в файл
Данные | Сохранить элементы, удаленные из источника данных | Количество элементов, сохраняемых в поле
Если первый установлен, а второй установлен на "Автоматически" или даже "Максимум", то могут произойти ошибочные вычисления, если удаленные элементы в вашем источнике сохранятся в вашей сводной таблице.
Если вы установите значение "Нет" и обновите его, правильно ли он рассчитывается?
Ответ 2
Я подозреваю, что у вас есть необычная Агрегатная функция, установленная на Объем продаж, например, ByAccount, AverageOfChildren. Вероятно, следует использовать Sum. Проверьте свойства показателя Сумма продаж.
https://docs.microsoft.com/en-us/sql/analysis-services/multidimensional-models/use-aggregate-functions?view=sql-server-2017
Ответ 3
Я хотел бы взглянуть на это с другой стороны и предположить, что проблема здесь не в SQL/SSAS, а в Excel. В сводной таблице с промежуточными итогами и общими итогами итоговые значения рассчитываются не кубом, а клиентским приложением. Я испытал это несколько раз и обнаружил, что это известная проблема с Excel. Решение обычно включает создание нового вычисляемого поля в Excel, чтобы обеспечить итоговую сумму. Это расстраивает, особенно если Excel - это клиентское приложение для доступа других пользователей к кубу. Если это утешит, я также испытал это раз или два в других инструментах, таких как Tableau, но по несколько другим причинам с другими решениями.
Вот ссылка на Microsoft KB, подтверждающая проблему. Влияет на версии 2003-2019 !!!
https://support.microsoft.com/en-us/help/211470/calculated-field-returns-incorrect-grand-total-in-excel
Ответ 4
Это скорее дикий удар, но могут ли эти значения в столбце суммы продаж суммироваться во всех ваших иерархиях за год. Например, продавец попадает в несколько иерархий в 2019 году, и в этом случае промежуточный итог правильно фильтруется на основе выбранной иерархии, но в значениях строк, показывающих сумму продаж на одного продавца во всех иерархиях за 2019 год?