Defining and Designing Reports

This section describes how to configure your third party reporting tool and how to define your reports in the system to enable users to submit reports online.

Contents

The Big Picture Of Reports

Configuring The System To Enable Reports

Sample Reports Supplied with the Product

How To Define A New Report

The topics in this section describe the approach for designing and defining your system reports.

Contents

Integration with BI Publisher and Business Objects Enterprise

How To Request Reports

Viewing Reports

Integration with BI Publisher and Business Objects Enterprise

Your DBMS, your product, and BI Publisher or Business Objects Enterprise / Crystal Reports can work together to produce reports.  You may choose to use a different reporting tool, but this may not be a trivial effort.  This section provides high-level information about some of the business requirements that are being solved with the reporting solution.

Contents

Reports Must Be Multi-Language

Requesting Reports from The System

Overview of the Data - BI Publisher

Overview of the Data - Business Objects Enterprise

Reports Must Be Multi-Language

The system supports a multi-language implementation and the reporting solution for the system must also support a multi-language implementation.

·         If a French-speaking user requests a given report, all labels, headings and messages are in French.  If the same report is requested by an English-speaking user, all information is in English

·         Different fonts may be necessary for a given report (the font for Chinese is rather different than the font for English)

·         Dates and numbers must be formatted as per the user’s profile in your product

·         Currency must be formatted as per the currency definition in your product

In order to provide the above functionality, the third party reporting tool must do the following:

·         Access the system's field and message metadata for labels, headings and messages (as different values can be defined for different languages in system's metadata)

·         Retrieve the appropriate font, size, and layout based on the requested report and the user’s language

·         Use the currency code information in the system to format currency-oriented information

·         Use the user’s display profile to format date and number fields

Requesting Reports from The System

Although reports are rendered in your reporting tool, users must be able to request ad-hoc reports from within the system (assuming users have the appropriate security access).

·         The prompts for the input parameters must be shown in the user’s language

·         Users should be able to use the standard search facilities to find parameter values

·         Plug-ins can be optionally used to cross-validate input parameters

·         Application security must authorize ad-hoc report requests

Overview of the Data - BI Publisher

The following diagram provides an overview of where data is stored for your reports for integration with BI Publisher.

Application and BI Publisher

The application contains:

·         The application data that appears on your reports.

·         The language-specific headings, labels and messages on your reports.

·         The layout file name to be used for the report.

BI Publisher contains:

• How your reports look.
• Information about scheduled reports and reports that have already run.

The DBMS contains the SQL used to retrieve the data on your reports (residing in database functions).

Overview of the Data - Business Objects Enterprise

The following diagram provides an overview of where data is stored for your reports for integration with Business Objects Enterprise.

Application and Business Objects Enterprise

The application contains:

·         The application data that appears on your reports.

·         The language-specific headings, labels and messages on your reports.

·         For Business Objects Enterprise, the font and size in which each report is rendered.

Business Objects Enterprise contains:

·         How your reports look.

·         When your reports are produced (the batch scheduler).

·         Historical images of reports.

The DBMS contains the SQL used to retrieve the data on your reports (residing in stored procedures).

How To Request Reports

A user may request an ad hoc report from within your product:

·         A report submission page enables a user to choose the desired report and enter the parameter values for the report

·         The user must be granted security access to the report

·         The request is passed to the reporting tool real time.  Refer to Configure The System to Invoke BI Publisher or Configure The System to Invoke Business Objects Enterprise for more information.

·         The reporting tool generates the report and displays it in a new browser window

The reporting tools' scheduler creates reports (as per your schedule)

·         This function is entirely within the reporting tool.  No scheduling functions reside within your product.

A user can request an ad-hoc report from within the reporting tool

·         Note, the user’s ID must be supplied as a parameter to the report in order for the user’s profile to be used to format dates and numbers

Viewing Reports

As described above, ad-hoc reports requested from within your product are displayed immediately after they are generated in a new browser window

