From Weaver OA Production Order Approval to Kingdee Purchase Order: One Sync Strategy in Practice
What This Strategy Solves
In one manufacturing client's flow, the workshop raises a production order in Weaver OA, it goes through approval, and only then does it become a purchase order in Kingdee Cloud Skylink. Earlier this was done by people copying approval numbers by hand — when an OA approval was withdrawn, the two sides drifted out of sync and finance spent two or three days every month reconciling. We used the Qeasy data integration platform to build a single one-way sync strategy: watch the final state of the OA approval node, push approved production orders into Kingdee as purchase orders using a fixed encoding mapping, and let rejections or withdrawals invalidate themselves automatically. It replaces manual entry.
Data Flow and Field Mapping
The end-to-end chain is Weaver OA-E9 (source) → Qeasy middle layer → Kingdee Cloud Skylink (target). The flow direction is A → B.
| Business meaning | Weaver OA-E9 (source) | Qeasy middle layer | Kingdee Cloud Skylink (target) |
|---|---|---|---|
| Document number | workflowNo | flow_id (primary key) | FBillNo |
| Applicant | creater | creator | FApplicant |
| Final approval state | wfStatus | final_status (PASS/REJECT) | only PASS triggers a write |
| Material code | itemNo | item_code | FMaterialId.FNumber |
| Quantity | qty | qty_decimal (unified precision) | FQty |
| Supplier | supplierName | supplier_code (lookup table) | FSupplierId.FNumber |
| Required date | needDate | need_date (YYYY-MM-DD) | FRequireDate |
The supplier-name-to-code mapping is the part that breaks most often. You need a central "supplier mapping table" maintained in Qeasy. Both systems have their own encoding scheme and the middle layer does the translation. Don't scatter the translation logic across every strategy — this is one of the most common patterns we see at client sites: centralized encoding mapping management.
How to Configure It in Qeasy
Sign in to the Qeasy console and create a new "source-system integration flow". On the source side, pick the Weaver OA-E9 Http adapter; on the target side, pick the Kingdee Cloud Skylink adapter. A few key configuration points:
- For the trigger, choose "event trigger" and bind it to the OA approval-ended callback rather than polling. Approvals are low-frequency but strongly real-time — polling is both slow and puts pressure on the database.
- In the Qeasy "field mapping" node, configure the source header and body in two stages: write the header first, take the FID returned by Kingdee, then fill it back into the body. This header-then-body staged write pattern is essentially standard for vendor-type document sync at client sites.
- Add a safety net in the mapping script: if
wfStatusis not PASS, go straight to the termination branch — don't call the Kingdee API and don't leave dirty data behind. - For the exception-handling policy, choose "retry 3 times + alert notification". Don't swallow errors silently.
Implementation Steps
We typically split the strategy's scheduling into three phases:
- Incremental start point: Run a one-off full backfill of historical data, batch-pushing production orders that have already been approved but not yet pushed into Kingdee. In Qeasy, use the "full trigger" button to run this manually once, with pagination parameters to keep each request from getting too large.
- Full reconciliation check: Right after the full backfill, run a reconciliation task that compares OA's PASS final-state documents against Kingdee purchase orders by FBillNo. Only when the difference hits zero do we cut over to live traffic.
- Scheduling cadence: For everyday scheduling, the event trigger is enough — no crontab is needed. In addition, set up a low-traffic nightly reconciliation check that automatically creates a ticket when it finds a difference. This dual-track incremental-and-full pattern is common at client sites running production-class sync: it gives real-time behaviour with an overnight safety net.
Lessons from the Field
- A classic mistake is using the OA document number directly as Kingdee's FBillNo. Kingdee has its own document numbering rules; stuffing the OA number in breaks all later lookups by document number. The safe approach is to use
flow_idas the primary key in the middle layer, let Kingdee generate FBillNo itself, and write that back into the middle layer for reconciliation. - Quantity precision goes wrong. OA is text-type, Kingdee is decimal — if you don't normalize, you get phantom differences like 100.0 vs 100.00. Add a
qty_decimalstep in the middle layer to unify precision. - Forgetting to maintain supplier codes. A new supplier can be submitted in OA, but if the record hasn't been created in Kingdee, the push gets rejected. We recommend adding a "skip and alert if supplier code is missing" branch in the mapping script instead of failing the whole document.
- Approval withdrawals aren't handled. The OA side supports the approver withdrawing, but the withdrawal event doesn't necessarily trigger any reverse action on the Kingdee side. We use a one-way sync strategy: on withdrawal, the corresponding Kingdee purchase order is set to "void" rather than physically deleted, so the audit trail is preserved.
- Time zone and date format. The OA date field can carry hours, minutes, seconds or even a time-zone offset; passing it straight through makes FRequireDate unreliable. The middle layer trims everything to
YYYY-MM-DD.
When to Use This and When Not To
Use it for production/purchase-class document sync where the approval node is well-defined, the final state is clear, both encoding systems are stable, and one-way writes are acceptable. Don't use it when you need bi-directional co-editing, when the approval flow often reverts and you require Kingdee to mirror the withdrawal, or when master data (materials/suppliers) hasn't been aligned between the two systems — for the latter, sync the master data first, then the documents.