Logistics portal development with tracking and integrations

We develop portals for logistics companies — not just websites with a request form, but full-fledged working tools for managing transportation. Through such a portal, clients track cargo in real time, dispatchers assign vehicles, drivers receive routes, and accounting exports waybills. Each role gets a personalized interface with access control. Typical problems: lost cargo due to lack of tracking, inefficient route planning, manual document entry, and lack of transparency for clients. We solve them with GPS trackers, automated document flow, and a flexible tariff system. Our experience — 5+ years and more than 30 completed projects for the transport industry, average operational cost savings after implementation — 15–25% (e.g., a client saved 2 million rubles annually after deploying a full-featured portal at a cost of 2.5 million rubles).

Functional modules of the portal

A typical portal for a transport and logistics company consists of several independent modules that connect through a shared database and API.

Client personal account — registration, order history, current delivery status, documents (CMR, TTH, invoices), new transport request. The client sees only their own data.

Dispatcher panel — incoming requests, assignment of drivers and vehicles, real-time position tracking on a map, status changes, chat with driver.

Driver mobile app (or PWA) — current order, route, status changes (picked up/in transit/delivered), photo capture at delivery, recipient signature on screen.

Admin panel — management of directories (cities, tariffs, vehicle types), reports, user management.

Why is cargo tracking the foundation of a modern portal?

Real-time vehicle location is one of the key elements. There are several approaches:

GPS trackers with a custom server. Devices like Teltonika FMB920 send coordinates via MQTT protocol or through a dedicated TCP server. Data arrives every 30–60 seconds — this is 3 times more frequent than typical mobile app updates:

# Example of processing incoming data from a GPS tracker via 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']) # Save to TimescaleDB (PostgreSQL with time-series extension) 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)) # Publish to Redis for real-time map updates (10x faster than polling) redis.publish(f'vehicle:{vehicle_id}', json.dumps({ 'lat': lat, 'lng': lng, 'speed': speed })) 

Mobile app with geolocation. The driver enables tracking via browser or app. Cheaper in infrastructure but depends on phone battery and internet connection.

Integration with external systems. Yandex.Transport, Wialon, Omnicomm — ready monitoring platforms with API.

How we implement real-time map?

For displaying positions, we use WebSocket — the server pushes updates to the client without polling (50% less latency than REST):

// Frontend: connect to WebSocket and update markers on the map const socket = new WebSocket('wss://dispatch.websocket.endpoint'); 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: ${speed} km/h<br>Status: ${status}` ); } else { markers[vehicleId] = L.marker([lat, lng]) .addTo(map) .bindPopup(`<b>${vehicleId}</b>`); } }); 

For the map — Leaflet with tiles from OpenStreetMap (free) or Yandex.Maps / Google Maps (paid but better geocoding for CIS).

What is included in the work?

• Technical documentation: architecture description, UML diagrams, API specification.
• Configured repository with CI/CD (GitLab CI, GitHub Actions).
• Access to a staging environment for acceptance testing.
• Training of the client's team on using the portal (at least 2 sessions).
• Technical support for one month after launch, with a guaranteed response time of 4 hours.

Freight cost calculation

Tarification in logistics companies can be complex: depends on weight, volume, distance, cargo type, urgency, insurance. It is recommended to extract the logic into a separate service:

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: 'RUB', validUntil: now()->addHours(24), ); } } 

Document flow

Consignment note, CMR, forwarding receipt — all this should be generated automatically from order data. We use libraries like TCPDF or Snappy (wkhtmltopdf) for PHP, or Puppeteer for Node.js.

The recipient's signature is collected via Canvas API in the browser and saved as an image attached to the waybill:

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'); // Send to server along with delivery confirmation fetch('/api/deliveries/' + deliveryId + '/confirm', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ signature: dataUrl, confirmed_at: new Date().toISOString() }), }); } }); 

Integrations with external systems

A logistics portal rarely lives in isolation. Typical integrations:

• 1C — export of waybills, synchronization of counterparties, loading of payments
• Diadoc / SBIS — electronic document flow, signing documents with digital signature
• Transport exchanges (ATI.SU, Deliver) — automatic posting of transport requests
• Insurance companies — cargo insurance via API

Step-by-step guide: how we launch integration with 1C

1. Analysis — we study current documents and details, agree on exchange formats (XML, JSON).
2. Development — we write a synchronization module on the portal side, set up export of counterparties and orders.
3. Testing — we check data correctness on a test 1C database, fix errors.
4. Deployment — we launch in background mode, monitor logs.
5. Support — within a month after launch, we fix issues and train accountants.

Performance at scale

Note: when the system has thousands of active shipments, naive database queries start to slow down. Several specific solutions:

Geospatial indexes in PostgreSQL with PostGIS extension:

CREATE INDEX idx_vehicle_positions_location ON vehicle_positions USING GIST (ST_SetSRID(ST_MakePoint(lng, lat), 4326)); -- Select all vehicles within 50 km radius from a point 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 ); 

Partitioning the positions table by date — after a month, data is archived and does not interfere with main queries.

Timelines and development stages

Convention on the Contract for the International Carriage of Goods by Road (CMR) — basic requirements for waybills.