ccdi/docs/plans/2026-03-16-large-transaction-project40-design.md

Project 40 Large Transaction Test Data Design

背景

project_id=40 对应项目为“大额交易模型测试”，当前 ccdi_bank_statement 中没有任何流水数据。目标是根据 assets/大额交易.csv 的业务口径，在开发库中直接插入一批能够稳定命中大额交易模型指标的测试流水。

现状

• 项目 40 已存在，但 ccdi_model_param 中没有项目级参数，命中逻辑将使用 project_id=0 的系统默认阈值。
• 可复用的测试身份已存在：
  • 员工 模型测试员工 / 330101198801010011
  • 家属 模型测试家属 / 330101199001010022
  • 员工 模型二测试员工 / 330101198802020033
  • 家属 模型二测试家属 / 330101199202020044
• 流水命中依赖的核心字段为 project_id、cret_no、trx_date、amount_dr、amount_cr、user_memo、customer_account_name、cash_type、le_account_name、le_account_no、accounting_date_id。

设计目标

• 为 大额交易.csv 中的每个指标至少生成一组稳定命中的流水。
• 直接写入开发库 ccdi_bank_statement，只影响 project_id=40。
• 除命中流水外，补充少量普通流水，避免页面展示只有极端数据。
• 插入后可以使用 大额交易.csv 中的 SQL 口径逐项核验。

设计方案

采用“指标命中 + 少量真实噪声”的平衡方案：

1. 为以下指标分别构造命中流水：
   • 房车消费支出
   • 税务支出
   • 单笔大额收入
   • 累计收入超限
   • 年流水交易额超限
   • 单笔大额存现
   • 单日多次存现
   • 单笔大额转账
2. 每个指标使用明显高于阈值的金额，避免边界值误差。
3. 复用两名员工和两名家属的证件号作为 cret_no，确保能命中员工本人及亲属范围。
4. 为每个账户生成一组连续日期和递增的 accounting_date_id，规避唯一键 (project_id, LE_ACCOUNT_NO, ACCOUNTING_DATE_ID, AMOUNT_DR, AMOUNT_CR) 冲突。
5. 补充少量普通转入、普通消费、工资代发等非命中流水，保证页面可读性，并验证排除逻辑。

数据策略

• 单笔大额收入：为员工本人生成大于 100000 的单笔收入，对手方不使用本人、家属和工资代发主体。
• 累计收入超限：为同一员工和同一外部对手方生成多笔累计收入，总额超过 50000001。
• 年流水交易额超限：在近一年内为同一员工生成大量转入与转出组合，使总交易额超过 50000001。
• 单笔大额存现：生成 amount_cr > 2000001 且摘要/交易类型命中现金存入关键词的流水。
• 单日多次存现：同一身份证同一天生成至少 6 笔满足大额存现条件的流水。
• 单笔大额转账：生成 amount_dr > 100001 且 user_memo / cash_type 命中转账关键词、同时避开“款”字排除条件的流水。
• 房车消费与税务支出：通过 user_memo 或 customer_account_name 命中关键词，且使用员工本人和家属证件号混合覆盖。

落库方式

• 新增一份独立 SQL 脚本，包含：
  • 插入前清理 project_id=40 既有测试流水
  • 批量插入设计好的流水数据
  • 插入后的核验 SQL
• 落库只操作 ccdi_bank_statement，不修改员工、家属、项目、参数等基础表。

验证方式

• 校验 project_id=40 的流水总数和涉及证件号是否符合预期。
• 按 大额交易.csv 的 SQL 口径逐项运行命中检查。
• 抽样查看流水明细中的摘要、对手方、金额、日期，确认页面展示可用。

风险与控制

• 若模型实现与 CSV 口径存在偏差，可能出现“SQL 能命中、页面不命中”的情况；因此落库后需要按数据库口径与页面结果双重验证。
• 由于 project_id=40 使用默认阈值，后续若产品调整项目级参数，当前测试数据可能不再命中；为避免误解，插入脚本会在注释中写明依赖的默认阈值。