Sales Outbound Sync in Practice: A Single-Strategy Tutorial from Jushuitan to Kingdee Cloud
What This Strategy Solves (Scenario & Value)
A multi-store retail enterprise uses Jushuitan for front-end e-commerce order management and Kingdee Cloud as the ERP for downstream finance and inventory accounting. Every day, over a thousand sales outbound documents need to flow between the two systems; manual export is slow and error-prone. This strategy does one thing only: incrementally pull Confirmed outbound orders from Jushuitan by modification time, and push them into Kingdee Cloud as sales outbound documents. The scope is small and the chain is short, but as long as field mapping, shop mapping, and the incremental window are handled properly, half of the supply chain integration is already stable.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The overall flow is Jushuitan → Qeasy Integration Platform → Kingdee Cloud. The middle layer handles field mapping, shop mapping, ID de-duplication, and status filtering; the source and target never talk to each other directly.
| Business Meaning | Jushuitan (Source) | Middle Layer | Kingdee Cloud (Target) |
|---|---|---|---|
| Document Number | io_id | Pass-through | FBillNo |
| Outbound Date | io_date | Standardized date | FDate |
| Document Type | — | Hard-coded constant | FBillTypeID |
| Sales Org | — | Hard-coded constant (per shop) | FSaleOrgId |
| Customer / Shop | shop_id | Translated via mapping table | FCustomerID |
| Document Status | status | Only Confirmed is taken | — |
The shop_id → FCustomerID column is the most valuable table in this strategy. A common Qeasy customer pattern is to centralize the mapping table in the middle layer's "Code Mapping" module: the source outputs raw values, the target only consumes final codes, and adding a new shop means editing one row.
How to Configure It on Qeasy
In the Qeasy console, this strategy is configured as two links: a Source link and a Target link.
Source: API jushuitan.saleout.list.query, method POST. Three parameters are critical—start_time uses {{LAST_SYNC_TIME|datetime}}, end_time uses {{CURRENT_TIME|datetime}}, and status is fixed to Confirmed. Keep page_index and page_size as well: the source returns at most 50 rows per call, so pagination must be looped.
Target: API batchSave, method POST. Header fields like FBillNo, FDate, FCustomerID bind directly to the middle layer's output variables. Base-data fields like FBillTypeID, FSaleOrgId, FSaleDeptID use the "constant + code mapping" dual track in Qeasy: a hard-coded default acts as the fallback, and the mapping table takes precedence when matched.
Scheduling (Crontab): Source is recommended as 1 * * * * (first minute of every hour); target as */20 * * * * (every 20 minutes). The two schedules are staggered so the target does not try to write before the source finishes pulling.
Implementation Steps
In a real project, we usually split the go-live into three phases:
Phase 1: Full backfill, a one-shot history load. Pull start_time back to the business start date and end_time to the day before go-live, then trigger a full run. This step does not rely on crontab; it is run via Qeasy's "Manual Trigger + Task Monitor". After verifying document numbers and amounts on both sides, the scheduled job is enabled.
Phase 2: Align the incremental start point. Qeasy records LAST_SYNC_TIME after each successful run. During the first week after go-live, the window is recommended to be narrowed to 5 minutes for manual comparison to confirm that source-side edits flow through to the target, then widened to hourly.
Phase 3: Steady-state scheduling. Source 1 * * * *, target */20 * * * *, with failure retries and alerting enabled. A common Qeasy customer pattern is the "incremental + full dual track": scheduled jobs handle the increment, while a separate monthly full validation runs in the background to catch any missed records.
Pitfalls Recap
- Hard-coding shop mapping inside a transform script means trouble every time it changes. The reliable approach is to use Qeasy's centralized "Code Mapping" management, so adding a shop only edits the mapping table, never the script.
- Ignoring the semantics of the source's "modification time".
start_time/end_timeis "modification time", not "outbound time". After-sales edits also trigger it, so if the target only inserts but never updates, duplicates appear. KeepidCheckastrueon the target and useio_idas the idempotency key. - Source errors when the time window exceeds 7 days. The Qeasy puller should slice the window into 6-day chunks internally and loop, rather than throwing 7 days at the source in a single call.
- Pushing header and lines together makes failures hard to locate. A common on-site pattern is the "header-then-lines phased" approach: validate header fields first, then handle line items separately, so errors are easier to pinpoint.
page_sizeset to 50 while the source max is 25. This triggers a parameter validation error and wastes an entire scheduled run. After configuration, always use Qeasy's "Test Run" to exhaust pagination at least once.
When It Applies and When It Does Not
Applies: Retail e-commerce front-end in Jushuitan with Kingdee Cloud as ERP, where Confirmed outbound orders need to be pushed to ERP at hourly granularity to form formal outbound and finance documents.
Does not apply: Scenarios that require syncing multiple statuses (pending, pending review, etc.) to ERP; complex business with cross-org transfers or consolidated invoicing; and hybrid-cloud environments where Jushuitan and Kingdee Cloud are not in the same public cloud and require a private line.