Decodification Master

The family's option menus — how a model number is built, segment by segment, and why a code is positional.

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-EMFM).
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.

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:

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 names one header above it as the one it depends on, and that one choice drives three constraints that are set separately and mean different things. For how these combine with hard limits and conditional defaults, and the order they apply in, see How answers are decided. The three are:

• 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. The editor sets this under Visibility, which offers two ways of saying when a header is in play: hide it when the parent is not applicable, or show it only for named parent choices.
• 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. The editor sets this under Material.
• Decides — answer this header from one or more other headers’ choices, where they are different questions rather than the same material. Mounting style decides wiring type; cage material decides how the scale is marked. The editor sets this under Allowed answers, as one mapping per allowed answer, read as IF the deciding header is one of the chosen choices, THEN this row answers the chosen answer. Several choices may lead to one answer, which is what the other two cannot express — they match a single parent choice to a single outcome. Add condition puts an AND line between the two, naming another header and its choices, and the mapping then applies only while all of them hold. A saved mapping that gains an unfinished condition — one naming no choice yet — is left out of the next published version and shown as removed in the publish review, so finish the condition or remove it before publishing. A mapping never published is simply not part of any version until it is complete.

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. Naming a parent and setting neither is legal and does nothing. “Decided by” is set independently of all three, and may name a different header again.

A mapping names an allowed answer for its deciding choices (R60). A choice one mapping names — or, where a mapping has AND lines, a combination of choices — allows that answer only, and fills it in. A choice or combination several mappings name allows each of their answers, and exactly one of those mappings is marked Default — that answer is filled in, and the others stay on the menu. A choice or combination no mapping names leaves every answer open and falls through to the header’s own default. The editor says which choices of the deciding header no mapping names, and which choices or combinations have several answers but no single default; publishing is refused until each of the latter has exactly one. When a header’s mappings together involve too many combinations to check (more than 10,000), publishing is refused until some conditions are removed.

For example, FLANGE MOC decided by IBR TYPE: Non-IBR allows CS and SS 316 with CS marked Default, and IBR allows CS only. The datasheet defaults to Non-IBR, so its default configuration takes CS, and an item code released as IBR cannot choose SS 316.

A released item code keeps whatever it was released with until it is next edited; saving it then refuses an answer its mappings no longer allow.

One option on a header can also be marked not applicable — “Transmitter Not Required” rather than a real answer. A header gated the first way needs its parent to carry one of these, or the gate can never fire.

Naming parent choices is what splits one header between several. “Not applicable” is a property of the parent’s option, so every header gated that way shares one condition: they all appear together, or none does. When a parent’s choices are real alternatives rather than a yes/no — and each alternative needs its own header, because the prices differ — each header names the parent choices it applies to instead. A header may name one choice or several, two headers may name the same choice, and a parent may be split three or four ways rather than two.

Two limits are worth knowing. There is no “any other choice” catch-all: a header applies to the choices it names and nothing else, so adding a new choice to a parent asks nothing extra until some header names it. The editor says so on the parent, listing which header each choice brings into play and warning about a choice no header covers. A header still gates and inherits from exactly one parent; a “Decided by” mapping is the way to make it depend on two headers together (see “Two headers together” below, and Limitations).

A position can also name which enquiry conditions — fluid, operating temperature, operating pressure, density — its options are judged against. An option’s hard limits and conditional defaults are read against the conditions its position names, as described below (Limitations says how far that reaches).

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 parent, two branches. IBR TYPE (IBR Approved & Certified / Non-IBR Certified) is not a yes/no: both are real answers, and flange materials are priced differently under each. So the flange material is two headers — one naming the IBR choice, one naming the Non-IBR choice. Whichever the customer picks, exactly one of the two is asked and only that one puts a segment in the model number, which is why the code is a position shorter on one branch than the other. Neither IBR TYPE option is marked “not applicable”: both are answers, and marking them so would hide both flange headers on every line.

Decides only. The tubular level indicator’s CAGE MOC decides SCALE MOC, and the two are not the same question — one is a metal, the other is how the scale is marked. MS takes an acrylic scale mounted separately, because corrosion on MS would spoil a scale marked straight onto the cage; SS 304, SS 316, PP and PTFE all take the scale engraved directly. That is two mappings over six choices — one naming MS, one naming the other five — and it is the case neither Gate nor Inherit reaches, since five different cage materials lead to one scale answer.

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.

Two headers together. A “Decided by” mapping can require more than one header at once. Take a header whose lining follows two others: when both Inlet lining and Outlet lining are Rubber, Body lining is Rubber. The mapping reads IF Inlet lining is Rubber, AND Outlet lining is Rubber, THEN answers Rubber. Only the pairs a mapping names are decided; any other pair leaves Body lining on its own default. A pair can allow two answers, one marked Default — Rubber and PTFE, Rubber the default — and a mapping for the pair alone can sit beside a broader one for the first header alone: where both apply, their answers are both allowed and one is the default. Publishing is refused until each such pair has exactly one. (An illustration, not a live master.)

