Analytics module
Numbers that survive the second question
Ask the question you care about — margin by brand, stock turns by site, overdue by customer — and the answer comes off the same data the warehouse and the accounts already produce, without asking anybody for it. And it holds up to the second question: the total matches its own breakdown, the margin states how much of the turnover it is computed on, and when a precomputed figure drifts from reality a guard says so.
Sum of line net amounts, tax excluded, discounts already applied, credit notes deducted. It holds in the total and in the breakdown: if two screens gave two numbers, one of them would be wrong.
Every precomputed table is re-checked against the same question asked of the live data. If they differ by a euro, that becomes a line with a date and a gap.
A saved view stores the question and revalidates it on every open: sharing it never hands anyone a permission they do not have.
A margin computed where cost is only half known arrives with the share of turnover it covers, instead of looking complete.
The question that matters is not «what did we turn over»: it is «what did we turn over, and where exactly does that number come from». Here revenue is defined once and holds on every screen; totals are recomputed instead of being summed from the groups; and every precomputed table is regularly challenged by asking the same question of the live data. No second program, no exporting into a spreadsheet, and above all no taking it on trust.
Revenue is defined once
It sounds like pedantry until it happens: the summary adds up order totals, the breakdown by category adds up order lines, and the two figures disagree — because shipping is in the order total and not in the lines. Whoever is reading has no way of telling which one is the turnover. Here revenue has a single definition, written in a single place: the sum of line net amounts — goods and services, shipping included — tax excluded, with line and header discounts already applied and credit notes deducted. Italian consumption duty stays outside because it is not revenue: it is a levy collected on behalf of the state, and adding it to turnover invents a margin that does not exist.
- VAT out, and kept as a measure of its own: turnover including VAT compares to nothing
- A cancelled order still produces its lines, flagged as non-revenue: «how much did we lose in cancellations» is a real question
- Shipping is counted once, even on orders that straddle a change of rule
| Item | In revenue | Why |
|---|---|---|
| Line net amounts, goods and services | yes | The definition is the sum of the lines, not the document total |
| Shipping | yes | It is revenue in every sense, and it is counted once |
| Line and header discounts | already in | The figure is the net one, not the list price |
| Credit notes | deducted | Otherwise a return would stay invoiced for ever |
| VAT | no | It is not revenue: it is tax, and it is kept as a measure of its own |
| Consumption duty | no | A levy collected on behalf of the state: adding it in inflates the margin |
A total is recomputed, never summed from the groups
Adding up the rows of a breakdown to get the total works for units and euros, and is wrong for everything else. Order count is the example you always meet: an order with twenty lines appears in twenty rows of the breakdown, and the sum reports three times the orders there are. Here the total is a second question, asked without the breakdown. And measures that are a balance — stock on hand, money owed by customers — have no total along time at all: the cell stays empty with the reason next to it, because adding twelve month-ends would give a warehouse twelve times too big, and no digit of that number would look wrong.
- The total is not the sum of the rows on screen: it is the same question without the grouping
- A document-level measure cannot be summed along a dimension finer than the document: the request is refused with a reason, not answered with an inflated number
- Stock and exposure add up across customers and warehouses, never across time
- Where a total makes no sense the cell is empty and explained, not zero and not a sum
- BY SUMMINGThe order count read off the rows of the table31
- BY RECOMPUTINGThe same question, asked without the grouping12
- REFUSEDA document measure asked for at a grain finer than the documentwith the reason
An order with twenty lines shows up in twenty rows of the breakdown: summing them gives three times the orders there are. It is the number most dashboards show without knowing it.
The questions it can answer, and what it can cross them with
Analytics here is not a set of fixed charts: you pick a measure, break it down along one or more dimensions, filter and read. There are five families of data — sales at order-line level, stock as a snapshot by day and by month, purchases at goods-in line level, shipments one row each, and open receivables with their due dates. The dimensions are the ones a business actually reasons in, each with its own levels: time by year, quarter, month or day; item by category, brand or single code; customer by province or region. Every measure carries a plain description of what it measures, for the person reading the number rather than the code.
- Dimensions: time, customer, item, warehouse, owner, supplier, carrier, sales channel
- Every dimension has its own levels: time by year, quarter, month or day; the item by category, brand or code; the customer by province or region
| Family | The grain | What is measured |
|---|---|---|
| Sales | The order line | Revenue, VAT, cost of goods sold, margin, quantity, orders, average order, active customers |
| Stock | The day and the month | Units, value at cost, value at selling price, average stock, days of cover, turns |
| Purchases | The goods-in line | Value purchased, units received, lead time measured between order and arrival |
| Shipments | The single shipment | Count, transport cost, transit days on deliveries actually confirmed |
| Receivables | The open item | Exposure, overdue, average days to collect |
A guard whose job is to contradict the dashboard
The numbers are precomputed, because at real volumes reading live does not hold up. The flaw of every precomputed model is that when it drifts from reality it does not say so: it shows the stale number with the same face as the right one. So the reconciliation does not compare two precomputed tables — if the load is wrong it is wrong in both the same way and the comparison comes back green — it asks the live data exactly the same question. And the tolerance is not only a percentage: half a point of a large turnover is thousands of euros of slack, which is a whole invoice disappearing with nobody knowing. A precomputed figure is not an estimate: it is the same sum done again, and it has to agree to the cent.
- The comparison is against live data, never against another precomputed total
- A percentage tolerance and an absolute one together: breaching either one is a breach
- Orphan rows and gaps by month, by customer, by warehouse: shape checks that must be exactly zero
- The outcome is read back after being written, so a guard cannot look passed without having been run
- When there is a gap, there is a way to put the numbers right without waiting for the weekly run
And a guard whose job is to prove it wrong
- The precomputed numberWhat the dashboard shows, already summed: fast, and for that reason worth watching.
- The same question, asked liveRe-run against the orders and invoices, not against another precomputed total that would be wrong the same way.
- The gapPast the tolerance — percentage and absolute together — it becomes a line with a date on it.
How fresh the numbers are, and who refreshes them
The load runs by itself at three different widths, and they are not the same thing with different parameters. The hot window, hourly, revisits recent days: that is what keeps the dashboard current. The full rebuild redoes the whole history on the quietest night of the week, so the model never drifts, not slightly and not for months. In between there is the targeted pass over what actually changed — a merged customer record, a corrected invoice — which fixes things in days rather than in years. Every run states how it went: it starts as «running» and ends with its outcome, including when the outcome is an error.
- Hourly hot window over recent days, full weekly rebuild
- Targeted pass over what genuinely changed, when a known gap needs fixing now
- A run that is interrupted records where it stopped and picks up from there
- The state of the load is visible: no fresh-looking number that is in fact a week old
- Reference data is reloaded in full every time: an item renamed in March never shows its old name in October
- The hot window, every hourIt goes back over the recent days: that is what keeps the dashboard current, and why today is fresh.
- The targeted pass, when neededOnly what actually changed — two customer records merged, an invoice corrected — so a known hole is fixed in minutes instead of waiting for the sweep.
- The full rebuild, at nightIt redoes the whole history on the quietest night of the week, so the model never drifts: not by a little, not over months.
Saved views, and who gets to see what
A question you have named becomes a view: you reopen it, you share it with the people you work with, you find it again next week. What gets saved is the question, never the query: so when somebody else opens it, it is revalidated on the spot against that person’s permissions. A shared view is never a way of showing a colleague numbers they could not ask for themselves. And the gate on money figures follows the person, not the screen: a shift supervisor sees quantities, times and productivity and does not see the euros — on every route to the same data, not only on the front door.
- The view keeps the question and revalidates it on every open
- Private, or shared with the company, with the roles allowed to open it
- Someone who cannot see money figures gets the same screens without the value columns, not a wall
- The list already says which views can be run and which can be deleted, instead of finding out after the click
- PURCHASINGStock turns by brand, with the value at costsees it all
- SHIFT LEADThe same rows, without the value columnsunits and days
- ON OPENINGThe question is revalidated against the permissions of whoever opens itevery time
What gets saved is the question, never the query: sharing a view is never a way of showing a colleague numbers they could not ask for on their own.
Operational dashboards, not only management reports
Not everything you look at is a month-end report. The shift dashboard answers questions about right now — how many orders are waiting, how many lines are stuck, where the exceptions are — and refreshes continuously without recomputing anything when nothing has changed. The daily indicators count goods receipts as acceptance events rather than as stock lines, because five pallets that arrived together are one receipt and not eighty-three: a number nobody on the floor recognises is not an indicator, it is noise. And movements are counted on the day the goods moved, not the day the row was written — otherwise every data import produces a spike that never happened.
- A shift dashboard with work waiting, work in progress and open exceptions
- Day and month indicators: receipts, delivery notes, movements, orders
- Movements are dated when they happened, not when they were recorded
- Exports to CSV or Excel with the scope stated in the header, and the row limit declared when it bites
Frequently asked questions
Why does the dashboard turnover differ from my accountant’s figure?
Because they answer two different questions, and the difference is stated. Here revenue is the sum of line net amounts: VAT excluded, consumption duty excluded, credit notes deducted, shipping included because it genuinely is revenue. A document total includes VAT and compares to nothing. Once you know which of the two you are looking at, the figures reconcile.
How current are the numbers?
The hot window runs hourly over recent days, so today is fresh. A full rebuild redoes the entire history once a week, overnight, so the model does not drift. And if a known gap needs fixing right away, the recalculation can be requested instead of waited for: the state of the load is written down, so you never look at a stale number thinking it is from this morning.
Is the margin I see trustworthy?
As trustworthy as the cost underneath it, and the number says so. Where cost of goods sold is not known on every line, the measure arrives with the share of turnover it covers: «this margin, over this much of the revenue». Without that, revenue would be counted in full and cost only in part, and the margin would come out close to the turnover — the worst kind of lie, because it looks plausible.
Who in the company can see money figures?
The role decides, and it holds on every route to the same data. A shift supervisor has their own analytics — units on the shelf, lines worked, times, days of cover — and does not have the euros, not through a shared view and not through an export. They do not get a wall: they get the same screens without the value columns.
Do I need another program for analytics?
No. The questions are asked inside CargoNode, on the same data the warehouse and the accounts produce: there is no overnight export into another system and no second place where the definitions could drift apart. The model underneath is a star schema — dimensions and fact tables — because that is the shape an analytical model keeps working in as the data grows.
I have very little history. Is analytics still worth it?
Yes, but what you look at changes. With a few months, stock turns and days of cover already read correctly, because they are annualised on purpose and an item that arrived mid-period does not look slower than it is. Year-on-year trends, on the other hand, arrive when the second year does: no calculation can invent them earlier.
Let us ask the question you actually care about
Tell us the number you rebuild by hand every month. We will show it to you on your own data, together with how you check that it is right.
Talk to us