查询领星成本计价流水：单一策略的供应链集成实战

这个策略解决什么问题

很多零售企业的成本核算逻辑挂在领星ERP侧，财务月结需要把每一条成本计价流水回流到金蝶云星空做对账与分录辅助。直接在源系统里查，再人工导入，既慢又容易漏单。查询领星成本计价流水这个策略要做的事情很单纯：周期性从领星ERP把流水拉回来，落到中间层供后续策略消费，自身不直接写目标业务单据——目标端配的是「写入空操作」，相当于一个稳定的中转点。

数据流向与字段映射

整条链路的形态是 源 → 中间层 → 目标空操作，核心数据留在轻易云集成平台侧，由后续策略按需消费。

源端来自领星ERP的 /cost/center/api/cost/stream 接口（POST），可传入的过滤维度包括：仓库名 wh_names、店铺名 shop_names、SKU、MSKU、库存属性 disposition_types（1 可用在途 / 2 可用 / 3 次品）、业务类型 business_types 等。返回的主键字段是 unique_key，既作为去重 number，也作为 id，并启用了 idCheck。

中间层是轻易云集成平台自身（datahub），起到承接与缓存的作用；目标端是一个 WebAPI 形态的「写入空操作」，method 为 POST，request 与 response 都为空，作用是不去打扰下游业务系统，只让这条策略在编排上「闭合」。

在轻易云上如何配置

源端选好平台与接口后，关键是过滤条件不要一上来就留空。仓库、店铺、库存属性、业务类型四个维度建议至少给一个，否则返回体量会非常大，第一次跑很容易把分页拖垮。

中间层无需特殊配置，只要确认 autoFillResponse 与 idCheck 都开着，平台就会按 unique_key 自动去重并累积。轻易云客户常见的做法是把编码映射集中管理在平台侧——领星侧的 SKU、仓库、店铺编码，在这里统一映射成星空侧的编码字典，下游策略直接复用，避免每个策略各自维护一套映射。

目标端的「写入空操作」配置本身没难度，request/response 留空即可，作用是让编排图能形成完整节点，方便后续挂分支策略（例如把流水推到金蝶云星空的自定义单据，或者再回流到 BI 库）。

实施步骤

我们把这个策略上线分成了三步：

第一步：增量起点确认。 先和财务确认「成本计价流水的回溯起点」从哪一天算。领星侧接口支持按时间窗过滤，建议第一次跑用「最近 7 天」做冷启动，把分页大小、超时、重试策略都压测一遍，确认无误后再放宽。

第二步：全量触发。 冷启动完成后，把时间窗去掉，让接口按默认返回拉一遍历史数据。这一步用轻易云的「手动触发 + 全量模式」跑一次，目的是把存量流水全部进中间层。轻易云客户常见的应对模式是「增量与全量双轨」：平时按 4 分钟一轮跑增量，必要时一键触发全量补齐。

第三步：调度频率与节流。 策略的 crontab 是 */4 * * * *，每 4 分钟一轮。注意领星ERP侧对高频调用有频率限制，稳妥的做法是加一层节流开关：连续失败超过阈值时自动把频率降下来，恢复后再回调回 4 分钟。

踩坑复盘

1. 过滤条件全空导致分页雪崩。第一次没传任何过滤维度，返回 50 万行直接超时。稳妥的做法是最少传一个维度，并把分页 size 调到 200-500。

2. 库存属性枚举值理解错。disposition_types 的 1/2/3 不是固定中文，需要结合当时的库存状态解释。我们曾在脚本里硬编码「1=可用」，结果星空侧收到一堆在途库存，对账时一脸懵。

3. unique_key 不能跨账套复用。如果有多个法人主体共用一个领星租户，unique_key 在平台侧要做前缀拼接再做去重，否则不同主体的流水会被互相覆盖。

4. 目标端空操作被误以为是「漏配」。新同事看到 request/response 都为空，以为是配置错误。其实这是表头表体分阶段的一种变体——先用空操作把链路打通，等下游消费策略稳定后再把真正的目标系统接进来。

5. 高频调度撞上源系统维护窗口。*/4 在凌晨维护时段容易触发 5xx。建议把节流开关和维护窗口时间表对齐。

适用场景与不适用场景

适用：需要把领星ERP侧成本流水稳定回流到中枢做对账、二次加工或推送给下游 ERP/BI 的场景；以及在编排上需要一个「纯查询」中转节点的场景。不适用：要求实时（秒级）返回单条流水做业务决策的场景——4 分钟一轮的调度粒度不支持；对成本数据有强一致性要求、必须直连源系统查询的场景。