56 lines
3.3 KiB
Markdown
56 lines
3.3 KiB
Markdown
# Local audit — 19 Aug 2026
|
||
|
||
Full audit of the local database, files, and the running app before the team enters the
|
||
first production month. **Verdict: system healthy and ready; three data-cleanup items for
|
||
the team below.**
|
||
|
||
## What was checked
|
||
|
||
| Check | Result |
|
||
|---|---|
|
||
| Database integrity (`PRAGMA integrity_check`) | ✅ ok — `ar_aging.db`, 295 MB, 20 tables |
|
||
| Foreign keys / orphaned rows | ✅ zero violations, zero orphans |
|
||
| Transactions | ✅ 883,930 rows across 4 processed closings, none missing currency or marketplace |
|
||
| Uploaded files vs database | ✅ all 4 files present on disk, sizes match, SHA-256 recorded |
|
||
| Duplicate upload rows (historical double-count bug) | ✅ none found — no closing ever double-counted a file |
|
||
| Orphan files on disk | ✅ none |
|
||
| Users | ✅ 4 active accounts (login verified for each) |
|
||
| Full test suite | ✅ 152 passed, 0 failed (12 skipped — large sample files) |
|
||
| Live API (running app, port 8010) | ✅ health deep-check ok; no token → 401; wrong password → 401; login ok; month-ordered listing; pending-months explanations; controls 5/6 on Jan |
|
||
| Frontend (port 5174) | ✅ serving, proxying to the API |
|
||
| Exchange-rate provider (live call) | ✅ Frankfurter reachable; EUR→USD 2026-06-30 = **1.139406**, 2026-01-30 = 1.191895 |
|
||
|
||
One environment fix made during the audit: this Windows machine's OS certificate store is
|
||
corrupted (Python `ssl [ASN1: NOT_ENOUGH_DATA]`), which blocked HTTPS calls. The FX service
|
||
now uses the `certifi` CA bundle instead (added to requirements) — affects nothing else.
|
||
|
||
## Findings for the team (data, not code)
|
||
|
||
### 1. ⚠️ June closings are valued at January's exchange rate — ≈ $50k overstated
|
||
Closings **#3, #4, #5** (all 2026-06) carry EUR→USD = **1.185665**, the January-2026
|
||
workbook snapshot, and it was *confirmed* at that value. The actual ECB rate on
|
||
2026-06-30 was **1.139406** — the June receivable of $1,290,921 is overstated by roughly
|
||
**$50,000**. Fix on whichever June closing is kept: Controls tab → **Fetch month-end
|
||
rates** → review → Confirm → re-run controls. This is precisely the failure mode the new
|
||
FX fetch exists to prevent.
|
||
|
||
### 2. ⚠️ Three identical June closings + three empty drafts
|
||
Closings #3 ("July finance report"), #4 ("june"), #5 ("Test Case - Germany Jun-2026") are
|
||
the **same June file processed three times** — identical 214,166 transactions and identical
|
||
receivable. Keep one, delete the other two. Drafts #2, #6 (2026-06) and #7 (2026-01) are
|
||
empty and can be deleted. The dashboard now flags all of these with a duplicate-month ⚠.
|
||
Going forward the app blocks accidental month duplicates at creation.
|
||
|
||
### 3. ℹ️ No month is published yet
|
||
No journal has been approved, so the Accounts Summary is empty — the summary page now
|
||
lists each processed month with the reason ("journal not approved yet") and a link. When
|
||
January is final: Journal Entry tab → Mark reviewed → Approve (records the signed-in
|
||
user's name).
|
||
|
||
## State after cleanup (recommended target)
|
||
|
||
- One closing per month: `2026-01` (#1) and one `2026-06`, both with fetched + confirmed
|
||
June/January rates, journals approved, then **Complete** to lock them read-only.
|
||
- First production month gets entered by the team on the deployed server per
|
||
`deploy/DEPLOY.md`; this local database migrates there as-is.
|