Guanyi Delivery Order to Kingdee Direct Transfer: A Practical Inventory Sync via Qeasy for Luggage Products

What This Strategy Solves

In a supply chain integration project for a luggage retail enterprise, the business side raised a straightforward requirement: the e-commerce front desk generates a large number of delivery orders from Guanyi every day, and these orders represent actual outbound shipments of finished luggage products. However, the financial-side inventory ledger lives in Kingdee Cloud Cosmic, and once there is a time gap between the two systems, inventory data drifts.

We ultimately adopted a single dedicated strategy — aggregating Guanyi delivery orders by luggage product dimension and translating them into Kingdee "direct transfer orders," so that inventory figures remain consistent across both systems using transfer semantics. This strategy focuses only on document semantic conversion, performs no cross-domain aggregation, has a single responsibility, and is easy to troubleshoot.

Data Flow and Field Mapping

The data flow is very direct: source end (Guanyi delivery order) → intermediate mapping layer (field alignment and encoding conversion done in Qeasy) → target end (Kingdee direct transfer order).

The following table shows the key field mapping (desensitized):

Note that the "warehouse" and "SKU" columns are the most error-prone points. In the luggage industry, it is common for the same outbound warehouse to correspond to multiple transfer target warehouses in Kingdee, so we centralize warehouse code mapping in the Qeasy mapping table rather than hard-coding it in scripts.

How to Configure in Qeasy

When configuring this strategy, we followed Qeasy's three-stage "source → mapping → target" structure.

The first stage is source-side access. Qeasy has a built-in Guanyi adapter; you only need to select the "delivery order" business object and pull data using an incremental time window.

The second stage is the mapping layer, which is the easiest place to lose control. In Qeasy's "field mapping" module, we centrally maintained three types of rules: one-to-one field pass-through, unit conversion, and code mapping. Code mapping uses a header/body separation strategy — the header handles fields like warehouse, customer, and currency that have few semantics but high impact; the body only cares about SKU, batch, and quantity. The benefit of this separation is that when SKUs are updated frequently, only the body mapping needs to be refreshed, without risking the header.

The third stage is target-side write, which calls Kingdee Cloud Cosmic's direct transfer order save interface. There is a detail here: after Kingdee's "direct transfer order" is saved, it triggers its own internal inventory update, so in the Qeasy strategy, we treat "target-side acknowledgment success" as the success criterion for the entire strategy, rather than source-side pull success.

Implementation Steps

We divided the rollout of this strategy into three phases, each with clear exit criteria.

Phase 1: Full baseline. Before the strategy goes live, run a "full backfill" in Qeasy to translate the historical N days of delivery orders into direct transfer orders in one pass, and verify whether inventory matches on both sides. This step is the baseline; all subsequent increments are aligned to it.

Phase 2: Confirm incremental starting point. Increments do not start from the moment of go-live; they start from "the last full-document timestamp + 1 second." We use the "time-window cursor" field in Qeasy to record this cursor, avoiding duplicates or missing records.

Phase 3: Scheduling frequency and dual-track operation. The schedule uses "high-frequency incremental + low-frequency full reconciliation" dual-track: the high-frequency incremental runs every 10 minutes, syncing only newly added or changed delivery orders; the full reconciliation runs once a day in the early morning for inventory check, triggering an alert if the discrepancy exceeds the threshold. This pattern is very common in Qeasy customer inventory sync scenarios.

Pitfall Review

Finally, here are several lessons learned in practice, as a heads-up for everyone:

1. A typical mistake is treating the Guanyi delivery order's "outbound warehouse" directly as Kingdee's "transfer-out warehouse." In luggage business, e-commerce outbound warehouses are often virtual or transit warehouses, while Kingdee requires mapping to physical warehouses. If this layer of mapping is missed, errors are inevitable.

2. Do not convert units by changing only quantity without changing the base unit. When converting pieces to boxes, if only the quantity is modified but the base unit field is not, the conversion rate in Kingdee will be messed up, causing inventory decimals. The safe approach is to modify the "quantity + base unit + conversion rate" trio simultaneously in the mapping layer.

3. Never use string comparison for time fields. Guanyi's delivery time sometimes has timezone drift, while Kingdee's side is pure date. If you do string comparison directly in Qeasy, you will encounter issues like "not synced yesterday, duplicates appear once backfilled today." We uniformly normalize the time to UTC+8 in the mapping layer before passing it through.

4. Dependency order must be explicit. This strategy itself has no pre-dependencies, but in production environments, if there is an upstream "delivery order review" process, remember to use the review status as a filter condition in Qeasy, and do not push draft documents over.

5. Be sure to test breakpoint recovery. Qeasy's cursor mechanism guarantees breakpoint recovery, but only if the source interface supports pagination by time window. Before the first go-live, we manually interrupted twice to verify that recovery would not produce duplicate documents.

Applicable and Inapplicable Scenarios

Applicable scenarios: Retail or distribution enterprises where e-commerce front desk and ERP back office inventory are inconsistent, near-real-time inventory sync needs to be triggered by delivery/outbound events, and the business allows aligning both sides' figures using "transfer semantics."

Inapplicable scenarios: Cross-organization transfers involving multiple accounting systems that require voucher or entry generation on the Kingdee side; and complex chains where delivery orders are tightly coupled with sales orders and require order matching before generating transfers. The latter is better handled by splitting into two collaborating strategies.