Kingdee Cloud Skylus PUR_ReceiveBill to Jijia ERP: Cross-Solution Field Manual

What This Interface Solves

In cross-border e-commerce and ERP supply chain integration, the bidirectional sync between Kingdee Cloud Skylus Purchase Receipt (PUR_ReceiveBill) and Jijia ERP Other Inbound / Other Outbound documents is the backbone of inventory consistency. In real scenarios, a cross-border retail enterprise uses Kingdee as the finance and master warehouse hub, while Jijia handles multi-channel (Amazon, Mercado Libre, independent sites) orders and fulfillment — every purchase receipt, transfer discrepancy, and stock adjustment must flow back in real time; otherwise, book-to-physical variance surfaces directly in settlement reports and receivables.

Interface Capabilities Overview

• Authentication: Kingdee typically uses OAuth2 + tenant tokens (per business tenant), while Jijia uses AppKey + signature or a custom gateway token. Credentials must be pre-configured in Qeasy Cloud and isolated by business tenant.
• Request Structure: Kingdee query APIs (QueryBill / ExecuteBillQuery) are built on FormId + FilterString + FieldKeys; write APIs (Save / Submit / Audit) follow the standard document body. Jijia side uses RESTful JSON, typically /api/inventory/otherIn, /api/inventory/otherOut.
• Pagination / Incremental Mode: Kingdee paginates with Limit + StartRow; incremental sync uses FApproveDate, FDate, or FModifyDate as watermark fields. Jijia paginates with the last_update_time cursor; full sync is used for initial load and reconciliation repair.
• Response Structure: Kingdee returns Result.Result (document set) + Result.Status; Jijia returns { code, data, message } — watch for partial success when code≠0.

Typical Field Mappings

Centered on "Kingdee Purchase Receipt → Jijia Other Inbound", with transfer and query highlights:

How to Configure in Qeasy Cloud

In the Qeasy Cloud Data Integration Platform, this interface uses a Kingdee Skylus Adapter + Jijia ERP Adapter dual-adapter combination:

1. Data Source / Target Source: Select "Kingdee Cloud Skylus" and "Jijia ERP" respectively, fill in credentials.
2. Strategy Templates: Qeasy Cloud ships templates for "Kingdee PUR_ReceiveBill → Jijia Other Inbound", "Bidirectional Transfer", "Warehouse/Customer Query", etc. — one click to derive 30 strategy skeletons.
3. Field Mapper: Drag-and-drop for the mappings above; code mapping tables (material, warehouse, customer, unit) are centrally maintained in the "Master Data Management" module; the platform auto-propagates changes to all referencing strategies.
4. Scheduling & Watermark: Master data strategies run every 30 minutes by default, business documents every 10 minutes; incremental watermark is automatically injected into FilterString via the LAST_SYNC_TIME global variable in Qeasy Cloud.
5. Exception & Alerts: Single-record failure → dead-letter queue + N retries; strategy-level exceptions trigger DingTalk alerts (strategy 30).

Cross-Solution Best Practices

From multiple cross-border e-commerce client projects, we distilled the following common lessons:

1. Master Data First: Kingdee material, warehouse, and customer must sync before business documents; otherwise, FMaterialId.FNumber in purchase receipts has no matching sku and the entire document fails.
2. Use FApproveDate as Watermark, Not FCreateDate: Cross-border scenarios frequently involve supplementary posting and reject-then-re-approve; using approval date guarantees eventual consistency.
3. Centralize Code Mapping: Material, warehouse, customer, and store→Kingdee customer mappings must live in the platform's master data module — scattering them across strategies is a maintenance disaster.
4. Distinguish Inbound from Returns: A single PUR_ReceiveBill may produce both "Other Inbound" and "Other Outbound" (red-letter) flows in cross-border business; filtering by document type/status is required, or inventory gets inflated.
5. Store→Customer Mapping: Each Amazon site, Mercado Libre store, and independent site needs its own Kingdee customer record; otherwise sales outbound, receipts, and other receivables all go to the wrong org.
6. Staggered Scheduling: Master data every 30 min, business docs every 10 min, but settlement-report-driven strategies (sales outbound, receipt, other receivables) must wait until reports are fully generated — otherwise data is missed.

Pitfall Retrospective

1. Quantity Precision Drift: Kingdee supports 4 decimals, some older Jijia versions only accept 2 — one client lost 0.0001 unit after rounding, breaking book-to-physical. Safe approach: configure explicit ROUND(qty, 2) cleansing in Qeasy Cloud's field mapper.
2. Empty Warehouse Codes: When either the outbound or inbound warehouse on a transfer is empty, Kingdee write API returns success but the document has zero inventory impact — easy to miss. Filter source data to non-null FStockOutOrgId and FStockOrgId before syncing.
3. Store Code Cross-Mapping: Mapping Mercado Libre stores to Amazon Kingdee customers landed a full month of receipts in the wrong org. This is where things break. Safe approach: enforce "platform + store" composite as the unique key in mapping tables.
4. Idempotency Failure on Re-runs: Concurrent incremental triggers push the same FBillNo twice. Qeasy Cloud's idempotency key defaults to document number, but cross-system case-sensitivity differences break it — always enable strict-match mode.
5. Settlement Report Delay: Amazon settlement reports typically generate 7-14 days after a transaction; pulling too early misses data. Recommend adding a "report availability check" in scheduling — skip rather than error when the report isn't ready.

When to Choose

Applicable: bidirectional inventory and sales document sync between cross-border e-commerce ERP (Jijia) and domestic general-ledger ERP (Kingdee Skylus), especially multi-channel, multi-store, multi-currency retail. Not applicable: pure manufacturing scenarios (use MES), enterprises without Kingdee/Jijia, or lightweight single-direction sync needs.