From Receiving Notice to Virtual Document: Practical Guide on Syncing External and Transit Warehouses Between Kingdee Cloud and WDT
What This Strategy Solves
When a retail or manufacturing enterprise has its inventory distributed across self-operated warehouses, external warehouses, and transit warehouses, the receiving notices generated upstream in Kingdee Cloud need to be visible to external and transit warehouses in WDT. Direct point-to-point API calls between the two systems typically struggle with code mismatches, missing status fields, and cross-organization coordination. With Qeasy, receiving notices from Kingdee Cloud are aggregated centrally and then pushed as virtual documents to external and transit warehouses, aligning the storage rhythm across all parties.
Data Flow and Field Mapping
The overall flow: Kingdee Cloud (source) → Qeasy middleware layer (aggregation, cleansing, mapping) → WDT virtual document (target, external and transit warehouse scenarios).
Key field mapping (typical illustration, desensitized):
| Business Meaning | Kingdee Cloud (Source) | WDT Virtual Document (Target) | Handling Notes |
|---|---|---|---|
| Document Number | FBillNo | virtual_order_no | Pass through as-is to avoid duplicates |
| Receiving Org | FStockOrgId | warehouse_code | Centralized code mapping |
| Warehouse Type | FStockType | warehouse_kind | Distinguish external / transit |
| Material Code | FMaterialId | sku_code | Centralized code mapping |
| Quantity | FQty | qty | Unit conversion |
| Expected Arrival Date | FExpectRecDate | expect_arrival_time | Timezone and date format |
| Supplier | FSupplierId | supplier_code | Centralized code mapping |
Note: the above reflects common field relationships. Actual field definitions should follow the metadata of both systems in real projects.
How to Configure on Qeasy
On the customer site, we typically set up this strategy as follows:
- Create a data integration task: select Kingdee Cloud as the source system and WDT as the target system, with the strategy type set to document synchronization.
- Configure the source system connection: use Kingdee Cloud's API capabilities (such as the form query interface) to retrieve data by document type
Receiving Notice. It is recommended to enable the incremental field (last modified time) to avoid full-table scans on each run. - Configure the target system connection: use the WDT virtual document write interface and configure target warehouse codes separately for external and transit warehouses.
- Field mapping and code conversion:
- Maintain a centralized code mapping table in Qeasy to map materials, suppliers, and organizations from Kingdee to WDT codes;
- Pass through the header as a whole first, then expand the detail rows through sub-mapping loops;
- Standardize dates and units.
- Null and exception handling: configure unified retry and alerting policies for null source fields, length truncation, and numeric overflow to prevent dirty data from reaching the target side.
- Storage and observability: enable Qeasy's logging and monitoring, integrated with the enterprise's existing alerting channels.
Implementation Steps
We typically follow a phased scheduling approach:
- Phase 1: Incremental Start. Fetch incrementally by last modified time, limiting to a narrow window (e.g., documents changed in the last 7 days) for small-scale verification;
- Phase 2: Full Trigger. Once the incremental flow is stable, schedule a one-time full data backfill to cover historical documents;
- Phase 3: Scheduling Frequency. After go-live, fetch incrementals every 15–30 minutes, avoiding peak business hours. If external/transit warehouses require higher real-time arrival forecasts, the interval can be shortened to 5–10 minutes, but watch out for API rate limits;
- Phase 4: Header / Body Phased Rollout. Stabilize the header first, then gradually enable body details and extended custom fields;
- Phase 5: Monitoring and Rollback. Keep a "log only, no write" gray switch for the first launch, and only enable real writes after verification.
Lessons Learned
- Decentralized code mapping: A typical mistake is to write conversion scripts separately in each task, leading to mismatched numbers three months later. The safe approach is to maintain mappings centrally in Qeasy's mapping center for reuse across strategies.
- Confusing external and transit warehouse types: The source side transmits only one warehouse code, but the target side distinguishes external and transit warehouses as two virtual document types. This is a common pitfall. The safe approach is to clearly distinguish fields at the source side and enforce routing in the mapping.
- Ignoring document status fields: Kingdee receiving notices have statuses such as approved and closed, while the target virtual document only checks whether goods have arrived. Without status synchronization, external warehouses may have signed off while the upstream still shows in-transit. The safe approach is to synchronize status fields together, at least the key states of "approved" and "closed".
- Full sync run too large at once: Pulling all historical documents at once into WDT triggers frequent rate limits on the target side. The safe approach is batch and shard writes, leaving intervals between batches.
- Timezone and date format inconsistencies: The source side provides timestamps with timezones, while the target side only accepts date strings. The safe approach is to standardize formatting in Qeasy to avoid date deviations of one day.
Applicable and Non-applicable Scenarios
Applicable: Retail/manufacturing enterprises with self-operated + external/transit multi-warehouse collaboration that need to synchronize upstream receiving notices as virtual documents to the warehouse management system. Not Applicable: Pure self-operated warehouses, single-organization scenarios, or target systems that do not accept virtual documents and require real document writes; as well as projects with extremely poor source data quality and without master data governance.