1C-Bitrix Industry Solutions

Industry-Specific Solutions on 1C-Bitrix

TecDoc API, GIS "Marking," EGAIS, size charts with RU/EU/US conversion — the standard catalog.section catalog can't handle any of this. Industry-specific projects require non-standard data architecture, specialized integrations, and business logic that doesn't exist out of the box. We develop these solutions on 1C-Bitrix, and the hardest part isn't the code — it's immersing ourselves in the client's domain.

Auto Parts — TecDoc and Cross-References

Auto parts are the most technically complex catalog type. Without TecDoc, there's nothing to be done here.

VIN lookup. The user enters a VIN — the system decodes the make, model, year, trim level, and displays an assembly tree. Click on "Braking System" → "Front Brake Mechanism" → get a list of parts with article numbers. Implemented via TecDoc API (getArticleDirectSearchAllNumbersWithState, getLinkageTargets) — each request returns JSON with part-to-vehicle mappings.

Cross-references. Original article number → OEM, aftermarket, and premium equivalents. The cross-reference table lives in a separate information block with an index on PROPERTY_CROSS_NUMBER. On a catalog with 500,000+ article numbers, cross-reference search will lag without Sphinx/Elasticsearch.

Interactive assembly diagrams. An SVG map of the engine or suspension with clickable zones — click a part, go to its product card. Zone coordinates are stored in information block element properties.

Specific pitfalls: the TecDoc API is slow (500-1500ms per request), so we cache data in a local database and update it once daily via cron.

Building Materials — Calculators and Oversized Freight

Calculation tools. This isn't just "multiply quantity by price." A foundation calculator: type (strip, pile, slab) → dimensions → soil type → outputs concrete volume, rebar quantity, waterproofing, formwork. All with a 10-15% material buffer.

Technically: a JS calculator on the frontend for instant recalculation, server-side validation via a REST endpoint in PHP. Calculation formulas live in a configuration file, not hardcoded. The client updates coefficients themselves through the admin panel.

Oversized delivery. The standard sale.delivery delivery module can't calculate by tonnage and pallet count. We write a custom handler: sum product weights from PROPERTY_WEIGHT, divide by vehicle capacity, calculate the number of trips. A separate line item — floor-by-floor delivery (50-100 RUB/floor/ton).

Product specifications. Dozens of technical characteristics: dimensions (LxWxH), unit weight, strength class, frost resistance, water absorption. All of these become filters in smart_filter with product count recalculation.

Apparel and Footwear — Sizes and Returns

Size charts. The RU → EU → US → UK conversion table is stored in a highload block. On the product card — size selection with automatic conversion and a hint: "Your size EU 42 = RU 48." Catalog size filtering is based on availability, not the full size range.

Returns — up to 30% of orders in fashion. You need a streamlined system: return request from the personal account, return shipping label generation, automatic refund request creation in sale.return. Return statuses are visible in the customer's personal account.

Lookbook catalog. Not just a product list, but styled outfits: model photo → clickable hotspots on the image → links to specific item cards. Implemented via a custom "Looks" information block linked to products.

Pharmaceuticals — Regulations and Labeling

The most heavily regulated industry. Mistakes are not an option.

• GIS "Marking" — every package with a DataMatrix code. Integration via the MDLP API: transmission of retail sale data, code verification at shipment
• State Drug Registry — linking products to the registry, automatic registration certificate verification
• Prescription vs. OTC separation — different logic: prescription drugs can't be added to cart, only "check availability at pharmacy" requests
• Distance selling prohibition — for certain categories, the "Buy" button is replaced with "Check availability at pharmacy"

Food and HoReCa

• Nutritional info (calories, protein, fat, carbs) and allergens on the product card — stored in information block properties, displayed in a standardized format
• Expiration date management: PROPERTY_EXPIRY_DATE, automatic removal from the storefront N days before expiration
• Subscription models: "weekly farm produce box" — implemented via sale.recurring or a custom subscription module
• B2B minimum order quantities for restaurants — a separate price type PRICE_TYPE_HORECA with minimums per case/package

Education

• Course catalog with filters: subject area, format (in-person/online/hybrid), duration, level
• Student personal account: schedule, materials, assignments — a custom section linked to a "Study Groups" information block
• LMS integration (Moodle, GetCourse) via API — SSO authentication, progress synchronization
• Certificate generation: student data + PDF template via the TCPDF library

Architectural Decisions

Specialized catalogs. The standard "Section → Subsection → Product" hierarchy doesn't always fit. For auto parts: "Vehicle → Assembly → Unit → Part" — four levels linked via highload blocks. For building materials: "Category → Subcategory" + a matrix classification by purpose (foundation, walls, roofing).

Multiple classifiers. OKPD-2, TN VED, ETIM — stored in highload blocks linked to catalog elements. Needed for B2B clients, tenders, and government procurement integration.

Industry-specific integrations beyond standard 1C and payment gateways:

Development Approach

1. Industry audit (3-5 days). We immerse ourselves in the specifics: how the market works, which processes are unique, what's regulated by law. We don't reinvent — we leverage work from similar projects.

2. Data architecture (1-2 weeks). Information block structure, highload blocks, properties, relationships. A mistake at this stage is expensive — restructuring a catalog with 100,000 products later is painful.

3. Prototyping (1 week). Catalog with industry-specific filters, product card with calculator, specialized checkout. We test on real users.

4. Development (1-4 months). Often the most labor-intensive phase is catalog population: data mapping from Excel/1C, characteristic normalization, image upload.

5. Industry scenario testing (1-2 weeks). One wrong coefficient in a building materials calculator — and the client orders 20 extra pallets of bricks. We verify calculations against real data.

Timelines and Complexity

Over the years, we've accumulated ready-made modules: building materials calculator, VIN lookup, size charts, GIS "Marking" integration. This reduces timelines by 20-40% compared to building from scratch.