Appearance
Report Catalog
The Report Catalog is the reporting registry for PinkApple. It controls what reports exist, how they are grouped, what backend procedure powers them, and who can run them.
Navigation: Administration -> Reporting -> Report Catalog
What The Catalog Contains
The catalog has two working tabs:
- Report Groups
- Report Definitions
Together, they control:
- how reports are presented to users
- which dataset procedure 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 navigation 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
- technical implementation style
Report Definitions
Each report definition is a governed, runnable reporting asset.
Core fields
| Field | Purpose |
|---|---|
| Report Code | Stable identifier used by presets, schedules, snapshots, support work, and integrations |
| Report Name | Business-facing display name |
| Report Group | The group where the report appears in runtime |
| Dataset Procedure | The approved backend procedure that generates the report |
| Report Type | High-level business classification such as list, dashboard, or financial statement |
| Output Mode | The rendering contract expected by the frontend |
| Description | Runtime help text or business context for the report |
| Active | Whether the report is visible for use |
Choosing Report Type
Use report type to communicate business intent, not just technical output.
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 procedure behavior.
Use ROWSET when
- the procedure returns tabular rows
- 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 REPORT_JSON when
- the procedure returns structured report payloads
- 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 procedure 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 FS engine.
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 implementation 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 procedures are deprecated
Governance standard
- select procedures only from the approved procedure lookup
- do not point definitions to experimental procedures
- review definitions after any material procedure change
Catalog Review Checklist
Before activating a report definition, confirm:
- report code is final
- report name is business-appropriate
- group is correct
- dataset procedure is approved
- report type is correct
- output mode matches actual output
- FS linkage exists where needed
- assignments are correct
- manual runtime testing has passed