Rate resolution chain

What it is

The rate resolution chain is the order in which Syndik8 picks the per-hour usage rate a given member pays on a given asset. Three inputs feed it:

The asset’s base usage rate.
The rate modifier on the member’s member rate.
Any per-asset override that pins a specific rate for a specific scheme on a specific asset.

The chain runs highest precedence first:

asset-level override  →  scheme modifier on the base rate  →  base rate alone

Whichever step matches first wins.

Who can use it

Owner and admin — can set or clear each layer.
Treasurer (admin) — same.
Member — sees the resolved rate on the usage-log estimate and the finalised charge.

Where to find it

The resolved rate is surfaced automatically wherever a rate is shown:

Log usage (estimate).
Asset Billing settings → Rate table — admin view of every scheme’s resolved rate on this asset, with inline edit for the override layer.
Booking finalisation (charge preview).

The layers themselves live here:

Layer	Where it lives
Asset override	Asset Billing settings, rate table row
Scheme modifier	Settings → Billing schemes, scheme edit dialog
Base rate	Asset Billing settings, Usage rate field

Fields / options

There are no fields directly on this page — it describes the resolution order.

Behaviour rules

Step 1 — asset-level override (highest precedence)

For a given asset and a given scheme, if there is an asset-scheme rate override row with a usage rate, that rate is used. The asset base rate and the scheme modifier are both ignored. This is the mechanism for saying “members on the renter rate pay exactly £300+VAT/hr on the SR22, regardless of anything else”.

Step 2 — scheme modifier on the base rate

If no override exists, the member’s scheme modifier is applied to the asset’s base rate:

Modifier type	Effective rate
`none`	base rate
`fixed`	base rate + value (floored at 0)
`percent`	base rate × (1 + value ÷ 100), floored at 0
`override`	modifier value, floored at 0

See member rates for examples.

Step 3 — base rate alone

If the member has no scheme (edge case: very old memberships before schemes existed), the base rate is used unchanged.

When the rate is “frozen”

The resolved rate is computed at two points:

On the usage-log estimate — so the member sees what they are about to be charged.
On usage-log save — the resolved values are written onto the log as a snapshot. Finalisation uses the snapshot, not the current live values.

This means changing a scheme modifier or an asset override after a log is saved does not change the charge for that log. Only new logs pick up the new rates.

Negative modifiers never produce negative rates

fixed = -999 on a £180+VAT/hr base rate results in £0+VAT/hr, not minus £819+VAT. The rate is floored at zero at the point it is resolved.

Event fees resolve via a parallel, shorter chain

Usage rate has the three-step chain above. Event fees (landing fees, touch-and-go fees, any other configured counter fees) have a two-step chain with no modifier layer:

asset-scheme event fee override  →  asset's base event fee

If a (scheme, counter) row exists under the asset’s Event Fees overrides, that rate is used for that scheme. Otherwise the asset’s base event fee applies, the same as for any scheme without an override. An override of 0 waives the fee for that scheme on that asset; a missing row inherits the base fee. See member rates — Example 5.

Worked example

Base rate on the asset is £180+VAT/hr. Scheme modifier on the member’s scheme is percent = -25 (a 25% discount). An asset-scheme rate override exists pinning this scheme’s rate on this asset to £200+VAT/hr.

With override present → £200+VAT/hr (step 1 wins).
If the override is removed → £135+VAT/hr (step 2: 180 × 0.75).
If the member has no scheme at all → £180+VAT/hr (step 3).