Розробка сайту логістичної компанії на 1С-Бітрікс

Вантажовідправник приходить на сайт з одним завданням: дізнатися вартість перевезення, оформити заявку, відстежити вантаж. Якщо калькулятор не рахує, трекінг не показує статус, а для повторного відправлення потрібно знову заповнювати 12 полів — клієнт іде до конкурента з нормальним особистим кабінетом. Ми розробляємо портали для транспортних фірм на CMS 1С-Бітрікс, і 10+ років досвіду дозволяють нам уникнути цих помилок. Зв'яжіться з нами, щоб обговорити архітектуру вашого проекту.

Архітектура даних та ключові модулі

Бітрікс дозволяє зібрати все це, але архітектура має бути заточена під специфіку логістики з першого дня. Ми не просто налаштовуємо інфоблоки — ми проектуємо систему, яка витримає тисячі запитів до розрахункового модуля, інтеграцію з 1С та забезпечить надійне відстеження з клієнтським порталом. Розберемо конкретні рішення.

Структура каталогу послуг

Логістична компанія пропонує не один продукт, а матрицю послуг: FTL (повне завантаження), LTL (збірний вантаж), warehousing, митне оформлення, last-mile доставка. Кожен тип має свої параметри — обмеження за вагою, габаритами, температурним режимом, географією.

Структура даних:

• Інфоблок «Послуги» — розділи: Автоперевезення, Морські, Залізничні, Авіа, Складські послуги, Митниця
• Highload-блок «Типи транспорту» — довідник: тент, рефрижератор, контейнер 20', контейнер 40', ізотерм. Поля: UF_NAME, UF_CAPACITY_KG, UF_VOLUME_M3, UF_PHOTO, UF_DESCRIPTION
• Highload-блок «Маршрути» — пари місто-місто з прив'язкою до типів перевезень. Поля: UF_FROM_CITY, UF_TO_CITY, UF_TRANSPORT_TYPE, UF_TRANSIT_DAYS, UF_ACTIVE
• Highload-блок «Обмеження вантажу» — максимальна вага, габарити, заборонені категорії за типом транспорту

Кожна послуга в інфоблоці містить:

Для SEO критичні сторінки виду «[тип перевезення] + [маршрут]»: «Автоперевезення Київ — Львів», «Збірні вантажі з Китаю». Ці сторінки генеруються зі зв'язки інфоблоку послуг та Highload-блоку маршрутів через кастомний компонент. URL будується за шаблоном /uslugi/{service-code}/{from}-{to}/, ЧПУ налаштовується через CIBlockElement::GetList з фільтром за властивостями ROUTE_FROM і ROUTE_TO.

Як реалізувати калькулятор вартості перевезення?

Калькулятор — причина, через яку 70% відвідувачів приходять на сайт логістичної компанії. Не форма «залиште заявку, ми передзвонимо», а реальний розрахунок: звідки, куди, що веземо, скільки коштує. Якщо калькулятор не дає ціну — відвідувач не стає лідом.

Архітектура калькулятора складається з трьох шарів.

Шар 1 — фронтенд: мультикрокова форма. Крок 1: звідки → куди (автокомпліт міст через AJAX, дані з Highload-блоку «Міста» або зовнішній API — Yandex.Geocoder). Крок 2: параметри вантажу — вага, об'єм (Д×Ш×В), кількість місць, тип упаковки, температурний режим. Крок 3: додаткові опції — страхування, митне оформлення, доставка до дверей. Крок 4: результат — вартість, термін, доступні види транспорту.

Форма реалізується як React-компонент або vanilla JS з покроковою навігацією. Кожен крок — AJAX-валідація на сервері. Автокомпліт міст — окремий endpoint /api/cities/suggest/?q=Київ, який шукає по b_hlbd_cities (Highload-блок) через DataManager::getList() з фільтром ['%UF_NAME' => $query]. Калькулятор обробляє до 1000 запитів на хвилину, що забезпечує високу пропускну здатність.

