Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Since our Adempiere implementation we have had resistance from our end-users to take up the writing of their own reports.
One of the impediments to writing reports is the data driven nature of the task. Only our more technical people have attempted to do this, and even they have struggled with some of the idiosyncrasies of what can sometimes be the complex task of writing reports.
One suggestion that has been mooted was that when you hit the configure report button, we could have an option to go into a graphical based report writer which translates the layout into the underlying data. Later you could re-enter the data driven side of things to help fine tune the layout (ie a graphical tool similar to Jasper, but targeted at producing the drillability of the inbuilt reports).
I am interested in understanding the experiences of others with the built-in report writer and what others might have as ideas for enhancing this area of functionality to avoid the unnecessary engagement of technical IT staff.
Perhaps if there were enough interest, collectively we could fund an enhancement in this area.
The integration of ADempiere with Jasper Report is a step in this direction. iReport is a very good report writer just like the commercial Crystal Reports. And generating reports is a little technical too. For ordinary users can use built-in print format feature which is simple enough to use
What I am saying is that real non-IT users do not find the inbuilt adempiere report writer easy to use - they get frustrated at trying to get everything aligned correctly because everything is driven off the data, it's not visual, and so for the majority of people who can't translate visual requirement to data (that's a large subset of people) this is a big ask.
I have some extra ideas for reporting functionality that would extend the usefulness of the inbuilt report writer.
What if instead of just reporting on the header table, the report writer would understand the form relationships to sub-tabs. This could then be used for allowing people to run reports on the header and detail tabs - something much more powerful than having someone technical create views so that reports could be constructed.
Combine this form reporting power with a GUI, and we could empower end users to create much more useful reporting.
What do others think of this enhancement?
Do you have any other ideas that would make end-user reporting more efficient and useful?
Another idea for extending the usefulness of end-user driven reporting - improvement to the find function.
As per the idea about allowing reports to leverage off the tabs in a form, the same could be find for the record Find function - ie. the concept of extending filters to include sub-record data (e.g find all orders on a certain date, with a certain product). Again this avoids the need for developers to create views for things that are already defined in AD.
Redhuan D. Oon
If there is one good thing going for the inbuilt reporting tool it will be its reporting on the fly capability (as seen in this http://www.adempiere.com/index.php/E-ticketing#Reporting_On_The_Fly example).
I agree with Allan then that a GUI would then be needed for the single form (with sub form) formatting. The framework is already there. There can be auto checking for form fitting position and sizing of the printed fields. Or auto generating of it like the grid view one.
Its better if you can list a few other applications with such features.