导图社区 延迟转账对账场景梳理
这是一篇关于延迟转账对账场景梳理的思维导图，梳理了延迟转账对账的各类场景、处理方案、数据迁移及注意事项，为相关业务处理提供了清晰的指引。
社区模板帮助中心，点此进入>>
费用结算流程
租赁费仓储费结算
E其它费用
F1开票注意事项
F2结算费用特别注意事项
洛嘉基地文件存档管理类目
CFA一级Ethics-standard思维导图
货币政策对黄金价格的传导机制
云报税（个税）
收入
延迟转账对账场景梳理
正常场景
到账
银联：T+1日 1301 转出流水
核心：T日 1301 转出流水 T+1日 1307 转账结果通知流水（到账）
处理方式：核心转出不参与对账，银联T+1日补一笔转账结果通知流水
差错记录：无差错
撤销
银联：无流水
核心：T日 1301 转出流水 T+1日 1307 转账结果通知流水（撤销）
处理方式：核心转出不参与对账，转账结果通知撤销不参与对账
类型不符
银联当实时，行内当延迟
银联：T日 1301 转出转账
核心：T日 1301 转出转账，T+1日不能触发转账结果通知
处理方式：银联T日补一笔转账结果通知
差错记录：T日有一笔银联有我行无的，转账结果通知
银联当延迟，行内当实时 （新疆遇到的场景）
银联：转账结果通知失败，银联无流水，延迟转账登记薄无记录
核心：T日 1301 转出流水
差错记录：T日有一笔我行有银联无的转出转账差错
银联当延迟，行内当实时 （前置有正常的1307流水，核心没有，不登记延迟转账登记薄，银联的通知正常响应）
银联：T+1日有转出流水 核心：T日有转出流水
核心：T日核心多，T+1日延迟对平 银联：转出延迟对平 差错：T日延迟对平的核心多转出差错
银联当延迟，行内当实时（特殊场景） （前置有正常的1307流水，但是核心没有，也正常登记延迟转账登记薄）
到账 银联：T+1日有转出流水 核心：T日有转出流水
核心：转出不参与对账 银联：转出延迟对平 差错：T+1日，银联有我行无，结果通知
撤销 核心T日有转出，银联T+1日无流水 最终应该有一条核心多的差错
可能的异常场景
转账结果通知失败，银联T+1日无流水 最终应该有一条核心多的差错
状态错误
银联到账
核心转出成功，通知失败 贵一
差错记录：T+1日有一笔银联有我行无的，转账结果通知差错
核心转出失败，通知成功 贵三
报错
T+1 日有通知成功流水，无对应的转出流水
核心转出失败，通知失败 贵二
差错记录：银联有我行无，转出转账
银联撤销/到账结果通知失败
核心转出成功，撤销失败 贵四
差错记录：我行有银联无，转出转账
银联无转出，核心无通知，有转出。调整转出转账为核心多
核心转出成功，到账失败
核心转出失败，撤销失败（与银联状态相符）
核心转出失败，撤销成功 贵六
T+1 日有通知撤销流水，但没有原流水，银联一笔流水都没有
核心转出成功，到账成功 贵五
T+1 日有通知成功流水，T日有转出流水，银联一笔流水都没有
注意事项
实时转账也会发结果通知，不能以是否有结果通知来判断是否为延迟转账
GoldenDB 分布式模式
差错表为单分片表、对账表为多分片表时 设置了分片关键字STOREGEDB时，假设差错记录在g2分片，差错表为g1分片，会插入不到差错表中/插入报主键冲突
处理方式：将差错清理和差错合并从对账step中拆出来
以此类推，update、delete在执行时也要格外注意
单笔批量更新巨慢（更新21万笔记录） update 表 set 字段=值 where batch_date=指定日期
需要在SQL语句后跟SW，避开分布式的各种校验，各分组节点并发执行
SW经过验证只适用于没有子查询的delete和update
不加SW慢的原因主要是，GoldenDB为了保证分布式数据一致性，select ... for update，加锁耗时很长
StoregeDB
添加后要求SQL相关的表都得有指定的分片名，如果要保证不漏更新/删除数据，需要保证被更新表和子查询分区规则一致
对账数据迁移
表设计
银联、核心、前置对账流水表：保留当前对账日期+前两日未对平+前两日转出和结果通知 分片不分区
历史表：存放所有对账数据 分片分区存储
对账方案
一、 三种报错场景校验 流水要素更新之后
银联通知到账行内反馈失败，核心转出成功，到账成功 （核心有到账成功和转出的流水，银联没有流水）
核心无转出，但有通知
银联到账，核心转出失败，通知成功
银联撤销，核心转出失败，撤销成功
二、 到账正常情况
银联、前置流水、延迟转账登记簿关联，补一笔转账结果通知流水 需要考虑两种场景 （1）银联当实时，行内延迟处理场景：前置无通知流水，需要通过银联转出的流水补，F7\F11\F32\F33和转出转账保存一致，PRE_TRAN_SEQ='APPEND'||转出.PRE_TRAN_SEQ （2）正常到账场景：使用前置转账结果通知流水要素补,F7\F11\F32\F33和转出转账保存一致,PRE_TRAN_SEQ和前置转账结果通知保持一致
删除补录的通知流水：银联有延迟的1301，前置有1307，核心没有通知
三、 流水勾兑（对平），原有逻辑
四、 银联当实时，行内当延迟 流水对平之后
将补录的转账结果通知流水，设置为银联多
条件：转出转账流水对平，但是在延迟转账登记薄中存在
五、 到账正常情况
1 更新核心转出转账，不参与对账
与前置、延迟转账登记薄关联
六、 撤销正常情况
1 核心撤销流水不参与对账
七、 流水勾兑（得出银联/核心多）原有逻辑
八、 差错补录 1 银联撤销成功、核心撤销失败 2 银联当延迟，行内当实时（特殊场景）
更新核心转出流水为核心多
核心有转出流水，无通知流水；银联无转出流水；前置有完整的转出和通知流水 （核心转出流水在<对账日期，前置通知流水=对账日期）
九、 延迟对平处理
十、 银联转出和通知都是银联多的情况，将通知调平，只保留转出的差错
银联延迟到账成功，核心转出成功，到账失败的情况下 经过上述处理，会出现两笔银联多的差错
放在第九步之后的原因 银联延迟到账成功，核心转出成功，到账失败的情况下。T+1日银联通知被调平，银联转出又延迟对平了。导致本身应该有一笔银联多的通知差错，结果一笔差错都没有了
老系统梳理场景
银联 核心 核心 处理 1301 1301 1307 一 有 有 无 √ 入账-银联多1307（1301-8） 二 有 无 无 × 报错-银联多1301 三 有 无 有 × 报错-银联多1301 四 无 有 无 √ 撤销-核心多1301（延迟3天） 五 无 有 有 × 报错-核心多1307 六 无 无 有 × 报错-核心多1307
