feat: link reviewed invoices to ledger transactions
This commit is contained in:
@@ -75,3 +75,9 @@
|
||||
- 服务端按经营主体做鉴权、限流、调用审计和数据隔离。
|
||||
- OCR 与 LLM 的响应都先经过服务端结构校验;客户端仍保留金额、日期和枚举白名单等确定性校验。
|
||||
- AI 只生成建议,不能直接写入账簿、修改税额或代替人工确认。
|
||||
|
||||
## 票据、流水与凭证
|
||||
|
||||
票据证明交易内容,流水证明资金实际收付,凭证负责把两类证据关联起来。三者不互相冒充:确认发票不会创建流水,导入流水也不会自动认定某张发票属于它。
|
||||
|
||||
当前一对一匹配由版本化确定性规则完成。金额和收支方向必须完全一致,日期必须在允许窗口内,交易对方名称只影响排序。用户确认后,系统保存匹配证据快照并按需追加流水分类修订;撤销通过新的审计事件和反向修订完成,不删除原记录,也不覆盖撤销前已经发生的后续人工修改。
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
- 界面与交互:`src/App.tsx`,视觉令牌与布局:`src/styles.css`。
|
||||
- 金额汇总规则:`src/domain/transactions.ts`,修改时先补对应测试。
|
||||
- 本地数据库、命令、迁移、备份和导出:`src-tauri/src/lib.rs`。
|
||||
- 票据与流水候选匹配、凭证和撤销审计:`src-tauri/src/vouchers.rs`。
|
||||
- 产品边界和架构决定:`docs/`,发布前同步更新版本说明。
|
||||
|
||||
## 不破坏旧数据的规则
|
||||
@@ -19,6 +20,8 @@
|
||||
|
||||
运行 `scripts/verify.ps1`,确认前端测试、生产构建和 Rust 测试通过;随后人工检查建档、记一笔、CSV 重复导入、确认、修改、搜索、账簿导出、备份和恢复。安装升级测试不得删除应用数据目录。
|
||||
|
||||
发布客户端必须使用 `npm run desktop:build`,不要用 `cargo build` 代替正式打包流程,否则最新 `dist` 可能没有嵌入可执行文件。SQLCipher 的 vendored OpenSSL 在 Windows 中文路径下构建失败时,可临时用 `subst` 把项目根目录映射到纯英文盘符后构建;映射只服务于编译,不得写入程序配置或用户数据路径。
|
||||
|
||||
## 故障定位顺序
|
||||
|
||||
先记录用户看到的中文错误和触发步骤,再判断属于界面、命令、数据库迁移还是文件系统。修复后必须增加能复现问题的自动测试。不要让用户手工编辑数据库或密钥文件。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 当前能力
|
||||
|
||||
票据中心已经形成“主动上传 → 加密存档 → OCR 识别 → 字段核对 → AI 建议 → 人工确认”的本地闭环。发票与收付款流水是两类不同证据,因此人工确认票据不会自动生成收支流水,避免把“取得发票”误当成“已经付款”。后续应通过流水匹配或单独的凭证流程完成入账。
|
||||
票据中心已经形成“主动上传 → 加密存档 → OCR 识别 → 字段核对 → AI 建议 → 人工确认 → 匹配流水 → 生成凭证”的本地闭环。发票与收付款流水是两类不同证据,因此人工确认票据不会新建收支流水,避免把“取得发票”误当成“已经付款”。只有匹配到已有真实流水并经人工确认后,系统才生成凭证关联并追加分类修订。
|
||||
|
||||
当前开放增值税发票图片,单张不超过 2.5 MB,支持 PNG、JPEG、BMP 和 WebP。文件按内容哈希去重,重复选择同一图片不会重复建档。
|
||||
|
||||
@@ -13,6 +13,8 @@
|
||||
- `document_extractions`:保存经过归一化的可编辑字段,金额统一使用整数分。
|
||||
- `ai_runs`:追加保存模型调用状态、服务可解析时的原始响应、校验后的建议和置信度。
|
||||
- `document_reviews`:追加保存每次人工确认时的字段快照与时间。
|
||||
- `vouchers`:保存票据、流水、入账分类、经营用途、匹配规则版本和确认前快照。
|
||||
- `voucher_events`:追加保存凭证确认与撤销事件,不覆盖历史状态。
|
||||
|
||||
原始 OCR 结果不会因人工修改而被覆盖。失败调用同样留下审计状态,但日志和界面不显示供应商密钥。
|
||||
|
||||
@@ -24,6 +26,9 @@
|
||||
- LLM 返回必须是结构化 JSON,并通过方向、分类白名单、金额一致性、日期和置信度校验。
|
||||
- 任何解析或校验失败都只显示失败,不产生记账结果。
|
||||
- AI 建议与人工确认是两个独立动作,AI 永远不能自动入账。
|
||||
- 流水候选使用确定性规则,不调用 LLM。金额和收支方向必须完全一致,日期相差不超过 45 天,交易对方相似度只参与排序和风险提示。
|
||||
- 同一张票据或同一笔流水同时只能存在一张有效凭证。
|
||||
- 撤销凭证通过追加反向事件和分类修订完成。如果用户在凭证确认后又手工修改过流水,撤销不会覆盖这次更新。
|
||||
|
||||
## 服务端迁移
|
||||
|
||||
@@ -40,3 +45,5 @@
|
||||
5. 人工修改后保存的是新复核快照,OCR 原始结果仍可追溯。
|
||||
6. 人工确认不会改变收支流水与税务计算结果。
|
||||
7. 本机真实配置、测试票据和密钥不会进入 Git 或安装包。
|
||||
8. 同额、同方向且日期相近的流水会成为候选,不同金额或相反方向不会出现。
|
||||
9. 确认凭证不会新建第二笔流水,撤销后原始票据、流水和凭证历史仍可追溯。
|
||||
|
||||
Reference in New Issue
Block a user