京东 POP 整单轧差：8 步骤判定流程详解
京东整单轧差 8 步骤 判定流程
摘要：京东 POP 收入对账脚本 v3.3.1（默认铺种于 2026-09-10）的整单轧差判定的 8 个步骤——前置过滤 + 防误判闸门、R0 无供应链分支（4 子层）、R1 主匹配、零金额红冲判定、R2 部分结算、R3 营销券差异、R4 差异诊断（3 子层）、R5 兜底（3 子层）——每一步都有明确的触发前提、命中即停、标签码落库、是否出单的工程纪律。配套承载行机制保证同一订单多体行只出一张物料明细、不翻倍差异合计；防误判闸门保证「净额 0 + 无供应链单」不会被脚本误判为成功。
关键词：京东整单轧差、8 步骤、判定流程、承载行、防误判闸门、R0 无供应链分支、营销券差异、R5 兜底
600 单对账成功，但「这一单为什么对不上」才是检验对账系统的真问题
京东 POP 2026-07 计划：600 体行、收入 98,837.12 元、差异 0.00 元。但点开 600 行 diffReason 列，会看到一段机读码的标签雨：4 行 CANCELLED_UNSHIPPED、1 行 PARTIAL_SETTLEMENT、6 行 MARKETING_COUPON_DIFF、9 行 INSTANT_REFUND——每一个标签都对应一个被自动识别的真实业务场景 [来源：京东 POP 2026-07 计划 cmtqn5ek60fh06hhdqyccm075 重跑实测]。
上图是京东 POP 整单轧差的 8 步骤判定流程图。判定纪律只有一条：每步有明确执行前提，不满足不进该轮；命中即停。这条纪律保证了脚本能稳定处理 600 行订单而不相互干扰，也是它能在 7 月实测中只翻 4 行结论、其余 596 行零变化的原因 [来源：2026-09-07 v3.2.0 重跑实测]。
整单轧差是什么？为什么京东 v3.0.0 要彻底废弃分向对账
整单轧差：拿平台账单上同一订单的全部货款（正的销售 + 负的退款）合并成账单净额，对供应链净额（全部行金额合并）——对齐抖音 v3.3 的合并口径 [来源：京东 POP 对账主流程图说明（2026-09 定稿）]。
旧版 v2.2.8 用「分向对账」：正/负体行各自独立匹配。4 类场景会出问题——
| 场景 | 分向口径问题 | 整单轧差处理 |
|---|---|---|
| 换货（重发 + 退货两行） | 正向匹配把重发行算进来虚增供应链收入 | 退/发自然互抵，差异 +17.62 = 自营券，走 R3 命中（3525402000291770） |
| 极速退款（结算全额 + 钱包扣收负行） | 扣收负行把收入轧成净额恰好对平（伪成功） | 池白名单剔除扣收行，对出真实差异 691.00（3537424007903740） |
| 取消未发货 | 同订单正/负各自匹配失败 → 落 INSTANT_REFUND | 互抵单前置识别 → SUCCESS + CANCELLED_UNSHIPPED（3532466005975710 等 3 单） |
| 部分结算 | 正向匹配把多行一起拉进来对不上 | 账单净额 = 某条单行金额 → 子集下推 |
用户 2026-09-05 拍板：「合并（整单轧差）在京东同样适用，按抖音方式处理；之前的剔除逻辑不用了」[来源：京东 POP 整单轧差改造需求文档（2026-09-05）]。v3.3.1 是当前 DB 默认版本，2026-09-10 铺种生效。
三角对账的世界观：平台账单 ↔ 供应链订单 ↔ 内部核算
8 步骤脚本处理的是收入侧三方核对的第一条边：平台账单 ↔ 供应链订单。完整三角对账还包括第三条边——内部核算（核算项目树 + 物料明细），由承载行机制统一承担。
整单轧差 8 步脚本只负责「平台账单 → 供应链订单」的判定与打标，不直接出单——「出什么单」完全在集成转换环节由 13 个 diffReason 机读码映射决定。v3 对账体系最关键的一条职责分界：
对账阶段只打标——在体行上落
reconcileResult与diffReason；「出不出单、出什么单」全部在集成转换环节按标签映射决定。
理解这条边界后，8 步骤脚本的输出才是稳定的：只回答「这一行应该挂什么标签」，不回答「这一行应该进金蝶哪张单」。
8 步骤判定流程（v3.3.1 现行默认）
下面 8 步对应收入对账脚本 v3.3.1 的现行默认实现。每步列出触发条件、规则、输出和典型样本。
步骤 0 · 整单轧差前置（立账过滤 + 财务数量过滤 + 防误判闸门）
脚本不是直接进 R0/R1 的——有 3 道前置过滤 + 1 道防误判闸门。
3 道过滤（按序）：① 财务数量过滤（v3.3.0）：salFinBaseQty ≠ 0 = 金蝶已下推财务应收 → 排除；= 0 或空参与。② 立账类型过滤（v2.2.1）：有 setAccountType 值时只取 '2'（暂估应收）；全空不过滤，防两套单据金额翻倍。③ 钱包扣收红冲对称剔除（v3.3.1）：收入池只取结算资金表，账户流水负收入合计 > 0 且供应链红冲合计 ≈ 钱包扣收额（容差 0.01）→ 红冲行从净额合并中剔除；部分红冲/无钱包扣收不触发。
防误判闸门：过滤后供应链一行都没有时，即使账单净额 = 0 也不算成功 → 进 R0 链。互抵单必须前置识别：R0-a（取消订单互抵）必须先于闸门执行——互抵单账单净额为 0，不前置识别会被闸门全部落 MISSING_SUPPLY。
统一口径表：账单净额 = 同计划同订单号全部体行
incomeAmount合并；供应链净额 = 过滤后行amount合并；差异 = 账单净额 − 供应链净额；主匹配严格相等、无容差（v2.2 的 1 元尾差已废弃）；标签「金额一致」判定容差 0.01 元。——对账阶段统一口径表
步骤 1 · R0 无供应链分支（0-a / 0-b / 0-b2 / 0-c / 0-d 五子分支按序判定）
闸门触发后进入 R0 链，按序匹配 4 个已知无供应链场景 + 1 个兜底，命中即停：
| # | 触发条件 | 输出 | 典型样本 |
|---|---|---|---|
| 0-a 取消订单互抵 | 同订单「订单·货款」正收入 与「取消退款单·货款」负收入 互抵（容差 0.01） | SUCCESS + CANCELLED_UNSHIPPED，正/负体行同标签不经承载行裁决，差异落 0、只打标不出单 | 3532466005975710（±310.96） |
| 0-b 补差价链接 | 结算收明细商品名含「邮费差 / 差价 / 补差」 | SUCCESS + PRICE_DIFF_ORDER，差异额保留，出费用应收单 | — |
| 0-b2 仅退款（v3.1.0） | 聚水潭售后分类任一行 = 仅退款 | SUCCESS + REFUND_ONLY，差异落 0、只打标不出单 | 3558441011808741（2026-07，¥339） |
| 0-c 聚水潭退货类 | 聚水潭售后分类 ∈ {普通退货, 拒收退货} | FAILURE + INSTANT_REFUND，只打标不出单 | — |
| 0-d 兜底 | 以上均未命中 | FAILURE + MISSING_SUPPLY，不出单，人工核对 | — |
0-a 与 0-b2 是 8 步里唯二不经承载行裁决的分支——因为它们的净额都是 0，没有翻倍风险。0-c 是失败分支、0-d 是真失败兜底。
步骤 2 · R1 主匹配（严格相等，无容差）
账单净额 = 供应链净额（严格相等、无容差） → 成功，差异原因为空；承载行落
matchedSupplyIncome/Quantity= 净额；非承载行 → SUCCESS +NET_MERGED+ 金额 0 +skipMaterialItems=true。
R1 是脚本的主路径——多数订单在这一步就结束。严格相等意味着 1 元尾差容忍度都没有，这是 v3.0.0 拍板的硬纪律。差异 ≠ 0 时不判失败，按序进下一步。
步骤 3 · 零金额红冲判定（CR-3，唯一「失败但出单」例外）
命中行全部为零金额行（
amount = 0 且 quantity < 0，金蝶红冲只冲数量）且账单净额 ≠ 0 → FAILURE +ZERO_AMOUNT_RETURN，差异全额出费用应收单。
混合行轧零（如一退一发互抵）不算，继续走 R2~R5。整单退款互抵且净额 = 0 的场景会落入 R1 成功——这与 v2.2 分向口径不同，2026-06 计划中 4 个样本单需财务确认（CR-10 标注 ⚠ 待确认）。它是 8 步里唯一的「失败但出单」例外——金蝶只冲数量没冲金额，但账单侧是真金白银的收入，必须出费用应收单让财务留痕。
步骤 4 · R2 部分结算（子集下推财务应收单）
账单净额 = 某一条供应链单行金额（严格相等；净额 = 0 不进本轮——零金额红冲行
amount=0会假命中）→ SUCCESS +PARTIAL_SETTLEMENT，返回matchedSupplyOrderIds子集，转换层按子集下推财务应收单。
覆盖场景：多款商品本期只结算其中一款、多款。注意：v3.0.0/v3.3.1 脚本把 R2 提到零金额红冲之后先于 R3 跑，避免被 R3 营销券误命中。
步骤 5 · R3 营销券差异（自营/立减各一张费用应收单）
差异 = 营销对账「联合按比例承担优惠劵-自营 / 立减」京东承担额（「-商家」已在收入中扣除，永不计入），容差 0.01。
R3 判定比看起来复杂——正向订单（无退款）：订单全量券合计 = 差异 → 命中；含退款订单（CR-5）：只勾稽商家实际承担金额——① 结算表「售后服务单·货款」负收入行定位退款 SKU → 退款 SKU 券合计 = 差异 → 命中；② 否则退款 SKU 券合计 − 某单一活动组 = 差异 → 命中（金蝶红冲已含该活动平台份额）；③ 结算表无售后货款行（流水扣收路径、无 SKU）→ 逐 SKU 试配；不按订单全量券兜底（0903 口径，废弃 v2.2.1 兜底行为）。
命中 → SUCCESS + MARKETING_COUPON_DIFF，差异额保留：主单下推 + 差异出费用应收单（自营/立减兼有分两张）。
步骤 6 · R4 差异诊断（5-a 直赔代扣 / 5-b 聚水潭补差价 / 5-c 小额打款退还）
R3 没命中，按序走 R4 的 3 个子分支（R4-b 是预留的膨胀金，账单类型未上线恒空）：
| # | 触发条件 | 输出 |
|---|---|---|
| 5-a（R4-a）直赔退款代扣 | 差异 = 账户流水「交易备注」含「直赔退款代扣」的金额合计 | FAILURE + DIRECT_COMPENSATION，不出单，人工处理 |
| 5-b（R4-c）聚水潭补差价 | 差异 = 聚水潭补差价商品行金额合计（行文本含「差价 / 补差」） | SUCCESS + PRICE_DIFF_ORDER，差异额保留，出费用应收单 |
| 5-c（R4-d）小额打款退还 | 差异 < 0 且 = 结算收明细「小额打款费用退还」金额合计 | SUCCESS + SMALL_PAYMENT，差异落 0 只留标签，不出单（费用侧已按 XEDKFYTH 出单） |
步骤 7 · R5 兜底（取消未发货·有供应链单 / 极速退款真差异 / AMOUNT_DIFF）
R4 都没命中，按序走 R5 的 3 个子分支：
| # | 名称 | 触发条件 | 输出 | 典型样本 |
|---|---|---|---|---|
| R5-① | 取消未发货·有供应链单形态（v3.2.0） | 同订单对账体行一正一负互抵（容差 0.01）且账单净额 = 0；聚水潭售后分类 ∈ {普通退货, 拒收退货} | SUCCESS + CANCELLED_UNSHIPPED（并入 R0-a 同标签），正/负体行同标签，差异落 0、只打标不出单 | 3545434018225983（红冲 −20）、3561492019513425（零金额红冲） |
| R5-② | 极速退款·真差异 | 聚水潭售后分类 ∈ {普通退货, 拒收退货}；账单净额 ≠ 0；v3.3.1 起增加红冲覆盖校验（红冲已足额覆盖钱包扣收则不命中） | FAILURE + INSTANT_REFUND（v3.2.0 起仅真差异命中），只打标不出单 | 3532450006116157、3534400005838258（差 −98.89 / −100.05 = 自营券份额，R3 命中翻 SUCCESS） |
| R5-③ | 兜底 | 以上均未命中 | FAILURE + AMOUNT_DIFF，不出单，人工核对 | — |
R5-① 是 v3.2.0 翻案最彻底的一步——4 体行由 FAILURE/INSTANT_REFUND 翻 SUCCESS/CANCELLED_UNSHIPPED，差异 +20/−46.90 全部落 0，剩余 596 体行结论逐行对比零变化 [来源：2026-09-07 v3.2.0 重跑实测]。实证：3545434018225983（红冲 −20）、3561492019513425（零金额红冲）。
贯穿 8 步的两个机制：承载行 + 防误判闸门
8 步判定流程不是独立的——有两个机制贯穿所有成功路径。
承载行（Carrier Row）机制：保证同一订单多体行只出一张物料明细、不翻倍差异
整单轧差后，同一订单可能有 2~6 条体行（正的销售 + 负的退款 + 售后单 + 直赔代扣等）。如果每条体行都出单，物料明细会翻倍、计划差异合计会翻倍——这就是分向对账时代的「一单多物料」问题。
承载行挑选规则（确定性算法，跨体行一致）：
净额 > 0 归 POSITIVE、< 0 归 NEGATIVE、= 0 或方向无匹配取 id 最小者 ——对账阶段承载行规则节
承载行裁决后的三种落库：
| 体行身份 | 承载行 | 非承载行（成功） | 非承载行（失败） |
|---|---|---|---|
reconcileResult | SUCCESS（带标签或不带） | SUCCESS + NET_MERGED | 同父体行结论的 FAILURE |
| 金额 | 净额 | 0 | 0 |
| 物料明细 | 完整生成 | 不写（skipMaterialItems=true） | 不写 |
| 出单 | 出单（按标签映射） | 不出单、不建物料 | 不出单 |
例外分支：R0-a / R0-b2 / R5-① 三个分支不经承载行裁决——互抵单净额为 0、无翻倍风险，正/负体行直返同一标签（不挂 NET_MERGED）。确定性保证：同一订单正/负体行各自独立执行必得同一承载行结论——每条体行独立跑脚本 → 必须返回同一结论 + 同一承载行 id，否则脚本有 bug。
防误判闸门：拦截「净额 0 + 无供应链单」的伪成功
旧版 v2.2.8 分向口径下，极速退款经常假对平——结算表确认全额收入、平台已走钱包扣收退款；扣收行在池内时收入被轧成退款后净额、恰好与供应链对上。脚本误以为 R1 成功，实际是漏判的 691.00 元差异 [来源：2026-09-09 收入池白名单整改说明，样本 3537424007903740]。
防误判闸门就是拦截这种伪成功：过滤后供应链一行都没有时，账单净额为 0 也不算成功，必须走 R0 链识别真实场景。但互抵单必须前置——R0-a 先于闸门执行：互抵单账单净额为 0，不前置识别会被闸门全部落 MISSING_SUPPLY。
实证样本：8 步骤如何在 600 行订单上稳定运行
下面用 2026-07 计划 cmtqn5ek60fh06hhdqyccm075 的 600 行实测，把 8 步骤和真实订单号绑在一起。
v3.2.0 重跑（R5-① 引入）：4 体行由失败翻成功
3545434018225983（红冲 −20）和 3561492019513425（零金额红冲）2 单由 FAILURE/INSTANT_REFUND 翻 SUCCESS/CANCELLED_UNSHIPPED。
其余 596 体行结论逐行对比零变化，matched 598 / unmatched 2。剩余 2 行 INSTANT_REFUND（3532450006116157、3534400005838258，负向单行净额 ≠ 0 真差异）正确保留失败——这正是 v3.2.0 的设计：互抵净额 0 → R5-① 改判成功，真差异 ≠ 0 → R5-② 保留失败。
v3.3.0 重跑（财务数量过滤引入）
| 订单号 | v3.2.0 结论 | v3.3.0 结论 | 触发步骤 |
|---|---|---|---|
| 3532450006116157 | FAILURE / INSTANT_REFUND | SUCCESS / MARKETING_COUPON_DIFF | 步骤 5 · R3（过滤已下推行后差异收窄为 −98.89 = 自营券） |
| 3534400005838258 | FAILURE / INSTANT_REFUND | SUCCESS / MARKETING_COUPON_DIFF | 步骤 5 · R3（同上，差异 −100.05） |
| 3534240005778185 | SUCCESS / PARTIAL_SETTLEMENT | SUCCESS（无标签） | 步骤 2 · R1（已下推行剔除后剩余行 R1 全额对平） |
| 3538419009238175 | SUCCESS / PARTIAL_SETTLEMENT | SUCCESS（无标签） | 步骤 2 · R1（同上） |
跨月退货单（6 月下单 7 月退款）往月正向暂估单已下推、本月红冲单未下推，不过滤两月单据轧零、差异放大为整单金额直落 R5-② 误判极速退款。过滤后差异收窄为自营券份额，R3 流水扣收路径逐 SKU 试配命中 [来源：2026-09-09 v3.3.0 全量模拟实测]。
v3.3.1 重跑：7 月计划 21 单极速退款纠偏
v3.3.1 新增「钱包扣收红冲对称剔除」前置过滤 + 极速退款打标前红冲覆盖校验——红冲已足额覆盖钱包扣收则 R5-② 不命中（脱出走 AMOUNT_DIFF）。21 单纠偏见脚本头注释。
从 v3.2.0 → v3.3.0 → v3.3.1，3 次重跑、3 次结论变化、每次只动 4~21 单——这就是整单轧差脚本的工程纪律：每一步新增的逻辑都能精确溯源到具体的样本订单号和差异金额，没有「顺带改了别处」的副作用。
13 个差异标签速查表（8 步骤涉及的）
下表是 8 步骤脚本涉及的 13 个 diffReason 机读码——是集成转换脚本读取的「唯一真源」。
| 步骤 | 标签 | 机读码 | reconcileResult | 出单 |
|---|---|---|---|---|
| 步骤 1 · 0-a / 步骤 7 · R5-① | 取消订单（未发货） | CANCELLED_UNSHIPPED | SUCCESS | 不出单（只打标，v1.5.0 起显式跳过主单） |
| 步骤 1 · 0-b | 补差价订单 | PRICE_DIFF_ORDER（R0-a 形态） | SUCCESS | 差异额出费用应收单 |
| 步骤 1 · 0-b2 | 仅退款 | REFUND_ONLY | SUCCESS | 不出单（只打标，v1.6.0 起显式跳过主单） |
| 步骤 1 · 0-c / 步骤 7 · R5-② | 极速退款 | INSTANT_REFUND | FAILURE | 不出单（出单口径待定论） |
| 步骤 1 · 0-d | 缺供应链订单 | MISSING_SUPPLY | FAILURE | 不出单，人工核对 |
| 步骤 2 · R1 | 主匹配（无标签） | — | SUCCESS | 财务应收单（暂估下推，承载行） |
| 步骤 3 · 零金额红冲 | 退货无金额差异 | ZERO_AMOUNT_RETURN | FAILURE | 出费用应收单（失败但出单） |
| 步骤 4 · R2 | 部分结算 | PARTIAL_SETTLEMENT | SUCCESS | 子集下推财务应收单 |
| 步骤 5 · R3 | 营销券差异 | MARKETING_COUPON_DIFF | SUCCESS | 主单 + 差异出费用应收单（自营/立减分两张） |
| 步骤 6 · 5-a | 直赔退款代扣 | DIRECT_COMPENSATION | FAILURE | 不出单，人工处理 |
| 步骤 6 · 5-b | 聚水潭补差价 | PRICE_DIFF_ORDER（R4-c 形态） | SUCCESS | 差异额出费用应收单 |
| 步骤 6 · 5-c | 小额打款退还 | SMALL_PAYMENT | SUCCESS | 不出单（费用侧已按 XEDKFYTH 出单） |
| 步骤 7 · R5-③ | 金额差异（兜底） | AMOUNT_DIFF | FAILURE | 不出单，人工核对 |
| 承载行机制 | 净额轧差并入 | NET_MERGED | SUCCESS（金额 0） | 不出单、不建物料 |
如果想系统化落地整套流程，可以考虑轻易云智能对账系统的「reconcile-script」沙箱：JS 沙箱承载 4 类脚本（parse/reconcile/allocate/transform），v3.3.1 这种带 R0~R5 复杂轮次 + 承载行裁决 + 防误判闸门的脚本可以做到试跑 30 秒、生成 v3.3.x → v3.3.y 迭代快照而不破坏生产数据。
京东 POP 收入对账计划的产品实测
下图是京东 POP 2026-07 收入对账计划详情：600 笔订单、收入 98,837.12 元、差异 0.00 元，列表展示业务订单号、对账结果、差异原因（如「联合优惠券/立减差异」）。
每一行 diffReason 都是 8 步脚本跑出来的机读码。点击体行进入二级详情，可看到承载行裁决后的物料明细（SKU 级）和处理建议。
上图是体行详情：业务订单号 3532421014848073、账期 2026-07、对账成功、差异原因「联合优惠券/立减差异」。处理建议：「差额金额与营销对账「联合按比例承担优惠券-自营/立减」金额一致（¥65.92），判对账成功并保留标签。处理：暂估应收下推生成财务应收单 + 按差异金额生成金蝶费用应收单。」——这就是 R3 营销券差异在承载行上的最终落库形态。
8 步骤的工程价值：判定纪律 + 双向兜底
8 步骤工程价值体现在 3 条原则：① 判定纪律：每步有前提、不满足不进该轮、命中即停；② 承载行机制：防止一单物料翻倍、差异合计翻倍；③ 防误判闸门：拦截「净额 0 + 无供应链单」的伪成功。
把这 3 条原则放在一起，整单轧差就成了一个可异步、可追溯、可重跑的对账引擎——轻易云智能对账系统「reconcile-script 沙箱」的核心设计哲学：脚本规则决定打标、出单规则决定金蝶单据、承载行机制决定物料明细，三者各司其职，互不越界。深入理解每个步骤的沙箱契约与回归测试方法，可参见「reconciliation-script-development」与「income-reconciliation-development」两份沙箱开发指南；新平台接入（速卖通、微信小店、独立站等）可参照「platform-script-onboarding」总 skill——它把京东 v3.3.1 的 8 步骨架提炼成了通用模板。
收尾：把 8 步骤变成可复用的对账能力
京东 POP 整单轧差的所有秘密，就这 8 步骤：前置过滤 → R0（5 子分支）→ R1 主匹配 → 零金额红冲 → R2 部分结算 → R3 营销券 → R4 差异诊断（3 子分支）→ R5 兜底（3 子分支）。真正难的不是记住它们，而是三件事：
- 判定纪律：每步有触发前提，命中即停——脚本稳定性的根。
- 承载行机制：同一订单多体行只出一张物料明细——整单轧差能取代分向对账的工程支点。
- 防误判闸门：拦截「净额 0 + 无供应链单」的伪成功——极速退款从漏判到显形的根因。
每一条规则都对应 1~3 个真实样本订单号（3545434018225983 红冲 −20 / 3561492019513425 零金额红冲 / 3532466005975710 互抵单 / 3532450006116157 跨月自营券 / 3525402000291770 换货剔除可废 / 3558441011808741 仅退款），每一条样本都对应 v3.0.0 → v3.3.1 的某个版本反转——这就是 8 步骤脚本可以稳定支撑 600 行订单、596 行零变化、4 行精确翻转的实证底气。
下一次再有人问「这一单为什么对不上」，把 diffReason 机读码拿出来，反查它在 8 步中的哪一步命中，然后看对应样本订单号的版本演进——答案永远在数据里。