Syncing Unaudited Other-Outbound Orders from Kingdee Cloud to Jiandaoyun: A Single-Strategy Tutorial

What This Strategy Solves

In the sales-order chain of a retail enterprise, Kingdee Cloud acts as the ERP backbone while Jiandaoyun is the lightweight form platform used by frontline staff. Warehouse operators create large volumes of "other-outbound" stock-out orders daily, but these documents are usually saved in Kingdee in an unaudited state and need to flow to Jiandaoyun's form view as quickly as possible so that business teams can follow up. If we wait until audit is complete, the business side notices too late; if we pull everything in full, scheduling pressure becomes unsustainable.

This strategy addresses "pushing unaudited other-outbound orders to Jiandaoyun incrementally"—ensuring frontline visibility without repeatedly re-sending audited or historical documents. We use the Qeasy Data Integration Platform to host it: one strategy, one direction, incremental-first.

Data Flow and Field Mapping

Data flows: Kingdee Cloud → Qeasy intermediate layer → Jiandaoyun, maintaining a B_TO_A direction throughout.

The source (Kingdee Cloud) uses the executeBillQuery WebAPI, fetching the header and entries by FBillNo (bill number) and FEntity_FEntryID (entry ID), along with FDocumentStatus (document status), FStockOrgId (inventory organization), FDate (business date), and other base fields.

The intermediate layer in Qeasy handles three things: status filtering (only unaudited records pass), code mapping (aligning inventory organization, customer, owner codes with Jiandaoyun-side fields), and splitting/staging header and body records.

The target (Jiandaoyun) calls /api/v2/app/{app_id}/entry/{entry_id}/data_create to write the prepared fields into the corresponding form.

Key field mapping:

How to Configure in Qeasy

In Qeasy this strategy is split into three steps: source query, intermediate processing, and target write.

The source query step uses WebAPI/POST bound to Kingdee Cloud's bill-execute-query endpoint. Add the required fields to the request body and, importantly, put the FDocumentStatus filter either in the query parameters or in an intermediate condition node, so that only unaudited records are pulled.

In the intermediate processing step we like to centralize code mappings: inventory organization, customer, and owner are maintained in a single mapping table that is reused by other strategies. One common pattern among Qeasy customers is centralized code mapping—change once, apply everywhere.

The target write step uses WebAPI/POST to call Jiandaoyun's data-create endpoint, with the body constructed from template variables that reference intermediate-layer fields. Note that Jiandaoyun's field names are in _widget_xxx form—don't try to interpret them; just make sure the variable bindings are correct.

Implementation Steps

We recommend a three-phase scheduling approach.

Phase 1: Incremental starting point. Use "last modified time > last successful sync time" as the incremental condition, and run an initial round to bring all unaudited documents up to the launch moment. In Qeasy this condition is placed in the source query's filter parameters.

Phase 2: Full trigger. On launch day we suggest an additional full pull as a baseline. Qeasy supports manual triggering, combined with the schedule, ensuring no historical unaudited records are missed.

Phase 3: Scheduling frequency. The source crontab is set to */13 6-23 * * *, i.e. every 13 minutes during business hours; the target write interval is */23 6-23 * * *, offset by 10 minutes to prevent the target from writing while the source is still reading, which would cause timing confusion. This source-target offset pattern is something we settled on after several projects.

Lessons Learned

1. Putting status filtering on the target side is a classic mistake. To save effort, someone filters FDocumentStatus on Jiandaoyun after writing—but this leaves dirty data in the form. The safe approach is to filter out non-unaudited records at the source query or intermediate layer.

2. Using only FBillNo as the idempotency key is not enough. A single bill number may contain multiple line entries; modifying one entry changes the overall version. We recommend FBillNo + FEntity_FEntryID as a composite idempotency key—simply enable idCheck in Qeasy.

3. Concurrent source/target writes at the same frequency. 13 minutes and 23 minutes both look "frequent," but if they are fully synchronized, a "source still reading, target already writing" window appears. The 10-minute offset is a stable value derived from real project retrospectives.

4. Jiandaoyun field names are unreadable. Field names like _widget_1688084455750 carry no business semantics—always map via the label, never guess suffixes.

5. Dependencies must be set up front. This strategy depends on master data (materials, customers, suppliers) being synced first (sequence A/B); otherwise the reference fields in the document will be empty. Set up dependent strategies in Qeasy and the scheduler will wait automatically.

Applicable and Non-Applicable Scenarios

Applicable: large document volume, unaudited status must reach the frontline quickly, clear incremental fields available, target system only displays or processes the workflow. Not applicable: when the target system requires strong transactional consistency, when source documents are repeatedly rolled back (audit then un-audit), or when master data has not yet been synchronized.