Report Catalog

The Report Catalog is the controlled list of reports available in Pinkapple. It controls what reports exist, how they are grouped, which approved data source powers them, and who can run them.

Open Reporting -> Setup -> Report Catalog.

Workspace Reference

Area	What The User Does
Report Groups tab	Creates and orders the groups users see when running reports.
Report Definitions tab	Creates and maintains runnable report definitions.
New Report Group	Opens the group form.
New Report Definition	Opens the report definition form.
Edit	Updates a group or definition before users rely on it broadly.
Activate / Deactivate	Controls whether a group or report is available for use.
Assign visibility	Limits report access by role, business unit, or other configured scope where supported.

What The Catalog Contains

The catalog has two working tabs:

• Report Groups
• Report Definitions

Together, they control:

• how reports are presented to users
• which approved data source backs each report
• how the result is rendered
• whether the report is live or hidden
• which roles or business units can access it

Report Groups

Groups are the runtime categories shown in Reporting -> Reports -> Run Reports.

Good group design should be:

• business-readable
• broad rather than overly narrow
• stable over time
• ordered intentionally

Good examples:

• Accounting
• Financial Statements
• Loans
• Deposits
• Management
• Operations

Avoid creating groups based on:

• developer ownership
• temporary projects
• one-off reports
• internal build style

Important group fields:

Field	Required	Meaning
Group Code	Yes	Stable short reference for the report group.
Group Name	Yes	Business-facing group name shown to users.
Description	Recommended	Explains what kinds of reports belong in the group.
Display Order	Recommended	Controls how groups are ordered for users.
Active	Yes	Controls whether the group is available for runtime use.

Report Definitions

Each report definition is a governed, runnable reporting asset.

Core fields

Field	Required	Purpose
Report Code	Yes	Stable identifier used by presets, schedules, snapshots, support work, and integrations.
Report Name	Yes	Business-facing display name.
Report Group	Yes	The group where the report appears in runtime.
Approved Data Source	Yes	The governed source that generates the report.
Report Type	Yes	High-level business classification such as list, dashboard, or financial statement.
Output Mode	Yes	Presentation style the report viewer should use.
Description	Recommended	Runtime help text or business context for the report.
Active	Yes	Whether the report is visible for use.

Choosing Report Type

Use report type to communicate business intent, not just how the result is displayed.

Typical uses:

• LIST
  • operational row-based reports
• FINANCIAL_STATEMENT
  • balance sheet, income statement, cash flow, equity statements
• DASHBOARD or structured types
  • KPI or management summaries

Report type helps runtime presentation and governance, especially when combined with the correct output mode.

Choosing Output Mode

This decision must match the actual report output.

Use row/table output when

• the result is tabular
• the report should behave like a standard table
• exports should mirror a straightforward grid

Typical examples:

• account statements
• audit lists
• exception reports
• transaction histories

Use structured report output when

• the report includes KPIs, multiple tables, chart-ready sections, or statement-style output
• the report needs richer metadata or guided presentation

Typical examples:

• trial balance
• balance sheet
• dashboard-style summaries
• comparative financial statements

If output mode and result shape do not match, the report may appear in the UI but render incorrectly or export inconsistently.

Financial Statement Definitions

For financial statement report types, a report definition is incomplete until it is linked to the financial statement setup.

Set:

• FS template
• column set where applicable

This is what allows the runtime viewer to treat the report as a structured statement rather than as a plain table.

Access Assignments

Definitions can carry visibility rules through:

• business-unit assignments
• role assignments

Use them when:

• some reports should only be visible to specific branches
• some reports are only for finance or management roles
• some reports should stay hidden from operational users

Do not rely on accidental visibility. Decide whether a report is:

• globally visible by design
• role-limited
• business-unit-limited
• both role- and business-unit-limited

Recommended Definition Standards

Naming standard

• use readable report names
• keep codes short and stable
• align codes with business domains rather than temporary project names

Description standard

Every important report should explain:

• what it answers
• what scope it covers
• whether it is a statement, list, or management view

Activation standard

• keep unfinished definitions inactive
• activate only after successful runtime validation
• retire definitions cleanly when the underlying report source is no longer supported

Governance standard

• select data sources only from the approved lookup
• do not point definitions to experimental data sources
• review definitions after any material data-source change

Catalog Review Checklist

Before activating a report definition, confirm:

• report code is final
• report name is business-appropriate
• group is correct
• data source is approved
• report type is correct
• output mode matches actual output
• FS linkage exists where needed
• assignments are correct
• manual runtime testing has passed

Related Pages

• Administration & Setup
• Creating Reports In The UI
• Financial Statements
• Operations & Usage