Reporting Overview

Pinkapple reporting is designed as a governed reporting platform, not just a screen for running 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 for administrators, finance leads, and business users who configure, run, and review reports.

Two Working Surfaces

Pinkapple reporting is split into two connected areas:

Area	Open From	Main Purpose
Reporting Setup	Reporting -> Setup	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.

Reporting Is The Shared Runtime For Service Reports

Service modules may seed report definitions, cards, and entry actions, but the runtime owner remains Reporting.

That means:

• Agriculture, Projects & WBS, POS, Billing, Loans, and other modules can point users into Reporting.
• Reports should run in the shared viewer instead of each module building a second report runtime.
• Drilldowns, exports, snapshots, and schedules should stay consistent across service domains.

Workspace Reference

Workspace	Open From	Main Action	Main Record
Report Catalog	Reporting -> Setup -> Report Catalog	Create or maintain report groups and report definitions	Governed report available to users.
Financial Statements	Reporting -> Setup -> Financial Statements	Create or maintain statement setup	Template, line, mapping, column, note, or manual amount used by structured financial statements.
Report Builder	Reporting -> Setup -> Report Builder	Create or maintain controlled report definition	Governed self-service report asset where enabled.
System Settings	Reporting -> Setup -> System Settings	Maintain reporting governance	Approved sources, cleanup, schedule behavior, and administration settings.
Run Reports	Reporting -> Reports -> Run Reports	Generate report	Runtime report output.
Snapshots & Presets	Reporting -> Reports -> Snapshots & Presets	Save, reuse, or reopen report context	Parameter preset or point-in-time report output.
Schedules	Reporting -> Reports -> Schedules	Create or review schedule	Automated recurring report run.

What The Reporting Module Covers

In Administration

Workspace	What it controls
Report Catalog	Groups, definitions, approved data sources, 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	Approved data sources, 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 approved report data sources.
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.

Shared Example: Project-Funded Agriculture Flow

One end-to-end example is:

1. Projects & WBS records funding source, fund receipt, and approved obligation.
2. Payments executes the payout batch from that obligation.
3. GL posts the financial result.
4. Reporting runs the shared fund-position, fund-utilization, or cross-funding exposure reports.
5. Users inspect drilldowns without leaving the report viewer unexpectedly.

Design Principle

Pinkapple reporting is catalog-driven.

That means a report is defined by controlled setup rather than by a custom screen for each report.

The base pattern is:

Report Group
     -> Report Definition
     -> Approved Data Source
     -> Rendering Style
     -> 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 report outputs
• 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. Administration & Setup
2. Creating Reports In The UI
3. Report Catalog
4. Financial Statements
5. Report Builder
6. System Settings
7. Operations & Usage
8. Running Reports
9. Snapshots, Presets & Schedules