抖店费用转换 v1.1.013 规则流水级直查的实操抖店费用转换v1.1.013 规则流水级直查应付带符号净额费用应付单费用应收单销售收款单提现金蝶云星空抖店费用转换 v1.1.0 13 规则 流水级直查 应付带符号摘要抖店的资金账单把所有费用项塞进同一份 CSV——平台服务费、佣金、拦截费、提现、消费者赔付、月付贴息……一个店铺月结就有十几种费用类型每种还要落到金蝶不同的单据。抖店费用转换脚本 v1.1.02026-09-03 用户定稿用「流水级直查 13 条规则 应付带符号净额」回答这个问题——不经过对账聚合层直接按「单据类型 × 核算项目」从账单行成单扣款出正数、退还出红字冲减单据合计与费用计划聚合净额对平。本文拆开这 13 条规则的分组、应付带符号净额的反直觉之处、v1.1.0 之后的版本演进以及试跑批次与 Excel 验算锚点。关键词抖店费用转换、13 规则、流水级直查、应付带符号净额、费用应付单、费用应收单、销售收款单、提现抖音月结十几种费用挤在金蝶门外抖店财务月底拿到的资金账单只有一份 CSV但里面的费用项比京东 POP 还杂。平台服务费、佣金、招商服务费、站外推广费、上门取件运费、权益保险、拦截费、月付贴息、消费者赔付、小额打款、用户向商家打款、提现……一个中等规模的抖店店铺月结有十几种费用行金额有的正有的负扣款为负、退还为正。手工时代财务怎么入账答案是按 Excel 透视列一行一行录。但抖店和京东不一样——抖店是「流水级直查」直接拿解析落库的BillRow不走对账聚合层因为提现和带单号的费用行根本不会进入费用聚合聚合只收未匹配订单的费用行。这意味着如果照搬京东 POP 那套「对账聚合 → 转换」链路抖店会漏掉一半费用项——提现整条漏、订单费用只录净额丢失明细。v1.0.0 之前的做法是按业务订单号聚合再出单结果 7 月某店铺佣金虚增了 2×退还额——一笔退还进账本应出红字冲减分录但 v1.0.0 用绝对值化口径把退还翻成了正数入账相当于把同一笔钱算了两次收入、又减了一次退还。v1.1.02026-09-03 方案 B的目标把应付单改成「带符号净额」口径——同单号流水净额取负 × 规则 sign扣款出正数、退还出红字冲减单据合计与费用计划聚合净额对平。本文就把这 13 条规则逐一拆开。13 条规则全景三类单据、三种 sign13 条规则按 docType 分三组对应金蝶三类单据费用应付单 AP_Payable、费用应收单 AR_receivable|YSD02_SYS、销售收款单 AR_RECEIVEBILL [来源2026-09-08 抖店集成转换脚本 v1.1.0 口径定稿]费用应付单 AP_Payable8 条sign 1费用项目编码 6601.28#核算项目名称7 月合计元1ZC.DOUDIAN.PDFWF平台服务费−5,876.422ZC.DOUDIAN.YJ佣金−50,151.233ZC.DOUDIAN.ZSFWF招商服务费−3,212.104ZC.DOUDIAN.ZWTKF站外推广费−12,847.655ZC.DOUDIAN.DZCJYF上门取件运费−843.276ZC.DOUDIAN.QYBX权益保险−1,560.887ZC.DOUYIN.LJF拦截费−3,278.918ZC.DOUDIAN.DYYFSJLHTXHD月付联合贴息费用划扣−387.50应付 8 项合计−78,157.968 项全是 sign 1按 v1.1.0 的应付口径「同单号流水净额取负 × sign」算出正数应付分录。这是 13 规则里金额最大的一组占了费用侧合计的 93%−78,157.96 / −83,923.78。费用应收单 YSD02_SYS4 条费用项目编码 6001.01#核算项目名称sign7 月合计元9SR.DOUYIN.DYYFLHTX抖音月付联合贴息−1−1,044.6710SR.DOUYIN.XIAOFEIZHEPEIFU消费者赔付−1−11.3211SR.DOUYIN.XIAOEDAKUAN小额打款−1−39.2412SR.DOUYIN.YHXSJDK用户向商家打款1131.00应收 4 项合计A–D−964.233 项 sign −1 出负数费用应收单平台给的是赔付/贴息/小额定向款财务上挂对抖音的应收用户向商家打款 sign 12026-09-03 用户裁定由负改正——商家收到的打款是真实进项要入正。这 4 项加起来只 −964.23但 sign 方向相反是 B 级干货项目符号按业务语义走不强求一律正负。销售收款单 AR_RECEIVEBILL1 条提现专用#核算项目名称出单口径13DOUYIN.TIXIAN提现v1.4.0 起一个分录一张单v1.1.0 时是按流水日期分桶提现是抖店费用侧最特殊的一项它不是费用是资金从平台账户打到我方银行账户。走销售收款单 AR_RECEIVEBILL单据头固定付款单位类型客户、付款单位店铺客户编码 22000004、结算方式JSFS04_SYS、收款用途SFKYT01_SYS7 月两笔07-01 07-16按 v1.4.02026-09-10 用户定稿每个分录一张单、业务日期分录流水日期。13 条规则总数与 v1.4.0 之后的「131」口径差异脚本开发指南 §4.1 把提现单独列了一栏并说「131 条」但真源 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四元键匹配——这意味着「加费用类型 加一条规则」不用动脚本代码。流水级直查为什么跳过对账聚合费用侧不像收入侧要走供应链匹配——费用出单只需要三样核算项目、金额方向、业务单号。这三样在解析脚本落库时就已经定型。所以费用侧的正确姿势是直接查DouyinAccountFlowBillRowquery.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再 × sign1 → 1,000 元正数分录 退还流水为正200取负变 −200再 × sign1 →−200 元红字冲减分录。两条同单号合并净额 1,000 − 200 800 元正数应付与费用计划聚合净额对平。如果某笔订单的退还 扣款比如佣金账户退还 300、扣款 −100合并净额 100 元正数对应付单出100 元正数分录——退还没有变成新的「应付」只是把扣款净额轧平了。这是带符号净额口径的核心反直觉之处红字冲减不是单独的「退款处理」而是同单号合并后的数学结果财务上的「冲减」是账面表达不是规则特殊处理。项目v1.0.0 绝对值化v1.1.0 带符号净额扣款 −1,000|−1,000| × 1 1,000正分录−(−1,000) × 1 1,000正分录退还 200|200| × 1 200正分录❌ 虚增−(200) × 1 −200红字冲减✓合计1,200多算 400800 真实净额应收侧维持 |流水净额| × sign 不动2026-09-03 用户确认3 项 sign−1 出负数单平台赔付/贴息/小额、用户向商家打款 sign1 出正数单。应收侧流水符号口径按项目不一致正收入/负收入并存绝对值化是既有验收口径不动。三类 docType 的字段口径13 条规则出三类单据单据头字段各有差异 [来源2026-09-07 四大平台集成转换脚本逻辑说明-0904 客户确认版]docType业务日期立账类型客户/往来供应商备注AP_Payable 费用应付单账期月末倒数第二天财务应付22000004客户映射91000004应付侧必传月份店铺核算项目名称AR_receivable|YSD02_SYS 费用应收单账期月末倒数第二天财务应收22000004—月份店铺核算项目名称AR_RECEIVEBILL 销售收款单分录流水日期v1.4.0—22000004付款单位—店铺月份账户提现应收/应付单通用取值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 提示。应付单的供应商必传是反直觉之处体行supplierCode91000004必须放 head不能放在体行——金蝶侧FSUPPLIERID校验在单据头层面实测「客户编码当供应商传」会报「供应商值不存在」并 FAILED。这是 2026-08-28ap-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-000113 条规则出的单据合计与手工 Excel 透视列对账 [来源2026-08-31 抖店集成转换 v1.4.0 试跑批次验算]单据类型张数系统金额元Excel 口径验算结论费用应付单8 项8−78,157.96平台服务费 5,876.42 佣金 50,151.23 招商 3,212.10 站外 12,847.65 上门取件 843.27 权益保险 1,560.88 拦截 3,278.91 月付贴息划扣 387.50✓ 一致费用应收单4 项4−964.23月付贴息 1,044.67 消费者赔付 11.32 小额打款 39.24 − 用户向商家打款 131✓ 一致销售收款单提现2195,000.007 月 2 笔提现 100,000 95,000✓ 一致合计14 张115,877.81应付 应收收款单正负相抵净额 668,606.94 收入 752,530.72 费用 −83,923.78✓ 一致某电商集团用轻易云的转换批次模块跑抖店从导入账单到 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 上午用户裁定 sign1正数费用应收单脚本里改了规则 sign但 transform_rules seed 里旧的 sign−1 规则没停用——同一个核算项目 SR.DOUYIN.YHXSJDK 同时存在两条规则active/inactive 各一脚本只取 isActive导致 131 元行被旧规则命中后输出 −131 元负数分录与用户向商家打款的真实语义相反。修复停用旧规则isActivefalse、isDefaultfalse 新规则启用并补 seed 文档说明 sign 方向。v1.1.0 之后13 条 → 13 条金额口径一直在变最后说一个反直觉的事实13 条规则的核算项目数没变过但应付/应收的金额口径在 v1.1.0 之后又迭代了 3 个版本版本关键变更影响v1.1.02026-09-03 方案B 用户定稿应付单改带符号净额扣款出正数、退还红字冲减修复佣金虚增 2×退还额流水 orderBy id 决胜v1.2.0收款单「类别编码×流水日期一张单」口径上线后续被 v1.3.0 取代v1.3.02026-09-08收款单改「一张单按流水日期各一条分录」后续被 v1.4.0 取代v1.4.02026-09-10 用户定稿已试跑 7 月验证收款单一个分录一张单 业务日期分录流水日期 flowDate付款单位类型客户、付款单位店铺客户编码 22000004原 QTWL0980 作废收款单张数显著增加存量批次需删除重生成v1.4.0 同期消费者赔付规则改绑SR.DOUYIN.XIAOFEIZHEPEIFU解析脚本 v3.3.10 起消费者赔付由费用正项改负收入与小额打款同口径旧 ZC 项规则入DOUYIN_STALE_RULE_CODES停用这条演进链是真实的 B 级干货13 条规则的总数是稳定的「锚」但每条规则的金蝶出单金额口径一直在变——做实施时拿到任何一份「差异录入规则」第一件事不是开发而是把规则的版本与口径基线摸清再做合计验算。13 条规则与 4 条补充说明把视野再拉远一点13 条规则背后还有 4 条补充说明决定了抖店费用侧的边界粒度 核算项目 × 账期一张单应收/应付收款单例外 v1.4.0 起一个分录一张单。有业务单号按单号一条分录同单号合并金额无单号合并一条。零额剔除流水金额为零的行不进单避免空单。超 3000 行拆多张单张单分录超过 3000 行时拆分表头一致、体行分片、sortOrder 片内重排。这 4 条说明定义了 13 条规则的物理形态——规则是「算什么」说明是「怎么排」。理解清楚后13 条规则的扩展加费用类型 加一条规则就不再是玄学。如果想把 13 条规则 流水级直查的能力直接用上可以看轻易云智能对账系统的集成转换模块——它把 transform_rules、IntegrationTransformScript、transform_batches 三张核心表 第四类沙箱脚本封装好支持抖店、京东 POP、支付宝、拼多多、亚马逊五平台每平台都能按「流水级直查 13/17 条规则 带符号净额」骨架跑费用类型新增只需加一条规则、不动脚本。总结13 条规则的三个 takeaway流水级直查 规则驱动是费用侧的天然形态。费用出单只需要核算项目/金额方向/业务单号——三样在解析时已定型。直查DouyinAccountFlowBillRow按 13 条规则命中核算项目过滤跳过对账聚合层自然不丢提现和带单号的费用行。13 条规则扩展时只改 transform_rules 表脚本类型不变。应付带符号净额是 v1.1.0 的反直觉核心。扣款出正数、退还出红字冲减——「冲减」不是单独的退款处理是同单号净额取负 × sign 的数学结果。退还 扣款时不会变成新的「应付」而是把扣款净额轧平到正数。这个口径修了 v1.0.0 佣金虚增 2×退还额的实测 bug。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 流水级直查的「数据安全网」——合并单一旦生成即使后续规则升级已推送的金蝶单据不会被反复重推。