Reporting Administration & Setup

This page is the recommended administrator path for setting up reporting in Pinkapple from a clean or recently reset tenant.

Navigation: Reporting -> Setup

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
Report Catalog	Reporting -> Setup -> Report Catalog	Maintain report groups, report definitions, parameters, access assignments, and drilldowns.
Financial Statements	Reporting -> Setup -> Financial Statements	Maintain statement templates, lines, mappings, columns, notes, and manual amounts.
Report Builder	Reporting -> Setup -> Report Builder where enabled	Maintain controlled self-service reporting assets.
Run Reports	Reporting -> Reports -> Run Reports	Validate and run published report definitions.
Schedules And Snapshots	Reporting -> Reports or Reporting setup areas where available	Preserve report outputs and automate trusted report runs.

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 report data sources
• 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. Approved Data Sources
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: Approved Data Sources

Open Reporting -> Setup -> System Settings where available and review the approved data-source area.

This is the first checkpoint because it controls which governed data sources are available to report definitions.

Use it to confirm:

• the source is active
• the source is approved for reporting use
• the source is intentionally available to report-definition lookups
• the source has a clear business purpose

If a source is missing or not approved, do not work around it by choosing a similar-looking source. Ask a system owner to review the source first.

Step 2: Report Groups

Open Reporting -> Setup -> 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 Reporting -> Setup -> Report Catalog -> Report Definitions.

Each runnable report must have a definition.

The minimum definition should correctly specify:

• report code
• report name
• report group
• approved data source
• report type
• output mode
• active status

Output mode rules

Use:

• ROWSET for table-style reports
• Structured report output for statements, dashboards, KPI-heavy outputs, or composite report layouts

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 Reporting -> Setup -> 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 Reporting -> Setup -> 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 Reporting -> Setup -> 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:

• Reporting -> Setup -> Financial Statements -> Column Definitions
• Reporting -> Setup -> 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:

• Reporting -> Setup -> Financial Statements -> Notes
• Reporting -> Setup -> 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 Reporting -> Setup -> Report Builder only when the need is suited to controlled self-service reporting.

Safe Sources

Register only approved:

• business data sources
• curated lists
• governed analytical sources

Treat safe sources as a whitelist. Users should not have to understand the underlying build details to use the builder safely.

Builder Definitions

Use builder definitions for:

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

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

Step 11: System Settings

Open Reporting -> Setup -> System Settings where available.

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
• Approved Data Sources
  • govern which sources 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 data sources
• output modes match actual report 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

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