Auto repair shop website development using 1C-Bitrix

Auto Repair Shop Website Development on 1C-Bitrix

A car owner searches for an auto repair shop when they already have a problem. They search for "oil change in Minsk" or "affordable body repair," land on your site, and immediately want answers to two questions: how much will it cost for their vehicle and when can they bring it in. If your site doesn't answer these questions — the customer calls a competitor.

The key tool that solves the first problem is a maintenance cost calculator. Let's examine its implementation in detail.

Auto Repair Service Catalog

Services are organized in an infoblock with section hierarchy. Typical structure:

• Maintenance — Service A, Service B, oil changes, filter replacements
• Body Work — painting, dent removal, rust protection
• Diagnostics — computer, suspension, engine
• Tire Service — seasonal replacement, storage, balancing
• Electrical — alarms, audio systems, additional equipment

Element properties: PRICE_FROM (number), DURATION_HOURS (number), CAR_TYPES (list — sedans, SUVs, commercial), DESCRIPTION_WORK (HTML — what's included). Link to brands through multiple "Element Link" property — not all services are available for all brands.

Maintenance Cost Calculator by Car Brand

The calculator is the main conversion element of the auto shop website. A customer selects brand, model, year, and mileage — gets the cost of scheduled maintenance with breakdown by work and parts.

Data Architecture. Reference lists are stored in Highload Blocks — here this is not optional optimization, but necessity. The "brand — model — generation — engine" reference for 50 popular brands contains tens of thousands of combinations. In a regular infoblock, this would be catastrophic.

Highload Block CarDirectory:

Highload Block MaintenanceRegulation — maintenance schedule:

Highload Block ServicePricing — labor rates by vehicle category:

Calculation Algorithm:

1. Customer selects brand → model → generation → engine (cascading AJAX selects, each next filtered by previous)
2. Enters current mileage — system determines nearest scheduled maintenance (rounds up to nearest 10,000 or 15,000 depending on manufacturer)
3. Query MaintenanceRegulation by UF_CAR_DIR_ID and UF_MILEAGE_KM
4. For each service — pull price from ServicePricing by vehicle class
5. For each part — price from catalog (if connected) or from average price reference
6. Result formatted as table: "work — work cost — part — part cost — total"

$regulations = MaintenanceRegulationTable::getList([
    'filter' => [
        'UF_CAR_DIR_ID' => $carId,
        'UF_MILEAGE_KM' => $nearestMileage,
    ],
])->fetchAll();

$total = 0;
$breakdown = [];
foreach ($regulations as $reg) {
    $workPrice = ServicePricingTable::getRow([
        'filter' => [
            'UF_WORK_ID' => $reg['UF_WORK_ID'],
            'UF_CAR_CLASS' => $carClass,
        ],
    ]);
    $partPrice = $reg['UF_PART_ID']
        ? getPartPrice($reg['UF_PART_ID']) * $reg['UF_PART_QUANTITY']
        : 0;

    $lineTotal = $workPrice['UF_PRICE_WORK'] + $partPrice;
    $total += $lineTotal;
    $breakdown[] = [
        'work' => getWorkName($reg['UF_WORK_ID']),
        'work_price' => $workPrice['UF_PRICE_WORK'],
        'part' => getPartName($reg['UF_PART_ID']),
        'part_price' => $partPrice,
        'required' => $reg['UF_IS_REQUIRED'],
    ];
}

Cascading Selects. Implemented through AJAX component or REST endpoint. Selecting brand — query models with filter UF_BRAND = 'Toyota'. Selecting model — query generations. Each query — DataManager::getList() with DISTINCT on needed field.

For cascades to work fast, composite indexes are created on Highload Block CarDirectory: (UF_BRAND), (UF_BRAND, UF_MODEL), (UF_BRAND, UF_MODEL, UF_GENERATION).

Populating the Reference. The main pain point. Maintenance schedules for 50 brands — massive data volume. Options: manual entry (time-consuming but accurate), parsing from open sources (manufacturer catalogs), purchasing ready-made database (TecDoc-compatible references). Most projects start with 10-15 most popular brands and expand as needed.

Online Service Booking

Booking is simpler than salon: no tie to specific technician, but tie to service bay. Customer selects service, date, convenient time. System checks bay availability.

Highload Block ServiceBooking: UF_DATE, UF_TIME_START, UF_TIME_END, UF_BAY_ID (bay/lift number), UF_CLIENT_ID, UF_SERVICE_ID, UF_CAR_INFO (brand, model, license plate — text field or link to CarDirectory).

Slot logic similar: get bay work time, subtract booked intervals, show available times. Duration determined by service's DURATION_HOURS property.

Integration with 1C:Auto Repair Shop

1C:Auto Repair Shop stores repair orders, service history, parts inventory. Site integration solves several tasks:

• Import service orders to customer account — customer sees service history linked to VIN or license plate
• Parts inventory sync — if site has parts catalog, stock updates from 1C via CommerceML or REST
• Transmit online bookings to 1C — site booking automatically creates preliminary service order

Exchange through 1C HTTP services — REST endpoint published on 1C side, Bitrix calls it by cron. Format — JSON or XML. Frequency — every 15-30 minutes for inventory, immediately (webhook) for bookings.

Customer Account with Service History

Customer links vehicle to profile — enters VIN or license plate. System pulls all service orders for this VIN from 1C. Customer sees: visit date, completed services, installed parts, mileage at service time.

This is a powerful retention tool. Customer returns to site not just for booking but to check when oil was changed and if next maintenance is due.

System can automatically calculate next maintenance date based on customer's average mileage and schedule, sending reminders via email or SMS.

Parts Catalog

Optional module. If the shop sells parts — use standard Bitrix catalog module (catalog). Products sync with 1C via CommerceML. Important to configure trade offers for parts with OEM numbers and cross-references to analogs.

Promotions and Seasonal Offers

Promotions infoblock with automatic publication/removal by dates (DATE_ACTIVE_FROM, DATE_ACTIVE_TO). Seasonal promotions tied to service types: tire service in fall, air conditioning in summer, rust protection in spring. Displayed on homepage via bitrix:news.list filtered by activity.

Implementation Timeline

What Determines Budget

The maintenance calculator is the most labor-intensive component, with main costs not in code but in populating the reference database. Developing calculation logic takes 2-3 weeks, but populating the base for 50 brands can take the same. Start with the minimal set of brands most commonly serviced and expand based on search analytics.