Setting up catalogue data
Creating an item group, its decodification master, a released item code, and pricing a driver row — in the order the product actually requires.
What this process achieves
A brand-new product family goes from nothing to quotable: a named family with its prefixes, an option menu that composes its model number, and one released size a quotation can actually pick.
Who is involved
Catalogue maintainers do all three creates. Today there is no separate
permission key for item groups or decodification masters — all three screens
sit behind the single item:* permission set (item:view / item:create /
item:edit) in the catalogue module. See Roles for
who holds it.
What starts it
A new family needs a catalogue entry, or an existing family needs another released size.
The steps
The product enforces a stricter order than “create three things”: an item group’s decodification master must be published before that group is offered anywhere an item code is released against it. Author the menu before the size, not after.
1. Create the item group
Master → Item Group Master → Add Item Group. Pick a category, name the
family, and set its prefix (starts the item-code series) and factor
(what the codes vary by — line size, pressure range, length, …). The model
prefix auto-derives from the prefix; edit it only if it should differ.
The new group appears with its decodification master marked Not authored and zero item codes — expected, since nothing has been built for it yet.
2. Author the decodification master
Master → Decodification Master → Add Master, pick the item group just
created (only groups with no current master are offered), name it, and
you land in the block editor.
Copy From is optional. Pick a published datasheet there and the editor
opens with a copy of its rows, options, letter codes and rules instead of an
empty draft. The name fills in as “
Every master starts with one implicit block — there is no “add block” control today, so everything is authored inside it. Import rows, above the row list, copies chosen rows from any other published datasheet onto the end of the draft; everything below applies to them just as to rows added by hand. Add row offers four kinds:
A Field row is answered as text, yes/no, a number, a range, or options — a list kept on its row-library entry. A Yes/No field’s default is picked from Yes or No, an options field’s from its list, and a text default can run over several lines. An options field is created from the Add row picker by choosing Options and typing its values; more can be added later from the row, and they reach every datasheet using that field.
A row whose row-library entry measures an operating temperature or pressure, such as Max Temperature, Design Pressure or Temperature Range, is read as that quantity on an enquiry under whatever name the datasheet gives the row: a figure in it counts as stated, so no ambient value is assumed beside it (R17).
Adding a Select row (searching the shared row library, or typing a new label to create one) opens it empty in the inspector on the right:
Options and positional codes. Every option comes from the shared option
library via From library; its code is auto-assigned (C1, C2, …) in
the order options are added to that row — there is no field to type a
custom code. This is what makes a code positional rather than global: adding
PTFE then SS 304 to Flowtube MOC gives SS 304 the code C2 —
— while the very same SS 304 library value, added as the first option on a
different row (Process Connection MOC), gets C1 there instead:
Inherit, without gating. A row’s “Parent header” names one sibling row under Depends on, and that one choice drives two independent things — Visibility and Material. Either can be used alone. Picking Flowtube MOC as Process Connection MOC’s parent and setting Material to “Flowtube MOC (itself)” makes this row’s material follow the parent’s, while Visibility stays on “Always ask this row.” The banner names any parent option this row has no matching option for yet:
Scoping the inheritance to one parent option reads back in plain language:
Visibility offers three choices, and which one fits depends on what the parent’s options mean.
The first names the parent and the option that hides this row — “Hide this row when Transmitter is ‘Transmitter Not Required’.” It cannot be picked while the parent carries no option marked “Not Applicable,” because a gate with nothing to fire on is refused when the version is published; a row that already holds it says so instead:
Marking the parent’s “not needed” option N/A is what lets that choice work at all:
Back on the gated child, the choice is available and spells out the option it fires on:
The second — “Show this row only when … is one of:” — names the parent choices this row applies to, as a chip per option. Use it when the parent’s options are real alternatives rather than a yes/no, and each alternative needs its own row: two rows on one parent, each naming a different choice, are asked one at a time. It needs no “Not Applicable” option, and a row may name several choices, not just one:
On the parent, the options list then shows the branch map — which rows each choice brings into play — and warns about a choice no row covers, which otherwise shows up only as a model number a position short.
The third, “Always ask this row,” leaves the link doing nothing on its own. A parent picked under Depends on with Visibility left there and Material left on “Ask independently” does nothing at all; the editor says so beneath the two, rather than leaving the link reading as live.
Process factors name the enquiry conditions a row’s options are judged against. They come from the row library’s list of process variables:
- Size, in NB;
- Fluid Type — Solid, Liquid or Gas;
- Operating Pressure and Operating Temperature;
- Flow Range and Operating Flow;
- Density and Specific Gravity / Density;
- Viscosity, Conductivity and Pressure Range.
Typing a name that is not on the list offers to create it. You choose whether it is answered as a range, a number, yes/no, or options (with the list of values), and its unit, and it is then offered on every master. Typing the name of an existing library field (Jacketing Size, say) offers to use that field as a process factor instead of making a copy; a text field cannot become one. Factors typed before the list existed still show on their rows, marked legacy.
Each option can then state its hard limits — the conditions it can work in (R62). For a number or range factor, that is either an exact value or a min–max band: filling one side greys out the other, and a band may have one end only (Conductivity “min 5” means at least 5). A yes/no factor takes Yes, No or Either. An options factor such as Fluid Type shows one chip per value, and each option turns on the values it suits — FLANGE TAP DEGREE’s 90° option takes Gas, its 180° option Liquid. Add value beside the chips adds a new value (Steam, say) for every datasheet that uses the factor; values cannot be removed or renamed from the app. An enquiry whose answer falls outside an option’s hard limit, even partly, never gets that option, unless a requirement line asks for it and the answer is only assumed, or a library value of a fluid no person has confirmed, which warns (R62).
Which allowed option becomes the default is set in the header’s Conditional defaults section: ordered rules, each with one or more conditions on the header’s factors and the option it picks — “Pressure −0.99 to 1 bar, then default to PFA”. The first rule the enquiry meets, whose option is still allowed, wins (R63); the arrows reorder rules. The line under them says what applies when no rule matches: the “Decided by” default when a mapping sets the header, otherwise the header default. A rule warns when its band falls wholly outside its option’s hard limit, since it can never apply, and notes when it picks the header default with no mapping in play, since it then changes nothing.
When the header’s Default option does not suit a value of an options factor
and more than one other option does, the value needs a rule of its own (R61).
The section opens with a note naming each such value — Fluid Type = Solid suits 3 options and not the default — and its Add rule starts a rule for
that value. With SS 304 (Liquid, Gas) as the default and CS 105, SS 316 and
Custom all taking Solid, one rule for Solid is needed, while Liquid and Gas
need nothing. Publishing is refused while any such value has no rule.
Publishing. A master’s blocks are immutable once published — editing them
again always writes a new version, reviewed as a diff before it is confirmed.
A metadata-only edit (name, active) saves immediately with no new version.
The diff names each changed option’s default, N/A mark, pricing and process
factors — Fluid Type: Liquid → Fluid Type: Liquid, Gas — and a header’s
process factors by name.
The first master published for an item group becomes that group’s current master. Publishing another master for a group that already has one does not move the pointer.
3. Release an item code
Once the group has a current master, it is offered in Master → Item Master → Add Item:
Pick the item group, name the variant (DN50, a pressure range, …), and fill
in classification. Item code and model number both auto-compose from
the group’s prefixes — item code from the prefix plus the next serial, model
number from the model prefix plus whatever the row defaults resolve to. HSN
is required once Goods Type is Finished.
4. Price a driver row in the Pricing Library
Pricing is not part of the group-before-master-before-code sequence above — a row can be marked Driver and priced whenever it is ready, before or after items are released against the group. A menu with real material choices does not price itself: mark the row that should move price, choose how each option is charged, then hand the actual rupee figures to the Pricing Library.
Marking Driver reveals a Priced by… control per option. Opening a select row — here, Flowtube MOC on the Guide Demo Flowmeter family used throughout this guide — shows a PRICE control that starts with no price impact:
Switching it to Driver saves immediately, and a Priced by… selector appears next to every option on the row:
Four charge methods, chosen per option, not per row — the same row can charge one option a flat amount and another by size:
PTFE is set to Fixed amount (a flat figure) and SS 304 to Rate table (two axes) (one figure per size). Unlike marking Driver, a Priced by choice is part of the row itself — it takes a new published version, the same as any other coded-position change:
Entering the actual rupee amounts can happen in the Pricing Library, or
in a Pricing section right on the row in Decodification Master — this
walkthrough uses the Pricing Library. Master → Pricing Library, open the
priced value, and its By item group list shows every group that uses it.
A group with a driver row newly published but nothing priced yet reads
“Nothing to price at this version”:
Entering ₹450 against PTFE’s Fixed amount field prices it for every size at once:
SS 304’s Rate table renders as a grid instead — rows are the item group’s driver rows, columns are its released sizes (here, just DN50, from DEMO-0001 above). Clicking an empty cell opens a small amount field:
Saving it turns the group’s price-coverage badge from 0/1 priced to 1/1 priced:
Price coverage, back in Decodification Master. Toggling Show price info in the block editor adds a coverage bar across the whole master — how many rows are drivers, inert, or still unreviewed:
What the business does here
- Name the family, author its option menu, then release sizes against it — in that order; the product will not let a size skip the menu.
- Keep codes positional: the same material can print a different code on every row it appears on, by design.
- Never edit a published version in place. A correction is a new version, reviewed before it goes live.
- Mark a row Driver and choose each option’s charge method before it can be priced at all; enter the actual rupee figures in the Pricing Library, or in the row’s own Pricing section in Decodification Master.
- A row authored or re-based this session needs publishing before its price can be set, whichever screen you set it from; a row you haven’t touched this session prices immediately.
Rules that apply
R32–R35 govern how this menu is later shown and resolved on a quotation line. R59 governs how a saved price is overwritten (latest entry wins, no approval). The group-before-master-before-code sequence itself is enforced by the product (confirmed directly against the running app while writing this guide) but is not yet a numbered rule in Business rules — worth closing that gap the next time this area changes.
Related: Item Group Master · Item Master · Decodification Master · Pricing Library.