By Artem Korsakov ·
Equipment configurators are often represented as forms with drop-down lists. Lists are indeed present, but the workflow is much deeper. A configurator stores connections between what the client knows and what must end up in the specification. Let's break down these layers step by step using a hypothetical example of an air handling unit (AHU).
What the Client or Manager Enters
The client describes the object. They usually do not name an equipment model. Their parameters are: room purpose, required air volume, regional climate, installation location, and control method. They usually do not know the fan or heater models, and asking them about these is futile.
Therefore, the first layer of the configurator consists of questions in the client's language. A good questionnaire is short and asks only what affects the bill of materials (BOM). If an answer to a question does not affect anything, the question is redundant. If you cannot select a component without an answer, the field is mandatory, and no quotation can be issued without it.
Fields must have clear units and limits. Air volume in cubic meters per hour, temperature in degrees, voltage from a list of available options. Values outside what the manufacturing plant produces should be blocked immediately with an explanation, rather than being passed through and discovered as an error during the specification stage. It is useful to preserve the origin of each value: whether it was entered by the client, clarified by a manager over the phone, or substituted with a default template.
How Rules Turn Requirements into a Bill of Materials (BOM)
The second layer contains rules. There are three types:
- Selection: based on air volume and network resistance, the fan size type is selected;
- Dependency: with a water heater, freeze protection and piping unit are mandatory;
- Prohibition: a certain housing is not compatible with the selected type of regenerator.
A rule is recorded once and works identically for all managers. The approach, where permissible combinations are defined by constraints, is described, for example, in Tacton materials on complex configurations. The system filters out impermissible options and leaves the manager with a choice within the allowed range. There is no need to list ready-made kits in advance.
Constraints are divided into hard and waivable. A hard constraint cannot be waived by anyone. A waivable one can be waived by an engineer if there is a valid reason.
Exception: When a Rule Needs to Be Overridden
Real requests sometimes go beyond the rules. The client asks to keep a smaller heater because there is another heat source in the room. Formally, the rule is violated; substantively, the decision may be correct.
The configurator should neither silently pass such requests nor ban them forever. The normal order is as follows:
- The manager requests an exception and writes the client's reason in words.
- The engineer sees the specific violated rule and parameters.
- The engineer approves or rejects it with justification.
- Approval applies only to these parameters. If the client changes air volume or region, the exception must be confirmed again.
The last point is often overlooked. Without it, an old authorization quietly carries over to another BOM for which no one gave permission.
Specification, Price, and Quotation Version
A specification is assembled from the verified BOM: article numbers, quantities, options. Prices, discounts, and delivery terms are applied to it. It is reasonable to calculate the discount only on equipment, while showing shipping and installation separately; otherwise, it is difficult for the client to compare offers.
Подпись: Training amounts, not a price list. An 8% discount is applied only to equipment.
The result is a quote version with a number. The client confirms exactly this one. If someone changes parameters after that, a new version is created, and the confirmed one remains unchanged. This way, in case of a dispute about what was agreed upon, there is an exact answer.
Подпись: Illustrative example of a device. Rules are recorded once, and after changing parameters, a new quote version is confirmed.
A quote version has an expiration date and the price list date by which it was calculated. If the price list is updated, the old version remains in history with previous prices, and a new one is issued for new confirmation. The client only sees their price, BOM, and terms here. Internal discount levels, limits, and discussions of exceptions do not appear in the document for the client.
The confirmed specification is then sent to an accounting system, where production and inventory are tracked. Accounting systems have their own sections for this purpose, such as the MySklad production section. How exactly the specification will get there and which system will be primary for updating directories is decided during implementation.
Rule Description Template
To prepare rules for any system, it is convenient to record each rule in a single format:
| Field | What to Record |
|---|---|
| Condition | Which parameters trigger the rule |
| Action | What to select, add, or prohibit |
| Type | Hard or waivable |
| Who Waives | The position authorized to allow an exception |
| Basis | Where the rule comes from: component datasheet, regulation, operational experience |
| Example | One permissible and one impermissible BOM |
If you cannot fill out the "Basis" for a rule, it should be discussed with engineers before being transferred to the system. Such rules often turn out to be habits without a technical basis.
What Remains Outside the Configurator
The configurator does not design an entire ventilation system and does not replace an engineering calculation of the facility. It speeds up standard selection within rules that the company already knows. Network aerodynamics, acoustics, and building thermal balance remain the responsibility of the designer.
Accounting, production, and accounting also remain outside its scope. The configurator passes them the approved BOM and receives directories from them. Integrations with existing systems are part of future implementation and are designed separately.
In a demonstration scenario, you can trace how an incompatible combination is blocked, how an exception goes to the engineer, and how the client confirms a specific quote version.
Related article: Ready-made configurator or custom development: what to check before choosing.
Sources and Example Boundaries
Sources confirm the described functions of ready-made products, not demand or return on investment for custom development. Scenarios and amounts are training examples. Demonstrations work with fictional data; real integrations, AI, payments, and external publication are not included in them.