This article explains the Finances › Cash view: the safe-side half of the café cash SOP. It covers what the weekly review records and what it deliberately does not, how the two checks (Unaccounted, Bank vs bag labels) are calculated, how the bank order is suggested and counted in, and how the safe keypad slots are tracked. Everything here is what the console does; the drawer-side procedure lives in Dripos.
Scope — what the console records and what stays in Dripos
Everything that moves between a drawer and the safe (Pay In, Payout, the close-out Drawer Reset) is already in Dripos and is not re-entered here. The console records only what Dripos structurally cannot see:
- the weekly physical count of the safe's change fund
- the sealed deposit bags carried to the bank
- the coin and currency order carried back
One row per weekly review, on Thursdays. The row's date is the Thursday it belongs to; before Thursday the form still points at last week's row, because you are still logging last week's bank run. Storage is SQLite at pepper-ui/backend/data/cash.db (tables cash_weeks, safe_codes, cash_settings; CASH_DB_PATH overrides the path). The History table shows the last 26 weeks.
The two header numbers
| Label | Setting | Default | Meaning |
|---|---|---|---|
| Starting bank | starting_bank | $150 | The drawer's opening float. Shown for reference only. |
| Change fund should hold | fund_par | $700 | Par — the level the safe's change fund is brought back to every week. $700 is what Maciej actually drew from Byline (2026-08-14); it replaced an earlier $300 estimate derived from an unmeasured cash-share figure. |
Par is a setting, not a constant. The SOP expects it to be retuned once real drawer data exists, and the form's Par — bring it back to field writes the value used for that week's row.
Change fund target
The change fund is meant to run down during the week as baristas pull change into drawers. That is not a shortage; it is the fund doing its job. The weekly step is to buy the difference back from the bank. This is separate from the deposit bags, which are the week's takings and leave entirely.
Buy from the bank = max(0, par − counted in the safe). It is an order quantity, not a variance.
Ask the teller for
The top-up is split into a teller-readable order. The mix is the $700 reference order (200 × $1, 70 × $5, 5 × $10, and 7 / 4 / 5 rolls of quarters / dimes / nickels) scaled to this week's amount: shares of 0.50 for $5s, 0.0714 for $10s, 0.10 quarters, 0.0286 dimes, 0.0143 nickels. Coin is allocated in whole rolls and $5/$10 in whole bills, then $1s absorb the remainder so the suggestion lands on the target exactly. If the fixed denominations overshoot (only possible on very small amounts), $5s are peeled back until it fits.
Unaccounted (counted + pulled − start)
This is the real reconciliation — the safe's equivalent of a drawer's Close Difference, and the reason a weekly count exists at all.
| Field | Where it comes from |
|---|---|
| Counted in the safe | The physical count. |
| Pulled to drawers this week | Dripos's Paid In/Out column for the week. The check stays blank until this is entered. |
| Fund at start of week | Auto-filled from last week's counted figure plus last week's cash order collected. If there is no prior row, it falls back to par. It only needs touching the first time, or when a top-up came up short. |
Counted + pulled should equal what the fund started with. The money either sat in the safe or went into a drawer, and every drawer trip is a Dripos Pay In, so any leftover is a genuine gap. Tolerance is ±$2: within $2 shows green, beyond $2 shows red, in the form and in the History column.
Why it is measured against the start-of-week figure and not par: two earlier versions were wrong. counted − par flagged a shortage every normal week, because the fund is meant to run down. counted + pulled − par assumed every week began at par, which was false in week one (the fund started at $0 and showed −$700 of phantom loss) and is false any week the top-up was short.
Sealed bags opened
One bag per day the café took cash. Each row records date, amount, bag serial and who closed it. The serial ties the row to the physical bag — the deposit bags carry a printed serial, and without a place to record it that control does nothing. The Closed by picker is the live 7shifts roster filtered to the Café department (7shifts groups every department under one location, so department is the only real discriminator, and only Café staff touch the register). If 7shifts is unreachable the picker degrades to a typed name rather than blocking the form. Bags with no amount are dropped on save.
Bank run
| Field | Rule |
|---|---|
| Deposited at Byline | What the bank actually accepted. |
| Bank vs bag labels | Deposit − bags total. Tolerance is $0.01; any larger gap shows red. A gap means a bag was miscounted, mislabelled, or never made it into the deposit. |
| Cash order collected | Derived from the counted denominations below whenever any are entered; a counted breakdown is authoritative over a typed total. |
What you got — count it in
The Bills / Coins tabs mirror Dripos's Till Modal (step a denomination up and down), so counting a bank order here feels like counting a drawer there. It is optional, but a few weeks of it shows which denominations actually run out, which is what tells you whether the order is the right size.
| Denomination | Unit | Value |
|---|---|---|
| $1, $5, $10 | bills | face value |
| Quarters | roll of 40 × 25¢ | $10 a roll |
| Dimes | roll of 50 × 10¢ | $5 a roll |
| Nickels | roll of 40 × 5¢ | $2 a roll |
Bills stop at $10 (Maciej, 2026-08-14): this is a change order, and a $20/$50/$100 never comes back from the bank as part of one. Coins are rolls, never loose. No pennies — the SOP never orders them; nickel rounding is live.
Safe keypad codes
The view records who holds which User slot on the safe's keypad — nothing else. The MSL-500 manual says to keep notes on which code belongs to which user; without that, deleting a leaver's code means guessing at a slot number, and a wrong guess revokes the wrong person.
- The codes themselves are never recorded, by anyone, including the owners. Each person sets their own, so nobody else has seen it. Knowing that a person is User 2 does not help anyone open the safe.
- Master (setting
master_holder, default Maciej Wolfart) opens the safe and is the only code that can add or delete users. The Master holder is not offered in the user-slot picker; there is no reason for him to also occupy a user slot. - Assigning a slot stamps the date it changed hands (since …); emptying it clears the date. Re-saving the same person keeps the original date.
- The picker is the same Café-department 7shifts roster as the bag rows; a holder who is no longer on it shows as (not café staff).
Slot 5 — unconfirmed
The MSL-500 manual contradicts itself on capacity: its feature list says Users 1–5, but its activate and delete instructions both accept only 1, 2, 3 or 4. The console shows five slots and marks Slot 5 unconfirmed. Settle it by programming slot 5 once; if that fails, treat 4 as the ceiling. An empty row costs nothing; a missing one would hide a holder.