京东 POP 收入转换：暂估应收 → 财务应收 Push 下推的实操
京东收入转换 暂估应收 财务应收 Push 下推
摘要：京东 POP 对账完成后，账单上的每一笔订单最终都要落到金蝶。但金蝶不是直接"Save 一张财务应收单"——本账套是暂估模式，财务应收单只能由暂估应收单通过 Push 下推生成。本文讲透这条最容易踩坑的链路：合并出单 v1.7.0 的口径翻转（G1 缺口消解）、推送字段完整性契约、Push 协议本身的硬约束、状态机回写，以及 2026-07 实测的 45 张单如何与手工 Excel 逐分录对平。
关键词：京东收入转换、暂估应收、财务应收、Push 下推、合并出单、v1.7.0、金蝶云星空
对账都"对平"了，下一步单据从哪来？
京东 POP 的财务每月做三件事：把京麦后台导出的结算资金表、账户流水、营销对账导入系统，跑收入对账脚本让 600 单的金额差异落到 0。屏幕上 100% SUCCESS，松了一口气——然后老板问："这些单什么时候进金蝶？"
答案是：账单数据要走一段"集成转换"才能进金蝶。集成转换不是简单的导表导出，它在系统里生成金蝶格式的转换单据（transform_documents），人工确认后再推送金蝶。这是第三类业务对象，前面还有两类：原始账单行（bill_rows）、对账计划明细（income_plan_items）。
收入侧转换生成的金蝶单据只有一种：财务应收单（立账类型 3 = 财务）。但这里藏着一个新接触的人最容易踩的坑——
财务应收单不能直接 Save 建单。
本账套是暂估模式。金蝶账套对"FSetAccountType='3'"的应收单有强制约束：直接 Save 一张财务应收单会被账套拒绝，报错信息是「立账类型财务应收单只能通过暂估应收下推」[来源：2026-08-24 真实账套验证记录]。翻译成大白话：金蝶规定财务应收单必须由暂估应收单通过 Push 协议生成，不允许凭空新建。
整条链路因此是这样的：
聚水潭/金蝶 PULL（暂估应收单，FSetAccountType='2'）→ SupplyOrder
收入对账：账单净额 vs SupplyOrder → reconcileResult=SUCCESS
收入转换 v1.7.0（合并出单：全月合并一张、超 3000 行拆分）
· INCOME_MAIN × direction → 财务应收单（暂估下推，含红字）
· INCOME_DIFF_LABEL × diffReason → 费用应收单（R6 差异标签）
ar-fin-receivable.push：Push 下推（RuleId=AP_HookRecToFinRec，多 FID 一次 Push）→ Submit → Audit
下面把这条链路的核心机制讲透。
反直觉：v1.7.0 全月合并一张单（G1 缺口消解）
2026-09-08 之前，京东收入转换是一张订单一张财务应收单（v1.6.0 及更早）。听起来很自然对吧？订单本来就是按订单收款的，按订单出单最直观。
但京东有个反直觉的场景——合并订单。一笔业务订单号下面，可能挂着 2~3 个子订单，每个子订单对应金蝶一张暂估应收单。问题是：合并订单在系统里的标识是"原始线上订单号" + 逗号拼接的字符串（"3561492019513425,3561492019513426"），金蝶那边没有任何一行的备注是这个字符串。
v1.6.0 的推送层走 head.orderNo 精确匹配暂估行：拼接串跟任何一行的 F_UJOP_Text1（业务订单号）都对不上 → 推送安全 FAILED「未找到匹配的暂估应收单」，但不推错误数据 [来源：京东 POP 合并订单 G1 缺口定位]。
这就是 G1 缺口的全貌：转换层按单号拆分出单没问题，但推送层做不到精确匹配。
v1.7.0（2026-09-08 定稿，2026-09-09 已实施·已落库）的修复思路不是"按原始单号精确匹配"，而是彻底换一条推送路径：
v1.6.0（按单号匹配，已废弃）：
head.orderNo → 拼接串 → 精确匹配暂估行 → 失败
↓
v1.7.0（按 payload 携带 FID，已落地）：
body 入参：
head.orderNo = '' // 不带
head.mergedOrderCount = N // 合并订单数
entries[i].payload.sourceErpDocId = <暂估单 FID>
entries[i].payload.sourceErpEntryId = <暂估单 FEntryID>
↓
handler 推送逻辑：
按 entry.payload.sourceErpDocId / sourceErpEntryId 逐行定位暂估行
多 FID 一次 Push → 多张财务单全部 Submit/Audit
具体来说，v1.7.0 把财务应收单由「一 IncomePlanItem = 一张单据」改为「全批次按 docType 合并成单」：
- 全部命中订单的 SKU 分录合并成一张（体行合并键 = 订单号-SKU 编码），超 3000 行拆成多张（同批次、表头一致）；
- 表头不带 orderNo，加
mergedOrderCount（合并订单数）；业务日期 = 账期月末；摘要 = 店铺+月份+合并下推（N 订单）； - 体行携带原始线上订单号 + 暂估单 FID（
sourceErpDocId）/ FEntryID（sourceErpEntryId）； - 正向收款为正、售后退款负向为红字体行，同单不做符号调整；
- 未匹配暂估行 / 无物料明细 / SKU 行缺供应链匹配的订单进
unmatched，不并入合并单（合并单金额 = 实际可下推金额）； - 推送走 handler 的 entry payload 路径（多 FID 一次 Push → 多张财务单全部 Submit/Audit，抖音在用同口径），不再依赖 head.orderNo 精确匹配——合并订单直接按体行 ID 下推，G1 缺口消解 [来源：京东 POP v1.7.0 实施与落库记录 2026-09-09]。
上图是集成转换的完整流程。注意中间那道人工确认闸门——批次从 DRAFT 推到 CONFIRMED 才能推送金蝶。PUSHED 重推需用户确认 ERP 重复风险；FAILED 可 reset 回 DRAFT 重新推送。
把"合并出单 + entry payload 携带暂估 FID + unmatched 不并入"这套机制做成可复用基座，是集成转换引擎的核心价值——轻易云智能对账系统正是这样处理的，规则变更改 transform_rules 表即可，零代码。
字段完整性契约：少一个键就 FAILED
推送 handler（ar-fin-receivable.push）有一个铁律：不回查业务主数据——转化脚本必须把推送所需的全部业务键携带进 head/payload；handler 缺键即 FAILED 并写明缺哪个键，不猜、不兜底出错误单据。
收入侧（→ ar-fin-receivable.push，暂估应收 Push 下推财务应收）的必带字段：
| 字段 | 取值 | 必带原因 |
|---|---|---|
head.orderNo | = businessOrderNo | handler 兜底用它匹配 supply_orders.businessOrderNo 找暂估单（取 sourceErpDocId 作 Push Ids）；v1.7.0 起表头不带，但 handler 内部仍校验存在 |
entry.payload.sourceErpDocId | = 暂估单 FID | 主推送键（v1.7.0 起优先） |
entry.payload.sourceErpEntryId | = 暂估单 FEntryID | 主推送键（v1.7.0 起优先） |
entry.payload.supplyOrderId | = 暂估单分录 FEntryID | 辅助校验/审计，不阻断 |
docType | AR_receivable|YSD01_SYS|FIN_FROM_HOOK | 三段式：formId|billTypeId|scenario——收入正负向同走下推（红字暂估单 → 红字财务应收单），不要把负向映射到 AR_RECEIVEBILL（收款单语义不符，历史占位误配已停用） |
为什么不能少 sourceErpDocId？2026-08-29 真实账套验证时踩过的坑：之前用 head.orderNo 精确匹配，碰到"详情有 ID、列表查不到"的就 FAILED。优化方案是优先 entry.payload.sourceErpDocId / sourceErpEntryId，回退 head.orderNo——双路径冗余 [来源：京东 POP 推送优化实施记录 2026-08-29]。
上图是集成转换的通用骨架。head 和 payload 内部结构系统不解释，目标系统差异全部收敛进脚本输出——这是为什么京东 POP 用一份脚本就能区分暂估下推、差异标签、补差价、极速退款等多种单据类型：所有差异都在 head/payload JSONB 里体现，金蝶侧根据 docType 三段式路由。
Push 协议：4 个关键参数，缺一不可
金蝶云星空的 Push 协议是金蝶原生的下推接口，body 格式曾经有多个版本（Save+Link、自定义格式），但 2026-08-29 切换为金蝶 UI 原生下推格式后，端到端实测稳定通过 [来源：金蝶云星空推送设计定稿 2026-08-29]。
// Push body（{ formid: "AR_receivable", data: {...} }）
{
"Ids": "<暂估单FID>", // 上游暂估单 FID；多张逗号分隔 = 合并下推
"Numbers": [],
"EntryIds": "<暂估单分录FEntryID>", // 可选但建议传；多张逗号分隔
"RuleId": "AP_HookRecToFinRec", // 暂估→财务转换规则（实测值）
"TargetBillTypeId": "", "TargetOrgId": 0,
"TargetFormId": "", // 显式 RuleId + IsEnableDefaultRule=false 时置空
"IsEnableDefaultRule": "false", // false=用显式 RuleId；true 时 TargetFormId 必填
"IsDraftWhenSaveFail": "false",
"CustomParams": {}
}
四条铁律：
RuleId = AP_HookRecToFinRec是金蝶账套里的暂估→财务转换规则标识，实测值，2026-08-29 定稿；不是随便写一个字符串——金蝶会按这个 RuleId 找下推规则，规则找不到直接 FAILED。IsEnableDefaultRule = "false"显式用 RuleId，避免金蝶默认规则把目标单据搞乱（默认规则有时会把应收单推到错误的目标单据类型）。IsDraftWhenSaveFail = "false"失败时不留草稿——失败就 FAILED 整体回滚，避免金蝶里留半成品。
响应单号位置与 Save 不同：
Result.ResponseStatus.SuccessEntitys[0].{Id, Number, EntryIds.FEntityDetail[]}→ 新生成的财务应收单 FID + 单号 + 分录 IDResult.ConvertResponseStatus.SuccessEntitys[0]→ 上游暂估单的回显
Push 产物 = 暂存态（A），需继续 Submit → Audit。Push 自动生成 FEntityDetail_Link 并反写上游钩稽金额；Delete 财务单钩稽自动回滚（实测）[来源：金蝶云星空推送定稿 2026-08-29 实测章节]。
幂等性：已全额下推的暂估单再 Push 被拒（可下推数量为 0）。这是天然幂等——金蝶侧拒绝就拒绝，不像费用应收单那样无幂等拦截。
状态机回写：转换批次走完的 4 个状态
转换批次 transform_batches 的状态机是一条线性的流水线，每一步都有明确的回写动作：
DRAFT 草稿 → CONFIRMED 已确认 → PUSHING 推送中 → PUSHED 已推送 / FAILED 推送失败
↑________FAILED 可人工退回 DRAFT 重来________|
- 只有 CONFIRMED 状态可推送——这是人工闸门。CONFIRMED 仅人工触发，意味着用户在界面上看过转换单据明细、确认无误才放行；
- PUSHED 重推需用户确认 ERP 重复风险——已推送不意味着"不能再推"，而是"再推前必须人工确认金蝶侧没有重复单"；
- FAILED 可 reset 回 DRAFT 重新推送——失败不丢弃，可以查日志改完参数重试。
状态机回写靠 integration_push_logs 表，每条 PUSH 调用一行日志，responseSummary 保留金蝶原始响应（不截断）。2026-08-28 收款单实踩过一个真实案例：externalBillNo 带 SIM- 前缀 = handler configJson.simulate=true 的模拟产物，金蝶侧根本没调用 [来源：金蝶云星空推送常见陷阱 2026-08-28 实测]。日志里 success=true、externalBillNo 已回填，但金蝶那边完全没有数据。遇到这种"看起来成功了但金蝶没数据"的情况，必须查 simulate 是否被误开。
R6 差异标签分流：合并出单之外的另一条链路
v1.7.0 的合并出单是 R1 规则（财务应收单主单），但收入侧还有一条 R6 规则——差异标签分流。它对应金蝶的费用应收单 AR_receivable|YSD02_SYS，docType 与 R1 共享 formId 但走 Save 而非 Push（费用应收单是可直接 Save 的）。
R6 出单门：diffReason 非空 且 差异额 ≠ 0。
需要出费用应收单的差异标签：
| diffReason 业务标签码 | 出单 |
|---|---|
MARKETING_COUPON_DIFF（营销券差异） | 费用应收单（按自营/立减分组出两张，v1.2 业务定稿） |
DIRECT_COMPENSATION（直赔代扣） | 费用应收单 |
PRICE_DIFF_ORDER（补差价） | 费用应收单 |
ZERO_AMOUNT_RETURN（退货无金额） | 费用应收单（CR-3：判 FAILURE 也出单，首个例外） |
R6 与 R1 都不消费（SKIP_MAIN_DOC_REASONS 显式跳过主单）的标签：
NET_MERGED（非承载行）：金额 0 + 无物料明细，不出单不出分录——承载行机制防一单重复出单；CANCELLED_UNSHIPPED（取消订单（未发货））：差异落 0，只打标（v1.5.0 起显式跳过）；REFUND_ONLY（仅退款）：v1.10.0 起按赠品物料 1102001235（蓝色小熊湿巾10片抽）判断——命中出正数「费用应收单-仅退款收入」、未命中只打标进 unmatched [来源：2026-09-10 仅退款终版处理 32b 财务拍板]；- 待接入标签（配件收入）：数据源接入前只打标不出单。
6 月实测：营销券差异 380 单、355.14 元就是由 R6 链路出费用应收单 [来源：京东 POP 2026-06 收入对账日志]。
这种 R1 主单 + R6 差异双链路的设计，让"对账成功 + 有差异"这种看似矛盾的标签能落地：账单净额匹配供应链（SUCCESS），但平台券/补差价的差额由 R6 单独出单消化。
实操验算：2026-07 一批 45 张单如何与手工对平
如果走系统化这条路，规则由 transform_rules 表承载、转换脚本按上面的粒度成批生成、批次生成即验算、unmatched 不静默——把反复合并出单的工程细节固化为系统默认动作。
规则落成脚本后，用 2026-07 真实数据跑了批次 TFB-20260909-0021 [来源：2026-09-09 收入 v1.7.0 合并出单首跑记录]，45 张单全部 DRAFT：
| 单据类型 | 张数 | 金额（元） | 与手工 Excel 验算 |
|---|---|---|---|
| 合并财务应收单 | 1 | 103,792.07 | mergedOrderCount=531，体行 100% 带订单号 + 暂估 FID/FEntryID |
| 营销券费用应收（自营） | 18 | 略 | 营销券按自营/立减分组出两张 |
| 营销券费用应收（立减） | 16 | 略 | 同上 |
| 补差价费用应收 | 8 | 339.00 | R6：补差价单按差异金额出单 |
| 极速退款费用应收（红字） | 2 | −1,047.02 | R6：极速退款负向行出负数费用应收单 |
| 合计 | 45 | — | 与手工 98,837.12 计划总额逐项归属，无 unmatched |
配平不变式：财务应收合并单 + 费用应收单 + 平台不入账差异 = 账单净额（98,837.12 = 103,792.07 + 营销券 719.30 + 补差价 339.00 − 极速退款 1,047.02 + REFUND_ONLY 3,705.00 + NET_MERGED −8,142.99 + INSTANT_REFUND −1,047.02 + PRICE_DIFF 339.00）。营销券与主单两侧无恒等关系（营销券按券面金额出单、主单按对账差异剥离，这是 v1.6.0 起既有设计）。
上图是全局转换单据列表。每一张单都能反向追溯：单据 → 转换批次 → 对账计划明细 → 原始账单行，批次号格式 TFB-YYYYMMDD-NNNN，逐条可回放。
上图是系统里的转换规则列表。收入转换不是"硬编码脚本"，而是 transform_rules 表驱动的：每条规则对应一个「核算项目 × 金额类别 × 方向 → docType」的映射，新增出单逻辑只需加规则，零代码。
如果想走系统化这条路，可以考虑集成转换能力：转换脚本按规则生成合并单据、unmatched 不静默、字段缺失直接 FAILED 而不是金蝶里留半成品。
关键陷阱：金蝶侧已完成时怎么办
把这种"按 orderNo 反查已审核财务单做终态确认"的兜底机制内置在推送 handler 里，是轻易云智能对账系统的工程做法——不做硬推失败 N 次，而是一次反查认领。
最后说一个实操里最容易踩到的场景：金蝶账套里暂估单已经被手工下推过。
2026-06 火枫店首批实测收入单全部被拒「应收单已经下推完毕」——这意味着财务在金蝶侧已经手工完成了暂估 → 财务应收的下推，系统再推一遍就失败了 [来源：2026-08-27 京东 POP 实施记录]。
正确做法不是硬推失败 4227 次然后全 FAILED，而是按 orderNo 反查已审核的财务单做终态确认；已审核（C）直接认领回填 externalBillNo；暂存态（A）草稿补 Submit/Audit 后认领 [来源：金蝶云星空推送常见陷阱 2026-08-29 实测]。
这个场景的反直觉之处在于：Push FAILED 不一定是配置错——金蝶侧的状态本身就在变（手工下推、跨期补单、删除重建），推送逻辑必须每次都按实时状态走，不能假设"暂估单就是没被推过"。
上图是集成中心 9 个 handler 全景。每一类单据走不同推送路径：财务应收单必须 Push 下推（暂估模式账套直接建单会被金蝶拒绝），费用应收/应付/收款单走 Save → Submit → Audit。
上图是集成中心的整体架构。三个引擎协同：PULL 引擎从金蝶拉暂估应收单，集成转换引擎按 docType 路由生成转换单据，PUSH 引擎按 handler 注册表调金蝶 API——三者通过 transform_documents 这张骨架表解耦，"换目标系统"等于换脚本 + 换 handler，零代码。
收尾：把收入转换变成可执行的资产
回到开篇的问题。京东 POP 收入转换的全部秘密，是这样一条链路：
暂估应收单（PULL 拉取）
→ 收入对账（整单轧差，账单净额 vs 供应链净额）
→ 集成转换 v1.7.0（合并出单 + R6 差异标签分流）
→ 字段完整性契约（head.orderNo + entry.payload.sourceErpDocId/sourceErpEntryId）
→ Push 下推（RuleId=AP_HookRecToFinRec，多 FID 一次 Push）
→ Submit → Audit
→ 状态机回写（DRAFT → PUSHING → PUSHED/FAILED）
真正难的不是记住每一步，而是四件事：
- 合并出单 v1.7.0——一订单一张改全月合并一张、超 3000 行拆分、表头带 mergedOrderCount 不带 orderNo；G1 缺口靠 entry.payload 携带暂估 FID/FEntryID 消解。
- 字段完整性契约——head.orderNo + entry.payload.sourceErpDocId/sourceErpEntryId 双路径冗余；少一个键直接 FAILED 不兜底。
- Push 协议四件套——RuleId=AP_HookRecToFinRec、IsEnableDefaultRule=false、IsDraftWhenSaveFail=false、多 FID 一次 Push；产物暂存态，需 Submit→Audit。
- 状态机闸门——CONFIRMED 才能推送、PUSHED 重推需用户确认、FAILED 可 reset 重来；simulate 误开 = 推送"成功"金蝶没数据。
如果走集成转换这条路，把这四件事做成默认动作——批次生成即验算、unmatched 不静默、字段缺失直接 FAILED、状态机每步可回查。规则从 Excel 搬进系统的那一刻，京东收入转换才从"某个财务脑子里的经验"变成"全公司可复用的资产"。