SOP for finding structural gap…

# 电商本体缺口检查报告（示例：v2.3 版本本体）

一、检查范围与方法

以示例案例“用户A在平台下单3件商品，微信支付299元，7天后退款1件并申请开票”为走查场景，逐一核对类与属性的覆盖度。

二、“订单—支付”缺口分析

已有关系：

• 订单 hasPayment 支付单 ✅
• 支付单 belongsTo 订单 ✅（双向冗余，可接受）

识别出的缺口：

1. 缺失属性：支付单.refundStatus（退款状态） ❌

• 建议增加枚举值：无退款 / 退款申请中 / 已退款 / 部分退款 / 退款失败
• 走查场景暴露问题：A退款1件（99元）后，原支付单299元与实付200元不一致，现有本体无处记录“部分退款”事实。

2. 缺失属性：支付单.refundAmount（退款金额）+ refundReason（退款原因） ❌

3. 缺失关系：退款单 RefundOrder 独立类 ⚠️

• 建议：订单 hasRefund 退款单，退款单 relatesTo 支付单，避免把退款塞进支付单单条记录导致状态机混乱。

4. 时序属性缺失：支付单.paidAt（支付时间）存在，但 refundAt（退款完成时间）缺失 ❌

三、“发票”类检查结论：确认漏了关联 ❌

走查证据：A开票时需知道“哪笔订单、实付多少、哪些商品”，但当前发票类仅有 invoiceType、title、taxNo，存在以下缺口：

| 缺口 | 建议补法 |

|---|---|

| 发票→订单 关系缺失 | 增加 发票 issuedFor 订单，多重数 1:N（一笔订单可拆多张发票） |

| 发票→退款单 关系缺失 | 退货开票需冲红：增加 发票 reversedBy 退款单 |

| 发票.amount 计算规则缺失 | 应绑定“订单实付 - 已退款金额”，需依赖第二节的退款属性补全 |

| 发票.status 缺失 | 补枚举：待开 / 已开 / 已冲红 / 已作废 |

四、修复优先级

1. 🔴 P0：发票.issuedFor 订单（阻断开票业务）

2. 🔴 P0：支付单.refundStatus + 退款单类（阻断售后链路）

3. 🟡 P1：refundedAmount / refundAt / 发票冲红关系

4. 🟢 P2：发票.status 状态机补全

五、落地建议

补齐后重跑本走查案例，验证链路：订单→支付→部分退款→差额开票，即可闭环。建议同步更新 OWL 基数约束（如 issuedFor cardinality ≥1）并在变更日志标记 v2.4。