Report localization for Crystal reports (Conditional processing)

Report localization

Software localization is a complex process, which may involve changes in design for various reasons (local language habits, regulations, currencies, measures, date and numeric formats, etc.).  While application localization is usually limited to text, report localization often also includes the layout. Applications are designed around the concept that the user interface is dynamic, will work with different resolutions and windows’ size might be changed by the user. In addition, applications usually do not require a fixed layout and the controls can be rearranged to fit the available space. There are also scrollbars, tabs etc. which can be used in case the available space is limited. Reports are very different. Often, they are expected to look in a certain way and since they are bound to a fixed paper size, they might need to be rearranged manually. A classic example is an invoice. An invoice is an accounting document that requires certain attributes to be included. Different countries may require different attributes. Obviously, invoices might use different languages and the field size may vary significantly. Here is a sample with invoices in English and Spanish. The size of the label for Company ID is wider in Spanish

As a result, the distance between “Bill To” and “Issued By” areas on the Spanish invoice (marked as 2) will be smaller than the distance between the same areas on the English invoice (marked as 1). In addition, the “Base de IVA” and “Tipo de IVA” fields (marked with 3), are for VAT tax used in the European Union and are not required on the English invoices for US clients.

Here is how the two invoices look side by side

In some scenarios, you can handle localization by adding subreports and using a parameter to suppress non used language. However, the invoice report above already contains a subreport showing invoice details and since Crystal reports does not support nested subreports, you cannot use subreports for the language level. In addition, you may have a single Invoice in Spanish, which will cover all your scenarios, but you may need to use 2 different reports in English since regulations in the UK and US are different and you need to include VAT on the UK invoice. VAT also has different rates for different items (VAT for food is different than VAT for machinery). The US invoice most likely will include sales tax, which is calculated in a very different way. In addition, in some countries you can send an invoice and expect to be paid in certain period, in others you will send a quote and, when it is paid, you will send an invoice for the payment. So, you may need to create 1 huge report, with one or more subreports for each language/country and you need to create a logic inside the report, which will suppress most of the subreports and use or ignore specific parameter values. In some cases, the software or the user will have to provide value for a parameter, which may be ignored because the subreport, which possibly will use it, is suppressed. You will also need to test the report for all languages, every time you make a change. This is a classic example of code debt because of a broken Separation of concerns principle. The report should address the concern to present a data record. The logic, which decides which report will be used should remain outside the report since it has nothing to do with the data record, but addresses the concern HOW the data record will be presented. For this reason, it is not a good idea to handle localizations with subreports even in SSRS, where nested subreports are supported.

Localization with RT Report Manager Workflow

RT Report Manager provides a workflow interface, which will allow you to run reports based on parameter/data field values. The interface will allow the user to run an Invoice and request a certain language/country layout to be used. Internally RT Report Manager will run a report based on your workflow settings and provided parameter values. To achieve this, define a job and add all reports that you may need to use. Then create a “Before Action condition” for each report. The sample below will print the English report if the language is “English” or “Both”, otherwise it will go to the next step and will not run the English report. In a similar way, it will print the report in Spanish, just in case the selected language is “Spanish” or “Both”.  

Obviously, if you want to handle US/UK invoices, you will need to have separate English-US and English-UK versions.

In the sample above, RT Report Manager will print English, Spanish or both reports based on the user selection for language.

• Appendix A shows a PDF generated by RT Report Manager when the user selects both languages. The PDF will have 2 bookmarks, one for each report and 2 pages, one with the English invoice and one with the Spanish invoice
• Appendix B shows a PDF generated by RT Report Manager when the user selects English languages. The PDF contains one page in English
• Appendix C shows a PDF generated by RT Report Manager when the user selects Spanish languages. The PDF contains one page in Spanish

Appendix A

Appendix B

Appendix C

Advantages to use workflow and separate reports instead of multi-language report with subreports:

• Separation of concerns principle is not broken because the logic, which report to use, is outside the report.
• Faster репорт processing. When loading a multi-language report with subreports, the reporting engine will read the whole report file, parse it and render it. There will be languages, which will be suppressed, but they still will be loaded. Single language reports will be much smaller and faster to process and the engine will load just the language, which will be rendered.
• Faster development and testing. Changing the Spanish subreport in a multi-language report with 5 languages will require testing all subreports and there will be at least 5 different tests. Changing a Spanish report when a workflow is used will require testing just the Spanish report so the number of tests will be reduced 5 times. You can add as many reports as you want to the workflow and it will not get more complicated.
• Flexibility. The workflow allows the addition of external files. For example, workflow may cover scenarios, where you need to append a file based on some conditions.
  • append Welcome letter to the first invoice of the customer.
  • append documents with specifications for items in an order.
  • append a flyer for the new store if the customer is in the zip of the store.

There is no easy and safe way to append additional external documents, for example PDF files, based on conditions using subreports. Subreports with OLE object might be considered a partial option, but it has memory and formatting issues and doesn’t support multiple pages.

Automated invoice generation

The example above shows manual run of a report. It might be useful in some rare scenarios when you need to generate a single invoice manually. However, most of the time you will need to generate invoices for the day, week or in real time as it is explained in the article Continuous Processing with RT Report Manager. In these scenarios you can combine a data driven job with workflow and retrieve the list of the invoices including Country or Language field. Then use this field to determine which report to run. Here is how it will work. Create a data driven job with a command like this:

Returned data will be something like this:

Data driven job will loop through the returned records, will load the first one and go as follows:

1. Based on the value in the "Country" field, which for the first row is Italy, load Italian report
2. Set report parameter InvoiceID using the value in field InvoiceID. The value for the first row is 2134
3. Export report to a PDF and name it "Invoice # 2134" using a formula like "Invoice # {InvoiceID}"
4. Create an email with a body
   Dear Mr. Rovelli
   Please find attached the invoice for .....
5. Send the email with the attached PDF file to rovelli@sportscenterville.com
6. Run a separate command to set IsProcessed field in Invoice table for InvoiceID = 2134
7. Go to the next record and process it in from point 1.