Chengdu Temporary Storage Make-to-Order: Sync Practice from JikuCloud Outbound Documents to Kingdee Cloud Stellar Sales Return Documents

What This Strategy Solves

A retail enterprise runs regional temporary storage warehouses across multiple locations. Once frontend sales orders trigger outbound operations in JikuCloud, the outbound facts from the "Chengdu temporary storage warehouse" need to flow back into Kingdee Cloud Stellar so that headquarters can see real shipping rhythm in time, and use it to drive purchase replenishment and inter-org settlement. This strategy incrementally extracts JikuCloud outbound documents by time window and writes them into Kingdee Cloud Stellar as sales return documents, serving as the carrier voucher for real outbound facts in the "make-to-order" chain.

Data Flow and Field Mapping

The overall flow is "JikuCloud (source) → Qeasy middleware → Kingdee Cloud Stellar (target)". The source pulls outbound documents incrementally via the WebAPI erp.storage.goodsdocout.v2, while the target writes sales return documents through batchSave.

Key field mapping:

The middleware mainly handles three things: paged fetching, field mapping, normalization of org and owner codes, and idempotent deduplication.

How to Configure on Qeasy

We use the Qeasy data integration platform to deliver this pipeline on customer sites. Below are the typical configuration essentials.

1. Source connector: Register the JikuCloud WebAPI connector, pick API erp.storage.goodsdocout.v2, method POST, effect QUERY. Start with pageSize of 50 for connectivity validation, then increase after stability is confirmed.
2. Incremental window: Use {{LAST_SYNC_TIME|datetime}} for startDate and {{CURRENT_TIME|datetime}} for endDate. This is the standard Qeasy pattern for the "incremental plus full-load dual-track" mode.
3. Middleware processing: Centralize code mapping (customer, owner, org, document type) inside the Qeasy transformer instead of scattering it across tasks. Handle header and body in phases—write the header first to obtain the target document number, then backfill the body in batches to reduce field-length risk on batchSave.
4. Target write: Use the Kingdee Cloud Stellar batchSave interface with document type XSTHD01_SYS, sales org I0101, stock org derived from the source owner name mapping, and date from inOutMonth.
5. Scheduling and dependency: Source crontab is set to 3 2 * * *, target to 23 2 * * *, leaving the middleware enough window for transformation and reconciliation.

Implementation Steps

We usually split the project into three phases, each with clear regression cases.

Phase 1: Define the incremental starting point For the first go-live, decide from which timestamp increments should start. A safe approach is to run a cold-start full load that pushes historical outbound documents in date-based batches as the baseline, and only then switch to the LAST_SYNC_TIME incremental window. A common mistake is using "current time minus 24 hours" as the starting point, which causes historical documents to be missed.

Phase 2: Trigger the full load During full load, split windows (e.g., by day) to avoid oversized batchSave batches being rejected by the target. Enable Qeasy failure retry and manual fallback so that differences can be reconciled.

Phase 3: Stable scheduling In steady state, the source pulls at 02:03 daily and the target writes at 02:23. For cross-day documents (created at 23:xx, persisted the next day at 00:xx), add a "wide-window merge" in the middleware instead of a simple calendar-day split.

Lessons Learned

• Mapping drift from owner name to stock org: JikuCloud carries the owner as "name", while Kingdee Cloud Stellar expects "org code". The most common pitfall is going live before base data is aligned on both sides, which leaves FStockOrgId empty and causes the target to reject entire documents. A reliable practice is to centralize code mapping in Qeasy, run a reconciliation pass, and only then go live.
• Narrow incremental window drops documents: If the source schedules later than the target write and the window is split by calendar day, cross-day documents can fall outside both windows. The middleware must keep both "wide window" and "deduplication" gates.
• Semantic mismatch in document type: The source is an "outbound document" while the target is written as a "sales return document". These are not the same semantics. Business must clarify: this pipeline carries "outbound facts flow-back", not real returns. So XSTHD01_SYS is a technical carrier voucher and must be aligned in business terminology.
• Page mis-alignment after enlarging pageSize: Whenever the source paging parameter changes, the middleware must preserve pageIndex continuity; otherwise the "next page" may still return data from the previous window.
• Missing idempotency key causes duplicate documents: The target id must come from the source goodsdocNo, not from target-side auto-increment; otherwise a rerun produces duplicate sales return documents.

Applicable and Non-applicable Scenarios

Applicable: Multi-org temporary storage, make-to-order, and scenarios where outbound facts need to flow back into the ERP as purchase/settlement driver vouchers; private deployments with JikuCloud as source and Kingdee Cloud Stellar as target.

Non-applicable: Scenarios that demand real-time ATP (Available-to-Promise) inventory—this strategy's daily window is insufficient. Also not applicable in early stages where owner/org base data has not yet been aligned across both sides.