SudoSOS Back-end API / transactions / sub-transactions
Transactions: Sub Transactions ​
A SubTransaction is one seller's slice of a Transaction. Where the parent transaction records "this user spent money at this POS", the sub-transaction records "and this much of it goes to this organ". A transaction with one container in the basket has one sub-transaction; a basket that mixes containers from three organs has three.
Roles on the sub-transaction ​
tois the user being credited -- the Container owner (typically a GEWIS organ).containeris the ContainerRevision the products were bought from. It is a revision so historical sub-transactions keep resolving even after the container is edited.transactionis the parent Transaction; cascading delete on the parent removes the sub-transaction with it.
Rows ​
Product lines live on SubTransactionRow: one row per product, with an amount (quantity) and a ProductRevision reference. The revision pins price (incl. VAT), VAT group, and category at the moment of sale.
Invoicing ​
A row can carry an invoiceId linking it to an Invoice. That marks the row as "billed to the invoiced customer" rather than charged directly to the buyer's balance. Balance reads treat invoiced rows the same as any other row when computing the seller side; the invoice flow handles the buyer side separately.
Why it exists ​
Splitting per-seller lets a single POS purchase pay multiple organs in one ring-up. Without sub-transactions you would need either one transaction per organ (and the cashier ringing up the same basket three times) or a denormalised seller field on each row (with reports gathering and grouping on the fly).
Classes ​
| Class | Description |
|---|---|
| SubTransaction | TypeORM entity for the sub_transaction table. One per (transaction, container) pair: the portion of a transaction that credits a single container owner. |
| SubTransactionRow | - |