Sync Purchase Receipts from Kingdee to Jushuitan: A Practical Configuration Tutorial

What This Strategy Solves (Scenario and Value)

In supply-chain integration projects, a retail company often faces an awkward situation: Kingdee Cloud serves as the source of procurement and finance, while Jushuitan handles warehousing and front-end operations. Both systems require duplicate entry of purchase receipts, leading to operator fatigue and frequent reconciliation mismatches.

The approach we deliver with Qeasy (Qingyiyun Data Integration Platform) is to push Kingdee's purchase receipts into Jushuitan according to predefined rules. Jushuitan then generates the corresponding purchase receipt, so warehouse staff only operate in one system while finance reviews in the other — accounts and inventory naturally stay aligned. This is the most typical, yet underestimated, "business document sync" scenario in supply-chain integration.

Data Flow and Field Mapping

The overall flow is: Kingdee Cloud (source) → Qeasy middleware layer (mapping / transformation / validation) → Jushuitan (target). The middleware layer handles code mapping, field conversion, mandatory field validation, and idempotency control — the part most worth investing design effort in.

Key field mapping:

Centralized code mapping is one of the most common patterns on Qeasy. Keeping supplier, material, and warehouse mappings in a unified set of mapping tables means a single rule change propagates to every strategy that depends on it.

How to Configure in Qeasy

In Qeasy Data Integration Platform, a single "Kingdee-Purchase Receipt → Jushuitan-Purchase Receipt" strategy typically consists of:

1. Source connection: Configure the Kingdee Cloud endpoint, credentials, and query views (header + line composite views).
2. Target connection: Configure Jushuitan open API credentials pointing to the "purchase receipt write" endpoint.
3. Extraction condition: Use FModifyDate > last_success_time for incremental extraction, while keeping a manual "full re-sync" trigger available.
4. Field mapping and transformation: Maintain header and line items separately. Headers map 1:1, while line items handle material, unit, and precision per row.
5. Validation and failure handling: Mandatory field checks, missing-mapping interception, and decision on whole-document rollback vs. per-line retry based on the customer's accounting tolerance.
6. Logging and observability: Qeasy records fetch, transform, and push outcomes per document for after-the-fact traceability.

Implementation Steps

We recommend a three-phase rollout: incremental start → full-volume backfill → stabilized scheduling.

Phase 1: Incremental Start First confirm Kingdee has a reliable timestamp field (typically FModifyDate), then switch the strategy to time-windowed incremental extraction. We suggest starting at every 15 minutes. The goal here is "don't miss a single document".

Phase 2: Full-Volume Trigger Once incremental is stable, run a historical full backfill. We typically use Qeasy's "full sync trigger" once and manually reconcile document counts and amounts. This phase often surfaces "dirty historical data" — voided documents or zero-amount test entries — which requires adding filters in the middleware.

Phase 3: Scheduling Stabilization Once business is stable, frequency can be tuned to business volume: 15 minutes during peak hours, hourly or longer during off-peak. Enable failure alerts so on-call staff are notified immediately of Jushuitan-side write failures.

Splitting header and body into separate phases is another common pattern on Qeasy: stabilize the header first, then run the body, then merge — instead of pushing the whole document at once and struggling to locate issues afterward.

Pitfall Review

1. Running purchase-receipt sync before material master sync. Classic mistake: configuring purchase receipts first, only to see all product codes fail mapping in Jushuitan. The safe approach is to confirm the material master-data strategy is already stable, since purchase-receipt depends on it.

2. Inaccurate source timestamps. Kingdee's FModifyDate does not always update on un-approval or line-item change, which causes missed documents. In such cases, add a "dedupe by document number + full-volume compensation" fallback in the middleware.

3. Precision and tax-caliber mismatch. Kingdee prices are usually tax-inclusive, while Jushuitan may require tax-exclusive values. We centralize the conversion in the middleware and document it clearly to avoid later reconciliation disputes.

4. Idempotency key collisions. Network-jitter retries may push the same receipt twice. Always use FBillNo as the idempotency key in the middleware — duplicates should be skipped or routed to an update branch.

5. Concurrent full-volume and incremental causing duplicates. Running full backfill while incremental scheduling is active easily produces duplicates. We recommend triggering full backfill only inside a manual window, then re-enabling incremental scheduling with a mutex flag set.

Applicable and Non-Applicable Scenarios

Applicable: Enterprises where Kingdee handles procurement and finance while Jushuitan handles warehousing and operations, with aligned organizational structures and product master data; high-frequency purchase receipts with strict reconciliation SLAs.

Not applicable: Cases where Jushuitan has fully outsourced the procurement flow upstream; projects where Kingdee has not yet standardized material and supplier master data (stabilize master data sync first, then business documents).