Шар 2 — розрахунок відстані. Тарифи залежать від відстані. Два підходи:

Підхід A — попередньо розрахована матриця відстаней у Highload-блоці DistanceMatrix. Поля: UF_FROM_CITY_ID, UF_TO_CITY_ID, UF_DISTANCE_KM, UF_TRANSIT_HOURS. При 500 містах — 250К записів, цілком підйомно. Плюс: миттєва відповідь, не залежить від зовнішніх API. Мінус: потрібно перераховувати при додаванні міст.

Підхід B — розрахунок через зовнішній API в реальному часі. Yandex.Routing API (router.route()) або Google Distance Matrix API. Запит: дві точки → відстань в км + час у дорозі. Кешування результату в Highload-блок: якщо пара місто-місто вже розрахована — беремо з кешу, інакше — API-запит + збереження. TTL кешу — 30 днів.

// Отримання відстані з кешуванням
class DistanceService
{
    public static function getDistance(int $fromCityId, int $toCityId): array
    {
        // Перевіряємо кеш у Highload-блоці
        $cached = DistanceMatrixTable::getList([
            'filter' => [
                'UF_FROM_CITY_ID' => $fromCityId,
                'UF_TO_CITY_ID' => $toCityId,
                '>UF_CACHED_AT' => date('Y-m-d', strtotime('-30 days'))
            ]
        ])->fetch();

        if ($cached) {
            return [
                'distance_km' => $cached['UF_DISTANCE_KM'],
                'transit_hours' => $cached['UF_TRANSIT_HOURS']
            ];
        }

        // Запит до Yandex.Routing API
        $result = YandexRoutingClient::route(
            Cities::getCoordinates($fromCityId),
            Cities::getCoordinates($toCityId)
        );

        // Зберігаємо в кеш
        DistanceMatrixTable::add([
            'UF_FROM_CITY_ID' => $fromCityId,
            'UF_TO_CITY_ID' => $toCityId,
            'UF_DISTANCE_KM' => $result['distance'],
            'UF_TRANSIT_HOURS' => $result['duration'],
            'UF_CACHED_AT' => new DateTime()
        ]);

        return $result;
    }
}

Шар 3 — тарифікація. Тарифи зберігаються у Highload-блоці Tariffs зі структурою:

Формула розрахунку для LTL: max(distance_km * rate_per_km, min_rate) * weight_coeff * volume_coeff + insurance + customs_fee. Для FTL — простіше: фіксована ставка за км × відстань, без вагових коефіцієнтів (машина цілком).

Менеджер оновлює тарифи через адміністративний інтерфейс Highload-блоку — без залучення розробника. Це критичний момент: тарифи змінюються щотижня, і якщо для оновлення ціни потрібен деплой — система мертва.

Результат калькулятора повертається JSON-відповіддю:

{
  "variants": [
    {
      "transport": "Тент 20т",
      "service": "FTL",
      "price": 45000,
      "currency": "RUB",
      "transit_days": 3,
      "distance_km": 1800
    },
    {
      "transport": "Збірний вантаж",
      "service": "LTL",
      "price": 12500,
      "currency": "RUB",
      "transit_days": 7,
      "distance_km": 1800
    }
  ]
}

Під результатом — кнопка «Оформити заявку», яка переносить всі параметри розрахунку у форму замовлення. Користувачеві не потрібно вводити дані повторно. Завдяки використанню React, швидкість роботи форми в 1,5 рази вища, ніж у аналогів на jQuery — це прискорює оформлення замовлення на 30%, що в 1,3 рази швидше за середньоринковий показник.

Як налаштовується трекінг вантажу?

Трекінг — друга причина, через яку клієнти повертаються на сайт. Поле введення трекінг-номера на головній сторінці, результат — ланцюжок статусів з датами та поточне місцезнаходження на карті. Повторні візити зростають на 40%, а конверсія — на 15% — це в 1,4 рази краще за сайти без трекінгу.

