Furniture factory website development using 1C-Bitrix

Furniture Factory Website Development on 1C-Bitrix

A furniture factory works with nomenclature where one product can have dozens of variations: a sofa in five upholstery options, three sizes, and two frame configurations — resulting in 30 trade offers. A kitchen set is assembled from modules, and the customer wants to see the result before ordering. A 1C-Bitrix website solves both tasks: a catalog with trade offers and faceted filtering for standard furniture, plus a 3D configurator for modular systems. Integration with 1C ensures current prices and stock levels without manual updates.

Furniture Catalog on Trade Offers

The catalog is built on Bitrix's trade catalog (module catalog) using the SKU mechanism — trade offers. The information block structure: kitchens, built-in wardrobes, sofas and chairs, beds, tables and chairs, bathroom furniture, office furniture.

The main information block "Furniture" contains products, each linked to an information block of trade offers. Product properties:

• Collection — reference to a reference book (information block "Collections")
• Style — list: classic, contemporary, loft, Scandinavian, minimalism
• Frame material — list: oak array, beech array, LDSP, MDF, metal
• Country of manufacture — list (for imported furniture in assortment)
• Warranty — numeric property (months)
• 3D model — GLTF/GLB file for configurator (where applicable)

Trade offers contain properties forming a specific variation:

• Color — reference with HEX code and sample photo
• Upholstery/facade material — reference with characteristics
• Size — string property (W×D×H in mm)
• SKU — unique code for synchronization with 1C
• Price — through the catalog module's price mechanism (base, retail, dealer)
• Stock — through the catalog module's warehouse accounting

Faceted Filtering

Parameter filtering is a critical element for a catalog with thousands of SKUs. Bitrix supports a faceted index (module iblock, method \Bitrix\Iblock\PropertyIndex\Manager::buildIndex()), which builds pre-calculated tables for instant filtering.

The component bitrix:catalog.smart.filter outputs a filter with parameters:

• Material — checkboxes with product count in parentheses
• Style — checkboxes
• Price — range (slider)
• Size — ranges for width, depth, height
• Color — visual swatches with samples
• Availability — toggle "In stock / To order"

The faceted index is rebuilt when products change through the OnAfterIBlockElementUpdate handler. For a catalog with 5000+ SKUs, this provides order-of-magnitude faster filtering compared to direct SQL queries.

Integration with 1C

Synchronization works through the standard exchange module catalog using the CommerceML 2 protocol:

• Nomenclature — from 1C to Bitrix: products, trade offers, properties (color, size, material)
• Prices — from 1C: base, retail, dealer price types
• Stock levels — from 1C: by warehouse, with aggregation for site display
• Orders — from Bitrix to 1C: site orders exported as customer orders
• Order statuses — from 1C to Bitrix: production/delivery status updates

Exchange schedule: prices and stock — every 30 minutes (cron), nomenclature — once daily (night exchange), orders — every 15 minutes.

B2B Section for Dealers

The dealer section is closed by authorization. Dealers register through a form with manager confirmation (moderation through a business process in module bizproc). After confirmation, the user is added to the "Dealers" group, which has access to:

• Dealer prices — separate price type in the catalog module, visible only to "Dealers" group
• Extended catalog — information block sections with access rights for dealers
• Marketing materials — information block with photos, renders, descriptions for dealer catalogs
• Order history and reconciliation — data from 1C exported to personal cabinet

Deep-dive: 3D Furniture Configurator

The modular furniture configurator is a key competitive advantage. The customer assembles a kitchen from modules in 3D space: selects lower and upper cabinets, places them along walls, chooses facades and worktop, sees the total cost. Technically, this is WebGL application integration on Three.js with data from the Bitrix catalog.

Interaction Architecture

The configurator is a client-side JavaScript application that loads data from Bitrix via REST API. Scheme:

1. When opening the configurator, JS requests /api/configurator/modules/ — a list of available modules with parameters (sizes, price, path to 3D model)
2. Data is taken from the "Configurator Modules" information block: each element — a separate module (lower cabinet 600mm, upper cabinet 400mm, corner module, etc.)
3. 3D models are stored in GLTF/GLB format — optimal balance between quality and file size
4. When placing a module on the scene, Three.js updates the overall specification and cost

Models and Optimization

Each module exists as a parametric 3D model. For a kitchen cabinet: chassis (fixed), facade (swappable — reference to facades dictionary), hardware (handles — swappable). Model loading is lazy: on initialization, only low-poly previews load; detailed models load when placed on the scene.

Model requirements:

• Polygon count per module — up to 5000 polygons (low-poly for real-time)
• Textures — 512×512 for modules, 1024×1024 for facades
• GLTF with Draco compression — 70–80% file size reduction
• Grouping: chassis, facade, worktop — separate mesh for material replacement

Material and Facade Changes

When selecting a facade material (e.g., "Natural Oak" → "White Gloss"), Three.js replaces the texture on the corresponding module mesh. Textures are stored in Highload information block "Configurator Materials" with fields: name, type (wood, plastic, glass), texture (PNG file), normal map (PNG file), PBR parameters (roughness, metalness).

Replacement occurs via THREE.TextureLoader with loaded textures cached in Map. On first material selection, texture loads from server; on repeat — from cache.

Spatial Arrangement

The user specifies room dimensions (wall lengths, ceiling height) through form input. Three.js builds a room framework. Modules snap to walls through snap logic: when dragging, a module "sticks" to the nearest wall and neighboring module. Collisions are checked via bounding box — modules cannot intersect.

Placement restrictions are set in module properties in the information block:

• UF_WALL_TYPE — list: lower, upper, tall unit, corner
• UF_SNAP_POINTS — JSON with junction point coordinates
• UF_MIN_HEIGHT — minimum installation height from floor (for upper modules)

Order Formation

After completing configuration, the user clicks "Place Order". JavaScript forms a JSON specification: array of modules with coordinates, selected facades and materials, scene render screenshot (generated via renderer.domElement.toDataURL()).

The JSON is sent to the server, where the PHP script:

1. Creates an order in the sale module with module products from the catalog
2. Calculates total cost through module binding to trade offers (facade + size = specific SKU)
3. Saves screenshot and JSON configuration in order properties
4. Exports the order to 1C at the next exchange cycle

Performance

A configurator with 15–20 modules on scene should run at 30+ FPS on mid-range devices. Optimization measures:

• Instancing for identical modules (THREE.InstancedMesh)
• Frustum culling — Three.js automatically clips objects outside camera
• LOD — as camera moves away, modules switch to simplified geometry
• Shadows disabled; lighting — ambient + directional without shadow map

Technical Requirements

The site deploys on "Business" edition — trade catalog modules, warehouse accounting, and 1C exchange are required. Server requirements: PHP 8.1+, PostgreSQL or MySQL, minimum 4 GB RAM (3D model conversion on upload via admin), SSD for GLTF files. Composite cache for catalog, CDN for static and 3D models.