抖店费用转换 v1.1.0 13 规则 流水级直查 应付带符号

摘要：抖店的资金账单把所有费用项塞进同一份 CSV——平台服务费、佣金、拦截费、提现、消费者赔付、月付贴息……一个店铺月结就有十几种费用类型，每种还要落到金蝶不同的单据。抖店费用转换脚本 v1.1.0（2026-09-03 用户定稿）用「流水级直查 + 13 条规则 + 应付带符号净额」回答这个问题——不经过对账聚合层，直接按「单据类型 × 核算项目」从账单行成单，扣款出正数、退还出红字冲减，单据合计与费用计划聚合净额对平。本文拆开这 13 条规则的分组、应付带符号净额的反直觉之处、v1.1.0 之后的版本演进，以及试跑批次与 Excel 验算锚点。

关键词：抖店费用转换、13 规则、流水级直查、应付带符号净额、费用应付单、费用应收单、销售收款单、提现

抖音月结，十几种费用挤在金蝶门外

抖店财务月底拿到的资金账单只有一份 CSV，但里面的费用项比京东 POP 还杂。平台服务费、佣金、招商服务费、站外推广费、上门取件运费、权益保险、拦截费、月付贴息、消费者赔付、小额打款、用户向商家打款、提现……一个中等规模的抖店店铺月结有十几种费用行，金额有的正有的负（扣款为负、退还为正）。

手工时代财务怎么入账？答案是按 Excel 透视列一行一行录。但抖店和京东不一样——抖店是「流水级直查」：直接拿解析落库的 BillRow，不走对账聚合层，因为提现和带单号的费用行根本不会进入费用聚合（聚合只收"未匹配订单"的费用行）。这意味着，如果照搬京东 POP 那套「对账聚合 → 转换」链路，抖店会漏掉一半费用项——提现整条漏、订单费用只录净额丢失明细。

v1.0.0 之前的做法是按业务订单号聚合再出单，结果 7 月某店铺佣金虚增了 2×退还额——一笔退还进账，本应出红字冲减分录，但 v1.0.0 用绝对值化口径把退还翻成了正数入账，相当于把同一笔钱算了两次收入、又减了一次退还。v1.1.0（2026-09-03 方案 B）的目标：把应付单改成「带符号净额」口径——同单号流水净额取负 × 规则 sign，扣款出正数、退还出红字冲减，单据合计与费用计划聚合净额对平。本文就把这 13 条规则逐一拆开。

13 条规则全景：三类单据、三种 sign

13 条规则按 docType 分三组，对应金蝶三类单据：费用应付单 AP_Payable、费用应收单 AR_receivable|YSD02_SYS、销售收款单 AR_RECEIVEBILL [来源：2026-09-08 抖店集成转换脚本 v1.1.0 口径定稿]：

费用应付单 AP_Payable（8 条，sign = +1，费用项目编码 6601.28）

8 项全是 sign = +1，按 v1.1.0 的应付口径「同单号流水净额取负 × sign」算出正数应付分录。这是 13 规则里金额最大的一组，占了费用侧合计的 93%（−78,157.96 / −83,923.78）。

费用应收单 YSD02_SYS（4 条，费用项目编码 6001.01）

3 项 sign = −1 出负数费用应收单（平台给的是赔付/贴息/小额定向款，财务上挂对抖音的应收）；用户向商家打款 sign = +1（2026-09-03 用户裁定，由负改正——商家收到的打款是真实进项，要入正）。这 4 项加起来只 −964.23，但 sign 方向相反是 B 级干货：项目符号按业务语义走，不强求一律正负。

销售收款单 AR_RECEIVEBILL（1 条，提现专用）

提现是抖店费用侧最特殊的一项：它不是费用，是资金从平台账户打到我方银行账户。走销售收款单 AR_RECEIVEBILL，单据头固定付款单位类型=客户、付款单位=店铺客户编码 22000004、结算方式=JSFS04_SYS、收款用途=SFKYT01_SYS；7 月两笔（07-01 + 07-16）按 v1.4.0（2026-09-10 用户定稿）每个分录一张单、业务日期=分录流水日期。

