Type Code Overview

Type Code Overview

A type code is a manufacturer's shorthand for a product variant, for example NW-4021-P075-U3-B0. It packs several choices (size, power, voltage, options) into one compact string.

The Type Code feature reads those codes for you. You describe a code's structure once as a rule, and from then on you can paste a code and the app decodes it into a full product, ready to export as an AAS. It turns a code your customers already use into product data, without retyping.

This is the most distinctive part of the app, and also the most involved. This page explains the idea. The step-by-step guides are on Type Code Rules, Parse a Type Code and Lookup Tables.

---

The idea in one picture

flowchart LR
    C[Type code<br/>NW-4021-P075-U3] --> R[A rule splits it<br/>into segments]
    R --> S[Each segment is<br/>interpreted]
    S --> P[A new product<br/>is created and filled in]
    P --> X([Export as AAS])

Loading

• A rule knows how one family of codes is built: where the segments are, what each one means.
• Parsing a code runs it through the rule and produces a product.
• The product is a variant, identified by its order code, sharing common data from a base product you chose when building the rule.

---

What a parse produces

This is the point people most often get wrong.

A parsed code creates a product (a variant), not a unit. NW-4021-P075-U3 and NW-4021-P150-U3 are two different products in your catalog, each with its own order code. If you later build physical units of one of them, you register those as instances in the normal way (see Product Instances).

Every parsed product also copies its shared data (images, classifications, markings, and so on) from a base product type you pick when you build the rule. The code only fills in what varies between variants.

---

A worked example

Take a pump maker whose codes look like NW-4021-P075-U3.

The rule splits it into segments and interprets each one:

Segment	Meaning	How it is interpreted	Result
NW-4021	The model	Direct (used as-is), mapped to the designation	NW-4021
P075	Motor power	Formula: drop the P, divide by 10	7.5 kW
U3	Supply voltage	Lookup: U3 means 400 V	400 V

Paste NW-4021-P075-U3 on the Parse a Type Code page and the app creates a product called NW-4021-P075-U3 with power 7.5 kW and voltage 400 V already filled in, plus everything the base product shares.

Change the code to NW-4021-P150-U3 and you get a second product at 15 kW, in seconds.

---

The three ways a segment is interpreted

When you build a rule, you tell it how to read each segment. There are three choices.

Type	What it does	Example
Direct	Uses the segment text as it is.	NW-4021 stays NW-4021.
Lookup	Translates the code through a lookup table you define.	U3 becomes 400 V; U1 becomes 230 V.
Formula	Computes a value from the number in the segment.	P075 becomes 7.5 by dividing by 10.

Lookup tables are shared and reusable, and they can also carry documents. See Lookup Tables.

---

The workflow

1. Build a rule. Paste a few example codes, name the segments, choose how each is interpreted, and pick a base product. A five-step wizard walks you through it. See Type Code Rules.
2. Publish the rule. A new rule is a draft and parses nothing until you publish it. Publishing is only allowed once the rule is complete and can successfully decode its own example codes.
3. Parse codes. Paste one code, or many at once, and the app creates a product for each. See Parse a Type Code.
4. Fill in the gaps. A code cannot supply every required field, so open each new product and complete anything still missing (see the limitation below).

---

Rule lifecycle

A rule moves through three states.

State	Parses codes?	Notes
Draft	No	A new rule starts here. Fully editable. Parses nothing until published.
Published	Yes	Live. You can still correct it in place.
Retired	No	Switched off, but its history is kept.

• Publishing is gated. The rule must have example codes, named segments, a pattern and a base product, and its examples must actually parse. If anything is missing, the app lists it.
• 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. See below.
• Deleting is allowed for a rule that has never parsed anything. One that has must be retired first. The list hides retired rules behind a "Show retired" toggle.

---

Re-parsing after a fix

If you correct a published rule, the products it already made do not change on their own. You trigger a re-parse (from the prompt after editing, or a button on the rule's page), and it always runs preview then confirm before changing anything.

Re-parsing refreshes the values the rule owns: technical data, the nameplate fields it maps, and lookup-matched documents. It never touches a product's order code, its company, carbon footprint, images, classifications, or any document or product you edited by hand. A product you have deliberately unlinked from the rule is left alone.

---

Hints

• Start with three or more real codes when you build a rule. The wizard detects the segments from your examples, so more examples means better detection.
• Use Lookup for anything with a fixed set of options (voltage, frame size, material). Use Formula only when the value is a straight calculation from the number. Use Direct for the parts that are already the value.
• Publish only when the rule decodes your own examples. The gate enforces it, and it is the quickest way to know the rule is right.
• Parse one code first to check the result before you paste a whole list.
• Wire a lookup entry to a document set if a certain option always ships with the same certificate, so parsing attaches it automatically. See Lookup Tables.

---

Limitations to know

• A parsed product can be incomplete. A code cannot carry every required technical-data value, so a parsed product may be missing some. The app does not force you to fill them, so open each new product and complete the required fields before you rely on its export.
• Bulk parsing does not prompt for the gaps. When you parse many codes at once, no per-product form appears; you revisit each product to finish it.
• Re-parse preview shows parseability, not value changes. It tells you how many products will update and how many no longer parse, but not the old-to-new value differences.
• One base product per rule. Every variant from a rule shares the same base product's images, classifications and markings. If two variants need genuinely different shared data, they need different rules.
• Codes with two plain-number segments and no letters can be read in the wrong order. Give such segments a distinguishing letter or a fixed pattern so the rule can tell them apart.

For technical users

A rule holds example codes, named token segments, a per-token interpretation (Direct, Lookup or Formula), a master regex, a scope, and a mapping onto a base ProductType's fields. Parsing keys the resulting ProductType by OrderCode and copies shared data from the base type; it never creates an instance. Rules carry a LineageId and Version; publishing a new version retires older published versions of the same lineage to avoid two rules matching one code. Parsed products are created with SkipRequiredValidation, which is why required technical-data fields can be absent until edited by hand.