Level 2 — print options and print pricing.

Two feeds: what can be printed, where and how large; and what that print costs at each quantity.

Level 2 is what makes decoration pricing computable, so a distributor's customer can configure a print and see a real price instead of waiting for a quotation. It unlocks TronCalculator.

Every rule has to be expressible as columns. A condition written as a sentence cannot be evaluated and is discarded rather than interpreted — §3.0 is the clause to read before you export anything.

The Level 2 checklist

Document: SPEC-L2-002
Revised: 8 September 2026
Depends on: Level 1

§1.0

What has to be true first

Requires Level 1

Transport, formats and identifiers

Level 1 is activePrint options join to product models by ModelCode. An unresolved code is rejected with E-301.
Your print positions have a stable code eachPositionCode is immutable and is consumed by Levels 3 and 4.
Your techniques map to the six accepted valuesListed in §2.0. An unknown value is dropped with W-311 rather than rejected.
Both feeds follow the shared transport and encoding rulesREF-FMT-010 governs anything this document does not state.

Level 2 can be positions without pricing

Submit print options and no pricing layer and the calculator stays unavailable — but Levels 3 and 4 can still consume the position data. It is a legitimate way to reach logo visualisation without digitising a price list first.

§2.0

Print options fields

Field	Type	Required at	Constraint
ModelCode	string	L2	Must resolve against the Level 1 product feed.
PositionCode	string	L2	A named position — CHEST_L, BACK, SLEEVE_R. Immutable, because Levels 3 and 4 consume it.
TechniqueCode	enum	L2	One of SCREEN, DTG, EMBROIDERY, PAD, TRANSFER, ENGRAVING. An unknown value is dropped with W-311.
MaxAreaCm2	decimal	Recommended	The maximum printable area at this position. Required for Level 3 overlay validation.
MaxColors	integer	—	Applies to screen and pad print. Ignored for full-colour techniques.

One row per combination

One row per ModelCode, PositionCode and TechniqueCode. A position may repeat across techniques; the combination has to be unique.

§3.0

Print pricing fields

Field	Type	Required at	Constraint
TechniqueCode	enum	L2	Must appear in the print options feed.
QtyBreak	integer	L2	50, 100, 250, 500, 1000. Strictly increasing per technique and colour count.
UnitPrice	decimal	L2	The price per unit at that break. Net, two decimal places.
Currency	ISO 4217	L2	One currency per feed.
Colors	integer	Conditional	Required where the technique is colour-priced. It defines a separate price curve per colour count.
SetupFee	decimal	—	A one-time cost per colour or per screen. Defaults to 0.
HandlingFee	decimal	—	A fixed surcharge per order line. Defaults to 0.
MinQty	integer	—	The minimum order quantity for the technique. Must be at or below the lowest QtyBreak.

Every price must be derivable from the columns alone

A condition expressed as prose — "25% surcharge for metallic, negotiable above 1000 pcs" — cannot be evaluated and is discarded rather than interpreted. If a rule cannot be written as quantity, technique, colour count and surcharge, it is not a rule the calculator can apply, and the quotation it produces will be missing it.

§4.0

Validation rules

Rule	Code	Outcome
A PositionCode is never priced	W-320	The position is accepted but not quotable. Every position needs at least one pricing row to be offered.
QtyBreak does not increase	E-204	Row rejected. Breaks must strictly increase per technique and colour count.
MinQty is above the lowest QtyBreak	E-205	Row rejected — the lowest break would be unreachable.
An unknown TechniqueCode	W-311	The value is dropped and the row accepted. The position stays available for its other techniques.
A pricing row with no matching option	E-302	Row rejected. Pricing cannot exist for a technique that is not offered at any position.
Colours omitted on a colour-priced technique	E-121	Row rejected. The price curve would be ambiguous.
MaxAreaCm2 missing on a position used at Level 3	W-321	Level 2 is accepted; Level 3 overlay validation for that position is skipped.

§5.0

Options and pricing for one model

Level 2 · Two positions and one techniqueprint.jsonJSON

{
  "ModelCode": "POLO-CLASSIC",
  "positions": [
    { "PositionCode": "CHEST_L", "TechniqueCode": "SCREEN", "MaxAreaCm2": 100, "MaxColors": 4 },
    { "PositionCode": "BACK",    "TechniqueCode": "SCREEN", "MaxAreaCm2": 600, "MaxColors": 6 }
  ],
  "pricing": [
    { "TechniqueCode": "SCREEN", "Colors": 2, "QtyBreak": 50,  "UnitPrice": 1.80, "SetupFee": 25, "Currency": "EUR" },
    { "TechniqueCode": "SCREEN", "Colors": 2, "QtyBreak": 250, "UnitPrice": 1.20, "SetupFee": 25, "Currency": "EUR" }
  ]
}

The nesting is for readability and is not required. Flat CSV and XML equivalents carry the same fields, one row per record.

Send the source, not the export

A PDF price list can be parsed, but conditional rules written as prose are lost on the way. The spreadsheet your team maintains internally — however messy — keeps the logic, and the logic is what §3.0 needs.

What goes wrong at Level 2