Axapta 3.0,AX2009 bug в Report-e: Не корректно работает группировка Section Group.

[Pustik]

Для примера возьмем элементарную задачу: Необходимо вывести номенклатурный справочник через отчет с группировкой по номенклатурной группе. Т.е. создать простенький отчет типа :
Абажуры
абажур для лампы
абажур для светильника
Лампочки
лампочка 40 ватт
лампочка 60 ватт
.........
и т.д.
1)Создаем Report.
2)В Report-e создаем datasource привязанный к таблице InventTable.
3)В свойствe Order by нашего datasource-а добавляем поле ItemGroupId
4)Генерируем Design. Generated Design.
5)В этом Design создаем Section Group и в свойствах прикручиваем ее к полю ItemGroupId
6)В этом Section Group создаем Header и добавляем туда поле ItemGroupId.
7)В этом Section Group создаем Body и добавляем туда поле ItemName.
Все простенький отчет готов.
А теперь сам bug :
Запускаем отчет, никуда в сторону не отходя жмем ОК, смотрим, проверяем - все красиво и замечательно отрабатывает. Группировка на месте. Запускаем еще раз, теперь зайдем на закладку "Сортировка", там по умолчанию уже стоит строчка с Номенклатурной группой (мы ее добавляли в Order by датасорса и прикручивали к Section Group). Удаляем ее (не хотим группировать по Номенклатурной группе) . Жмем ОК. Отчет так же работает корректно. Получаем такие результаты :
абажур для лампы
абажур для светильника
лампочка 40 ватт
лампочка 60 ватт
Запускаем этот отчет в третий раз. Идем на закладку "Сортировка" и добавляем туда строчку с Номенклатурной группой (снова хотим группировать по Номенклатурной группе). Жмем ОК. И уже от группировки не осталось ни следа. Добавляй, удаляй меняй, делай что хочешь,но группировки по номенклатурной группе тебе больше не видать.
Лечится только сбросом настроек для пользователя через Сервис -> Параметры -> Использование данных.
Мы долго не могли разобраться почему беда. Потому что находились в ступоре от вопроса пользователя : Где моя группировка?. Представляете, звонит пользователь, ты проверяешь, что у него группировка по номенклатурной группе стоит, запускаем отчет а ее нет. Пользователь конечно же не рассказывает, что до этого он эту группировку удалял, а потом снова добавлял.
Можно, конечно, переделать отчеты как-то по другому. Но у нас таких отчетов достаточно много, написаны когда-то давно консалтерами. Причем в основном отчеты аля Оборотно-сальдовые ведомости. Стиль написания всех этих отчетов один.
Мои попытки исправить ситуацию без сброса настроек пока ни к чему не привели.
Просьба не трогать поля сортировки пользователей не устраивает. Я уже не говорю про Сервис -> Параметры -> Использование данных. Удаляя оттуда настройки сбрасываются все параметры отчета.
Вообщем пока не очень весело.

[Pustik]

Кому не лень проверить, но лень создавать отчет прикрепляю готовый Report

[Владимир Максимов]

Проблема в переключателе "Выбор запроса". Если при изменении режима сортировки он, тем не менее, остается в значении "Ранее использованный запрос", то, естесственно, будет использовать то, что было при предыдущем запуске. Без группировок. Надо установить его в значение "Используемый запрос"

[Pustik]

Вот оно как оказывается. Сейчас протестировал, да помогает. Но только для репортов, которые запускаются на прямую через обертку RunBaseReportStd. А вот у наследников RunBaseReport ошибка осталась несмотря на выбор "Используемый запрос". Может быть это аналогично или как-то похоже на ранее обсуждаемую проблему В Стандартной АХ2009 не работает кнопка <Параметры> на диалоге класса унаследованного от RunBaseReport ? Может быть, так-же как и PrintJobSettings надо передать и Query?

[Владимир Максимов]

Аналогом выбора "Используемый запрос" является кнопка "Сброс". Результат тот же (возврат к исходному запросу отчета), но работает и в классе, и напрямую в отчете.

Как мне кажется, это глюк (или фича, как посмотреть) построителя отчетов. Собственно, какая ему разница, есть сортировка по полю или нет? Изменилось значение поля группировки - печатаем заголовок/подвал группы. А есть или нет упорядочивание - не должно иметь никакого значения! Пусть хоть для каждой строки будет повторяться одна и та же группа. Это уже не проблема отчета, а проблема пользователя!

