Reporting Administration & Setup

This page is the recommended implementation path for building reporting in PinkApple from a clean or recently reset tenant.

Navigation: Administration -> Reporting

Foundations To Confirm First

Do not start reporting setup before the wider platform basics are stable.

Confirm these already exist:

• business units and business-unit hierarchy
• user roles and permission model
• chart of accounts and sub-ledgers
• fiscal dates and reporting periods
• approved backend procedures for reporting
• a clear decision on which reports are catalog reports, financial statements, or builder reports

Recommended Implementation Sequence

Build the reporting domain in this order:

1. Procedure Registry
2. Report Groups
3. Report Definitions
4. Financial Statement Templates and Lines
5. Financial Statement Mappings and Columns
6. Builder assets where required
7. Access assignments
8. Runtime validation
9. Presets, snapshots, and schedules

This order matters because later steps depend on earlier governance being correct.

Step 1: Procedure Registry

Open Administration -> Reporting -> System Settings -> Procedure Registry.

This is the first checkpoint for reporting implementation because it controls which procedures are available to the catalog.

Use it to confirm:

• the procedure exists in the backend
• the procedure is active and approved for reporting use
• the procedure is intentionally exposed to report-definition lookups

If a procedure is missing here, report-definition setup will be inconsistent even if the SQL exists.

Step 2: Report Groups

Open Administration -> Reporting -> Report Catalog -> Report Groups.

Groups are the top-level categories users browse in Reporting -> Reports -> Run Reports.

Typical groups include:

• ACCOUNTING
• FINANCIAL_STATEMENTS
• MANAGEMENT
• LOANS
• DEPOSITS
• OPERATIONS

For each group define:

• group code
• group name
• description
• sort order
• active

Keep groups broad and stable. Groups are long-lived navigation assets, not short-term project folders.

Step 3: Report Definitions

Open Administration -> Reporting -> Report Catalog -> Report Definitions.

Each runnable report must have a definition.

The minimum definition should correctly specify:

• report code
• report name
• report group
• dataset procedure
• report type
• output mode
• active status

Output mode rules

Use:

• ROWSET for table-style reports
• REPORT_JSON for statements, dashboards, KPI-heavy outputs, or composite payloads

Wrong output mode is one of the fastest ways to create frontend rendering problems.

Financial-statement report definitions

For FINANCIAL_STATEMENT reports, the definition must also carry:

• FS template
• column set where the statement layout depends on one

Without that linkage, the statement may exist in setup but still not run properly in operations.

Step 4: Access Assignments

Still within report definitions, configure who should see the report.

Use assignments to bind:

• business units
• roles

Apply assignments when reports should be limited by branch, department, or user role. If you leave a report broadly visible, do it intentionally.

Step 5: Financial Statement Templates

Open Administration -> Reporting -> Financial Statements -> Templates.

Templates define the statement family and top-level identity.

Typical templates are:

• balance sheet
• income statement
• cash flow statement
• statement of changes in equity

Use business-readable codes and names. Templates should remain stable across reporting periods.

Step 6: Financial Statement Lines

Open Administration -> Reporting -> Financial Statements -> Line Items.

Create the statement structure in the exact order users should read it.

Common line types include:

• section headers
• detail rows
• subtotals
• totals
• derived or formula-driven rows

Good line design is the backbone of a maintainable statement. Do not rush it.

Step 7: Account Mappings

Open Administration -> Reporting -> Financial Statements -> Account Mappings.

This is where the financial statement starts to become real.

Map the correct GL accounts to the correct lines and validate:

• account category
• reporting intent
• whether the balance should represent movement or position
• whether the line should aggregate multiple accounts
• whether the mapping remains valid across business units

Bad mappings are the most common reason a statement is structurally correct but financially wrong.

Step 8: Column Definitions And Column Sets

Open:

• Administration -> Reporting -> Financial Statements -> Column Definitions
• Administration -> Reporting -> Financial Statements -> Column Sets

Use column definitions for reusable statement columns such as:

• current period
• prior period
• year to date
• budget
• variance
• variance percentage

Use column sets to bundle those columns into runtime-ready layouts such as:

• current period only
• current vs prior
• current vs budget
• comparative three-column layout

Step 9: Notes And Manual Amounts

Open:

• Administration -> Reporting -> Financial Statements -> Notes
• Administration -> Reporting -> Financial Statements -> Manual Amounts

Use notes for narrative or disclosure content tied to the statement.

Use manual amounts only where the statement design explicitly requires controlled values that are not purely derived from standard mappings.

Manual amounts should be carefully governed and reviewed during period-end reporting.

Step 10: Report Builder

Open Administration -> Reporting -> Report Builder only when the need is suited to controlled self-service reporting.

Safe Sources

Register only approved:

• views
• tables
• procedures

Treat safe sources as a whitelist, not an open SQL workspace.

Builder Definitions

Use builder definitions for:

• evolving operational lists
• exploratory but governed analysis
• tabular reporting that does not justify a dedicated stored procedure yet

Do not use the builder for statutory statements or board-critical curated outputs.

Step 11: System Settings

Open Administration -> Reporting -> System Settings.

Use this area for cross-cutting controls:

• System Admin
  • seed system catalog
  • cleanup expired snapshots
• Schedules
  • create recurring report runs
• Elimination Rules
  • support consolidated reporting scenarios
• Procedure Registry
  • govern which procedures are available to the reporting catalog

Step 12: Runtime Validation

After setup, move to Reporting -> Reports -> Run Reports.

Validate every important report by checking:

• it appears in the right group
• it is visible to the right users
• the parameter form is correct
• the report renders correctly
• totals reconcile
• drilldowns work where expected
• exports match the on-screen output

No report should be considered complete until it has passed runtime validation.

Step 13: Operationalize

Only after successful runtime validation should you:

• save presets
• capture important snapshots
• activate schedules

This avoids automating bad definitions or preserving the wrong output.

Go-Live Checklist

Before handing reporting to end users, confirm all of the following:

• report groups are clean, ordered, and understandable
• report definitions point only to approved procedures
• output modes match actual procedure output
• financial statement templates reconcile to mappings
• column sets exist for all required FS layouts
• visibility rules are correct
• runtime execution succeeds
• exports are accurate
• drilldowns are validated
• recurring reports have appropriate presets and schedules

Related Pages

• Implementation Model
• Creating Reports In The UI
• Report Catalog
• Financial Statements
• Report Builder
• System Settings
• Operations & Usage