Type Code Rules

Type Code Rules

A rule describes how one family of type codes is built, so the app can decode any code in that family into a product. You create a rule once, publish it, then parse codes against it. New here? Read Type Code Overview first.

Open Type Code → Rules in the left menu, then Create Rule. A five-step wizard walks you through it: Define Scope → Verify Segments → Name Segments → Interpretation → Map & Save. A progress bar at the top shows where you are, and you can click back to any completed step.

Throughout this page we build one rule for a pump family whose codes look like NW-4021-P075-U3, so you can follow a single example from the first step to the last.

---

Step 1: Define Scope

What you are doing: naming the rule and showing the app real examples so it can work out the segment pattern.

How:

Field		What to enter
Rule name	*	A unique name for this code family.
Description		A short note on what it covers.
Example Type Codes	*	Paste 2 to 5 real codes, one per line.

Then click Continue.

Example: name the rule NW pump codes, and paste three real codes:

NW-4021-P075-U3
NW-4021-P150-U3
NW-4055-P075-U1

Hint: vary the examples. Codes that differ in each segment help the app find the boundaries. Three or four is plenty.

---

Step 2: Verify Segments

What you are doing: checking that the app split the codes in the right places before you build anything on top.

How: the app lays the detected segments out in columns across your examples. Read down each column and confirm it holds one real part of the code. If a boundary is wrong, fix it here: Add Part adds a segment, and you can split one that was joined or merge two that were split. A warning appears when a column does not line up cleanly across the examples.

Example: the app detects four segments and they line up:

	Seg 1	Seg 2	Seg 3	Seg 4
NW-4021-P075-U3	NW	4021	P075	U3
NW-4021-P150-U3	NW	4021	P150	U3
NW-4055-P075-U1	NW	4055	P075	U1

If it had wrongly read P075U3 as one column, you would split it into P075 and U3 here.

Hint: if a column looks wrong, it is usually because the examples are too few or too alike. Adding one more example in Step 1 often fixes the detection.

---

Step 3: Name Segments

What you are doing: giving each segment a name and saying what kind it is, so the later steps and reports read clearly.

How: expand each segment and set:

Setting	What it means
Name	A readable label, e.g. Voltage Rating.
Fixed	A constant part of the code, like a separator or a class letter.
Dynamic	A part that varies and carries information (voltage, power, size).
Value Prefix	If the app detected a prefix (yellow banner), Accept it. The prefix is stripped before the value is read, so P075 is read as 075.

The first fixed segment becomes the Rule Identifier, the value the app checks to decide this rule applies to a code. A green panel shows the resulting identifier prefix.

Example:

Segment	Name	Kind	Prefix
NW	Series	Fixed (so it becomes the Rule Identifier)	—
4021	Model	Dynamic	—
P075	Power	Dynamic	Accept P so the value read is 075
U3	Voltage	Dynamic	—

The identifier panel now shows the prefix NW: codes must start with NW for this rule to apply.

Hint: name segments the way you say them out loud. Those names are what you connect to product fields in Step 5.

---

Step 4: Interpretation

What you are doing: telling the app how to turn each dynamic segment's text into a real value.

How: for each segment pick an Interpretation Type, and add a Unit or Default Value if useful.

Type	What it does
Direct	Use the value as it is.
Lookup Table	Map the value to a label through a table. New Table builds one without leaving the wizard.
Formula	Compute from the number, using value as the variable and basic arithmetic only (+ - * / and parentheses).

Unit appends a physical unit. Default Value is a fallback shown when a lookup misses or a formula cannot be computed (Lookup and Formula only).

Example:

Segment	Type	Setup	Result
Model	Direct	none	4021 stays 4021
Power	Formula	expression value / 10, unit kW	075 becomes 7.5 kW
Voltage	Lookup Table	a table mapping U1 → 230 V, U3 → 400 V, unit V	U3 becomes 400 V

Hint: use Lookup for a fixed set of options, Formula only for a straight calculation, and Direct for anything that is already the value you want.

---

Step 5: Map & Save

What you are doing: connecting the decoded values to a real product, checking the result, and saving.

How: on the "Map to a Product Type and save" step:

• Base Product Type: the product every parsed variant copies its shared data from (images, classifications, markings). Pick the one that represents this family.
• Nameplate Field Sources: choose which segment feeds each identity field: Order Code, Designation, Family, Variant and Article Number.
• Technical Data Template: the template the parsed products use for their specifications.
• Submodels to include: which parts of the AAS the parsed products carry.
• Rule Summary shows everything the rule will do, and Test Parse decodes one example so you can confirm before saving.
• Save creates the rule as a Draft.

Example: pick the base product NW pump (base). Map Order Code to the whole code, Designation to the Model segment, and leave the others as they fit. Assign your Centrifugal Pump Template. Click Test Parse on NW-4021-P075-U3 and confirm it shows Power 7.5 kW and Voltage 400 V. Then Save.

Hint: always run Test Parse before saving. It is the quickest way to catch a wrong formula or a mis-mapped field.

---

After saving: publish the rule

A new rule is a Draft and parses nothing yet. Its detail page shows a draft banner with a Publish button.

Publishing is gated. The rule must have example codes, named segments, a pattern and a base product type, and its examples must actually decode. If anything is missing, the app lists all of it at once. Once published, the rule is live and you can parse codes against it (see Parse a Type Code).

---

Editing, versions, retiring and deleting

• A published rule can be corrected in place. If it has already parsed products, editing prompts you to edit in place, make a new version, or cancel.
• After a correction you can re-parse the codes the rule already handled, so existing products pick up the fix. Re-parsing previews before it changes anything, and never touches a product's order code, company, images or hand-made edits.
• Retire a rule to switch it off while keeping its history. The list hides retired rules behind a Show retired toggle.
• Delete is only allowed for a rule that has never parsed a code. One that has must be retired first.

---

Drafts

You do not lose work if you leave mid-way. Leaving the wizard saves a real draft rule automatically, and there is an explicit Save as draft and exit button. Returning updates that same draft rather than making duplicates. Create Rule always starts fresh.

---

Limitations to know

• A parsed product can be incomplete. A code cannot carry every required technical-data value, so open each parsed product afterwards and fill in what is missing.
• Test Parse and re-parse preview show whether codes decode, not a full before-and-after of every value.
• One base product per rule. Every variant from a rule shares that base product's images, classifications and markings. Variants needing genuinely different shared data need separate rules.
• Two plain-number segments with no letters can be read in the wrong order. Give such a segment a distinguishing letter or a fixed pattern.

For technical users

The wizard builds a rule with example codes, ordered token definitions (fixed or dynamic, with an optional stripped value prefix), a per-token interpretation (Direct, Lookup or Formula), a master regex and scope prefix derived from the leading fixed segments, and a TemplateMapping onto a base ProductType's nameplate fields plus a technical-data template. Saving creates the rule in Draft; Publish is gated on completeness and on the examples parsing as a dry run. Rules carry a LineageId and Version; a new published version retires older published versions of the same lineage.