Syncing Kingdee Production Requisition to Wangdiantong Other Outbound Order: A Single-Strategy Tutorial

What This Strategy Solves

In a typical manufacturing supply-chain integration, the ERP (Kingdee Cloud) records workshop material requisitions while the e-commerce WMS (Wangdiantong) needs to deduct consignment-warehouse inventory per outbound order. Production requisitions map one-to-one to Wangdiantong's "Other Outbound Order – Production Use," but the two systems use different coding schemes, warehouse types, and field semantics. This strategy pushes production requisitions on a 5-minute incremental schedule so that consignment-warehouse inventory is deducted in real time, avoiding the embarrassing gap where materials have already left the workshop but the warehouse still shows them in stock.

Data Flow and Field Mapping

Data flow: Kingdee Cloud (source) → Qeasy Data Integration Platform (middleware) → Wangdiantong·QiMen (target).

The source side calls Kingdee's executeBillQuery (QUERY type), fetching production requisitions by document number FBillNo and entry ID FEntity_FEntryID. The target side invokes wdt.stockout.order.push (EXECUTE type) on Wangdiantong to write the other outbound order.

Key field mapping:

The middleware layer handles three jobs: code mapping (warehouses, items), unit conversion (base units vs. inventory units), and idempotency control (unique outer_no).

Configuring It in Qeasy

In Qeasy, this strategy has several typical configuration points.

First, the source metadata uses autoFillResponse: true, which lets the platform automatically assemble the request body by FBillNo + FEntity_FEntryID, saving the trouble of hand-writing scripts. idCheck: true prevents re-fetching the same document.

Second, the target outer_no is bound directly to {{FBillNo}}, which is the key to idempotency. A common Qeasy customer pattern is to centralize all cross-system document number mappings into a single "mapping table" for easier rule changes later.

Third, warehouse mapping needs special care: Kingdee's FStockId cannot be dropped directly into the target—it must go through a lightweight lookup that translates it into a Wangdiantong-recognized consignment warehouse warehouse_no. We usually attach a built-in mapping function at the Qeasy "field transformation" node to avoid hard-coding mappings in scripts.

Fourth, buildModel: false means the target request structure is defined directly by the metadata template, and Qeasy validates field types on first run, preventing strings from being stuffed into numeric fields.

Implementation Steps

Roll this out in three phases.

Phase 1: Full-volume trigger, verify mapping. Manually trigger one full-volume run, pushing all production requisitions from the last 7 days. The goal isn't to backfill history—it's to verify field mapping, unit conversion, and warehouse translation. Don't enable scheduling yet; let engineers run it manually.

Phase 2: Set the incremental anchor. In Qeasy's "scheduling anchor," pin FDate to the timestamp when full-volume verification completed. The incremental strategy only fetches records where FDate > anchor AND audit status is "approved," avoiding drafts being pushed.

Phase 3: Enable scheduling frequency. Both source and target metadata declare crontab: */5 * * * *, polling every 5 minutes. Production requisitions are typically entered and approved immediately by shop-floor workers, so a 5-minute granularity is sufficient. But watch Wangdiantong's API QPS limit—a common Qeasy customer pattern is the "dual-track" approach: incremental runs every 5 minutes, while a full-volume job acts as a safety net once daily at dawn to retry failed pushes.

Pitfalls and Lessons Learned

Pitfall 1: Warehouse type mismatch. Wangdiantong's wdt.stockout.order.push requires the warehouse_no's warehouse type to be consignment. If Kingdee issues the requisition against a regular warehouse, the call fails with "warehouse type not supported." The safe approach is to put a warehouse-type validation in front of the mapping layer in Qeasy, routing unsupported documents to an exception channel instead of throwing a hard error.

Pitfall 2: Duplicate outer_no push. If a Kingdee document is modified and re-approved, FBillNo stays the same but entries may be added or deleted. The classic mistake is using outer_no as the idempotency key, causing the target system to reject the entire document. The fix in Qeasy is to concatenate outer_no with the entry primary key FEntity_FEntryID, making idempotency per-line.

Pitfall 3: Unit inconsistency. Kingdee's item base unit might be "piece," while Wangdiantong's inventory unit is "case." The middleware must perform unit conversion, or inventory deduction will be off by an order of magnitude. Recommend maintaining a unit conversion table separately in Qeasy rather than scattering it across strategies.

Pitfall 4: Dependency order. This strategy depends on item master data being synced first (Kingdee items → Wangdiantong goods). If the item code hasn't been created yet when pushing a requisition, Wangdiantong fails to write. In Qeasy we mark the "item sync" strategy as an upstream dependency and force it to run first during orchestration.

Pitfall 5: Draft pollution. Unapproved requisitions being pushed causes phantom inventory deductions. Always add an audit-status filter in the source query conditions. Qeasy's autoFillResponse supports appending filter conditions to the request body.

Suitable and Unsuitable Scenarios

Suitable: Manufacturing enterprises with high-frequency workshop material requisitions (dozens of orders per day or more) that need real-time consignment-warehouse inventory deduction on the e-commerce side; also ERP-to-WMS integrations where document types map strictly one-to-one and field semantics are clear.

Not suitable: Businesses with frequent draft revisions (consider switching to event-driven triggers rather than scheduled polling); or scenarios involving complex approval flows and inter-organization transfers between Kingdee and Wangdiantong, where a single strategy is hard to cover.