The calculation rules screen

Every other screen in CCC displays what the pipeline produced. This one configures it. A rule here decides which transactions get an impact, how large that impact is, and which account it books to, which is what every margin figure is made of.

What the rules mean is calculation rules. This page is what the screen does.

The list

One row per rule, with its name, whether it is activated, the transaction type it targets, the account it books to, and that account's account group with the technical key the impact table is named after. The technical key is worth reading: it is what tells you which of cm_impact_revenues, cm_impact_cogs, cm_impact_voc or cm_impact_vmc the rule writes into.

The detail view

/contributionmargin/calculationrules/detail/<id> is one rule, in five sections, each edited separately:

The detail view also counts how many impact rows the rule has already produced, per impact table, so you can see whether a rule has ever done anything before changing it.

Which edits change stored figures

Editing basic settings deletes the rule's existing impacts. Changing the transaction type or the account would leave impacts booked under the old answer, so the screen removes them rather than leaving a mix. It also switches the rule off, so nothing is recalculated until someone deliberately activates it again.

Saving activation queues, then deletes. The screen works out every day in the activation window, capped at today because a rule cannot be applied to the future, and queues one calculate batch per day for that rule's transaction type. It then deletes every impact the rule has ever booked, across every impact table and regardless of date, so the window it no longer covers is cleared as well as rebuilt.

It reports how many days it tried to queue, how many were actually queued, and the first and last date, on the redirect. Fewer queued than attempted means those days were already in the queue: setbatchtodo() dedupes per type and settings.

There is a gap in that pair, and it matters when you shrink a window: the deletion reaches every date, while the re-queue reaches only the new window, so the per-order totals outside it keep the old figure. See recalculate margin.

A long window is a lot of batches. A rule spanning several years queues a batch per day of it.

Filter and impact edits do not queue anything by themselves. They change what the rule will do the next time its days are calculated. To apply them backwards, save activation over the window you want rebuilt.

Preview

The detail view accepts transaction ids and shows what the rule would do to each of them, resolving the ids through the model for that rule's transaction type. It computes and displays; it stores nothing. This is the way to check a filter before putting a rule live.

Where to look next

Related

• Calculation rules
• Configure a calculation rule
• The impact screen
• Accounts

Evidence

Sections, actions, the impact delete on a basic edit, the day-by-day re-queue with its today cap and its reporting, and the preview resolving ids per transaction type, all from app/http/contributionmargin/calculationrules.php. The impact row count per table from the same file's detail case. Columns from templates/main/contributionmargin/calculationrules.tpl. Dedup on queueing from app/models/batches.php. Basis: code-checked at 30f5313.