Syncing Kingdee Receipt Notices to Wangdiantong Purchase Warehousing: A Transit-Warehouse Configuration Playbook
What This Strategy Solves
A retail customer runs Kingdee Cloud Starry Sky for finance and supply-chain ledger while using Wangdiantong for store and e-commerce fulfillment. The two systems disagree on what "goods arriving in the warehouse" means: Kingdee treats the receipt notice as the entry for inspection and payables, while Wangdiantong expects the purchase warehousing document to drive inventory and put-away directly.
Manual double entry causes three pain points: quantity drift between received and put-away quantities, broken document-number linkage that prevents audit lookup, and overnight delays that miss same-day posting. We built this pipeline on the Qeasy Data Integration Platform so that Kingdee receipt notices generate Wangdiantong purchase warehousing documents under transit-warehouse rules — one entry, two systems updated.
Data Flow and Field Mapping
The flow is: Kingdee Cloud Starry Sky (Receipt Notice) → Qeasy Middle Layer → Wangdiantong (Purchase Warehousing Document). The defining feature of the transit-warehouse pattern is that warehouse codes must be landed in the middle layer rather than simply passed through.
Key field mapping (simplified; project-specific values depend on the customer's master data):
| Business Meaning | Kingdee Source Field | Wangdiantong Target Field | Handling Notes |
|---|---|---|---|
| Document Number | FBillNo | external_no | Preserve source number as external ref for reverse lookup |
| Receipt Date | FDate | order_time | Normalize timezone to UTC+8 date |
| Supplier Code | FSupplierId.FNumber | provider_code | Resolve via supplier master in middle layer |
| Warehouse Code | FStockId.FNumber | warehouse_code | Core field of transit-warehouse mapping |
| Material Code | FMaterialId.FNumber | sku_code | Centralized mapping; changes touch one place |
| Quantity | FQty | num | Unit conversion lives in middle-layer script |
| Batch Number | FLot.FNumber | batch_no | Strict non-null check when batches are enabled |
| Remarks | FNote | remark | Pass through; truncate to target field length |
Worth highlighting: centralized code mapping is the common pattern on Qeasy for these projects. Material, supplier, and warehouse master mappings live in a single lookup maintained in the platform's Data Center, so future changes do not scatter across dozens of strategies.
Configuring on the Qeasy Platform
This strategy is orchestrated as a three-stage pipeline on the Qeasy Data Integration Platform:
- Source: Pull Kingdee receipt notices via modification-time incremental fetch. On initial sync, backfill N days as the baseline.
- Middle layer: Field mapping, unit conversion, and transit-warehouse landing happen in Qeasy's transformer. The code-mapping table is centrally maintained in the Data Center component.
- Target: Write to the Wangdiantong purchase warehousing document API. Header and body are pushed in two stages — the header lands first, then body lines are submitted in batches to reduce rollback cost on partial failures.
Typical configuration points:
- Incremental start point: Before the first run, manually pick a "historical backfill cutoff date" to avoid pulling years of history and skewing initial inventory in the target.
- Transit-warehouse identifier: Add a
warehouse_type = TRANSITbranch in the mapping script so only transit-warehouse receipts are pushed here; formal-warehouse receipts follow a separate strategy to avoid mixed flows. - Failure retry: Failed lines are visible in Qeasy run logs and usually resolve on retry. However, if three consecutive retries fail, route the record to a manual handling queue instead of looping forever and flooding the log.
Implementation Steps
Staged scheduling is the safe approach for purchase document sync:
- Stage 1: Incremental start point. Configure a scheduled task in Qeasy; on first run, backfill one accounting period (for example, the last 90 days) as the initial baseline. Immediately after baseline completion, switch to modification-time incremental mode at a 15-minute cadence — timely enough without overloading the source system.
- Stage 2: Full-volume trigger. If the customer requires a daily consistency check, schedule the full job into the early-morning low-traffic window and run it mutually exclusive with the incremental task to avoid table locks.
- Stage 3: Scheduling cadence. Recommend the incremental-plus-full dual-track pattern: incremental ensures freshness, full ensures consistency. A common operational pattern on Qeasy is header-then-body staging — header failures abort, body failures only affect that line, which simplifies troubleshooting.
For this specific strategy: trigger a full sync at 06:00 daily and an incremental sync every 15 minutes during business hours. Each run logs success count, failure count, and duration in Qeasy, which feeds directly into weekly reports.
Lessons Learned
These are the high-frequency issues we have reviewed on customer sites:
- Transit and formal warehouses mixed up. A common shortcut is to write the warehouse mapping as "pass the source warehouse through unchanged," which causes transit-warehouse receipts to land in formal warehouses and leaves both sides out of balance within three months. The safe approach is an explicit branch in the script that routes by warehouse type.
- Unit conversion buried in field mapping. If a material has box-and-piece dual units, hardcoding conversion inside the field map forces you to revisit dozens of strategies later. Centralize conversion factors in the Data Center and have field mappings only reference them.
- Wrong incremental start time. Setting the first sync start to "the day the system went live" silently drops all pre-existing receipt notices and leaves the target inventory short. The safe approach is to backfill one full financial period before the live date.
- Unbounded retry on transient failures. The target API occasionally times out; infinite auto-retry floods the run log and hides the real anomalies. Set a maximum retry count and an alert threshold directly in the Qeasy strategy configuration.
- Missing non-null check on batch field. When batch management is enabled, source documents without a batch number get pushed through and create dirty "no-batch" receiving records on the target. Validate in the middle layer rather than leaving it to the target system to error out.
When to Use and When Not to Use
Use it when: Kingdee owns the supply-chain ledger and Wangdiantong handles store fulfillment, transit-warehouse inbound needs to be linked, and master data has already been aligned on both sides.
Do not use it when: real-time expectation is below five minutes (consider a message-queue direct push instead); the source is a formal-warehouse direct receipt (use the "Kingdee → Wangdiantong formal warehouse" strategy instead, do not mix into this one); master data is still unaligned during a transition period (fix master data governance first, then sync documents).