Practical Tutorial: Syncing Sales Outbound Orders from Jushuitan to Kingdee Cloud (Non-Qimen, Pinduoduo Channel)
What This Strategy Solves (Scenario and Value)
In one of our retail client engagements, we ran into a very typical pain point: Jushuitan acts as the front-end e-commerce ERP, handling orders and shipments for channels like Pinduoduo, while Kingdee Cloud serves as the back-end financial and supply chain system that needs first-hand outbound documents for cost accounting and receivable confirmation. The two systems run independently, and if you rely on manual export/import, the numbers will inevitably drift after three months. The goal of this strategy is straightforward—push Jushuitan's sales outbound orders (non-Qimen channel, Pinduoduo) to Kingdee Cloud according to an agreed schema, so that shipments are immediately recorded and inventory is reconciled daily.
Data Flow and Field Mapping
The overall flow is: Jushuitan (source) → Qeasy middleware layer → Kingdee Cloud (target). The middleware layer carries no business logic—its job is field alignment, code mapping, and exception staging.
| Business meaning | Jushuitan (source field) | Kingdee Cloud (target field) | Handling notes |
|---|---|---|---|
| Document number | io_id / io_no | FBillNo | Prefer source document number; validate uniqueness on target |
| Store / channel | shop_id (Pinduoduo shop) | FHeadEntity_FFieldName (channel custom field) | Centralize code mapping; do not hardcode in scripts |
| Warehouse | warehouse_id | FStockOrgId / FStockId | Two-level mapping: source warehouse → target org + warehouse |
| Material code | sku_id | FMaterialId | Depends heavily on the upstream material sync strategy; otherwise rows are lost |
| Quantity | qty | FQty | Perform unit conversion once in the middleware layer |
| Outbound date | io_date | FDate | Normalize time zone and date format centrally |
| Remark / buyer info | remark / buyer_memo | FNote | Define an overflow truncation policy in advance |
The reliable approach is to centralize all code mappings in Qeasy's mapping tables, so that business changes only need to be made in one place.
How to Configure on Qeasy
We use the Qeasy Data Integration Platform to carry this integration on the client site. There are four key configuration areas:
- Data source connectivity: On the Jushuitan side, we use the open API for outbound order queries; on the Kingdee Cloud side, we write through the standard API. All connection information is stored in Qeasy's Connection Management—no secrets are embedded in business scripts.
- Field mapping and transformers: Complete the mapping described above in Qeasy's mapping canvas. For two-level mappings such as store → channel and warehouse → org+warehouse, use "Lookup Table" transformers rather than custom functions.
- Exception handling: Qeasy provides an "exception staging" area and a "retry queue." Documents dropped due to network jitter are persisted, and engineers can inspect the details directly in the UI—no more digging through logs.
- Logging and reconciliation: Each document carries a trace id through fetch, transform, and write stages. Cross-system reconciliation becomes a simple trace lookup, which is an order of magnitude faster than Excel-based reconciliation.
Implementation Steps (Phased Scheduling)
We usually split this sync into three phases:
- Phase 1: Incremental baseline. On go-live day, run a full backfill of historical outbound orders (the range is agreed with the business, e.g., the last 90 days) as a baseline. The incremental cursor is set to "max successful io_date + 1 second" and is persisted by Qeasy, so it survives instance restarts.
- Phase 2: Full reload trigger. Once incremental is stable, the business often asks for a full reload over a specific window, e.g., suspected data loss during a promotion. This dual-track (incremental + full reload) pattern is supported by Qeasy through two independent strategy instances, so they don't pollute each other's watermarks.
- Phase 3: Scheduling frequency. Sales outbound orders are time-sensitive, so we usually schedule every 5 minutes; during low-traffic nights, we drop to every 15 minutes. Qeasy supports different intervals per time window—do not hardcode a single value.
Pitfalls and Lessons Learned
- Upstream dependencies ignored. Sales outbound documents contain material codes, but if the materials haven't been created on the Kingdee side yet, the entire outbound document fails. The safe approach is to decouple the material sync strategy from the outbound sync strategy, but add a "material existence check" on the outbound side and route failures into the exception queue rather than silently dropping them.
- Code mappings scattered across scripts. During one root-cause analysis, we found channel code mappings hardcoded in three different scripts—fixing A but not B caused mismatches. We later centralized all code mappings in Qeasy mapping tables and put changes through a review process.
- Mixed time zones and date formats. Jushuitan defaults to time-zone-aware timestamps, Kingdee does not—cross-day documents get assigned to the wrong date. Forcing normalization to a single "business date" in the middleware layer is mandatory; relying on either side to convert is a typical mistake.
- Full reload overwriting the incremental watermark. This is a common trap—a promotional-period full reload overwrote the incremental cursor, and subsequent incremental runs missed data. Qeasy's independent watermark feature prevents this, but engineers must explicitly distinguish the two strategy instances during configuration.
- Unbounded retries. When the target system rate-limits, infinite retries can saturate the queue. We recommend configuring the Qeasy retry queue with a max retry count and backoff policy, escalating to manual handling after exhaustion.
Applicable and Non-Applicable Scenarios
Applicable: Retail or distribution companies using Jushuitan as the e-commerce front-end and Kingdee Cloud as the back-end finance/supply chain system, requiring channel-level (here, Pinduoduo) accounting and inventory linkage. Not applicable: outbound orders going through the Qimen channel should use the corresponding channel strategy; pure offline store outbound and inter-org transfer scenarios require their own dedicated strategy templates.