Printing reports or/and labels is part of your software?
Then FlxReport is the solution to your headaches.
In a few words: no matter what report you design, it will never satisfy all users (and practically maybe not a single one). Each customer is unique and thus has specific needs: label size, layout, use of special letterhead paper, hiding confidential data, and so on...
With this said, what are the available solutions?
Solution 1 - Multiplying reports creation
This solution is to create as many reports as customers. It's the first thing one have in mind. It's the fastest one to start a project even it is... the worst!
With 5 or 6 customers: no problem, with twenty: starts being challenging. Now with 500 customers: your biggest nightmare. Maintenance costs for that solution are tied to the number of customers and number of reports. In case you modify the database's structure, you might have to change 500 reports because of a new retrieval argument, not including testing time. Moreover, we end up doing one PBL per customer and one custom CD.
Solution 2 - Infomaker
This solution supposes that the client will modify the reports by himself using Infomaker. Might look like the ideal solution but practically is never realistic for various reasons.
First, your customers will not want to spend time doing that nor have the knowledge to do it. Second, it rises some security issues if the customer modifies the SQL statement or retrieval arguments list which might have unexpected behaviour from the application.
Solution 3 - The FlxReport
This is the ideal solution. It is an independent module that effortless allows managing an infinite number of report customizations. Some of the strengths:
- Structure: customizations are not stored in a PBL but well in the database or in export files which makes it easy to send to customers.
- Maintenance: one key asset is the automatic update if a SQL statement changes or a retrieval arguments list is changed. Nothing you have to do on your side or on the customer side, the only thing to be changed being the standard report.
- Security: The SQL statement or retrieval arguments are not accessible, only the visual part of the report is updateable (fields, groups, sort order, filters...)
- Dynamism: the customer wants to change something on a report. With FlxReport, no need to regenerate the PBL or worse, recompile the whole application. You can even make real-time customizations during a demo to demonstrate your software's flexibility.
- Ease of use: the SQL statement being irrelevant in FlxReport makes it possible for the developer to delegate the reporting designs to consultants or hotline staff.
- Diversity: imagine your customer requires different access levels for the reports (to hide confidential data for example), FlxReport allows you to create customizations based on the user's profile. Administrators would see custom report 1 and regular users custom report 2.
Interested ? Download the video presentation here :
Just unzip and launch the file flxreport.htm (if you are using 1024x768 resolution, maximize your explorer for optimized video).
For more information, contact us at :