------ 从 AR / AP / GL 出发，构建可长期演进的财务系统
一、为什么"命名规范"在财务系统中是生死级问题？
在业务系统中，最容易被低估、但最终代价最高的设计问题之一，就是命名 。
而在财务系统中，这个问题的严重程度被放大了 10 倍以上。
常见问题包括：
-
同一个"应收"，有人叫：
ys、receivable、shoukuan、ar -
同一个"总账凭证"，有人叫：
voucher，有人叫journal -
同一套业务，在 数据库、接口、代码层命名完全不一致
在系统规模较小时，这些问题"看起来还能忍"；
当系统进入 多团队协作、多微服务、多租户、对接外部财务系统阶段，命名混乱会直接导致：
-
财务口径无法统一
-
新人理解成本极高
-
接口对接错误频发
-
数据仓库指标口径混乱
-
审计、合规成本激增
结论只有一句：
👉 财务系统的命名规范，不是代码风格问题，而是"财务一致性与系统可持续性"的基础设施。
二、全球通用的财务命名体系：AR / AP / GL
企业级系统不采用拼音、不采用中式缩写，而是统一遵循国际会计标准（IFRS / GAAP）：
| 模块 | 英文全称 | 国际标准缩写 | 中文 |
|---|---|---|---|
| 应收账款 | Accounts Receivable | AR | 应收 |
| 应付账款 | Accounts Payable | AP | 应付 |
| 总账 | General Ledger | GL | 总账 |
| 资金管理 | Cash Management | CM | 资金 |
| 固定资产 | Fixed Assets | FA | 固定资产 |
| 成本核算 | Cost Accounting | CA | 成本 |
| 税务管理 | Tax Management | TAX | 税务 |
| 预算管理 | Budget Control | BC | 预算 |
这些缩写不仅存在于 SAP、Oracle、用友、金蝶中，也存在于绝大多数银行、财务 SaaS、数据仓库模型中。
✅ 这不是"个人偏好"，而是行业共识。
三、统一命名的设计原则（架构级约束）
一套合格的财务命名规范，必须满足以下四条铁律：
1️⃣ 模块前缀强制统一
-
所有应收相关表 → 必须以
ar_开头 -
所有应付相关表 → 必须以
ap_开头 -
所有总账相关表 → 必须以
gl_开头
禁止出现：
-
ys_、yf_、cw_这类拼音 -
receive_、payable_这类不统一英文
2️⃣ 数据库、API、代码三层同名
同一个对象，三层命名必须一致：
| 层级 | 示例 |
|---|---|
| 表名 | ar_adjust_bill |
| API | /api/ar/adjust/post |
| Java 类 | ArAdjustBill |
这可以保证：
-
新人一眼能从接口定位到表
-
架构设计具备"可读性"
-
避免领域模型割裂
3️⃣ 财务数据禁止"语义不明的字段命名"
禁止：
-
status = 0 / 1 / 2 -
type = 1 / 2 / 3
必须：
status = NEW / APPROVED / POSTED / REVERSED adjust_type = PLUS / MINUS / WRITE_OFF
这是为审计、对账、回溯服务的基本要求。
4️⃣ 命名必须为"长期可扩展"而设计
例如：
-
不用
receipt1、receipt2 -
不用
bill_tmp -
不用
data_new
而应该是：
-
ar_receipt -
ar_writeoff -
ar_adjust_bill
四、AR（应收）模块命名规范示例
这是企业级系统中最核心的一组表：
| 业务含义 | 标准表名 |
|---|---|
| 应收台账 | ar_account |
| 应收单据 | ar_bill |
| 应收明细 | ar_bill_detail |
| 应收收款单 | ar_receipt |
| 应收核销单 | ar_writeoff |
| 应收调整单 | ar_adjust_bill |
| 应收调整明细 | ar_adjust_detail |
| 客户账龄 | ar_aging |
| 客户信用额度 | ar_credit_limit |
五、AP（应付）与 GL（总账）命名规范示例
AP（应付）
| 业务 | 表名 |
|---|---|
| 应付台账 | ap_account |
| 应付单据 | ap_bill |
| 应付付款单 | ap_payment |
| 应付核销单 | ap_writeoff |
| 应付调整单 | ap_adjust_bill |
GL（总账）
| 业务 | 表名 |
|---|---|
| 会计科目 | gl_account_subject |
| 会计凭证 | gl_voucher |
| 凭证明细 | gl_voucher_entry |
| 会计期间 | gl_period |
| 结账记录 | gl_close_record |
六、跨模块公共字段统一规范
所有财务单据，必须包含以下字段：
| 业务含义 | 统一字段 |
|---|---|
| 主键 | id |
| 租户 | tenant_id |
| 单号 | bill_no |
| 状态 | status |
| 创建人 | creator |
| 创建时间 | create_time |
| 审核人 | approver |
| 审核时间 | approve_time |
| 过账人 | poster |
| 过账时间 | post_time |
金额字段统一：
amount 本币金额 foreign_amount 外币金额 currency 币种
七、为什么"命名统一"是财务系统可扩展的基础？
当你的系统发展到以下阶段之一，命名规范会直接决定你能否继续演进：
-
上线数据仓库（ODS / DWD / ADS）
-
多账套并行
-
对接外部财务系统（金蝶 / 用友 / SAP）
-
做经营分析、资金预测、现金流模型
-
通过审计、IPO、融资尽调
如果底层命名是：
ys_table、ys_data、cw_mx、cw_tmp
那么你后续的：
-
BI 报表
-
财务分析
-
资金预测
-
税务申报
都会变成灾难级维护成本。
八、架构级结论
✅ 财务系统的命名不是"技术洁癖"，而是"业务长期安全性设计"。
✅ AR / AP / GL 不是习惯问题，而是"行业通用协议"。
✅ 命名一旦失控，系统规模越大，重构成本越趋近于"不可承受"。