SSRS Reporting Tool

TonyH · 2011-04-28

I would just like to say; if the new NAV SSRS reporting tool was a human being, I would personally invest in a flight anywhere in the world so I could punch it in the face.

](*,)

jglathe · 2011-04-28

You're welcome. I would even invest in a bat to get my point accross.

with best regards

Jens

clausl · 2011-04-28

So as the responsible for reporting in NAV team I guess I will soon have 2 guys standing outside my door with a bat.

Maybe you guys would like to share your frustrations before we get to that?

You are also welcome to connect with me, just write me a pm with your contact details.

/Claus

jlandeen · 2011-04-28

Claus,

While I do generally agree with those here....I think I can resist my base urges and avoid punching you in the face (although you owe me a drink at the next Directions Conference!).

Here's some suggestions:
1) Consider buying Pivoteer and making that the new toolset - their NAV to RDL toolset is better than the NAV out of the box solution and I think they're heading in the right direction
2) Develop a WYSIWIG reporting tool....I understand Crystal Reports, Visual Studio and I, as a developer, can understand and write reports in NAV....but USERS should be able too. I think Alex Chow has posted a very good article and provides some insight into why it's non technical users that need to be able to write reports and not just us propeller heads/code monkeys.

See: http://www.dynamicsnavconsultant.com/2011/03/open-suggestions-to-make-navision-rdlc-reporting-more-efficient/

Alex_Chow · 2011-04-28

The frustration is, and always will be, that the current NAV reporting tool for NAV2009 is for technical people, not end users.

Unfortunately, it's really hard to get the "easier to use" point across... When you get it, you get it.

This is exactly why Apple GUI will always be superior to that of Windows.

Alex_Chow · 2011-04-28

TonyH wrote:

I would just like to say; if the new NAV SSRS reporting tool was a human being, I would personally invest in a flight anywhere in the world so I could punch it in the face.

](*,)

By the way, thank you for the humor of the day!

TonyH · 2011-04-28

jlandeen wrote:

1) Consider buying Pivoteer and making that the new toolset - their NAV to RDL toolset is better than the NAV out of the box solution and I think they're heading in the right direction

I know Pivoteer very well, and its not without its own issues mind...

Alex Chow wrote:

The frustration is, and always will be, that the current NAV reporting tool for NAV2009 is for technical people, not end users.

Unfortunately, it's really hard to get the "easier to use" point across... When you get it, you get it.

This is exactly why Apple GUI will always be superior to that of Windows.

Your right, the tool is vastly more articulate than the standard NAV tool. But its not thats its technical. Feedback within the IDE is poor, as well as how intuitive it is.
Example of a frustration today is that you cannot add more than one field reference from ReportItems into a field in the header.

Alex Chow wrote:

By the way, thank you for the humor of the day!

It was meant to be very tongue in cheeky, I am sure the more I can manage the tool more accurately and have a better experience... Still can't get over the time it takes, and the difficulty involved in something so simple.

t

jlandeen · 2011-04-29

and just so there's no confusion around what I meant when I suggested buying Pivoteer....I mean that Microsoft should really consider acquiring Pivoteer and their technology.

Generally I think the architecture upgrade that we get when going from NAV 5.0, 2 tier to RTC and 3 tier in NAV 2009 is worth some of the problems and missed features...but the report authoriging tool is still a major deficiency and the current tool is just not as good as the old one

Belias · 2011-04-29

Personally, i've had an "I hate reporting" season for the well known reasons:
- report preview <> print preview <> from actual printout
- steep learning curve
- crappy and tedious transformation logic
- IDE RESPONSIVENESS (ms should really work on this), lack of shortcuts...
- .....

but I can say that after a pair of months of (intensive) work on reports, i started to figure out how does it work, what are the "catches" and the known issues etc...and hey, they are cool! In a demo, a report with hyperlinks, colors, collapse/expand feature, autoexport to pdf/excel does its damn good impression!

you're right alex, the time of "customer can create its own reports" is finished, but in my personal experience, none of our customers have ever asked to create its own report (but it's probably due to an italian users lazyness

)...it would be very nice if they would like to create the reports, but i guess that the amount of these customers is something like 10% :-k

P.S.: a lot of users don't even know how to customize a page, how can i pretend they create some report?
P.P.S.: i'm not generalizing, and i'm not saying "users can't do anything"...I'm just saying that an average user usually don't customize pages/reports

jlandeen · 2011-04-29

I think that's where there's a lot of room for improvement. In the majority of the large implmentations that I have done there are client users who end up modifying and creating reports and this is very benfitial to them - it actively engages them with their data and reinforces the use of NAV in their organizations and it reduces the costs on outside consultants and resources.

