Latest industry insights, tutorials, best practices and case studies.
279 articles
This guide systematically covers the Kingdee Cloud ExecuteBillQuery interface for BD_SETTLETYPE settlement types, including field mapping, incremental sync strategy, and platform configuration. It distills cross-project field-handling experience for Kingdee–DingTalk integration scenarios.
双 11、618、年货节、38 节……每一次大促，财务团队都要面对一次「对账洪峰」——平时 5 天处理完的账单量，大促后 48 小时内必须清完，否则赶不上月结。多数企业靠「加人 + 加班」硬扛，但 2026 年覆盖 50 家中型电商财务团队的调研显示：**63% 的财务团队在大促后第 2 周仍有未清完的跨期账单，42% 的 CFO 因「账期不准」被 CEO 反复追问，29% 的财务人员在大促后第一个月离职**。本文给出经过 6 家年 GMV 5 亿以上电商验证的「大促对账黄金 72 小时」节奏表，配套 AI 时代 4 大应对策略（异步任务削峰、AI 沙箱自动扩、23 业务标签码分流、AI 智能体自助诊断），让财务团队从「加人加班」升级为「让 AI 替代财务加班」。
做电商对账,最难的不是某一平台怎么对,而是**怎么让 5 个平台同时跑稳**——京东 POP 用整单轧差、抖店用五轮匹配、亚马逊得分向不轧差、支付宝三表要对、速卖通 5 个 billType 各有差异。这篇文章把 2026 年 9 月 5 大平台全部稳定运行后沉淀的 5 条工程纪律拆开:**平台聚合范式(不抽象基类)+ 平台隔离 BullMQ 队列 + 平台默认脚本+店铺级覆盖 + 23 个 diffReason 跨平台统一 + CAT/SR/ZC 核算项目命名规范**。每条配一段真实事故或压测数据,业务人员与财务经理照搬即可跨过最常见的 5 类陷阱。
一家年 GMV 9.6 亿的多平台电商，2026 年 6 月月结时 CFO 想回答 3 个问题——这个月到底卖了多少、净利多少、库存还能撑多久。财务经理翻了 4 套系统凑出 3 张表，**会议开了 3 小时，问题没答完**——不是没数据，是数据没聚合成「CFO 视角的 5 个数字」。本文围绕 CFO 财务驾驶舱的 **5 大核心指标**：销售额、毛利率、净利率、库存周转、回款周期——给出每个指标的**计算公式 + 5 个同环比口径 + 实时监控阈值 + 异常告警分级**，并回答「5 个指标背后的数据怎么从 T+10 压到 T+1 自动喂数」。文末附「CFO 驾驶舱 12 条硬指标自检清单」，可直接拿去做系统验收。
This tutorial aggregates hands-on experience from multiple real customer projects on integrating Jushuitan with Kingdee Cloud Cosmic for supply chain scenarios. It covers 25 integration strategies, key document field mappings, incremental sync mechanisms, code mapping, exception handling, and scheduling strategies, enabling engineers to master all key interface points of this integration scenario in one read.
This tutorial aggregates multi-customer实战经验 to systematically dissect the YonBIP Sales Order query API (/yonbip/sd/voucherorder/list), covering field meanings, request/response structure, pagination, and pitfalls. It addresses detail-line primary keys, status enums, incremental sync, and org/customer/product mapping for CRM-ERP order integration.
This tutorial systematically organizes the field definitions, incremental and pagination mechanisms of the Jushuitan /open/supplier/query API, as well as the mapping essentials with Kingdee Cloud Skylight supplier master data. Based on practical experience from multiple customer projects, it distills common pitfalls and platform configuration methods, providing an authoritative reference for supplier master data synchronization in supply chain integration.
业务人员反复在同一个地方犯嘀咕——"我只改了分摊脚本，run-allocate 一下怎么就把订单明细清掉一列又重写？"这不是 bug，是双模式的代价。「公摊」用 **实时**（E1：先撤旧再累写），「订单费用下沉」用 **覆盖式**（E11：先清零再 set 写）。本文不抽象，给业务人员和财务经理一份 4 维度对比 + 3 步选择法，把"我什么时候该期望哪种行为"讲明白。
当一份对账差异表里有 14 行 FAILURE，传统的呈现方式是「自由文本 + 数字」。审计师拿到这张表的第一反应是「我需要把每一行的差异原因重新归类」——这一步往往占去 60-70% 的现场工时。23 个业务标签码（diffReason + diffDisposalSuggestion 双字段）做的就是把这一步从「现场归类」前移到「系统标注」：每条差异在落到数据库那一刻就带上了「机读码」与「中文处理建议」两个标签，审计师拿到的是一张可机读、可分组、可穿透到凭证的差异地图，而不是一锅自由文本。
电商财务对账做到 80% 后撞上的那堵墙，根源不在引擎、不在 ERP，而在「差异原因」字段是不是结构化。本文拆解 v3 对账体系里最容易被忽视、却承担 80% 自动化收益的工程支点——「机读码 + 人读建议」双轨设计：23 个 `diffReason` 给机器消费、决定下游集成脚本按码精准出单；`diffDisposalSuggestion` 给人阅读、保留财务手补痕迹不被自动重跑清空。这对字段采用**不对称落库语义**，正是把对账从「工程实现」升级为「业务规范」的关键设计。
亚马逊日本站对账不是「美站对账 + JPY」的减法题，本质是 **3 条主线 × 5 项差异**的工程化串联——JPY 单币种（日元是亚马逊五平台中**唯一无小数单位**的货币，金额直接按整数落库）+ 消费税 10%（含 7.8% 国税 + 2.2% 地方税；区分标准税率 10% 与轻减税率 8%，国内销售 vs 输出免税）+ 适格请求书制度 JCT（2023-10-01 实施，区分 適格請求書発効事業者 vs 免税事業者，影响 B2B 业务的仕入税額抵扣链）+ Amazon JP 作为代理人代征消费税（与美站 Marketplace Facilitator 同源但口径不同）+ 日元整数对账与跨境汇率的「2 套账本」。本文用 5 张图拆解亚马逊日本站对账的工程框架，并给出与亚马逊美站、欧洲站的 6 项关键差异——为日站卖家和跨境业务核算专员提供一份"3 条主线 × 5 项差异"的操作地图。
亚马逊欧洲站对账不是「美站对账 + 欧元 + 欧洲 VAT」的加法题，本质是 **3 重复杂度 × 4 类 VAT 流程 × 多国汇率 × 2 套物流方案**的工程化串联——VAT 多国（DE 19% / FR 20% / IT 22% / ES 21% / UK 20% 五国税率 × 进口 VAT / 销售 VAT / IOSS / OSS 四类流程）+ 泛欧计划 PAN-EU（一个 VAT 号发往全欧 29 国，但要在目的国分别申报）+ 欧洲配送网络 EFN（库存跨境调拨，FBA 仓间调拨产生库存调拨单和跨境物流费）+ 各国汇率差异（EUR / GBP / PLN / CZK / SEK 等 7 国本币折算的 3 套口径）。本文用 5 张图拆解亚马逊欧洲站对账的工程框架，并给出与亚马逊美站、京东 POP / 抖店的 6 项关键差异——为欧洲站卖家和跨境业务核算专员提供一份"3 重复杂度 × 4 类 VAT × 2 套物流方案"的操作地图。
This tutorial systematically consolidates the practical points of querying the Operator master data (BD_OPERATOR) via the Kingdee Cloud executeBillQuery WebAPI. Drawing on multiple real integration projects, it covers field definitions, incremental filters, pagination strategies, and cross-system mapping experience, enabling engineers to master the full integration in one read.
This tutorial centers on P2-342 (Query Kingdee Other Outbound Order, row-by-row), aggregating hands-on experience from multiple supply chain integration projects. It covers executeBillQuery field mappings, request parameters, pagination and incremental patterns, Qeasy platform packaging, and common pitfalls, giving engineers a one-stop reference for cross-system outbound order integration.
库存级核算是电商精细化财务核算的"最后一公里"——前 4 个维度（店铺级 / SKU 级 / 毛利级 / 税务级）算的是"账面赚了多少钱"，库存级算的是"账面利润被库存吃掉了多少"。一家年 GMV 5 亿的电商公司，看似 18% 的净利率，扣除「在库滞销 + FBA 长期仓储 + 退货在途 + 缺货损失」4 类隐性库存成本后，真实净利可能只有 6.8%——11.2 个百分点的差额就是库存黑洞。本文给出 CFO 必须看清的 4 类库存成本、多仓核算口径、库存周转"虚假拉长"的 3 大陷阱，以及 FBA 仓 + 国内仓的多仓合并视图。
抖店的资金账单把所有费用项塞进同一份 CSV——平台服务费、佣金、拦截费、提现、消费者赔付、月付贴息……一个店铺月结就有十几种费用类型，每种还要落到金蝶不同的单据。抖店费用转换脚本 v1.1.0（2026-09-03 用户定稿）用「**流水级直查 + 13 条规则 + 应付带符号净额**」回答这个问题——不经过对账聚合层，直接按「单据类型 × 核算项目」从账单行成单，扣款出正数、退还出红字冲减，单据合计与费用计划聚合净额对平。本文拆开这 13 条规则的分组、应付带符号净额的反直觉之处、v1.1.0 之后的版本演进，以及试跑批次与 Excel 验算锚点。
This tutorial aggregates hands-on experience from real-world private-deployment integration projects, using the Kingdee Cloud Galaxy Sales Order query and the Xiaoshouyi currency and bank account queries as the example. It covers authentication, incremental pagination, nested field extraction, code mapping, scheduling, and retry practices.
亚马逊 Subscribe & Save 订阅服务在 2026 年跨境家居 / 母婴 / 美妆品类的复购率贡献占比 28-42%，但它的财务对账远比普通订单复杂——同一订阅下的不同配送周期（月付 vs 周付）、3 类折扣的叠加（阶梯折扣 + Coupon + Bundle）、跳过订单（Skip）与取消订阅（Cancellation）的两条出口判定，都是境内电商看不到的特殊场景。本文以订阅订单的「分向聚合 × 折扣叠加判定顺序 × 无单守卫 × 跨期归属」为 4 条主线，拆解 Subscribe & Save 对账的工程框架，给出 5 个反直觉结论与 5 步走的实操建议——为订阅订单占 GMV 20%+ 的跨境品牌财务经理提供一份"4 主线 × 5 反直觉 × 5 步走"的操作地图。
最近三个月，业务一线咨询「AI Agent 能不能帮我写脚本」「沙箱安不安全」「能不能撤销」的问题集中在 4 类：能力边界、工作流、安全、知识库。本文按这 4 类递进，挑出最高频的 10 个问题逐条作答——读者可跳到对应编号阅读，也可从头串读。每一问都对应代码里的真实落点，不是 PPT 上的承诺。
This tutorial consolidates hands-on experience from multiple projects around the 'Xiaomi Inventory Query - with stock_age_XM_VIEW' interface, detailing field mapping, stock age aggregation, incremental sync, and pitfall handling, helping engineers complete SQL Server to Xiaomi supply chain inventory integration on the Qeasy platform.
