How a shipment actually
sails through SEALUTION.

Each port record is small but load-bearing: a code, a name, coordinates, a gallery photo, and an active/inactive switch. Deactivate a port instead of deleting it and it simply stops appearing as an option, history stays intact.

A route simply links two ports and states the distance in nautical miles and a standard transit time. That's what lets the Estimator answer "how many days?" before a single voyage is scheduled.

This is the one distinction worth pinning down early, because the two words sound interchangeable and aren't.

Every real ship is registered here: name, IMO number, flag, capacity, a photo gallery, and a status of Active, In Maintenance, Docked, or Retired.

A Service isn't one sailing, it's the pattern a whole lane of sailings follows, e.g. TEST1. Every voyage on that service inherits its rules.

The ordered list of ports a service calls at, built right on the Service's own edit page.

1. Row 1 is the origin, day zero.
2. Every row's transit days is cumulative from that origin, not from the row above it.
3. Dwell hours, how long the vessel sits at that port before it can depart again.
4. Load and discharge checkboxes, a port can be a pure transshipment stop, a pure load, a pure discharge, or both.

A Voyage takes the Service's abstract pattern and pins it to reality: a specific vessel and a specific departure date, under a voyage number like V2629.

Every time a voyage is saved, or its service's rotation or cut-offs change, SEALUTION deletes and rebuilds one row per port in the rotation, this is what actually produces the ETA/ETD/cut-off dates you see everywhere else.

Schedule Search, the standalone "find a sailing" page, and the identical picker built right into the Estimator's Check availability button, answers one question: what sails from A to B, on or after this date? It matches a Load call and a Discharge call that belong to the same voyage, and reports the gap between their dates as the transit time.

The Estimator is a look, don't touch yet tool. Nothing is booked or billed here, it exists so a rep can answer "how much, and when?" in under a minute, then convert the answer straight into a Quotation.

1. Pick an Origin Port and Destination Port, then Check availability, this lists real sailings with ETD, ETA, transit days and the document cut-off date.
2. Choose a Cargo Type and Fleet Type (e.g. Container Ship, 500–2,000 TEU). Only fleet types with an actual sailing on this route are offered.
3. Pick the specific Vessel & Voyage. The panel shows live capacity: firm holds, tentative holds, and what's genuinely available in CBM.
4. Enter gross weight (kg) and volume (CBM).
5. Choose a Service Package, Express, Standard, or Economy (see Reference Data below).
6. Click Calculate Estimate.

A Quotation is the same numbers as the Estimator, but now it's a numbered document (e.g. QTN-446D5F6F) with a client's name on it, ready to send.

1. Start a Quotation directly from the Estimator's result, or from a specific sailing via the Schedule page's Quote button, either way, route, vessel and voyage are pre-filled.
2. Attach it to a Customer, apply a manual discount if you're negotiating, and review the line items.
3. Save it. While a Quotation is live, it places a tentative capacity hold on the chosen voyage, so two reps can't both promise the last container to different clients.
4. Track it through its status: Draft → Sent → Accepted (or Rejected / Expired).

The Invoice is where Operations hands off to Finance. It can be emailed straight to the client from a template, and its payment status is never set by hand, it's recalculated automatically every time money moves.

1. Record a payment, reference, amount, currency, method and date. Removing a payment recalculates the balance instantly, same as adding one.
2. Issue a credit or debit note where needed, and apply or un-apply it against the invoice, the balance and status update live either way.
3. Once the invoice reflects a real booking, click Create Shipment.

A shipment moves through a strict one-way status flow. Status can move forward on its own, but moving it backward, or recovering it out of an exception, is an administrator-only action, by design.

A GPS device attaches to whichever thing it's physically riding on, never directly to a booking. Register and assign devices from GPS Devices; the reconciliation rules that decide what the map shows live in Settings → Map & GPS.

More than one device can be attached to the same target at once, a primary tracker plus a backup is normal in ocean shipping. When that happens, one setting decides what the map actually shows:

If a vessel, its current voyage, and a shipment aboard all have their own devices reporting at once, the most general one wins: vessel beats voyage beats shipment. This only falls through to a more specific level if the more general one has nothing fresh to report.

Every stop in a service's port rotation, and the voyages generated from it, can be tagged with why the ship is calling there, not just loading or discharging cargo:

ETA at each stop is calculated from real distance and the vessel's speed, not a manually-typed guess, hours = distance ÷ speed, leg by leg, carried forward from each stop's actual departure time. A per-stop transit override is there for the rare case where the real world doesn't match the math (weather routing, a known slow patch), leave it blank and the calculation runs itself.

