Syncing Other Inbound Stock Orders from Wangdiantong to Kingdee Cloud Galaxy: A Single-Strategy Tutorial

What This Strategy Solves

In a retail supply chain, warehouses generate a large number of "Other Inbound Orders" every day — transfers in, inventory gains, initial stock, and so on. These documents originate in the WMS side (Wangdiantong in this case). Finance and the general ledger need every inbound action reflected in the ERP (Kingdee Cloud Galaxy here); otherwise the inventory account and cost calculation both fall short.

The core question this strategy answers: pull the Wangdiantong "Other Inbound Orders" whose status has reached "Audited / Completed" on a fixed schedule, translate them into the format Kingdee Cloud Galaxy accepts, write them in, and guarantee no duplicate document numbers, no wrong statuses, no unreasonable posting dates.

Data Flow and Field Mapping

The pipeline is one-way: source (Wangdiantong) → Qeasy middleware layer → target (Kingdee Cloud Galaxy).

On the source side, the connector calls wdt.wms.stockother.inquery.querywithdetail via POST with pagination params. The key returned fields are business document number other_in_no, status status, warehouse code warehouse_no, posting date, and the detail rows (SKU and quantity). The middleware's job is to translate this payload into a form the target understands.

The target uses Kingdee Cloud Galaxy's batchSave endpoint to write the document. The critical field mapping (only the error-prone ones listed):

Code mappings (warehouse, doc type, supplier, SKU) should not be scattered across transform scripts — a common Qeasy customer pattern is to centralize them in one maintainable lookup table. When a new warehouse opens or a doc type changes, only one place needs editing.

How to Configure in Qeasy

Inside the Qeasy Data Integration Platform, this strategy is modeled as a "source query → transform → target execute" pipeline. Key configuration points:

1. Source connector: Pick the Wangdiantong flagship platform, choose wdt.wms.stockother.inquery.querywithdetail, send params + pager for pagination, and pick a conservative page size (e.g., 50) to avoid triggering source-side rate limits.
2. Status filter: At the middleware layer, only allow status ∈ {20, 40, 60, 70} (Audited / Pushed to WMS / Partially inbound / Completed). Drop 10 (Pending audit) and 80 (Cancelled) to keep downstream clean.
3. Deduplication and idempotency: Use other_in_no as the primary key. Before writing to the target, check whether it already exists; if so, skip or take the update branch — never insert twice.
4. Target connector: Kingdee Cloud Galaxy, batchSave, organize the payload by FBillNo, submit header and detail rows in one call.
5. Exception handling: A single failed row should not kill the whole batch — catch exceptions per row and land the failed other_in_no values into a "manual review" queue.

Implementation Steps

This strategy should go live in stages. Recommended sequence:

Step 1: Incremental kickoff. Start with a time-based incremental pull in the middleware. Anchor the start time to the beginning of a working day (e.g., 00:00:00 of the most recent working day) so that everything from that point forward comes in. Only run incremental at this stage; leave history alone.

Step 2: Full backfill trigger. Once the incremental runs stably, schedule a one-time full historical backfill. Pull in ascending order by document number, throttle via pagination params, and route any failed writes into a fault-tolerant table so the main flow is never blocked. Do not cut over to formal scheduling before the full backfill completes.

Step 3: Scheduling frequency. Source cron is */10 7-22 * * * (every 10 minutes, business hours only). Target write cron is offset by a few minutes (3-59/10 7-22 * * *) so the two ends never compete for the same window. No scheduling at night — let the source do its data housekeeping.

Step 4: Go-live observation. For the first two weeks, manually reconcile daily: are the inbound document counts on the target side consistent with the audited counts on the source side? Inspect the failure queue's root causes until the gap converges.

Lessons from the Field

• Never skip status filtering. At one point we also pushed status=10 (Pending audit), which produced draft documents on the Kingdee side that finance couldn't post. Once we hard-filtered status ≥ 20, the issue disappeared.
• Use modification time, not creation time, for posting date. In business terms, "when did the entry hit the books" aligns with the moment the document actually took effect — modified is far more stable than created.
• Centralize warehouse code mappings. First time around we wrote warehouse mappings into every single strategy; adding one warehouse meant editing fourteen strategies. We eventually consolidated all warehouse, doc-type, and supplier mappings into one table — a very common "centralized code mapping" practice among Qeasy customers.
• Be conservative with the incremental anchor. Picking the anchor a bit earlier (previous-day 00:00:00) lets history be replayed; picking it too late misses data that finance will struggle to recover.
• Throttle pagination aggressively. The source WMS is sensitive to high-frequency pagination. During full backfill, drop page size to 20–50 and add a few hundred milliseconds between pages to avoid source-side throttling.

When to Use and When Not

Use when: WMS and ERP are separate systems, inventory orgs must be accounted on both sides, and document volume is steady at hundreds to thousands per day (typical retail / distribution scenarios).

Don't use when: Real-time stock linkage down to the second is required (use a message queue or database CDC instead of a scheduled pull); or the document needs multi-level approval before hitting the ERP — in that case, trigger only after approval, not by status.