Purchase Receipt Sync from Weaver OA to Kingdee Cosmic: A Single-Strategy Tutorial on Qeasy
What this strategy solves
In one manufacturing enterprise, the receiving process requires a purchase receipt to first go through approval in Weaver OA-E9, and then be written into Kingdee Cosmic for inventory accounting and financial posting. Both systems must hold the same receipt — it is a hard requirement for a closed-loop supply chain. If the link breaks, the warehouse ledger drifts from physical stock, or finance cannot close the books on time. We used Qeasy (the data integration platform) to carry this strategy: parsing the PDF purchase receipt from Weaver OA into structured fields, then writing it as a purchase receipt in Kingdee Cosmic, so the moment approval completes, inventory updates.
Data flow and field mapping
The pipeline is one-way push: Weaver OA-E9 (source) → Qeasy middleware (parse + map + route) → Kingdee Cosmic (target).
Key field reference:
| Business meaning | Weaver OA-E9 source | Kingdee Cosmic target | Handling notes |
|---|---|---|---|
| Document number | Application number | FBillNo | Keep original value to avoid mismatch |
| Supplier | Supplier name | FSupplierId | Name → code mapping, centralized |
| Receipt date | Business date | FDate | Convert to yyyy-MM-dd |
| Warehouse | Receiving warehouse | FStockId | Warehouse code mapping |
| Material code | Material number | FMaterialId | Consistent with material master strategy |
| Quantity | Received quantity | FQty | Keep two decimals |
| Unit price | Tax-included price | FPrice | Verify tax inclusion |
| Lot number | Lot field | FLot | Mandatory when not empty |
Centralized code mapping is one of the common patterns among Qeasy customers — all supplier, warehouse, and material codes sit in one mapping table, the OA side uses names, the target side uses codes, and the middleware translates everything in one place so nothing is hardcoded in scripts.
How to configure on Qeasy
In the Qeasy console, this strategy is assembled in three segments:
- Source adapter: pick the Weaver OA-E9 HTTP interface, configure authentication and the document query endpoint, restrict the document type to "Purchase Receipt," and pull incrementally by approval time.
- Data cleansing and mapping: perform field renaming, type conversion, and code mapping inside the Qeasy transformer. Header and body are processed in phases — handle the header first, confirm supplier, warehouse, and date are correct, then iterate over body line items. Header failure drops the whole document; body line failure drops only that line and writes a log.
- Target write: call the Kingdee Cosmic purchase receipt save interface. The recommended order is header save, then entry write, then submit. Submission is a separate action so it can be retried independently.
Source-side pull should use pagination plus a time window: 50 records per page, ascending by modification time, to avoid missing or duplicate records.
Implementation steps
We broke the rollout into three scheduling phases:
- Incremental seed: at first go-live, manually trigger one historical document as the "seed" for the pipeline — its purpose is to validate field mapping and interface connectivity. Once the seed document succeeds, enable scheduled runs.
- Full-trigger backfill: when historical volume is small, backfill the last three months in one shot; for large volumes, batch by supplier to avoid congestion on the Kingdee interface. After the full backfill completes, switch to incremental mode.
- Scheduling cadence: in production, run every 15 minutes. States include "success," "failure with retry," and "manual intervention." Use exponential backoff for retries, capped at 30 minutes. Dual-track incremental plus full is another common pattern among Qeasy customers — full handles initial backfill, incremental handles steady-state operations.
Pitfall review
- PDF parsing field mismatch: in Weaver OA's PDF receipt, the positions of "tax-included price" and "tax-excluded price" are easy to mix up. The middleware should validate using the triple (business date + supplier + document number); any ambiguous row goes into the exception queue and is not allowed to post fuzzily.
- Code mapping embedded in scripts: a classic mistake is hardcoding supplier codes inside the transform script, so adding a new supplier requires a code change and release. The safe approach is to lift all code mappings into Qeasy's mapping tables, where business users can also maintain them.
- Document number collision on the Kingdee side: writing the source document number directly into FBillNo causes conflicts when the two sides use different numbering rules. Let Kingdee auto-generate the number on the target side, and put the source document number into a custom field for reverse lookup.
- Submission failure leaves inventory untouched: in Kingdee Cosmic, "save" and "submit" are two separate actions; saving without submitting will not post the inventory ledger. Make sure submission is part of the pipeline, and design retries plus alerting for submission failures.
- Body line partial failures get swallowed: when the header succeeds but a body line fails, rolling back the whole document causes already-successful lines to be retried repeatedly. This is where the phased strategy pays off — handling header and body in separate phases reduces the granularity of failure down to the line level.
When this applies and when it does not
Applies when the source is Weaver OA-E9, the target is Kingdee Cosmic, the document structure is clear, and you need inventory to update immediately after approval. Does not apply when bidirectional sync is required, when source documents are revised frequently, or when the Kingdee side already contains manually adjusted receipts — in those cases, one-way push would overwrite manual edits, so use manual triggers or a reverse validation channel instead.