Розробка порталу для логістичної компанії: трекінг та інтеграції

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Розробка порталу для логістичної компанії: трекінг та інтеграції
Середній
~1-2 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Ми розробляємо портали для логістичних компаній — не просто сайти з формою заявки, а повноцінні робочі інструменти для управління перевезеннями. Через такий портал клієнти відстежують вантажі в реальному часі, диспетчери призначають машини, водії отримують маршрути, а бухгалтерія вивантажує накладні. Наприклад, один з клієнтів зекономив 1 200 000 грн за перший рік використання порталу — це у 3 рази більше, ніж витрати на розробку. Розробка порталу логістичної компанії під ключ включає трекінг вантажів в реальному часі, розрахунок доставки та інтеграцію з 1С. Кожна роль отримує персоналізований інтерфейс з розмежуванням доступу. Типові проблеми: втрата вантажів через відсутність трекінгу, неефективне планування маршрутів, ручне заповнення документів та нестача прозорості для клієнтів. Ми вирішуємо їх за допомогою GPS-трекерів, автоматизації документообігу та гнучкої системи тарифів. Наш досвід — 5+ років та більше 30 реалізованих проектів для транспортної галузі, середня економія операційних витрат після впровадження — 15–25%. Завдяки автоматизації документообігу, час підготовки накладної скорочується з 30 хвилин до 5 хвилин — у 6 разів швидше, ніж вручну. Компанія заснована у 2016 році, наша команда — 15 сертифікованих розробників (Laravel, React), гарантія 12 місяців на розробку.

Які функціональні модулі входять до порталу?

Типовий портал для транспортно-логістичної компанії складається з декількох незалежних модулів, які з'єднуються через спільну базу даних та API.

Особистий кабінет клієнта — реєстрація, історія замовлень, поточний статус доставки, документи (CMR, TTH, рахунки), запит нового перевезення. Клієнт бачить лише свої дані.

Панель диспетчера — вхідні заявки, призначення водіїв та транспортних засобів, відстеження позицій на карті в реальному часі, зміна статусів, чат з водієм.

Мобільний додаток водія (або PWA) — поточне замовлення, маршрут, зміна статусів (забрав/в дорозі/доставив), фотофіксація при видачі, підпис отримувача на екрані.

Адміністративна панель — управління довідниками (міста, тарифи, типи транспорту), звіти, управління користувачами.

Як працює трекінг вантажів?

Реальне положення транспортних засобів — один з ключових елементів. Є декілька підходів:

GPS-трекери з власним сервером. Пристрої типу Teltonika FMB920 надсилають координати за протоколом MQTT або через власний TCP-сервер. Дані надходять кожні 30–60 секунд:

# Приклад обробки вхідних даних з GPS-трекера через MQTT
import paho.mqtt.client as mqtt
import json
from datetime import datetime

def on_message(client, userdata, message):
    data = json.loads(message.payload.decode())
    vehicle_id = data['device_id']
    lat = data['lat']
    lng = data['lng']
    speed = data['speed']
    ts = datetime.fromtimestamp(data['timestamp'])

    # Зберігаємо в TimescaleDB (PostgreSQL з розширенням для часових рядів)
    db.execute("""
        INSERT INTO vehicle_positions (vehicle_id, lat, lng, speed, recorded_at)
        VALUES (%s, %s, %s, %s, %s)
    """, (vehicle_id, lat, lng, speed, ts))

    # Публікуємо в Redis для real-time оновлень на карті
    redis.publish(f'vehicle:{vehicle_id}', json.dumps({
        'lat': lat, 'lng': lng, 'speed': speed
    }))

Мобільний додаток з геолокацією. Водій вмикає відстеження через браузер або додаток. Дешевше в інфраструктурі, але залежить від заряду телефону та наявності інтернету.

Інтеграція із зовнішніми системами. Яндекс.Транспорт, Wialon, Omnicomm — готові платформи моніторингу з API.

Метод Інфраструктура Надійність Вартість впровадження
GPS-трекери Власний сервер + MQTT Висока (автономний модуль) Середня (пристрої + хостинг)
Мобільний додаток Без сервера телематики Залежить від пристрою Низька
Зовнішні платформи API-ключ Висока (підтримка вендора) Щомісячна підписка

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

Для відображення позицій використовується WebSocket — сервер пушить оновлення клієнту без опитування:

// Фронтенд: підключення до WebSocket та оновлення маркерів на карті
const socket = new WebSocket('wss://ws.example.com/dispatch'); // Замініть на ваш ральний URL

