Latest industry insights, tutorials, best practices and case studies.
276 articles
一家年 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.
电商财务对账做到 80% 后撞上的那堵墙，根源不在引擎、不在 ERP，而在「差异原因」字段是不是结构化。本文拆解 v3 对账体系里最容易被忽视、却承担 80% 自动化收益的工程支点——「机读码 + 人读建议」双轨设计：23 个 `diffReason` 给机器消费、决定下游集成脚本按码精准出单；`diffDisposalSuggestion` 给人阅读、保留财务手补痕迹不被自动重跑清空。这对字段采用**不对称落库语义**，正是把对账从「工程实现」升级为「业务规范」的关键设计。
当一份对账差异表里有 14 行 FAILURE，传统的呈现方式是「自由文本 + 数字」。审计师拿到这张表的第一反应是「我需要把每一行的差异原因重新归类」——这一步往往占去 60-70% 的现场工时。23 个业务标签码（diffReason + diffDisposalSuggestion 双字段）做的就是把这一步从「现场归类」前移到「系统标注」：每条差异在落到数据库那一刻就带上了「机读码」与「中文处理建议」两个标签，审计师拿到的是一张可机读、可分组、可穿透到凭证的差异地图，而不是一锅自由文本。
业务人员反复在同一个地方犯嘀咕——"我只改了分摊脚本，run-allocate 一下怎么就把订单明细清掉一列又重写？"这不是 bug，是双模式的代价。「公摊」用 **实时**（E1：先撤旧再累写），「订单费用下沉」用 **覆盖式**（E11：先清零再 set 写）。本文不抽象，给业务人员和财务经理一份 4 维度对比 + 3 步选择法，把"我什么时候该期望哪种行为"讲明白。
亚马逊日本站对账不是「美站对账 + 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.
最近三个月，业务一线咨询「AI Agent 能不能帮我写脚本」「沙箱安不安全」「能不能撤销」的问题集中在 4 类：能力边界、工作流、安全、知识库。本文按这 4 类递进，挑出最高频的 10 个问题逐条作答——读者可跳到对应编号阅读，也可从头串读。每一问都对应代码里的真实落点，不是 PPT 上的承诺。
亚马逊 Subscribe & Save 订阅服务在 2026 年跨境家居 / 母婴 / 美妆品类的复购率贡献占比 28-42%，但它的财务对账远比普通订单复杂——同一订阅下的不同配送周期（月付 vs 周付）、3 类折扣的叠加（阶梯折扣 + Coupon + Bundle）、跳过订单（Skip）与取消订阅（Cancellation）的两条出口判定，都是境内电商看不到的特殊场景。本文以订阅订单的「分向聚合 × 折扣叠加判定顺序 × 无单守卫 × 跨期归属」为 4 条主线，拆解 Subscribe & Save 对账的工程框架，给出 5 个反直觉结论与 5 步走的实操建议——为订阅订单占 GMV 20%+ 的跨境品牌财务经理提供一份"4 主线 × 5 反直觉 × 5 步走"的操作地图。
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.
电商行业涉税面比传统零售宽得多——一家做跨境电商的中型公司，可能同时要面对 6 大税种（增值税、消费税、企业所得税、个人所得税、印花税、关税）的精细化核算，每个税种的计税基础、税率、申报频率、平台代扣场景都不一样。本文把 6 大税种拆成「计税基础 × 平台场景 × 申报节点 × 常见坑」4 个维度逐一拆解，给到一份能直接落到对账系统的税务处理 map——CFO 和税务经理看完，能立刻定位自己公司在哪个税种上还欠着账。
把电商财务的全流程拆开看，过去 18 年的"按账期对账"是"事后算账"——每月 1 次、月底拉账单、手工对账、月初出报表。2026 年的电商日均订单已是 8000-12000 单、退款潮 7-15 天、平台扣点 24 小时波动、月度差异累积 3000 万元是常态。"流程再造"不是把月对改成周对或日对——是把"以账期为单位的批量处理"重新设计为"以业务事件为单位的实时触发"：订单完成、退款完成、佣金结算、平台代扣税、ERP 推送成功 5 类事件各自触发独立流水线。本文给出 5 类业务事件的标准定义、流程再造的 3 层技术底座、1 份从"按账期"过渡到"按事件"的 4 阶段路径，以及 3 个反直觉判断。读者是 CFO 和财务经理，看完应该能直接拍板"我们公司要不要做流程再造、怎么做、半年内能拿到什么"。
2024 年 Temu（拼多多海外）对账逻辑发生「**业务模式两极分化**」的剧变 ——一边是 **Temu 全托管**（商家供货 / 平台代运营代销代发货），一边是 2024 年下半年才大规模放量的 **Temu 半托管**（商家自备货到 Temu 合作海外仓 / 平台负责销售 / 商家自负责售后退货回流 / USD 结算后结汇 CNY）。两种模式对账路径**完全不一样**：全托管走二方核对（无买家订单号），半托管走「**三方两段式**」——平台账单 ↔ 海外仓入库快照 ↔ 商家内部核算 + 资金回流链独立追踪。本文以 2026-08-22 Temu 半托管试点接入定稿记录 + 试点 6 月账期实测为基准，拆透半托管对账新规则 ——核心是 **3 道闸门**（主营收入正循环 SUCCESS / 海外仓入库未映 MISSING_WAREHOUSE / 跨业务类型混淆 ORDER_TYPE_MISMATCH）+ **售后退货回流四件套**（回流单独立记账 + 货品回流登记 + 质检报废标记 + 退运费回拨）+ **USD 结算镜像**（平台收付净额 = 商家 USD 收单合计、商家实收