An order captures how the cargo actually gets there, not just where: export or import direction, the feeder vessel and voyage, and, where the route needs it, a separate tug/barge combination for the final leg. Status runs Draft → Confirmed → Loading → Loaded → In Transit → Arrived → Completed, tracked independently of the retail Shipment status flow.

How the order arrived is recorded too, email, WhatsApp, phone, portal, or other, along with the source reference, so a booking that started as a WhatsApp message stays traceable back to it.

Each order holds a spreadsheet-like grid of containers, number, seal, ISO type/size, full or empty, shipper/consignee/notify party, HS code, weight, VGM, and a dangerous-goods flag where it applies. A container can link to a real Shipment record, which is what lets it also show up on the live tracking map.

A large order doesn't have to be typed in row by row, a CSV import matches columns flexibly enough to tolerate the odd typo in a header, previews what it found, and only commits once it's confirmed.

A Bill of Lading groups a set of containers under one shipping document, laden, empty, or draft, export or import, with the usual BL fields (shipper, consignee, notify party, vessel/voyage, ports, incoterms, freight terms) and a status running Draft → Confirmed → Released → Original Issued → Surrendered.

Generates the paperwork a B2B order actually needs, straight from its container grid and Bill of Lading data, a Booking Confirmation (container counts by size and type), a Loading List and Discharging List (full container detail, paginated with repeating headers), a Bill of Lading, and a Cargo Manifest, as PDF, or CSV where a spreadsheet is more useful than a formatted document.

A shared to-do list, not a personal one, every staff member sees every task by default, with priority, due date, and an optional link back to a shipment, quotation, or invoice. The "assigned to me" filter narrows it down without hiding anyone else's work.

Any task can be linked to any other, either as a general "relates to" or a "blocks" dependency, from the task's edit screen, across every status, including tasks already in Review or Done. The read-only Flow view lays every card out in its normal board column and draws each relation as a connector between them, each one in its own colour so several relations in the same area stay visually distinct, "blocks" is the only relation labelled on the diagram, since it's the one that actually changes what can happen next.

An itemized handover document for the last mile, driver, vehicle, items, and a signature status running from Draft through Delivered to Signed. Optionally linked to the shipment it belongs to, so the paper trail and the tracking timeline point at the same reference.

For correcting an invoice without editing the original, a credit note reduces what's owed, a debit note adds to it, each linked back to its source invoice with its own reference number and running total.

The search box in the top bar reaches across shipments, customers, quotations, invoices, vessels, voyages, delivery notes, and more at once, plus page names, so typing "settings" jumps straight there. Results only ever show what your role can already see elsewhere in the app; search never widens access, it just finds things faster.

The real fuel-purchase ledger, separate from just tagging a stop "Refuel" in the schedule: vessel, voyage (optional), port, fuel type, quantity, price, supplier, and invoice reference. Recording one here immediately recalculates that voyage's fuel timetable with the real number, in place of the planning estimate.

The embeddable chat widget runs a configurable flow, built visually in the Flow Editor from message, button, and lookup nodes, that can look a shipment, invoice, quotation, customer, or task up live and answer directly, calculate a freight estimate, or search the sailing schedule. Typing a port name for a route lookup shows live suggestions from the real port list, so a visitor doesn't have to guess the exact spelling.

When a conversation needs a person, "Talk to Our Team" hands it to the staff inbox (Chat Sessions) as a live conversation, separate from the internal team messaging system used for staff-to-staff channels and DMs.

Live GPS pings feed the tracking map while a voyage is under way; once it completes, that recorded track is archived as a compact file, grouped by lane (origin/destination port pair) rather than kept as raw pings forever. The GPS Data page lists every archived trip per lane, with a detail map for one trip, a Compare view to overlay two or more trips on the same lane, and export/import for moving an archive between environments.

Once a lane has a few real archived trips, that recorded history becomes available as a waypoint source when hand-drawing a route, alongside the existing manual and auto-generated options, so a route can be based on where a ship actually sailed, not just a straight line between two ports.

Overview covers the basics for a selected period (7/30/90 days or 12 months), a revenue trend chart, shipment status and cargo-type breakdown, top routes and customers, and cancelled shipments with the revenue lost to them. Advanced adds revenue by port and by vessel, fleet capacity utilization, a period-over-period comparison, and planned-vs-actual transit efficiency. Any section on either tab can be hidden from the Customize menu if it's not relevant to how you work, the choice is remembered per browser.

Press Ctrl+K anywhere and type what you want. “open vessels” and “buka kapal” both land on the same page; so do “find container TEMU1234567” and “cari kontainer”. It only ever offers pages your role can already open, so it finds things faster without widening what anyone can see.