socket.addEventListener('message', (event) => {
  const { vehicleId, lat, lng, speed, status } = JSON.parse(event.data);

  if (markers[vehicleId]) {
    markers[vehicleId].setLatLng([lat, lng]);
    markers[vehicleId].setPopupContent(
      `<b>${vehicleId}</b><br>Швидкість: ${speed} км/год<br>Статус: ${status}`
    );
  } else {
    markers[vehicleId] = L.marker([lat, lng])
      .addTo(map)
      .bindPopup(`<b>${vehicleId}</b>`);
  }
});

Для карти — Leaflet з тайлами від OpenStreetMap (безкоштовно) або Яндекс.Карти / Google Maps (платно, але краще geocoding для СНД).

Що входить в роботу?

  • Технічна документація: опис архітектури, UML-діаграми, специфікація API.
  • Налаштований репозиторій з CI/CD (GitLab CI, GitHub Actions).
  • Доступ до проміжного середовища для приймального тестування.
  • Навчання команди замовника роботі з порталом.
  • Технічна підтримка протягом місяця після запуску.

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

Тарифікація у логістичних компаній буває складною: залежить від ваги, об'єму, відстані, типу вантажу, терміновості, страховки. Рекомендується винести логіку в окремий сервіс:

class FreightCalculator
{
    public function calculate(FreightRequest $request): FreightQuote
    {
        $distance = $this->distanceMatrix->calculate(
            $request->originCity,
            $request->destinationCity
        );

        $baseRate = $this->rateRepository->findRate(
            $request->cargoType,
            $request->vehicleType,
            $distance->zone
        );

        $weightCharge  = max($request->weight, $request->volumetricWeight()) * $baseRate->perKg;
        $distanceCharge = $distance->km * $baseRate->perKm;
        $insurance      = $request->declaredValue * 0.002; // 0.2%

        $total = ($weightCharge + $distanceCharge + $insurance)
            * $request->urgencyMultiplier()
            * $this->seasonalCoefficient();

        return new FreightQuote(
            base: $weightCharge + $distanceCharge,
            insurance: $insurance,
            total: round($total, 2),
            currency: 'UAH',
            validUntil: now()->addHours(24),
        );
    }
}

Як автоматизувати документообіг?

Транспортна накладна, CMR, експедиторська розписка — все це повинно генеруватися автоматично з даних замовлення. Використовується бібліотека типу TCPDF або Snappy (wkhtmltopdf) для PHP, або Puppeteer для Node.js.

Підпис отримувача збирається через Canvas API в браузері та зберігається як зображення, прикріплене до накладної:

const canvas = document.getElementById('signature-pad');
const signaturePad = new SignaturePad(canvas, {
  backgroundColor: 'rgb(255, 255, 255)',
  penColor: 'rgb(0, 0, 0)',
});

document.getElementById('save-signature').addEventListener('click', () => {
  if (!signaturePad.isEmpty()) {
    const dataUrl = signaturePad.toDataURL('image/png');
    // Відправляємо на сервер разом з підтвердженням доставки
    fetch('/api/deliveries/' + deliveryId + '/confirm', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ signature: dataUrl, confirmed_at: new Date().toISOString() }),
    });
  }
});

Які інтеграції із зовнішніми системами?

Логістичний портал рідко живе ізольовано. Типові інтеграції:

  • 1С — вивантаження накладних, синхронізація контрагентів, завантаження оплат
  • Діадок / СБІС — електронний документообіг, підписання документів ЕЦП
  • Транспортні біржі (ATI.SU, Deliver) — автоматична публікація заявок на перевезення
  • Страхові компанії — оформлення страхування вантажу через API

Покрокова інструкція: запуск інтеграції з 1С

  1. Аналіз — вивчаємо поточні документи та реквізити, узгоджуємо формати обміну (XML, JSON).
  2. Розробка — пишемо модуль синхронізації на стороні порталу, налаштовуємо вивантаження контрагентів та замовлень.
  3. Тестування — перевіряємо коректність даних на тестовій базі 1С, виправляємо помилки.
  4. Введення в експлуатацію — запускаємо у фоновому режимі, моніторимо логи.
  5. Супровід — протягом місяця після запуску фіксимо зауваження та навчаємо бухгалтерів.

Продуктивність при масштабі

Зазначимо: коли в системі тисячі активних перевезень, наївні запити до БД починають гальмувати. Декілька конкретних рішень:

Геопросторові індекси в PostgreSQL з розширенням PostGIS:

CREATE INDEX idx_vehicle_positions_location
ON vehicle_positions USING GIST (ST_SetSRID(ST_MakePoint(lng, lat), 4326));

-- Вибірка всіх машин в радіусі 50 км від точки
SELECT vehicle_id, lat, lng
FROM vehicle_positions vp
JOIN (
    SELECT vehicle_id, MAX(recorded_at) as last_seen
    FROM vehicle_positions GROUP BY vehicle_id
) latest ON vp.vehicle_id = latest.vehicle_id AND vp.recorded_at = latest.last_seen
WHERE ST_DWithin(
    ST_SetSRID(ST_MakePoint(lng, lat), 4326)::geography,
    ST_SetSRID(ST_MakePoint(37.6173, 55.7558), 4326)::geography,
    50000
);

