Other Outbound (Production Requisition) Sync from JKY to Kingdee Cosmic: A Single-Strategy Tutorial

What This Strategy Solves (Scenario & Value)

In a real manufacturing customer's environment, the production floor generates a large volume of "Other Outbound documents (production requisition)" every day. The source side records them in JKY, while the target side needs them in Kingdee Cosmic under the proper inventory organization, so they flow into costing and inventory ledger reconciliation. Without this sync, the two ledgers drift apart, and the cost allocation for production requisition breaks. The goal of this strategy is to push those JKY outbound documents—filtered by a time window—into Kingdee Cosmic in a stable and auditable way.

Data Flow & Field Mapping (Source → Middle Layer → Target)

The flow is straightforward: JKY (source) → Qeasy middle layer → Kingdee Cosmic (target). The source uses a WebAPI query endpoint such as erp.storage.goodsdocout.v2, pulling an incremental time window via startDate / endDate, with pageIndex / pageSize for pagination. The target writes through batchSave against Kingdee Cosmic's outbound document API.

Key field mapping (excerpt, drawn from the provided metadata):

We recommend centralizing code mappings in Qeasy's mapping module so that materials, departments, and warehouses all live in one place rather than being scattered across strategies. This is one of the most common patterns we see among Qeasy customers in the field.

How to Configure It in Qeasy

On-site, we usually configure the strategy around the following points:

1. Source platform connection: register the JKY account (credentials stored in Qeasy's secret vault), set up the request template, bind startDate to {{LAST_SYNC_TIME|datetime}} and endDate to {{CURRENT_TIME|datetime}}—this is the heart of the incremental window.
2. Pagination and deduplication: pageSize at 50 is a common compromise; use goodsdocNo as the idempotency key and enable idCheck in Qeasy's key strategy to prevent duplicate writes.
3. Field mapping: in Qeasy's visual mapper, drag source fields to target fields; constants and fixed values (such as FStockDirect = GENERAL, FBillTypeID = QTCKD93_SYS) go directly on the target side.
4. Target platform write: Kingdee Cosmic uses batchSave; the request body is built per its spec. On failure, Qeasy handles retries and alerts per the strategy configuration.
5. Scheduling and alerts: place the crontab in business off-peak hours (for example, two staggered points at 01:33 and 02:33 in the source material); enable retry and threshold alerts in Qeasy's monitoring panel.

Implementation Steps (Phased Scheduling)

We usually move in three phases:

• Phase 1: Align the incremental baseline. First perform a one-off full backfill of historical data, then anchor "current time" as the future incremental starting point. From there, daily syncs only pull the incremental window, never the full set.
• Phase 2: Incremental trigger and frequency. Configure scheduled jobs (the cron expression in the source material is a good reference). The source side pulls from LAST_SYNC_TIME → CURRENT_TIME; the target side writes one hour later to stagger pressure on both ends.
• Phase 3: Steady-state and reconciliation. Run a "header-then-line phased" strategy pattern in Qeasy: stabilize headers first, then lines, then status fields; if something breaks, roll back the header first to keep the blast radius small.

The "incremental + full backfill dual-track" pattern is very common among Qeasy customers: full load to bootstrap, incremental thereafter.

Pitfalls and Lessons Learned

1. Time drift in the incremental window. A typical mistake is using the source's returned timestamp as LAST_SYNC_TIME when source and Qeasy time zones differ, causing missing or duplicate rows. The safe approach is to anchor the incremental baseline on Qeasy-side time and unify time zones on both ends.
2. Inventory org cannot be mapped. Stuffing FStockOrgId directly from the source's owner name will fail because the two systems use different organization code schemes. You must run code mapping first: source ownerName → target org primary key.
3. Header succeeds, lines fail. Other Outbound has a header + line structure. When batchSave errors out on a line, you can easily end up with a "half-committed" document. Validate the lines in Qeasy before writing, and configure a failure rollback policy.
4. Duplicate writes. Without goodsdocNo as an idempotency key, retries on network blips create duplicate documents. Always enable idCheck in Qeasy and treat the document number as the unique key.
5. Scheduling collision. Source and target strategies running at the same time can trigger rate limiting on either side. Staggering (e.g., source at 01:33, target at 02:33) is the safe option.

Suitable and Unsuitable Scenarios

Suitable: the source emits documents incrementally with a stable time field, the target supports a batchSave-style bulk write, and the business requires document-level traceability and reconciliation. Unsuitable: scenarios where the source has no reliable time field, where the target does not need a formal document, or where near-real-time (second-level) inventory balance sync is required—the latter is better served by a "real-time inventory sync" strategy rather than document-level sync.