--- title: Decodification Master description: The family's option menus — how a model number is built, segment by segment, and why a code is positional. sidebar: label: Decodification order: 13 --- Decodification is the **menu of specification options** for one family, and the rules that turn those choices into a Flowtech **model number** (order code). The composed number **is** the order code. There is no separate mapping from "configuration" to "something the factory understands". ## How a model number is built Take an electromagnetic flowmeter line: 1. Start with the group's **model prefix** (`FMIPL-VTFM`). 2. Walk each **coded position** in the master, in order. 3. Append that position's **option code** (`FT2`, `PC1`, `PCS1`, …). 4. Skip positions that do not apply to this order. The result is unique to **this quotation line**. A different lining tomorrow is a different string, still on the same item code. ```mermaid flowchart LR prefix["FMIPL-VTFM"] --> p1["Flowtube FT2"] p1 --> p2["Process connection PC1"] p2 --> p3["Connection size PCS1"] p3 --> rest["… remaining positions"] rest --> full["Full model number"] ``` ## Positions, not a bag of materials Option codes are **positional**. SS 304 on the flowtube is not the same code as SS 304 on the process connection: | Position | Code | Value | | --- | --- | --- | | FLOWTUBE MOC | `TS1` | SS 304 | | PROCESS CONNECTION MOC | `S1` | SS 304 | | COIL HOUSING MOC | `CH2` | SS 304 | A shared "SS 304" library entry can still carry the material's corrosion behaviour and price basis. The **code that prints on the model number** belongs to the position. Flattening codes across positions is how a product list stops matching the client's workbook. ## Headers that depend on each other A position can name two independent constraints against the header above it, in the same master — never one merged "depends on" setting: - **Gate** — ask this header only when its parent is actually in play. A transmitter's voltage is never asked on a line with no transmitter, and a gated-off header contributes no segment to the model number, the same as any other position that does not apply. - **Inherit** — take the parent's material and resolve to the matching code on this header's own position, never the parent's code (see "Positions, not a bag of materials"). Left open, inheriting follows whatever the parent resolves to; it can also be narrowed to specific parent choices. A header may gate without inheriting, inherit without gating, both, or neither — voltage-style headers gate on their transmitter without inheriting its material; MOC-style headers inherit without being hidden. One option on a header can also be marked **not applicable** — "Transmitter Not Required" rather than a real answer. A header gated on a parent needs that parent to carry one of these, or the gate can never fire. A position can also name which **enquiry conditions** — fluid, operating temperature, operating pressure, density — it should eventually be judged against. Nothing scores an option against them yet; naming them today prepares the ground for the rule engine that will (see [Limitations](/business/limitations)). ### Examples from live masters **Gate only.** The metal tube rotameter's `JACKETING MOC` carries a "Jacketing Not Applicable" option. `Jacketing Size`, `Jacketing Fluid` and `Jacketing Temp.` all gate on it. Pick a real jacketing material and all three ask; pick "Not Applicable" and none of them do — three fewer things to fill in, three fewer positions in the code. **Inherit only.** The electromagnetic flowmeter's `EARTHING MOC` is never gated — it is always asked. Its header is `EARTHING TYPE` (In-Built Electrode / Earthing Ring), and all that header decides is *when* the inheritance applies; what gets copied is `ELECTRODE MATERIAL`, a different row. Pick "In-Built Electrode" and Earthing MOC auto-fills to the same metal as the electrode, under its own code for that position. Pick "Earthing Ring" instead and Earthing MOC is asked on its own. **One answer, two positions.** The side mounted magnetic level indicator's `LEVEL TRANSMITTER DETAILS` (Transmitter Required / Not Required) gates `TRANSMITTER LENGTH` and `STEM MOC` together — one answer decides both at once. `SWITCH DETAILS` gates its own pair the same way: `SWITCH TYPE` and `HL`, the high-level trip point. The two pairs are independent: a line can have a transmitter with no switch, a switch with no transmitter, both, or neither. ## What a menu shows on a quotation Every choice is marked: | Marking | Meaning | | --- | --- | | **Allowed** | Nothing stated rules it out | | **Ruled out** | A stated requirement provably breaches a known rating, with the reason | | **Unconfirmed** | We could not check it — missing parameter, or no rating. Still selectable | **Custom** is never ruled out (R32). It is how an enquiry stays quotable when nothing in the menu survives. A menu where **every** option is ruled out is a line-level problem — this family is wrong for the duty — not an empty dropdown (R33). What the customer stated outranks family defaults (R34). A default filled over something they asked for is printed as a deviation (R35). ## Driver rows and how they're priced A row can be marked a **Driver** — it moves the quotation's price; a row that isn't has no price impact, whatever gets chosen there. Marking a row Driver saves immediately and says only *that* it prices. It says nothing about *how*. *How* is set per option, right here on the row: **Priced by…** on each of the row's options chooses a charge method — Per option, Per unit measured, Rate table (two axes), or Base variant — with a hint next to each option for what has been priced as of the row's own published version. Unlike Driver, a Priced by choice is part of the row itself: it takes a new published version to apply, same as any other change to a coded position (see Versions, below). The rupee amounts themselves are entered and kept in the [Pricing Library](/business/features/pricing-library), against whichever method was chosen here. ## Versions A published menu is **immutable**. Editing the master writes a **new version**. A quotation line pins the version it was built from, so a sent document never silently changes when applications engineering corrects a menu next month. The group's "current master" pointer is which menu new lines start from. Old lines keep the version they used. A group takes its first published master as that pointer automatically; once set, publishing another master for the same group does not move it. Saving a datasheet you have not changed records nothing — the version history only gains an entry when the menu itself differs. **Marking a header a Driver needs the header published first.** Price relevance is held against the group's current published version, not against your draft, so a header you have just added has nothing to attach to until you publish. The editor says so rather than appearing to accept the click. ## What the business does here - Maintain the blocks: which positions exist, which codes, which are defaults, which parts are wetted (the process fluid actually touches them). - Publish a new version when a datasheet or the product list changes. - Publish before setting price relevance on a new header. - Never edit a version in place — that would rewrite history on sent quotes. Related: [Item Group Master](/business/features/item-groups) · [Item Master](/business/features/item-master) · [Pricing Library](/business/features/pricing-library) · [Product suggestion](/business/features/product-suggestion) · [Setting up catalogue data](/business/workflows/setting-up-catalogue-data).