# NumeraBooks 2.11.1 — the reconcile screen

> Requires 2.11.0 first, or install this straight over whatever you are on — it contains everything
> in 2.11.0 as well.

## "no date filter, no transaction type filter, no sorting, and after reconciling it brings all the transactions again"

Four complaints, three of them true and one of them a bug you had already reported.

### The date filter existed — you just couldn't use it

`rc_dfrom` / `rc_dto` have been there since 1.0.1. They sat **inside the element `rcLoad()` rewrites**,
so typing a year completed the field at year 0002, fired the change handler, rebuilt the container,
and destroyed the input under your cursor. That is RCN-501, the "can't change the dates" bug, fixed
in 2.11.0 — which you hadn't installed when you looked. It'll appear to be a new date filter.

### The list showed the account's entire history, every time

This is the real one. `rcLoad()` selected every ledger row for the account with no exclusion at all.
The only relief was a **"Hide already-cleared"** checkbox that defaulted to **off** and was never
remembered, so each new statement opened on years of settled history with the current month's
handful buried inside it.

There is now a **Show** selector:

| | |
|---|---|
| **Unreconciled only** | the default — what you asked for |
| **Reconciled only** | so a mistaken mark can still be found and undone |
| **All transactions** | the old behaviour, when you want it |

Plus a **transaction type** filter built from the types the account actually holds, **sortable
columns** on both tables (date, number, name, amount), and a **date ceiling that seeds itself from
the statement date** — QuickBooks' "hide transactions after the statement end date". It stops next
month's items being cleared into this month's statement, and on a busy bank account it is the
difference between loading a page and loading a decade. Touch either date box, or press **All
dates**, and it stops seeding.

---

## The two invariants that made hiding safe

Hiding reconciled rows is the obvious fix and it is also the dangerous one, because two pieces of
machinery behind this screen assumed every row was on screen. Both had to be built or this feature
would have quietly destroyed reconciliations.

**1 · `saveReconciliation()` replaces the account's whole unlocked cleared set** with whatever it is
given. A cleared item that is merely *hidden* is therefore not hidden — it would be **un-cleared on
the next save**, silently, with the books still balancing. Every such mark is now carried in
`_rcOutOfView` and re-sent. This mechanism already existed for the date filter; it now also covers
the Show filter, which is a far bigger hole because hiding cleared items is the *default*.

There is a test that proves the bug rather than just the fix: it saves January, then saves February
sending only the on-screen ticks, and asserts January is destroyed. It's there so nobody
"simplifies" `rcFinish` back into it.

**2 · `rcCalc()` summed the ticked checkboxes in the DOM.** Hide the cleared ones and the cleared
balance reads zero, the Difference reads the whole statement, and the natural next move is to tick
items that were already reconciled — reconciling the same money twice. `_rcHidden` carries the
totals of every cleared row not rendered and `rcCalc` adds them back, so **changing the view never
changes the numbers**. The screen tells you how many are withheld and how much they come to, rather
than leaving you to wonder why the arithmetic looks short.

A closed statement stays untouchable through all of it: locked marks are hidden by "unreconciled
only", still counted in the cleared balance, and deliberately *not* in the re-send list — they are
not ours to re-send, and the engine holds them either way.

---

## Also

**"Hide already-cleared" is gone.** The Show selector does that job properly. Two controls that both
hide cleared items — one of them a sticky checkbox — is how you end up unsure what you are looking
at.

**Sorting goes through `NBSORT.register()`, not the auto-attach pass.** `rcLoad()` replaces the list
wholesale on every filter change and the tick state lives in the DOM, so re-sorting has to re-render
from the data rather than shuffle live rows carrying checkboxes with them.

## Verification

**3,562 assertions across 67 suites, 0 failing.** New: `reconfilter` (32) — the Show/type/date
filters, sorting, both invariants above, and the closed-statement case.