Practical Tutorial: Syncing Panwei OA Purchase Order Approval to Kingdee Cloud Cosmos

What This Strategy Solves

In many enterprises, purchase order approvals happen in Panwei OA, but actual order execution—receiving, invoicing, and payment—lives in Kingdee Cloud Cosmos. A common scenario we have seen: after an approver clicks "Approved" in OA, the buyer still has to manually re-enter the order header, line details, prices, and quantities into Kingdee. Small mistakes cause mismatched quantities or misaligned vendor records between the two systems. This strategy addresses exactly that: once an order is approved, it is automatically written into Kingdee Cloud Cosmos with header and line items landing together in one pass, removing the dependency on manual re-entry.

Data Flow and Field Mapping

The overall flow is: source system (Panwei OA) → middleware layer (Qeasy data integration platform) → target system (Kingdee Cloud Cosmos).

A few fields are often overlooked but critical: delivery date, receiving organization, payment terms, and currency. In the OA approval flow these are often secondary, but in Kingdee they directly affect receiving and settlement. Map them explicitly—do not leave them blank by default.

How to Configure on Qeasy

On customer sites, we typically recommend a three-stage setup in the Qeasy data integration platform: source resource library → target resource library → strategy orchestration.

1. Source resource library: Connect to Panwei OA-E9 HTTP interfaces to fetch approved purchase orders. The common practice is to trigger on the approval-flow end node rather than polling on a timer, which reduces empty runs.
2. Target resource library: Connect to Kingdee Cloud Cosmos's purchase order save interface. Validate in a test ledger first.
3. Strategy orchestration: This is where things tend to go wrong. Typical configuration includes: centralized code mapping (vendors and materials maintained in one mapping table and reused across strategies), header/body phased writing (header first, then lines written in a loop by line number), and field cleansing (trim spaces, unify date formats, normalize tax categories).

One thing that saves effort on Qeasy: code mappings and field transformation rules can all be centralized in the "Mapping Center," and new strategies can reuse old mappings. This avoids each strategy having its own rule set that becomes unreadable months later.

Implementation Steps

We usually split rollout into three phases rather than a "big bang" full launch:

• Phase 1: Align the incremental starting point. Agree with business on a clear start time (for example, "only orders approved after midnight today are synced"). Leave historical orders to manual reconciliation between OA and Kingdee; do not mix historical data into the first wave.
• Phase 2: Enable the full-trigger switch. After incremental runs stably for one to two weeks, enable full triggering, but only for "approved orders not yet in Kingdee." Once catch-up completes, immediately turn off the full-trigger switch and return to incremental-only. This is the common "incremental and full dual-track" pattern.
• Phase 3: Converge the schedule frequency. Early on, schedules may run every few minutes as a safety net. Once stable, switch to "OA approval end-node trigger + failure retry compensation." Qeasy supports automatic retry on failure, so compensation strategies do not need custom scripts.

There is no standard answer for schedule frequency, but one rule of thumb: do not rely on high-frequency polling to mask business-side latency. Trigger-based is more resource-efficient and closer to actual business reality than polling-based.

Lessons Learned from the Field

1. Code mappings not centralized, mismatches appear after three months. A typical mistake is each strategy maintaining its own vendor and material mapping table. Someone updates Strategy A's table but Strategy B still references the old values. The safe practice is to maintain mappings centrally in Qeasy's Mapping Center and share them across all related strategies.
2. Header written but body failed, creating "header without body" dirty records. This often happens when a line item error occurs during looped body insertion, but the header has already landed. The safe practice is to make header and body transactional, or at least roll back the header when body insertion fails. On Qeasy, this can be avoided by writing to an intermediate staging table first, then submitting as a whole.
3. Units and tax categories not unified, quantities match but amounts do not. For example, OA uses "case" while Kingdee uses "piece"; an approved quantity of 10 becomes 10 pieces after landing, immediately inflating the amount. The safe practice is to enforce unit conversion in the field-cleansing stage and align tax category and rate with Kingdee before writing.
4. Rejected and withdrawn orders also get pushed. The root cause is treating the "approval status" field as the filter but the frontend sends the last node's "agree" rather than the entire flow's final conclusion. The safe practice is to take the final status after the whole flow completes, not any node's local status.
5. Failure retry has no upper bound, leading to "ghost retries." An order has already landed successfully in Kingdee, but because of an intermittent interface timeout, Qeasy retries and creates a duplicate. The safe practice is to enable idempotency checks by document number—before retrying, query Kingdee to see if the document already exists.

Suitable and Unsuitable Scenarios

Suitable: Enterprises whose purchase approval is in Panwei OA and execution is in Kingdee Cloud Cosmos; daily approved order volume ranging from tens to low thousands; clear vendor and material master data.

Not suitable: Cases where the approval flow still needs long-term tracking in OA (in that case, only write back status; do not push the entire order); and cases where vendor or material master data has not yet been set up in Kingdee. In the latter, run the master data sync strategy first, then the order sync strategy.