Querying Cost Valuation Streams from LingXing ERP: A Single-Strategy Supply Chain Integration Tutorial

What This Strategy Solves

For many retail enterprises, cost accounting logic lives on the LingXing ERP side, and monthly closing requires every cost valuation stream to flow back into Kingdee Cloud Cosmos for reconciliation and journal support. Querying the source system directly and importing by hand is slow and error-prone. The Query Cost Valuation Streams from LingXing strategy does one focused thing: pull streams from LingXing ERP on a schedule, land them in an intermediate layer for downstream strategies to consume, and not write any business document into the target — the target side is configured as a no-op write, serving as a stable staging point.

Data Flow and Field Mapping

The overall flow shape is Source → Intermediate Layer → No-Op Target, with the core data held on the Qeasy data integration platform side and consumed on demand by subsequent strategies.

The source comes from LingXing ERP's /cost/center/api/cost/stream endpoint (POST). The filter dimensions it accepts include: warehouse name wh_names, shop name shop_names, SKU, MSKU, inventory attribute disposition_types (1 = in-transit available / 2 = available / 3 = defective), business type business_types, and others. The returned primary key is unique_key, which is used both as the dedup number and as the id, with idCheck enabled.

The intermediate layer is the Qeasy integration platform itself (datahub), acting as the relay and cache. The target is a WebAPI-shaped no-op write, method POST, with empty request and response — its role is not to disturb downstream business systems but to let this strategy "close" in the orchestration graph.

How to Configure on Qeasy

After picking the platform and API on the source side, the key is not to leave all filter conditions empty. For the four dimensions — warehouse, shop, inventory attribute, business type — we recommend passing at least one, otherwise the response volume is huge and pagination tends to collapse on the first run.

The intermediate layer needs no special configuration. As long as autoFillResponse and idCheck are both on, the platform will deduplicate by unique_key and accumulate automatically. A common pattern we see among Qeasy customers is to manage encoding mappings centrally on the platform side — LingXing-side SKU, warehouse, and shop codes are mapped into a unified Kingdee-side code dictionary here, and downstream strategies reuse it directly, so each strategy doesn't maintain its own mapping table.

The no-op write on the target side is straightforward to configure — just leave request/response empty. Its purpose is to give the orchestration graph a complete node, making it easy to attach branch strategies later (e.g., pushing the streams to a Kingdee custom document, or flowing them onward to a BI store).

Implementation Steps

We split the rollout of this strategy into three steps:

Step 1: Confirm the incremental starting point. First align with finance on the "lookback starting point" for cost valuation streams. The LingXing endpoint supports time-window filtering. We recommend a cold start with "last 7 days" to pressure-test pagination size, timeout, and retry settings, then widen the window once stable.

Step 2: Full-volume trigger. After cold start, remove the time window and let the endpoint return historical data by default. Use Qeasy's "manual trigger + full mode" for this pass — the goal is to get all historical streams into the intermediate layer. A common response pattern we see with Qeasy customers is the "incremental + full dual-track" approach: incremental every 4 minutes in normal operation, with a one-click full trigger when needed for backfill.

Step 3: Schedule frequency and throttling. The strategy's crontab is */4 * * * *, one round every 4 minutes. Note that the LingXING side has rate limits on high-frequency calls. The safe approach is to add a throttling switch: when consecutive failures exceed a threshold, automatically back off the frequency, then ramp back to 4 minutes once recovered.

Pitfalls and Lessons Learned

1. Empty filter conditions cause a pagination avalanche. The first run passed no filter dimensions at all and got back 500k rows that timed out. The safe approach is to pass at least one dimension and keep page size between 200 and 500.

2. Misreading the inventory attribute enum values. The 1/2/3 in disposition_types are not fixed Chinese meanings — they need to be interpreted in the context of inventory state at the time. We once hardcoded "1 = available" in a script and ended up with a pile of in-transit inventory landing on the Kingdee side, which made reconciliation very confusing.

3. unique_key cannot be reused across books. If multiple legal entities share one LingXing tenant, unique_key needs prefix concatenation on the platform side before deduplication; otherwise streams from different entities will overwrite each other.

4. The no-op target mistaken for "misconfiguration". New colleagues see the empty request/response and assume it's a configuration error. In fact, this is a variant of the header/body phased approach — first close the loop with a no-op, then wire up the real target system once the downstream consumption strategy is stable.

5. High-frequency schedule colliding with source-system maintenance windows. */4 during the early-morning maintenance window tends to trigger 5xx responses. We recommend aligning the throttling switch with the maintenance window schedule.

Suitable and Unsuitable Scenarios

Suitable: scenarios where LingXING-side cost streams need to flow back reliably to a hub for reconciliation, secondary processing, or delivery to downstream ERP/BI; and scenarios where a "pure query" staging node is needed in orchestration. Not suitable: scenarios that require real-time (second-level) return of a single stream for business decision-making — a 4-minute scheduling granularity does not support that; or scenarios with strong-consistency requirements on cost data that must query the source system directly.