Crystal’s report repository can be used to retrieve historical versions of a report.  The Report History page allows users to open the Crystal’s report execution history page and request a view of this report.

Contents

Configuring BI Publisher Reports

Configuring Business Objects Enterprise Reports

Defining Reporting Options

Defining Report Definitions

Configuring BI Publisher Reports

This section contains topics specific about configuring the product to interoperate with BI Publisher.

Contents

Configure the System to Invoke BI Publisher Real-time

Batch Scheduling in BI Publisher

Configure the System to Invoke BI Publisher Real-time

The base product provides an installation algorithm plug-in spot called Reporting Tool.  This plug-in spot should contain an algorithm that invokes the third party reporting tool real-time. 

For BI Publisher, the system provides an algorithm type called F1-BIPR-INV, which invokes BI Publisher.

These algorithms rely on information defined in the Reporting Options table: the reporting server, reporting folder and the user name and password for accessing the reporting tool.  The values in the reporting options should have been set up when the system was installed.  Contact your system administrator if there are any problems with the values defined on the reporting options.

To use the algorithm types to invoke BI Publisher, perform the following steps:

·         Create an algorithm for the appropriate algorithm type.

·         On the installation options, add an entry to the algorithm collection with an algorithm entity of Reporting Tool and indicate the algorithm created in the previous step.

Batch Scheduling in BI Publisher

For many of your reports, you probably want the report to be produced on a regular basis according to a scheduler.  The reporting solution relies on the BI Publisher software to provide the batch scheduler functionality.  Refer to BI Publisher documentation for details about configuring the batch scheduler.

Configuring Business Objects Enterprise Reports

This section contains topics specific about configuring the product to interoperate with Business Objects Enterprise.

Contents

Configure the System to Invoke Business Objects Enterprise Real-time

Batch Scheduling in Business Objects Enterprise

Configure the System to Invoke Business Objects Enterprise Real-time

The base product provides an installation algorithm plug-in spot called Reporting Tool.  This plug-in spot should contain an algorithm that invokes the third party reporting tool real-time. 

For Business Objects Enterprise, the system provides an algorithm type called RPTE-INV, which invokes Business Objects Enterprise.

These algorithms rely on information defined in the Reporting Options table: the reporting server, reporting folder and the user name and password for accessing the reporting tool.  The values in the reporting options should have been set up when the system was installed.  Contact your system administrator if there are any problems with the values defined on the reporting options.

To use the algorithm types to invoke one of the reporting tools, perform the following steps:

·         Create an algorithm for the appropriate algorithm type.

·         On the installation options, add an entry to the algorithm collection with an algorithm entity of Reporting Tool and indicate the algorithm created in the previous step.

Batch Scheduling in Business Objects Enterprise

For many of your reports, you probably want the report to be produced on a regular basis according to a scheduler.  The reporting solution relies on the Business Objects Enterprise software to provide the batch scheduler functionality.  Refer to Business Objects Enterprise documentation for details about configuring the batch scheduler.

The product provides a report history page to display report instances that were produced via the batch scheduler and are stored in a repository.  The report history page relies on the reporting tool algorithm to invoke Business Objects Enterprise and display the historic instances for the selected report.

Defining Reporting Options

The reporting options are provided as a mechanism for defining information needed by your reporting solution.  The base product uses the reporting options to define information needed to access the reporting tool from within the system using the algorithm defined on the installation option.

Navigate to this page using Admin Menu, Reporting Options.

Description of page

The following information must be defined to interface with BI Publisher real-time.  Contact your system administrator to report any problems with the settings defined here.

Reporting Folder                                 Defines the shared folder where reports are stored. 

                                                            For Business Objects Enterprise, defines the name of the virtual directory on the server where Java Service pages (JSP) are located. The reporting tool algorithm uses this information to construct the URL to launch the reporting tool.  The reporting tool algorithm assumes that a JSP named “logon.jsp” is located there. 

