# 连锁业务对账系统状态流转设计 ## 1. 文档目的 本文档定义连锁业务对账系统中各核心对象的标准状态、状态流转条件、聚合规则、分账阻断关系和人工操作边界。 本文档是 P1-05 状态设计成果,作为数据模型详细设计、产品能力地图、功能架构、页面展示、接口协议、权限控制和验收测试的统一依据。 ## 2. 状态设计原则 1. 不使用单一总状态承载同步、归属、核销、结算、退款、差异、分账和入账等不同语义。 2. 状态必须归属于明确业务对象,不能只存在于页面展示层。 3. 支付明细是核销和分账准备状态的最小对象,订单状态由支付明细聚合。 4. 已支付、已核销、已结算、可分账、已输出和已入账是相互独立的状态。 5. 状态变更必须由业务事件、有效数据或授权操作触发,并保留时间和操作来源。 6. 已确认或已输出结果发生变化时,不直接覆盖历史状态,使用撤销、冲正、失效或新版本处理。 7. 人工操作不能绕过金额平衡、归属唯一、累计金额上限和客户隔离等强制约束。 8. 状态名称在接口、数据库、页面和报表中保持一致,不允许各模块自行创造同义状态。 ## 3. 状态维度总览 | 状态维度 | 核心对象 | 回答的问题 | | --- | --- | --- | | 数据同步状态 | 接入批次、订单、支付明细、账单等 | 数据是否已按时、完整进入系统 | | 标准化状态 | 原始记录、标准对象 | 原始数据是否成功转换为标准模型 | | 归属状态 | 订单、支付明细、账单明细 | 客户、门店、经营主体和结算主体是否明确 | | 支付平衡状态 | 业务订单 | 订单应收是否被支付明细完整覆盖 | | 核销状态 | 支付明细、账单明细、退款明细 | 应核对金额是否完成匹配 | | 渠道结算状态 | 账单明细、结算单 | 是否达到平台应结算时间并完成结算 | | 退款状态 | 退款单、退款明细、退款流水 | 退款业务和实际执行是否完成 | | 差异状态 | 差异记录 | 异常由谁处理、是否解决、是否阻断 | | 对账确认状态 | 支付明细 | 核销、退款、费用和归属结果是否已确认 | | 分账准备状态 | 支付明细 | 当前金额是否允许输出给分账系统 | | 分账输出状态 | 可分账结果 | 结果是否已成功交付分账系统 | | 分账执行状态 | 分账结果 | 分账系统是否完成分账 | | 银行入账状态 | 分账结果、入账反馈 | 分账资金是否实际进入银行账户 | ## 4. 状态之间的关系 ```mermaid flowchart LR A["数据同步状态"] --> B["标准化状态"] B --> C["归属状态"] C --> D["支付平衡状态"] D --> E["核销状态"] E --> F["对账确认状态"] G["渠道结算状态"] --> F H["退款状态"] --> F I["差异状态"] --> F F --> J["分账准备状态"] J --> K["分账输出状态"] K --> L["分账执行状态"] L --> M["银行入账状态"] ``` 该图只表达依赖关系,不表示所有状态必须串行。渠道结算、退款、差异处理可能与核销并行推进。 ## 5. 数据同步状态 ### 5.1 状态定义 | 状态 | 定义 | 是否异常 | | --- | --- | --- | | 等待同步 | 尚未到客户约定的数据完整截止时间 | 否 | | 同步中 | 接口、文件或批次正在接收和处理 | 否 | | 已同步 | 数据已接收,但尚未完成完整性校验 | 否 | | 已完整 | 批次范围、数量和金额等完整性校验通过 | 否 | | 不完整 | 超过完整截止时间后数据仍有缺失 | 是 | | 同步失败 | 接口、文件解析或任务执行失败 | 是 | | 已补齐 | 原缺失或失败数据已通过补传补齐 | 否 | | 已失效 | 批次被撤销、替换或确认不再使用 | 否 | ### 5.2 收银订单 D+1 流转 ```mermaid stateDiagram-v2 [*] --> 等待同步 等待同步 --> 同步中: D+1批次开始 同步中 --> 已同步: 数据接收完成 同步中 --> 同步失败: 接口或文件失败 已同步 --> 已完整: 完整性校验通过 已同步 --> 不完整: 截止时间后校验不通过 同步失败 --> 同步中: 重试或补传 不完整 --> 已补齐: 补传并校验通过 已补齐 --> 已完整: 重新确认批次 已完整 --> 已失效: 批次被有效新版本替换 ``` ### 5.3 D+1 约束 - 数据完整截止时间前,订单或支付明细尚未到达时保持等待同步,不生成正式缺失差异。 - 截止时间后仍有缺失时进入不完整,并生成同步缺失差异。 - 实时数据可以提前进入已同步,但仍需通过 D+1 完整批次校验后进入已完整。 - 后到或补传数据需要触发标准化、核销和差异状态重新评估。 ## 6. 标准化状态 | 状态 | 定义 | 后续处理 | | --- | --- | --- | | 待标准化 | 原始数据已接收,尚未转换 | 等待标准化任务 | | 标准化中 | 正在执行字段、金额和时间转换 | 禁止重复处理 | | 标准化成功 | 已生成或更新标准对象 | 进入归属解析 | | 标准化失败 | 必填字段、格式或映射失败 | 生成数据质量差异 | | 待配置 | 缺少字典、字段映射或规则配置 | 配置完成后重试 | | 已失效 | 原始版本被新版本替代 | 保留历史,不参与当前处理 | ```mermaid stateDiagram-v2 [*] --> 待标准化 待标准化 --> 标准化中 标准化中 --> 标准化成功 标准化中 --> 标准化失败 标准化中 --> 待配置 标准化失败 --> 待标准化: 数据补传或修正 待配置 --> 待标准化: 配置完成 标准化成功 --> 已失效: 新版本替换 ``` ## 7. 归属状态 ### 7.1 状态定义 | 状态 | 定义 | 分账影响 | | --- | --- | --- | | 待归属 | 尚未执行归属解析 | 阻断 | | 归属成功 | 门店及必需主体唯一明确 | 不阻断 | | 归属缺失 | 未找到有效映射或主体关系 | 阻断 | | 归属冲突 | 找到多个有效关系或关系相互冲突 | 阻断 | | 待人工确认 | 已生成归属差异并等待处理 | 阻断 | | 人工已确认 | 人工指定唯一归属并留痕 | 不阻断 | | 已失效 | 归属结果被撤销或新版本替代 | 不参与当前处理 | ### 7.2 流转 ```mermaid stateDiagram-v2 [*] --> 待归属 待归属 --> 归属成功: 唯一匹配 待归属 --> 归属缺失: 无有效关系 待归属 --> 归属冲突: 多个或冲突关系 归属缺失 --> 待人工确认 归属冲突 --> 待人工确认 待人工确认 --> 人工已确认: 指定唯一归属 人工已确认 --> 已失效: 撤销确认 已失效 --> 待归属: 重新解析 ``` 门店映射冲突必须进入待人工确认,不允许通过优先级自动选择门店。经营主体按照业务发生营业日期匹配当日唯一有效关系。 ## 8. 订单支付平衡状态 | 状态 | 判定条件 | | --- | --- | | 待校验 | 订单或支付明细尚未完整 | | 平衡 | 有效支付明细应核对金额合计等于订单应收金额 | | 不平衡 | 两者金额不一致 | | 待补充支付明细 | 订单已到达但支付构成尚未完整 | | 已冲销 | 订单被有效取消或完全冲销,不再参与正常对账 | ```text 订单应收金额 = 有效支付明细应核对金额合计 ``` 订单支付不平衡时不得进入正常自动核销,但已明确为无须参与对账的抹零、免单或内部承担项可以按标准支付或调整对象补齐后重新校验。 ## 9. 支付明细核销状态 ### 9.1 状态定义 | 状态 | 判定条件 | | --- | --- | | 待核销 | 已具备核销对象,但尚未执行匹配 | | 核销中 | 自动或人工核销任务正在执行 | | 未核销 | 有效核销金额为 0 | | 部分核销 | 有效核销金额大于 0 且小于应核对金额 | | 已核销 | 有效核销金额等于应核对金额 | | 核销冲突 | 存在多个候选匹配且无法唯一确定 | | 暂停核销 | 因归属、数据质量或人工冻结暂停 | | 已撤销 | 原有效核销记录已撤销 | ### 9.2 金额判定 ```text 未核销金额 = 支付明细应核对金额 - 有效核销金额合计 ``` | 金额结果 | 核销状态 | | --- | --- | | 有效核销金额 = 0 | 未核销 | | 0 < 有效核销金额 < 应核对金额 | 部分核销 | | 有效核销金额 = 应核对金额 | 已核销 | | 有效核销金额 > 应核对金额 | 金额异常,不允许进入已核销 | ### 9.3 流转 ```mermaid stateDiagram-v2 [*] --> 待核销 待核销 --> 核销中 核销中 --> 未核销 核销中 --> 部分核销 核销中 --> 已核销 核销中 --> 核销冲突 待核销 --> 暂停核销 核销冲突 --> 核销中: 人工选择或规则修正 未核销 --> 核销中: 新账单或流水到达 部分核销 --> 核销中: 后续账单到达 已核销 --> 已撤销: 撤销有效核销 已撤销 --> 待核销: 重新核销 暂停核销 --> 待核销: 解除暂停 ``` ## 10. 渠道账单核销状态 渠道账单明细可以关联一条或多条支付明细,其状态按照账单可核销金额计算: | 状态 | 定义 | | --- | --- | | 待核销 | 尚未执行支付明细匹配 | | 未核销 | 无有效支付明细核销 | | 部分核销 | 部分账单金额已关联支付明细 | | 已核销 | 账单可核销金额已全部匹配 | | 核销冲突 | 候选支付明细无法唯一确定 | | 超额核销 | 有效核销金额超过账单可核销金额 | | 已撤销 | 账单核销关系已撤销 | 账单核销状态与渠道结算状态独立。一条账单明细可以已核销但尚未结算,也可以已进入结算单但订单侧仍未完成核销。 ## 11. 渠道结算状态 ### 11.1 状态定义 | 状态 | 定义 | 是否异常 | | --- | --- | --- | | 待计算周期 | 尚未匹配 D+N/T+N 规则 | 否 | | 周期规则异常 | 规则缺失或同优先级冲突 | 是 | | 待结算 | 已计算预期结算日,尚在正常周期或宽限期内 | 否 | | 结算超期 | 超过预期结算日及宽限期仍无有效结算 | 是 | | 部分结算 | 累计有效归集金额小于可结算金额 | 视规则 | | 已结算 | 累计有效归集金额等于可结算金额 | 否 | | 结算异常 | 超额归集、重复归集或批次金额不平 | 是 | | 已撤销 | 原结算归集或结算单已撤销 | 否 | ### 11.2 流转 ```mermaid stateDiagram-v2 [*] --> 待计算周期 待计算周期 --> 待结算: 唯一匹配周期规则 待计算周期 --> 周期规则异常: 规则缺失或冲突 周期规则异常 --> 待计算周期: 配置修正 待结算 --> 部分结算: 收到部分结算归集 待结算 --> 已结算: 一次完成结算 待结算 --> 结算超期: 超过宽限期 结算超期 --> 部分结算: 后到结算 结算超期 --> 已结算: 后到完整结算 部分结算 --> 已结算: 后续归集完成 部分结算 --> 结算异常: 超额或重复归集 已结算 --> 已撤销: 结算撤销 已撤销 --> 待结算: 重新归集 ``` 周期规则按客户企业、品牌和平台隔离,不跨品牌兜底。D+N/T+N 规则到期前不生成结算超期差异。 ## 12. 退款状态 ### 12.1 退款单状态 | 状态 | 聚合条件 | | --- | --- | | 待拆分 | 尚未生成完整退款明细 | | 退款处理中 | 至少一条退款明细正在执行 | | 部分退款 | 部分退款明细完成,仍有未完成明细 | | 退款完成 | 全部退款明细完成 | | 退款失败 | 全部有效退款路径失败且未继续处理 | | 退款异常 | 存在超额、重复或原支付关联异常 | | 已撤销 | 退款单被有效撤销且未产生不可逆退款 | ### 12.2 退款明细状态 | 状态 | 定义 | | --- | --- | | 待退款 | 已关联原支付明细,尚无有效退款流水 | | 退款中 | 已发起退款,等待执行结果 | | 部分退款 | 有效退款流水金额小于业务退款金额 | | 退款完成 | 有效退款流水金额等于业务退款金额 | | 退款失败 | 实际退款执行失败 | | 退款冲突 | 多条流水、跨方式退款或重复退款风险待确认 | | 已撤销 | 退款明细已撤销 | ### 12.3 退款明细流转 ```mermaid stateDiagram-v2 [*] --> 待退款 待退款 --> 退款中: 发起退款 退款中 --> 部分退款 退款中 --> 退款完成 退款中 --> 退款失败 部分退款 --> 退款中: 继续退款 退款失败 --> 退款中: 重试或更换方式 退款完成 --> 退款冲突: 发现重复退款风险 退款冲突 --> 退款完成: 确认无重复 待退款 --> 已撤销: 撤销退款 ``` 退款状态按退款明细分别影响原支付明细,不使用退款单总状态一次性阻断订单下全部支付明细。 ## 13. 差异处理状态 ### 13.1 状态定义 | 状态 | 定义 | | --- | --- | | 待分派 | 差异已生成,尚未确定责任人 | | 待处理 | 已分派,等待处理 | | 处理中 | 责任人正在调查或补充材料 | | 待协同 | 等待其他部门、门店、平台或上游系统处理 | | 待复核 | 处理人已提交结论,等待复核 | | 已关闭 | 差异已解决或确认不再构成异常 | | 暂缓处理 | 因外部条件或争议暂停 | | 已驳回 | 复核不通过,退回处理 | | 已失效 | 来源对象撤销或重新计算后差异不再有效 | ### 13.2 流转 ```mermaid stateDiagram-v2 [*] --> 待分派 待分派 --> 待处理: 分派责任人 待处理 --> 处理中 处理中 --> 待协同: 需要外部协作 待协同 --> 处理中: 协作结果返回 处理中 --> 待复核: 提交处理结论 待复核 --> 已关闭: 复核通过 待复核 --> 已驳回: 复核不通过 已驳回 --> 处理中 处理中 --> 暂缓处理 暂缓处理 --> 处理中: 恢复处理 待分派 --> 已失效: 来源重算 待处理 --> 已失效: 来源重算 ``` ### 13.3 阻断状态 差异处理状态和分账阻断属性分开保存: - 阻断:差异未关闭前对应支付明细不可分账。 - 不阻断:可以继续分账,但差异仍需跟踪。 - 人工暂缓:不改变差异性质,但人工控制对应支付明细暂缓分账。 关闭差异不等于自动可分账,系统仍需重新执行全部分账前置条件。 ## 14. 对账确认状态 | 状态 | 定义 | | --- | --- | | 待确认 | 核销结果已产生,但尚未完成综合检查 | | 确认中 | 系统或人工正在检查退款、费用、归属和差异 | | 已确认 | 支付明细确认金额及相关条件已确认 | | 确认失败 | 金额、归属或规则校验不通过 | | 已撤销 | 原确认结果失效 | | 待重新确认 | 后到数据、退款或配置变化要求重新确认 | ```mermaid stateDiagram-v2 [*] --> 待确认 待确认 --> 确认中 确认中 --> 已确认 确认中 --> 确认失败 确认失败 --> 待确认: 问题修复 已确认 --> 待重新确认: 后到数据或业务变化 已确认 --> 已撤销: 授权撤销 待重新确认 --> 确认中 已撤销 --> 待确认 ``` 人工确认不能将未平衡金额、冲突归属或超额核销强制改为已确认。 ## 15. 分账准备状态 ### 15.1 状态定义 | 状态 | 定义 | | --- | --- | | 待判断 | 尚未执行分账前置条件检查 | | 不可分账 | 存在尚未满足的数据、核销、退款、归属或差异条件 | | 暂缓分账 | 条件基本满足,但因争议、调查、风险控制或人工冻结暂不输出 | | 可分账 | 所有前置条件满足,已形成可分账金额 | | 已失效 | 原可分账结果因退款、撤销或数据变化失效 | | 待重新计算 | 后到数据或规则变化要求重新计算 | ### 15.2 流转 ```mermaid stateDiagram-v2 [*] --> 待判断 待判断 --> 不可分账: 前置条件不满足 待判断 --> 暂缓分账: 人工冻结或争议 待判断 --> 可分账: 前置条件全部满足 不可分账 --> 待判断: 数据或差异更新 暂缓分账 --> 待判断: 解除暂缓 可分账 --> 待重新计算: 退款或后到数据 可分账 --> 已失效: 撤销确认 待重新计算 --> 待判断 已失效 --> 待判断: 重新处理 ``` ### 15.3 可分账强制条件 支付明细进入可分账至少需要: - 订单有效且支付平衡。 - 归属状态为归属成功或人工已确认。 - 对账确认状态为已确认。 - 退款状态明确。 - 不存在有效阻断型差异。 - 支付明细结算主体关系已确认且金额平衡。 - 未被人工冻结。 - 场景要求等待渠道结算时,渠道结算条件已满足。 ## 16. 分账输出状态 | 状态 | 定义 | | --- | --- | | 未输出 | 可分账结果已生成,尚未发送 | | 输出中 | 正在调用分账系统 | | 输出失败 | 调用失败或未收到有效回执 | | 已发送 | 请求已发送,等待接收确认 | | 已接收 | 分账系统确认接收成功 | | 已拒绝 | 分账系统拒绝接收 | | 已撤销 | 原输出版本被撤销 | | 已替换 | 已由新版本结果替换 | ```mermaid stateDiagram-v2 [*] --> 未输出 未输出 --> 输出中 输出中 --> 已发送 输出中 --> 输出失败 已发送 --> 已接收 已发送 --> 输出失败: 回执超时 已发送 --> 已拒绝 输出失败 --> 输出中: 幂等重试 已拒绝 --> 未输出: 修正数据并生成新版本 已接收 --> 已撤销: 分账前撤销成功 已接收 --> 已替换: 新版本接收成功 ``` 只有收到分账系统有效接收回执后才能进入已接收。网络调用成功但无业务回执时仍不能视为已接收。 页面如需使用“已输出分账”作为业务标签,应将其定义为输出状态已接收,不新增独立的“已输出”原子状态。 ## 17. 分账执行状态 分账执行状态由分账系统生成并反馈,对账系统只记录: | 状态 | 定义 | | --- | --- | | 待分账 | 已接收但尚未执行 | | 分账中 | 正在执行分账 | | 部分成功 | 部分参与方分账成功 | | 分账成功 | 本次分账全部成功 | | 分账失败 | 本次分账失败 | | 已退回 | 分账资金被退回 | | 已冲正 | 原分账结果已执行冲正 | 分账失败或退回不反向改变支付明细已核销状态,但会形成分账执行异常。 ## 18. 银行入账状态 ### 18.1 分账结果入账状态 | 状态 | 金额判定 | | --- | --- | | 待入账 | 有效入账关联金额为 0 | | 部分入账 | 有效入账关联金额大于 0 且小于应入账金额 | | 已入账 | 有效入账关联金额等于应入账金额 | | 入账异常 | 有效关联金额超过应入账金额或关联冲突 | | 入账失败 | 银行或资金处理失败 | | 已退回 | 已入账资金发生退回 | ### 18.2 流转 ```mermaid stateDiagram-v2 [*] --> 待入账 待入账 --> 部分入账: 收到部分有效入账 待入账 --> 已入账: 一次完整入账 待入账 --> 入账失败 部分入账 --> 已入账: 后续入账完成 部分入账 --> 入账异常: 超额或冲突关联 已入账 --> 已退回: 银行退回 入账失败 --> 待入账: 重新处理 已退回 --> 待入账: 重新发起入账 ``` 银行入账属于分账后状态,不回退订单、支付明细或账单的核销与结算状态。 ## 19. 订单聚合状态 订单状态只用于汇总展示,不作为支付明细处理的替代状态。 ### 19.1 订单核销状态 | 聚合状态 | 判定规则 | | --- | --- | | 待核销 | 全部有效支付明细均未进入核销 | | 未核销 | 全部有效支付明细均为未核销 | | 部分核销 | 支付明细状态不完全一致,或至少一条为部分核销 | | 已核销 | 全部有效支付明细均为已核销 | | 核销异常 | 至少一条支付明细存在核销冲突、超额或暂停 | ### 19.2 订单结算状态 | 聚合状态 | 判定规则 | | --- | --- | | 待结算 | 需要渠道结算的支付明细均未完成结算 | | 部分结算 | 仅部分需结算支付明细已结算,或存在部分结算 | | 已结算 | 全部需要渠道结算的支付明细均满足结算条件 | | 结算异常 | 存在周期规则异常、超期或结算异常 | | 不适用 | 订单全部由无外部结算的内部权益构成 | ### 19.3 订单分账准备状态 | 聚合状态 | 判定规则 | | --- | --- | | 全部不可分账 | 所有有效支付明细均不可分账 | | 部分可分账 | 至少一条可分账,且并非全部可分账 | | 全部可分账 | 所有有效支付明细均可分账 | | 部分暂缓 | 至少一条支付明细暂缓分账 | | 已全部输出 | 所有可分账支付明细均已被分账系统接收 | 订单聚合状态不得阻止已满足条件的支付明细先行输出。 ## 20. 状态重算触发事件 以下事件需要触发相关对象状态重算: - D+1 订单或支付批次到达、补传或修正。 - 新渠道账单、结算单或结算归集明细到达。 - D+N/T+N 预期结算日或宽限期到期。 - 新退款单、退款明细或退款流水到达。 - 权益流水、现金流水或现金汇缴批次到达。 - 门店映射、经营主体关系或结算主体关系完成确认。 - 费用项、容差规则或结算调整项发生变化。 - 差异关闭、驳回、失效或阻断属性变化。 - 人工冻结或解除冻结。 - 可分账结果输出回执返回。 - 分账结果或银行入账反馈返回。 状态重算必须保证幂等,不得重复累计核销、结算、退款、可分账或入账金额。 ## 21. 状态变更审计 每次状态变更至少记录: - 客户企业。 - 对象类型和对象标识。 - 状态维度。 - 原状态和新状态。 - 触发事件类型。 - 触发数据或任务标识。 - 系统规则版本。 - 操作人或来源系统。 - 状态变更时间。 - 变更原因。 - 是否人工操作。 - 关联差异、核销、退款或输出版本。 禁止直接修改状态字段而不产生状态变更记录。 ## 22. 页面展示规则 1. 页面应分别展示核销、结算、退款、差异、分账准备、输出和入账状态。 2. 不使用“已完成”作为跨流程通用状态。 3. 订单列表展示聚合状态,支付明细列表展示原子状态。 4. 状态标签必须可以追溯到金额和状态变更记录。 5. 异常状态需要同时展示责任人、阻断属性和下一处理动作。 6. D+1 截止前显示等待同步,不显示订单缺失。 7. D+N/T+N 宽限期前显示待结算,不显示结算超期。 ## 23. 状态边界 - 已支付不等于已核销。 - 已核销不等于已结算。 - 已结算不等于可分账。 - 可分账不等于已输出。 - 已输出不等于分账成功。 - 分账成功不等于已入账。 - 差异已关闭不等于自动可分账。 - 订单已核销不代表订单下全部退款均已完成。 - 银行入账异常不回退订单核销状态。 ## 24. 评审重点 1. 状态是否全部归属于明确业务对象。 2. 核销、结算、退款、差异、分账和入账是否相互独立。 3. 支付明细状态能否准确聚合为订单展示状态。 4. D+1 同步和 D+N/T+N 结算是否具有等待、超期和补传状态。 5. 部分核销、部分结算、部分退款和部分入账是否均可表达。 6. 撤销、冲正、重算和新版本是否不会覆盖历史结果。 7. 人工状态变更是否具备权限、复核和审计要求。 8. 状态是否能够直接支持后续页面、接口和测试设计。