Integration Solution Overview: Syncing Receipt Confirmations from Yikuabao to the Asset Management System

Scenario and Value

At the financial shared service center of a manufacturing enterprise, fixed-asset classification has long relied on manual re-entry. Business users submit receipt-confirmation applications on Yikuabao, and only after finance receives the paper or digital document does someone go into the asset system and create an asset card line by line. This "last mile" information gap leads to two recurring problems:

• Delayed booking: after a receipt confirmation completes, the asset card often takes 3 to 5 business days to enter the asset system, leaving depreciation and cost allocation without data in the meantime;
• Inconsistent classification: whether the same batch of receipts is booked as a fixed asset depends on the project and product attributes, and relying on memory is unreliable.

The goal is to close this gap: once the receipt-confirmation application in Yikuabao is approved, it is automatically routed based on the FA_type field and synced to the asset system to create the asset card. The workflow shifts from "people chasing the system" to an automated data loop, with no manual register in between.

Integration Architecture and Data Flow

The integration consists of 2 sync strategies, with clear roles for source and target:

• Yikuabao: the expense reimbursement and procurement application platform, responsible for creating, approving, and managing receipt-confirmation applications and their details;
• Asset Management System (the U.S.-style asset system): the asset management platform, which receives procurementList through the asset docking interface (/assetCard/ekuaibaoProcurementDocking) and creates asset cards.

The data flow has three stages:

1. Extract: the integration platform calls Yikuabao's getApplyList (with type=requisition, filtered by specificationId) to fetch the header and form.details rows of the receipt-confirmation application;
2. Map and route: business field conversion is completed based on the project code and product-attribute code mapping tables, and FA_type decides whether a detail row enters the asset card flow;
3. Write: the assembled procurementList is pushed to the asset system's docking interface to create an asset card.

In similar projects we have worked on, this segment is typically handled by an iPaaS data integration platform. On customer sites we use the Qeasy (轻易云) data integration platform, which packages extraction, transformation, and scheduling into visual strategies; the two strategies can run in parallel or in staggered mode.

Interface Inventory

Both strategies share the same source object and target interface and have no mutual dependency. The difference is the offset in execution time, which reduces the risk of burning through the shared Yikuabao API quota.

Implementation Notes

Phased scheduling. S1 and S2 both run every 5 minutes from 08:00 to 19:00 (*/5 8-19 * * *); S2 is offset to 3-59/5 8-19 * * *, 3 minutes apart from S1. The two strategies can run in parallel, but if they share rate limits, switch to serial.

Incremental-first, full-load as a safety net. In normal operation, filter incrementally by startDate/endDate plus updateTime. For first deployment or data repair, drop the time window and run a full load with pagination count ≤ 100. A weekly full-load reconciliation is recommended as a backstop.

Centralized code mapping. Project IDs, product-attribute IDs, and similar mapping tables must be in place before the strategies go live, otherwise the strategies will skip entire records because of missing mappings. FA_type classification also depends on these two mapping tables, so the tables are a hard dependency for the strategies.

Exceptions and retries. Network timeouts use exponential backoff with 3 retries (30s/60s/120s); target 5xx retries twice with a 60s interval; 4xx business validation errors do not retry, they go straight to alerts; 429 throttling retries 3 times with 60s/120s/300s backoff; missing code mapping skips the record and logs it.

Privacy handling. The design itself contains no customer names, vouchers, or API keys. At deployment, credentials are stored in the platform's credential vault and never persisted to strategy configuration.

Best Practices and Lessons Learned

1. Staggering is not about saving quota; it is about avoiding a throttling cliff. When two same-source strategies fire simultaneously, a 429 from Yikuabao takes them both down at once, and the monitoring dashboard looks like a full-link outage. We fixed the offset at 3 minutes and the blast radius shrank immediately.
2. FA_type classification must live in the mapping table, not in if-else inside the transform script. When a new product attribute appears, the script must be edited and redeployed; a mapping table only needs a new row. On Qeasy (轻易云) we keep mapping tables in a centralized configuration center, where the business team can update them directly.
3. Do not skip the full-load reconciliation. After a long run of incremental syncs, drift is almost inevitable (one side's updateTime did not move while the other side already changed). A weekly full reconciliation surfaces these issues early, before quarter-end close when business will.
4. Write detail rows in stages. Persist the header first, then split form.details and write them in batches. Any failure in between can resume from the header breakpoint instead of re-running the whole document.
5. Alert thresholds should not be guessed. Pause on ≥3 consecutive failures, alert when failure rate > 10%, alert when latency > 30 minutes — these three thresholds have been validated across multiple projects, neither too sensitive nor too blind.

When to Use Qeasy

When an enterprise needs to automatically distribute and transform documents across multiple ERPs, expense-control systems, and asset systems according to business rules, and does not want to build its own scheduling + retry + monitoring middleware, the Qeasy (轻易云) data integration platform is a pragmatic choice. Visual strategy orchestration, centralized mapping management, and built-in exponential-backoff retry and throttling handling turn an integration of 2 to N strategies from a "script patchwork" into an observable, operable engineering artifact.