Reporting Server                                 Defines the URL of the web application where the reporting tool is installed.  For example, using BI Publisher, the format is: http://<BI Publisher Server>:<port>.

Reporting Tool User ID                        Not applicable when integrating with BI Publisher.

                                                            For Business Objects Enterprise, defines the user id to use when logging in.

Reporting Tool Password                    Not applicable when integrating with BI Publisher.

                                                            For Business Objects Enterprise, defines the password to use when logging in.

Where Used

This information is used by the reporting tool algorithm on the installation option to invoke the reporting tool software.

Implementations may use reporting options to record other information needed for their reporting tool.

Defining Report Definitions

For each report supplied by your installation, use the report definition page to define various attributes of the report.

Contents

Report Definition - Main

Report Definition - Labels

Report Definition - Parameters

Report Definition - Main

Navigate to this page using Admin Menu, Report Definition.

Description of page

Enter an easily recognizable Report Code and Description for each report.  Use the External Reference ID to define the identifier for this report in your external reporting tool.

Define an application service to enable users to request submission of this report online or to view report history for this report.  Once you define an application service for each report, use application security to define which users may access this report.

If you have more than one parameter defined for your report and you wish to perform cross-validation for more than one parameter, provide an appropriate Validation Algorithm.  Click here to see the algorithm types available for this system event.

Enter a Long Description to more fully describe the functionality of this report.  This information is displayed to the user when attempting to submit the report online or when viewing history for this report.

For BI Publisher, if you want to use one of the sample reports provided by the system, but with a different layout, indicate the layout to use for the report in the Customer Specific Font / Layout fieldand BI Publisher uses this information instead.  The name for base report layout is <report code>_Base. For example, a base layout for CI_VACANT is named CI_VACANT_Base.

For Business Objects Enterprise, the Report Font and Report Font Size are used to control the display of the report information.  If you wish to use one of the sample reports provided by the system, but wish to use a different font and font size, indicate your Customer Specific Font in the Customer Specific Font / Layout field and Business Objects Enterprise uses this information instead.

Report Definition - Labels

Navigate to this page using Admin Menu, Report Definition and go to the Labels tab.

Description of Page

In order to provide multi-language capability for each report, the labels used for the report must support multiple language definitions.  For each label used by your report, indicate a unique Sequence and the Field used to define the Label.  The label defined here should be the same label that is defined in your report layout defined in the external reporting tool.

When rendering an image of the report, the external reporting tool retrieves the appropriate label based on the language used for the report.

Report Definition - Parameters

Navigate to this page using Admin Menu, Report Definition and go to the Parameters tab.

Description of Page

The Parameters scroll contains one entry for every parameter defined for the report.  To modify a parameter, simply move to a field and change its value.  To add another parameter, click + to insert a row and then fill in the information for each field.  The following fields display:

Parameter Code                                  The identifier of the parameter.  This must correspond to the parameter definition in the reporting tool.

Required                                              Turn on this switch if the user must supply a value for the parameter when submitting the report.

Sort Sequence                                     Indicate the sort sequence for this parameter.  This sequence must match the parameter order defined in the reporting tool's report.  It is also used when displaying the list of parameters on the report submission page.

Characteristic Type                              Indicate the characteristic type used to define this parameter.

Default Value                                       Use this field to define a default value for this parameter.  Default values are displayed to the user when the report is chosen on the report submission page.

Description                                          Define a brief description of the parameter.  This description is used when displaying the parameter on the report submission page.

Long Description                                 Define a detailed description of the parameter.  This description is used on the report submission page when the user requests more information for a given parameter.

The system provides several sample reports that may be used by your organization as they are or as a starting point for creating a new report.  The following sections provide an overview of the sample reports along with instructions on how to use one of the sample reports in your implementation environment.

Contents

How to Use a Sample Report Provided with the System

