Workload plan

Place what is actually left to do on weeks, against a declared capacity rather than a guessed one, and quantify what cannot be placed instead of hiding it.

Symbifox 18.0 (September 2026 catalogue) · Modules: Workload plan · Revised 2026-10-02

Watch it

A task backlog tells you how many hours are recorded. It does not tell you whether they fit, which weeks they land on, or which of them are real work. The Plan de charge (workload plan) application fills exactly those three gaps and nothing else. It is meant for the person carrying several engagements at once who wants to know, with figures rather than a feeling, whether they are taking on too much.

This module is published but absent from the Boréal demo: this chapter describes it from its documentation and its declared screens, without screenshots (module published, not illustrated). The labels below are those of an English interface.

Overview#

Three ideas govern everything else, and each answers a way of being wrong.

Capacity is declared, never inferred. Hours in a timesheet are not wall clock time. On a real database several days go past sixteen hours, sometimes far past: assisted work produces several hours within the same hour. Dividing a backlog by "the hours I log per week" therefore returns a wrong answer with two decimals. The module measures the candidates, shows them side by side, and lets a person choose.

A workload says where it came from. Odoo's allocated hours field has several sources: a human estimate, or a sold quantity converted by its unit of measure. A yearly subscription line sold in "Year" belongs to the working time category and becomes thousands of hours nobody estimated. Every task therefore carries its source, and an hour derived from a sale unit that is not the hour is set aside from the plan, visibly, with its reason.

What cannot be placed is never hidden. A task with no date lands on no week. A calendar that only shows what it can place lies by omission. The plan therefore always shows, next to the weeks, the total hours it could not place and how many tasks that is. That figure, rather than the calendar, is often what answers the question being asked.

The vocabulary fits in five words. The capacity contract declares what one person can deliver per week. The workload plan places open work on a horizon of weeks. Each week of the plan carries its workload, its capacity and a verdict. The signals say whether you are taking on too much. The reading keeps a dated count, so a trend exists.

The application lives off two others, which it only reads. Last logged dates come from Timesheets, and a task's start date, when there is one, from Échéancier (Gantt). It modifies neither.

Configuration#

Access and permissions#

The application ships a single group, Workload plan: management. A person's capacity is sensitive data: it is not offered to every internal user, and the menu only appears for whoever holds the group.

The group is deliberately narrow. The module therefore reads timesheet lines and sale units with elevated rights on its own behalf, and each read is bounded to its own company rather than relying on an access rule that elevation would bypass.

Settings#

Two settings, both in the system parameters.

The module also ships a scheduled action, Workload plan: weekly reading, which takes a reading every week and keeps it. It ships disabled, on purpose: a reading taken before a capacity is declared archives zeros that will later look like a measurement. Enable it once the contract is filled in.

Base data#

Two things come before the first plan.

• A capacity contract in force, for the person whose workload you plan. Without it, the plan places the hours but cannot say whether they fit, and three of the five signals stay "not declared". See Declare the capacity.
• The template tag on projects used as patterns. A template project is a pattern to clone, not work waiting: its hours never enter a plan. See Mark a project as a template.

Getting started#

This walkthrough declares a capacity, builds a first plan over twelve weeks and reads what it could not place.

1. Go to Workload plan › Capacity contracts and select New.
2. Check the Person, then enter the Hours per week actually available for delivery.
3. Select Take the measured meeting median to fill in Meeting hours per week, then select Put in force.
4. Go to Workload plan › Workload plans and select New.
5. Check the Person, choose the Capacity contract, then enter "12" in Horizon in weeks (eight by default, starting today).
6. Select Compute the plan.
7. Read the What the plan could not place block, then the What the plan says summary.

Result: the plan shows the hours placed week by week in the Weeks tab, with their verdict, and next to them the total hours it could not place. If that total surprises you, look at it first.

Common tasks#

Declare the capacity#

The contract covers a person, not a team. It is filled in by hand, next to what the database has measured.

1. Go to Workload plan › Capacity contracts and open or create the person's contract.
2. Read the What the database measures, and what nobody should mistake for an answer block: five measured candidates, none of which the module picks.
3. Under What is declared, enter the Hours per week and the Meeting hours per week, or select Take the measured meeting median.
4. If needed, enter the Ceiling on concurrent customers and the Target customer share (%).
5. Write the Stop criteria: what has to happen for you to stop taking more on.
6. Select Put in force.

Result: the Net capacity per week appears, and that is what the plan uses. The same person's previous contract is closed automatically; Close ends a contract by hand. A contract without hours per week is refused: that is its whole purpose.

Mark a project as a template#

A project used as a pattern must not count as work.

1. Go to Project and open the pattern project's record.
2. In Tags, add "Gabarit".
3. Save.

Result: the project's Kind, shown under the tags, becomes Template, and its hours leave every plan. They stay counted apart, in the Out of plan, by construction block.

Correct a task's workload#

A task with no estimate, or whose estimate no longer holds, gets a workload set by hand, which overrides everything else.

1. Go to Project and open the task.
2. Under Allocated Time, enter the Corrected workload (h).
3. Save.

Result: a Retained workload (h) row appears under your entry, with your figure and the source Corrected by hand. The next computation of the plan takes it into account.

Build and recompute a plan#

A plan can be redone as often as you like: the computation clears and rebuilds its weeks, lines and signals.

