Preparing a manufacturer's BIM catalogue often takes more time than drawing the models. A product may have one name in the sales list and another on its technical drawing. A dimension may have changed while an older file remains in circulation. Options may be familiar to the sales team without being clearly connected to order codes. Resolving these relationships makes both the first release and later updates easier.
The architect using the catalogue does not have the factory's product knowledge. When placing a window, they need to understand which size they selected, which commercial product the type represents and whether the downloaded document applies to that option. Preparation works best when it follows the same route: identify the product, choose a variation, use the file and find the supporting information again.
Connecting a series, its variants and its files
Consider a fictional window series with two frame widths, two opening directions and several finishes. The sales team may manage separate order codes while the modelling team prefers several types in one family. Those arrangements can work together. First, map each commercial option to the place where users will find it in the model.
In Revit, a family groups elements with common parameters and related representations. Types hold variations within that structure. Autodesk's explanation of families establishes the distinction; deciding which variations belong in one file also requires an understanding of the product and how it will be used.
The following codes and dimensions are invented for this example. They answer a practical question before file naming begins: which orderable product does the selected model type represent?
| Product reference | Overall frame size | Model option | Publication detail |
|---|---|---|---|
| P-014-L | 1200 × 1500 mm | 1200 width, left opening | Matching opening drawing and document |
| P-014-R | 1200 × 1500 mm | 1200 width, right opening | Explanation of the viewing direction |
| P-016-L | 1400 × 1500 mm | 1400 width, left opening | Technical information for this size |
| P-016-R | 1400 × 1500 mm | 1400 width, right opening | Order code for this size and direction |
Finish can be described separately here. If another coating creates a different order code, include that relationship too. Users should not have to infer it from a filename and description. Where two similar-looking products have different technical properties, that difference needs to be accessible outside the sales team.
Choosing a pilot with enough variety
A group of five or ten products helps reveal problems before they spread across the catalogue. The selection matters more than the number. Several colours of one size may not expose the same issues as a different width, opening direction or material. Include options that show where the technical documents and model structure actually diverge.
The small window might work correctly while a wider type produces an unexpected frame junction or opening representation. A pilot makes this manageable. Its useful outcome is a preparation method that can accommodate the series, rather than one successful file.
Product management can identify current options, the technical team can explain dimensions and document applicability, and the editor can connect that information to searchable names and categories. Knowing where a question belongs saves time even in a small team: every uncertainty need not circulate with the entire file package.
When the drawing and catalogue disagree
Suppose the sales table lists a width of 1200, while an old model contains 1190. Do not immediately overwrite one with the other. Establish what each value measures: overall frame, installation opening or a previous revision. Using the same unit does not establish that the numbers describe the same dimension.
Once the source is clear, align the product description, document link and type list. Renaming the model does not change an internal parameter, and uploading a document does not update the page automatically. Treat these as connected parts of one product delivery.
Keep product codes unchanged in Turkish and English. The meaning of a dimension must also survive translation: overall frame width should not become clear opening. A genuinely different product for another market deserves an explicit explanation. The product data article develops the relationship between field definitions and sources.
Trying the delivery in a small, realistic task
Knowing the intended environment helps the modelling team spend time on useful details. An architect placing and changing a Revit component may need a different delivery from a coordinator receiving exchange models. Use the format comparison when deciding how to support those tasks.
Opening the pilot file is only a starting point. Place it in a small project resembling its intended use, change the type and look for the product code where the recipient expects it. Repeat with a different size. This gives a concrete account of what was tried and under which conditions.
Track project-specific information requirements separately from the general catalogue. buildingSMART IDS expresses requirements for model exchange in a computer-interpretable form. Understanding the recipient's requirements is more useful than adding arbitrary fields. Uploading a file to BIMNESNE does not itself constitute an IDS assessment.
Turning preparation into BIMNESNE drafts
Once the basic list is ready, download the CSV template from Products > Bulk Product Import in the company panel. It contains reference_code, product_name_tr, product_name_en and category_id. These fields create starting records; images, technical files and descriptions are completed in the product editor. The import does not accept XLSX workbooks or image URLs.
Format reference codes as text in Excel to preserve leading zeros. Each row needs a name in at least one language and a valid subcategory ID. Use the downloadable category list instead of guessing identifiers. Save as UTF-8 CSV within the limits of 5 MB and 5,000 rows.
- Put the pilot products in the template and upload it. Previewing creates no products, leaving time to examine invalid and skipped rows.
- Confirm suitable rows. Processing proceeds through browser requests of up to 50 rows, so keep the page open until it finishes.
- Open the resulting drafts and connect their cover, description and downloads to the same reference.
- Review one pilot from beginning to end before expanding the list. The placement checks can support this step.
Importing does not update existing products. References already used by the company, including deleted products, are not added again. Codes are optional, but a product without one is not automatically matched across different files. If the page closes or capacity runs out, inspect import history before restarting: completed records remain, and outstanding rows retain their status. Drafts also count towards the plan quota.
Publication timing and the next revision
When creating a company, you can choose the free trial or an available paid plan. The registration trial starts with company approval and runs for 14 days. A paid period requires verified payment and company approval. Unused registration trial entitlement is added to the first paid period; if the trial has never started, that entitlement is 14 days. Plan/Billing shows the current status and capacity.
Because the period does not start while approval is pending, preparation and publication can be planned separately. Creating a draft is not immediate publication: normal company and product publication conditions still apply. At expiry, products are hidden from the public catalogue while content and editor records remain. Account email verification is a separate process from company approval.
For the published pilot, retain the accepted file, its supporting document and the person responsible for changes. With the next revision, first identify affected products, then update their types, descriptions and downloads. When another size joins the range, the relationship between codes and files gives the next editor a clear place to begin.