Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Baker's Dozen: 13 Productivity Tips for Crystal Reports and .NET : Page 5

These 13 tips show you how to build tools to address common reporting requirements for your business using Crystal Reports with .NET.


advertisement
Tip 6: Custom Reporting
Business Objects produces other tools (such as Crystal Info) that allow end users to generate their own reports. Crystal Reports doesn't provide any out of the box capabilities for users to define their own reports, but you can provide users with a certain level of empowerment (in a controlled environment). The technique isn't specific to Crystal Reports. As an example, suppose your application has six measures that are used to analyze a sales account's performance: profit margin, profit dollars, total costs, total gross dollars, returns, and cost per unit sold. You are building a report that contains other information and only has room for three of those measures. Some may wish to see profit calculations, and others may want to see different figures. You can accommodate this requirement by doing the following:

  • Develop a simple user interface for users to select up to three measures.
  • Design the report's dataset to include three generic columns at the appropriate level of detail (CustomCol1 through CustomCol3).
  • Include three corresponding Header Definition columns in the report's dataset to define the appropriate heading for the selected measures (as you won't know the headings at design time).
  • If formatting differs for any of the three columns (some are displayed as two decimals, some as zero, etc.), you'll need to define additional Definition columns to store this type of information. You can use a Crystal Reports formula to define a particular format (decimals, alignment, etc.) using this definition column.
Tip 7: Report Formulas
Crystal Reports provides a variety of report formulas for math, financial, and string functions. The Crystal Reports formula editor also provides an English-like scripting language for a variety of purposes. Corporate power users who pull data directly from back-end data sources (like SQL Server) for reporting rely on these formulas, as they aren't working with an application tool to further synthesize data.

Like any good user interface, report output should look consistent.
However, Crystal Report's formula capability is a little less necessary for developers, who have the ability to format the final report data through programmatic means—either by stored procedures or local data manipulation prior to report generation.

Generally speaking, the data passed on to a report should essentially mirror what is on the report; additional logic and calculations should be used judiciously. You should view reports as a presentation vehicle for the data, not as a repository for large amounts of business logic. When reports contain large amounts of formulas and calculations, those formulas and calculations create maintenance issues when application changes are made.

As a general rule of thumb, the only types of formulas you really need to use in Crystal Reports are ones that affect the report's appearance. For instance, back in the first report example, you set sales to bold if the value exceeded $5,000, and you displayed the retail price in red if it exceeded $5.00. This is done by defining the following formulas for the column's Font Style and Font Color, respectively:

if {DtProductList.SalesTY} > 5000 crBold; else crRegular; if {DtProductList.AveragePrice} > 5 crRed; else crBlack;

Note that in these examples, you hard-coded the thresholds. You could define these values in a definition table. (Again, reports are all about data!)

Tip 8: Repeatable Reporting Practices
I'd like to spend a few paragraphs on another concept that you can apply to many different reporting projects: a report style-guide.

Just like a good user interface, report output should be consistent. Some development groups build and adhere to report style guides that define conventions for attributes such as font usage and margins. I was a Tahoma man for years, I had a brief fling with Trebuchet, and these days I prefer Verdana. You and your company can use whatever font is best for you.

I generally recommend a maximum of three font sizes on a report. You might want to use 14 point for primary titles, 12 or 10 point for secondary titles, and 8 point for data. Of course, you can use bold and italics as needed. As for margins, I generally use a half inch on all sides. I realize that might make it difficult for reports with a large number of columns. But keep in mind that the output might be reproduced for a binder, manual, or some type of printed package where a very small margin might make it difficult to read. Of course, you may place greater emphasis on being able to display a large number of measures on your report, and that's fine: the point is to think through all the uses of your reports as you make decisions on these attributes.

A style guide should also cover common content and placement. The bar chart in Figure 8 shows several pieces of information that you might choose to display across all reports, and their locations:

 
Figure 8: Crystal Reports makes a nice bar chart with very little effort.
  • Company name and report title (upper center)
  • Report sort order and any primary filter condition (upper left)
  • Date/Time Prepared/User who ran the report (upper right)
  • Company Copyright, URL, phone number (lower left)
  • User footnote and system-generated annotation (lower center)
  • Software version and page X of Y (lower right)
Of course I'm just making suggestions: you want to identify the type of information you wish to display on all of your reports, and identify how/where you want to consistently present them for your application. You may not need all of these pieces of information for every reporting solution, although things like User ID and Data Source can be very helpful in troubleshooting a problem.

Let me suggest a few other things to keep in mind:

  • Watch for labels and text running into each other
  • Make sure you allow enough area/space for currency values
  • Avoid over use of dollar signs on currency columns. I recommend that you indicate in a column heading that the column represents currency (e.g. Gross Revenue $).


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date