1. Go to Workload plan › Workload plans and open the plan.
2. If needed, change the Starting from date or the Horizon in weeks.
3. Select Compute the plan.

Result: Computed on takes today's date, and the three blocks fill in.

The Weeks tab gives one row per week, with its hours, the Declared capacity, the Load (%) and a coloured Verdict: green below eighty percent, yellow above, red when the week exceeds capacity.

Read the five signals#

A plan's Signals tab answers the question "am I taking on too much". Each signal shows its Measure and its Benchmark, not just its colour, and stays "not declared" while its benchmark is not in the contract.

The third stays silent if the Hour bank application is not installed: it says so rather than showing a misleading green.

Slice the workload#

Every computation writes one row per task and per week its workload lands on, carrying its project, customer, source, dates and outcome. A task straddling two weeks gives two rows whose shares add up to one.

1. In a plan, select the Lines quick access button, or go to Workload plan › Workload, line by line.
2. Read the Workload by week chart: bars stacked by outcome of the workload.
3. Switch to the Workload, cross table pivot to see projects in rows and weeks in columns.
4. Remove the Placed filter and turn on Not placeable or Out of plan to see what found no week.

Result: the workload reads by week, outcome, project, customer, source or project kind, with the Customer work and Internal work filters to separate engagements from the rest.

Follow the trend with readings#

A plan answers "where do we stand"; it does not answer "is it getting worse". The reading keeps the few numbers that carry that answer.

1. Declare the capacity first (see above).
2. Go to Settings › Technical › Scheduled Actions and open Workload plan: weekly reading.
3. Enable it.
4. A few weeks later, go to Workload plan › Readings and read the Backlog trend chart.

Result: one reading per week, which the Readings, cross table pivot compares over several months.

The menus, one by one#

Workload plan: the application's root, visible only with the Workload plan: management group.

Workload plan › Workload plans: the list of plans, most recent first, with the person, starting date, horizon, declared capacity, placed and unplaceable hours, backlog in weeks and computation date. This is the starting screen: you create a plan there and compute it.

Workload plan › Workload, line by line: the table of all lines, opening on the Workload by week chart, filtered on placed hours and grouped by week by default. The pivot and the list complete it. This is the screen for slicing the workload every which way.

Workload plan › Weeks: the weeks of every plan, as the Placed workload by week chart, as a monthly calendar of weeks against capacity, or as a list.

Workload plan › Capacity contracts: the list of contracts, with the person, date in force, hours per week, meeting hours, net capacity, customer ceiling and state (Draft, In force, Closed).

Workload plan › Readings: successive readings, as the Backlog trend chart, the Readings, cross table pivot or a list.

Reference#

Fields of the Capacity contract form#

The five measured candidates, shown without being chosen:

Fields added to the task and the project#

Reports and exports#

No printed report. The analysis screens are standard Odoo views: a stacked chart of workload per week, a projects by weeks pivot, a calendar of weeks against capacity, coloured cards for the signals, a trend line over the readings. Every list exports through the usual actions.

Automations#

The plan itself never recomputes on its own: Compute the plan rebuilds it.

Modules that extend this application#

No satellite module. Two applications are recognised when installed, without ever being required: Échéancier (Gantt) gives the plan a start date to spread the workload from, and Hour bank makes the third signal report real balances.

Understanding#

Where a task's workload comes from. Five sources, in order of priority: Corrected by hand always wins; Estimated when the allocated hours come from a human entry; Sold quantity when they come from a sale line whose unit is the hour; Sold quantity, set aside when the unit is another unit of time, the workload then being zero and the reason saying so; None when the task carries no estimate. That last case is a fact, not a zero, and it is counted apart.

The sale unit that writes thousands of hours. A service product that creates a task on sale, sold in the Year unit, writes into allocated hours the conversion of that year into working hours, several thousand of them. Nothing flags the anomaly: the number is exact, it is what it describes that is not. A sold duration is not an estimated effort. If the total set aside surprises you, a product in your catalogue deserves another unit of measure.

How an hour finds its week. The module looks for the task's start date, if Échéancier is installed and the date is filled in, then its deadline. A task carrying both has its workload spread in proportion to the days of each week it covers. A task carrying only one lands entirely on the matching week. A task with no date is not placeable. A deadline already past brings the workload back to the first week, counted as overdue; a start beyond the horizon counts it apart; a window running past the horizon places only the visible share.

Projects classify themselves. A project carries the template tag: Template. It is archived, or no hour has been logged in it within the configured window: Dormant. Otherwise: Live. An archived project is filed away whatever its last logged hour, because a task left active inside an archived project would come back without a word and be counted as live work. On a real database, the great majority of open budgeted hours live in a handful of projects that no longer move, or in templates. Removing them from the plan hides nothing: their totals stay displayed apart.

Why standard views. The analysis screens are Odoo's own, not a hand drawn dashboard. A component failure shows up in no server side test, whereas a standard view cannot lie about data the tests check.

What the module does not do. It does not compute a capacity: it asks for one. It does not ask you to date your tasks: it quantifies what is not dated. It estimates nothing on your behalf: a task with no estimate stays without one, and that is counted. It assigns nobody to anything: it is not a resource booking tool.

Troubleshooting#

See also#

• Project: the tasks and projects the plan reads.
• Timesheets: what was consumed, which the plan refuses to confuse with what is planned.
• Échéancier (Gantt): the start dates that spread the workload.
• Hour bank: the balances behind the third signal.