13 条规则总数与 v1.4.0 之后的「13+1」口径差异：脚本开发指南 §4.1 把提现单独列了一栏并说「13+1 条」，但真源 30-integration-transform.md §1.2 表里已经把提现算在 13 条内——这是开发指南与口径文档之间的历史表达差异，不是规则数本身的争议。本文以 13 条为准，与对账计划 ERP-DOUYIN-20260909-0001 的批次验算口径一致。

如果想走系统化这条路，可以考虑轻易云智能对账系统的集成转换能力——transform_rules 表承载「核算项目 → 单据 + docType + sign」的映射，13 条规则在沙箱脚本里按 docType 三桶分组，每组一个 hookGroups 结构，扣款/退还走带符号净额、应收侧走绝对值化、提现走收款单——一种费用类型加一条规则即可，不用动脚本类型。

上图是系统里的转换规则列表——164 条规则按来源类型分组，抖店这 13 条只是其中一组。同一套机制承载着京东 POP 17 条、亚马逊、拼多多、支付宝的多平台费用转换规则。所有规则共用 transform_rules 表，靠 sourceType × accountingItemId × amountKind × direction 四元键匹配——这意味着「加费用类型 = 加一条规则」，不用动脚本代码。

流水级直查：为什么跳过对账聚合

费用侧不像收入侧要走供应链匹配——费用出单只需要三样：核算项目、金额方向、业务单号。这三样在解析脚本落库时就已经定型。所以费用侧的正确姿势是直接查 DouyinAccountFlowBillRow：

query.douyinAccountFlowBillRow({
  where: {
    shopId: scope.shopId,
    parseStatus: "PARSED",
    accountingItemId: { in: ruleItemIds },   // 13 条规则命中的核算项目
    period: { gte: scope.periodFrom, lte: scope.periodTo },
  },
  orderBy: [{ transactionTime: "asc" }, { id: "asc" }],  // id 决胜防分页丢/重行
  limit: 2000, skip: skip,
});

两个关键设计：

第一：只查 13 条规则命中的核算项目，不查全集。accountingItemId: { in: ruleItemIds } 把费用侧的数据源锁死在 13 条规则对应核算项目上——其他无规则的核算项目（如解析兜底的 ZC.DOUDIAN.QT）不会被转换层读到，也不会静默丢单：它们会留在费用聚合池里，靠手工归「其他费用」。

第二：orderBy 加 id 决胜。抖店资金账单的 transactionTime 字段存在大量重值（同一天几百笔流水），按单字段排序 + skip 翻页，非确定性地丢行/重行——2026-09-03 实测丢了 1 行（38.41 元），原因是翻页边界上同时间戳的记录被重复读取。修复方案是排序键追加 id 决胜，与京东 POP 账户流水 2026-08-27 实施与验算记录里的翻页漏行修复是同一类经验。

v1.1.0 反直觉：应付改「带符号净额」，不是绝对值

13 条规则里最容易理解错的是 v1.1.0 的应付带符号净额口径。原 v1.0.0 的口径是「绝对值化」：体行金额 = |流水净额| × sign。这个口径在退还场景下会虚增费用——

举个例子：佣金账户 7 月有 1 笔扣款 −1,000 元 + 1 笔退还 +200 元。v1.0.0 绝对值化后，扣款行出 |−1,000| × +1 = 1,000 元正数分录，退还行出 |+200| × +1 = 200 元正数分录，两条都加进应付单，合计 1,200 元——但实际佣金净支出是 800 元。多出的 400 元是退还部分被算成了正数应付，等于把「平台退还给商家的钱」当作「商家欠平台的费用」入了账。手工 Excel 一对就对得上，但系统算错 400 元。

v1.1.0 的应付口径修正：

体行金额 = 同单号流水净额取负 × 规则 sign

