加工厂分发到金蝶盘亏单同步：单一策略实战教程

这个策略解决什么问题

某零售/制造企业的加工厂前端在盘货后会产生盘亏结果，需要把这一结果以盘亏单的形式落到金蝶云星空里，作为财务和库存核算的源头。表面上看是“一张单据推到下游”，但跨系统、跨账套之后，组织、货主、单据类型、计量单位、批号任何一个维度对不齐，盘亏单就会被下游驳回或挂起。这条策略要解决的，就是把加工厂分发的盘亏数据，稳、准、可追溯地写入金蝶盘亏单。

数据流向与字段映射

整体流向是 加工厂分发（上游） → 轻易云（Qeasy）中间层 → 金蝶云星空盘亏单。

上游侧是一条空操作触发查询（WebAPI / POST），靠 BILL_NO 作为单据编号、ReqId 作为幂等键拉取盘亏结果。返回的关键字段包括 ReqId、FBillTypeID（单据类型编码）、FBusinessType（业务类型）、FDate（业务日期）、FSupplierId（供应商/加工厂标识）等。

下游侧调用金蝶 batchSave，把盘亏单写入星空。关键字段对照表如下：

这里的关键不在字段数量，而在三类映射：编码映射（加工厂→金蝶字典）、组织映射（账套→库存组织/货主）、日期/编号格式映射。这三类映射建议全部沉淀到轻易云的统一映射表中集中管理，避免散落在各个策略里。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略通常由「源端采集器 + 目标写入器」两部分组成。

源端：选用 WebAPI 触发器，方法 POST，请求体可为空（“请求空操作”），通过 URL 参数或上下文中的 BILL_NO 拉取上游盘亏数据。返回结果直接作为本策略的输入载荷。

目标端：选用金蝶云星空的 batchSave，方法 POST。请求体按金蝶单据模型组装，单据头先放 FBillNo、FStockOrgId、FDate、FBillTypeID、FOwnerTypeIdHead、FOwnerIdHead，再跟表体行项目。

几个我们经常在客户现场强调的配置要点：

1. idCheck 设为 true：金蝶这侧按 id 做幂等校验，重复推送不会产生脏数据。
2. 单据类型必须用金蝶字典里的编码（如 PK01_SYS），不要把上游原始编码直接透传。
3. 日期统一格式化为 yyyy-MM-dd 或带 T 的 ISO 字符串，避免时区/格式差异导致的驳回。
4. 表头表体分阶段映射：先把单据头打通，确认下游能落单，再补表体的物料、批号、数量、原因代码。

实施步骤

我们建议按“增量起步 → 全量兜底 → 调度常态化”三步走。

第一步：增量起点。 先用一条真实盘亏数据做端到端冒烟：从加工厂分发拉一条记录，走完映射、写入金蝶、查询回执，确认单据能在星空里查到。这一步不追求跑批，只验证链路。

第二步：全量触发。 冒烟通过后，触发一次全量回灌，把历史盘亏数据按时间窗口（建议按月分批）补齐。全量阶段要打开轻易云的运行日志，逐批核对成功数、失败数和驳回原因。

第三步：调度频率。 上游调度采用较稀疏的间隔（素材中 crontab 为 1 1 1 1 1，可理解为低频触发），下游金蝶写入采用近实时频率（素材中 */3 * * * *，即每 3 分钟一轮）。这种“上游稀疏拉、下游近实时写”的双轨节奏，是轻易云客户常见的应对模式：避免上游被频繁轮询打爆，同时保证下游落单延迟可控。

踩坑复盘

1. 单据类型编码写错：直接把上游的 FBillTypeID 原样推到金蝶，结果星空里根本没有这个字典，批量失败。稳妥的做法是建立上游→金蝶的编码映射表，并加单元测试覆盖每个枚举值。
2. 库存组织和货主混为一谈：把“加工厂”直接当成“库存组织”写入，导致盘亏单挂在错误的组织下，财务无法对账。必须把库存组织、货主类型、货主 ID 拆成三个独立字段分别映射。
3. 日期格式不一致：上游是 yyyy-MM-ddTHH:mm:ss，下游期望 yyyy-MM-dd，格式没归一就被驳回。建议在轻易云里加一个统一的日期格式化组件。
4. 没开幂等，重复推送产生脏单：idCheck 默认为 false 时，重跑会生成多张盘亏单。一旦打开幂等并以 ReqId 作为 id，重复推送会自动覆盖。
5. 全量一把梭哈导致下游压力：历史数据一次性推送，几万条盘亏单同时落到金蝶，触发星空限流。稳妥的做法是按月分批，每批之间留出缓冲。

适用场景与不适用场景

适用：上游已经形成结构化的盘亏结果（如加工厂分发的盘亏数据），需要按单据落到金蝶做财务核算和库存冲减；组织/货主/单据类型字典相对稳定。不适用：上游盘亏数据非结构化、需要人工判定；或者金蝶侧的组织、货主、单据类型字典尚未稳定，频繁变更的情况——此时应先做基础资料同步，再谈盘亏单同步。