While I do agree that the new features and functionality of the product are great and an improvement over previous versions, I think having such an intuitive user development interface for reports was a very compelling feature, and that has been reduced in the latest release.

Alex_Chow · 2011-04-29

I'm not talking about a user creating their own reports, because we all know, that's very rare. But even if it's rare, there are still end users creating their own reports using wizards.

I'm talking about users going in there and MODIFYING reports. Most of the time, the user would just like to add an additional field to the report or to their Sales Order. It's very easy to train the user on how to add a field on the sales order with the CAL tool.

I have not found a way teach the users to add fields to the sales header, or any other RDLC reports, without them getting lost. It just look and feel very intimidating.

I just don't know why Microsoft insists on having techies do the design instead of having end users do the design.

Here's a challenge for you Microsofters. Teach Dan Brown to generate a Ship-to Address Sales Statistics by Item report in RDLC. Teach Dan Brown on how to add Shipping Agent and Shipping Agent Service on the Sales Order and Sales Invoice. Then you'll know what our frustrations are.

Alex_Chow · 2011-04-29

jlandeen wrote:

I think that's where there's a lot of room for improvement. In the majority of the large implmentations that I have done there are client users who end up modifying and creating reports and this is very benfitial to them - it actively engages them with their data and reinforces the use of NAV in their organizations and it reduces the costs on outside consultants and resources.

While I do agree that the new features and functionality of the product are great and an improvement over previous versions, I think having such an intuitive user development interface for reports was a very compelling feature, and that has been reduced in the latest release.

At the end of the day, this will always be true:
Easy of Use > Product Feature.

EnricosFolly · 2011-05-01

Reporting is always a sensitive subject. I hate reporting because it is writing in water: each new change of tide erases the work. No report is finished. Reports only become too expensive to modify and clients come to tolerate the difference between what they want and what they have.

The RDLC, a poor cousin of the ReportViewer, is difficult to use and offers insufficient benefits for the bother. The difference now between what the client wants and what they are willing to tolerate is now much broader because any trivial changes cost several factors more than compared to classic.

Two things are necessary for clients to write their own reports: 1) they must know their schema, and 2) they must have sufficient technical resources to utilize any report tool. In my experience the majority of clients in the Navision market space are limited in both their technical and data comprehension and in their technology. This is one of the benefits of the Navision market space for the consultant.

For this reason I concur that clients look toward consultants for affordable support. This has become almost impossible in the RTC report platform.

It seems Microsoft has fitted it's consultant community with a very colorful straight-jacket. Selecting the ReportViewer (or even SSRS for that matter) forces the Navision developer community to learn and use a very complex reporting platform. In the case of the ReportViewer component, the limitations include a single result set and the lack of interactive parameter selections. These are understandable as the ReportViewer consumes an externally-generated result set. Am I mistaken that the version of the ReportViewer which the RTC employs is several versions old? At least you could have used a newer version.

Even SSRS is of little consolation because it carries the same kinds of report limitations that make the ReportViewer component a mis-match for financial and simple reporting: the difficulty in populating dynamic header and footer data; the complexity of group and filter properties; another eccentric expression syntax, and the current disjointed development methodology prove both platforms a bad choice for what is otherwise a straightforward and efficient development and production platform.

There are no programming best practices in the RDLC -- there are only "tricks and workarounds" to get a report to look and behave as it should.

A report platform should be able to consume different and separate data sets, binding the data set to a component and linking components. As an example, I think of web components, like gridviews and combo-boxes, linked in code to a data source. There could be numerous data sources, filtered by logic, and acquired at run-time.

A good development environment should make as much code viewable, simultaneously, as is logically possible -- not hide each data element and property behind an IDE that obfuscates according to scoping and context. Even in a complex ASP.NET page I can view the layout on one page and the code on the other -- all in text and none more difficult to find than a search or even a left-click to follow the menu to the definition of a keyword.

Perhaps the real solution is multiple report platforms. If Navision easily exposed its virtual data (option strings, flow fields, etc.), SSRS would be an appropriate high-end report platform. I do rather like the idea of including Pivotier in the RTC release, too. It's query designer and RDL export capability make it a fine intermediate to outside report platforms.

But there is a need inside RTC for the low-end report tool, too. A mimic of the old Navision report writer, with all its limitations, is still more than enough for 80 percent of the client requests I field. Why do they need the Queen Mary when a runabout will do?

Until something better comes along, I'm stymied when my clients ask (and they will) why it takes twice as much time to modify a report -- or create a new one -- as it did before Navision got all fancified. Shall I tell them that progress means inefficiency? I cannot.

