还款运营监控闭环优化
1. 目标
面向 kasykredit 和 poketbuy 建立一套可每日复盘、可发现异常、可追溯回款的还款运营监控。运营人员能够清楚回答：当天应收多少、实际已入账多少、代扣是否完整触发、网页主动还款卡在哪个环节、各应还日截至今天回了多少。
还款成功的唯一业务口径为：资金完成 FCS 入账，即还款订单同时为 order_status=S、payment_status=S。支付渠道返回成功但未完成 FCS 入账，不得计为已还。
2. 范围与不纳入项
2.1 覆盖范围
| 维度 | 要求 |
|---|---|
| 业务线 | 每张报表必须按 kasykredit、poketbuy 分开出数；汇总仅作为附加行，不能替代分业务线数据。 |
| 代扣 | 正常应还批扣、逾期补扣、支付失败原因、未触发异常。 |
| 主动还款 | 网页主动还款的支付单生成、等待支付、支付失败、支付成功待入账、还款已入账。 |
| 回款 | 当日实际入账、虚拟账户实际入账、按应还日累计回款。 |
2.2 本期不纳入
- 虚拟账户“发起订单数”及其转化监控。当前生产记录只在到账回调后形成，不能把到账笔数当作发起笔数。
- 网页主动还款按“银行卡”拆分。现有网页支付记录没有可靠支付工具字段，不能把网页支付直接标为卡还。
- 单次代扣任务实例级监控。当前没有稳定贯穿全链路的批次运行编号，本期按业务日和扣款场景监控。
3. 运营报表与口径
3.1 还款总览（每日）
| 指标 | 运营含义 | 统计规则 |
|---|---|---|
| 当日计划应还金额（当前计划口径） | 当天正常到期的计划规模，不含此前已逾期计划 | 统计日应还日对应的当前计划金额；报表必须标注“按提取时当前计划”。 |
| 当日实际入账金额 | 当天真正收回并完成入账的金额 | 按 FCS 入账成功的业务日统计，同一还款订单只计一次。 |
| 代扣入账金额 | 自动扣款实际入账金额 | 正常应还批扣、逾期补扣等自动扣款入账之和。 |
| 网页主动还款入账金额 | 客户通过网页支付完成并入账的金额 | 网页支付单关联到 FCS 网页还款且已入账成功。 |
| 虚拟账户实际入账金额 | 虚拟账户到账后完成入账的金额 | 仅统计虚拟账户回调并完成 FCS 入账的金额。 |
| 其他主动还款入账金额 | 不属于网页支付或虚拟账户、但已识别为主动还款的入账 | 单独展示，禁止与网页支付或虚拟账户混报。 |
3.2 代扣执行监控（每日）
统计粒度固定为“业务日 + 业务线 + 扣款场景”，扣款场景仅为“正常应还批扣”和“逾期补扣”。
| 指标 | 运营含义 |
|---|---|
| FCS 已生成待扣订单数/金额 | 已进入本次应扣范围，作为应扣基数。 |
| 渠道扣款已触发订单数/金额 | 已实际发起到支付渠道，作为执行基数。 |
| 订单/金额触发覆盖率 | 已触发除以已生成待扣；低于 100% 必须产生待跟进项。 |
| 未触发订单数/金额 | 已生成待扣但未发起渠道扣款；必须可下钻订单清单。 |
不显示“批次编号”。运营侧需要的是当天哪一类扣款没有跑全；在未补齐稳定运行编号前，禁止伪造单次批次归属。
3.3 网页主动还款监控（每日）
按“统计日期 + 业务线 + 实际环节”逐行展示，不再按内部还款方式代码展示。
| 实际环节 | 运营定义 | 是否需跟进 |
|---|---|---|
| 网页支付单已生成 | 客户已进入并生成网页支付单 | 否，作为当日发起基数。 |
| 等待用户支付 | 支付单仍待客户完成支付 | 超过配置时长后跟进。 |
| 支付失败 | 支付单已有失败结果 | 是，需结合失败原因优化支付体验。 |
| 支付成功待入账 | 网页支付已成功，但尚未形成 FCS 入账成功 | 是，优先排查回调、补偿和入账链路。 |
| 还款已入账 | 已完成 FCS 入账成功 | 否，计入网页主动还款实际回款。 |
每行展示订单数、金额、占当日网页支付单生成的订单/金额比例、是否需要运营跟进、跟进原因和数据来源。
3.4 代扣失败原因监控（每日）
按“业务日 + 业务线 + 标准失败原因”展示失败人数、失败订单数、失败人数占比。一个客户在同一业务日多次失败时，仅按最后一次失败原因计入失败人数；订单数保留所有失败尝试。
失败原因以支付流水的最终渠道返回为准；未生成支付流水的订单固定归类为“未生成支付流水/未触发”，单独告警。
3.5 应还日回款追踪（每日更新）
按“应还日期 + 业务线”展示计划应还金额、截至最新业务日累计已入账金额、剩余未回金额、最新回款日期和回款完成率。已入账金额必须按还款分摊到对应应还计划，不能用全部还款金额直接按日期汇总。
4. 必须补齐的数据留存
4.1 每日应还快照
新增每日应还快照，在每日账务结转完成、正常应还批扣开始前固化。每条计划每天最多一条，至少记录：
- 业务日、业务线、快照时间、计划 ID、借据 ID；
- 应还日期、计划应还金额、期初未还金额、已还金额、调整金额；
- 借据状态、是否为当日正常应还、是否已逾期；
- 快照版本和来源时间。
历史复盘中的“当日计划应还金额”和“当日回款完成率”必须以该快照为分母。上线前的历史日期没有快照时，只允许展示“当前计划回溯口径”，并明确标识，不得与快照口径混用。
4.2 代扣运行标识
每次正常应还批扣或逾期补扣生成唯一运行编号，并把该编号带入待扣订单、支付订单、支付流水和最终入账记录。记录业务日、业务线、扣款场景、开始/结束时间、应扣与触发数量金额、失败数量金额和运行状态。
4.3 网页主动还款状态事实
网页支付单需保留创建、支付成功、支付失败、回调收到、FCS 入账成功/失败的发生时间和关联标识。支付工具仅记录枚举值及支付流水引用，不记录卡号等敏感信息。网页支付单与 FCS 入账必须可一对一或明确一对多关联。
4.4 失败原因标准化
保留渠道原始返回码和原始文案，同时映射运营可读的标准原因分类。标准分类至少覆盖余额不足、账户/授权失效、银行卡限制、渠道超时、渠道系统异常、未触发、未知原因；映射版本须可追溯。
5. 出报与告警
- 每日固定出报，所有报表使用同一个业务日截止时间。
- 当日计划应还、当日实际入账、代扣入账、网页主动还款入账、虚拟账户实际入账之间必须可勾稽；差额进入数据核对清单。
- 代扣触发覆盖率低于 100%、支付成功待入账超时、未触发订单出现、单一失败原因占比异常、应还日回款完成率异常时，生成待跟进项。
- 待跟进项至少包含业务线、业务日、异常类型、订单/金额影响、当前环节、责任方、首次发现时间、处理状态和关闭说明。
6. 验收标准
- 运营可在同一工作簿查看两条业务线的日报、代扣执行、网页主动还款、失败原因和应还日回款追踪。
- 任意“已还”指标均可下钻到 FCS 入账成功事实，且不会把渠道成功未入账计为已还。
- 从上线首日开始，任一历史业务日可使用当日应还快照复算计划应还金额和回款完成率；同一日期重复出报结果一致。
- 正常应还批扣与逾期补扣均可验证“已生成待扣—已发起渠道扣款—已完成 FCS 入账”的数量和金额链路。
- 网页主动还款可区分五个实际环节；虚拟账户不再出现发起数或发起率指标。
- 报表 SQL、数据字典和飞书表头使用同一套中文运营名称，并保留数据来源与口径说明。