Subreports Used with Crystal Reports

How to Use a Sample Report Provided with the System

If you would like to use any of the sample reports, you need to perform some steps to be able to execute them in an implementation environment.  This section walks you through the steps needed.

Contents

Steps Performed at Installation Time

How To Copy A Report Definition From The Demonstration Database

Steps Performed at Installation Time

The Installation Guide provides instructions for setting up and configuring your product and reporting tool to use the sample reports provided with the system.  The following steps are described there.

·         Setting up the stored procedures used by the sample reports.

·         Defining the company title and logo used by the sample reports.  Note the company name used as a title in the sample reports is defined as a message on the installation options.  For information about installing the company logo, refer to the Reports Configuration chapter of the Installation Information. 

·         Defining a user for integration with your product.

·         Publishing the sample reports in BI Publisher or Business Objects Enterprise.

Contact your system administrator to verify that the above steps have occurred.

How To Copy A Report Definition From The Demonstration Database

In order to use one of the sample reports in your product, you must define the metadata for each report.  The demonstration database contains the report definition and all its related data for each sample report.  The topics in this section describe how to copy any / all of the report definitions from the demonstration database to your implementation’s database.

Contents

If You Work In A Non-English Language

One Time Only - Set Up A DB Process To Copy Reports

Run The Copy Reports DB Process

Securing Your Reports

If You Work In A Non-English Language

The demonstration database is installed in English only.  If you work in a non-English language, you must execute the NEWLANG background process on the demonstration database before using it as a Compare Source supporting environment.  If you work in a supported language, you should apply the language package to the demonstration database as well.

If you don’t execute NEWLANG on the demonstration database, any objects copied from the demonstration database will not have language rows for the language in which you work and therefore you won’t be able to see the information in the target environment.

One Time Only - Set Up A DB Process To Copy Reports

You need a “copy reports” database process (DB process) setup in the target database (i.e., your implementation’s database).  This DB process must have the following instructions:

·         A primary instruction for the report maintenance object (MO)

·         A child instruction for each MO referenced as a foreign key on a report (i.e., validation algorithm, characteristics used for parameters and any algorithms used by the characteristics)

The demonstration database contains a DB process that performs these steps (it’s called CI_COPRP).  In order to copy reports from the demonstration database, you must first copy this DB process.

You can copy the CI_COPRPDB process from the demonstration database by submitting the CL-COPDB background process in your target database.  When you submit this process, you must supply it with an environment reference that points to the demonstration database.  If you don’t have an environment reference setup in your target database that references the demonstration database, you must have your technical staff execute a registration script that sets up this environment reference.  Refer to Registering ConfigLab Environments for more information about this installation script.

CL-COPDB is initially delivered ready to copy every DB process that is prefixed with CI_ from the source database (there are numerous sample DB processes in the demonstration database and this process copies them all).  If you only want to copy the CI_COPRP DB process, add a table rule to the primary instruction of the CL-COPDB database process to only copy the CI_COPRP DB process.  The remainder of this section assumes you have added this table rule.

When the CL-COPDB process runs, it highlights differences between the “copy reports” DB process in your source database and the target database.  The first time you run this process, it creates a root object in the target database to indicate the CI_COPRP DB process will be added to your target database.  You can use the Difference Query to review these root objects and approve or reject them. 

After you’ve approved the root object(s), submit the CL-APPCH batch process to change your target database.  You must supply the CL-APPCH process with two parameters:

·         The DB Process used to create the root objects (CL-COPDB)

·         The environment reference that identifies the source database (i.e., the demonstration database)

Run The Copy Reports DB Process

After you have a “copy reports” DB process in the target database, you should add a table rule to its primary instruction to define which report(s) to copy from the demonstration database.  For example, if you want to copy a single report called CI_MTREAD, you’d have a table rule that looks as follows:

·         Table: CI_MD_RPT

·         Override Condition: #CI_MD_RPT.REPORT_CD='CI_MTREAD'

