Transactions
One movement of money: what every transaction carries, how the three types differ, and why status is a separate question from type.
What a transaction is
A transaction is one movement of money. It carries an amount, the currency that amount is in, a date, the wallet the money went through, and a comment if you want one. Every figure elsewhere in SavingStat is assembled from these.
It actually keeps two amounts rather than one: what the movement was worth in its own currency, and what it came to in the wallet's. The two are the same number whenever the currencies agree, which is most of the time. Currencies explains why both are kept instead of one being converted away.
What a transaction holds beyond that depends on which of three types it is.
Three types
The type says what kind of movement it was, and it decides what else the record can hold.
- Expense: money going out. It carries one or more expense lines, and each line is where a category, a budget and an optional event sit. Those belong to the line rather than to the payment as a whole.
- Income: money coming in. It carries the income source the money arrived from, and can name an event as well.
- Transfer: money moving between two wallets you own. It carries the receiving wallet and the amount that actually landed there, which you type yourself rather than have converted for you.
A transfer takes no category and no budget. Nothing was earned and nothing was bought, so there is nothing to label it as, and the record has nowhere to put one. Record a transfer covers the rest of it.
Status is a separate question
Type and status are two different axes, and a transaction always has one of each. Type is what kind of movement it was. Status is where the record stands. A draft expense is both at once: an expense on one axis, a draft on the other. Neither answer tells you the other.
Draft means the row came out of an import and has not been published. It sits outside your data: absent from your transaction list, and no wallet balance has moved for it. Publishing is the one way off it, and there is no way back.
Completed is the ordinary state of everything else. Income and transfers land there as soon as they are published; there is nothing about them left to work out.
The other three belong to expenses alone, and all three are the same arithmetic: whether the expense lines add up to the transaction's own amount. Pending means the lines come to nothing at all, usually because none has been given an amount yet. Partially Completed means they come to less than the payment. Over Budget means they come to more. The last name is misleading, since it is not about a budget's contents and no budget can produce it. Budgets says more about that.
The sum is worked out again every time a line is added, edited or removed, so a split you are part-way through says so. It is not applied to a draft at all: the arithmetic first runs at the moment you publish.
There is a sixth, Error, and you will meet it only in the filter drawer, where it is offered as something to tick. Nothing produces it: the three branches above cover every way the lines and the amount can compare, so no row is left over to fall into it. Do not read its absence as good news about your data.
Splitting one payment
One payment often covers more than one thing. A supermarket trip is part groceries and part something for the flat; a single card payment can belong half to one budget and half to another. That is why an expense holds lines rather than a single category: each line has its own amount, and its own category, budget, event and comment.
The lines live on the transaction's own page under Expense details, where one can be opened and amended, removed, or another added beside it.
This is what the three arithmetic statuses are reading. They are not remarks about your spending; they report whether the split you have made adds up to the payment it came from. Get the lines to match the amount and the transaction reads completed.
Files attached to one
A transaction can carry files: the statement or photograph an import read it out of, a receipt you add afterwards, an invoice. They come from your file library, and attaching one leaves it there.
Sharing is per attachment, not per transaction. Each file on a transaction has its own switch reading Shared or Private, and a file you attach yourself starts private. Private means you are the only person who can list or download it. Shared offers that one file to the accepted members of the budget the transaction is filed under. What is shared is that file alone, not the transaction and not the other files on it.
The budget in that rule is the one held by the transaction itself, and that is set when an import files the row. A transaction you enter by hand keeps its budget on its expense lines, and those are not what the rule reads.
Only the owner sees the switch. Members receive the shared rows and nothing else, so they have no state to change. An import sets it for you and sets it differently per kind: a receipt scan is attached shared, and a statement file is attached private, because it covers far more than the one row.