использование Reporting Services в Axapta

[AlexeyS]

Постепенно перевожу отчеты на RS и вот какие мысли по этому поводу:

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

в RS удобные механизмы группировки записей,
можно добавить графики, диаграммы
можно повысить удобство работы и настроить цвета ячеек, например по коэффициентам или другим параметрам
с помощью параметра BackgroundColor

=IIF(Fields!ABCRate.Value="A", "Green",
     IIF(Fields!ABCRate.Value="B", "Yellow",
         IIF(Fields!ABCRate.Value="C", "Red", "White")))

WEB доступ удобен, плюс к этому разграничение прав доступа, на основе win пользователей, удобно разложить отчеты по папкам

так как прямой доступ к БД, скорость выше, чем аксаптовские отчеты

можно поставить RS Data Extension и обращаться через фреймфорк к AX 2009,
но с этим пока не разбирался

из минусов - во первых нужно самому писать SQL-запросы и настраивать дизайн - русское название поля и его длину

enum-ы в таблицах это просто числа,
соответственно нужно делать подстановку на уровне SQL запроса.
есть два варианта решения
1.подменять цифры на текст непосредственно в запросе через CASE
2.сформировать таблицу наподобие OlapEnum, где хранить все EnumName, EnumText и EnumValue и join-ить ее (плюс нужно обновлять после каждого изменения в enum-ах)
это можно сделать в случае, если нужно будет делать много отчетов и предпологается активное изменение enum-ов, для небольшого количества проще использовать case
еще остается вопрос - если много раз присоединить такую таблицу в запросе, как это скажется на производительности

вот пример запроса для отчета "ABC по продажам за период"

select ItemID, Sum(LineAmountMST) as Summ, Sum(Qty) as SummQty
into #tmp
from bmssa.CustInvoiceTrans
where InvoiceDate >= @DateFrom and InvoiceDate <= @DateTo
group by ItemID
order by Summ DESC

select IC.ItemCodeDesc, IC.ItemCategoryID, t1.ItemID, IT.ItemName, 
       cast(t1.Summ as Numeric(10,2)) as SoldAmountMST,
       cast(t1.SummQty as int) as SoldAmountQty,
  case when sum(case when t1.Summ <= t2.Summ then t2.Summ end) < sum(t2.Summ) *@RateA/100 then 'A'
       when sum(case when t1.Summ <= t2.Summ then t2.Summ end) < sum(t2.Summ) *@RateB/100 then 'B' else 'C' end as ABCRate,
  case when IT.ABCRevenue = 1 then 'A' 
       when IT.ABCRevenue = 2 then 'B' 
       when IT.ABCRevenue = 3 then 'C' else '-' end as ABCRateOLD, 
       IT.ABCRevenue as ABCRevenueCodeOLD
from #tmp t1, #tmp t2, bmssa.InventTable IT, bmssa.ITEMCATEGORY AS IC 
where IT.ItemID = t1.ItemID and IT.ITEMCATEGORYID = IC.ITEMCATEGORYID
group by IC.ItemCategoryID, IC.ItemCodeDesc, IT.ItemName, IT.ABCRevenue, t1.ItemID, t1.Summ, t1.SummQty

drop table #tmp

а вот как он выглядит

[AlexeyS]

собственно сам отчет. сделан в BIDS 2008

[mazzy]

Цитата:

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

есть два варианта решения
1.подменять цифры на текст непосредственно в запросе через CASE
2.сформировать таблицу наподобие OlapEnum, где хранить все EnumName, EnumText и EnumValue и join-ить ее (плюс нужно обновлять после каждого изменения в enum-ах)
это можно сделать в случае, если нужно будет делать много отчетов и предпологается активное изменение enum-ов, для небольшого количества проще использовать case
еще остается вопрос - если много раз присоединить такую таблицу в запросе, как это скажется на производительности

По-моему,
1. хардкодить в запросе - плохой путь.
2. Но и массовый join для разыменования enum'ом - тоже плохо.
Может есть еще какой-нибудь путь?

[glibs]

Цитата:

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

...
и предпологается активное изменение enum-ов
...

Гм...

Вообще, если код системы постоянно изменяется на таком уровне... стоит подумать... может что не так.

Представьте себе, что Микрософт будет раз в 3 месяца обновлять список системных перечислений (я имею в виду перечисления а-ля RangeStatus, JoinMode). Я думаю, что пользователей постоянное обновление перечислений тоже несколько может озадачить.

Цитата:

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

...
проще использовать case
...
еще остается вопрос - если много раз присоединить такую таблицу в запросе, как это скажется на производительности
...

Если таблица будет небольшая, то проблем с производительностью я бы ожидать не стал.

Что касается CASE — тоже не панацея. У меня был такой опыт. Долговато отрабатывал запрос в парочке VIEW, на основании которых строился OLAP отчет. Ни план исполнения запроса, ни код VIEW особых подозрений не вызывал. Была только одна особенность. Текст этой VIEW был длинный. 10 Кб +/- колометр. Пытаясь разобраться в коде... который, должен признаться, целиком в мое сознание не помещался... я его сократил, вынеся часть логики в пользовательские функции, сократив тем самым количество букв, но нисколько не поменяв сам код. Просто чтобы его понять можно было. Скорость построения запроса после этого возросла на порядки. Я не помню точно было это еще в 2000-й или 2005-й версии, но с тех пор я решил не "парить мозги" без особой надобности парсеру запросов.