If you do not introduce this table rule to the primary instruction of the DB process, ALL reports in the demonstration database will be copied to the target database (and this may be exactly what you want to do).

At this point, you’re ready to submit the background process identified on your “copy reports” DB process.  This background process highlights the differences between the reports in the demonstration database and the target database (the target database is the environment in which you submit the background process).

When you submit the CI_COPRP background process, you must supply it with an environment reference that points to the source database (i.e., the demonstration database). 

When the CI_COPRP process runs, it simply highlights differences between the reports in your source database and the target database.  It creates a root object in the target database for every report that is not the same in the two environments (actually, it only concerns itself with reports that match the criteria on the table rule described above).  You can use the Difference Query to review these root objects and approve or reject them. 

After you’ve approved the root object(s) associated with the report(s) that you want copied, submit the CL-APPCH batch process to cause your target database to be changed.  You must supply the CL-APPCH process with two parameters:

·         The DB process of the “copy reports” DB process (i.e., CI_COPRP)

·         The environment reference that identifies the source database (i.e., the demonstration database)

Securing Your Reports

In order for a user to submit a report using the online report submission or to view report history, the user must have access to the report through the application security.  Reports that you have copied from the demonstration database reference an application service (whose name matches the report name).  If you plan to use one of the reports in the demonstration database with no changes, you must configure your system to enable access to this application service for the appropriate user groups.  The access mode must be defined as Submit/View Report.

Subreports Used with Crystal Reports

The sample reports supplied with the system use several common subreports.  Subreports are used in Crystal Reports to retrieve common data such as, labels and your company title.  They are shared for all reports and may be reused for customer reports.  Implementers may also use these subreports when designing new reports. 

Contents

Display Company Logo and Title

Format Report Information

Labels

Display Company Logo and Title

The subreport CIZCOMP receives the user id as a parameter and calls the stored procedure CIZCOMP.  It retrieves the company’s title in the user’s language from the appropriate installation message record. 

Format Report Information

The subreport CIZINST defines shared variables that are used for formatting fields in the main report.  It calls the stored procedure CIZINST.  This subreport receives the user id and report code as parameters.  It retrieves the font and font size from the report definition.  It retrieves the format date/time and number format from the user’s display profile.  Finally, it retrieves the currency from the installation record and retrieves the currency symbol and position from the currency’s record.

Labels

The subreport CIZLABEL keeps all labels used in the main report.  It calls the stored procedure CIZLBALL with the user ID as a parameter.  This stored procedure returns all labels defined for all reports.  The subreport selects labels specified for the current report and sets shared variables L001...L100 to store the labels.  If more than 100 labels are required for a new report, the version of the CIZLABEL subreport used for the new report should be changed to add additional shared variables.

Contents

Use a Sample Report as a Starting Point

Publishing Reports in BI Publisher

Publishing Reports in Business Objects Enterprise

Designing Your Report Definition

Use a Sample Report as a Starting Point

·         Make a copy of the report and save it in an appropriate directory.  Prefix the new report name with CM.

·         Review the stored procedure(s) used for this report.  Refer to the installation guide for information about where the stored procedures should be defined.  If you want to change the data that is being accessed, copy the stored procedure, prefixing the new stored procedure with CM.  Make the appropriate changes in the new version of the stored procedure.  Contact your database administrator to find out the procedure for creating a new stored procedure. 

·         Review the parameters used by the report.  Make appropriate changes to the parameters required by the report.  This affects how you define your report.  Refer to Designing Parameters for more information.

·         Determine whether or not you require cross validation for your report parameters.  If any cross validation is necessary, you should design an appropriate validation algorithm to be executed when requesting a report in your product.   Refer to Designing Validation Algorithms for more information.

·         Review the labels used by the report.  Labels and other verbiage are implemented in the sample reports using a reference to the field table in the system.  This enables the report to be rendered in the appropriate language for the user.  For any new report label you require, you must define a new field entry.  Refer to Designing Labels for more information.

