Skip to main content

Multimodal transportation and legs

Multimodal transportation is the delivery of cargo using several modes of transport or through several carriers with transshipments. For example: a truck takes the cargo from the plant to a railway terminal, the container goes by rail to a port, by sea to a foreign port, and by road to the final receiver.

In LogiFlow such transportation is drawn up as one shipment (or one request) with several legs.

What a leg (LogisticLeg) is​

A transportation leg (LogisticLeg in the code) is one section of the route with its own parties, carrier, addresses and dates. The leg is the place where LogiFlow stores the route and the carrier. You enter them in the familiar form of a request (the "Logistics details" block) or of a shipment, and the system stores them as the leg(s) of that record. A simple transportation has one leg; a multimodal one has several.

Every leg contains:

  • The sender of the leg — who hands over the cargo on this section.
  • The receiver of the leg — who accepts the cargo on this section.
  • The carrier — who carries it on this section.
  • The driver, the vehicle, and if needed the trailer — for the legs of a shipment.
  • The addresses of the start and the end of the section.
  • The start date and the end date of the leg.
  • The order — the number of the leg in the chain (1, 2, 3…).
A leg belongs either to a request or to a shipment

A single leg is bound strictly to one entity — either to a request or to a shipment (but not to both at once). In practice:

  • A simple transportation by one vehicle for one client — the leg(s) live on the shipment.
  • A groupage cargo of several clients (each with their own section) — it is convenient to keep the legs on the clients' requests.

An important difference regarding transport: the legs of a shipment contain the transport data (driver, vehicle, trailer) — they are set right in the shipment wizard on the "Transport" step. The legs of a request store only the route and the carrier, without transport — the specific vehicle and driver appear at the shipment level.

For most users the placement of a leg is a detail: the interface shows the legs where they are defined. What matters is only that different clients in a groupage transportation can have their own legs.

The types of the leg's parties​

The sender, the receiver and the carrier are set not as free text (although manual input is possible too) but through a party type:

  • Client — a client from the system (available for the sender and the receiver).
  • Counterparty — an external organisation (available for the sender, the receiver and the carrier).
  • Account/Cash register (a legal entity of the company) — one of your legal entities (available for all three roles).
  • Manually — arbitrary text, if the party is not in the directories.
A warehouse as a party

There is no separate "warehouse" type. An intermediate warehouse or terminal is drawn up as a counterparty or as your legal entity/account — depending on whose warehouse it is.

The address of a party​

The address of every party can be taken from three sources:

  • From the address book — an address from the directory (with geolocation).
  • From the requisites — the actual address of the selected party.
  • Manually — arbitrary text.

The requisites of the parties​

For print forms and calculations the system derives the requisites automatically — from the sender, the receiver and the carrier selected on the leg (it takes their requisites as a client/counterparty/legal entity). There is no need to enter the requisites separately on the leg — it is enough to specify the parties correctly.

When to use several legs​

Create additional legs if:

  • Different carriers work on the different sections.
  • The mode of transport changes (road → rail → sea → road).
  • There is an intermediate warehouse or a customs terminal with a transshipment.
  • The deadlines and the cost of each section need to be accounted for separately.

If, however, the transportation goes by one vehicle from point A to point B, one leg is enough.

Adding a leg​

  1. Open the shipment card (or the request card).
  2. On the "Route" tab (for a shipment) click "+ Add leg".
  3. Fill in the parties, the carrier, the addresses and the planned dates. For a leg of a shipment additionally specify the transport (driver, vehicle, trailer).
  4. Save.

The leg is automatically assigned the next sequence number in the chain. This is exactly how a multimodal transportation is drawn up: several legs on one shipment (for example road → rail → road), each with its own carrier, transport and section of the route.

The sender of a new leg is the receiver of the previous one

The prefill follows the joint in the route, not "field to field": into the sender of the new leg the system copies the receiver of the previous leg together with its address. The logic is simple — where the previous carrier handed the cargo over, the next one picks it up; there is one transfer point.

The receiver of the new leg is not prefilled — you enter it yourself, because the system has no way of knowing where the cargo goes next.

