Reporting Overview

PinkApple reporting is designed as a governed reporting platform, not just a screen for running SQL-backed lists.

The module combines:

• administration and configuration
• day-to-day operational report usage
• financial statement design
• automation through presets, snapshots, and schedules

This section of the guide is written to support both implementation teams and business users.

Two Working Surfaces

PinkApple reporting is split into two connected areas:

Area	Navigation	Main purpose
Reporting Administration	Administration -> Reporting	Define report groups, report definitions, financial statements, builder assets, and reporting governance
Reporting Operations	Reporting -> Reports	Run reports, review output, drill down, export, save snapshots, reuse presets, and manage schedules

Administration defines what can be run. Operations is where users consume those configured reports.

What The Reporting Module Covers

In Administration

Workspace	What it controls
Report Catalog	Groups, definitions, dataset procedures, report types, output modes, and visibility
Financial Statements	Templates, line items, account mappings, column definitions, column sets, notes, and manual amounts
Report Builder	Safe sources and controlled self-service report definitions
System Settings	Procedure registry, schedules, elimination rules, catalog seeding, and snapshot cleanup

In Operations

Workspace	What users do
Run Reports	Select groups and reports, enter parameters, generate output, drill down, and export
Snapshots & Presets	Reuse parameter sets and reopen saved point-in-time outputs
Schedules	Review and maintain recurring report runs

End-To-End Lifecycle

Use this lifecycle when building reporting from scratch or after a cleanup:

1. Register or verify the reporting procedures.
2. Create stable report groups.
3. Create report definitions with the correct output mode.
4. Build financial statement configuration where needed.
5. Add builder definitions only for suitable ad-hoc use cases.
6. Assign roles and business-unit visibility.
7. Validate everything in Reporting -> Reports -> Run Reports.
8. Add presets, snapshots, and schedules after runtime validation.

Design Principle

PinkApple reporting is catalog-driven.

That means a report is defined by metadata and a dataset procedure rather than by a custom frontend page.

The base pattern is:

Report Group
  -> Report Definition
     -> Dataset Procedure
        -> Output Contract
           -> Report Viewer / Export / Drilldown

For financial statements, the design extends into a statement engine:

FS Template
  -> FS Lines
     -> Account Mappings
     -> Column Definitions / Column Sets
     -> Notes / Manual Amounts
  -> Financial Statement Report Definition
  -> Runtime Generation

This gives you:

• one place to govern report availability
• one runtime workspace for users
• reusable rendering across lists, statements, and structured JSON reports
• controlled automation through snapshots and schedules

Recommended Reading Order

If you want the full end-to-end flow, read the reporting section in this order:

1. Implementation Model
2. Implementation Runbook
3. Administration & Setup
4. Creating Reports In The UI
5. Report Catalog
6. Financial Statements
7. Report Builder
8. System Settings
9. Operations & Usage
10. Running Reports
11. Snapshots, Presets & Schedules