ODTS 75 — 额度管理（new-quota）：交易前的”钱包余额”

为什么需要这篇文档

31-Contract-Operations 里提过一句关键的踩坑：“额度预占失败导致交易被拒”。但”额度”本身——客户/账户到底有多少可交易额度、怎么查、怎么占用、怎么在日终重置——整个系列从没专篇写过。

代码库里有一个独立的额度管理前端 new-quota，它和交易簿记、风险管理都是分开的系统。一个 PM/BA 如果不理解额度，就理解不了”为什么交易台明明有意向、下单却被系统挡回来”这类最高频的运营问题的一半。

---

1. 它是什么

new-quota/                          — 独立 Vue 项目（和 new-edsweb 同级）
├── src/views/
│   ├── balanceList.vue             — 额度余额列表（核心）
│   ├── dailyList.vue               — 日终额度明细
│   ├── quotation.vue               — 询价/报价额度
│   ├── Inquiry.vue                 — 额度查询
│   ├── Feedback.vue                — 反馈
│   ├── ContactInfo.vue             — 联系信息
│   ├── login/  changePassword/  renewPassword/  retrievePassword/  initPassword/
│   └── newLayout.vue
└── src/api/
    ├── index.js
    └── inquiry.js

业务定位： 额度（quota）是交易前的”钱包余额”——在真正簿记一笔交易之前，系统要先确认这个交易账户/科目还有没有足够的可交易额度。它和 72 的 RiskRule（“能不能做”的前置拦截）是两道不同的闸：RiskRule 管”规则允不允许”，quota 管”额度够不够”。

---

2. 额度余额列表：系统最常被查的页面

balanceList.vue 调的接口是 /balance/getBalanceList，返回的字段直接说明了额度的数据模型：

字段	含义
tradeAccountName	交易账户
accountSubjectName	科目（额度按科目维度切分）
amount	额度金额
currencyName	币种
deskEntityName	所属 desk/实体
createTime	创建时间

业务含义： 额度不是”一个账户一个数字”，而是按 (交易账户 × 科目 × 币种 × desk 实体) 切分的网格。一个交易台可能对”股票收益互换”科目有 10 亿额度，对”雪球”科目只有 2 亿——这就是 31 文档里”额度预占失败”发生的位置：簿记雪球时，系统在 amount 里找不到足够余额。

---

3. 额度的几个视角

页面/接口	看什么	谁看
balanceList.vue	当前额度余额（按账户/科目/币种）	交易台/中台
dailyList.vue	日终额度明细——每天额度怎么变化的	运营/清算
quotation.vue	询价额度——报价环节能占用多少	销售/交易
Inquiry.vue	主动查”这个账户现在还有多少可用额度”	任何人
Feedback.vue / ContactInfo.vue	额度争议的反馈与联系人	运营

询价额度（quotation）的特殊性

quotation.vue 对应的是报价阶段的预占——在客户正式下单之前，销售可能先询价，这一步就会占用一部分询价额度。这解释了 31 文档里”为什么没成交也占了额度/为什么额度莫名变少”：报价预占如果不及时释放，会挤占真实交易的额度。

---

4. 额度 vs 保证金 vs 风控规则（三道闸，别搞混）

控制	维度	时点	失败表现
RiskRule（72）	规则允不允许做这个标的/产品/账户	交易提交时	”该账户禁止交易此产品”
额度（本文）	还有没有足够的额度余额	交易提交时（预占）	“额度不足，交易被拒”
保证金（16/73）	成交后押多少押金、要不要追保	成交后 / EOD	”请于今日 14:00 前补足”

一句话： 规则是”能不能进门”，额度是”进门要刷的卡里有没有钱”，保证金是”进门后押的押金”。三者独立裁决、任一不满足都挡交易。

---

5. 内行才知道的：额度预占是一次”先扣后还”的原子操作

额度最核心的工程难点是预占（reservation）的原子性：一笔交易提交时，系统要先”锁住”一部分额度（预占），交易成功就正式扣减，交易失败/取消就释放回去。如果预占和正式扣减之间发生系统故障，就会出现**“额度被锁死、谁也用不了”**的幽灵占用——这正是 31 文档里”额度预占失败导致交易被拒”的深层原因：不是额度真的没了，而是上一次预占没干净释放。

这又回到全系列反复出现的主题：分布式操作里”预留→确认/回滚”的状态必须严丝合缝，否则就会留下清理不掉的残影。和 05 的幽灵状态、72 的 deleteFlag 软删除、09 的状态机回退，是同一类教训在不同业务上的重演。

---

自测

• 额度在数据模型上是”一个账户一个数字”吗？如果不是，它按哪几个维度切分？
• 为什么”没成交的询价”也会让真实交易额度变少？
• 额度、RiskRule、保证金这三道闸，分别在交易的哪个时点起作用？
• “额度预占失败”在代码语义上，通常是”额度真没了”还是”上一次预占没释放”？为什么后者更危险？

相关阅读：31-Contract-Operations.md（额度预占踩坑）、72-Credit-and-Risk-Rules-Engine.md（前置规则拦截）、16-Margin-Calls-IM-and-VM.md（成交后押金）