It also starts new work from a sentence. “create shipment from Perawang to Klang for Borneo Timber”, or “buat pengiriman dari Perawang ke Klang untuk Borneo Timber”, opens the New Shipment form with the ports and the customer already filled in, looked up from your real port and customer lists. The same works for anything in your menu, an invoice, a customer, a task, a vessel, an incident, a budget, and the sentence can carry the details: containers (“2x40HC”), weight, volume, departure and arrival dates, vessel, goods and notes. Anything the form has no field for, or any word it did not understand, is written on the result line rather than quietly dropped. It reads the sentence by rules, not with AI, and it never saves anything itself: you check the form and press Save. When a name fits more than one port, it offers each one rather than guessing.

The one thing it can write directly is a meter reading, “log 41,250 hours on main engine”, or the same in Indonesian, and it shows the figure it understood before anything is written. Anything the parser is not certain of is refused rather than guessed. Both the palette and its ability to write can be switched off in Control and Settings.

Container number, ISO type, size, tare, ownership (owned, leased, or shipper-owned), and current condition. Leased boxes carry their lease dates, so a unit you are still paying for after it stopped earning is visible rather than assumed.

Movements are what get recorded: gate-in, stuffing, load, discharge, gate-out, stripping, empty return, off-hire. The container's state is then worked out from that list of movements, never typed in by hand.

That distinction matters more than it sounds. A state somebody sets manually drifts the first time a step is entered late; a state computed from the movements can be rebuilt at any moment and will agree with the paperwork, because the paperwork is what it was built from. If a movement was missed, the answer is to record the movement, not to correct the status.

Demurrage is the box sitting inside the terminal past its free days. Detention is the box outside the terminal, in the customer's yard, past its free days. They are different clocks with different free-day allowances and different rates, and conflating them is how an invoice gets argued away.

Free days and tariffs are configured per customer where they were negotiated per customer. The running charge is computed from the movement timestamps, so it can be shown to the customer with the dates that produced it rather than as a number they have to take on trust.

Damage, customs holds, missing seals and idle units are raised as open exceptions against the container itself, and stay open until somebody closes them with a note. A box can only carry one open exception of a kind at a time, so the same problem cannot be logged five times by five people and then closed once.

The building is modelled the way the people in it describe it: warehouse, zone, aisle, rack, level, bin. Each location has real dimensions and a weight limit, so the system knows a pallet will not fit before somebody carries it there. There is a floor plan you can look at from above and a 3D view for the racking, both drawn from the same configuration, not a picture kept up to date separately.

Every receipt, put-away, pick, transfer, adjustment and dispatch is written to a movement ledger. The quantity you see in a bin is the sum of those movements, cached for speed and rebuildable from scratch at any time.

This is the same discipline used for the accounting trial balance and the container lifecycle, and for the same reason: a stored figure that nobody can reproduce is a figure nobody can defend during a stock take. If the cache and the recomputation ever disagree, that is treated as a bug in the software, not as a discrepancy in the warehouse.

Stock is held either as own stock (you bought it, it is your asset) or in custody (your customer owns it, you are storing it). Custody stock is tracked, counted, picked and billed for exactly like anything else, and it never touches your balance sheet, because it is not yours. Getting this wrong inflates a freight forwarder's assets by the value of their customers' cargo, which is the sort of error an auditor notices.

Goods arrive against an inbound document, get put away into a specific bin, and are later picked against an outbound order, packed into cartons or pallets, and dispatched. Each step names a real location and a real person, so “we received it” and “we can find it” are separate facts that are separately true.

Cycle counts check a slice of the warehouse regularly rather than shutting the whole thing once a year; a full count does the lot. Either way the variance is shown before it is posted, and posting it writes an adjustment movement rather than overwriting a number. Slotting looks at how often each item is actually picked and suggests moving the busy ones closer to where the picking starts.

Bin and item labels are printed from the platform and scanned back into it from an ordinary phone camera, so the person holding the carton is the person recording the move, not somebody copying a list at a desk an hour later. Outside the building, the yard is modelled as rows, stacks and tiers, which is what a container yard actually is.

Your own chart of accounts, with the shipping-specific ones already present. Every journal has to balance to the cent before it will post, there is no “save anyway”. A posted journal is not edited afterwards; it is reversed and replaced, so the history of a correction survives the correction.

An invoice posts revenue, tax and a receivable. A receipt clears the receivable and moves cash. A bunkering record posts fuel cost against the voyage that burned it. A maintenance job that consumed spares posts that cost once, from the warehouse, at the moment the parts left the shelf, not again when somebody remembers. The ledger is a consequence of the operation rather than a second description of it.

