Financial operations
A financial operation in LogiFlow is the unit of financial accounting: a bill issued to a counterparty or received from one, or a payment (incoming or outgoing). All operations live in the Finances section, where you can create, filter, post, unpost, link and export them.
| Role | Access to the "Finances" section |
|---|---|
| Administrator | Full access: view, create, edit, delete, post, link. |
| Head | Full access (same as administrator). |
| Client | View own operations only. Cannot create, edit or post. |
| Manager | The section is not displayed. |
| Warehouse worker | The section is not displayed. |
Further in this article, each action states who can perform it.
Two dimensions of an operation: direction and document type
This is the key principle — without it the finance module makes no sense. Every operation has two independent attributes, and they must not be confused.
1. Direction of money (operation type)
- Incoming — money (or an obligation in our favour) moves towards the company.
- Outgoing — money (or an obligation of the company) moves away from the company.
2. Document type
- Bill — an accrual document. It records an obligation: who owes whom. On its own it does not move any money through an account.
- Payment — a money movement document. It records the fact that money came in or went out through a specific account/cash register.
The combination of these two attributes defines the meaning of the operation:
| Document type | Direction | Business meaning |
|---|---|---|
| Bill | Incoming | A bill was issued to us — we owe the counterparty (accounts payable). |
| Bill | Outgoing | We issued a bill to the client — the client owes us (accounts receivable). |
| Payment | Incoming | We received money (for example, the client paid a bill). |
| Payment | Outgoing | We paid money out (for example, we paid the carrier's services). |
"Bill" = obligation, "Payment" = money. The document type determines what exactly changes when you post: the counterparty balance, the account balance, or both. Details are in What "posting" an operation means.
What an operation consists of
| Field | What it means |
|---|---|
| Number | A unique numeric identifier. Assigned automatically and never changes. |
| Payment date | The date of the business transaction (the payment date/due date). Not to be confused with the record creation date. Debt aging is calculated from this date. |
| Operation type | Incoming or Outgoing — the direction (see above). |
| Document type | Bill or Payment (see above). |
| Counterparty | Who we settle with. This is either a client — a system user, or an external counterparty from the reference data. Exactly one of the two is filled in. |
| Item | A category from the income/expense items reference data: "Transportation", "Warehouse rent", "Taxes", etc. |
| Account/cash | Where the money comes from/goes to: a bank account, a cash register, a wallet. Selected at creation time; its currency becomes the document currency. Used when posting payments (see below). |
| Amount and currency | The monetary value and currency of the operation. The currency is set by the selected account (it is not chosen separately). For a bill the amount is built up from the services; for a payment it is entered manually. |
| Remaining (document balance) | How much of the document is still not closed by links. In the table this is the "Remaining" column. For a bill this is the "remaining to pay", for a payment the "remaining to allocate". For a posted document it initially equals the amount and decreases as allocation proceeds (see Allocating payments). |
| Paid | A service flag. Set automatically: an operation counts as paid when it is posted and its "document balance" equals zero. Not editable manually. |
| Linked shipment / request | The link to a specific carriage — required for profitability analytics. |
| Basis | A reference to another operation used as the basis. |
| Comment | Free text. |
| Posted | The main accounting flag (see What "posting" means). |
A single operation cannot specify both a client-user and an external counterparty — exactly one field must be filled in. An operation cannot be saved without a counterparty.
Bill line items by service
A document of type Bill has a mandatory table of services — for example: "Transportation — 50,000 RUB" + "Insurance — 5,000 RUB". Each line refers to a service from the services reference data, the line specifies quantity and price, and the line total is calculated automatically. The bill amount is the sum of the service lines (the "Amount" field of a bill is read-only).
A bill must contain at least one service — otherwise the document will not be saved (a zero amount cannot be entered). Services are bound to a currency: the list only offers services in the currency of the selected account. The services reference data is maintained by the administrator and the head — see Reference data → Services.
There is no separate VAT field in the operation: the tax is determined by the account the document is issued on, and it is extracted from the amount rather than added on top. A line of "50,000 RUB" at a 22% rate is 40,983.61 RUB net of VAT and 9,016.39 RUB of tax. The rate is an example; the one on the account is used.
The "net / VAT / total" breakdown appears in the printable bill form; the electronic waybill takes it from there as well. How the mode and rate are set — VAT mode and rate.
A document of type Payment has no service table — its amount is entered manually.
Bill line from a tariff
If the bill is linked to a request in which a tariff has been selected, you do not need to calculate the line by hand. Next to the "Add service" button there is "Add from tariff" — one click adds a line with the quantity, price and amount already calculated.
The button is available everywhere the bill service table is edited: in the operation creation wizard (the "Services" step), in the "create bill from request" dialog, and in the bill card in edit mode.
What gets filled into the line:
| Line field | Where it comes from |
|---|---|
| Service | The service specified in the tariff itself (there is no dropdown — the button's tooltip shows which service will be added). |
| Quantity | The weight or volume of the request: the actual value if it has been entered, otherwise the declared one. If volumetric weight is enabled on the tariff, the greater of "physical weight" / "volume × factor" is used. |
| Price | The tariff rate, recalculated per unit and converted into the bill currency. |
| Amount | Quantity × price. |
The amount is calculated from the snapshot of the tariff conditions captured in the request at the moment the tariff was selected, not from the current state of the reference data: editing the price list does not change already issued bills. The exchange rate is taken as of the document date (the "Payment date" field), not as of today. When the bill is saved, the server recalculates the line from scratch and stores the applied rate and its date together with the line — so that later it can be explained where the amount came from.
When the button is unavailable — the tooltip names the reason:
| Tooltip | What to do |
|---|---|
| "Select a request in the bill first" | Fill in the "Request" field on the "Details" step. |
| "No tariff selected in the request" | Open the request and select a tariff. |
| "Could not determine the tariff service" | The tariff is not readable by your role (the tariffs reference data is available to manager level and above). |
| "The tariff service currency (EUR) does not match the bill currency (RUB)" | The currency of the service must match the bill currency; the currency of the rate itself may be anything — it gets converted. Select an account in the required currency, or create a tariff whose service is in that currency. |
A few more rejections come after the click: "A line for this service already exists in the bill" (the same tariff service cannot be added twice), plus calculation messages — "weight/volume is not filled in for the request", "no EUR rate defined for …". The full list is in Shipping calculation.
If the actual weight of the request, the exchange rate or the rate in the reference data changes, an already added line does not change. The document comes first. If you need a different amount, correct the line manually or delete it and add it again (in an unposted bill).
The whole "tariff → request → bill" chain is described in detail in The tariff in a request and a bill.
Operation life cycle
- Creation — the operation appears in the list with the status Not posted. It does not affect balances.
- Posting — the operation is recognised as having taken place; balances are recalculated (see What "posting" means).
- Allocation (for a Bill ↔ Payment pair) — the payment closes the bill fully or partially; the remaining amount of both documents decreases (see Allocating payments).
- Unposting — balances are rolled back and the operation becomes a draft again.
- Editing / deletion — possible only while the operation is not posted (see the section below).
Creating an operation
Available to: administrator, head. A client cannot create operations.
Click "Add financial document" in the top left corner of the section — a step-by-step wizard opens. The set of steps depends on the document type:
- Bill: General → Details → Services → Files → Summary.
- Payment: General → Details → Files → Summary (without the "Services" step).
If custom fields are configured in the company, an "Additional info" step is inserted between "Files" and "Summary".
Step 1. General
- Document type — Bill or Payment.
- Operation type — for a bill: "Incoming" / "Outgoing"; for a payment: "Receipt" / "Disbursement".
- Payment date — the date/due date of the operation.
- Account / cash — select an account. Its currency automatically becomes the document currency — you do not need to choose the currency separately.
You choose the account first, and its currency then determines which currency the document will be in and which services can be added (services are bound to a currency). See Accounts and balances.
Step 2. Details
- Counterparty — a client-user of the system or an external counterparty from the reference data (exactly one).
- Item — a category from the income/expense items reference data.
- Amount — for a payment it is entered manually; for a bill the "Amount (from services)" field is read-only and is built up from the service lines (step 3).
- Basis — for a payment only: a reference to the bill this payment closes (see Allocating payments).
- Request and Shipment — the link to the carriage, for analytics. If you select a request, the "Shipment" field is locked (the request's shipment is filled in).
- Comment — free text.
Step 3. Services (bills only)
Add services with the "Add service" button: choose a service, enter quantity and price — the line will calculate its total, and "Total" is shown at the bottom. Bill amount = the sum of all lines. At least one service is required (see Bill line items by service).
Next to it there is a second button — "Add from tariff": it adds a line calculated by the system from the request's tariff (quantity, price and amount are filled in automatically). See Bill line from a tariff.
Step 4. Files
Drag and drop or select files (scans of the bill, the acceptance certificate, the payment order). You can create folders. Limits: up to 50 files, up to 50 MB per file; formats PDF, DOC, DOCX, XLS, XLSX, JPG, JPEG, PNG, WEBP, HEIC, HEIF.
Step 5. Summary
A summary of the document and two ways to save:
- "Create" — save as a draft (Not posted): it does not affect balances, and you can edit and post it later.
- "Save and post" — save and post immediately (see What "posting" means).
It is convenient to create a payment straight from a bill: right-click the bill → "Create on the basis of" → Payment. The wizard opens with fields already filled in (counterparty, basis, amount = the bill's remaining to pay, request/shipment, comment) — you just need to check them and save. Likewise, a bill can be created from a payment. After such a payment is posted, the system immediately offers to allocate it against the bill — see Allocating payments.
So that a repeated click on "Save" or a network failure does not create two identical documents, an idempotency mechanism is used at creation. Repeating the same request returns the already created operation instead of making a duplicate. More details in the Idempotency section.
Allocating payments against bills
Available to: administrator, head.
A payment does not close a bill "by itself" based on the counterparty — you have to state explicitly which payment settles which bill. That is what allocation is (the payment ↔ bill link). Allocation decreases the "remaining to pay" of the bill and the "remaining to allocate" of the payment by the amount of the link.
Allocation moves only the remaining amounts of the documents (how far they are closed). Only posting affects the counterparty balance and the account balance, not allocation. See What "posting" means.
Method 1. Right after creating a payment on the basis of a bill
If you created a payment on the basis of a bill and clicked "Save and post", the system shows the "Link documents?" dialog: the bill (with its remaining to pay) → the payment (with its remaining to allocate), the "Link amount" field (by default the maximum possible, no greater than the smaller of the two remaining amounts) and the buttons:
- "Link" — allocate the payment against the bill for the specified amount.
- "Skip" — leave the payment unallocated (it can be allocated later).
A payment created manually without a basis does not trigger this dialog.
Method 2. From the document card
Open the document (double-click in the list):
- In the payment card — the "Linked bills" tab → "Link document": the list shows the unsettled bills of this counterparty.
- In the bill card — the "Linked payments" tab → "Link document": the list shows the payments of this counterparty that still have an unallocated remainder.
Specify the link amount and confirm. An unwanted link can be deleted — the remaining amounts will be restored.
Allocation rules
- Documents are linked only when they belong to the same company, the same currency and the same counterparty, and both must be posted.
- The link amount ≤ the bill's remaining to pay and ≤ the payment's remaining to allocate.
- When the bill's "remaining to pay" reaches zero, the bill is marked "Paid".
- One payment can be allocated across several bills, and several payments across one bill.
- When a bill or a payment is unposted, all of its links are released and the documents' remaining amounts are restored.
Until a bill is fully closed (the bill is unpaid or the payment is unallocated), its unclosed remainder is counted in accounts receivable and in overdue reports. More details — Accounts receivable.
Filters and search
The operations list can be filtered by:
- Operation type — incoming / outgoing.
- Document type — bills / payments.
- Posting status — posted / not posted.
- Payment status — paid / not paid.
- Payment date — a range.
- Counterparty, item, account/cash, currency.
- Shipment, request, basis, author.
Global search works across all fields; there is a separate search by comment.
Just like in Requests/Shipments: columns can be reordered, hidden/shown (the "Columns" button at the bottom), resized with the width saved, sorted and filtered by values. Bulk row selection shows the totals for the selected operations broken down by currency and document type (bills/payments).
Detailed view of an operation
A double-click on a row opens the operation card. The header shows the number, the type ("Incoming bill" / "Outgoing bill"; for a payment, "Receipt" / "Disbursement") and the posting status. The set of tabs depends on the document type:
- Bill: Document · Linked payments (appears only for a posted document) · Services · Files.
- Payment: Document · Linked bills (posted documents only) · Files.
On the Document tab of a posted document there is an amount block:
- for a bill — "Paid X (Y%)" and "Remaining to pay";
- for a payment — "Allocated X (Y%)" and "Remaining to allocate".
At the bottom of the card there is the "Cancel posting" button (for a posted document); at the top there are icons for unposting, editing (unavailable for a posted document) and closing.
Actions from the table
Context menu (right-click)
Right-clicking a row opens the actions menu:
- Edit (unavailable for a posted document — cancel the posting first).
- Delete (marked "unavailable" for a posted or linked document).
- Post operation / Cancel posting.
- Create on the basis of → Create bill or Payment based on the selected document (the wizard opens with pre-filled fields).
Quick change of the payment due date
The payment due date and the comment can be changed without cancelling the posting. Click the value in the "Payment due date" column — the "Change payment due date" dialog opens with the "Payment due date" and "Comment" fields.
This is the only change permitted for a posted document: only the payment date and the comment change. All other fields of a posted document are unavailable (cancel the posting first). Available to the administrator / head roles.
Editing
Available to: administrator, head.
A double-click on a row opens the operation card.
While an operation is posted, editing its fields is forbidden — the system returns the error "A posted operation cannot be edited. Cancel the posting first." The exception is the quick change of the payment due date and comment.
The correct order is: cancel the posting → make the changes → post again. There is no automatic "re-posting" on edit — balances are rolled back precisely at the unposting step.
Deletion
Available to: administrator, head. Deletion is irreversible.
You can only delete an operation that satisfies two conditions:
- It is not posted. A posted operation cannot be deleted — you will get the error "A posted document cannot be deleted. Cancel the posting first." The posting is not rolled back automatically on deletion — unpost it manually first.
- It is not the basis of a transportation cost. If the bill is attached to a transport leg as its cost (T5/T6), remove that link first — otherwise you get the error "The document cannot be deleted: it is referenced by "Transportation cost (T5/T6)". Remove that link first."
When an operation is deleted, its attached files are deleted as well.
Deletion erases the record from history. To correct reporting that has already been filed, use a correction made with a new operation (a reversal), not the deletion of the old one.
Idempotency (duplicate protection)
When operations are created, the system applies idempotency: a unique key bound to the request content is attached to the request.
What this gives the user:
- A repeated identical request (a double click, a retry after a timeout, an unstable network) does not create a duplicate — the result of the first request is returned.
- If different data is sent under the same key, the system detects it and returns a conflict error (code 409) instead of silently overwriting. This protects against unnoticed data corruption.
In practice: if a save appears to hang, you can safely retry — no extra operation will appear.
What's next
- What "posting" an operation means — the main accounting principle.
- Accounts and balances — where the resulting balances are visible and how to read the sign of a balance.
- Accounts receivable and aging — debt management.
- Bulk operations — posting, unposting and exporting in batches.
- Reference data — items, accounts, currencies and services.
- The tariff in a request and a bill — how a carriage rate turns into a bill line.