Creating Reports In The User Interface

This page is for reporting administrators who configure reports from Pinkapple screens. It explains the choices users make in the UI and the operational meaning of those choices.

Use this page when you want to:

• Add a report group.
• Create a runnable report definition.
• Build a financial statement report from templates, lines, mappings, and columns.
• Configure drilldowns from summary rows into supporting detail.
• Use presets, snapshots, and schedules safely.

Where Each Setup Task Lives

What you want to create	Screen
Report group	Reporting -> Setup -> Report Catalog -> Report Groups
Report definition	Reporting -> Setup -> Report Catalog -> Report Definitions
Financial statement template	Reporting -> Setup -> Financial Statements -> Templates
Statement lines	Reporting -> Setup -> Financial Statements -> Line Items
Account mappings	Reporting -> Setup -> Financial Statements -> Account Mappings
Column definitions	Reporting -> Setup -> Financial Statements -> Column Definitions
Column sets	Reporting -> Setup -> Financial Statements -> Column Sets
Notes	Reporting -> Setup -> Financial Statements -> Notes
Run and validate	Reporting > Reports

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
Report Catalog	Reporting -> Setup -> Report Catalog	Create groups, definitions, access rules, parameters, and drilldowns.
Financial Statements	Reporting -> Setup -> Financial Statements	Build statement templates, lines, mappings, columns, column sets, notes, and manual amounts.
Run Reports	Reporting -> Reports -> Run Reports	Validate report output before publishing or scheduling.
Snapshots, Presets, And Schedules	Reporting -> Reports or Reporting setup areas where available	Save repeatable filters, preserve point-in-time outputs, and automate report runs.

Before You Create A Report

Have these decisions ready first:

• What business question the report answers.
• Which report group users should browse to find it.
• Which approved data source or statement engine the report should use.
• Whether the output is a list, statement, KPI pack, dashboard, chart, pivot, or custom summary.
• Which business units and roles should see it.
• Which filters users should start with.
• Whether users need drilldowns into supporting detail.
• Whether the report needs shared presets or scheduled delivery.

For financial statements, also confirm:

• The statement template exists or will be created now.
• The line hierarchy is agreed.
• The account mappings are agreed.
• The column layout is agreed.
• Finance owns the sign convention and presentation rules.

Report Groups

Report groups are the categories users browse in Reporting > Reports.

Good groups are stable and business-readable, such as:

• General Ledger Reports.
• Financial Statements.
• Loan Reports.
• Deposit Reports.
• Billing Reports.
• Management Reports.

Avoid project names, one-off cleanup names, or developer-oriented labels. A group should still make sense months after go-live.

Report Definitions

A report definition is the runnable report card users select in Reporting > Reports.

Important fields:

Field	Meaning
Report Code	Stable system identity for the report. Users normally do not change it after publishing.
Report Name	User-facing name shown in report lists and selectors.
Report Group	Where users find the report.
Report Type	The business shape of the report, such as list, financial statement, KPI, summary, or chart.
Output Mode	How Pinkapple should render the result: table-style output or structured report output.
Default Parameters	Starting filters users see when opening the report.
Active	Whether the report is available for normal use.

Keep incomplete reports inactive until they have been run and validated.

Choosing Report Type And Output Mode

Report Type tells Pinkapple what kind of business result the report represents.

Output Mode tells Pinkapple how to display the result.

Use this matrix:

Report Type	Use It For	Normal Output Mode
List	Registers, ledgers, account statements, transaction listings	Row/table output
Financial Statement	Trial balance, balance sheet, income statement, cash flow	Structured report output
Management Dashboard	Mixed KPI, chart, and table views	Structured report output
KPI	Compact indicator packs	Structured report output
Summary	Grouped totals, exposure summaries, aging buckets	Structured report output
Chart	Chart-led analytical reports	Structured report output
Pivot	Cross-tab or matrix-style analysis	Structured report output
Custom	Specialised reports that do not fit the normal categories	Structured report output unless finance confirms otherwise

If the wrong output mode is selected, the report may run but render poorly. Common symptoms include a statement opening as a flat table, missing totals, broken exports, or unusable drilldowns.

Default Parameters

Default parameters are the starting values users see before running a report.

Good defaults are practical and low-risk:

• Current month.
• Last month.
• Year to date.
• Current business unit.
• Default reporting currency.

Avoid defaults that hide important data or make the report look empty for most users.

Access Rules

Before publishing a report, decide who should see it.

Use access rules to limit reports by:

• Business unit.
• Role.
• Service context where applicable.

Do not leave a sensitive report broadly visible unless that is the intended governance policy.

Drilldowns

Drilldowns let a user click a report row and open supporting detail.

Examples:

• Trial balance row to account statement.
• Aging summary to invoice detail.
• Portfolio summary to account list.
• Settlement summary to transaction list.

When configuring a drilldown, focus on the user experience:

• Use a clear action label, such as View Account Statement.
• Show the action only on row types where it makes sense.
• Require the row to carry the fields needed for the follow-up.
• Confirm the target report is visible to the same user audience.

The user should not need to manually copy filters. Pinkapple should carry the current report context and the clicked row context into the follow-up report.

Financial Statement Reports

Financial statement reports need more setup than ordinary reports.

The minimum working set is:

• A financial statement template.
• Ordered statement lines.
• Account mappings.
• Column definitions.
• A column set.
• A report definition linked to the statement.

Validate the statement in Reporting > Reports before publishing it. Confirm:

• The line order is correct.
• Signs and totals make sense.
• Mapped accounts are complete.
• Comparative columns show the intended period.
• Exports match the screen.

Presets

Presets save repeatable filter choices.

Good preset examples:

• This Month.
• Last Month.
• Year To Date.
• Current Branch.
• Board Pack.

Use presets when users repeatedly run the same report with the same filter pattern. Do not use presets to hide unclear report design.

Snapshots

Snapshots preserve a report result at a point in time.

Use snapshots for:

• Board packs.
• Management packs.
• Period-end evidence.
• Reports that need a preserved output even if later balances change.

Use normal report runs for day-to-day live review.

Schedules

Schedules run reports automatically.

Only schedule a report after manual validation passes. Confirm:

• The report opens correctly.
• The parameters are stable.
• The output is trusted.
• The delivery timing is meaningful.
• Someone owns failed schedule follow-up.

Validation Checklist

Before marking a report ready for users, confirm:

• The name and group are business-readable.
• The report type and output mode match the result.
• Default parameters are useful.
• Access rules are correct.
• The report runs in the Reporting workspace.
• Totals reconcile where relevant.
• Drilldowns work.
• Exports match the screen.
• Presets and schedules are added only after validation.

Common Mistakes To Avoid

• Do not publish a report just because setup saved successfully.
• Do not use developer-style names for report groups or reports.
• Do not choose a financial statement type for ordinary list output.
• Do not schedule reports before a finance user has validated them manually.
• Do not leave sensitive reports visible to all roles by accident.

Related Pages

• Reporting Overview
• Administration & Setup
• Report Catalog
• Financial Statements
• Running Reports