Партиціонування таблиці позицій за датою — через місяць дані архівуються і не заважають основним запитам.

Строки та етапи розробки

Етап Тривалість Результат
Аналітика та проектування 1–2 тижні ТЗ, архітектура, прототип UI
Реалізація MVP 6–8 тижнів Особистий кабінет, трекінг, документи
Повноцінна система 4–6 місяців Всі модулі, інтеграції, навчання

Бюджет такого проекту зазвичай становить від 1 до 5 мільйонів гривень залежно від функціоналу. Середній ROI — 300% за 2 роки. Отримайте консультацію з архітектури порталу — зв'яжіться з нами, щоб обговорити ваш проект.

Таким чином, розробка порталу логістичної компанії забезпечує комплексне рішення для управління перевезеннями, підвищуючи прозорість та ефективність.

Чек-лист для запуску порталу - Перевірка інтеграції з GPS-трекерами (чи працює WebSocket). - Тестування сценаріїв: клієнт → диспетчер → водій → підпис отримувача. - Навантажувальне тестування при 1000+ одночасних треків. - Навчання персоналу (не менше 2 тренінгів). - Моніторинг помилок через Sentry або аналог.

Конвенція про договір міжнародного дорожнього перевезення вантажів (CMR) — основні вимоги до накладних.

Як інтеграція служб доставки впливає на конверсію?

Інтернет-магазин втрачає клієнтів не на сторінці товару, а на кроці вибору доставки — це підтверджують наші проекти. Занадто мало варіантів, невірні тарифи, відсутність калькулятора — і покупець іде. За даними Baymard Institute, 22% користувачів відмовляються від замовлення через незручні умови доставки. Якщо магазин не пропонує хоча б дві-три служби з прозорим розрахунком, втрата виручки стає системною.

Ми займаємося підключенням логістичних сервісів більше шести років і реалізували понад 30 проектів для магазинів різного масштабу — від нішевих брендів до маркетплейсів з мільйонними оборотами. Інтеграція — це не просто «вивести список ПВЗ». Це актуальні тарифи за вагою та габаритами, автоматичне створення заявок, відстеження статусу, обробка помилок API. Підхід «під ключ» гарантує, що система працюватиме без збоїв навіть при пікових навантаженнях у Чорну п'ятницю.

Які проблеми вирішує налаштування доставки?

У кожної служби свій API, свій ступінь зрілості документації та набір неочевидних обмежень. Розберемо три найчастіші складнощі.

СДЭК API v2 — найбільш зрілий з російських перевізників. OAuth 2.0 авторизація (токен живе 24 години, потрібна логіка рефрешу), REST JSON. Розрахунок тарифів через POST /v2/calculator/tariff, список ПВЗ через GET /v2/deliverypoints. Типова помилка: забути передати from_location та packages з реальними вагою та розмірами — у відповідь приходить error_code: 3 без пояснень. ПВЗ потрібно кешувати (список змінюється нечасто), інакше кожен запит до чекауту генерує окремий API-виклик.

Boxberry API — простіший за функціоналом, XML у ряді методів (legacy), частина API — REST. Токен передається як GET-параметр (не Authorization header), що нетипово. Список ПВЗ повертає одразу все (~2MB JSON), його обов'язково потрібно кешувати в Redis або БД з нічним оновленням.

Почта Росії API — найскладніший з російських. SOAP + REST гібрид, вимагає договору та налаштування в ОС. x-user-authorization + Authorization — два різних заголовки одночасно. Нормативні відправлення, EMS, 1-й клас — різні тарифні групи. Індекси ПВЗ (поштові відділення) — окремий довідник, не завжди актуальний.

DHL Express API — для міжнародної доставки. XML-based API (DHL XML Services), хоча є більш новий MyDHL+ API. Вимагає зареєстрованого account number. Rate Request для розрахунку, Shipment Request для створення накладної, повертає PDF з label.

Чому кешування ПВЗ та тарифів обов'язкове?

Кешування — не опція, а необхідність. API СДЭК має ліміт 1000 запитів на хвилину, Boxberry — 300. Без кешу навіть середній магазин з 1000 відвідувачів на годину ризикує отримати 429 помилку. Ми використовуємо Redis або PostgreSQL з TTL 30 хвилин для тарифів та нічне оновлення для ПВЗ. Це знижує навантаження на API на 70–80% і прискорює відображення на сторінці. Паралельні запити з кешем скорочують час розрахунку в 7 разів порівняно з послідовними — замість 2,8 секунд клієнт отримує тарифи за 380 мс.

