TCURV table — Exchange rate type definitions

One row in TCURV represents one exchange rate type as defined in the system, for example M (standard translation rate), B (bank buying rate), G (bank selling rate), or a company-specific type created for a particular scenario such as budget planning or hedge accounting. The row carries the behavioural settings for that type: which currency is treated as the base currency for rates stored under it, whether the rate can be inverted (used in the reverse direction) when a matching direct rate is missing, and whether the rate for that type is meant to be fixed and not changed at document entry. It is a small, client-dependent configuration table maintained once and referenced constantly by postings, valuations, and translations across every module that touches currency.

TCURV is tiny, typically a handful of rows per client since most installations use only the SAP-delivered types plus one or two custom ones. There is no selectivity problem: filter on client and, if needed, on KURST directly. The risk with this table is not performance, it is misreading the flags. XINVR and XFIXD are booleans that change behaviour elsewhere, not values to be extrapolated into a business rule without checking how the rate type is actually consumed in the posting or valuation program that uses it.

Symptom: a translated amount looks like it used the wrong side of a currency pair, for example EUR to USD applied where USD to EUR was expected. Select TCURV where KURST equals the rate type in question and check XINVR. If XINVR is blank, the system will not invert a missing direct rate and will instead raise a rate-not-found error rather than silently flipping direction, so the real fault lies in TCURR maintenance, not in TCURV.

TCURV is unchanged on S/4HANA. It remains a standard configuration table maintained through the same currency configuration transaction and is not superseded by a compatibility view, since it is master configuration rather than transactional or aggregated data. Programs and CDS views that need exchange rate behaviour still read TCURV alongside TCURR exactly as they did in ECC.

Currency and exchange rate type setup belongs to the FI general ledger or treasury configuration lead, not to Basis or an ABAP developer. Any question about why a particular translation used inversion, or why a fixed-rate flag behaves a certain way, should go to whoever owns the currency configuration chapter of the FI build, since it is a deliberate design decision, not an accident of data.

TCURR holds the actual exchange rates stored per type and date and is the table to check first for a missing or wrong rate. TCURN and TCURF govern which rate types are usable together and how translation ratios apply between currency pairs. The exchange rate type text table supplies the description shown in maintenance and reports. On the transactional side, BKPF carries the rate type used per posted document, and the standard configuration transaction for maintaining exchange rate types and the companion one for maintaining daily rates are where consultants actually make changes.