Qeasy Cloud
Get Started

京东 POP 营销券差异:差额 = 平台券 + 立减金额(容差 0.01 元)

· 何海波· AI Financial Reconciliation· 136 views· 11 min read
京东营销券平台券立减容差MARKETING_COUPON_DIFF整单轧差R3 营销券SKU同步退款商品券份额CR-5

京东营销券 差异 立减 容差

摘要:京东 POP 营销对账差异判定(脚本 R3 轮次)的全部口径——"差额 = 营销对账表里京东承担的券金额 + 立减金额、容差 0.01 元、有退款的订单按退款商品的券份额算"。反向推,按订单全量券兜底是错的;SKU 级精确勾稽才是关键;主匹配严格相等 + 标签判定容差 0.01 的双层容差体系,是这一轮次能在 600 行订单里稳定识别自营券 / 立减份额不误判的全部原因。

关键词:京东营销券、平台券、立减、容差 0.01、MARKETING_COUPON_DIFF、整单轧差 R3、退款商品券份额、CR-5、SKU 级勾稽

6 单差异看起来像漏了,其实是被脚本主动"放过去"的

京东 POP 2026-07 收入对账计划(脚本 v3.3.1)跑完,600 体行里 diffReason 不是空的总共 17 行。其中 MARKETING_COUPON_DIFF 6 单——这一组单子看起来最像"漏对账":账单收入小于供应链金额、差额从 17 元到 100 多元不等,但脚本不报错、不出单、只挂一个标签。

业务经理的常规疑问是:这些单差异为什么是「京东承担的券」?为什么用 0.01 而不是 1 元的容差?退款的订单怎么"按券份额算"?手工算的金额和系统算的对不上,到底是数据错了还是计算方式不一样?

这是 v3.0.0 整单轧差之后京东 POP 第 5 步脚本「R3 营销券差异」的所有细节——一道纯业务逻辑题,跟平台代码没关系,跟数据来源倒很有关系。

京东 POP 优惠券核销与回退流程图:从买家下单时平台券 / 立减承担,到结算账单反向钩稽,最终通过脚本 R3 把京东承担金额打标成 MARKETING_COUPON_DIFF 差异

上图是优惠券在京东生命周期的完整链路。注意买入端只要写一行券面值("立减 30"),结算端却要把这笔钱拆成"京东承担的 30"还是"商家承担的 0"——拆错一根筋,下游对账全部被坑。

R3 在 8 步脚本里的位置:整单轧差之后的第 5 把钥匙

京东 POP 整单轧差脚本总共有 8 个判定轮次(R0~R5 加前置过滤),每一步有明确的执行前提,不满足就不进该轮。R3 处于「R2 部分结算」与「R4 差异诊断」之间——是当主匹配失败、且不是零金额红冲、也不是部分结算时,最后一道业务意义明确的自动识别。

整条判定链是这样的:

步骤名称触发后做的判定命中的标签
前置立账类型 + 财务数量 + 防误判闸门阻断"假对平"—
R0无供应链分支(5 子分支)互抵单 / 补差价 / 仅退款 / 退货类兜底CANCELLED_UNSHIPPED / PRICE_DIFF_ORDER / REFUND_ONLY / INSTANT_REFUND / MISSING_SUPPLY
R1主匹配netBill = netSupply 严格相等(无标签)
零金额红冲介于 R1 与 R2 之间命中行全部为零金额红冲ZERO_AMOUNT_RETURN
R2部分结算netBill = 某条供应链单行金额PARTIAL_SETTLEMENT
R3营销券差异差异 = 营销对账自营券 + 立减MARKETING_COUPON_DIFF
R4差异诊断(3 子层)直赔代扣 / 补差价 / 小额打款DIRECT_COMPENSATION / PRICE_DIFF_ORDER / SMALL_PAYMENT
R5兜底(3 子层)退货类真差异 / 兜底INSTANT_REFUND / AMOUNT_DIFF

R3 是 R1/R2/零金额红冲都不命中才进的兜底入口;要进 R3 必须满足两个前提:① 账单净额 ≠ 供应链净额(差额存在);② 账单净额 ≠ 任意一条供应链单行金额(不是部分结算);③ 差异方向有正有负都可能(正 = 账单高于供应链,京东承担在账单端少扣;负 = 账单低于供应链,多见于极速退款 + 钱包扣收组合)。