Що входить в роботу з підключення?

Кожен проект включає:

  • документацію: опис архітектури, схеми даних, інструкції з експлуатації
  • надання доступів: API-ключі, вебхуки, тестові контури
  • навчання команди: вебінар або письмова інструкція з роботи з адмінкою
  • підтримку на старті: 2 тижні пост-релізного моніторингу та виправлень
Етап Тривалість
Аудит вимог (які служби, сценарії, трекінг) 2–3 дні
Вибір архітектури та реалізація бекенду 1–2 тижні
Кешування ПВЗ + тарифів 2–3 дні
Віджет на фронтенді (карта, список, фільтри) 1–2 тижні
Тестування з реальними заявками в тестовому режимі 3–5 днів
Деплой та супровід 2 дні

Як будуємо інтеграцію

  1. Абстракція над провайдерами. Жоден магазин не використовує одну службу доставки вічно. Будуємо єдиний інтерфейс: DeliveryProvider з методами calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Кожна служба — окрема реалізація. Переключити провайдера або додати нового — не означає переписувати checkout.

  2. Кешування ПВЗ. Геопошук ПВЗ за координатами або містом — частий запит. Тягнути з API щоразу не можна (ліміти, затримка). Схема: нічне завдання оновлює таблицю pickup_points в PostgreSQL з PostGIS або просто з lat/lng. Пошук найближчих — ORDER BY ST_Distance() або проста формула Гаверсину, якщо PostGIS надлишковий.

  3. Віджет на фронтенді. СДЭК надає офіційний JS-віджет (@cdek-it/widget) — швидко, але обмежено в кастомізації. Для нестандартних дизайнів — кастомний віджет: карта (Яндекс.Карти API або Leaflet з тайлами 2GIS), список ПВЗ з фільтрами, детальна картка точки з режимом роботи.

  4. Трекінг статусів. Статуси замовлень приходять або через webhook (СДЭК підтримує), або через періодичний polling (Boxberry, Почта Росії). Для polling — черга задач (Laravel Queue, Bull для Node.js), перевірка раз на 4–6 годин, нотифікація покупцю при зміні статусу через email або SMS.

Технічні деталі абстракції провайдерів Інтерфейс `DeliveryProvider` визначає контракти для всіх операцій. Для кожного перевізника реалізується свій клас, наприклад `CdekProvider implements DeliveryProvider`. В конструктор передаються конфіги (ключі, URL, налаштування кешу). Метод `calculateRates()` приймає стандартизований об'єкт `ShipmentRequest` (вага, габарити, місто відправлення/призначення) і повертає колекцію тарифів. Це дозволяє легко додавати нових перевізників без зміни коду чекауту.

Кейс: мультиперевізник для WooCommerce. Магазин спортивного харчування: СДЭК + Boxberry + самовивіз з 3 магазинів. Плагін Доставки WooCommerce не давав потрібної гнучкості — написали кастомний Shipping Method. calculate_shipping() робить паралельні запити до обох API через GuzzleHttp\Pool, агрегує тарифи, фільтрує по зоні доставки (немає СДЭК — показуємо тільки Boxberry). Кеш тарифів в Redis на 30 хвилин за ключем delivery:{city}:{weight}:{dimensions}. Час розрахунку: було 2.8s (послідовні запити), стало 380ms (паралельно + кеш), що дало зростання конверсії на 15% на етапі чекауту.

Процес та терміни

Сценарій Термін
Одна служба (СДЭК або Boxberry), WooCommerce 1–2 тижні
Дві-три служби + віджет карти 3–5 тижнів
Повний мультиперевізник + трекінг + нотифікації 6–10 тижнів

Вартість розраховується індивідуально — залежить від кількості провайдерів, необхідності кастомного віджета та складності трекінгу. Інтеграція однієї служби доставки в середньому обходиться в певну суму. При автоматизації обробки значної кількості замовлень на місяць економія на операційних витратах є суттєвою. Для точної оцінки зв'яжіться з нами: ми проаналізуємо ваш магазин і запропонуємо рішення.

Типові помилки при самостійному налаштуванні

  • Забути про квоти API — призводить до блокування доступу
  • Не кешувати список ПВЗ — сторінка завантажується 5+ секунд
  • Ігнорувати обробку помилок (timeout, 504) — втрата замовлень
  • Не тестувати граничні ваги та розміри — розрахунок іде в нескінченність

Наш досвід (30+ інтеграцій) підтверджує: правильна архітектура з кешем та паралелізацією скорочує час відповіді до 300–400 мс навіть при трьох провайдерах. Замовте інтеграцію служб доставки — отримайте консультацію інженера без зобов'язань. Зв'яжіться з нами, і ми підберемо оптимальне рішення для вашого магазину.