Разработка сайта каршеринга на 1С-Битрикс

Разработка сайта каршеринга на 1С-Битрикс

Каршеринг — сервис с высокой технической нагрузкой на backend: real-time карта автомобилей, тарификация по времени и зонам, верификация водительского удостоверения, предавторизация платежа. 1С-Битрикс в этом проекте выступает как CMS для публичной части (каталог, тарифы, регистрация, личный кабинет) и как административная панель для операторов. Телематика и биллинг живут в отдельных сервисах, а сайт интегрируется с ними через API.

Каталог автомобилей

Автомобили хранятся в инфоблоке со следующими свойствами:

• Марка и модель — два связанных списка (марка → модель, зависимый выбор через JS в админке).
• Класс — список: эконом, комфорт, бизнес, внедорожник.
• Год выпуска — число.
• Цвет — список.
• Госномер — строка, уникальное свойство.
• VIN — строка (для внутреннего учёта, не выводится на фронт).
• Статус — список: свободен, занят, на обслуживании, в резерве.
• Текущая локация — два числовых свойства (широта, долгота), обновляемые из телематики.
• Тарифная группа — привязка к элементу Highload-блока тарифов.
• Фото — множественное свойство «Файл».
• Уровень топлива — число (%, обновляется из телематики).

Каталог на сайте — не классический список товаров. Это скорее справочная страница с карточками классов автомобилей и их характеристиками. Конкретные свободные машины пользователь видит на карте.

Регистрация с верификацией

Регистрация каршеринга — многоэтапная. Стандартного модуля регистрации Битрикс недостаточно, нужен кастомный компонент.

Этап 1: базовые данные. Имя, фамилия, дата рождения, телефон, email. Телефон подтверждается SMS-кодом (интеграция с SMS-шлюзом через событие OnBeforeUserRegister или отдельный AJAX-обработчик).

Этап 2: загрузка документов. Водительское удостоверение — фото лицевой и оборотной стороны. Паспорт — разворот с фото. Селфи с документом. Файлы загружаются через стандартный CFile::SaveFile и привязываются к пользовательским свойствам (UF_DRIVER_LICENSE_FRONT, UF_DRIVER_LICENSE_BACK, UF_PASSPORT, UF_SELFIE).

Этап 3: верификация. Два варианта:

• Автоматическая — интеграция с сервисом проверки ВУ (API ГИБДД или коммерческие сервисы: IDX, ScoringBureau). Запрос отправляется при загрузке документов, результат записывается в UF-поле пользователя.
• Ручная — оператор в админке просматривает загруженные документы, подтверждает или отклоняет. Статус верификации — пользовательское свойство с обработчиком, отправляющим push/SMS при изменении.

До прохождения верификации пользователь видит каталог и тарифы, но не может начать аренду.

Личный кабинет

Разделы личного кабинета:

• История поездок — данные из биллинговой системы, отображаемые через кастомный компонент. Каждая поездка: дата, время начала/конца, маршрут (полилиния на мини-карте), стоимость, применённый тариф.
• Штрафы — ГИБДД-штрафы привязываются к поездкам. Оператор загружает штраф в Highload-блок с привязкой к пользователю и дате. Пользователь видит штраф и может оплатить.
• Баланс — текущий баланс внутреннего счёта. Пополнение через платёжный шлюз. Используется внутренний счёт модуля sale (CSaleUserAccount).
• Бонусная программа — накопленные бонусы, история начислений и списаний. Бонусы хранятся в отдельной таблице или Highload-блоке.
• Документы — договор оферты, акты.

Интеграция с платёжным шлюзом: предавторизация

Перед началом поездки с карты пользователя выполняется предавторизация (холдирование) — блокировка суммы без списания. После завершения поездки списывается фактическая стоимость, остаток разблокируется.

Реализация через платёжный модуль sale с кастомным обработчиком платёжной системы:

1. При старте аренды — API-запрос к шлюзу (CloudPayments, ЮKassa, Тинькофф) на preauth с суммой депозита.
2. Идентификатор транзакции сохраняется в свойстве заказа или в отдельной таблице.
3. При завершении — запрос capture на фактическую сумму.
4. Если поездка отменена — запрос void для разблокировки.

