Home > SI5 Documentation > User Guide > Reports > Designer > Report Components

Report Components

Key Components in a Report

There are many components of an SI5 report that determine how the report will function.


The main report itself is the topmost "level".  All components of a report are children of the main report.  Besides all of the components that a report can have, the report itself has it's own properties that can be set.  One key property is the "PrintWidth" of the report that determines the width of the designer canvas of the report.



The key section of any report built using the Active Reports engine is the “Detail” section. This section represents a single record in the data the report is iterating over.   This section should be considered the middle of the report. It is the only section that does not have a sibling section. This means that the detail section of a report stands alone. All other sections (Group, Page, or report sections) have both a header and a matching footer section. In the shot below, each section is color coded to show the sibling sections, notice no sibling for the "Detail" section:


Sections in a report:

Detail – This is the only section that is required for a report. As stated above, this section represents a single record in the reports data.

Report Header and Footer – The report header and footer sections will print once per report. The header will be the first section rendered for the report and the footer will be the last section.

Page Header and Footer – The page header and footer sections will print once per page. The page header will always be the very first section rendered to a page in the report and the page footer will be the very last section rendered at the bottom of the page in a report.

Group Header and Footer - The Group header and footer sections represent the most powerful sections in the report. Group sections allow users to aggregate data into subtotals, counts, etc. The number of instances of a given group section in a report is determined by the number of times the data that group is bound to changes.

Every Group Header in a report has a property called a “DataField”. This property is set to the field in the data set the report is iterating over. Every time the value changes in this field, a new instance of the group is created. 

In the case of SI, many times users will want to group their data in the report by location. This requires that the data in the report is iterating over be sorted by location. When the data is sorted by location, a new group will be created every time the location for the current record in the data set is different than the previous record in the data set.

Report Datasource – Every report has a defined Datasource. In the case of the SI5 reports, the Datasource is an XML document. The Datasource for a report can be modified by selecting the report in the “Report Explorer” and then clicking on the “Edit Data Source” link in the Properties window when the main report is selected or by clicking the Datasource icon located in the Detail section of the report designer canvas:

edit data source.jpg

If a user is creating a custom report based on an existing report, there is no need to modify the Datasource. By default, new custom reports NOT based on existing reports are set to iterate over the “Items” represented by the recordset pattern by default (XPath Expression): //dtr:Items/dtr:Item.


Following is a list of recordset patterns commonly used in DTools Reports:


  • //dtr:Items/dtr:Item – This pattern is used to iterate over each item in a project without regard to its existence in a package or its association as an accessory to another item. This is the “Engineering Bill of Materials”. All physical items in a project in a list.
  • //dtr:ProposalItems/dtr:ProposalItem – This pattern is used to iterate over each item in the “Sales Bill of Materials” and is the pattern used for the “Proposal” report and all of its variants. Top level items may represent Equipment items or Packages in a Project. Accessories to Equipment Items and the Items in a package are represented as child nodes to this node.
  • //dtr:PhaseItems/dtr:Item – This pattern is used to iterate over items that must always be sorted by phase. A number of sub report rely on this section to render correctly.
  • //dtr:Project – This pattern is used for reports that do not require the items to be iterated over. The Contract, Statement of Work and Cover Page reports are all examples of reports that do not iterate over items to render their data.


While these are the most common patterns used in the reports, any XML node can be used as the recordset pattern for a report. The “File URL” should not be modified when editing a Datasource in the Report Designer.
Last modified


This page has no custom tags.


This page has no classifications.