Your Manufacturing Website on 1C-Bitrix

Imagine: you have 20,000 items, each needs to be described by 50 parameters, and dealers wait hours for a response to their request. Deadlines are missed, managers drown in Excel. We develop websites for manufacturing companies on 1C-Bitrix that become a working tool for dealers, procurement specialists, and engineers. The main goal is to give a technical specialist the ability to find the right item by parameters, download a specification, and send a request for a commercial proposal. Everything else is secondary.

With over 10 years of experience and 50+ completed projects for industrial enterprises, we deliver reliable solutions that combine a comprehensive catalog, deep 1C integration, and a full-featured B2B cabinet. A typical manufacturing company saves up to 3,000,000 rubles annually by automating order processing. On average, order processing time is reduced by 40% compared to manual methods.

On 1C-Bitrix, such a site is built around an information block catalog, a B2B module for personal cabinet, and data exchange with 1C:UPP or 1C:ERP. The catalog can contain tens of thousands of products with dozens of technical properties. The B2B personal cabinet on Bitrix provides personal prices and order history. Integration with 1C ensures automatic synchronization of nomenclature and stock balances. The average check per dealer is 150,000 rubles, and the time savings on order processing due to automation is up to 40%.

Let's break down each block.

Product Catalog with Technical Specifications

This is the core of the site. A typical manufacturing company catalog contains from 500 to 50,000 items, each with 15 to 60 technical properties. Valves, rolled metal, electrical equipment, industrial machinery—each industry has its own set of parameters, but the architectural approach is the same.

How to Organize a Catalog with Technical Specifications?

The catalog on Bitrix is built on an information block of type catalog (commercial catalog). Information block sections constitute the category tree. For each top-level category, a separate property set is usually created via the property-to-section binding mechanism (b_iblock_section_property table). This is critical: if you have pumps and valves in one information block, you don't want to show 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 is used. Values are stored in b_iblock_element_property (regular properties) and b_catalog_product (trading parameters).

Smart Filter

The catalog.smart.filter component works with a facet index—the b_catalog_smart_filter table stores precomputed combinations. Without a facet index, filtering by 30+ properties on a catalog of 10,000 items generates queries taking 3-5 seconds. With the index, it takes 50-100 ms – that's 30-60 times faster. This catalog filter on Bitrix is essential for performance.

Building the facet index is triggered via \Bitrix\Iblock\PropertyIndex\Manager::markAsInvalid($iblockId) followed by reindexing. The index updates automatically on each element change, but after a mass import from 1C, a full rebuild is needed.

For engineering catalogs, the standard filter is often insufficient. Typical customizations:

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

PDF Specifications and Documentation

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

On-the-fly PDF catalog generation is a separate task. Usually, the mPDF or TCPDF library is used, called via a custom component. The PDF template is formed from information block data, the result is cached and served to the user.

Integration with 1C:Manufacturing Enterprise Management

The standard exchange module catalog in Bitrix implements the CommerceML 2 protocol (exchange via XML files). For 1C:UPP and 1C:ERP, this is the main path for synchronizing nomenclature and prices.

How Does Integration with 1C Work?

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

1. Authorization—1C sends login/password, gets a session.
2. Catalog upload (catalog)—files import.xml and offers.xml are uploaded to the server.
3. Import—Bitrix parses XML, creates/updates information block elements.
4. Order exchange (sale)—bilateral exchange of order statuses.

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

• Multiple price types. In 1C:UPP—retail, wholesale, dealer, special for a specific counterparty. The catalog module supports multiple price types via the b_catalog_group table, but mapping with 1C must be configured manually.
• Warehouse balances. The b_catalog_store_product table stores balances by warehouses (b_catalog_store). 1C:UPP can upload balances broken down by warehouses, but a modification on the 1C side is needed.
• Nomenclature characteristics. In 1C, this is implemented via "Item Characteristics", in Bitrix via SKUs (trade offers). One-to-one mapping is not always possible, especially if characteristics are multi-level.

Highload Blocks for Reference Data

Reference data from 1C (units of measurement, categories, materials, GOSTs) are best 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 is implemented via Bitrix REST API or a custom endpoint called from 1C on a schedule.

B2B Functionality

Dealer Personal Cabinet

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

• Personal prices—via price types attached to user groups. The "Dealers" group sees the wholesale column, the "Distributors" group sees their own. Configured in b_catalog_group2group.
• Order history—component sale.personal.order.list, usually customized: adds production status, shipment tracking number, link to invoice.
• Repeat order—adding all items from a previous order to the cart with one button.
• Export to Excel—generating a price list with personal prices for a specific dealer.

Request for Commercial Proposal

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

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

Additional Blocks

• News and articles—standard information block, components news.list / news.detail. For a manufacturing company, these are industry news, participation in exhibitions, catalog updates.
• Certificates and licenses—separate information block or media library section. PDF files with image preview.
• Product calculator—if the nomenclature involves calculations (length, volume, non-standard sizes). Implemented as a JS component accessing the catalog API for prices.
• Geography of deliveries—Yandex.Maps API with markers for dealers and representative offices. Data from Highload block DealerNetwork.

What's Included in the Work

• Detailed technical specification based on audit of current processes.
• Architecture and design: information block structure, 1C exchange scheme, role model.
• Catalog development with smart filter, PDF specifications, and documentation.
• Integration with 1C:UPP or 1C:ERP (CommerceML 2, REST API).
• Dealer personal cabinet with personal prices and CP request.
• Testing and performance optimization (caching, indexes).
• Deployment to server, monitoring setup.
• Transfer of documentation, access, administrator training.
• Technical support during warranty period (up to 6 months).

Implementation Timeline

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

Our experience: over 10 years of development on 1C-Bitrix, more than 50 completed projects for industrial enterprises. If you need a website that becomes a working tool for dealers and engineers, contact us. Get a consultation on the project and an approximate work plan.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.