Developing a website for a manufacturing company using 1C-Bitrix

Manufacturing Company Website Development on 1C-Bitrix

A manufacturing company website is not a showcase—it's a working tool for dealers, suppliers, and engineers on the client's side. The primary goal is to enable technical specialists to find the needed product by parameters, download specifications, and submit a request for a commercial proposal. Everything else is secondary.

On 1C-Bitrix, such a site is built around a product catalog using infoBlocks, a B2B personal account module, and data exchange with 1C:ERP or 1C:UPP. Let's examine each component.

Product Catalog with Technical Characteristics

This is the site's core. A typical manufacturing company catalog contains anywhere from 500 to 50,000 product items, each with 15 to 60 technical properties. Fittings, metal products, electrical equipment, industrial machinery—each industry has its own parameter set, but the architectural approach remains consistent.

InfoBlock Structure

The catalog is built on an infoBlock of type catalog (merchandise catalog). InfoBlock sections form a category tree. For each top-level category, a separate property set is typically created through the section property binding mechanism (table b_iblock_section_property). This is critical: if you have pumps and valves in one infoBlock, you shouldn't display the "Nominal diameter" property for items in the "Electric motors" category.

Typical property configuration for an industrial catalog:

For properties with units of measurement, the b_catalog_measure reference book is used. Values are stored in b_iblock_element_property (regular properties) and b_catalog_product (commercial parameters).

Smart Filter

The catalog.smart.filter component works with a faceted index—the b_catalog_smart_filter table stores pre-computed combinations. Without a faceted index, filtering by 30+ properties on a catalog of 10,000 items will generate queries taking 3-5 seconds. With the index—50-100 ms.

Building the faceted index is launched via \Bitrix\Iblock\PropertyIndex\Manager::markAsInvalid($iblockId) followed by reindexing. When an element changes, the index updates automatically, but after bulk import from 1C, a full rebuild is necessary.

For engineering catalogs, the standard filter often isn't sufficient. Typical enhancements:

• Range filter for numeric properties (pressure from/to, temperature from/to)—natively supported but requires display configuration
• Filter by multiple values of a single property with OR logic—works out of the box
• Cross-filtering—when selecting a value for one property narrows available values for others. Implemented via AJAX filter loading with current parameters
• Tabular comparison of selected items—the catalog.compare.list component, but typically rewritten completely for the task

PDF Specifications and Documentation

Technical documentation is stored in F (file) type properties. Each product may have multiple documents: product passport, certificate, drawing, installation instructions. The correct approach is a multiple property with file bindings or a separate Highload block TechDocuments with fields UF_PRODUCT_ID, UF_FILE, UF_DOC_TYPE, UF_LANGUAGE.

PDF catalog generation on-the-fly is a separate task. Typically, the mPDF or TCPDF library is used, called from a custom component. The PDF template is formed from infoBlock data, the result is cached, and delivered to the user.

Integration with 1C:Manufacturing Enterprise Management

The standard catalog exchange module in Bitrix implements the CommerceML 2 protocol (data exchange via XML files). For 1C:UPP and 1C:ERP, this is the primary nomenclature and price synchronization path.

Exchange Mechanism

Exchange works through the URL /bitrix/admin/1c_exchange.php and consists of stages:

1. Authorization—1C sends login/password, receives a session
2. Catalog export (catalog)—import.xml and offers.xml files are uploaded to the server
3. Import—Bitrix parses XML, creates/updates infoBlock elements
4. Order exchange (sale)—bidirectional order status exchange

For a manufacturing company, the standard exchange is usually insufficient. Problem areas:

• Multiple price types. In 1C:UPP—retail, wholesale, dealer, special rates for specific counterparties. The catalog module supports multiple price types via the b_catalog_group table, but mapping to 1C requires manual configuration
• Stock levels by warehouse. The b_catalog_store_product table stores inventory by warehouse (b_catalog_store). 1C:UPP can export stock with warehouse breakdown, but processing must be customized on the 1C side
• Product characteristics. In 1C, this is implemented via "Product characteristics"; in Bitrix—via SKU (stock keeping units). One-to-one mapping isn't always possible, especially for multi-level characteristics

Highload Blocks for Reference Data

Reference data from 1C (units of measurement, categories, materials, GOSTs) should be stored in Highload blocks rather than regular lists. The b_hlblock_entity table defines the block; data is stored in an automatically created table with a prefix. Access API—via \Bitrix\Highloadblock\HighloadBlockTable::getById() and a generated ORM class.

Reference data exchange is a separate task not covered by standard CommerceML. It's implemented via Bitrix REST API (/rest/) or a custom endpoint called from 1C on a schedule.

B2B Functionality

Dealer Personal Account

The personal account is built on the sale module and extended with custom components. Basic capabilities:

• Personalized pricing—via price types bound to user groups. The "Dealers" group sees the wholesale column, the "Distributors" group—theirs. Configured in b_catalog_group2group
• Order history—the sale.personal.order.list component, typically customized: production status, shipment tracking number, invoice link added
• Order repeat—adding all items from a previous order to cart with one button
• Excel export—generating a price list with personalized pricing for a specific dealer

Commercial Proposal Request

For manufacturing companies, the cart often functions not as order checkout but as a request for a commercial proposal. The user adds items, specifies quantity, and instead of payment, completes a "Request Proposal" form. The request goes to Bitrix CRM (crm—lead or deal) and simultaneously to the manager's email.

Implemented via a custom handler for the OnSaleOrderBeforeSaved event or a completely custom component, bypassing standard order checkout.

Additional Modules

News and Articles—standard infoBlock, news.list / news.detail components. For a manufacturing company, this covers industry news, exhibition participation, catalog updates.

Certificates and Licenses—separate infoBlock or media library section. PDF files with image preview.

Product Calculator—if the nomenclature implies calculation (length, volume, custom sizes). Implemented as a JS component calling the catalog API for price retrieval.

Shipping Geography—Yandex.Maps API with markers for dealers and offices. Data from Highload block DealerNetwork.

Implementation Timeline

The bottleneck is always 1C integration. It depends on how standardized the configuration is on the client's side and whether a dedicated 1C specialist is available for exchange customization.