23 个 diffReason 业务标签码判定流程图:收入对账脚本的判定树骨架——R0 无供应链分支、R1 主匹配、R2 部分结算、R3 营销券差异(高亮位置)、R4 差异诊断、R5 兜底

R3 的位置就是上面这张判定树的「R3 营销券差异」节点。它和 R2 部分结算在排序上故意调换了一次:v2.2.8 版让 R3 跑在 R2 之前,导致一条供应链单行金额恰好等于订单全量券的订单会被误判成营销券差异错失部分结算——v3.0.0 拍板 R2 跑前 R3 跑后,逻辑闭环。

容差 0.01 元到底是哪里的余量:主匹配严格相等 ≠ 标签判定严格相等

R3 用容差 0.01 元,主匹配 R1/R2 是严格相等、零容差。两条规则的容差口径不同,是新手最常混淆的。

步骤判定对象容差工程原因
R1 主匹配账单净额 vs 供应链净额严格相等、零容差整单净额必须能对得上供应链;否则要么是数据错、要么是差异有业务解释,落到 R3~R5
R2 部分结算账单净额 vs 某条供应链单行金额严格相等、零容差同 R1
R3 营销券差异 vs 营销对账自营券 + 立减合计容差 0.01 元营销对账表的"自营 / 立减"金额是从结算周期反向计算得到的,跨多笔子券逐张拆分时可能产生 0.005 的舍入尾差

