Transactions

A laundry and cleaning business runs on installment payments, partial pickups, and discount arrangements that happen verbally and get forgotten by Thursday. The NGN-denominated transaction record in this template is built specifically for this kind of operation — not a retail POS, not an invoice system, but a real-time ledger of what was dropped, what was cleaned, what was paid, what remains, and whether the customer has actually come back to collect.

Carrying the Balance in Your Head Is the Liability

The mental load of informal transaction management compounds daily. A customer drops twelve items on Monday, pays half at drop-off, and promises the balance at collection. They come back on Saturday, you name a figure, they dispute it, the argument runs three minutes, and you end the transaction at a number you're not sure is accurate. This happens six times a week.

The Remaining Balance calculated field resolves this. It computes: Amount minus Payment 1 minus Payment 2 minus Payment 3 minus Refund minus Discount. Amount itself is a calculated field — it sums the price of each linked Service entry multiplied by the logged Quantity, directly from the Services library. When a customer asks what they owe, the number is on the screen. It is not a recall, not an estimate. It is the arithmetic of the transaction you logged when they dropped off the order.

Three payment fields — Payment 1, Payment 2, Payment 3 — accommodate the real payment patterns of small-business customers who pay in stages: something at drop-off, something mid-week when they walk past, the rest at collection. Total Payment sums them automatically. Remaining Balance knows what that leaves outstanding. Discount and Refund apply at the record level — a loyalty discount negotiated at collection, or a refund for a garment that came back damaged, both reduce the Actual Amount independently of the payment fields.

The Fields That Tell You Where the Order Is

Work started? has three states: Not started, Started, Completed. Collected by customer? has two: Yes, No. These two fields are the operational dashboard for a multi-order day. Filter Work started? = Not started and you see the backlog. Filter Work started? = Completed combined with Collected by customer? = No and you see the finished orders sitting in the shop waiting for a pickup call. That is the phone call list.

The Collection Date field sets the expected pickup window. Orders where the Collection Date has passed and Collected by customer? is still No are overdue pickups — storage pressure, cash outstanding, operational friction. Surfacing these requires a single filter rather than a physical walkthrough of the hanging orders.

Customer is a linked entry field pointing to the Customers library, which holds first name, last name, phone number, and gender. Phone number is a dedicated phone field — tap to call directly from the transaction record. When a customer's collection date has passed and you need to chase the pickup, you do not look up the number separately. You open the transaction, tap the phone field, make the call.

At One Hundred Active Transactions

When the transaction log reaches a hundred records — roughly four to six weeks of active business — the data starts answering questions you weren't originally asking. Which services drive the most revenue by Amount? Which customers have the highest average Remaining Balance at collection — the ones who consistently pay short? What percentage of transactions complete in a single Payment 1 versus requiring follow-up payments?

The answers are already in the records. The only thing required is the filter and the sort.