In-Depth Tutorial: Syncing Other Monetary Funds Receipt & Refund Orders

What This Strategy Solves

A retail enterprise's finance team noticed during monthly reconciliation that "Other Monetary Funds Receipt & Refund Orders" generated in the source system were not entering the target ERP in time. This caused the bank deposit accounts to mismatch with the business system ledger, forcing the finance team to manually re-enter records—inefficient and error-prone. We used the Qeasy data integration platform to take over this link, splitting the source system's receipt/refund documents by business type and pushing them into the target ERP's finance module, achieving automatic alignment of document status, currency, and settlement organization, which drastically reduced reconciliation workload.

Data Flow and Field Mapping

The overall flow is: source system → Qeasy middleware → target system. The source side uses the QueryStrategyData API to incrementally pull documents by time window, while the target side uses the batchSave API for bulk writing.

Key field mapping table:

It is recommended to centrally maintain encoding mappings in Qeasy's "Mapping Management" module so that new stores or currencies only require updates in one place, avoiding scattered changes across multiple strategies.

How to Configure on Qeasy

Within the Qeasy integration platform, this strategy has 4 key configuration points:

1. Source Strategy Configuration: Select the QueryStrategyData API via POST; bind strategy_id to this strategy; status defaults to 0 (waiting), retry uses 3 (error); time window uses created_at_begin ~ created_at_end, with end filled by the {{CURRENT_TIME}} variable automatically on each schedule.
2. Target Execution Configuration: Select the batchSave API; document type FBillTypeID defaults to SKTKDLX99_SYS; enable idCheck=true for idempotency to prevent duplicate pushes.
3. Scheduling Plan: Source strategy uses 1 1 1 1 1 (placeholder, driven by trigger); target uses 23 2 * * *, executing at 02:23 AM daily to avoid business peak hours.
4. Header and Body in Phases: A common practice among Qeasy customers is to first stabilize the header (document number, status, currency, business date), then push the body (line items) in a separate strategy. This makes troubleshooting faster.

Implementation Steps

We recommend a three-phase rollout using "incremental start + full trigger + scheduling frequency":

• Phase 1 · Incremental Start: Determine the incremental start timestamp (e.g., 1700409600), first sync new documents after this point; filter source status with 0,5 (waiting, queued).
• Phase 2 · Full Trigger: During early rollout, manually trigger a one-time full backfill to flush all historical unsynced documents; immediately switch back to incremental mode after full run to avoid occupying scheduling resources.
• Phase 3 · Scheduling Frequency: Target runs once daily in the early morning, source polls every 5-10 minutes; a common pattern among Qeasy customers is the "dual-track of incremental and full"—incremental goes through scheduling, full goes through manual trigger, with idCheck providing natural deduplication.

For the first week after rollout, it is recommended to reconcile three metrics daily: "source document count vs target loaded count vs error queue count", and alert when differences exceed threshold.

Lessons from the Trenches

1. Currency Mapping Missing Default: If the source document's currency is empty, the target FCURRENCYID becomes an empty string, and the target ERP rejects the entire batch. The safe approach is to add a default value PRE001 in Qeasy's field mapping and tag it in logs for traceability.
2. Status Code Confusion: Source status=4 (unaudited) corresponds to target FDOCUMENTSTATUS=A (created), not C (approved); a typical mistake is to pass 4 through directly, causing target documents to stay at "created" forever, uncaught by the audit module.
3. Time Window Drift: If the source filters by business date, cross-timezone orders may be missed. The safe approach is to use creation time (created_at) rather than business date, and unify the timezone to UTC+8 in Qeasy.
4. batchSave Batch Too Large: When a single batch exceeds 500 records, the target side occasionally times out. This is where things go wrong. The safe approach is to limit batch size to 200 records/batch in Qeasy, with automatic retry on failure.
5. Refund and Receipt Mixed Push: Although these have different business types (FBillTypeID), their document number ranges are similar. Always pre-split on the source side using the bill_type field—do not let the target side judge, otherwise document types get mixed and reconciliation fails.

Applicable and Non-Applicable Scenarios

Applicable: Multi-store/multi-organization retail or distribution enterprises that need to sync business system receipt/refund flows daily into the financial ERP for bank deposit reconciliation. Not Applicable: Pure offline financial entry scenarios, or enterprises with very small document volumes (<50 records/month) where manual entry is cheaper; also not suitable for real-time single-document push scenarios requiring sub-second latency, since this strategy runs on a bulk asynchronous chain.