Piece Work

A new entry takes five fields: the employee (picked from your directory), the item or task, the quantity completed, the rate per unit and the date the work was done. Quantity and rate sit side by side, and beneath them the form shows the amount they imply, updating live as you type — a running preview of the sum the server will compute and round to two decimal places as the definitive figure on save.

The employee field is optional, so you can log work first and attach the person afterwards, and the date field lets you record work on the day it happened rather than the day it was typed in. Item or task and the two numbers are marked required on the form, so whoever is logging work is prompted for the figures that give the entry its value before it is submitted.

Entries land in a single register showing the item, the employee's name resolved from the directory, quantity, rate, the computed amount, the work date and a colour-coded status badge. Numbers are formatted for reading — thousands separators, the amount in bold — so a supervisor can scan a day's output down the page without opening anything.

Each row carries its own actions inline. A pending entry offers Approve and Reject; an approved entry offers Pay; a rejected or paid entry offers nothing further, because its journey is over.

Every entry starts life as pending. From there it can be approved or rejected; only an approved entry can be marked paid. These rules are enforced on the server, not just hidden in the interface — an attempt to pay an entry that was never approved, or to approve one twice, is refused outright with a message explaining which statuses the action accepts.

That server-side guard means the lifecycle holds even when requests arrive by other routes: there is no sequence of clicks or calls that produces a paid entry which skipped its approval.

The Piece Rates tab is your organisation's standing rate card: each record names an item or task, its rate per unit, the unit it is measured in, and an active or inactive status. Rates can be added and edited as prices are renegotiated, marked inactive when an item is retired, or removed from the card entirely when they no longer belong on it.

Because the rate on each work entry is entered explicitly, the rate card serves as the agreed reference the person logging work reads from, and the approver checks against, rather than a hidden default nobody can see.

Piece Work Settings records two payout policy choices for the organisation: whether approval is required, and whether piece-work is paid with payroll. Both are simple Yes/No selections, saved organisation-wide so everyone administering the module works from the same declared policy.

A second tab manages the unit list — the vocabulary of measurement your rates use. Add the units your operation counts in, from single pieces to dozens, and remove the ones you no longer use; the list is stored centrally with your organisation's other module configuration.

Piece Work is a tenant-scoped module: every API call resolves your organisation from the signed-in session, and every entry, rate and setting belongs to it alone. On the access side, the route is mapped to the Piecework module in the Role Templates catalogue, so a role granted nothing in that module simply does not reach the pages — the same permission-aware gating that protects the rest of the dashboard, applied to direct URLs as well as the visible navigation.