Personally, I think it was a bad compromise, and one that should carry a terrible penalty to the manager who decided that this tool and solution was a good idea.

I hope I have been specific enough. I'll fill in more if you request.

1) Two separate reporting platforms: one simple, one complex.
2) Single development platform: work in Navision or in Visual Studio -- not both.
3) Open code visibility. I want to see everything in one place without having to play "Hide and Go Seek."
4) Ability to bind different sections/components/gridviews to separate data sources.
5) Ability to link components in a report logically. This would allow a powerful parent-child relationship.
6) Expose virtual data (and meta data) as table data or as related web service data. This would allow developers to use external report tools without losing the readability and functionality we appreciate within Naivsion.
7) Provide an interactive query tool inside Navision to generate efficient and appropriately-related data via the SQL Queries produced by the query tool.
8) Give me a debugger that works in the RDLC

Is that enough?

davmac1 · 2011-05-01

I have used SSRS to develop parameter driven (easy to do), multi-company reports.
The problem with multiple companies is the company name prefix, which I solved by using SQL Server's synonyms. Unfortunately the synonyms are global, so only 1 user could run the reports at a time - which was fine for this customer.
With the more typical customer with multiple companies, I would need to find another solution.

I think the SQL Server engine group, the SSRS group, and all the ERP developers live on 3 separate planets.
One example is how long it took to introduce the DATE field (as opposed to DATETIME) into SQL Server.
Now we finally have VARDECIMAL - but only in SQL Server Enterprise.

SSRS does not play well with stored procedures - sometimes it is best to put the SQL statements directly in the report.
SSRS has been positioned as a Crystal Reports replacement, and outside of ERP systems, it has been extrememly successful.

I would like to see the SQL Server group schedule an annual get together of the Engine group, the SSRS group, and all major ERP developers, and come up with a cohesive direction and development path.

I have seen some ERP products push all their reporting to Crystal. I think it would be tough to do the same with SSRS.

kine · 2011-05-02

I think that we will move further in next version. Of course, the question is, which tool is for whom... Right now, the RDLC is for developers/partners, but what is for end-user? Excel? New tools should be focused on end-user (and there will be some). Of course, there are external tools which could be used, but as it was written, they are missing all the additional things inside like option values, flowfields etc.

Chemanel · 2011-05-02

Hello all,

I read of all your post and i'm agree with you. Creating reports in NAV is very frustrating and not really friendly. And more, the
creations/modifications of reports by End Users is totally out of question.

Well, in my project we are looking for another solution. Instead of creating reports directly in NAV, we're studing to create a DataWareHouse. From this end users could directly create all the reports they need in Excell.

Look, there is a video that can show you what is the expected result :

http://www.youtube.com/watch?v=FrhIYxRBaRw (sorry it's in spanish)

It's a LOT more friendy and it's and easy way to create all the report you need in a familair IDE (Excell)

Maybe this could prevent you to don't punch clausl

clausl · 2011-05-02

Next week at Directions EMEA in Berlin I will be there, and here you have an excellent opportunity to punch me, if this what you feel like. I will be the guy with the white t-shirt and glasses.

Although I also have to say that I was not the guy who decided to have our reports in RDLC format, at that time we took that decision I was busy working on something we called the Page Designer, but maybe you also want to punch me for that.
If you want to listen in on what is coming for reports in the next version I suggest you attend my session at Directions. Here I will be talking about how we secure your investment in RLDC reports in NAV 2009 and what new things and possibilities we have in our next version which will improve report design. Also at Directions we will provide a Hands On Lab(HOL) for creating reports in NAV 2009, so if you are new to the RDLC reports in NAV 2009 this will be a good training to go through. We plan to release the HOL document after Directions, so if you are not attending Directions you will not miss out.
I’m happy that you guys are as passionate about reports in NAV as I am, and please continue to punch and hit me with feature request, I read and listen to all feedback and make sure together with the Reporting team that we implement the features requested, if possible of course.
If you feel like setting up a meeting with me at Directions feel free to write me PM or e-mail, e-mail only if you can guess my e-mail address, should be easy.

See you next week at Directions in Berlin,
Claus

Alex_Chow · 2011-05-02

Hi Claus,

Maybe it's a good time to "cut the rope" on RDLC before partners make additional investments in learning this tool? Maybe it's a better investment to develope something more straight forward?

Are there plans to introduce a Pivotier like reporting feature in NAV? It's unreasonable to ask the end user to spend another $5,000.00 for something so trivial as reports.

