Configuring Exchange Between 1C:Auto Service and 1C-Bitrix
An online auto parts store or auto service website built on Bitrix has specific characteristics not found in a standard product catalog: applicability (which vehicles a part fits), OEM numbers, cross-reference numbers, and VIN linkage. All of this is stored in 1C:Auto Service — and the integration task is to ensure this data reaches the website correctly.
Items in 1C:Auto Service
The configuration stores parts with extended attributes:
- Manufacturer's part number (OEM number)
- Cross-reference numbers (equivalents from other manufacturers)
- Applicability (make, model, year, engine)
- Brand / manufacturer
- New / used flag
- Warranty period
Standard CommerceML transmits the name and part code. OEM numbers, cross-reference numbers, and applicability are transmitted via AdditionalAttributes. On the Bitrix side, each of these attributes must become an infoblock property with the correct type (string, multiple value for cross-reference numbers, directory reference for applicability).
Applicability: the Most Complex Part
Part applicability is a many-to-many relationship: one part fits several vehicles, one vehicle uses many parts. In 1C:Auto Service, applicability is stored in an information register.
CommerceML has no standard way to transmit this structure. Options:
Option 1: JSON in an attribute.
In 1C, a JSON string with applicability data is composed and placed in AdditionalAttribute:
[
{"make":"Toyota","model":"Camry","year_from":2006,"year_to":2011,"engine":"2AZ-FE"},
{"make":"Toyota","model":"RAV4","year_from":2005,"year_to":2012,"engine":"2AZ-FE"}
]
In Bitrix — a "Text" type property storing JSON. Filtering by applicability — via full-text search or a separate table.
Option 2: Separate applicability infoblock. Create a dedicated "Applicability" infoblock in Bitrix (make/model/year/engine) and a "Parts" infoblock with a link via an "Element Reference" property. This is the correct architecture for full vehicle-based search, but synchronizing it from 1C is more complex — a custom import handler is required.
Cross-Reference Numbers and Search
Cross-reference numbers are codes for the same part under different brands. A buyer searches by cross-reference number on the site — the part should be found even if an equivalent from a different manufacturer is being sold.
In Bitrix, cross-reference numbers are stored as a multiple-value infoblock property. Searching by them — via the bitrix:catalog.smart.filter component or a custom search using CIBlockElement::GetList with a property filter.
When importing from 1C:Auto Service, cross-reference numbers are transmitted via AdditionalAttributes with multiple values:
<AttributeValue>
<Name>CrossNumber</Name>
<Value>BP-35</Value>
</AttributeValue>
<AttributeValue>
<Name>CrossNumber</Name>
<Value>ATE-603310</Value>
</AttributeValue>
The Bitrix import handler must collect multiple values for the same attribute into an array.
Service Requests: Auto Service Specifics
In 1C:Auto Service, in addition to parts sales, "Work Orders" are maintained — documents for performing services. On the website, this can be a service appointment form or an online diagnostics request.
Submitting service requests from the website to 1C:Auto Service: this is typically not CommerceML but a REST request to the 1C HTTP service. The request is created as an "Inquiry" or "Work Order" with the status "New."
Case Study: Used Parts Store
A car dismantling operation: 45,000 used parts, each with photos, condition rating (1–5), and applicability data. A full exchange with 1C:Auto Service took 40 minutes and stalled the server.
Optimizations applied:
- Export filter: "In Stock" only (quantity > 0)
- Images via FTP separately from XML (XML without base64 is twice as small)
- Applicability — JSON in a single field (no separate infoblock)
- Incremental exchange every 30 minutes: only items with changed stock levels
Result: full exchange — 12 minutes (at night), incremental — 2 minutes.