为什么要保留 0.01 容差?因为京东营销对账表的"自营 / 立减"金额是按子活动拆分汇总出来的,跨"京券 / 东券 / 店铺券 / 跨店满减 / 立减优惠"逐张结算时,每张子券算出的"京东承担额"会出现 ±0.005 量级的舍入差 [来源:v3.3.0 脚本交付说明文档(2026-09-09)。如果硬卡 0 容差,6 单营销券至少有 3 单会从 SUCCESS 退化为 FAILURE/AMOUNT_DIFF,留给人工白白增加工作量。

R3 容差 0.01 元是工程上的实用妥协,不是业务上的妥协——业务零容忍指的是"差额必须是营销券承担金额,不能是没来由的金额"。0.01 容差不影响这个判定前提。

正向订单:订单全量券合计 = 差异(最干净的命中形态)

R3 第一种命中形态:订单没有退款、所有优惠券一次性核销。整张订单算出来的"营销对账表自营券 + 立减"金额直接等于对账差异。

假设订单 3556410001234567:账单净额 798.00、供应链净额 814.50,差异 −16.50。同时段营销对账表里这张单的自营券 12.00 + 立减 4.50 = 16.50 → 命中 → 标签 MARKETING_COUPON_DIFF,差异额 16.50 元保留,下游出"自营券 12 + 立减 4.50"两张费用应收单 [来源:京东 POP 2026-08 批次验算]。

实务里正向订单占比不算最高(约 30%~40%),但形态最干净:差异能跟券金额逐张配对、财务核对无需做 SKU 拆解。

第二种形态不在 R3,而在 R0-b(结算收明细商品名含「邮费差 / 差价 / 补差」)——这是补差价链接单,与本篇无关。

含退款订单:SKU 级精确勾稽(CR-5 三条子路径)

R3 真正复杂、真正让脚本有"技术含量"的是含退款订单。一张订单退款了 3 个 SKU 中的 2 个,营销对账表只给你一个总券金额。这时候商家实际承担 = 总券 − 退款 SKU 的券份额,必须按 SKU 反算才能精确匹配。如果简单按"订单全量券 = 差异",会把已退款的券重复算一遍。

v3.0.0 起 CR-5 把含退款订单的 R3 判定拆成 3 条子路径,按序命中:

子路径 ① :结算表有「售后服务单·货款」负收入行 → 定位退款 SKU → SKU 券合计 = 差异命中。这种最直接:负收入行里带退款 SKU 编码,营销对账表对每张 SKU 有"商家承担 / 平台承担"分摊,扣回这些 SKU 的平台承担额,剩下的就是商家承担的差。

子路径 ② :退款 SKU 券合计 ≠ 差异 → 「券合计 − 某单一活动组」= 差异。常见:金蝶红冲已经包含了某活动(比如 pop 神券)的平台份额,红冲单要回滚这一份额。这种场景下,营销对账表的券金额看起来比实际商家承担多 1~2 元的活动组金额——R3 必须主动按活动组金额做减法 [来源:CR-5 京东 POP 营销券 SKU 级勾稽说明(2026-08-21)]。

子路径 ③ :结算表无售后货款行(流水扣收路径 / 无 SKU) → 逐 SKU 试配。最极端的形态:钱包扣收路径——结算表没出货款负收入,钱包从余额里扣掉,但金蝶没对应单据,营销对账表也没有 SKU 维度。脚本只能"逐 SKU 试配"——把订单原始 SKU 列表按子路径 ① 反算的逻辑逆推一遍,找到一个能让"券合计 − SKU 贡献"等于差异的 SKU 组合。

v3.3.0 重跑实测样本:订单 3532450006116157 / 3534400005838258——6 月下单、7 月退款,往月正向暂估单已下推财务应收,过滤已下推行后差异收窄为 −98.89 / −100.05 = 自营券份额,R3 流水扣收路径逐 SKU 试配命中,由 FAILURE/INSTANT_REFUND 翻 SUCCESS/MARKETING_COUPON_DIFF [来源:2026-09-09 v3.3.0 全量模拟实测]。

这条子路径在脚本里是 CR-5 之后单独写的分支——它和正向订单路径、前两条子路径都不同:试配是从"已知 SKU 集合"组合遍历找答案,不是直接勾稽。

反直觉警示:v2.2.1 的"按订单全量券兜底"为什么被废弃

R3 第一版(v2.2.1 之前)有一个反直觉的行为:正向订单找不到精确配对时,按订单全量券合计兜底——意思是"找不到精确 SKU,就按总券充数"。这种行为在数据干净的早期没问题,但碰到两种情况就会出大事:

情况一:订单全额退款。营销对账表仍会按原始订单算"自营 / 立减",但实际商家承担 = 0(已全额退,券回收给平台)。按订单全量券兜底会把这部分券全算成商家承担 → 差异 −50 元被误识别成营销券差异,但实际是全额退款的零差异。

情况二:跨月退款。券核销在订单月、退款在结算月、营销对账表附在结算月。三个时间维度叠加,"按订单全量券兜底"会把已退款的券份额算到最新一次对账周期的商家头上,导致跨月大额差异。

v3.0.0 拍板废弃这种兜底行为:"不按订单全量券兜底(0903 口径,废弃 v2.2.1 兜底行为)" [来源:京东 POP 整单轧差改造定稿(2026-09-05)]。脚本现在进 R3 但拿不到精确配对时,宁可落 AMOUNT_DIFF 走人工兜底,也不"按总券充数"。

实证样本:6 单 MARKETING_COUPON_DIFF 的真实勾稽

下面是 2026-07 计划 cmtqn5ek60fh06hhdqyccm075 的 600 行里 MARKETING_COUPON_DIFF 命中样本(脱敏),每个样本对应一条"业务意义明确的真实差异":

订单号类型差异(元)子路径业务含义
3540210000012345正向−16.50① 直接配对自营券 12 + 立减 4.50,按 SKU 反算命中
3540210000234567部分退款−28.40② 减活动组自营券 36.00 - pop 神券活动组 7.60 = 28.40
3542010000345678跨月退款−98.89③ 流水扣收路径逐 SKU 试配命中(v3.3.0 重跑后才识别)
3542010000456789跨月退款−100.05③ 流水扣收路径同上
3544010000567890换货+17.62① 直接配对整单轧差后差异 = 自营券(3525402000291770 历史样本)
3545010000678901部分退款−12.00② 减活动组京券 12 - 满减活动组 0 = 12.00

6 单 6 种形态——R3 的"识别能力"就在这里体现。换成 v2.2.x 的兜底逻辑,6 单至少有 3 单(跨月退款的 2 单 + 全额退款的 1 单)会被误算成 AMOUNT_DIFF 进人工队列。

下游出单:6 单全部走"主单下推 + 差异额出费用应收单"——自营券 / 立减兼有时分两张费用应收单(账套上自营券挂「平台营销补贴-京东承担」、立减挂「平台立减-京东承担」两个独立费用项)。这意味着同一张订单的对账结果可能产出 1 张财务应收单 + 2 张费用应收单,三张单据独立推金蝶。

轻易云智能对账系统收入对账计划详情页:京东 POP 2026-07 账期 600 体行,差异原因列展示了 MARKETING_COUPON_DIFF 等多种业务标签码

上图为系统收入对账计划详情页的实拍截图——"差异原因"一列里就能直接看到 MARKETING_COUPON_DIFF 标签,财务做月度复核时点开这一列就知道哪些单需要走主单 + 费用应收单的双下发流程。

收入对账体行详情实拍截图:物料明细展示 + 处理建议 + 当前 diffReason=MARKETING_COUPON_DIFF 时推荐出单路径是「主单 + 费用应收单两张」

体行详情页把这 6 单的物料明细和处理建议都串在一起——配合这页的"处理建议"字段,财务知道这一单要不要补出费用应收单、补几张。

13 标签码速查里 R3 的最终定位

完整的 v3.0.0 / v3.3.1 营销券定位要看 13 个 diffReason 的速查表。R3 落在 SUCCESS 那一边(命中不打失败),跟它"失败但出单"代表的 ZERO_AMOUNT_RETURN 不同。

23 个 diffReason 业务标签码体系图:成功类(PARTIAL_SETTLEMENT / MARKETING_COUPON_DIFF / PRICE_DIFF_ORDER / SMALL_PAYMENT / NET_MERGED / CANCELLED_UNSHIPPED / REFUND_ONLY)+ 失败类(ZERO_AMOUNT_RETURN / INSTANT_REFUND / DIRECT_COMPENSATION / INFLATION_FUND_DIFF / MISSING_SUPPLY / AMOUNT_DIFF / RECONCILE_FAILED)

R3 命中(MARKETING_COUPON_DIFF)的出单纪律:

项目取值
reconcileResultSUCCESS(不是 FAILURE)
差异额是否保留保留(不归零)
主单暂估应收单正常下推(v3.0.0 起 CANCELLED_UNSHIPPED / REFUND_ONLY / NET_MERGED 这三个标签才显式跳过主单,MARKETING_COUPON_DIFF 不在此列)
费用侧出费用应收单——自营 / 立减兼有时分两张;纯自营券或纯立减时出一张;金额等于差异额
集成转换脚本映射JDPOP_FEE_RECEIVABLE_DOCTYPE = "AR_receivable|YSD02_SYS",自营券挂 ZC.JDPOP.ZYYWSR.EXT、立减挂 ZC.JDPOP.JD.PlatformSubsidy 两个核算项目子节点

注意两条容易踩的规则:(1) 营销券差异常是"成功但出费用应收单"而不是"失败但出费用应收单"——ZERO_AMOUNT_RETURN 是失败但出单(差异全额出费用应收单),MARKETING_COUPON_DIFF 是成功且出单;(2) 主单不会因为有营销券差异就被跳过,只是额外加费用应收单。

写在最后

回过头看 R3 营销券差异这条规则:它既不是自动对平、也不是失败留底,而是一道"业务有解释、金额对得上"的中间态。脚本要做的两件事——①精确识别"这笔差额是京东承担的券还是商家承担的",②把金额分摊成"主单 + 费用应收单"两张金蝶单据——靠的全是 SKU 级的勾稽逻辑和 0.01 容差的工程妥协。

轻易云智能对账系统的京东 POP 收入对账脚本 v3.3.1,正是把这 3 个版本(v3.2.0 取消未发货、v3.3.0 财务数量过滤、v3.3.1 钱包扣收红冲对称剔除)的反复改进叠在 R3 一道轮次上——跨月退款的 −98.89 / −100.05 样本能从 v3.2.0 的 FAILURE/INSTANT_REFUND 自动翻成 v3.3.0 的 SUCCESS/MARKETING_COUPON_DIFF,就是 R3 子路径 ③ 流水扣收逐 SKU 试配这条新分支的具体落地。

每月初看那张「收入对账计划详情」时,差异原因那一列里看到 MARKETING_COUPON_DIFF 不要慌——它已经是被脚本精确识别的、由系统自动出单的"业务意义明确的真实差异",不是漏对账、不是数据错、也不是要返工的假对平。

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/reconciliation/4-1-4-jdpop-marketing-coupon-tolerance-0-01

Comments