Integration Field Handbook: Jushuitan to Kingdee Cloud Skylink Supply Chain Integration

What This Interface Solves

In retail enterprises that run both an e-commerce ERP and a finance ERP simultaneously, Jushuitan manages front-end stores, orders, and inventory flow, while Kingdee Cloud Skylink handles back-end materials, suppliers, procurement, and financial accounting. Without integration, you get duplicate item codes, mismatched inventory, lost purchase orders, and sales outbound data that never reaches finance. By aggregating experience across multiple customer deployments, we have distilled this bidirectional sync chain — master data (items/suppliers) → purchase orders/receipts/returns → sales outbound — into a single field handbook so you can master the key design patterns in one read.

Interface Capability Overview

Authentication: Jushuitan uses app_key + app_secret signature-based open-platform authentication; Kingdee Cloud Skylink uses OAuth2 / Bearer Token flows based on data center ID + application ID, with tenant ticket caching for refresh.

Request structure: Jushuitan Qimen/non-Qimen endpoints accept page_index / page_size / modified_begin / modified_end via form or JSON; Kingdee Cloud Skylink uses formId (e.g., BD_MATERIAL, PUR_PurchaseOrder, SAL_OUTSTOCK) plus business parameters and OrgId organizational filters.

Response structure: Both return paginated data (line item arrays + total count). Note that Kingdee wraps results in Result with ResponseStatus success flag, while Jushuitan nests items under data.items with has_next.

Pagination and incremental modes: Jushuitan increments primarily via modified_begin/modified_end, with optional pay_date filtering for sales outbound; Kingdee prefers approval date FApproveDate, supplemented by FModifyDate. Initial deployment must run a full backfill; subsequent runs use LAST_SYNC_TIME sliding windows.

Typical Field Mappings

How to Configure on Qeasy

In the Qeasy Data Integration Platform, this solution is typically split into three layers: a Jushuitan connector, a Kingdee Cloud Skylink connector, and orchestration. The Jushuitan connector ships with built-in templates for jushuitan.saleout.list.query and similar endpoints — you can pick a template and adjust the shop_id filter; the Kingdee connector provides predefined schemas for BD_MATERIAL, PUR_PurchaseOrder, SAL_OUTSTOCK, and more, with OrgId bound as a connection attribute.

Code mappings (item / supplier / warehouse / shop-to-customer) are maintained in Qeasy's "Field Mapper," which supports manual table creation, SQL sync, and Excel import. The Field Mapper automatically validates source and target field types — for example, converting Kingdee's FEntryTaxRate (percentage) to Jushuitan's tax_rate (decimal) using the custom function round(x/100,2), no coding required.

For scheduling, Qeasy places query-type tasks in the master data group and chains business documents into a DAG based on dependencies. Failure queues and retry backoff policies are built in, so a single failed record never blocks subsequent batches.

Cross-Solution Practical Points

1. Master data always comes first: Items, suppliers, and warehouses must be queried and synced ahead of business documents; otherwise sku_id, supplier_id, and wms_co_id will not land at the target.
2. Code mapping is the linchpin: Maintain item, warehouse, and shop-to-customer mapping tables early and support bidirectional lookup. Custom Kingdee fields like F_QKMS_JSTBM must be modeled in Kingdee before any Jushuitan-side filtering.
3. Multi-store requires splitting policies: Different Jushuitan shop_id values map to different Kingdee customers/orgs. Every deployment we have seen creates one policy per store rather than cramming all stores into one rule — this simplifies troubleshooting and differential tax configuration.
4. Separate linked vs unlinked receipts: When a source PO exists, always look up the mapping table for po_id; when none exists, fall back to FBillNo as po_id to avoid target-side validation failures.
5. Pick the right incremental field: For Kingdee, prefer FApproveDate (approval date) over FModifyDate to avoid pulling the same modified record repeatedly; for Jushuitan sales outbound, layer pay_date as a secondary filter.
6. Do not auto-approve or auto-confirm: is_confirm=0 and excute_confirming=false on the Jushuitan side have become industry defaults — write first, then have humans review, which dramatically reduces operational risk.

Pitfall Recap

1. Writing FBillNo into po_id for linked receipts: In linked scenarios, you must use FSRCBillNo to look up the PO; otherwise you will create orphan data where the receipt exists but no matching purchase order can be found. The safe pattern is to look up first, then fall back only when lookup fails.
2. Tax rate not divided by 100: Kingdee's FEntryTaxRate is a percentage (e.g., 13), but Jushuitan expects a decimal (0.13). Passing it through directly doubles amounts — always apply round(x/100,2).
3. Confusing inventory gain/loss field names: FGainQty is gain quantity, FLossQty is loss quantity. Although only one letter differs, they map to completely opposite inbound/outbound directions in Kingdee. Verify field-by-field per policy.
4. Missing shop-to-customer mappings: One project configured only 5 of 21 stores, causing the remaining stores' sales outbound to fail outright. Recommend building the table up front and running a coverage validation script.
5. Kingdee custom fields not modeled first: Custom Kingdee fields such as F_QKMS_XKDDH (tracking number) and F_QKMS_KDGS (carrier) are silently dropped if not modeled in Kingdee beforehand, wasting retry quota.

When to Use

This pattern fits medium-to-large retail or distribution enterprises that run both an e-commerce ERP and a finance ERP and need to bridge master data plus purchase/sales documents. If your inventory and financial accounting live in a single system, or master data originates from only one side, you do not need this bidirectional chain — a unidirectional sync suffices. The handbook also applies directly when spanning multiple organizations, stores, and tax entities.