swaits
d5b9e5cf99
An invoice is issued, not edited. Without `confirmed` the create tools now preview: the posting (with the accounts' codes, which the live chart may not hold yet), the number it will take, its due date, terms and early discount, warnings, and for an invoice the DRAFT copy of the PDF, handed over as a file. Nothing is written and no number is used up. With `confirmed` the invoice posts, takes the number the preview showed, and files the issued copy with itself in the same call: `receipt.attached` on its entry plus the link to the invoice, its SHA-256 in the event (A-1, A-7, B-40). The copy the customer received is therefore the copy in the books, and `books.document`'s re-created page can never be mistaken for it. The result also carries a `mailto` link for a human to send it; the books never send (A-4). A bill keeps what the plan says a bill is: the vendor's own invoice number, the vendor's invoice filed on its entry as its evidence, and, in books that have declared `documents_v2`, an account on every line, so no bill can land in General Expenses by default any more (A-9, A-10, A-13). A vendor number entered twice is refused unless the caller says why, and the reason is journaled with the second bill (B-40 item 4). Books that have not declared the feature keep recording bills exactly as before, so the owner's books keep working between units (D-39, 8.0.4). Terms are resolved in one place and in one order: the due date given, else the terms given, else the customer's or vendor's own default, else the books' `invoicing.default_terms`; a document given only a due date stores no terms, so an old-shape invoice is still written byte for byte as before (B-39, A-13). D-55: a party carries the owner's full contact block (phone, contact person, billing and shipping addresses, billing email). It rides the same `party.updated` event behind `documents_v2`, and an invoice's bill-to is snapshotted at issue with the billing address and billing email in place of the general ones when the party has them — `PartySnapshot::from_party` is the one place that rule lives, so a later edit cannot change what was sent, and the next invoice takes today's details. Tests: the wire tests are the new `crates/ledger-cli/tests/documents.rs` (preview writes nothing, the DRAFT copy, the issued copy's SHA-256 equals `books.get_receipt`'s, numbers run, a bill's file and terms, the duplicate refusal, the line-account rules, the terms fallback, the `party_id` alias and the ambiguity it refuses, the contact block's set and clear, and the bill-to at issue); `format_upgrade.rs` gains `documents_v2_refused_until_consent` and the cut-over test now refuses and then makes a document carrying a new field (8.0.6 item 3); the store tests are `the_contact_block_round_trips_and_replays` and `an_invoice_keeps_the_billing_details_it_was_issued_with`, and `books_written_under_older_rules_still_open` gains a hand-written contact-block event (8.0.6 item 1). Merge does not need the owner's go-ahead: the live books refuse a write that needs `documents_v2` until he gives it, and take every other write as before (8.0.6 item 6). No figure moved: S4 moves none.
123 lines
8.9 KiB
Markdown
123 lines
8.9 KiB
Markdown
# Parity catalog
|
|
|
|
Every semantic feature we intend to clone, with its status. Updated in the
|
|
same commit as the feature. **The floor never decreases**: the count of
|
|
`done` items is monotonic across commits.
|
|
|
|
Statuses: `done` = implemented + invariant-tested + golden-covered.
|
|
`partial` = implemented but missing tests or goldens. `todo` = not started.
|
|
No other statuses.
|
|
|
|
**Floor: 10 done** (2026-10-10; fixed-asset register added).
|
|
|
|
| Area | GnuCash counterpart (a cross-check, not the spec) | Status | Notes |
|
|
|---|---|---|---|
|
|
| Chart of accounts (5 types, codes, hierarchy) | Accounts tab | done | `account.rs`; placeholder support in |
|
|
| Double-entry validation (balanced, ≥2 lines) | Journal validation | done | `journal.rs::validate` |
|
|
| Exact decimal money, no floats | — (we go further) | done | `money.rs`; Currency ISO codes |
|
|
| Posted-entry immutability | Read-only posted txns | done | reversal via `reverse_entry` |
|
|
| Trial balance | Reports → Trial Balance | done | golden-covered |
|
|
| Balance sheet (A = L + E) | Reports → Balance Sheet | done | current earnings folded in pre-close; golden-covered |
|
|
| Profit & loss | Reports → Income Statement | done | golden-covered |
|
|
| P&L for a date range, line per account (closing entries excluded) | Reports → Income Statement (custom dates) | partial | hand-verified fixture + property tests; no golden file yet |
|
|
| Balance sheet as of a date, line per account | Reports → Balance Sheet (as of) | partial | hand-verified fixture + property tests; no golden file yet |
|
|
| General ledger by account (running balance, split) | Reports → General Ledger | partial | hand-verified fixture, ties to trial balance; no golden file yet |
|
|
| Trial balance as of a date | Reports → Trial Balance (as of) | partial | hand-verified fixture; no golden file yet |
|
|
| Statement of changes in members' equity | Reports → Statement of Changes in Equity | partial | hand-verified two-member fixture incl. rounding and a close; no golden file yet |
|
|
| Tax line mapping + tax summary | Accounts → Tax line mapping; Tax reports | partial | hand-verified fixture (50% meals, nondeductible, contra income); no golden file yet |
|
|
| Reversing entries | Reverse transaction | done | linked via `reversal_of` |
|
|
| Canonical report snapshots (JSON) | — (our oracle format) | done | `reports::snapshot` |
|
|
| Fixed-asset register + straight-line depreciation | Fixed Asset register | done | `assets.rs`; golden-covered schedule; idempotent runs; disposal with gain/loss; posted (the books') vs scheduled, in-service vs acquired dates, the §723, depreciable and §704(c) figures (P3) |
|
|
| Cash flow statement (direct, with the reconciliation schedule and noncash disclosures) | Reports → Cash Flow | done | R-FUTURE-3; rules.md B-14 (P3 defect 1) |
|
|
| Foreign-currency lines (base + foreign stored) | Multi-currency accts | done | R-FUTURE-1 |
|
|
| Period close (closing entry to Retained Earnings) | Close books | done | R-FUTURE-2 |
|
|
| Bank reconciliation (cleared flags + report) | Reconcile | done | — |
|
|
| QuickBooks CSV import (bank txns, chart of accounts) | Banking → Upload | done | R-FUTURE-4 |
|
|
| QuickBooks IIF + XLSX export | Export / reports | done | R-FUTURE-4 |
|
|
| A/R invoices + payments + aging | Business → Invoices | done | R-FUTURE-5; numbers, terms, line accounts, the party snapshots and the issued PDF filed with the invoice, through `books.create_invoice`'s preview and confirm (P4b S4.4) |
|
|
| A/P bills + payments + aging | Business → Bills | done | R-FUTURE-5; the vendor's own invoice number (a duplicate refused), terms, line accounts and the vendor's invoice filed as the bill's evidence, through `books.create_bill`'s preview and confirm (P4b S4.4) |
|
|
| Payroll runs (accounting only, no tax tables) + tax remittance | Payroll | done | — |
|
|
| Tracking classes (divisional P&L) | Class tracking | done | invoice and bill lines take a class too (projects, rules.md B-37 item 8; QBO/Xero class or tracking per line) |
|
|
| CPA handoff package (TB + GL xlsx, P&L + BS pdf, zip) | Reports → export | done | — |
|
|
| Budgets | Budgets | todo | R-FUTURE-6 (declined as bloat) |
|
|
| Scheduled transactions (recurring entries → drafts) | Scheduled txns / Recurring transactions | partial | hand-verified fixture incl. month-end dates; drafts only, by design |
|
|
| Payout gross-up (deposit → revenue, fees, adjustments) | Bank deposit with fee lines; Xero/QBO Stripe & Shopify integrations | partial | hand-verified fixture incl. classes and a negative payout; no statement parsers yet |
|
|
| 1099 vendor tracking + year-end worksheet | Vendors → Track payments for 1099; 1099 report | partial | hand-verified fixture (bill payments, card exclusion, reversal, year boundary); no golden file yet |
|
|
| Prepaid expense + deferred revenue amortization | Amortization schedules (Xero/QBO add-ons) | partial | hand-verified fixture, to the cent; no golden file yet |
|
|
| Automated cross-implementation diff harness (GnuCash first) | — (our `xtask oracle`) | todo | roadmap phase 3 |
|
|
|
|
Workflow/UI parity (QuickBooks/Xero reference) gets its own catalog when the
|
|
egui phase starts; semantics come first.
|
|
|
|
### P0 guard rails (2026-10-16)
|
|
|
|
P0 (`plan/served.md`) changed no feature in the catalog above, so no
|
|
status moved and the floor stands. It hardened what exists: an older
|
|
version refuses books from a newer one as newer, not corrupt (rules.md
|
|
B-27); the MCP server fails closed after an internal error, and no input
|
|
reaches one (dates are four-digit years, amounts at most a line's, B-28);
|
|
local files
|
|
were read only from the import roots, never the books, the vault or its
|
|
key (P2 slice 5 removed local paths: files now come in only as uploads,
|
|
D-46); no file with a full TIN is filed into the books (B-26); the agent is
|
|
told the rules in force in a short connect text and a handbook, and no
|
|
agent text points at the books' files, git or the repo.
|
|
|
|
## U0b: one attention engine (D-53, 2026-10-26)
|
|
|
|
No semantic feature changed, so no status moved and the floor stands (10
|
|
done). Needs attention used to be computed by the viewer alone; it now
|
|
lives in `ledger-package::attention`, over `PackageBooks`, and both the
|
|
viewer and `books.start` read it (the same items, the same prompts), so the
|
|
list the human sees and the next steps the agent gets cannot drift. The
|
|
parity test `the_viewer_and_books_start_see_the_same_attention` compares
|
|
them item for item on the demo books and on a book written entry by entry.
|
|
|
|
## Capability parity (AI-first phase)
|
|
|
|
Semantic parity (above) is about *correctness*: the engine computes the
|
|
right numbers. Capability parity is about *usefulness*: can the new system
|
|
do everything the GSheet+GDrive system does today? Tracked separately in
|
|
`docs/capability-parity.md`, with its own cutover rule (parallel run +
|
|
the owner's approval). The two catalogs converge: when both are green, the
|
|
sheet retires.
|
|
|
|
### P13 bookspec (2026-10-26)
|
|
|
|
P13 is a specification, not a feature, so no row of the semantic catalog
|
|
moves and the floor stands. It adds the checker crate (`bookspec/checker`:
|
|
the example schema, the rule identifiers `BS-<area>-<n>` and the `Engine`
|
|
trait), the runner (`bookspec/runner`: pass, fail or not claimed per rule),
|
|
and the rule index from B-1 to B-45 (`bookspec/spec/rules-index.md`). Every
|
|
existing bookspec example still runs on every `cargo test`, through both
|
|
the loader's own checks and the `Engine` trait.
|
|
|
|
### P4b S4.4: the create tools preview and confirm (2026-10-27)
|
|
|
|
The A/R and A/P rows above gain their note rather than a new row: no
|
|
parity item changed status, so the floor stands. `books.create_invoice`
|
|
and `books.create_bill` now preview without `confirmed` (the posting, the
|
|
number and due date it will take, the DRAFT or the discount, and nothing
|
|
written) and post with it (A-1), which is what the workflow reference
|
|
does before a document leaves the company. A bill in books that have
|
|
declared `documents_v2` names each line's account and keeps the vendor's
|
|
invoice (A-10, A-13); an invoice keeps the copy it issued (A-7, B-40) and
|
|
a `mailto` link for a human to send it, since the books never send (A-4).
|
|
`books.update_party` takes the party's email and terms per side (A-13) and
|
|
the owner's full contact block (D-55: phone, contact person, billing and
|
|
shipping addresses, billing email), which an invoice's bill-to copies at
|
|
issue.
|
|
|
|
### P9a self-host deployment (2026-10-26)
|
|
|
|
P9a is a deployment, not a semantic feature: the same engine, store, MCP
|
|
surface and reports on a machine of the owner's own. No row above changed
|
|
status and the floor stands. What it adds is the enforced isolation the
|
|
catalog's parity claims rest on in practice: a dedicated account, a data
|
|
root only that account can read, `books.start` saying
|
|
`service_user (enforced)` (`--isolation`), and the same bearer-guarded MCP
|
|
door on loopback for Caddy or a tunnel. `crates/ledger-cli/tests/two_user.rs`
|
|
proves the account boundary and the move's head in CI
|
|
(`.github/workflows/two-user.yml`); the recipe is `deploy/README.md`.
|
|
The cutover rule in `docs/capability-parity.md` is unchanged.
|