v4.1.1 — Scheduled-transaction integrity & data-safety fixes

Quality & data-integrity release. No headline feature — this one is about the ledger being correct and staying correct.

Highlights

• Same-day transaction ordering — choose Entry order / Deposits-first / Payments-first in Settings; transfers honour the setting too.
• Negative opening balances — credit cards and liability accounts keep a negative starting balance instead of having it forced positive.
• Transfers honour the amount sign — direction stays consistent at every entry point.
• Backup & restore polish — a unified hub, accurate status lines, and clearer local-backup warnings.
• Cent-accurate totals and data-safety fixes throughout.

Scheduled transactions no longer skip occurrences

Reported by a user whose monthly bills quietly stopped posting: "basically none of them auto populate."

A schedule's next-due date could advance past an occurrence that was never applied, permanently disarming auto-apply. The cause: the decision to skip an occurrence and the decision to advance past it were never derived from the same fact — the due date was free-running state that several code paths recomputed at will, while the ledger was never consulted.

Fixed at the cause:

• The due date now moves only on proof that the occurrence was applied.
• Editing a schedule no longer re-derives its position from the start date, which is what silently jumped a pending occurrence.
• The duplicate guard now compares local calendar days. It previously compared a UTC day against a bare DATE() that returns NULL on Android SQLite < 3.42 — so on those devices the guard silently never matched.
• Applying an occurrence is a single database transaction — the ledger row, its provenance, and the date advance commit together or not at all.
• Backups now carry occurrence history, so a restored install knows what was already applied and won't re-post on top of it.

What this release deliberately does not do: it never edits your ledger. Two versions of an automatic "repair" that would have back-filled apparently-missed transactions were built and removed during review — both could create money you didn't ask for, and neither could reliably tell "the bug skipped this" from "I already handled this". Your register is yours; the app fixes the cause and stays out of your history.

Changing the same-day sort order no longer fails

Found on-device after the first release candidate and fixed before shipping.

On a register carrying sub-cent rounding drift — which any ledger migrated from the legacy app does — changing the intraday sort order failed outright with a constraint error, making the release's headline feature unusable. The amount-validation rule was re-checking every row on any bulk update, even updates that never touched an amount, so one legacy row with more than two decimal places aborted the whole operation.

The rule is now scoped to amounts actually being written, and is repaired automatically on every launch so it reaches installs regardless of upgrade path. Existing drifted amounts are left exactly as they are — rounding a stored amount would change a balance, and that's your data, not ours.

Verification

Device-verified on a physical Pixel 9 Pro — schedule lifecycle, the reported edit-skip bug, apply-now behaviour, a full backup → restore → relaunch round trip with zero drift, and the intraday sort re-order on a 13,597-transaction migrated register. Migration from v4.1.0 was verified by full-snapshot diff with no balance or ordering change.

Assets

All Android artifacts are versionCode 232, signed with the Netdonkey Labs release certificate. These supersede the earlier versionCode 230 artifacts, which shipped the intraday sort defect above and were never promoted beyond internal testing.