Practical Guide: Syncing Kingdee Inventory Write-off to Wangdiantong Subcontract Outbound (Cloud Warehouse)

What This Strategy Solves

In a real supply chain scenario at a retail enterprise, Kingdee Cloud Cosmic serves as the ERP ledger of record, capturing inventory write-off documents after physical stocktaking. Wangdiantong, as the front-end e-commerce fulfillment and cloud warehouse collaboration platform, needs to reflect these write-offs as subcontract outbound orders (cloud warehouse). This synchronizes the deduction of available cloud warehouse stock, generates customer compensation/loss reports, and triggers downstream financial reconciliation.

Each system owns a piece of the truth: Kingdee tracks the "ledger-versus-physical" variance, while Wangdiantong tracks the "fulfillment" variance. If staff manually export write-offs from Kingdee and re-key them into Wangdiantong, missing or wrong entries are inevitable. Three months later, the stock ledgers on both sides won't reconcile, and the financial stocktake will fail. This is precisely why we built this strategy on the Qeasy Data Integration Platform — to align document semantics so both systems post the variance at the same moment.

Data Flow and Field Mapping

The overall flow is Kingdee Cloud Cosmic (source) → Qeasy middle layer → Wangdiantong (target). The middle layer handles code mapping, field conversion, and exception staging.

Key field mapping (only fields that commonly cause issues):

Tip: In real projects, code mapping should never be scattered across scripts. Centralize it in Qeasy's mapping table so a single change applies everywhere.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy falls under "Business Document Sync." Typical configuration points:

1. Datasource registration: Register Kingdee Cloud Cosmic query interfaces (write-off list and detail) and Wangdiantong's subcontract outbound write interface.
2. Strategy canvas: Source fetch → field cleansing → code mapping → target push — four nodes is enough.
3. Code mapping: Maintain Kingdee warehouse IDs and material IDs as Wangdiantong warehouse codes and product codes in Qeasy's mapping table. A common pattern among Qeasy customers is to centralize all cross-system codes into one mapping table, which other strategies can reference directly.
4. Header / body phasing: Write-offs are header + body structures. Push the header first (to validate document legality), then the body line by line. This avoids half-success / half-failure outcomes.
5. Exception handling: Configure retry, alerting (WeCom/DingTalk), and route failed documents into an exception queue for manual re-push.

Implementation Steps

We usually follow three phases: "incremental start point → full trigger → schedule frequency."

• Step 1: Incremental start point. Define the start timestamp (e.g., 00:00 on go-live day). Qeasy continuously pulls new and changed write-offs where FDate > start point. This is the steady state.
• Step 2: Full trigger. The day before go-live, run a full backfill of historical write-offs on the customer site to reconcile pre-launch stock variance. After the full run, the business side must verify "Kingdee write-off amount over the last 90 days vs Wangdiantong subcontract-writeoff amount" before sign-off.
• Step 3: Schedule frequency. Write-offs are low-frequency by nature, so polling every 30 minutes is enough. However, keep a "real-time trigger" toggle — emergency write-offs from in-store stocktakes require minute-level sync to cloud warehouse so it stops shipping against the old quantity.

The dual-track approach (incremental in steady state + full during off-peak for reconciliation) is a common pattern among Qeasy customers.

Lessons Learned from the Field

1. Unit conversion is missing. Kingdee's item master uses "base unit"; Wangdiantong accepts "sales unit." Skipping the conversion causes quantities to differ by a factor. The safe approach is to record conversion coefficients per SKU in the Qeasy mapping table and compute before pushing.
2. Warehouse code is many-to-one. A Kingdee write-off warehouse does not map 1:1 to a Wangdiantong cloud warehouse. In some cases, one Kingdee warehouse corresponds to multiple cloud warehouses. A typical mistake is picking the first warehouse, so all subcontract outbound orders land in the same cloud warehouse. The mapping table should encode the combination "write-off warehouse + owner → cloud warehouse."
3. Deletion / un-approval is not echoed back. When a write-off is un-approved or deleted in Kingdee, without handling, it becomes a "ghost outbound order" in Wangdiantong. Configure "status field monitoring" in Qeasy so that source-side cancellation triggers a reversal or write-back on the target side.
4. First full run times out. The first full run pushes tens of thousands of historical write-offs at once, easily hitting Wangdiantong's rate limit. The safe approach is to batch — 200 per batch with a 1-second interval.
5. No reconciliation view. After go-live, the business side asks, "do both sides match?" Without a daily reconciliation report, the team has to pull numbers ad hoc. Mount a reconciliation view in Qeasy that emits the daily diff between Kingdee write-offs and Wangdiantong subcontract outbounds.

When It Applies and When It Doesn't

Applies: Multi-channel retail with cloud warehouse subcontract fulfillment, where ERP and e-commerce fulfillment systems are separate — especially enterprises that need to synchronize ledger-versus-physical variance to the fulfillment side in real time to deduct stock.

Does not apply: Enterprises with only a single ERP and no cloud warehouse subcontract fulfillment; or scenarios where write-offs are purely financial journal entries and do not deduct cloud warehouse availability — those only need financial module data exchange and should not be pushed to Wangdiantong.