Vendor Master Modification Sync in Practice: Closing the ID Change Loop from Weaver OA to Kingdee Cloud
What This Strategy Solves
Vendors get updated in the OA, but Kingdee still shows the old version—this is the classic "two sources of truth" problem in private supply chain integration. In one manufacturer's project, procurement submitted a vendor rename or qualification update in Weaver OA, but the change never made it to Kingdee Cloud on time. Subsequent purchase orders and AP settlements kept using the old code, and the discrepancy only surfaced during reconciliation three weeks later. This strategy focuses on pushing vendor modifications from Weaver OA one-way to Kingdee Cloud, consolidating master data maintenance into a single system.
Data Flow and Field Mapping
The data flow is straightforward: Weaver OA-E9Http (vendor modification event) → Qeasy middle layer (field mapping, rule validation) → Kingdee Cloud (vendor profile update).
Key field mapping:
| Business Meaning | Weaver OA Source | Middle Layer | Kingdee Target | Notes |
|---|---|---|---|---|
| Vendor Code | vendor_code | Pass-through, match key | FNumber | Key reference for ID changes |
| Vendor Name | vendor_name | Trim, remove full-width spaces | FName | Mind multi-language scenarios |
| Unified Social Credit Code | uscc | Checksum validation | FTaxRegisterCode | 18-digit length check |
| Contact / Phone | contact/tel | Concatenate then write | FContact/FPhone | Concatenate cautiously |
| Status | status | Active=1, Inactive=0 | FUsed | Inactive needs related cleanup |
| Qualification Attachment | attachments | Cache, write back on demand | FAttachment | Large object, async handling |
The Qeasy middle layer handles three things: centralized code mapping, field-level transformation rules, and secondary confirmation for inactive vendors.
How to Configure in Qeasy
In our on-site work, the typical configuration for this strategy splits into four pieces:
- Source Trigger: Pull incremental updates from the vendor modification event exposed by Weaver OA-E9Http over HTTP. Recommend a timestamp cursor (
lastModifiedTime) combined with the business primary key to avoid missed records. - Middle Layer Mapping: Maintain a code mapping table in the Qeasy data integration platform, centrally storing OA code → Kingdee code correspondences. Change the mapping without touching the logic—keeps cleanup controllable later.
- Target Write: Use Kingdee Cloud's save interface to update the vendor profile. Match precisely on FNumber first; only fall back to create on no match. In practice, 90% are update scenarios.
- Exception Handling: In Qeasy's alerting channel, classify failed records by error code—field length overflow goes to manual, network timeouts auto-retry three times, unmapped codes go directly to the pending queue.
Implementation Steps
We recommend rolling out this strategy in three phases:
Phase 1: Incremental Start Run only increments during the first week, with vendor creation time in OA later than midnight of the deployment day. Filter historical data in Qeasy to avoid triggering a massive writeback at launch.
Phase 2: Full Reconciliation After the incremental runs stably for two weeks, trigger a full comparison: pull all currently active vendors from OA and compare against Kingdee records one by one. Qeasy's "full + incremental dual-track" mode is perfect for this—full captures drift, incremental handles daily sync, and the combined output becomes a discrepancy report.
Phase 3: Scheduling Frequency
We recommend running every 15 minutes initially for observation; after one week of stability, switch to hourly. Qeasy's scheduler supports cron expressions—on-site we typically use 0 */1 * * *. Inactive status changes should use a dedicated channel with near-real-time processing to avoid impacting normal purchasing.
Lessons Learned
- Mapping table not maintained: Three months in, a vendor's short name was updated in OA but the mapping table wasn't synced, so Kingdee still showed the old name. The safe approach is to put mapping table changes into the change management process and let Qeasy run periodic checks.
- Status not synchronized: A vendor was deactivated in OA but remained active in Kingdee, so purchasers could still place orders. The typical mistake is syncing only base fields and ignoring
FUsed. The status field must be explicitly handled in the middle layer. - Qualification attachments not written back: Attachments are large objects, prone to timeouts. On-site we saw "fake success"—master data updated but attachment lost. Make attachment handling a separate step in Qeasy; on failure, roll back the master data or mark it for re-upload.
- Multi-language names overwritten: One foreign vendor's English name was maintained in OA, but syncing to Kingdee overwrote the Chinese name, causing invoice printing issues. Recommend language-branch writes in the middle layer instead of simple replacement.
- Schedule frequency overloading the source system: Hourly full pulls hammer the OA API and slow the source system down. Make sure to implement an incremental cursor on the Qeasy side; full pulls should only run once in a designated window.
Applicable and Non-Applicable Scenarios
Applicable: Private supply chain scenarios where OA is the vendor master data maintenance entry and Kingdee is the downstream business system; enterprises with moderate vendor change frequency and centralized master data governance on the OA side. Not applicable: Scenarios requiring bi-directional sync where either side can modify data; scenarios with very large vendor volumes (tens of thousands of daily changes) requiring second-level real-time performance—interface throughput must be evaluated.