·         Review the layout of the report and make any desired changes based on your business needs.

When you have finished designing and coding your new report in your reporting tool, you must do the following in order for it to be usable:

·         Publish the report in BI Publisher or Business Objects Enterprise.  Refer to the documentation for these products for details about publishing a report.  Refer to Publishing Reports in BI Publisher and Publishing Reports in Business Objects Enterprise for configuration information specific to publishing a report for integration with your product.

·         Define the report.  Refer to Designing Your Report Definition for more information.

Publishing Reports in BI Publisher

Please refer to the documentation for BI Publisher for more information about publishing a report in this system.  The remaining topics in this section provide information about settings needed to ensure that the report is accessible using BI Publisher.

Contents

BI Publisher Database Access

Verify BI Publisher User Access Rights

BI Publisher Database Access

When publishing a report in BI Publisher, you are asked for database logon information.  The logon user name and password must be the user name and password that has access to the database functions related to this report in your database.

Verify BI Publisher User Access Rights

To verify the user's access rights to folders in BI Publisher:

·         Open the BI Publisher Enterprise Security Center.

·         Check that the role for the user has access to the appropriate report folders. 

For more information, refer to the "Understanding Users and Roles" section in the Oracle Business Intelligence Publisher User's Guide. 

Publishing Reports in Business Objects Enterprise

Please refer to the documentation for Business Objects Enterprise for more information about publishing a report in this system.  The remaining topics in this section provide information about settings needed to ensure that the report is accessible using Business Objects Enterprise.

Contents

Business Objects Enterprise Database Access

Verify Parameter Definition

Verify Business Objects Enterprise User Access Rights

Business Objects Enterprise Database Access

When publishing a report in Business Objects Enterprise, you are asked for database logon information.  The logon user name and password must be the user name and password that has access to the stored procedures related to this report in your database.

Verify Parameter Definition

This section describes how to verify parameter definitions in the Crystal Management Console (CMC).

·         Once your report has been published, navigate to the CMC.  This is the web-based administration component for Business Objects Enterprise and provides access to all administrative functions.

·         To verify/change the settings of a report in the CMC go to the Objects management area and select the desired report by clicking its link located in the Object Title column.

·         Once you have selected your report, click the Parameters tab to change the settings.

·         If your report requires parameters to be provided by the user, you must configure the parameter settings in the CMC to ensure that parameter values are passed from the system when submitting the report via the Report Submission page.  If you plan to submit reports from within your product, the Prompt the user for new value(s) when viewing check box should be checked.

·         Click OK on this window and then click Update.

Verify Business Objects Enterprise User Access Rights

To verify the access rights for a user in CMC:

• Navigate to the Rights tab in the Objects management area of the CMC and check that the user has correct security level for the report.
• Integration with your product requires an access level of View On Demand for the user.

Designing Your Report Definition

When adding a new report, you must define it in the system to allow users to request ad-hoc reports from on-line and to take advantage of the multi-language provisions in the system.  The following topics illustrate the steps to take to correctly configure your report definition.

Contents

Designing Main Report Definition Values

Designing Characteristic Types

Designing Parameters

Designing Validation Algorithms

Designing Application Services

Designing Labels

Designing Main Report Definition Values

Refer to field description section of the report definition main page for information about defining general information about the report.

For the validation algorithm, preliminary steps are required.  Refer to Designing Validation Algorithms for more information.

For the application service, preliminary steps are required.  Refer to Designing Application Services for more information.

Designing Characteristic Types

The parameter tab on the report definition page uses characteristic types to define the report parameters.  For each report parameter that you plan to use, you must define a characteristic type. 

You do not need a unique characteristic type for each report parameter.  For example, if Start Date and End Date are parameters your report, only one Report Date characteristic type needs to be defined.  This characteristic type would be used on both date parameters.