Deep-dive: карта авто в реальном времени и тарифная логика

Карта — центральный интерфейс сервиса. Пользователь открывает приложение (или сайт), видит ближайшие свободные машины и выбирает одну. Реализация на Битрикс требует двух вещей: быстрого API для получения координат и гибкой тарифной модели.

Архитектура real-time карты

Координаты автомобилей обновляются телематическим сервисом (GPS-трекеры в каждой машине передают данные раз в 10–30 секунд). Битрикс не обрабатывает телематику напрямую — это задача отдельного backend-сервиса. Но сайт должен отображать актуальные данные.

Схема взаимодействия:

1. Телематический сервис записывает координаты, статус и уровень топлива в Redis или PostgreSQL (быстрое хранилище).
2. API-эндпоинт на стороне Битрикс (кастомный контроллер в /local/routes/) запрашивает данные из хранилища и возвращает JSON со списком машин в заданном bounding box (прямоугольнике видимой области карты).
3. Фронт (Яндекс.Карты JS API) при загрузке и при перемещении карты запрашивает API с координатами видимой области. Получает массив объектов:

[
  {
    "id": 142,
    "lat": 55.7558,
    "lng": 37.6173,
    "class": "comfort",
    "model": "Kia K5",
    "fuel": 68,
    "tariff_group": 2,
    "status": "free"
  },
  ...
]

4. Маркеры на карте обновляются без перезагрузки. Свободные машины — активные маркеры (кликабельные), занятые — не отображаются для пользователей (только в админке оператора).

Оптимизация запросов

При сотнях автомобилей на карте и тысячах одновременных пользователей нагрузка на API существенная. Решения:

• Кеширование в Redis — координаты кешируются с TTL 15 секунд. Все запросы за эти 15 секунд получают одинаковый снимок.
• Геоиндекс — если данные в PostgreSQL, используется PostGIS расширение для пространственных запросов (ST_Within). Запрос по bounding box с индексом работает за миллисекунды.
• Throttling на клиенте — фронт запрашивает обновление не чаще раза в 10 секунд и только при движении карты.

Тарифная сетка

Тарифы хранятся в Highload-блоке Tariffs с полями:

Географические зоны — отдельный Highload-блок TariffZones с полигонами (JSON-поле с координатами границ зоны). Центр города, спальные районы, загород — разные зоны с разными ставками.

Расчёт стоимости поездки

Стоимость рассчитывается биллинговым сервисом, но логика определена в тарифной сетке Битрикс:

1. Определение зоны — по GPS-координатам начала поездки определяется зона (проверка вхождения точки в полигон).
2. Определение периода — по времени начала: день или ночь.
3. Определение дня — будни или выходные.
4. Выборка тарифа — из Highload-блока по комбинации: класс авто + период + день + зона.
5. Расчёт — для поминутного: кол-во минут движения × UF_RATE_MINUTE + кол-во минут ожидания × UF_WAITING_RATE. Применяется UF_MIN_COST.

Если поездка пересекает границу периодов (началась днём, закончилась ночью), расчёт разбивается на два интервала с разными ставками. Аналогично — при пересечении зон.

Страница тарифов на сайте

На публичной странице тарифы выводятся таблицей:

Таблица генерируется динамически из Highload-блока. При изменении ставок в админке — данные на сайте обновляются автоматически (кеширование с тегами).

Администрирование и мониторинг

В админке Битрикс (раздел /area51 или стандартная панель) оператору доступны:

• Карта автопарка — все машины со статусами в реальном времени (кастомная страница в админке).
• Управление статусами — перевод машины в обслуживание, резерв.
• Верификация пользователей — очередь заявок с просмотром документов.
• Штрафы и инциденты — журнал с привязкой к поездке и пользователю.
• Редактирование тарифов — через интерфейс Highload-блока.

Техническая сводка

Сайт каршеринга на Битрикс — это интеграционный проект. Битрикс отвечает за контент, регистрацию, тарифы и админку. Телематика, биллинг и real-time карта опираются на внешние сервисы, связанные с Битрикс через API. Такая архитектура разделяет ответственность и позволяет масштабировать каждый компонент независимо.