Reports in AL

What Is a Report in AL?

A report in AL is an object that reads data from one or more tables, processes that data in a defined sequence, and optionally produces an output such as a printed document, PDF, Excel file, or no output at all.

A report defines:

• Which data is read
• How records are iterated
• When logic is executed
• How output is generated (or suppressed)

A report does not:

• Store data
• Replace posting logic
• Act as a UI editing surface

Reports are read-oriented and execution-focused objects.

Why Reports Exist in Business Central

ERP systems must support:

• Business documents (invoices, orders, statements)
• Regulatory and financial reporting
• Periodic batch processing
• Data exports and analysis

Reports exist to handle these needs in a controlled, repeatable, and auditable way. They allow data to be processed consistently across large record sets, which is difficult to achieve through pages or codeunits alone.

Two Common Uses of Reports

Although reports can be flexible, they are commonly used in two ways.

First, reports are used as output documents, where data is formatted and presented to users or external parties.

Second, reports are used as processing engines, where data is read and logic is executed without producing visible output.

Both uses rely on the same report structure.

Basic Structure of a Report in AL

A report typically consists of:

• Report properties
• Dataset definition
• Optional request page
• Optional triggers
• Optional layout (RDLC or Word)

Each section serves a specific role and should be kept cleanly separated.

The following example shows a report that processes data without printing anything.

report 50130 "Customer Feedback Processor"
{
    ProcessingOnly = true;
    UsageCategory = Administration;
    ApplicationArea = All;

    dataset
    {
        dataitem(CustomerFeedback; "Customer Feedback")
        {
            trigger OnAfterGetRecord()
            begin
                // Processing logic per record
            end;
        }
    }
}
    

This report:

• Iterates through records
• Executes logic per record
• Produces no output
• Can be scheduled or run manually

Dataset and DataItems

The dataset defines which tables the report reads and in what hierarchy. Each dataitem represents a table and controls record traversal.

A dataitem:

• Reads records sequentially
• Can be filtered
• Can contain triggers for record-level logic

Multiple dataitems can be nested to represent header–line relationships.

dataset
{
    dataitem(Customer; Customer)
    {
        dataitem(CustomerFeedback; "Customer Feedback")
        {
            DataItemLink = "Customer No." = field("No.");
        }
    }
}
    

This structure:

• Iterates customers
• Then iterates related feedback records
• Mirrors relational data structure

Request Page (User Input)

Reports can include a request page that allows users to:

• Set filters
• Choose options
• Control execution behavior

requestpage
{
    layout
    {
        area(Content)
        {
            group(Options)
            {
                field(IncludeBlocked; IncludeBlocked)
                {
                    ApplicationArea = All;
                }
            }
        }
    }
}
    

The request page is optional and can be disabled for automation scenarios.

Report Properties (High-Level Understanding)

Report properties define how and when the report runs. Common properties include:

• ProcessingOnly
• UseRequestPage
• SaveValues
• DefaultLayout
• UsageCategory
• ApplicationArea

These properties should be used to control behavior before adding code.

Report Triggers (When Logic Runs)

Reports support triggers at different levels:

• Report-level triggers (e.g., OnPreReport)
• DataItem triggers (e.g., OnAfterGetRecord)
• Request page triggers

Triggers should be used for:

• Initialization
• Controlled processing
• Output preparation

They should not replace core business logic.

Reports and Batch Processing

Reports are commonly used for:

• Period-end routines
• Data corrections
• Recalculations
• Scheduled background jobs

Because reports process records sequentially, they are well-suited for controlled batch execution.

Layouts in Reports (High-Level Only)

When reports produce output, layouts define how data is rendered. Business Central supports:

• RDLC layouts
• Word layouts

Layout design is a specialized topic and is covered separately.

Common Beginner Mistakes With Reports

Developers often:

• Use reports to modify data incorrectly
• Put heavy business logic in report triggers
• Ignore filtering and performance
• Treat reports as UI objects

Reports should process data responsibly and predictably.

Summary

Reports in AL are data-processing and output objects used to read, process, and optionally present business data. They are a core part of Business Central’s reporting and batch execution model.

A well-designed report:

• Reads data efficiently
• Uses properties before code
• Separates processing from presentation
• Supports automation and auditing

Understanding reports prepares you for advanced topics such as Report Extensions and background job execution.