订单和退款怎么建模？跨月退款应算在哪一天？
面试怎么回答
订单与退款属于不同业务过程，我会分别保存订单行事实和退款明细事实，通过原订单行建立可追溯关联。退款发生日用于看当天退了多少，原订单日期用于看某批订单截至现在退了多少，两种指标不能混名。跨月退款不靠改日期解决。汇总时先把各自事实聚合到共同粒度，避免一对多放大，并统一成功状态、冲正和统计截至时间。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一笔 8 月底的订单，9 月才退款。看板负责人说应该扣在 9 月，活动复盘的人说应该算回 8 月。这时如果急着判断谁对谁错，很容易把两个不同的问题塞进同一个“净销售额”。
订单与退款先保留各自粒度；退款发生日和原订单归属日回答不同问题，必须分别命名和对账。
先分过程，不要只给订单加一个退款字段
订单行描述卖了什么、卖了多少；退款明细描述哪次退款、针对哪个订单行、成功退了多少。一个订单行可能多次部分退款，一次退款申请也可能涉及多个商品，因此要明确退款明细的唯一标识及拆分规则。
仅在订单表保存一个“累计退款额”，适合看当前状态，但很难还原每天发生的退款，也难以解释金额在哪次变更后改变。比较稳妥的基础是销售事实与退款事实分别保留，再按需要派生累计状态。
退款申请、审核通过和实际退款成功也不是同一事件。统计成功退款额时，应使用已约定的成功状态和对应时间，不能拿申请时间代替完成时间。
两个日期，回答两件事
第一种是发生口径：某天销售了多少、某天成功退款多少。它描述这一天发生的业务活动，即使退款对应的订单来自上个月，也应在当天退款指标里出现。
第二种是订单归属口径：某一批订单截至观察时点，累计退了多少，还剩多少。它适合活动质量、渠道退款率等分析。这里的退款仍保留真实发生日期，只是分析时归属原订单批次。
比如 8 月 31 日支付 100 元，9 月 3 日成功退 30 元。发生口径在 9 月记录退款 30 元；订单归属口径看到这笔 8 月订单截至 9 月 3 日净额为 70 元。两张报表不同，不代表数据错了。
本文讨论经营分析建模，不替代收入确认、财务结账或税务制度。若有这类要求，应按组织已经确认的规则建模，不能直接把经营口径公式当成财务口径。
关联关系正确，不代表汇总就正确
假设订单行 O1 销售 100，之后退款 R1 为 20、R2 为 10。直接把订单行关联到退款明细，再 SUM 销售金额，会得到 200；退款 30 没错，但销售额被一对多关系放大了。
应先将退款聚合到订单行粒度，再与订单行关联，得到销售 100、累计退款 30。若做发生日看板，则销售和退款各自按日期、店铺等共同维度聚合，再合并结果，而不是先把两张明细硬连起来。
退款金额还要说明是否包含运费、优惠分摊和其他费用。不能把订单级退款总额完整复制到每个商品行；需要单独记费用项，或使用可解释且能对回总额的分摊规则。
一个典型场景：部分退款后，销售额反而涨了
比如看板上线后，普通订单没有问题，多次部分退款订单却显示更高销售额。最初可能怀疑源订单被重复同步，但查看订单事实发现仍然只有一行。
真正的重复发生在查询阶段：一个订单行匹配到两条退款记录，销售金额被带出了两次。测试只覆盖无退款和一次退款，所以没有暴露一对多。修复应先统一汇总粒度，并增加“连接前后销售金额不变”的检查，而不只是检查源表主键唯一。
对账还需要一个明确的观察时点
订单归属口径会随着后续退款变化，因此“8 月订单退款率”必须带上截至日期或观察窗口。今天和下周查询同一批订单，结果可能不同；不标注这个条件，很容易被误认为历史数据漂移。
同时要处理撤销、失败、重复通知和冲正。原始事件保留完整轨迹，分析事实按明确规则取有效版本；需要历史复盘时，再保留冻结快照或版本，不要让最新状态覆盖掉所有历史解释。
我会把对账拆成几层：退款明细唯一，明细汇总能对回退款单，退款能追溯原订单行，指标名称能说明日期口径与截至时间。只有最后的总金额相等，还不足以证明模型可靠。