What a header’s description is for

Each header carries a description, behind its info button in the editor. Requirement gathering goes by it: each value a client states is placed in the header whose name, description and choices fit it. A header with no description is read from its name alone, and a description that contradicts its choices sends values to the wrong header.

Say what the header holds, the client’s words that belong in it, and where a close neighbour’s values go instead. A header that switches others on (a gate) also says which wording turns it on: on the orifice plate, flanges, WNRF or weld neck flanges, an orifice flange assembly or an orifice set make Orifice Flange Assembly Details Required, and the plate alone is the default. A note for whoever edits the datasheet, such as “Remove in PP”, is read as meaning, so it belongs elsewhere. Reading takes the first 240 characters. A few common headers, such as process connection type and isolation valve, carry a description FlowOS sets itself, which replaces the datasheet’s.

What a menu shows on a quotation

Every choice is marked:

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).

One default per menu

A menu marks at most one option as the default. Picking a default clears whichever option held it before, and picking the current default again leaves the menu with none — which is allowed, and means the row is answered per line instead of falling back to a house choice.

Publishing a master is refused while a menu marks two, naming the rows to fix — unless a rule decides that row, in which case two defaults are exactly right and the rule picks between them. A component list is the other exception: it supplies several parts at once, so every part marked default is included.

A handful of masters authored before this rule still carry two defaults on a row. They keep working as they are; the editor flags them, and the next publish of that master is where the choice has to be made.

The order of a menu

Options appear in the order they were added. To change it, drag an option by the grip at the left of its line. From the keyboard, focus the grip, press Space or Enter to pick the option up, move it with the arrow keys, and press Space or Enter again to drop it (Escape cancels). A menu with a single option has no grip. The order is only how the menu reads: an option’s code, its default and its price do not change when it moves, and neither does the model number.

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 — Fixed amount, By parameter, 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, against whichever method was chosen here — or right here, in a Pricing section under the row’s own options, for any select or components row whose options are library-linked. Both routes write the same figure; the Pricing section is the shortcut for setting a price while you’re already choosing how it’s charged, not a second record of it.

Hard limits and conditional defaults

A process factor relates an option to an enquiry condition in two different ways, and a band can be either:

• Hard limit — the range an option can actually work in. Outside it the option is not usable, even when the customer asks for it by name. Set per option, under Hard limits (“Outside this, the option cannot be supplied”).
• Conditional default — which option is picked when nobody asked. Set per header, as an ordered list of rules under Conditional defaults: each rule names one or more conditions on the header’s process factors and the option it picks when they’re met, tried top to bottom until one fires. A rule never rules an option out — the option it doesn’t pick stays choosable on request.

Take an electromagnetic flow meter’s Lining header. PFA lining only survives −1 to 2 bar, so that’s its hard limit. Below that, three conditional defaults decide what’s picked when the customer hasn’t chosen a lining:

1. Pressure −0.99 to 1 bar → PFA (its low end covers vacuum service).
2. Size 15–80 NB → PTFE.
3. Size 100–2000 NB → Rubber.

An enquiry at −0.5 bar gets PFA — it fits PFA’s hard limit and meets the first rule. One at −0.5 to 5 bar cannot have PFA at all, since part of that range falls outside PFA’s hard limit; the rule is skipped and the next one that still fits decides instead.

A note at the top of the header’s Conditional defaults section names any options-factor value the header’s default doesn’t suit, where more than one other option does — Solid, say, when the default only suits Liquid and Gas — with Add rule for each, since one of those values needs a rule before the datasheet can publish (R61). A rule can also warn that it can never fire, when its own band falls entirely outside its option’s hard limit.

Previewing the price

Preview in the editor’s header, and the eye button on the Decodification Master list, show a datasheet the way a configured enquiry would see it. The editor previews the draft; the eye button previews the published version, with the datasheet’s rows and options on a second tab.

Enquiry conditions has one answer per process factor the headers are judged against (Fluid Type, Size, …) — a band factor takes a min and a max, not just one figure. A requested option that fails its hard limit is dropped, and every such conflict is listed together under the conditions — “PFA requested; outside its Pressure limit of −1 to 2 bar at 5 bar”. Any header left without a request runs its conditional defaults in order, then a mapping’s default, then the header’s own default, picking the first option still allowed. Leave a condition on Any to ignore it.

Price build-up has one column per item code in the group. The unit price is on top, then one line per Driver row with its chosen option and what that option adds at each size, then the total: unit price plus add-ons. A Base variant option reads No add-on — already in the unit price.

Specification lists every other row under its section.

Someone without pricing access still gets the preview, without the price build-up: every row sits in the specification, and the conditions and answers work the same way.

The preview is for comparing, not editing: field values are shown as they stand, and only menus and conditions can be switched. Each switch runs the datasheet’s own logic again: Decided-by mappings narrow the answers a row offers (marked narrowed), parent-header gates show or hide rows, and inheriting rows copy their material again. Nothing is saved, and Reset to defaults clears every answer.

