The landside layer on top of your RBS
Your RBS runs the terminal. DMSLOG runs the landside around it — appointments, gate automation, billing and connectors — without touching the gate authority you already trust.
RBS (Realtime Business Solutions) — TOPS Expert and TOPX — automates container terminals and depots. DMSLOG bolts on the landside layer around it and writes confirmed events straight back — no rip-and-replace.
DMSLOG plugs into RBS — and the TOS family around it
One documented API, plus EDI (COPARN, CODECO, COARRI, BAPLIE), EIR and FTP, projected into one canonical model next to the systems already on your desk.
Your RBS stays in place
DMSLOG is not a rip-and-replace. RBS keeps its gate and yard authority — we bolt on the four landside bricks it is missing, each one working on its own.
Vehicle Booking System
Gate automation, OCR & Virtual Kiosk
Billing & Web Customer Portal
EDI & API connectors
Bolt on the bricks your RBS is missing — each one plugs in on its own
Appointments on top of RBS
Post-payment slots
Carrier or terminal books
The same Vehicle Booking System behind a million truck appointments a year, reading availability from RBS and writing the confirmed slot back.
A 5-second gate cycle
Read automatically
Validated into RBS
The driver self-serves at a Virtual Kiosk; DMSLOG reads, matches the appointment and hands a clean, validated event to RBS.
Every landside fee in one place
Self-service billing
Reconciled across customers
Amazon-like billing for the landside, bolted onto the TOS you already run — the monthly close shrinks instead of sprawling across spreadsheets.
One canonical model, whatever your TOS
Standards in
Events back to RBS
DMSLOG connects to RBS through its API and EDI feeds, read-only to start, then writes confirmed events back so the TOS stays the single source of truth.
What the landside layer adds — and who gets it
The terminal keeps its TOS
Planners get appointments
Truckers get a 5-second gate
Finance gets self-service billing
IT gets one connector
Start with one brick
Fewer idling trucks at the gate, reported in the same flow
Appointments and a 5-second gate cut queuing and idling on the apron. The same event stream that drives the landside turns into the CO₂ of your terminal moves — scope-3 figures you can report, not a spreadsheet guess.
The platform your landside would run on
Platform scale, live in production — not a pilot.
Containers booked / year
Appointments / year
Carriers on the network
EDI standards into RBS
The shape of the gain
Mechanics, not promises — typical ranges that come from how the landside layer works on top of RBS, not from any one terminal.
1 source of truth
0 re-keying
4–5× / lane
~99.7% OCR
How it plugs into RBS
1. Connect
2. Project
3. Run the landside
4. Write back
We never ask a terminal to leave RBS. DMSLOG sits on top of it and runs the landside — appointments, the gate, billing — and every confirmed event flows straight back into the TOS they already trust.
Questions, answered
No. DMSLOG is not a competing TOS. RBS keeps its gate and yard authority; we bolt on the landside layer around it. See every actor we connect on the port solutions page.
Through API and EDI. COPARN, CODECO, COARRI and BAPLIE feeds — and RBS TOPS/TOPX data — are projected into one canonical model, no rip-and-replace, read-only to start.
Never. Data flows both ways automatically, so the gate and yard stay in sync with RBS and nobody retypes anything.
Yes. Take the Vehicle Booking System first, then add gate automation, billing and connectors when you are ready — each brick works on its own.
RBS here, and the same landside layer bolts onto Navis N4, Tideworks, Octopi and TotalSoft (CATOS) too.
Talk to us about your RBS
Tell us which TOS you run and your peak hours, and we set up a call (Zoom, Teams or Meet) to show the landside layer running on your own flow — no rip-and-replace.
Works with the systems you already run
Navis N4 · Tideworks · Octopi · TotalSoft · CATOS