Однако разработчики решили по другому. Группировка считается группировкой, если есть сортировка по указанному полю. Весь вопрос в том, когда происходит обновление дизайна отчета. В том смысле, что, вероятно, когда удаляется поле сортировки, то где-то в дизайне сбрасывается какой-то признак. А когда группировка устанавливается этот признак не восстанавливается.

Вот в кеше и остается не корректная версия дизайна. Не запроса! Запрос-то как раз в полном порядке. А именно дизайна. Пока не понял, где это происходит

[Pustik]

Цитата:

Сообщение от Владимир Максимов

Вот в кеше и остается не корректная версия дизайна. Не запроса! Запрос-то как раз в полном порядке. А именно дизайна. Пока не понял, где это происходит

Вот блин. Не подскажете в какую сторону крутить? Где копать? Я поковырялся бы.

[Владимир Максимов]

Если бы знал, уже исправил бы

И SQL-профайлер и инфолог в самом отчете (this.query().DataSourceNo(1).toString()) показывают, что с Query - все в порядке. Вот что указали в настроечной форме, то и используется. Вне зависимости от способа вызова отчета. Значит, проблема в каких-то настройках.

PS: Кстати, лишним подтверждение корректности запроса служит влияние настройки порядка сортировки. По убыванию или по возрастанию. В смысле, она оказывает влияние на отчет.

В принципе, есть нечто похожее. Если в самом отчете встать на узел

\Reports\ReportInventTable\Data Sources\Query\Data Sources\InventTable_1(InventTable)\Order By\InventTable_1.ItemGroupId

То есть такие свойства у этого узла

• AutoHeader
• AutoSum

Не вполне понятно, влияют ли именно они на факт отображени/скрытия шапки и подвала группы, поскольку, например, в исходном запросе они в значении No, но, тем не менее, шапка и подвал группы печатается.

Однако пока никаких других идей по поводу данного поведения нет

[Pustik]

Цитата:

Сообщение от Владимир Максимов

Если бы знал, уже исправил бы (

Я не сомневаюсь в Вашем профессионализме.
Спасибо, Владимир за понятное разъяснение. Как Вы считаете это находится в ядре?

[Владимир Максимов]

Цитата:

Сообщение от Pustik

Как Вы считаете это находится в ядре?

Мне кажется, что "Да". Это ошибка ядра. Хотя, как я уже говорил, не уверен, что это именно ошибка, а не некое действие "по умолчанию".

Удалите в Вашем примере отчета из узла Order By все поля и запустите отчет. Или замените поле ItemGroupId на любое другое. Т.е. поле сортировки источника данных должно отличаться от поля группировки секции отчета.

В этом случае, Group Header и Group Footer отображаться не будут вообще! Почему, собственно? Я не вижу логичных причин подобного поведения. Только программные (так было проще программистам). А баг это или фича - не знаю...

Впрочем, здесь есть некоторое совпадение логики с тем, что в запросах order by не может отличаться от group by. Вероятно, это как-то связано внутри отчета.

[Pustik]

Цитата:

Сообщение от Владимир Максимов

Мне кажется, что "Да". Это ошибка ядра. Хотя, как я уже говорил, не уверен, что это именно ошибка, а не некое действие "по умолчанию".

Еще раз спасибо, Владимир, взволю это на свои плечи.Спасибо.

[Владимир Максимов]

Ну, вобщем, понял-таки в чем дело.

Проблема в том, что при создании поля сортировки непосредственно в отчете идентификация поля выполняется по его FieldId. А когда поле сортировки добавляется через форму настройки запроса, то идентификация выполняется по Extended FieldId.

Применительно к полю InventTable.ItemGroupId имеем

    print 'FieldId = ', fieldnum(InventTable, ItemGroupId);
    print 'ExtFieldId = ', fieldid2ext(fieldnum(InventTable, ItemGroupId), 1);
    pausel

А поскольку 1 <> 65537, то и печати шапки/подвала группы не происходит. Это такая фича генератора отчетов.

Соответственно, если есть желание это исправить, то надо смотреть, почему при добавлении поля сортировки через настроечную форму поле идентифицируется как массив (именно в этом случае требуется Extended FieldId). Ну и в методах формирования Query также убрать конвертацию через fieldid2ext()

[Pustik]

Спасибо за направление. Будем кувырять.