В общем, я за таблицу . С пересчислениями я не связывался еще как-то. Не пришлось. У нас были группировки более высокого уровня в отчетах, которые были у пользователей в голове, но которых не было в Аксапте. Таблички стали заводить в Аксапте. Там удобно создавать формы, с помощью которых редактировать данные. В первый раз чтоб побыстрее создал в БД напрямую, чтоб быстрее, но сразу понял неудобство такого подхода.

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

Если бы я создал что-то для перечислений, я бы постарался отказаться от идеи обновления таблицы автоматически . Из принципа исключительно. Ну не должны перечисления постоянно меняться.

[mazzy]

Цитата:

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

Вообще, если код системы постоянно изменяется на таком уровне... стоит подумать... может что не так.

Енумы могут просто добавляться.

[glibs]

Цитата:

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

...Енумы могут просто добавляться...

После того, как система уже некоторое время или даже давно в промышленной эксплуатации, причем они это делают настолько постоянно, что целесообразно писать автоматическое обновление таблицы (списка переводов по языкам)?

Я остаюсь при своем мнении.

[glibs]

Цитата:

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

...Я остаюсь при своем мнении...

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

[AlexeyS]

Цитата:

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

После того, как система уже некоторое время или даже давно в промышленной эксплуатации, причем они это делают настолько постоянно, что целесообразно писать автоматическое обновление таблицы (списка переводов по языкам)?

Я остаюсь при своем мнении.

на мой взгляд enum-мы могут только добавляться

вопрос в трудозатратах - постоянно использовать case, при этом код получается несколько громоздким, или одним махом создать таблицу перечислений и использовать join-ы.
в случае большого количества отчетов склоняюсь к этому варианту. а обновление этой таблицы - административная задача при обновлении AOS, а это чаще всего бывает на этапе внедрения и разных доработок

[Yaroslav]

Цитата:

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

select ...
into #tmp
...

Cкажите, а какую версию SQL сервера Вы используете?
Насколько мне известно, RS в SQL 2005 не позволяет использовать временные таблицы, приходиться использовать табличные переменные, а это приводит к некоей потере производительности.
В SQL 2008 это уже не так?

[TravellerInTime]

Цитата:

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

Насколько мне известно, RS в SQL 2005 не позволяет использовать временные таблицы

С чего Вы это взяли? Очень часто использую временные таблицы в запросах RS в SQL 2005!

Цитата:

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

приходиться использовать табличные переменные, а это приводит к некоей потере производительности.

Но не к такой, чтобы об этом задумываться...

[Yaroslav]

К вопросу о создании в базе таблицы по Enum'ам - когда у нас Аксапта только внедрялась и ее возможности я знал плохо, а вопрос отчетности уже встал, то я написал скрипт на Perl, который принимает на вход XPO файл с выгруженными Enum'ами (с метками) и генерирует SQL-скрипты для создания в базе таблицы Enum'ов и меток.
Может кому пригодиться.

[AlexeyS]

Отчеты в Аксапте можно делать двумя способоми - Visual Studio или с помощью Report Builder

Основной принцип такой
1. В AX (в AOT) создаются перспективы (есть преднастроенные),
это модель данных, которая содержит таблицы, перечислимые типы данных, валюта, язык
эта модель будет использоваться в RS как источник данных для отчета
2. В AX настраиваются URL-и для Web-сервиса и Report Manager
3. Для создания отчета используется Report Builder (запускается прямо из браузера)
в нем выбирается модель данных, тип отчета и собственно создается отчет
4. настраиваем права доступа через Web или SQL Server Management Studio

вещь реально очень мощная и довольно простая, не хватает только описания как это работает, чтобы "пошло в массы"

[kalex]

Для перечислимых типов делал следующее:
1. SQL запрос выбирает числовое значение перечислимого типа.
2. Уже в дизайн отчета вставляется вычисляемое поле с функцией choose(<Поле перечислимого типа>+1, список наименований)
Не претендую на оптимальность, но как вариант...

[Alexx7]

Господа.
А что почитать стоит (какую книгу какого автора) по "теме использование Reporting Services в Axapta" или может быть у когонибудь есть в электронном варианте можно даже на английском. Поделитесь с новичком.

Спасибо.

[AlexeyS]

на русском это прежде всего "Microsoft SQL Server 2005 Reporting Services. Профессиональная работа с отчетами. От создания до управления" Ларсон Б.
также http://msdn.microsoft.com/
http://sql.ru/forum/actualtopics.aspx?bid=57

на английском полно документации и книг в электронном виде.
но лично я медленно читаю на английском и в принципе полностью хватит первой книги

[AlexeyS]

еще есть видео на www.techdays.ru/category/2/1.html