Prices come from the last published version, so a datasheet that has never been published shows no prices. When a Driver row has no price (no option chosen, no price set, no rate for some sizes, a charge method not yet published, a quantity needed), a note above the table names the row and the reason, and each total that leaves it out carries a *. A missing price is never counted as zero.

Downloading the price sheet

The eye button’s view of a family’s current master has Download price sheet beside its title: the same PDF price list the family’s item group view downloads, built from the published version. On an older master, or one never published, the button is disabled and says why. The editor has no download, because a draft is not what the sheet prices.

Operating conditions

Every datasheet opens its OPERATING CONDITIONS heading with the same rows, in this order:

The IoT device and the orifice flange assembly, which is quoted with its orifice plate, carry none of them, and the manometer carries no flow rows. Other rows a product needs under the heading, such as density, viscosity or a transmitter’s own pressure range, follow these. An instrument’s own rating, such as a sight glass’s maximum pressure, is a Rated Maximum Pressure or Rated Maximum Temperature row elsewhere on the datasheet: Maximum Pressure and Maximum Temperature always mean the client’s process.

The assumed conditions, design values, product checks and quotation figures read these rows (R17, R65, R68, R87), so add them from the row library when building a datasheet. A row created under another name is not read as the same condition.

From draft to published version

Edits stay in a draft inside the editor until you publish. Publishing checks the draft first, and nothing is saved if the check finds issues.

Versions

A published menu is immutable. Editing the master writes a new version. An issued quotation keeps each line’s order code, positions and wording as they were, so it never silently changes when applications engineering corrects a menu next month; a draft is rebuilt from the current menu on every view.

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.

Setting a price is held to the same rule, row by row. A price is recorded against the group’s current published version too, so a row you have just added, or changed, in this session has nothing published to record a price against yet — its Pricing section says “Publish to price” until you publish. A row you have not touched this session is unaffected: it prices immediately, whatever else is still in draft elsewhere on the datasheet.

Deleting a datasheet

The bin icon on the Decodification Master list deletes a datasheet, for anyone allowed to delete catalogue items. It is refused while any item code was released against the datasheet: those codes were built from it, so it stays and can only be archived (turn Active off in the editor).

A datasheet no item code uses can be deleted. The confirmation says what goes with it: every published version, every price recorded against them, and, if it was its item group’s current datasheet, the group’s link to it and the group’s record of which headers drive price. The group can then be given a new datasheet from scratch or as a copy.

Copying and importing

Most datasheets are close to one that already exists, so a new one rarely has to start empty.

• Start from a copy. When adding a master, Copy From names a published datasheet. The editor opens with its current version’s rows, options, letter codes and “Decided by” mappings, all editable.
• Import rows. Inside the editor, Import rows picks rows from any other published datasheet, a block or a single row at a time, and adds them to the end of the draft. Their positions in the model number follow on after the rows already there.

Either way the copy is a draft until you publish, like any other edit: closing or refreshing the editor first discards it.

What comes across, and what does not:

A row whose key is already used in the draft is renamed as it comes in; the import list says which ones before you confirm. If you then remove the row that held the key before you save, the copy takes the key back when you save, unless you have already set its price relevance. So does a row added from the row library, or a measure field added in the editor, under a taken name. It then counts as that row for the family: it keeps the row’s price relevance, and each option keeps the price the last published version had for the same option and charging basis. A key that a published version already uses is never changed, so a key published with a number on the end, such as c-c-height-2, keeps it. A row that depends on a row you have not ticked — its parent, the row it takes its material from, or the length field an option is priced by — is flagged there, with a link to include that row. Without it, a per-unit option is measured against its own row instead. Price relevance is copied only onto headers not yet reviewed in the new family, so nothing already decided is overwritten.

Same concept, different key

Every header has a key, the short name an enquiry’s reading, a rule and a price use to find it. A header picked from the row library stands for that library entry, and the families of one category are read best when each entry sits under one key across them: Process Connection Size as process-connection-size on every level gauge, not process-connection-size-2 on one of them.

Each save that publishes rows checks the datasheet against the other active families of its item category, at their current versions, and lists what it finds under Same concept, different key at the foot of the editor. Each warning names the other families as “Full name (PREFIX)” and this one as “this datasheet”, and Show jumps to the row. The warnings never stop a publish: the version is saved either way.

The editor cannot change a key once a row has one, since rules, prices and copied mappings point at it. To settle a warning, decide which key the category should use and ask engineering to correct the rows that differ; to settle a split, decide whether the concept is a field or a menu. Until then, quoting works as it does today. The editor checks only the datasheet being saved, so a category’s older splits show when each family is next saved.

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).
• Start a new family’s datasheet from the closest existing one, then price its options — prices never come across with a copy.
• Publish a new version when a datasheet or the product list changes.
• Publish before setting price relevance on a new header, or before pricing a row you have just added or changed this session.
• Never edit a version in place — that would rewrite history on issued quotes.

Related: Item Group Master · Item Master · Pricing Library · Product suggestion · Setting up catalogue data.