扣款流水为负（−1,000），取负变 +1,000，再 × sign=+1 → 1,000 元正数分录； 退还流水为正（+200），取负变 −200，再 × sign=+1 → −200 元红字冲减分录。

两条同单号合并净额 = 1,000 − 200 = 800 元正数应付，与费用计划聚合净额对平。

如果某笔订单的退还 > 扣款（比如佣金账户退还 +300、扣款 −100），合并净额 = 100 元正数，对应付单出 100 元正数分录——退还没有变成新的「应付」，只是把扣款净额轧平了。这是带符号净额口径的核心反直觉之处：红字冲减不是单独的「退款处理」，而是同单号合并后的数学结果，财务上的「冲减」是账面表达，不是规则特殊处理。

应收侧维持 |流水净额| × sign 不动（2026-09-03 用户确认）：3 项 sign=−1 出负数单（平台赔付/贴息/小额）、用户向商家打款 sign=+1 出正数单。应收侧流水符号口径按项目不一致（正收入/负收入并存），绝对值化是既有验收口径，不动。

三类 docType 的字段口径

13 条规则出三类单据，单据头字段各有差异 [来源：2026-09-07 四大平台集成转换脚本逻辑说明-0904 客户确认版]：

应收/应付单通用取值（0904 客户确认版）：客户=shop.externalCode（缺维护回落到 22000004）、供应商=shop.reserved1（落到 91000004）、归属部门=shop.reserved8（落到 220102）、费用承担部门=shop.reserved5（落到 1201）、币别=shop.reserved9（落到 PRE001）、费用项目=shop.reserved10（落到 6001.01 应收 / 6601.28 应付）。缺失字段不阻断出单，仅在 unmatched 给 SHOP_MAPPING 提示。

应付单的供应商必传是反直觉之处：体行 supplierCode=91000004 必须放 head，不能放在体行——金蝶侧 FSUPPLIERID 校验在单据头层面，实测「客户编码当供应商传」会报「供应商值不存在」并 FAILED。这是 2026-08-28 ap-payable.push 落地时的实测坑。

收款单的付款单位也是 2026-09-10 才定的：原 v1.1.0 时是「付款单位类型=其他往来单位 + 付款单位=QTWL0980」固定值，v1.4.0 起改付款单位类型=客户 + 付款单位=店铺客户编码（externalCode，抖店示例 22000004）——这就是为什么文章标题说 v1.1.0、但收款单部分提 v1.4.0 的口径，v1.1.0 的核心是应付带符号净额，收款单拆分是后续优化。

实操验算：13 条规则 vs Excel 透视，0 元对平

2026 年 7 月火枫官方旗舰店真实批次 TFB-20260803-0001，13 条规则出的单据合计与手工 Excel 透视列对账 [来源：2026-08-31 抖店集成转换 v1.4.0 试跑批次验算]：

某电商集团用轻易云的转换批次模块跑抖店，从导入账单到 13 条规则出单 14 张、对账 0 元差异，全过程不到一天——其中大半时间花在口径确认（应付带符号净额方向、用户向商家打款符号反转），而不是写脚本。

但这个批次不是一次跑成的，中间抓出两个典型 bug：

踩坑 1：流水直查 orderBy 必须 id 决胜。2026-09-03 实测：抖店 7 月资金账单有 2,847 行流水，但 transactionTime 字段有 1,742 个重值（同一天几百笔流水），按单字段排序 + skip 翻页在分页边界上丢 1 行（38.41 元）——批次总额比费用计划聚合净额小 38.41。修复：orderBy 追加 id: "asc" 决胜（与京东 POP 账户流水 2026-08-27 实施与验算记录里的翻页漏行修复是同一类经验）。

踩坑 2：用户向商家打款 sign 反转没及时同步。2026-09-03 上午用户裁定 sign=+1（正数费用应收单），脚本里改了规则 sign，但 transform_rules seed 里旧的 sign=−1 规则没停用——同一个核算项目 SR.DOUYIN.YHXSJDK 同时存在两条规则（active/inactive 各一），脚本只取 isActive，导致 +131 元行被旧规则命中后输出 −131 元负数分录，与用户向商家打款的真实语义相反。修复：停用旧规则（isActive=false、isDefault=false）+ 新规则启用，并补 seed 文档说明 sign 方向。

