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

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

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

Каталог автомобілів

Автомобілі зберігаються в інфоблоці з наступними властивостями:

• Марка та модель — два пов'язані списки (марка → модель, залежний вибір через JS в адмінці).
• Клас — список: економ, комфорт, бізнес, позашляховик.
• Рік випуску — число.
• Колір — список.
• Держномер — рядок, унікальна властивість.
• VIN — рядок (для внутрішнього обліку, не виводиться на фронт).
• Статус — список: вільний, займатий, на обслуговуванні, в резерві.
• Поточна локація — дві числові властивості (широта, довгота), оновлюються з телематики.
• Тарифна група — прив'язка до елементу Highload-блока тарифів.
• Фото — множинна властивість «Файл».
• Рівень палива — число (%, оновлюється з телематики).

Каталог на сайті — не класичний список товарів. Це швидше довідкова сторінка з карточками класів автомобілів та їх характеристиками. Конкретні вільні машини користувач бачить на карті.

Реєстрація з верифікацією

Реєстрація каршерингу — багатоетапна. Стандартного модуля реєстрації Bitrix недостатньо, потрібен кастомний компонент.

Етап 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, Tinkoff) на preauth з сумою депозиту.
2. Ідентифікатор транзакції зберігається у властивості замовлення або окремій таблиці.
3. При завершенні — запит capture на фактичну суму.
4. Якщо поїздка скасована — запит void для розблокування.

Deep-dive: карта авто в реальному часі та тарифна логіка

Карта — центральний інтерфейс сервісу. Користувач відкриває додаток (або сайт), бачить найближчі вільні машини та вибирає одну. Реалізація на Bitrix вимагає двох речей: швидкого API для отримання координат та гнучкої тарифної моделі.

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

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

Схема взаємодії:

1. Телематичний сервіс записує координати, статус та рівень палива в Redis або PostgreSQL (швидке сховище).
2. API-ендпоїнт на стороні Bitrix (кастомний контролер у /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-поле з координатами границ зони). Центр міста, спальні райони, загород — різні зони з різними ставками.

Розрахунок вартості поїздки

Вартість розраховується біллінговим сервісом, але логіка визначена в тарифній сітці Bitrix:

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

Якщо поїздка перетинає границю періодів (почалася днем, закінчилася ніччю), розрахунок розділяється на два інтервали з різними ставками. Аналогічно — при перетинанні зон.

Сторінка тарифів на сайті

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

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

Адміністрування та моніторинг

В адмінці Bitrix (розділ /area51 або стандартна панель) оператору доступні:

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

Технічна сводка

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