Tariff presets

A hall with four seat grades and three audiences offers twelve tariffs. A season of forty productions means typing those twelve rows forty times, and nothing in the module helped: cloning is switched off on every yoyaku entity, the venue package carries the hall's inventory but not its tariff setup, and the slot generator only seeds downwards from a production's own tariffs onto its slots.

A tariff preset (yoyaku_tariff_preset) is where those twelve rows are typed once. "Grille A" and "Grille B" then describe how a house prices a big production against a small one, and a gala offering fewer reduced seats is a quota on one cell rather than a manual edit repeated across every production.

A preset is a stamp, not a live source

Applying a preset copies its tariffs onto a production. Afterwards the production's tariffs are its own, and nothing reads a preset at booking time.

That is deliberate. No booking stores the price it agreed except the one it was booked at, and the effective price is otherwise derived live, including for orders that already exist: the order summary, the per-booking column, the amount the gateway is asked to charge, and the figure in notification emails all recompute it. A preset read live would let one edit rewrite what a week-old order says it cost, and change what an unpaid transaction is charged.

Copying is also what the engine already does one level down: a resource tariff's quota is copied into each new slot tariff at generation, never resolved at read time.

Nothing records which presets a production was stamped from. Storing that provenance would recreate the source-of-truth question this design exists to avoid: a resource tariff is simply a tariff, however it was typed.

What a preset holds

A preset carries a name, and holds one yoyaku_tariff per cell. A cell is the same shape as the resource tariff it becomes, because applying is a field-for-field copy:

Module	On the preset	On each tariff
yoyaku	tenant, key, label, weight	preset, key, label, tariff_class, quota, weight, booking_channels, allotment
yoyaku_placement	venue (0+)	grade (0+)
yoyaku_payment		price (required, 0 allowed), collect_mode, collect_value, noshow_fee

price is required because a resource tariff's price is required: a preset that left a cell unpriced would stamp out an invalid tariff. Enter 0 for a free cell.

Everything else is optional and copies as written, silence included: an empty collect_mode means the tariff it becomes inherits its resource, so a preset saying nothing about collection changes nothing. That is what makes it safe for the preset to carry the whole shape rather than only the price: a house that always collects its subscriber grid in full, or collects it at the box office only, says so once instead of once per production.

It also holds the numbers, not only the prices

A preset tariff pointed at an allotment says who draws on the schools. It never said how many places the schools get, so a season declared that by hand on every production it ran. A preset therefore also holds one yoyaku_preset_allotment per allotment: the allotment, how many places it holds, and how long before a slot the unbooked ones are released.

Applying stamps those onto the production as yoyaku_resource_allotment records, beside the tariffs. The offset travels and a date does not, which is why an allocation carries release_before and never release_at: a season says "release two days before" once, and a date belongs to one evening. Nothing here writes a slot's own record, so a slot departing from its production stays a manual exception, exactly as it is for a quota.

Empty and zero say different things and both survive the copy. Empty means the preset declares no number, leaving a placed allotment to hold whatever a pinning names for it; zero means the allotment holds nothing. Collapsing them would turn "no opinion" into "hold nothing", which is a decision nobody made.

Two kinds of preset, and nobody chooses a mode

Which kind a preset is falls out of whether its tariffs price place grades.

• Global: no venue named, no tariff prices a grade. An audience price list, adult 15 / child 8 / member 12, reusable across every venue and every unplaced resource in the tenant. This serves a refuge, a museum, a workshop.
• Hall-bound: one or more venues named, tariffs price grades. The twelve-cell grid for one hall, or one preset carrying a grid per hall and letting each production take its own.

A global preset stays applicable to a placed production, where it creates tariffs that price no grade, which is already legal.

Grades bind a preset to its halls, in both directions

Grade keys are only unique within a venue, so a house with two halls has two things called "Cat. 1", and a cell pointing at the wrong one is invisible afterwards. Four rules keep that from happening, all in yoyaku_placement because the venue and grade fields are its:

1. A preset holding any tariff that prices a grade must name at least one venue. Without this the next rule has an empty premise and fails open.
2. Every grade a tariff prices must belong to one of the preset's venues.
3. One tariff must not price grades from two venues. A cell spanning halls matches no production cleanly.
4. Applying offers only the tariffs whose grades belong to the production's hall. A tariff for another hall is listed as excluded with the reason, never silently dropped.

The halls are declared on the preset rather than derived from the grades its tariffs price, because declaring them is what scopes the grade checkboxes on each tariff: deriving would be circular, since the venues must be known before the grades can be offered.

A cell names grades by entity reference, exactly as a production's tariff does. Storing the grade's key and resolving it per hall would make one preset portable across halls, but real halls overlap only partly, so some cells would always resolve to nothing and the silent-skip path would be the normal case.

Applying a preset

From a resource's Tariffs tab, "Apply a preset". One screen, listing every tariff every applicable preset would write, so choosing and confirming are the same act.

Which presets appear. The global ones, plus those naming the production's venue. Each is a group headed with the number of tariffs it would contribute to this production, so a preset that names the venue but prices nothing for it reads as empty rather than broken. Several may be applied at once, which lets a house decompose its grids along the audience axis: a production offering no subscriber seats simply does not get that preset.

What each group holds. Two tables, because a tariff already on the production asks a different question:

• Tariffs to create, with the tariff's audience, quota, price and place grades, so a twelve-cell grid reads as a grid. The header checkbox takes or drops the whole preset in one click; any single row can still be selected on its own.
• Already on this resource, where selecting a row overwrites its price and quota. Left alone, a price typed on one production survives: it is a decision, and re-applying must not quietly discard it. Each row also carries the tariff's own Edit and Delete, so one that should not be on the production at all goes without leaving the screen.
• Allocations to create, and Already on this resource beside it, when the preset holds any. They ask the same two questions about numbers that the two tables above ask about tariffs: what to write, and whether to move a number the production already carries. Four tables rather than two merged pairs, because a row's checkbox owns that row's input path, so one table asking two questions makes its header checkbox mean two things.
• Anything the hall refuses is listed below with its reason as text.

Nothing is selected when the screen opens. Applying writes tariffs, so it asks first, and the group header makes "all of this preset" a single click. Choosing only allocations is a legitimate apply: carrying this season's numbers onto a new production without touching its prices is a thing an operator means to do.

Applying stays on the screen. What it just created moves into the table of tariffs already on the resource, so applying one preset and then another is two clicks rather than two round trips; Back to tariffs leaves. There is no separate save: applying is the write.

A resource that does not offer by tariff yet is offered the switch here, rather than having it set silently.

The screen also states how many of the production's slots are already open for booking. Courtesy rather than a guard rail: a booking stamps the price it was booked at, so overwriting a tariff changes what is offered from now on, not what an existing order says it cost.

Two presets naming the same key describe the same tariff, so applying both creates one. The first preset offered wins.

Applying never touches a yoyaku_slot_tariff. A per-slot override stays the most specific thing and always wins.

Tariff classes are the tenant's vocabulary

A tariff class is tenant-level, so the same "Full price" heads a preset's tariffs and every production's. Manage them under Booking > Tariff classes.