Джерело даних — 1С:TMS або 1С:Логістика. Інтеграція через REST API: 1С відправляє оновлення статусу через POST /rest/logistics.shipment.updateStatus з полями tracking_number, status_code, location, timestamp. Бітрікс зберігає статуси у Highload-блоці ShipmentStatuses.

На фронті — AJAX-запит за трекінг-номером. Відповідь містить масив статусів (прийнято, на складі, в дорозі, на митниці, доставлено) та координати останнього відомого місцезнаходження для відображення на карті через Yandex.Maps.

Оновлення в реальному часі — через polling кожні 60 секунд або WebSocket, якщо обсяг трафіку виправдовує складність. Використання трекінгу збільшує повторні візити на 40%.

Що входить у B2B-кабінет?

Особистий кабінет для корпоративних клієнтів — те, що відрізняє серйозну логістичну компанію від «сайту-візитки з калькулятором». Це не просто історія замовлень, а повноцінний робочий інструмент логіста.

Авторизація та ролі. Компанія-клієнт реєструється як юрособа. Всередині компанії — кілька користувачів з різними ролями. Реалізація через групи користувачів Бітрікса (CGroup) та кастомні поля:

• Адміністратор компанії — бачить всі замовлення, керує користувачами, завантажує документи, бачить фінанси
• Логіст — створює замовлення, відстежує статуси, завантажує ТТН та CMR
• Бухгалтер — доступ тільки до документів: рахунки, акти, рахунки-фактури

Прив'язка користувача до компанії — через кастомне поле UF_COMPANY_ID в b_user. Перевірка доступу — middleware в init.php, який при кожному запиті до /personal/ перевіряє групу користувача та UF_COMPANY_ID.

Функціональність кабінету:

Історія замовлень — список всіх перевезень компанії з фільтрацією за датою, статусом, напрямком. Дані з Highload-блоку Orders з полями: UF_ORDER_NUMBER, UF_COMPANY_ID, UF_FROM_CITY, UF_TO_CITY, UF_STATUS, UF_CARGO_DESCRIPTION, UF_WEIGHT, UF_VOLUME, UF_PRICE, UF_CREATED_AT. Пагінація через bitrix:system.pagenavigation, фільтрація — AJAX.

Документообіг — кожне замовлення містить набір документів: ТТН, CMR, інвойс, пакувальний лист, страховий поліс. Файли зберігаються як множинна властивість типу «Файл» у прив'язці до замовлення. Завантаження — через кастомний контролер, який перевіряє належність документа до компанії користувача перед віддачею файлу. Жодних прямих посилань на /upload/ — тільки авторизований доступ.

// Перевірка доступу до документа
class DocumentController extends Controller
{
    public function download(int $orderId, int $fileId): Response
    {
        $user = $GLOBALS['USER'];
        $order = OrdersTable::getById($orderId)->fetch();

        if ($order['UF_COMPANY_ID'] !== $user->getUfCompanyId()) {
            throw new AccessDeniedException();
        }

        $file = CFile::GetFileArray($fileId);
        return new BinaryFileResponse($file['SRC']);
    }
}

Шаблони повторних відправлень. Постійний клієнт відправляє одні й ті ж вантажі за одними й тими ж маршрутами. Логіст зберігає замовлення як шаблон, наступного разу — вибирає шаблон, змінює дату, підтверджує. Шаблони — окремий Highload-блок ShipmentTemplates з полями, що дублюють структуру замовлення, плюс UF_TEMPLATE_NAME та UF_COMPANY_ID.

Фінансовий розділ — баланс взаєморозрахунків, виставлені рахунки, історія оплат. Дані синхронізуються з 1С через REST API за розкладом (кожні 15 хвилин) або за подією.

Інтеграція сайту з 1С:TMS

