Seeing the same numbers in a technical document, model file and catalogue page is reassuring. Yet those numbers may describe different things. If the document gives packaging dimensions and the model gives enclosure dimensions, making them match does not improve the information. First establish what is being measured, which product option is involved and when the information applies.
The difficult part of preparing product data is often deciding which question to ask when sources disagree. Technical knowledge has to become something a catalogue editor can use. The person downloading the model should then be able to identify the same product without access to the manufacturer's internal conversations.
Three records for the V-240 product
Consider a fictional ventilation product. The sales list calls it V-240, a technical drawing shows an enclosure measuring 600 × 400 × 300 mm, and a logistics table gives 620 × 420 × 330 mm. Suppose the logistics dimensions were copied into an old model description. These codes and figures are illustrative, not technical declarations for a real product.
The immediate reaction might be that one set of dimensions is wrong. But logistics describes the package, while the drawing describes the enclosure. A catalogue heading that says only “dimensions” hides that distinction. Giving each value the right meaning resolves the problem more effectively than forcing every source to contain one number.
Likewise, the 240 in V-240 should not automatically be interpreted as a capacity. It may simply be part of the series code. Product identity, technical properties and a project's placement notes serve different purposes.
Choose a stable commercial reference and relate it to the drawing, document and model. If the series has different motors, enclosures or finishes, explain which option each document covers. A shared series name does not establish that every technical value is shared.
| Field | Illustrative information | Meaning | Source to consult |
|---|---|---|---|
| Product reference | V-240 | Text identifying the commercial product | Current product list |
| Enclosure width | 600 mm | External width of the enclosure | Applicable technical drawing |
| Package width | 620 mm | External width of the shipping package | Logistics information |
| Condition-dependent value | Awaiting technical clarification | Not ready for use without its conditions | Document for the relevant variant |
| Document revision | R03 | Revision identifying the source used | The document's revision field |
The explanation that belongs beside a number
A short field name such as “width” may seem sufficient to people who know the product well. That shared knowledge disappears when the file reaches another company. Enclosure width, installation opening and maintenance clearance mean different things. Combining them in one field can make a correct number serve the wrong purpose.
A field dictionary can stay compact: what is measured, its data type, unit and source. Product codes stored as text retain leading zeros. A dimension's unit should not be inferred from the filename; the same number in centimetres and millimetres represents different sizes.
When sources use different units, compare them in a common unit while retaining an understanding of the original notation. Decimal punctuation may change between languages without changing the value. Stating the expected display in the dictionary helps an editor distinguish formatting from a technical revision.
Zero is a particularly misleading substitute for missing information because it looks like a defined value. Distinguish unknown, not applicable and awaiting clarification in the working list. Rather than forcing explanatory text into a numerical parameter, keep the reason for the omission and its responsible person alongside the preparation work.
Making sure the document covers the product
A technical document does not make every value inside it applicable to the whole catalogue. Imagine two equipment options for V-240. Copying a value from one option into the other creates a record that looks complete but has an uncertain basis.
Performance information may also depend on operating conditions. The technical owner needs to explain both the number and the variant or conditions it describes. Only then can the editor choose a useful statement for the page. Guessing a missing condition or filling the gap with an older value creates ambiguity that is difficult to unwind later.
Make the document revision identifiable as well as linking to the document. A URL can remain the same while its contents change. Knowing which technical explanation supported an accepted model makes the affected fields easier to find when a replacement arrives. This is useful even when several people maintain only a handful of products.
Giving model parameters distinct jobs
Treating model parameters as copies of every catalogue column can create unnecessary duplication. First understand where the information varies. A property shared by a product type and a location note for one placed element have different roles. Revit's choice between type and instance parameters matters here.
The manufacturer's V-240 reference identifies the product; “second-floor corridor” describes its placement in a particular project. Substituting a location note for product identity leaves misleading information when a file is reused. Equally, a change intended for one placement may not be appropriate for every element of that type.
If the recipient needs tags or schedules, try the fields in those outputs. Autodesk explains that shared project parameters can be tagged and scheduled. Finding the parameter name is only the start; a small example should show that the correct value comes from the intended product.
Keeping Turkish and English tied to one technical record
Do not translate product codes. Enclosure dimensions, document revisions and variant relationships should come from the same technical source in both languages. Natural English may need a different sentence structure, but the measured object must remain the same. Translating “enclosure” as “package” changes the information even if the numbers stay identical.
A short product glossary makes later translations easier. It can explain how a field is used as well as offering a word equivalent. If another market receives a genuinely different option, describe that difference explicitly. Silently changing the value between languages does not explain it.
Images and downloads belong in this relationship too. A general series image may not depict every option. Explaining which illustration is representative and which file covers a particular variant helps the reader follow the written information.
Finding the scope of a new revision
When a revised drawing arrives, establish what changed before choosing which file to upload. Was an enclosure dimension corrected, did the product code change, or was only a drawing note revised? Not every change requires rebuilding every model type.
If the enclosure width genuinely changes, consider geometry, its dimension field and the catalogue description together. A packaging change should not alter the modelled enclosure. Identifying the affected scope is particularly valuable when a single file contains several product types.
Put the previous value, replacement, supporting document and affected products side by side. Then try the changed type in a small placement task, compare a known dimension and read the relevant schedule value where necessary. Retaining the accepted file with this short change explanation saves the next editor from repeating the investigation.
Where catalogue information meets a project delivery
A general catalogue cannot anticipate every project's information requirements. Requested properties or classifications need to be agreed separately. buildingSMART IDS helps structure requirements for model exchange. Checking for specified fields does not replace the judgement needed to apply a technical document to the correct variant.
BIMNESNE's CSV import creates drafts from references, product names and categories; it does not automatically populate technical fields or model files. Complete dimensions, materials, descriptions and downloads in the product editor. The manufacturer catalogue preparation article connects the information list to that workflow, while the Revit and IFC comparison discusses native and exchange deliveries.
After creating a company and preparing a pilot product, ask a colleague unfamiliar with it to read the page, model and document together. Their questions can reveal information that seems obvious inside the manufacturer but is unclear outside it. Resolving those questions gives the next products in the series a much more useful starting point.