Order Line Item Amounts

price holds the same value as net. The two are kept separate because price is the charged amount as stated on the order, while net is the revenue figure financial reporting sums. They coincide today and nothing should assume they must.

fee is not part of this identity. It is an expense incurred against the line, not a reduction of what the customer owed. Revenue is net; the cost of collection is fee; the contribution after payment costs is net - fee. Subtracting fee from net when storing the value would make the line’s revenue depend on how the customer chose to pay, which is not a property of the sale.

A high-school entry with a catalogue price of R200, sold to a school at a bulk rate of R30, paid by card where the processor charges 4.2% plus VAT on the amount transacted:

Revenue for the line is R30.00. Payment cost is R1.45. Contribution is R28.55. The R170.00 discount is visible as forgone revenue without having to reconstruct it from the catalogue.

fee is stored VAT inclusive, because that is the amount that leaves the bank account. A processor invoice states its line amounts exclusive of VAT and adds VAT as a single figure at the foot, so reconciling a stored fee against an invoice line requires multiplying the invoice figure by 1.15.

A processor invoice also carries charges that are not per-transaction — payout or withdrawal fees, and adjustments for refunds. These have no order to attach to and are not represented in fee. An invoice total will therefore exceed the sum of stored fees for that period by exactly those items.

The membership order update path receives the charged and pre-discount amounts from the storefront and populates the full sales picture. The storefront’s line subtotal becomes gross; its line total becomes price and net; the difference becomes discount. A line reduced to zero against a non-zero catalogue price records the whole catalogue price as the discount, so that a comped membership still shows what was given away.

Event participants are attached to an order at registration, which happens before payment. The order is created with the number DRAFT and the participants are linked to it; only when the buyer proceeds to pay is a storefront order created and the order given its real number.

The line item factory sets price and net when it is given a price or a product to price from, and leaves them at the created default otherwise. It never sets gross, discount or fee on any path.

No code path assigns fee. The column exists on the entity, the DTO and the criteria filter, and is readable through the API, but nothing populates it. Payment costs are consequently absent from every figure the system derives, and must be obtained from the processor’s own records.

Where the registration path attaches a participant without a resolved product or price, the line is created with price at zero and gross, discount, net and fee left NULL — even though the price is determinable at that moment from the participant’s event category, which carries a product reference.

An order in this state has no monetary value anywhere in the database. Its status records whether it was paid; how much it was paid for does not survive. Where such orders dominate an event, financial reporting for that event cannot be answered from the system at all.

Two REST resources fill in a missing net when mapping a line item to its DTO, computing it as price - discount. Because price already holds the post-discount amount, a line with a stored discount and no stored net yields a value one discount too low.

The defect is latent rather than active: the only path that writes discount also writes net, so no stored row currently satisfies both conditions. It will produce wrong totals for the first line item that carries a discount without a net — including any line populated by a back-fill that sets gross and discount but not net. The order total is summed from these DTO values, so the error propagates from the line to the order.

Both writing paths assign the same value to price and net. Nothing enforces the identity net = gross - discount at the persistence layer, so a row can be written that violates it, and nothing detects that it has been.