What This API Solves

The Payment Application (付款申请单) is a pivotal finance-supply-chain document in Kingdee Cloud, capturing "who pays whom, how much, and when." In real projects we frequently need to mirror it into DingTalk approval flows or use it for AP tracking, expense reconciliation, and payment planning. The executeBillQuery endpoint (FormId: CN_PAYAPPLY) is Kingdee's official query gateway, supports incremental pulls by creation date, and is well suited as an upstream source for downstream integrations. Typical scenarios include: payment approval sync, expense reconciliation, payment plan tracking, and AP request management.

Capability Overview

Protocol: Kingdee Cloud WebAPI, POST with JSON request/response.
Form: CN_PAYAPPLY (Payment Application), header-line flat response.
Authentication: Standard Kingdee API authorization (data center ID + app secret + user token); most projects use a dedicated integration account.
Pagination: Uses Limit/StartRow together with the FilterString clause and FieldKeys to explicitly request needed columns for performance.
Incremental: FCREATEDATE>='{{LAST_SYNC_TIME|dateTime}}' is the canonical incremental filter, scheduled 0-59/10 8-22 * * *.
Write: Target is a no-op write — this is a pure QUERY strategy that other strategies can depend on.

Canonical Field Mapping

Field	Type	Meaning	Field Notes
FID	string	Header primary key	Cross-system unique ID, used as external_id on the DingTalk side
FPAYAPPLYENTRY_FEntryID	string	Line primary key	For line-level reconciliation; do not confuse with FID
FBillNo	string	Business document number	Human-readable, first choice for manual reconciliation
FDOCUMENTSTATUS	string	Document status (draft/submitted/approved)	For incremental sync, usually restrict to approved
FCREATEDATE / FMODIFYDATE / FAPPROVEDATE	string	Created/modified/approved timestamps	Incremental anchors; strict datetime format
FAPPLYORGID / FPAYORGID / FSETTLEORGID / FPURCHASEORGID	string	Apply/Pay/Settle/Purchase orgs	Required in multi-org scenarios, affects posting
FCONTACTUNIT / FRECTUNIT	string	Contact/Payee unit	Object type; real value usually under `.FNumber`
FAPPLYAMOUNTFOR_H / FPAYAMOUNTFOR_H	string	Header apply/pay amount (base currency)	Recommend unifying on base currency upstream
FAPPLYAMOUNTFOR / FPAYAMOUNTFOR / FREALAPPLYAMOUNTFOR	string	Line amounts (original currency)	Combine with exchange rate for FX
FCURRENCYID / FSETTLECUR / FEXCHANGERATE / FSETTLERATE	string	Currency/rate	Confirm rate type in FX scenarios
FSRCBILLNO / FSRCROWID / FSOURCETYPE	string	Source bill/row/type	Required to trace back to PO/AP docs
FPAYPURPOSEID / FCOSTID / FEXPENSEDEPTID	string	Pay purpose/cost item/expense dept	Drives expense attribution
FEACHBANKACCOUNT / FEACHBANKNAME / FEACHCCOUNTNAME	string	Payee bank info	Cross-border needs FSwiftCode too
FEXPECTPAYDATE / FENDDATE	string	Expected/end pay dates	Key for payment planning dashboards
FCANCELSTATUS / FCLOSESTATUS	string	Cancel/close status	Filter out canceled in full sync
FPRESETBASE1/2, FPRESETTEXT1/2	string	Extension slots	Often overlooked custom fields

Configuring on Qeasy Cloud

In the Qeasy Cloud data integration platform we pick the Kingdee Cloud adapter, fill in the data center ID plus the authorized account, and point it to form CN_PAYAPPLY. The platform ships a request template for executeBillQuery. In practice:

Choose "Kingdee Cloud" as the source, supply credentials and the form ID CN_PAYAPPLY.
Use the visual field mapper to select target fields; the header-line flat model is auto-flattened.
Enable the "Incremental by FCREATEDATE" option; Qeasy Cloud stitches the FilterString using the last run time.
Keep the same cadence (every 10 minutes between 08:00–22:00), set Target to no-op, and publish as a pure QUERY strategy that downstream SYNC strategies can depend on.

Qeasy Cloud's mapper natively flattens object fields like FCONTACTUNIT.FNumber without custom Groovy, and auto-renames FPAYAMOUNTFOR_H / FAPPLYAMOUNTFOR_H to pay_amount / apply_amount to align with downstream semantics.

Cross-Project Practical Points

Decompose the header-line flat model: each row carries both header and line fields. Combine FID and line ID for dedup, otherwise downstream consumes duplicates.
Take only .FNumber for object fields: FSETTLEORGID, FCONTACTUNIT, FRECTUNIT are objects; only the code survives cross-system alignment.
Preserve both base-currency and original-currency amounts: *_H for summary reporting, original-currency fields for FX reconciliation — don't pick just one.
Prefer FCREATEDATE for incremental: more stable than FAPPROVEDATE; pair with FMODIFYDATE if unapprove/re-approve patterns exist.
Filter at the source: only sync FDOCUMENTSTATUS='approved', not canceled, not closed — cuts downstream noise by 70%+.
Offset the schedule between read and write: align Kingdee's cron (08:00–22:00 every 10 min) and offset downstream writes by 1–2 minutes to avoid read/write contention.

Troubleshooting Replays

Pitfall 1: Object fields returned as full objects break deserialization. Fix: keep the FilterString, but in the mapper pick .FNumber only and enable "flat value extraction" in Qeasy Cloud.
Pitfall 2: Incremental time not formatted → Kingdee returns 0 rows. Fix: use Kingdee's yyyy-MM-dd HH:mm:ss; inject via {{LAST_SYNC_TIME|dateTime}} rather than ISO-8601.
Pitfall 3: Confusing FID with FBillNo, downstream cannot locate the doc. Fix: use FBillNo for human display, FID for idempotency — keep responsibilities separate.
Pitfall 4: Header vs line amounts mixed, totals don't reconcile. Fix: use *_H for totals, line fields for detail; group-validate before SUM.
Pitfall 5: Forgetting FAPPLYORGID in multi-org setups routes data to the wrong ledger. Fix: include org fields in the key mapping; route at the dispatcher by organization.

When to Use

Use this API for syncing Kingdee Cloud payment applications to DingTalk, BI, or reporting systems — especially when you need incremental pulls by creation date, approval reconciliation, or payment plan tracking. If the requirement is purely manual approval logging, lean on Kingdee's built-in workflow engine instead. If you need to write payment vouchers back into Kingdee, switch to the saveBill API rather than executeBillQuery.

Authoritative Tutorial on Kingdee Cloud Payment Application API Field Reference (executeBillQuery/CN_PAYAPPLY)