Syncing LingXing Purchase Receipts to Kingdee Cosmic: A Field Guide to One Strategy
What This Strategy Solves
Cross-border or multi-entity retailers often run purchasing receiving in LingXing ERP while keeping general ledger and cost accounting in Kingdee Cosmic. LingXing is the operational system; Kingdee is the financial one. If both sides enter the same receipt manually, after three months the inventory quantities, receipt amounts, and supplier payable accounts will drift apart. This strategy pulls LingXing warehouse receipt lists into Kingdee Cosmic purchase receipts under a defined rule so every receipt lands once and the two systems stay aligned.
Data Flow and Field Mapping
The overall flow is B → A: LingXing ERP (source) pulls the warehouse receipt list → Qeasy integration platform performs cleaning and code mapping in the middle → Kingdee Cosmic (target) writes the purchase receipt.
Key field mapping (desensitized, refer to source/target metadata in production):
| Business meaning | LingXing ERP (source) | Mapping layer | Kingdee Cosmic (target) |
|---|---|---|---|
| Receipt no. | receipt_no | Pass-through | FBillNo |
| Receipt date | receipt_date | Normalize to yyyy-MM-dd | FDate |
| Supplier | supplier_code | Supplier lookup table | FSupplierId (internal id) |
| Warehouse | warehouse_code | Warehouse code map | FStockId |
| Item code | sku | Item lookup table (LingXing SKU → Cosmic material id) | FMaterialId |
| Received qty | qty | Non-negative validation | FQty |
| Tax-inclusive price | price_with_tax | 4 decimal places | FTaxPrice |
| Remark | remark | Truncate to 200 chars | FNote |
The code mapping layer is the lifeline of the whole chain. On Qeasy we typically isolate supplier, material, and warehouse mappings as standalone lookup sets, so a code change on either side only requires one update rather than triggering a full rerun.
How to Configure on Qeasy
We use Qeasy (轻易云数据集成平台) as the integration backbone. For business document sync like this, the typical setup is:
- Source connector: Configure LingXing ERP OpenAPI credentials, select the "query warehouse receipt list" endpoint, and use last-modified-time as the incremental cursor.
- Target connector: Kingdee Cosmic "Purchase Receipt" save API. Kingdee enforces strict header/body grouping, so define the field grouping strictly according to the target template on Qeasy.
- Transformation layer: Centralize code mapping, field normalization, and null fallback here. Qeasy supports both visual mapping and script nodes. Prefer visual for the majority of fields, and reserve scripts for complex cases such as FX conversion or batch splitting.
- Write control: Kingdee requires unique bill numbers. We add an idempotency table in the middle layer—check before write—to prevent duplicates.
- Exception branch: Kingdee error codes (e.g., insufficient inventory, organization isolation) are routed to a manual handling queue rather than retried blindly.
Implementation Steps
We usually roll this out in three stages to keep things stable:
- Stage 1: Full load (initialization). Backfill historical data in one shot. Use Qeasy's "full schedule" trigger to pull the last N months of LingXing receipts into Kingdee. Real-time is not the goal here; "reconciliation passes" is. After completion, a manual reconciliation is mandatory.
- Stage 2: Incremental cursor switch. Use the full-load end time as the new incremental cursor. A common pitfall here is timezone mismatch—unify on UTC+8 across both systems.
- Stage 3: Steady scheduling. Frequency is driven by business cadence. A common pattern is dual-track incremental plus full: incremental every 5–15 minutes during the day, plus a light full check at dawn as a safety net. Faster is not better—it depends on LingXing API rate limits and Kingdee's write concurrency ceiling.
Lessons from the Field
- Code mapping buried in scripts. A classic mistake is hard-coding supplier/item mappings inside transformation scripts. When either side changes its coding rule, the engineer has to touch every script. The safer pattern is centralized code mapping maintained on Qeasy's mapping sets.
- Header and body pushed in one shot. Kingdee's purchase receipt header and body are tightly coupled. Wrong grouping produces dirty records where the header exists but the body is missing. The recommended pattern is phased header-then-body: write the header first to get the internal id, then fill back the body, with rollback at each step.
- Ignoring the "approved" status gap. LingXing's already-approved receipts, when written directly into Kingdee, trigger Kingdee's reverse-write logic and pre-book the cost. A safer approach is to land these in Kingdee as "unapproved", then let Kingdee's own approval flow take over.
- Duplicate receipts. The LingXing list endpoint can occasionally return the same bill number at pagination boundaries. Without an idempotency table, the same receipt is recorded twice. Do not use bill number alone as the idempotency key—use the combination of "source org + bill number".
- Timezone and date cut-off. A receipt at dawn may be "yesterday" in LingXing and "today" in Kingdee, causing drift at month-end. Unify the receipt date at the business-day level (e.g., 08:00 cut-off) in the middle layer.
When to Use and When Not
Use when: Cross-border e-commerce, multi-entity retail, or cross-border trading enterprises where LingXing is operational and Kingdee is financial, and where purchase receipts need to be unified in Kingdee for GL and cost accounting.
Don't use when: Pure warehouse operations without financial accounting, or scenarios where Kingdee is already the entry source and there is no dual-entry divergence—forcing sync only adds complexity.