ERP Analytics

Measures and Dimensions

ERP analytics separates what you measure from how you slice it. Define each once and every report built from them agrees.

Where to find it

Architect Panel → ERP - Trading & Analytics:

• Analytics — the console — build and run
• Measures — what is counted, and how it is aggregated
• Dimensions — how results are grouped

A measure

A measure names a number: its source, the column holding the value, the aggregation (sum, count, average), an optional filter restricting what is included, an optional formula for derived figures, a display format, and an enabled flag.

The filter is what makes a measure precise. "Revenue" filtered to posted documents excluding intercompany is a definition; "revenue" as a bare column sum is an invitation to an argument.

Define once, centrally

This is the whole point. The commonest reason two reports disagree is not a bug — it is that each computed revenue slightly differently, one including credit notes and the other not, and nobody noticed until a board pack contained both.

A central measure means there is one definition, it is visible, and correcting it corrects every report at once.

A dimension

A dimension names a way of grouping: its source, the key column, the label column, and optionally a parent column for hierarchies.

The parent column is what gives you drill-down — region to country to office, or category to subcategory to product — because the hierarchy is declared rather than reconstructed per report.

Label separately from key

Group by a stable key and display a readable label. Grouping by a name means a renamed customer splits into two rows, and the split is invisible unless somebody notices the total no longer matches.

Name them for the business

These names appear in front of people choosing what to report on. "Net Revenue (excl. intercompany)" is a usable choice; "erp_doc_total_2" is not, and it will produce reports built on whatever was guessed at.

Row limits

Measures carry a row limit. Set a sensible one so an accidentally broad report does not attempt to aggregate everything — but set it high enough not to silently truncate a legitimate result. A truncated total that looks plausible is worse than one that fails.

Start small

Ten well-defined measures and half a dozen dimensions cover most of what a business asks. Add on demand rather than modelling everything up front; measures nobody uses still have to be maintained and still confuse the person choosing.

Worked example

A distributor defines Net Revenue, Gross Margin, Order Count, Average Order Value and Stock Value, with dimensions of Customer, Product Category (hierarchical), Entity, Salesperson and Month. Every report and dashboard is built from these, so when the intercompany exclusion is corrected, all of them correct together.

Recommendations

• Put the definition in the measure, never in each report.
• Name for the business audience.
• Key and label separately on every dimension.
• Start with ten measures and grow on demand.

Reports, Schedules and Dashboards

A report is a saved combination: which measures, which dimensions, what filters, how it is laid out, and who may see it.

Where to find it

Architect Panel → ERP - Trading & Analytics:

• Analytics — the console — build, preview, run
• Reports — the saved definitions
• Report Schedules — recurring distribution

Architect Panel → Automation:

• Tasks — Scheduled Report Distribution, hourly

What a report holds

• Measures — the numbers.
• Dimensions — how they are grouped.
• Filters — what is included.
• Layout and chart type — how it is presented.
• Row limit — a bound on the result.
• Security groups — who may see it.

Security is on the report

Restricting by security group is a first-class field, not an afterthought. Reports aggregate — which means a report can expose in summary what a person cannot see in detail. A salesperson restricted to their own accounts should not receive a company-wide margin report because nobody set the groups.

Set them when you create the report, not when somebody notices.

Two dimensions is usually enough

A table grouped three or four ways is technically a report and practically a spreadsheet nobody reads. Build several focused reports rather than one that answers everything; each one should answer a question somebody actually asks.

Chart type

Match it to the question. Trend over time is a line; comparison across categories is a bar; composition is a stacked bar — and almost never a pie, which humans read badly at more than three segments. If the chart needs a legend to be intelligible, the report is probably doing too much.

Scheduling

A schedule holds the frequency, the recipients, the format, and the last and next run times. The Scheduled Report Distribution task drives it hourly and ships disabled — enable it under Automation → Tasks, or schedules will sit there looking configured and send nothing.

Send fewer, less often

A daily report nobody opens trains people to ignore the sender, and the one report that mattered goes unread with the rest.

Send weekly unless somebody will act daily, send to named people rather than a distribution list, and remove recipients who have stopped needing it. A scheduled report should prompt an action; if it does not, stop sending it.

Check who receives it

Recipients are a list on the schedule, so review it when people change roles. A monthly management pack that keeps arriving after somebody leaves the company is a data protection problem, not merely untidy.

Worked example

A finance team runs a weekly margin report by product category and month, restricted to the finance security group, delivered as a spreadsheet each Monday to four named people. A separate daily stock-below-reorder report goes to two buyers — daily because they act on it every day.

Recommendations

• Set security groups on creation.
• Two dimensions, and build more reports rather than bigger ones.
• Enable the distribution task or schedules do nothing.
• Review recipients quarterly.