|JD Edwards EnterpriseOne Tools Development Tools: Report Design Aid Guide
Release 8.98 Update 4
Part Number E14708-02
|PDF · Mobi · ePub|
This chapter contains the following topics:
Oracle's JD Edwards EnterpriseOne provides fully integrated applications for managing information across an enterprise. This information includes employee data, accounts receivable and payable information, financial data, and product information. JD Edwards EnterpriseOne enables you to view and evaluate this information to make critical decisions to improve the business operation and profitability. You can also distribute this data to others with whom you do business, such as shareholders, employees, and business consultants.
JD Edwards EnterpriseOne provides reports across these systems to meet many business needs:
Oracle's JD Edwards EnterpriseOne Financial Management
Oracle's JD Edwards EnterpriseOne Human Capital Management
Oracle's JD Edwards EnterpriseOne Logistics
Oracle's JD Edwards EnterpriseOne Manufacturing
You can easily process these reports to be viewed online and in PDF, as well as export them to a spreadsheet program. However, to help you meet all of your business needs, you can create custom reports using Oracle's JD Edwards EnterpriseOne Report Design Aid (RDA). Using this reporting tool, you can extract and present information that is vital to the business.
Reports that are used primarily to manipulate data are referred to as batch processes. Reporting and batch processing can be combined in a single report. Reports and batch processes are considered by the system as batch applications.
The Oracle's JD Edwards EnterpriseOne reporting solution includes a report design tool to create reports and batch processes, a batch engine for processing, and an output management system to output information.
You can use RDA to create a variety of simple and complex reports as well as batch processes. The interface is simple enough to use without programming expertise, yet powerful enough to create the most complex batch applications.
RDA includes a Report Director (also referred to as the Director) to guide you through the process of creating report templates. This Director presents multiple reporting options from which to choose. You can create custom Directors to aid in the creation of report templates. These Directors are configured to use report components that meet a specific reporting requirement.
After using the Director to create the initial report template, you can enhance the report by:
Further organizing the data.
The design workspace in RDA can be configured to compliment individual work preferences. You can:
Modify the report view options.
Select which toolbars and windows appear in the workspace.
You can use RDA with terminal server. Just like in a traditional client server configuration, a report template that is checked out using terminal server cannot be accessed by other users.
You cannot process a report without a batch version. You submit the batch version for processing and can choose to process the batch version either locally or on the server. Typically, servers are faster, so processing on a server is more efficient. Once you submit a batch version, it runs without any further interaction from you. You do not interact with the report again until processing is complete.
Once you have submitted a batch version for processing, you have no control over the flow of the logic. You must make changes to the flow of logic in RDA and resubmit the batch version.
This section discusses:
Introduction to reports
A report exists as a set of specifications that are read by the Oracle's JD Edwards EnterpriseOne batch engine for processing. You can create variations of a single report using batch versions. The first step in creating a report is to create a batch application object within JD Edwards EnterpriseOne. You can accomplish this from Oracle's JD Edwards EnterpriseOne Object Management Workbench (OMW) or by accessing RDA directly from Oracle's JD Edwards EnterpriseOne Solution Explorer. You then begin designing the report using RDA. The report is actually a template from which multiple versions can be created.
Each report is comprised of sections. These sections are the building blocks of all reports. Within the template, you can add, hide, remove, and rearrange sections as needed.
Each report section is comprised of report objects. You can add, modify, revise, rearrange and delete report objects within a section.
JD Edwards EnterpriseOne is object-based. Each report template is considered a batch application with an object type of Universal Batch Engine (UBE). When you add a report object, the system creates a header record in the Object Librarian Master Table (F9860). This header record contains information about the report, such as its name and description.
Each report section is comprised of report objects. You can add different types of report objects to report sections. Not all objects are available for all section types. You can modify the properties of report objects such as:
Font style and color
Lines and boxes
Report sections are the basic components of a report. Most reports include more than one section. You can use some sections for special purposes, such as performing calculations and totaling. Section types include:
A report header section appears once at the beginning of the report. A report footer section appears once at the end of the report on its own page. You typically populate these sections using constants and variables. You can define only one of each of these sections per report.
A page header section appears at the beginning of each page of the report. A page footer section appears at the bottom of each page of the report. You typically populate these sections using constants and variables. You can only define one of each of these sections per report.
From the Report Director in RDA, there is a fourth option for creating application reports. This option actually uses one of the three types of detail sections already mentioned—columnar, group, or tabular. The section layout of a detail section is typically populated using fields from a business view. Business views are used to access data from one or more database tables. Business views present a subset of data relevant to the immediate business requirement. Business views provide a link between the data in the database and the report that you are creating.
In addition to the business view fields that you select, you can define and add data fields to the detail report section, such as data dictionary fields, constants, and variables.
Define level break fields for use in level break header sections. Level break header sections are used to further organize data.
Define level break fields for use in level break footer sections. Level break footer sections are used to calculate and display totals.
A level break occurs during the processing of a report when the value of a data sequencing field, which is also defined as a level break field, changes. A set of records that contains the same value for this defined field is in the same level. For example, in an address book report that is sequenced by search type, where the search type field is also defined as a level break field, all of the records having the same search type are in the same level. (All records with a search type of E for employees are in the same level.) When the value of the search type field changes, a level break occurs. (When the search type value changes from E for employees to C for customers, a level break occurs.) Level breaks are used to group large amounts of data into more manageable units. Level break headers provide a descriptive heading prior to the associated data. Level break footers are used to include aggregates with descriptive labels in the report.
Detail sections present the data required by the business need. This data is fetched from the JD Edwards EnterpriseOne database using a business view.
Attach a business view.
Sequence data using business view fields.
Define level breaks using data sequencing fields.
Filter data based on designated criteria.
You can include multiple detail sections in a report template. The guideline for the size of a report template is not the number of sections but rather the physical size. A report design should not exceed a physical page size of 45 inches in length and width. The RDA interface includes rulers to help you keep the report template within these parameters. Report templates that exceed this 45-inch parameter guideline might encounter problems at runtime.
The columnar section format consists of column headings with rows of data under the headings. Each row is considered a record.
Each field that you add to a columnar section, includes a column heading and a column variable. The column heading describes the data. The column variable is the data that varies by record.
Due to the format of the columnar section, the column headings cannot be disconnected from their associated variables. If either the column heading or column variable is deleted, the other is also deleted.
You can include multiple columnar sections in a report.
You can include level break headers and level break footers in columnar section reports. The level break header appears above the column headings in columnar section reports. The level break footer displays totals and other aggregates and appears after the columnar section.
Use columnar sections when you want to display rows of data with column headings. This format is beneficial when reviewing a large number of records with specific fields of interest. For example, you want to review the salary of all the employees in the company.
You can join columnar sections to other columnar sections or to group sections. You can attach a different business view to each section. You must join the sections on common fields.
You can define columnar sections as conditional. Conditional sections are called from the report section preceding the conditional section. Conditional sections are called using event rules and process only when stated criteria is met.
Group sections enable you to arrange fields in a free-form layout; they are not restricted to a predefined format. The group section type is the most flexible because you can place fields anywhere in the section. Business view fields within group sections are composed of constants and variables. Initially, the constant and variable are linked; however, you can disconnect the constant from the variable to meet reporting requirements. Because of the free-form layout, group sections are ideal for creating level break footers and grand total sections.
You can include multiple group sections in a report.
Use group sections when a free-form layout is required to meet the reporting needs.
You can join group sections to other group sections or to columnar sections. You can attach a different business view to each section. You must join the sections on common fields.
You can define group sections as conditional. Conditional sections are called from the report section preceding the conditional section. Conditional sections are called using event rules and process only when stated criteria is met.
Tabular sections appear in the same column-and-row format as columnar sections. However, there are three major differences between columnar and tabular sections. Tabular sections offer:
Row description columns
Because of the additional functionality, tabular sections are desirable for presenting numeric data that needs to be summarized with subtotals and grand totals. Typically, financial reports use tabular sections. However, tabular sections are not exclusive to financial reporting.
Automatically calculate and display totals using level break fields.
Automatically calculate and display grand totals.
Define data selection at the column level.
Define data selection at the row level.
Define calculations at the cell level.
Define the drill-down feature.
The drill-down feature enables you to research values in the report by creating a link between the report output file and the associated JD Edwards EnterpriseOne application.
You can include multiple tabular sections in a report. Tabular sections processes data based on the fields you have defined as level break fields.
Tabular sections automatically include a Row Description column. This column displays descriptions for rows, based on data sequencing and level break fields. Row Description columns are typically the first columns in tabular sections.
Totaling is dynamic in tabular sections. If a column does not require totaling, you can override the totaling function. Because the totaling logic is built into tabular sections, level break footer sections are not required to provide totals. You can easily change the totaling without redesigning the report; simply change which fields you have defined as level breaks to display totals differently.
Tabular sections process differently than columnar and group sections. Therefore, there are features that are used in columnar and group section reports that are not available for tabular sections. In tabular sections you cannot:
Add level break headers.
The Row Description column provides this functionality.
Add level break footers.
Tabular sections include automatic totaling so level break footers are not needed.
Define tabular sections as conditional.
Join tabular sections to other sections.
Advantages of using tabular sections include:
Totaling can be suppressed on individual columns.
Changing which fields are defined as level break fields changes how totals are calculated.
Audit trails can be created using the drill-down feature.
Row Description columns
Multiple descriptions can appear in the Row Description column.
Use tabular sections when you want to display rows of data with column headings but also need to:
Perform row level processing, such as calculations.
Work with individual cell properties.
Include totaling that is flexible.
Define data selection at the column, row, or cell level.
Calculate grand totals.
Review detail at the application level using the drill-down feature.
The system allows you to define only one report header in a report template, which prints once at the beginning of the report. Report headers typically include:
Time period of the data being reported.
The system allows you to define only one page header in a report template, which prints once at the beginning of each page of the report. Page headers typically include:
Report object name
The system allows you to define only one page footer in a report template, which prints once at the end of each page of the report. You can use page footers to present an explanation of the contents of the report. Typically, you populate page footers using data fields such as:
The system allows you to define only one report footer in a report template, which prints once at the end of the report. You can use report footers to remind viewers that the contents of the report are for internal use only. Typically, you populate report footers using data fields such as:
Report templates are batch applications that you create in RDA. They are the master specifications of reports. These specifications describe the report to the batch engine; they define what data is used and how the data is selected, sorted, displayed, and formatted.
Because you can create multiple versions of report templates, you typically want to keep the report template generic. This means that you want to leave the data selection and data sequencing in the report template open and create batch versions with different data selection and data sequencing to meet specific business needs.
Properties defined in the report template are read by the associated batch versions. There are two exceptions to this rule:
Batch versions that contain specifications that have been overridden.
Specifications that are overridden in the batch version are not read from the report template.
Report level properties that have been modified after the report template is saved and RDA is exited.
Note:When you create batch versions from the Director, the system uses the current report level values. If you change the report level values prior to saving the report template and exiting RDA, the new values transfer to the version. However, if you save the report template and exit RDA, then reenter RDA and change the report level values, the modified report level values do not affect any existing versions. New batch versions that you create do reflect the modified report level values. Batch versions that you copy reflect the template specifications at the time the original version was created.
Batch versions read the master specifications from the associated report template. However, batch versions typically differ slightly from the report template. For each batch version you can easily define different:
Section data selection
Section event rules
Section database output
Section sort sequence
Batch versions enable you to preserve template integrity while providing custom processing to meet a specific business need. Instead of creating separate report templates for multiple variations of a report, you can create one report template and add multiple batch versions.
See JD Edwards EnterpriseOne Tools Development Tools: Batch Versions Guide.