Purchase Order Sync from Weaver OA to Kingdee Cosmos: A Practical Integration Approach with Qeasy

What This Strategy Solves

In a manufacturing enterprise, procurement approvals run on Weaver OA-E9 while warehousing and financial accounting run on Kingdee Cosmos. After a buyer completes approval in OA, the purchase order needs to be pushed to Kingdee Cosmos to generate a purchase receipt—only then can the warehouse receive goods and post the voucher. It looks like a simple document sync, but code mapping, field semantics, and document status often fail to align between the two systems, leading to mismatched numbers, duplicate receipts, and incorrect amounts. This solution uses the Qeasy Data Integration Platform to bridge this cross-system purchase order sync flow, connecting "OA approval → Kingdee receipt" end to end.

Data Flow and Field Mapping

The overall flow is a one-way push: Weaver OA-E9 (source) → Qeasy middle layer → Kingdee Cosmos (target). The middle layer does not persist business data itself; it only cleans, maps, enriches, and packages.

Code mapping (supplier, material, warehouse) is the most failure-prone area in this solution. The common Qeasy pattern is centralized code mapping management: all mapping relationships are stored in a single mapping table, source-to-target code conversion is centralized in the middle layer, and ongoing maintenance only touches the mapping table—not the main flow.

How to Configure on Qeasy

In Qeasy, a strategy is an "integration flow" composed of three segments: source capture, middle-layer mapping, and target write.

Source capture: Connect to the Weaver OA-E9 Http interface. The filter condition is "Approval Status = Approved AND Business Type = Purchase Order"—only approved documents are pulled, avoiding drafts and in-progress approvals being pushed downstream.

Middle-layer mapping: This is the critical segment. Qeasy supports visual field mapping where the relationships in the table above are dragged and dropped one by one. Logic that needs to be handled in the middle layer includes: supplier code enrichment, material code enrichment, tax-inclusive/exclusive separation, amount rounding to two decimals, and remarks concatenation with the flow number.

Target write: Call the Kingdee Cosmos purchase receipt save interface. The recommended approach is to first call the "save as draft" interface for document creation, then call the "submit" interface for status progression. This keeps rollback cost low on write failure.

Scheduling configuration: The incremental strategy uses crontab for periodic pulling; the full reconciliation strategy is configured separately and triggered manually or during off-peak hours.

Implementation Steps

This solution is typically rolled out in three phases.

Phase 1: Determine the incremental start point. First, anchor the incremental start timestamp—only sync documents created after go-live to avoid historical data flooding in. The typical Qeasy practice is to anchor the start time at a specific day at 00:00, pulling only OA records with "Modified Time > Start Point".

Phase 2: Full-volume trigger. On go-live night or during a weekend off-peak window, run a full-volume job once to backfill any historical purchase orders not yet synced. Immediately switch to incremental mode after the full job completes to avoid duplication. Running incremental and full-volume in parallel is a common Qeasy customer pattern: full-volume for baseline alignment, incremental for daily sync. The two logics are configured independently and never mixed into one flow.

Phase 3: Scheduling frequency and monitoring. Daily scheduling is typically set to every 15 minutes or hourly, adjusted based on business volume. Configure exception alerts and failure retries in Qeasy: network jitter causing write failures triggers automatic retry up to 3 times; validation failures (such as missing supplier code) trigger alerts to operations for manual intervention.

Pitfall Review

1. Supplier/material code mapping not centrally managed. A typical mistake is embedding mapping logic inside transformation scripts scattered across multiple flows. New team members cannot find the corresponding relationships and fix one place while forgetting others. The safe practice is centralized code mapping management—all mapping tables are maintained uniformly, and the source side only does field pass-through.

2. Header and line items synced together causing partial failure. Header and lines stuffed into one interface call—any single line validation failure rolls back the entire document. The safe practice is staged header and line processing: write the header first, and on success, batch-write the line items. Failures only roll back the line-item segment.

3. Inconsistent tax-inclusive/exclusive separation conventions. OA stores tax-inclusive unit price, but Kingdee receipts require both tax-inclusive and tax-exclusive fields. Tax separation must be performed explicitly in the middle layer—do not rely on the target system to auto-convert, otherwise numbers will not match when tax rates differ.

4. Missing duplicate protection. The same OA request number pushed repeatedly causes multiple receipts in Kingdee. The safe practice is to add an idempotency key in the middle layer, using the OA document number as a unique identifier—if the target already has it, skip or update.

5. Mixing full-volume and incremental runs causes duplicates. The full-volume strategy does not disable the incremental trigger, so historical data is backfilled while incremental runs simultaneously, producing duplicate receipts. The safe practice is to separate full-volume and incremental strategies—manually switch after the full job completes, or use a status field for deduplication.

Applicable and Non-Applicable Scenarios

Applicable: Small-to-mid manufacturing/retail enterprises where OA handles procurement approval and ERP handles inbound receiving and accounting, requiring approved purchase orders to be automatically pushed to ERP for receipt generation. Not applicable: Scenarios where OA and ERP have already been merged into one system, or where procurement is fully closed-loop within ERP. Also not applicable for bidirectional sync scenarios (such as writing received quantities back to OA)—those require a separate return flow design.