v1.1.0 之后：13 条 → 13 条，金额口径一直在变

最后说一个反直觉的事实：13 条规则的核算项目数没变过，但应付/应收的金额口径在 v1.1.0 之后又迭代了 3 个版本：

这条演进链是真实的 B 级干货：13 条规则的总数是稳定的「锚」，但每条规则的金蝶出单金额口径一直在变——做实施时，拿到任何一份「差异录入规则」，第一件事不是开发，而是把规则的版本与口径基线摸清，再做合计验算。

13 条规则与 4 条补充说明

把视野再拉远一点，13 条规则背后还有 4 条补充说明，决定了抖店费用侧的边界：

1. 粒度 = 核算项目 × 账期一张单（应收/应付）；收款单例外 v1.4.0 起一个分录一张单。
2. 有业务单号按单号一条分录（同单号合并金额）；无单号合并一条。
3. 零额剔除：流水金额为零的行不进单（避免空单）。
4. 超 3000 行拆多张：单张单分录超过 3000 行时拆分，表头一致、体行分片、sortOrder 片内重排。

这 4 条说明定义了 13 条规则的物理形态——规则是「算什么」，说明是「怎么排」。理解清楚后，13 条规则的扩展（加费用类型 = 加一条规则）就不再是玄学。

如果想把 13 条规则 + 流水级直查的能力直接用上，可以看轻易云智能对账系统的集成转换模块——它把 transform_rules、IntegrationTransformScript、transform_batches 三张核心表 + 第四类沙箱脚本封装好，支持抖店、京东 POP、支付宝、拼多多、亚马逊五平台，每平台都能按「流水级直查 + 13/17 条规则 + 带符号净额」骨架跑，费用类型新增只需加一条规则、不动脚本。

总结：13 条规则的三个 takeaway

1. 流水级直查 + 规则驱动，是费用侧的天然形态。费用出单只需要核算项目/金额方向/业务单号——三样在解析时已定型。直查 DouyinAccountFlowBillRow，按 13 条规则命中核算项目过滤，跳过对账聚合层，自然不丢提现和带单号的费用行。13 条规则扩展时只改 transform_rules 表，脚本类型不变。

2. 应付带符号净额是 v1.1.0 的反直觉核心。扣款出正数、退还出红字冲减——「冲减」不是单独的退款处理，是同单号净额取负 × sign 的数学结果。退还 > 扣款时不会变成新的「应付」，而是把扣款净额轧平到正数。这个口径修了 v1.0.0 佣金虚增 2×退还额的实测 bug。

3. 13 条规则的总数是锚，金额口径一直在变。v1.1.0 之后又迭代了 3 个版本（v1.2/v1.3/v1.4），每版动的是单据粒度/付款单位/付款单位类型等口径，13 条核算项目的总数没变。做实施时，版本号与口径基线必须绑定记录——只报数字不报版本 = 误导。

最后用一张图把转换到推送的完整链路串起来——从对账确认 CONFIRMED 到金蝶 Submit/Audit：

中间那道人工确认闸门是金蝶审核的安全阀——费用应收单（YSD02_SYS）直接创建、金蝶侧没有幂等拦截，重复推送会生成重复单；只有人工确认过的批次才允许推送。

13 条规则的产物落库到 transform_documents × payload JSONB 的通用骨架——表头 8 字段（docType / head / status / aggregateId / platform / shopId / period / sourceRefs）、体行携带完整业务字段（orderNo / expenseItemCode / taxRate / remark / costDepartmentCode 等）。批次生成即快照，后续对账侧数据变化与脚本版本变更均不影响已生成的批次，需要刷新就删批次重新生成。这种快照语义是 v1.1.0 流水级直查的「数据安全网」——合并单一旦生成，即使后续规则升级，已推送的金蝶单据不会被反复重推。