Bryce
e9970bd41a
A client's bank account and the financial account it posts to carry the same numeric code. Reports keyed their detail rows on [code, name], so the pair rendered as two rows — one labelled for the bank account, one for the financial account. The amount was duplicated too, not just the label: the row's figure is filtered by code alone, so both rows printed the whole code's total. The group subtotal counts the code once, so a section's visible rows stopped footing to their own subtotal. Penelope's Coffee and Tea overshot the 2000 Accounts Payable subtotal by $251,751.80 this way. Resolve it in two places: - build-account-lookup now maps every account at a shared code down to the bank account's name, per client. Where a client has two bank accounts on one code, lowest :bank-account/sort-order wins, then lowest :db/id, so the label is stable across runs. - used-accounts now keys rows on the code alone. Across a multi-client report the clients can still disagree, since only some of them have a bank account at the code; a bank-sourced name wins there, which the new :bank_account_name? flag carries through from the lookup. Rows are code-keyed now, so detail-rows decides whether to print a figure by asking whether the client has data at the code rather than under the winning name — otherwise a client reaching a code under a name another client won would blank out. Balance sheet, profit and loss and cash flows all route through used-accounts and are all fixed. The GraphQL and cljs balance sheets pick up the unified name through build-account-lookup. A sweep of all 146 clients with bank accounts finds duplicate rows on 8 of them before this change and none after, with every section total unchanged.