The advent of ActiveReports 7 provided us two different reporting formats in just one ReportingTool. This not only provides more options of reporting but also a better value for money.
Why a Reporting Tool?
Collecting and organizing data is one of the most cumbersome tasks for most of us. But a reporting tool not just makes it easier but also more organised and presentable. With a reporting tool, we just need to provide the datasource, set a few properties here and there and data can be represented in groups, charts, tables etc. Hence, a format that is far more acceptable and easier to comprehend from a user's perspective. ActiveReports offers this and much more as an integrated ad-hoc report designer for Microsoft .Net developers. It also offers Multiple Report types to fit the needs of one and all.
Section-based reports are the banded reports with predefined sections namely - Page header , Detail , Page footer. From Invoices to Budget and Sales-Accounting reports or even a school report card, virtually any report can be divided into these 3 basic sections. Reporting eventually reduces down to just binding data to control or providing a data source to fetch from and leaving the reporting engine to render beautiful and professional reports. We can further customize these reports using code/scripts in the report events. The detailed concepts (structure/events etc.) of SectionReports are discussed here.
User Scenario : Lets consider a case of a supermarket where a simple invoice needs to be generated on the basis of the products sold. The invoice will start with the name of the store, its address and contact details, followed by a summarized view of total amount due before taxes, taxes involved and amount due after taxes. It will then display the list of all purchased items, their quantity and final price. This list may go on till several pages and finally the total amount, calculation for taxes and the final amount due would be displayed.
The design of the report would be in the following manner : ReportHeader would have the fields displaying : name of the store, its address and contact details Detail would have the fields displaying : purchased items, their quantity and final price ReportFooter would have the fields displaying : total amount, calculation for taxes and the final amount due The final report would look like the following :
Sometimes designing of reports requires that each page be designed to a specific need. Even though many workarounds can be created with Section based report it becomes a little painstaking. Page based reports are the perfect solution in such scenarios. In this case, each page is an object and can contain controls both that need to be fixed and that need to be repeated to show data from a data source. Even PageReports offers two layouts to meet all the user-needs and provide the most interactive options.
1. Fixed Page Layout :
This kind of layout is a 100% 'What you see is what you get'. Each page is a canvas and the controls can be dropped anywhere on it. Unlike SectionReports it does not have a fixed header/footer and hence this report can be best the option when Vertical PageHeaders are required. Under ideal condition, the fields are not allowed to grow/shrink and hence we may design it exactly the way we want it to get displayed. However, this isn't any limitation and Page-Based reports does have specially designed controls to handle such situations. They can be placed according to need where we wish to display the overflown data. This kind of reporting is best for creating form based reports and multiple layout reports.
User Scenario : Lets again talk about the SuperMarket. This time from a different perspective to handle the billing. Everytime a bill would be generated, it will have the name of the store, its address and contact details at the top of each bill. It will then display the list of items purchased by the customer and sum total of the bill. A desirable situation would be to have two copies for this bill: one for the store and one for the customer. The store's copy will have a 'Merchant's Copy' message and might also include customer's detail (name, contact number) for further follow up. It might also include the name of the person at the billing counter for the day.
Since the details are specific, we can use parameters to enter them at the time of report generation. On the other hand, the customer's copy would have a 'Customer's Copy' message, store's tollfree helpline number and the other messages like 'NoRefund/NoExchange', 'Thank you for Shopping' etc. In such a scenario, a report with two pages (one for cutsomer's copy and other for store's copy) can be created and each page would have a different layout. The final report in this case would look like the following :
2. Continous Page Layout :
The CPL report is the most interactive type of report. Controls can grow and shrink, one can set up interactive sorting, drill-down reports in which detail data is initially hidden, and can be toggled by other items, and add drill-through links to other reports and to bookmark links within reports. CPL reports are ideal when you need to show data from different data sets, and when you do not need to control where the data appears on the page. Hence, the CPL offers best of both worlds. The liberty to design each page according to need and the fun of not bothering about how much space is allotted to which control.
User Scenario : Considering the Supermarket example once again, how would CPL fit in this scenario. It would be best suited in a situation when the Supermarket might want to create an 'end of the year' report highlighting its total sales that year (Category wise) with a chart representation of the same, list of the 5 most loyal customers and its 5 most valuable employees. Designing this report will be a breeze with CPL.
The final report would look like the following :