If the previous leg has an ETrN consignment note

Then, instead of the usual form, a wizard opens: first the question "what changes?" with groups (transport · receiver · carrier), and you only fill in what you ticked — the rest is inherited from the previous leg silently and shown in the final summary. This is how a relay is drawn up: changing the driver or the vehicle in the middle of the route. See Corrections in ETrN.

The dates of a leg and the time calculation​

Every leg has two key dates:

  • The start date of the leg — when the carrier accepted the cargo on their section.
  • The end date of the leg — when they handed the cargo over further.

As the transportation is carried out, the warehouse worker or the manager fills in these dates. Based on them, analytics calculates the total transportation time and the time on each section.

How the auto-filling of the dates works

The system helps to fill in the end dates of the legs so that there are no gaps in the chronology:

  • If a leg has no end date specified, it is taken automatically from the start date of the next leg. The principle: "the end of the previous one = the start of the next one".
  • For the last leg the end date is set automatically (if it is empty) to the current date — but only when the request/shipment moves into a final status.

The auto-filling only concerns empty fields: if you have specified an end date manually, it is kept as it is and is not overwritten.

A nuance of the auto-filling of the last leg

The end date of the last leg on the transition into a final status is set to the current server date, not to the planned/actual delivery date of the shipment. If the actual delivery happened earlier or later, check it and correct the end date manually if needed.

Finances across the legs​

In a multimodal transportation the expenses are usually split across the legs — a separate payment to each carrier:

  • One income from the client (the client sees the total amount and knows nothing about the legs).
  • Several expenses — one per carrier.

The profitability of the transportation is calculated as the income minus the sum of all the expenses across all the legs. For details see Financial operations.

Analytics across the legs​

The analytics section has a tab for the transportation legs ("Legs" / multimodal analytics). It helps to see how much time the different sections take on average and where time is lost. This is useful for optimising the routes and for negotiating with contractors. The terms are in the analytics glossary.

Who can do what with transportation legs (roles)​

ActionAdministratorHeadManagerWarehouse workerClient
View legs✅✅✅✅✅ (within their own records)
Create / edit / delete legs✅✅✅❌❌
About the warehouse worker and the client roles

The warehouse worker sees the legs and fills in the actual dates through a status change, but cannot create or delete legs — that is available to the manager and above. The client sees the legs only of their own requests/shipments.

The client does not see who carries the cargo

On the legs the client is shown the route, the parties, the addresses and the dates — but not the carrier (its name, details and contact phone) and not the transport (driver, vehicle, trailer). This is the freight forwarder's commercial boundary: the carrier's name and the rate you work with them at are your information, not the client's.

The restriction applies both in the interface and in the API: the hiding is not cosmetic, those fields are simply not given to the client. The same rule works in the request list — the carrier column is empty for a client.

Frequently asked questions​

Can the order of the legs be changed? The order of the legs is set by the number (1, 2, 3…) and is assigned when a leg is added. There is no separate drag-and-drop of legs in the interface — build the chain by adding the legs in the required sequence.

What if a leg was cancelled (the cargo was transshipped into another vehicle, the carrier changed)? Simply edit the leg (change the carrier/parties/dates) or delete the unnecessary leg and add the current one. There is no separate "cancelled leg" state in the system — a leg either exists or is deleted.

A leg with an issued ETrN cannot be deleted

If an electronic consignment note has already been issued for a leg, the system will refuse: "The leg cannot be deleted — an active ETrN refers to it." In that case a change of the driver, the vehicle, the receiver or the carrier is drawn up not by deleting the leg but by amendments to the consignment note itself — see Corrections and non-standard situations.

I made two shipments instead of one with two legs. What do I do? Shipments cannot be merged automatically. Transfer the data manually: add the missing legs to one of the shipments, reattach the requests and delete the unnecessary shipment. Transfer the files by downloading and re-uploading them (there is no moving of files between records — see Files).

What's next​

  • Shipments — general work with shipments.
  • Requests — legs on the request side (groupage cargo).
  • Analytics — reports, including on the legs.