It looks like you're new here. Sign in or register to get started.
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.
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
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.
Alex Chow wrote:
By the way, thank you for the humor of the day!
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.
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?