Querying Last Month's Currency Rates: An Underestimated Building Block for Supply Chain Integration

What This Strategy Solves

In cross-border and multi-org supply chain integration, any settlement, cost allocation, or inventory valuation with a monetary amount starts with one question: which exchange rate applies this month? Last month's currency reference data is precisely the input parameter for the exchange rate API.

Many teams, when first building integrations, think "just query it inline within the main document flow." Six months after go-live, they discover three months of stale currency data in the rate table, with hundreds of currency units of variance nobody wants to own.

When we do this on the Qeasy data integration platform (轻易云), the habit is to extract it as a standalone lightweight query strategy: triggered on schedule at the start of each month, responsible only for pulling last month's currency list and landing it on the platform's middle layer for downstream consumption. Clean, isolated, easy to troubleshoot.

Data Flow and Field Mapping

This strategy's flow is a bit different from a typical sync — it's source → middle layer → no-op sink, i.e., a "pull and audit" operation.

On the source side (LingXing ERP), the WebAPI /erp/sc/routing/finance/currency/currencyMonth queries last month's currency list by month. The middle layer is the Qeasy integration platform, where fields land and are audited. The target side invokes a "no-op write," whose main purpose is to let the schedule close cleanly and write results into the run log.

Key field mapping is roughly:

The source request only needs one date parameter, valued as last month's year-month, with an expression like DATE_FORMAT(DATE_SUB(LAST_DAY(NOW()), INTERVAL 1 MONTH), '%Y-%m'). There's no shortcut here — the month parameter must be computed by the platform in the business timezone, never by letting the source system pick "today" by itself, otherwise cross-timezone batch runs drift by a month.

How to Configure on Qeasy

Open the Qeasy data integration platform, create a new strategy, pick "LingXing ERP" as the source connector, and the platform itself (datahub) as the target connector.

A few typical configuration points:

• API path: /erp/sc/routing/finance/currency/currencyMonth, method POST, effect set to QUERY — read-only against the source.
• Number field: name. ID field: code. Distinguish "unique key" from "business key" — don't use the currency name as the unique key; same-named currencies are not unusual in cross-border scenarios.
• idCheck off: currency is reference data, not a document, with no "already exists" semantics.
• buildModel off: the response shape is stable; rebuilding the model each run is unnecessary.
• autoFillResponse on: skip manually filling response fields into the model — source fields map directly to the platform's middle table.
• Target side: pick no-op write, API blank, method POST. Its role is to "let the task close as a complete cycle" and incidentally write the run summary into the log.

A common pattern among Qeasy customers is to put currency, exchange rate, and unit-of-measure reference data under one centrally managed code-mapping directory, so any downstream document flow looks up from there rather than re-querying the source.

Implementation Steps

We recommend a three-phase rollout:

Phase 1: Incremental seed Configure the strategy, manually trigger one run, and check that the returned currency list matches expectations (USD, EUR, CNY, JPY, GBP…). The first run often surfaces currencies with an empty name from the source — a default-value fallback or filter is needed on the platform.

Phase 2: Full trigger Switch the strategy to "query full" mode, run a full natural-month backfill, and confirm no duplicate rows or missing fields in the platform's middle table. This phase also validates platform-side partitioning and indexing.

Phase 3: Scheduling frequency Production schedule: 0 10 6 * *, i.e., the 6th of each month at 10:00. Why not the 1st? Because most cross-border source systems finalize rate data only in the first few business days of the month — querying on the 1st often returns an empty set. The 6th is an empirical stable choice.

The target-side no-op link uses 23 2 * * *, running at 02:23 every night, responsible for log archival and cache refresh on the platform side. It's decoupled from the source strategy: even if the source misses a day, downstream isn't blocked.

Lessons from the Field

Pitfall 1: Embedding currency queries inside the sales outbound sync The most common mistake. A single main document flow ends up querying shops, currencies, and rates all at once. With so many fields, any query failure stalls the entire document. The safe pattern is to fully externalize reference data — the document flow only consumes already-landed middle-table data.

Pitfall 2: Letting the source compute the month parameter Already covered above. If the source server's timezone differs from your business timezone, you frequently see issues like "I clearly queried in early February, but the result is January data." Always compute the month explicitly on the platform side before passing it.

Pitfall 3: Using code as the business key Currency codes are not always unique across systems — some organizations distinguish ISO 4217 three-letter codes from internal custom codes. A common Qeasy customer pattern is a composite key of code + business organization, rather than code alone.

Pitfall 4: Ignoring empty name and icon name and icon in the source response are occasionally blank. Without a fallback, downstream reports show rows with only USD, leaving everyone confused during troubleshooting.

Pitfall 5: Setting the schedule too early Running at 00:00 on the 1st often pulls the source's "frozen" month-end data rather than the "settled" data. Recommend scheduling on the 5th–7th of the month — leaves a buffer for the source to close the books and doesn't delay pre-10th settlement batches.

Applicable and Non-Applicable Scenarios

Applicable: cross-border e-commerce, multi-org finance, and scenarios needing a monthly pull of last month's reference data; plus any integration project that wants to provide a "clean, stable, traceable" reference data source for downstream document flows.

Not applicable: real-time FX quote scenarios (need second- or minute-level refresh — this monthly query cannot keep up); and small organizations whose currency data is maintained manually rather than via API.