Non-Production Payment Request Sync in Practice: Integrating Weaver OA to Kingdee Cloud Other Payable Bills

What This Strategy Solves

In a typical manufacturing enterprise, non-production payment requests from administration, after-sales, and marketing teams usually go through Weaver OA for approval, but the final booking must happen in Kingdee Cloud. Without integration, finance staff have to re-key the approved request into Kingdee as an Other Payable Bill, which is slow and error-prone. This strategy automatically converts approved non-production payment requests from Weaver OA into Kingdee Cloud Other Payable Bills, removing duplicate data entry and creating a closed loop between OA approval and ERP booking.

Data Flow and Field Mapping

The end-to-end flow is: Weaver OA (source) → Qeasy middleware layer → Kingdee Cloud (target). The middleware layer handles code conversion, field normalization, and batch retries, so the two systems do not become tightly coupled.

Key field mapping (Weaver OA → Kingdee Cloud):

Business meaning	Weaver OA field	Kingdee Cloud field	Mapping notes
Document number	requestNo	FBillNo	Pass-through; used as idempotency key
Request date	requestDate	FDate	Normalize to yyyy-MM-dd
Applicant	applyUser	FApplicant	Map to user primary key, not display name
Supplier	suppName	FSupplierId	Convert name to supplier code via master data
Payment amount	amount	FAmount	Strict numeric validation
Currency	currency	FCurrencyId	Convert ISO 4217 code to Kingdee currency ID
Subject	subject	FExplanation	Pass-through
Custom fields	extField1~5	FText1~FText5	One-to-one alignment of custom segments

We recommend keeping all code mappings in the Qeasy data transformation layer rather than scattered across scripts. This makes it easy to maintain when new suppliers or currencies appear.

How to Configure on Qeasy

Create the source connection: Choose the Weaver OA-E9Http adapter, set up authentication, and define the incremental start time. Prefer the approval completion timestamp lastModifyTime as the cursor field.
Create the target connection: Choose the Kingdee Cloud adapter, log in to the on-premises tenant, and confirm the Other Payable Bill form metadata has been published.
Configure data transformation: Build the field mapping table in Qeasy's transformation panel, and use the expression engine to handle dates, currencies, and user keys. For suppliers, currencies, and departments, use the lookup table component so operations staff can maintain them on their own.
Configure the write policy: Enable idempotency check using FBillNo as the deduplication key. Configure retries up to 3 times with exponential backoff.
Configure exception branches: Missing fields, unmatched codes, and amount validation failures should each route to a different alert channel, so one stuck document does not block the whole batch.
Lightweight notifications: Push failed tasks to enterprise IM or email so engineers can pick them up the next morning.

Implementation Steps

We usually run this integration in phased scheduling, then merge once it proves stable.

Phase 1: Incremental start point

Pick one historically approved request as the first sample and run it through the full path: source pull → middleware transform → target write.
Validate the document format, field values, and attachments in the Kingdee test tenant first.

Phase 2: Small-batch validation

Change the schedule to every 15 minutes, pulling only requests approved in the last 24 hours.
Observe for one week, focusing on failure rate, retry count, and supplier code hit rate.

Phase 3: Full backfill and steady-state scheduling

Once stable, set the cursor start to any historical point and run a one-time full backfill.
After backfill completes, switch to normal incremental scheduling, typically every 5–10 minutes, balancing real-time freshness with target system load.

Phase 4: Day-2 operations

Sample-check document status between OA and Kingdee weekly, ensuring no cases of "OA approved but not generated in Kingdee" or the reverse.
Keep Qeasy run logs for at least 90 days for traceability.

Lessons Learned from the Field

Do not pass applicant display names directly to Kingdee. Names drift when people change or fonts differ. The safer approach is to map to the Kingdee user primary key FApplicant.
Suppliers must exist in Kingdee first. If a new supplier appears in OA first, the transformation cannot find the matching code. A common mistake is dumping the supplier name into remarks to get past the issue; this always causes reconciliation problems later.
The currency field is easy to forget. OA defaults to RMB while Kingdee uses CNY, and the initial run fails repeatedly because no currency mapping table was built.
Do not use "approval time" as the incremental cursor. Historical backfill causes this timestamp to jump, leading to missed documents. Use lastModifyTime or the source system's last-modified time instead.
Custom segments are easy to misalign. Both systems carry custom fields such as "project code" and "expense category." Always ask the business side for a complete custom-segment mapping table and avoid verbal agreements.

When to Use and When Not to Use

Use when: OA approval drives finance booking in ERP, cross-system code systems are inconsistent, or approval results must sync to the general ledger in near real time. Do not use when: The payment is purely production-related (use the Kingdee purchase payment bill instead), the volume is very high (prefer a dedicated interface or staging table), or the field semantics between the two sides differ greatly and require custom development.