Analytics & Business Intelligence

1. The Analytics and BI Module

SamvraCore's Analytics and Business Intelligence module gives an organisation a way to see across the data its operational modules generate. It is built from four user-facing surfaces — a BI Dashboard (BIDashboardPage), a KPI Board (KPIBoardPage), a Report Builder (ReportBuilderPage) and a Forecasting view (ForecastingPage) — sitting on top of a dedicated analytics data foundation.

The module is also the home for custom reporting used by other areas of the product. The accounting module, for instance, points to this Analytics module as the place where a custom report builder lives, rather than duplicating reporting inside financial reporting. This keeps a single reporting surface for the whole ERP.

The four surfaces at a glance

• BI Dashboard — embedded charts and headline KPIs in one view.
• KPI Board — a board of key metrics, authored through a KPI Designer.
• Report Builder — construction of custom reports.
• Forecasting — forward-looking projection.

Because the ERP is multi-tenant, analytics is scoped to the organisation viewing it, like every other module. The following chapters examine each surface in turn and then the data foundation — materialised views and a KPI definitions table — that makes the dashboards and boards perform.

2. The BI Dashboard

The BIDashboardPage is the module's at-a-glance surface. It combines embedded charts with KPIs so that a user can read both trends and headline figures in a single place. Charts render visual patterns over time or across categories, while KPIs condense a measure down to one number that answers a direct question such as how much or how many.

Putting charts and KPIs together on one dashboard is a common BI pattern: the KPI tells you the current state, and the chart next to it tells you how you arrived there. For a decision-maker this reduces the number of separate screens needed to understand performance.

How it draws on the rest of the ERP

A BI dashboard is only as useful as the data beneath it. In SamvraCore the operational modules — accounting, sales, inventory, HR and the rest — are the source of the figures a dashboard summarises. Because those modules record transactional detail, the dashboard can present aggregated views without the user having to open each module individually.

The dashboard's embedded charts and KPIs are backed by the analytics data foundation described later, which is what lets a summary view respond quickly even when it spans a large volume of underlying records. The BI Dashboard is therefore best understood as a presentation layer: it assembles and displays, while the heavy aggregation is prepared beneath it.

3. KPI Board and the KPI Designer

The KPIBoardPage is a dedicated board for key performance indicators, distinct from the broader BI Dashboard. Where the dashboard mixes charts and metrics, the KPI Board concentrates on the metrics themselves, presenting a set of indicators an organisation wants to watch.

What makes the board configurable is the KPI Designer, provided as a modal within the page. The designer is where a KPI is defined — it is the authoring experience that turns an abstract idea of a metric into a concrete indicator that the board can display. This means KPIs are not hard-coded; an organisation can shape the indicators it tracks.

Board versus designer

• The KPI Board is the display — it shows the indicators.
• The KPI Designer is the editor — a modal where indicators are defined.

Behind the board sits a KPI definitions table in the database, introduced by a dedicated migration. That table is what persists each KPI an organisation has designed, so the definitions survive between sessions and are available to render on the board. The split between a persisted definition and a visual board is the same separation-of-concerns pattern the product applies elsewhere: configuration is stored as data, and the UI renders from it. For a user, the practical effect is that building a monitoring board is a configuration task, done through the designer modal, rather than a development task.

4. Report Builder and Forecasting

The ReportBuilderPage is the module's tool for custom reports. Rather than being limited to a fixed set of canned outputs, a user can construct a report to their own specification. This is the capability other modules defer to: the accounting area explicitly routes its custom report building to the Analytics module, so the Report Builder serves as a shared reporting surface across the ERP rather than a siloed accounting feature.

The ForecastingPage adds a forward-looking dimension. Where the BI Dashboard and KPI Board describe what has happened and what is currently true, forecasting is concerned with projection — extending from recorded data toward expected future values. Together, descriptive dashboards and a forecasting view give an organisation both a rear-view and a forward-view of the same operational data.

Choosing the right surface

• Use the BI Dashboard for a mixed overview of charts and headline KPIs.
• Use the KPI Board to concentrate on defined indicators.
• Use the Report Builder to produce a specific custom report.
• Use Forecasting to look ahead rather than back.

These four surfaces are complementary: an analyst may design KPIs, watch them on the board, assemble a detailed custom report for a stakeholder, and consult the forecasting view when planning. All four draw on the same tenant-scoped operational data and the analytics data foundation that supports them.

5. The Analytics Data Foundation

The Analytics module is backed by a deliberate data foundation rather than live queries against every transactional table. Two database constructs, each added by its own SQL migration, underpin it: materialised views for analytics and a KPI definitions table.

A materialised view is a precomputed, stored result of a query. Instead of recalculating an aggregation every time a dashboard opens, the system can read from the materialised view, which already holds the summarised figures. This is why a summary surface spanning many underlying records can respond quickly — the expensive aggregation has been done ahead of time and persisted.

The KPI definitions table stores the indicators an organisation has created through the KPI Designer. Separating the definition of a KPI from its display means the same stored definition can drive the KPI Board and feed KPI figures shown on the BI Dashboard.

Why the foundation matters

• Materialised views move heavy aggregation out of the request path, improving responsiveness.
• The KPI definitions table makes metrics durable, configurable data rather than hard-coded values.
• Both are introduced by versioned SQL migrations, so the analytics schema evolves with the rest of the database.

This foundation is what connects the module's four visual surfaces to the operational reality of a busy, multi-tenant ERP: the dashboards present, the designer configures, and the materialised views and definitions table do the storing and precomputing that keep the presentation fast and consistent.