2. 基础知识

在进入TMS（资金管理系统）现金头寸与流动性模块的设计之前，必须先建立一套统一的“资金语言”。很多项目在需求阶段争论不休，根源并非技术方案分歧，而是对“头寸”“流动性”“资金池”这些词的理解不在同一层面。本节将把这些基础概念逐一拆解，并说明它们在系统设计中的映射关系。

一、核心原理：从账户余额到可用头寸

最容易被混淆的一组概念是“账面余额”与“现金头寸”。账面余额是银行账户或内部账户在某一时点的静态数字；而现金头寸是企业在特定时点可实际支配、可用于支付或调拨的资金净额。二者之间隔着在途、冻结、预留和授信等多个调整项。

用公式表达更为直观：

可用头寸 = 账面余额
         + 在途入账（已收未记）
         - 在途出账（已付未记）
         - 冻结金额（保证金、司法冻结）
         - 预留金额（已审批未支付）
         + 可动用授信额度

这个公式是流动性模块计算引擎的核心逻辑。系统设计时，必须把每一个调整项都建模为独立的数据实体，而不是在余额字段上做加减法，否则后续无法追溯差异来源。

二、流动性：时间维度上的支付能力

流动性不是某一个数字，而是一个带时间轴的预测结果。它关注的是：在未来1天、7天、30天甚至更长的滚动周期内，企业的现金流入是否足以覆盖现金流出。流动性管理的本质是期限错配管理。

在TMS中，流动性通常通过“流动性缺口”来量化：

流动性缺口(t) = 累计现金流入(t) - 累计现金流出(t)
若缺口 < 0，则存在流动性风险，需要提前安排融资或调拨

流动性预测的数据来源包括：应收账款到期计划、应付账款排程、贷款还本付息计划、工资税费日历、已签约未履约合同等。系统需要把这些分散数据统一到“现金流事件”模型中，按日期聚合。

三、资金池与账户体系：物理与逻辑的双层结构

资金池是集团企业集中管理分散资金的机制，常见形式包括实体资金池（实际归集）和名义资金池（仅计息不归集）。在系统设计中，资金池不是账户，而是一组账户之间的关系与规则集合。

账户体系则分为物理账户与逻辑账户两层：

• 物理账户：真实存在于银行的账户，有账号、开户行、币种、余额。
• 逻辑账户：企业内部为核算、考核或归集目的设立的虚拟账户，通常挂在物理账户之下。
• 主子账户：资金池中用于归集的主账户与参与归集的子账户，存在上下级归集关系。
• 内部账户：用于成员单位之间内部结算，不产生实际银行流水。

理解这层结构，才能正确设计头寸汇总的粒度。头寸可以按物理账户汇总，也可以按逻辑账户或资金池汇总，不同粒度服务于不同管理视图。

四、常见术语清单与系统映射

下表整理了本节涉及的核心术语及其在TMS模块中的典型字段或对象，便于设计与开发对齐。

术语	含义	系统映射对象
账面余额	账户在银行或内部账上的静态余额	Account.balance
可用头寸	扣除冻结、预留、在途后的可支配资金	Position.available
在途金额	已发生但尚未记账的收付款	InTransit.amount
冻结金额	保证金、司法冻结等不可动用部分	Frozen.amount
流动性缺口	某期限内现金流入减流出的差额	LiquidityGap.value
资金池	一组账户按规则归集形成的资金集合	CashPool.rules
主子账户	资金池中归集主账户与参与子账户	PoolMember.relation
内部账户	成员单位间内部结算用的虚拟账户	InternalAccount

五、案例场景：一次头寸误判的复盘

某集团财务公司在TMS上线初期，日间头寸看板显示可用头寸充足，但下午实际支付时却出现两笔大额付款失败。复盘发现：系统只读取了银行账面余额，未扣减当日已审批但尚未支付的预留金额，也未计入一笔在途出账。结果账面余额虚高，可用头寸被高估。

修正方案是在头寸引擎中增加“预留池”和“在途池”两个数据源，并设置定时刷新与事件触发双机制。修正后，可用头寸与实际情况的偏差从平均8%降至1%以内。

六、设计要点小结

1. 先定义清楚“头寸”的计算口径，再设计数据库字段，避免后期返工。
2. 流动性预测必须基于现金流事件，而不是简单的外推余额。
3. 资金池是规则集合，账户体系是层级结构，二者在数据模型上应解耦。
4. 所有调整项都要可追溯、可审计，保留快照与变更日志。
5. 头寸与流动性的刷新频率应根据业务节奏设定，日间高频、日终全量。