I know you're probably not the person making these decision, but maybe you can share with us who IS making these decisions. We can voice our concerns to him/her directly.

Alex_Chow · 2011-05-02

Wow.. This sums it up. Enricos, your next round of beer is on me. =D> =D> =D>

EnricosFolly wrote:

Reporting is always a sensitive subject. I hate reporting because it is writing in water: each new change of tide erases the work. No report is finished. Reports only become too expensive to modify and clients come to tolerate the difference between what they want and what they have.

The RDLC, a poor cousin of the ReportViewer, is difficult to use and offers insufficient benefits for the bother. The difference now between what the client wants and what they are willing to tolerate is now much broader because any trivial changes cost several factors more than compared to classic.

Two things are necessary for clients to write their own reports: 1) they must know their schema, and 2) they must have sufficient technical resources to utilize any report tool. In my experience the majority of clients in the Navision market space are limited in both their technical and data comprehension and in their technology. This is one of the benefits of the Navision market space for the consultant.

For this reason I concur that clients look toward consultants for affordable support. This has become almost impossible in the RTC report platform.

It seems Microsoft has fitted it's consultant community with a very colorful straight-jacket. Selecting the ReportViewer (or even SSRS for that matter) forces the Navision developer community to learn and use a very complex reporting platform. In the case of the ReportViewer component, the limitations include a single result set and the lack of interactive parameter selections. These are understandable as the ReportViewer consumes an externally-generated result set. Am I mistaken that the version of the ReportViewer which the RTC employs is several versions old? At least you could have used a newer version.

Even SSRS is of little consolation because it carries the same kinds of report limitations that make the ReportViewer component a mis-match for financial and simple reporting: the difficulty in populating dynamic header and footer data; the complexity of group and filter properties; another eccentric expression syntax, and the current disjointed development methodology prove both platforms a bad choice for what is otherwise a straightforward and efficient development and production platform.

There are no programming best practices in the RDLC -- there are only "tricks and workarounds" to get a report to look and behave as it should.

A report platform should be able to consume different and separate data sets, binding the data set to a component and linking components. As an example, I think of web components, like gridviews and combo-boxes, linked in code to a data source. There could be numerous data sources, filtered by logic, and acquired at run-time.

A good development environment should make as much code viewable, simultaneously, as is logically possible -- not hide each data element and property behind an IDE that obfuscates according to scoping and context. Even in a complex ASP.NET page I can view the layout on one page and the code on the other -- all in text and none more difficult to find than a search or even a left-click to follow the menu to the definition of a keyword.

Perhaps the real solution is multiple report platforms. If Navision easily exposed its virtual data (option strings, flow fields, etc.), SSRS would be an appropriate high-end report platform. I do rather like the idea of including Pivotier in the RTC release, too. It's query designer and RDL export capability make it a fine intermediate to outside report platforms.

But there is a need inside RTC for the low-end report tool, too. A mimic of the old Navision report writer, with all its limitations, is still more than enough for 80 percent of the client requests I field. Why do they need the Queen Mary when a runabout will do?

Until something better comes along, I'm stymied when my clients ask (and they will) why it takes twice as much time to modify a report -- or create a new one -- as it did before Navision got all fancified. Shall I tell them that progress means inefficiency? I cannot.

Personally, I think it was a bad compromise, and one that should carry a terrible penalty to the manager who decided that this tool and solution was a good idea.

I hope I have been specific enough. I'll fill in more if you request.

1) Two separate reporting platforms: one simple, one complex.
2) Single development platform: work in Navision or in Visual Studio -- not both.
3) Open code visibility. I want to see everything in one place without having to play "Hide and Go Seek."
4) Ability to bind different sections/components/gridviews to separate data sources.
5) Ability to link components in a report logically. This would allow a powerful parent-child relationship.
6) Expose virtual data (and meta data) as table data or as related web service data. This would allow developers to use external report tools without losing the readability and functionality we appreciate within Naivsion.
7) Provide an interactive query tool inside Navision to generate efficient and appropriately-related data via the SQL Queries produced by the query tool.
8) Give me a debugger that works in the RDLC

Is that enough?

jlandeen · 2011-05-02

Yeah I think those 8 points really do sum things up nicely....and while I do think Pivoteer is a great reporting tool. A good reporting tool should be built into the base platform rather than an aftermarket add on or something that requires an additional fee. As NAV is targetted at the small to medium enterprises....it's the smaller ones that probably are the most affected by this. The larger implementations can more likely absorb an additional charge.

Howdy, Stranger!

Quick Links

Categories

SSRS Reporting Tool

Comments