Transactions

What a transaction is

A transaction in SavingStat is one movement of money. It carries an amount, the currency of that amount, a date, the wallet the money went through, and a comment if you want one. Every figure elsewhere in the app is assembled from these.

A transaction 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.

Everything else a transaction holds depends on its type. There are three.

The three transaction 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, not 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. You type that amount yourself; nothing is converted for you.

A transfer takes no category and no budget. Nothing was earned and nothing was bought, so there is nothing to label, and the record has nowhere to put a label anyway. How to record a transfer covers the rest.

Status is a separate question from type

Type and status are two different axes, and every transaction has one of each. Type says what kind of movement it was. Status says 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 yet. It sits outside your data: absent from your transaction list, with no wallet balance moved for it. Publishing is the only way out of draft. There is no way back.

Completed is the ordinary state of everything else. Income and transfers become completed as soon as they are published, because nothing about them is left to work out.

The other three statuses belong to expenses alone, and all three report 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 no line has been given an amount yet. Partial means they come to less than the payment. Over budget means they come to more. That last name is misleading: it has nothing to do with 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. A draft is never checked. The arithmetic first runs at the moment you publish.

Splitting one payment across lines

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 you can open and amend one, remove it, or add another beside it.

The three arithmetic statuses read these lines. 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 a transaction

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 anything you attach yourself starts private, meaning 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, and nothing more: not the transaction, and not the other files on it.

The budget in that rule is the one held by the transaction itself, which an import sets when it 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 the switch for you, differently per kind: a receipt scan is attached shared, and a statement file is attached private, because a statement covers far more than the one row.