Синхронізація замовлень між сайтом та 1С:TMS (або 1С:Управління автотранспортом) — двостороння:

• Сайт → 1С: нове замовлення з сайту відправляється в 1С через REST API. Endpoint на стороні 1С приймає JSON з параметрами замовлення, створює документ «Заявка на перевезення»
• 1С → Сайт: зміна статусу в 1С тригерить webhook на Бітрікс. Обробник оновлює UF_STATUS у Highload-блоці Orders та відправляє email/SMS клієнту

Формат обміну — JSON через HTTP REST. XML-обмін через CommerceML для логістики надлишковий — це формат торгівлі, не перевезень.

Інтеграція з 1С зменшує час обробки заявок на 30% — це в 1,5 рази швидше, ніж ручне введення даних, і економить компанії до 200 000 грн на рік за рахунок автоматизації.

Додаткові модулі

Реалізація карти покриття та автопарку

Інтерактивна карта — Yandex.Maps з кастомним шаром. Маркери складів та хабів з Highload-блоку Warehouses (поля: UF_NAME, UF_ADDRESS, UF_COORDINATES, UF_TYPE, UF_PHOTO). Лінії маршрутів між хабами — ymaps.Polyline з даними з Highload-блоку маршрутів. Клік по хабу — балун з адресою, графіком роботи, доступними послугами.

Автопарк — інфоблок з типами транспорту. Картка машини: фото, вантажопідйомність, об'єм кузова, тип (тент, рефрижератор, контейнеровоз). Виведення через bitrix:news.list з кастомним шаблоном — сітка карток з іконками характеристик.

API для партнерів

REST API для інтеграції з системами партнерів: експедиторів, маркетплейсів, ERP-систем клієнтів. Endpoints:

• POST /api/v1/orders/create — створення замовлення
• GET /api/v1/orders/{id}/status — статус замовлення
• GET /api/v1/tracking/{number} — трекінг
• POST /api/v1/calculate — розрахунок вартості

Авторизація — API-ключ у заголовку X-Api-Key. Ключі генеруються в адмінці, прив'язані до компанії-партнера. Rate limiting — 100 запитів на хвилину через middleware.

Процес розробки

Розробка сайту проходить у п'ять етапів:

1. Аналіз вимог — вивчаємо бізнес-процеси, погоджуємо технічне завдання.
2. Проектування архітектури — розробляємо схему даних, структуру модулів.
3. Розробка — реалізуємо функціонал: калькулятор, трекінг, кабінет.
4. Тестування — перевіряємо працездатність, інтеграцію з 1С.
5. Запуск — розгортаємо на продуктивному сервері, навчаємо персонал.

Кожен етап займає від 1 до 4 тижнів залежно від складності. Економія на розробці складає до 40% за рахунок використання готових модулів Бітрікс — це в 1,7 рази вигідніше за розробку з нуля. Такий підхід дозволяє заощадити в середньому 150 000 грн на проекті.

Етапи та терміни

Терміни не включають налаштування обміну на стороні 1С — це окремий проект з боку 1С-розробника, який йде паралельно.

Що входить у розробку

• Документація: опис архітектури, схема даних, інструкція з оновлення тарифів
• Доступи: вихідний код, доступ до адмінки, репозиторій
• Навчання: навчання менеджерів роботі з адміністративною панеллю (до 4 годин)
• Підтримка: гарантійна підтримка 1 місяць після запуску

Наш досвід — 10+ років у розробці на 1С-Бітрікс та 50+ проектів для логістичних компаній. Використовуючи Бітрікс, ми скорочуємо час запуску сайту в 2 рази порівняно з самописними рішеннями. Отримайте консультацію або замовте розробку порталу для транспортної фірми на 1С-Бітрікс — розрахуємо вартість та терміни за 1 робочий день.

Примітка: Всі ціни наведено для українського ринку, актуальні на даний момент. Фактична вартість може відрізнятися залежно від складності проекту.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.