| Fix | Result |
|---|---|
| Hidden 257 closed-position securities (ZHIDEINLISTS=1) | Security pickers down from 317 → 60 entries |
| Truncated 34M of Quicken logs | Faster startup, no data impact |
| Reassigned 167 entries to fresh ZQUICKENIDs | 175 duplicate groups → 0 |
| Updated 26 ZTRANSFER references via amount-matching | Transfer counterparts resolve to correct accounts |
| Deleted 9 orphan parent ZTRANSACTIONs (mine) + 1 zero-stub | Quicken display went $931.98 → $2,036.98 |
| Jason deleted 2 duplicate $22.94 manual entries | 2020 Checking now $2,082.86 = bank exactly |
| Mercury IO Autopay sweep, EWEB→Utilities, UA INFLT→Travel | From this morning's nightly, preserved through restore |
Per CLAUDE.md, deleting ZTRANSACTION rows can crash reconcile. The recommended pattern was to delete only ZCASHFLOWTRANSACTIONENTRY rows. Problem: Quicken's account balance display uses SUM(ZTRANSACTION.ZAMOUNT), not entry sums. Leaving parents kept the phantom transactions visible in the register and dragged the displayed balance.
Fix going forward: Delete BOTH parent and child entries when removing a transaction, OR set ZTRANSACTION.ZAMOUNT=0. Validated this session: deleting orphan ZTRANSACTIONs that have no remaining children is safe — no reconcile crash observed.
Old CSV imports (accounts 216 / 217 named 2794061050.csv) created entries with ZQUICKENIDs that overlapped with real entries in C. Price Promissory Note and Jason's Old Checking. Quicken's transfer-target lookup uses ZQUICKENID; with duplicates it picked the wrong account for display. Symptom: enter a transfer to "2020 Checking" → display shows "C. Price" or "Jason's Old Checking".
Fix: Reassign new unique ZQUICKENIDs (start at 1000003+) to all but the oldest entry in each duplicate group. Update ZTRANSFER references using amount-matching (a +N entry's transfer should resolve to a -N entry). Implemented in this session via Python script. 0 duplicates remain.
Daily nightly script clicks Next then Finish at $0 diff. For QCS-downloaded accounts that's mostly fine because entries arrive pre-cleared. For accounts with manual entries, new outflows stay uncleared forever. Hit hard when 8 phantom 2020 Checking transfers from late 2025 / early 2026 had been sitting uncleared, balanced at $0 diff because cleared total matched bank.
Fix: Update reconcile loop to click "Mark all as Cleared" between Next and Finish, with a diff check before clicking Finish (vs Finish Later). $0 → Finish; ≤$1.00 → Finish Later + Dispatch; >$1.00 → Finish Later + Dispatch (data problem).
Quicken positions reconcile dialogs at unpredictable coordinates, often partially off-screen on SMBX2431. Programmatic clicks via AX still work (logical hierarchy), but visually impossible to verify mid-run, and edge cases caused stuck dialogs.
Fix: Reconcile script v10 calls set position of rWin to {mainX+200, mainY+150} before driving the dialog. Always lands the dialog on whichever monitor the main window is on.
Earlier reconcile script versions used keystroke "l" using command down after selecting a sidebar row. Returned 17/17 NO_DIALOG — keystroke didn't fire even though main window was raised. Same script worked manually.
Fix: Use menu navigation: tell menu bar item "Accounts" → click → tell menu "Accounts" → click menu item "Reconcile Account…". 100% reliable.
Documented bug from 2026-04-30. Confirmed again this session — Mark Reviewed via menu bar reports success but ZRECONCILESTATUS stays at 0 for many transfer-tagged entries. SQL writes to ZTRANSACTION crash QCS so cannot bypass.
Workaround: Per-account selection (vs All Transactions Cmd+A) helps somewhat but isn't 100% reliable. For now, accept that some entries stay marked uncleared even after a clean reconcile. Cosmetic only — doesn't affect cleared totals.
Restored from a backup 8 hours older than the current QCS state. On launch Quicken showed: "Only the latest version of a file can use Quicken Cloud" with three options: Take File Offline, Reset Quicken Cloud, Decide Later.
Fix: Reset Quicken Cloud is the right choice — pushes the restored state to QCS as canonical. Banks re-fetch on next sync. "Take Offline" kills daily downloads (avoid). "Decide Later" parks sync until decided.
Accounts named 2794061050.csv and 2794061050.csv 2 from old Mint CSV imports. During this session, 70 phantom transactions appeared in them spontaneously (between 12:38 and 20:02). Those 70 transactions created 65 of the 175 duplicate ZQUICKENID groups.
Open issue: Investigate trigger and clean up these accounts entirely. They serve no purpose and keep generating cruft.
Spent ~30 min chasing an "$810 over bank" discrepancy that turned out to be a measurement artifact. I summed ZCASHFLOWTRANSACTIONENTRY.ZAMOUNT for cleared (status≥1) entries. Quicken displays SUM(ZTRANSACTION.ZAMOUNT). Different methods, different numbers, no real $810 issue.
Fix: Always validate balance using SUM(ZTRANSACTION.ZAMOUNT) WHERE ZACCOUNT=<pk>. That's what Quicken displays. Entry sum is misleading because of orphan parents and split structures.
step9_reconcile.applescript v10 — menu navigation + dialog repositioning + simple-tracking pre-skip + button-click drive (saved to outputs)| Backup | State |
|---|---|
2026-05-06-02-37-29_data | Post-nightly (morning, clean) |
2026-05-06-12-38-07_data_pre-log-truncate | Before any cleanup work |
2026-05-06-19-09-26_data_pre-2020-phantom-cleanup | Before phantom deletes |
2026-05-06-20-02-54_data_current_state_pre_restore | Deprecated state (with display bug) |
2026-05-06-20-49-38_data_pre_orphan_parent_delete | Before final fix |
Current data | Balanced, 0 duplicate ZQUICKENIDs |
PK 77394 Square Inc orphan (-$810.49 from 2025-04-17) — has ZAMOUNT but no entries. Dragged 2020 Checking $810 down for years. Either delete (Quicken display jumps $810 over bank) or restore the missing entries. Needs separate audit.