A worked example

Classifications are the part of belsimple that takes longest to click. This article follows one small project from task tree to finished report, so you can see exactly where each figure comes from.

The setup

One project with four tasks, and two classifications applied to them:

The classification “Frascati R&D Categories” is one of the built-in templates — the R&D categories a tax filing is built on. Only two tasks have an explicit Frascati class: “Experimental Development” on the root, and “Non-R&D” on customer support. The other three inherit from the root, which is why their cells read inherited — nothing was set on them. Customer support is what an override looks like: its own class replaces the inherited one rather than adding to it, so that time counts as “Non-R&D” and not as “Experimental Development”.

This company also runs a project supported by VLAIO, the Flemish innovation agency. The approved application divides the funded work into work packages — two of them here: the control electronics, and the validation in the field — and the agency expects progress to be reported per work package.

To produce that reporting from belsimple, the company created a second classification of its own, “Grant work packages”, with one class per package: “WP1” and “WP2”. That way the report can add up the time per work package. Unlike the Frascati classes, these were assigned task by task and nothing is inherited. The root task was given no work package at all, because the project as a whole is not a work package — the work packages sit in the tasks below it.

What was logged

Over one week:

Eighteen hours in total.

What the report shows

The Classifications tab of the time report, which aggregates across everyone in the workspace:

Where each figure comes from

960 minutes of Experimental Development is 8 h + 4 h + 4 h — the three tasks that inherited the root’s class. Inheritance is invisible in the report: an inherited class counts exactly as much as one set directly on the task.

120 minutes of Non-R&D is the customer support time. Because that task overrides the inherited class rather than adding to it, none of its time appears under “Experimental Development”.

WP1 gets 600 minutes, WP2 gets 360. The control loop prototype contributes its full 480 minutes to “WP1” and the field trials their full 240 to “WP2”. The integration tests are the interesting one: that task carries two classes from the same classification, so its 240 minutes are split equally — 120 to each. Time is never counted twice within one classification.

The same 240 minutes count in full under Frascati. The split happens only among classes of the same classification. An hour is not divided between the two classifications — it counts in full in each. That is why each classification adds up to the full 1,080 minutes on its own.

120 minutes are Unclassified under the grant classification. Customer support was never given a work package. That is not an error — support work genuinely sits outside the grant — but the row makes it visible instead of letting the time disappear. Under Frascati nothing is unclassified, so that row reads zero. It is always present either way, so you can confirm at a glance that nothing fell through.

Reading it as a reviewer

Two properties of the table are worth internalising, because they are what make the report defensible:

• Each classification totals the same 1,080 minutes. If one of them doesn’t, time is sitting in “Unclassified” — which is exactly what that row is for.
• The figures reflect what was true when the time was logged, not what the task looks like today. Reclassifying a task from tomorrow onward leaves this report unchanged. See Classifications for how those snapshots work, and Reports for the other tabs in the file.