Each characteristic type to be used as a report parameter must indicate a characteristic entity of Report.

To illustrate the characteristic type definitions, let’s look at the sample report Tax Payables Analysis.  It needs the following parameters: From Date, To Date, GL Account Type Characteristic Type and Account Type value.

To support the required parameters, the following characteristic types are needed.

Char Type	Description	Type	Valid Values	Char Entities
CI_DATE	Date Parameter	Ad-hoc	(Uses validation algorithm to validate proper date entry)	Report
CI_CHTYP	Characteristic Type	FK Reference	CHAR_TYP	Report
CI_GLTY	GL Account Type	Pre-defined	A- Asset, E- Expense, LM- Liability/miscellaneous, LT- Liability/taxes, R-Revenue	Distribution Code, Report

Highlights for some of the above settings:

·         We have defined a characteristic type for defining a characteristic type.  This is to allow the user to indicate which Char Type on the Distribution Code is used for the GL account type.  This is an FK reference type of characteristic. 

·         The GL account type characteristic type is referenced on both the Distribution Code entity and the report entity.

Designing Parameters

Your report definition parameters collection must define a unique parameter entry for each parameter sent to the reporting tool.  The sequence of your parameters must match the sequence defined in your reporting tool.

Continuing with the Tax Payables Analysis report as an example, let’s look at the parameter definitions.

Parameter Code	Description	Char Type	Default Value
P_FROM_DT	From Date	CI_DATE	N/a
P_TO_DT	To Date	CI_DATE	N/a
P_CHAR_TYPE	Account Type Characteristic	CI_CHTYP	CI_GLTY
P_TAX_ACCTY_CHAR	Account Type Char Value for Tax Related GL Account	CI_GLTY	LT-Liability/taxes

Highlights for some of the above settings:

·         The from date and to date parameters use the same characteristic type.

·         The characteristic type parameter is defined with a default value pointing to the GL account type characteristic type.

·         The GL account type parameter defines the liability/taxes account type as its default value.

Designing Validation Algorithms

When designing your report definition, determine if cross validation should occur for your collection of parameters.  In the Tax Payables Analysis report, there are two date parameters.  Each date parameter uses the characteristic type validation algorithm to ensure that a valid date is entered.  However, perhaps additional validation is needed to ensure that the start date is prior to the end date.  To do this, a validation algorithm must be designed and defined on the report definition.

The system provides a sample algorithm RPTV-DT that validates that two separate date parameters do not overlap.  This algorithm should be used by the Tax Payables Analysis report.

If you identify additional validation algorithm, create a new algorithm type.  Create an algorithm for that algorithm type with the appropriate parameter values.  Plug in the new validation algorithm to the appropriate report definition.

Designing Application Services

Application services are required in order to allow a user to submit a report on-line or to view history for a report.  Define an application service for each report and define the user groups that should have submit/view access to this report. 

Update report definition to reference this application service.

Designing Labels

The system supports the rendering of a report in the language of the user.  In order to support a report in multiple languages, the verbiage used in the report must be defined in a table that supports multiple languages.  Some examples of verbiage in a report include the title, the labels and column headings and text such as “End of Report”. 

The system uses the field table to define its labels. 

For each label or other type of verbiage used by your report, define a field to store the text used for the verbiage.

·         Navigate to the field table using Admin Menu, Field.

·         Enter a unique Field Name.  This must correspond to the field name used in your report definition in the reporting tool and it must be prefixed with CM.

·         Define the Owner as Customer Modification.

·         Define the Data Type as Character.

·         Precision is a required field, but is not applicable for your report fields.  Enter any value here.

·         Use the Description to define the text that should appear on the report.

·         Check the Work Field switch.  This indicates to the system that the field does not represent a field in the database.

Update the report definition to define the fields applicable for this report in the Labels tab.

If your installation supports multiple languages, you must define the description applicable for each supported language.