Trial balance, profit and loss, balance sheet and cash flow are generated from the journals on demand. The trial balance is rebuilt rather than accumulated, so it cannot slowly drift out of agreement with the entries that produced it. Every figure on a statement can be opened to see the journals behind it.

Ageing comes out of the invoices and receipts themselves, so the collections list and the ledger cannot disagree. Payables do the same for what you owe, bunker suppliers, port agents, hauliers. Bank statement lines are matched against the ledger, and the ones that did not match are shown plainly rather than quietly absorbed, because an unmatched line is usually the interesting one.

PPN is calculated on a fraction basis rather than a flat percentage, which is how the regulation is actually written and where hand-built spreadsheets tend to go wrong by a rupiah or two per line. PPh 15, the special final tax regime for domestic shipping, is opt-in: it applies to some operators and not others, and the system will not assume it applies to you. Tax export produces the filing format.

Vessels, vehicles, containers and equipment are registered as assets and depreciated on two schedules at once: the book schedule you report to shareholders and the fiscal schedule the tax office requires. These genuinely differ, and running only one of them means one of the two audiences is being given the wrong number.

Budgets sit beside actuals per account and per period. Recurring journals (depreciation, accruals, standing charges) post on their schedule instead of on somebody's memory. When a month is closed it stops accepting entries, a closed period that can still be edited is not closed, it is merely labelled.

Systems contain components, components contain parts: main engine → turbocharger → bearing. The question a chief engineer asks is “when did we last service this component”, never “when did we last do maintenance on the ship”, and only the first of those is answerable. Equipment can be marked critical, which is a category rather than a priority: a critical job can only be moved by an approved waiver, and a routine one cannot become critical because somebody was in a hurry.

Meter readings are logged, never overwritten. Current hours is simply the latest reading, so a mistyped figure is corrected by logging the right one, the wrong entry stays visible, with who entered it and when. A field you can edit in place cannot tell you that somebody once entered 41,250 as 4,125.

Real manuals say “every six months or 1,000 running hours, whichever comes first”, and that is supported as written. Picking one half silently would over-service a laid-up vessel and under-service a hard-working one, which are opposite failures with the same cause. Due-ness is computed from the template and the last completion every time it is asked for, never stored as a fact that can go stale.

A job becomes a work order, which is started, completed and then verified by someone other than the person who did it. The meter reading is captured at the moment of completion, so the next interval counts from what was true then rather than from when the paperwork caught up.

Spares come out of the warehouse, which means the cost is posted once, by the warehouse, at the moment the parts left the shelf. There is no separate parts catalogue: a ship's store is an ordinary warehouse. Photographs and video attach to the job as before, during and after, so a repair can be judged later instead of recalled.

A truck's service interval and a generator's are the same idea measured on a different meter, kilometres instead of hours, so they run on the same engine rather than in a second system that would drift out of step with the first. Maintenance appears inside each vessel, vehicle and container record, and there is one platform-wide list you can filter by asset type when you want to see everything that is due at once.

Class and statutory surveys carry their windows, not just their dates, because a survey has a range in which it may legally be done. Bottom surveys, PSC inspections with their deficiencies, dry-dock planning, condition alerts and near-miss reporting each have their own record. Near misses are deliberately kept separate from platform status incidents: they share a word and nothing else, and putting a safety event in the same table as a server outage helps nobody.

A critical job's due date cannot simply be edited. It moves through a deferral: a written reason, a requested new date, and an approval from somebody other than the requester. A waiver nobody signed is just a delay with better presentation, and the difference matters when an inspector asks why.

Trucks are registered on the same footing as vessels: specs, capacity, ownership, documents with expiry dates, and an odometer that feeds the maintenance schedule. Drivers carry their licences and certificates with expiry tracking, so a licence that lapses is caught by a calendar rather than by a roadside check.

A trip is assigned a vehicle and a driver, and links to the shipment it is carrying. Because it is a leg of that shipment rather than an independent record, the customer's tracking view shows door to door without anyone stitching two systems together at the end of the month.

Depots, lanes and the distances between them, refined by the trips your drivers actually make, the road equivalent of learning a sea route from real GPS trails. For refrigerated cargo, temperature is logged along the trip, so a claimed breach is something you can prove or disprove with a record rather than argue about.

A lightweight CRM: name, company, email, phone, address, an assigned account manager, a running shipment count, and a timestamped notes thread, enough context to pick up a relationship mid-conversation.

Three tiers sit on top of every Fleet Type rate as a multiplier. Try the calculator below, purely illustrative, not a live rate.

The classification picked first in the Estimator (e.g. General Cargo). It determines which Fleet Types and handling rules are even eligible for that shipment, before a single vessel is chosen.