What This Interface Solves

The Do1QQ Qiqiao "Payment Plan (Receipt Details)" interface is used to pull planned and actual receipt amounts for customers on a contract-by-contract basis. The typical scenario is syncing receipt details into OKKICRM for financial reconciliation, payment progress tracking, and performance accounting. After working on multiple customer projects, we have found that mastering this single interface makes the cross-system receipt data loop much more stable.

Interface Capability Overview

Authentication: Uses the Do1QQ Qiqiao open platform's Access Token mechanism. Tokens are obtained through application credentials and carried in the request header (usually Authorization or a custom header) for query requests.
Request Structure: Queries are conditioned on contract or customer dimensions. Common inputs include number (contract number), id (contract primary key), and time ranges. Combined filtering is supported.
Response Structure: Returns a JSON object whose main body is an array of form records. Each record contains customer name, contract number, amount fields, and an extend extension object, which usually hides custom form fields.
Pagination/Incremental Mode: Do1QQ Qiqiao form-style interfaces commonly use traditional pagination with page number + page size (e.g., pageNo/pageSize or similarly named fields). Incremental pulls depend on business time fields (such as modification time) for cursor-based filtering. In QeasyCloud, this is typically encapsulated as a "rolling pull by time window" strategy template.

Typical Field Mappings

Field Name	Type	Meaning	Practical Notes
Customer Name	string	The customer associated with the receipt	When aligning with CRM master data, it is recommended to map customer profiles in QeasyCloud first to avoid homonymous but different companies
Contract Number	string	The unique sales contract number used for association	Also used as `number` and `id` in strategy metadata; it is the primary association key for receipt details
Planned Receipt Amount	string	The planned or agreed receipt amount	The amount field is a string; be sure to convert to decimal/number when landing
Actual Receipt Amount	string	The amount the customer has actually paid	The difference between this and the planned amount equals the outstanding balance, which can directly feed KPIs
OKKICRM Receipt Number	string	The unique receipt number on the CRM side	Key to cross-system deduplication; QeasyCloud's field mapper automatically uses it as the idempotency key
extend	object	Form extension fields/metadata	The actual structure depends on the form configuration and must be parsed from the real response; do not store it as a whole

How to Configure on QeasyCloud

In the QeasyCloud data integration platform, this interface is typically encapsulated as a "Form Query" adapter under the source-side "Do1QQ Qiqiao" node. Configuration takes only three steps. First, fill in the application credentials in the adapter, and the platform automatically maintains token acquisition and refresh. Second, select the "Payment Plan (Receipt Details)" form and set query conditions (such as contract number or time range). Third, map Do1QQ fields to CRM fields one by one in the field mapper. The platform uses "OKKICRM Receipt Number" as the idempotency key by default, ensuring that repeated pulls do not generate duplicate receipt records.

Cross-Scenario Practical Points

Organize data by contract as the primary key: Do1QQ's receipt details are naturally organized by contract dimension. The contract number serves as both the business key and the common query input, making master data association very convenient.
Treat all amount fields as strings: The source side is always string. No matter whether the downstream is CRM, ERP, or BI, do not forget the type conversion, or you will get scientific notation or precision loss.
Land planned and actual amounts separately: The difference between them is the "outstanding balance." It is recommended to produce it directly through a calculated field in QeasyCloud, which saves a lot of work for downstream consumers.
Carefully expand the extend object: The extension field often hides custom form items. A safe approach is to use QeasyCloud's visual parser to preview and expand first, then selectively land only the needed fields; do not dump the entire JSON block to downstream.
Increment by time window, not by page number: Form-style interfaces are prone to page offset issues. In real scenarios we prefer rolling pulls by modification time. QeasyCloud supports configuring an "incremental pull by time window" strategy.
The idempotency key must be the receipt number: The same receipt may be pushed multiple times. As long as the "OKKICRM Receipt Number" is consistent, QeasyCloud automatically overwrites and updates, avoiding dirty data during reconciliation.

Pitfall Review

Amount string treated directly as a number: When a retail enterprise integrated, the "Planned Receipt Amount" was directly stored as a number, causing precision loss for decimals. A safe approach is to explicitly CAST/CONVERT to decimal, or specify the numeric type in QeasyCloud's field mapper.
Storing the entire extend object caused downstream field explosion: In one project, the entire extend object was landed as-is, disrupting the downstream table structure. It is recommended to parse only the needed custom fields and ignore the rest.
Pagination missed data: Under concurrency, form interfaces may have boundary issues where "the same record appears on two pages." A safe approach is to switch to time window increments, or enable the "deduplicate by primary key" switch in QeasyCloud.
Inconsistent contract number encoding on both sides: The contract number format differs between CRM and Do1QQ (one with prefix, one without). Without normalization, association fails. It is recommended to add a "Contract Number Normalization" cleansing step in QeasyCloud.
Token expiration interrupted batch tasks: A bulk receipt sync task was interrupted halfway because the token expired, causing all subsequent 401 errors. In QeasyCloud, the platform automatically refreshes tokens and retries failures, essentially avoiding such interruptions.

When to Use

Whenever the business involves "syncing receipt details to CRM or BI by contract dimension" and the source is a Do1QQ Qiqiao custom form, this interface should be chosen directly. However, if the requirement is bank-flow-by-flow reconciliation or organizing data by account dimension, it is not suitable, and a bank statement interface or third-party payment interface should be used instead.

Do1QQ Qiqiao Payment Plan (Receipt Details) Interface Field Handbook