财务管理
为什么这是一个运行时问题，而不是 CRUD 问题
每个成长中的企业最终都会撞上同一堵墙：会计凭证在电子表格里，供应商发票在邮件里，银行对账是每月的救火演习，没人说得清哪个数字才是准的。根本原因不是缺少一个页面——而是复式记账本质上是一套约束系统，而非数据存储。凭证过账前借贷必须相等。凭证必须落在已开放的会计期间内。某位会计编制的凭证，不能由同一个人来过账。这些规则都无法塞进通用表单构建器里。
关于功能边界的坦诚说明。 AuraBoot Finance 覆盖操作层核心：总账、应收、应付、凭证审批流程、带三单匹配的供应商发票、付款记录、银行对账、费用报销、成本中心和财务报表。它不是特定国家或地区的会计合规套件。不内置各国法定会计科目表，不内置各国税务局 e-invoice 接口，也不提供本地化增值税申报功能。如果你的首要需求是某个国家的监管申报，请在选型前诚实评估这一缺口。AuraBoot 提供的是干净、可配置的操作层，合规逻辑可以通过自研插件或可选的 tax-compliance 插件叠加其上。
在明确了边界之后：完整的审批过账流水线是一张命令图，不是手写的 Controller 链。会计期间生命周期是一等公民状态机。编制人与审批人之间的职责分离由权限系统强制执行，而不是靠代码注释约定。
数据模型概览
Finance 插件包含六个功能域共 31 个模型：
- 总账核心：
fin_account（层级科目表，五种科目类型）、fin_fiscal_period（月度期间，含开放 / 软关闭 / 硬关闭 / 锁定生命周期）、fin_journal_entry+fin_journal_line（带审批流程的复式凭证）、fin_gl_balance（按期间汇总的借贷余额）。 - 应收应付：
fin_ar_transaction（来自出货或手工开票的客户应收）、fin_ap_transaction（来自收货或手工录入的供应商应付）、fin_supplier_invoice+fin_supplier_invoice_line（供应商发票采集）、fin_three_way_match（采购订单 vs 收货 vs 发票三单匹配，含容差和挂起解决）、fin_payment（与应收/应付关联的付款记录，自动生成凭证）。 - 费用报销：
fin_expense_claim（员工报销，含草稿 / 待审 / 已批准 / 已付款生命周期）。 - 银行：
fin_bank_account、fin_bank_statement+fin_bank_statement_line、fin_reconciliation（对账单行与凭证的匹配关联）。 - 多币种：
fin_currency（ISO 4217 主数据）、fin_exchange_rate（汇率历史）；所有凭证同时保存交易货币金额和本位币金额。 - 成本核算：
fin_cost_center、fin_cost_element、fin_cost_allocation_rule、fin_standard_cost、fin_cost_variance。 - 报表 / KPI：
fin_report_template+fin_report_line、fin_financial_report、fin_voucher_template+fin_voucher_template_line、fin_kpi_definition+fin_kpi_snapshot、fin_restatement。
核心命令
该解决方案包含 60 余条命令。会计凭证状态机是约束执行最清晰的示例：
| 命令 | 形态 | 所需权限 | 说明 |
|---|---|---|---|
fin:create_journal_entry | 创建 | fin.financial.manage | 自动生成凭证号 JE-{yyyyMMdd}-{seq}，初始状态 draft |
fin:submit_journal_entry | 状态转换 | fin.financial.manage | draft / rejected → submitted；编制人发起审核 |
fin:approve_journal_entry | 状态转换 | fin.financial.admin | submitted → approved；需与提交人角色不同 |
fin:post_journal_entry | 状态转换 + handler | fin.financial.manage | 服务端 handler 校验借 = 贷，同事务更新 fin_gl_balance |
fin:reverse_journal_entry | 状态转换 | fin.financial.admin | posted → voided；生成冲销凭证 |
fin:approve_match | 状态转换 | fin.financial.three_way_match | 批准三单匹配（matched / within_tolerance → resolved）；自动创建应付款记录 |
fin:reconcile_bank_statement | 操作 | fin.bank_recon.manage | 将对账单行与凭证匹配；标记未匹配行 |
fin:post_journal_entry 命令携带 handler 字段，触发服务端 Java 逻辑。任何客户端校验都无法替代这一环节：handler 是唯一能在同一事务中原子校验余额并更新总账的地方。
发票到付款生命周期
供应商发票到达
|
v
[fin_supplier_invoice: 草稿]
|
提交
|
v
[待审]
|
批准 / 驳回
|
v
[已批准] ──驳回──> [已驳回] ──重新提交──> [待审]
|
v
创建三单匹配 (fin_three_way_match)
采购订单金额 vs 收货金额 vs 发票金额
|
在容差范围内？
/ \
是 否
| |
v v
[匹配: 已批准] [匹配: 挂起] ──解决挂起──> [已批准]
|
v
创建应付款记录 (fin_ap_transaction)
|
v
记录付款 (fin_payment)
|
v
自动生成会计凭证 → 过账至总账
权限示例
一个真实的财务团队至少有两类张力需要编码：职责分离（编制凭证的人不应是过账的人）和团队隔离（应收人员不应看到或操作应付数据）。
职责分离——凭证过账：
- 角色
fin_accountant持有fin.financial.manage——可以创建、提交和过账凭证。 - 审批步骤（
fin:approve_journal_entry）要求fin.financial.admin。 - 实际操作中，企业将超过一定金额的凭证配置为必须经过审批，并仅将
fin.financial.admin授予财务主管。编制人可以提交，但无法审批自己编制的凭证。
应收 / 应付团队隔离：
- 应收专员角色：
fin.financial.read、fin.payment.manage（针对应收记录收款）——没有fin.supplier_invoice.manage，也没有fin.bank_recon.manage。 - 应付专员角色：
fin.supplier_invoice.manage、fin.payment.manage（针对应付记录付款）——没有fin.financial.admin（无法审批或过账总账凭证）。
字段级成本中心遮蔽：
- 成本会计角色持有
fin.cost.read和fin.cost.manage——可以查看fin_cost_center分摊率和标准成本卡。 - 应收 / 应付角色不持有
fin.cost.read——凭证行视图中的成本中心分摊字段对他们不可见。
五层权限机制（RBAC、组织范围、ReBAC、ABAC、字段级）与其他所有用例共用同一平台管道，按顺序依次评估。
如何获取
- 社区版：在拥有该插件包的发行环境中导入 Finance 插件，然后执行
aura exec fin:init_chart_of_accounts初始化默认科目表。 - 标准版：以平台为基础进行白标，将 Finance 插件作为你的行业解决方案的一部分发布。
- 专业版：获取包含预配置菜单、角色、仪表盘以及可选
tax-compliance扩展（支持的地区）的 Finance 解决方案包。 - 企业版：同上，另包含托管期末关账编排、独立交付为垂直产品的国家合规包、高级多主体合并，以及 SLA 保障的支持服务。
完整版本对比请参见定价页面。
企业版说明 — 托管期末关账编排（跨主体自动化软关账检查、硬关账闸门执行、对账完成度门控）、以独立版本化垂直产品形式交付的国家合规包（法定科目表、司法管辖区 VAT 申报、e-invoicing 税务局接口），以及包含内部交易抵消的高级多主体合并，均为商业版专属能力。上述总账 / 应收 / 应付 / 付款运行时契约在各发行形态中保持一致。