BI and ERP Analytics
There are two analytics surfaces and it is worth knowing which is which before you build anything.
Where to find it
Architect Panel → Dashboards:
- Explore — general BI over any datastore
- BI Dashboards — dashboards built from it
Architect Panel → ERP - Trading & Analytics:
- Analytics — the ERP console
- Measures — ERP measures
- Dimensions — ERP dimensions
- Reports — saved ERP report definitions
ERP Analytics
Purpose-built for the ERP modules, with measures and dimensions defined over the ledger, stock, documents and the rest. It understands entities and accounting periods natively, and its scheduled distribution runs through the ERP report task.
Use it for financial and operational reporting out of the ERP layer — a trial balance summary, stock valuation by location, aged debt by entity.
Business Intelligence
The general layer, over any registered datastore including the ones you designed yourself.
Use it for questions that are not ERP-shaped: casework performance, service demand, attendance, anything specific to what you built.
Which to use
If the question is about the ledger, stock or ERP documents, use ERP Analytics — it already knows the semantics and the period rules. If the question spans your own datastores, or mixes them with ERP data, use BI.
Where both could answer, prefer whichever surface the audience already uses. Consistency of experience beats theoretical fit.
Do not define the same measure twice
This is the one rule that matters.
If "revenue" exists in both surfaces they will eventually disagree — a filter changes on one side, a period rule is interpreted differently, an exclusion is added in one place and not the other. Reconciling two definitions of the same figure is a genuinely bad week, and it usually happens in front of somebody senior.
Decide which surface owns a given measure and let the other reference it rather than redefining it.
Worked example
A housing provider keeps rent income in ERP Analytics, because it comes from the ledger and must tie to the accounts. Repairs performance lives in BI, because it comes from a bespoke repairs datastore. A board dashboard shows both, each drawn from its owning surface, so neither number has a second definition anywhere.
Recommendations
- Write down which surface owns which measure. A one-page list prevents years of confusion.
- Never copy a measure definition between surfaces to save a join.
- Put the source on the dashboard so a reader can tell where a figure came from.