API integration with pricing management returns incorrect currency conversion rates

ERP SAP S/4HANA
, , , , , , , ,
1

Our API integration with the pricing management module is returning incorrect currency conversion rates for multi-currency pricing scenarios. We recently updated our exchange rates in SAP, but the API continues to return outdated rates.

We’ve checked the API payload being sent and it includes the correct currency pairs and effective dates. However, when SAP processes the pricing request and applies currency conversion, it uses exchange rates that are several days old. The strange thing is that when we check rates directly in SAP transaction OB08, the current rates are displayed correctly.

The API endpoint we’re calling is the standard pricing simulation API. Our external pricing tool sends requests with base currency USD and target currencies EUR, GBP, JPY. SAP should apply the latest exchange rates from table TCURR but appears to be using cached or outdated values. Any ideas why the API would show different rates than what’s configured in SAP?

2

Your issue stems from a combination of API configuration, exchange rate type handling, and SAP’s rate caching mechanism. Let me provide a comprehensive explanation and solution.

Understanding the Exchange Rate Update Discrepancy: You’re observing that exchange rates appear current in transaction OB08 but the API returns outdated values. This happens because the pricing API and the OB08 transaction access exchange rate data through different mechanisms. OB08 reads directly from table TCURR in real-time, while the pricing simulation API uses a buffered data structure that’s refreshed on a schedule.

Why Your API Payload Check Isn’t Sufficient: You mentioned verifying that the API payload includes correct currency pairs and effective dates. However, the payload doesn’t control which exchange rate type SAP uses - that’s determined by your system configuration. The API inherits rate type defaults from your pricing procedure, condition records, or company code settings. If you’re not explicitly specifying a rate type in your API request, SAP applies its configured default, which may not be the ‘M’ (standard) type you’re maintaining.

SAP Shows Updated Rates Because: When you check OB08, you’re viewing the TCURR table directly with real-time data access. The transaction doesn’t use buffering or caching, so you immediately see any rate updates. The pricing API, however, operates through the application layer which employs multiple caching mechanisms for performance optimization.

Complete Solution:

  1. Identify the Active Exchange Rate Type:

    • Check your company code configuration in transaction OBY6
    • Review field ‘Exchange rate type for translation’ - this is often the API default
    • Verify pricing condition records (transaction VK11/VK13) to see if they specify a rate type
    • Check table T001 field KURST for company code default rate type

  2. Explicitly Specify Rate Type in API Requests: Modify your API payload to include the exchange rate type parameter:


// Pseudocode - Enhanced API request:
1. Build pricing request with currency pair (USD->EUR)
2. Add parameter: exchangeRateType = 'M' (or your configured type)
3. Include effectiveDate = current_date
4. Set rateSource = 'SAP' to ensure TCURR lookup
5. Send request and validate response rate matches TCURR
// API Documentation: Pricing Simulation API v2 Section 5.3

  1. Verify Rate Maintenance Scope:

    • Ensure you’re updating exchange rates for ALL rate types that might be used
    • In transaction OB08, check which rate types have entries
    • If API uses rate type ‘P’ but you only maintain ‘M’, that explains the discrepancy
    • Maintain rates consistently across all active rate types

  2. Address API Caching:

    • Check SAP Gateway cache settings in transaction /IWFND/MAINT_SERVICE
    • Look for your pricing service and review cache configuration
    • Reduce cache TTL for exchange rate data to 1-4 hours instead of 24 hours
    • Consider implementing cache invalidation triggers when rates are updated

  3. Implement Rate Buffer Refresh:

    • Exchange rates are buffered in table TCURF (rate factors) and internal structures
    • Schedule program RFTBFF00 to run after each rate update
    • This program refreshes the exchange rate buffer used by APIs
    • Alternatively, call function module BAPI_EXCHRATE_CREATEMULTIPLE with refresh flag

  4. Configure Real-Time Rate Access: If your business requires immediate rate updates, modify the pricing API configuration:

    • In SPRO, navigate to Sales and Distribution → Basic Functions → Pricing → Exchange Rates
    • Enable ‘Direct database access for exchange rates’ option
    • This bypasses buffering but may impact API performance
    • Test performance impact before enabling in production

  5. Validation and Monitoring:

    • After implementing changes, test API with known currency pairs
    • Compare API-returned rates against OB08 values for same date and rate type
    • Set up monitoring to alert when API rates diverge from TCURR by more than threshold
    • Log rate type used in each API call for troubleshooting

Recommended Implementation Order:

  1. First, explicitly specify exchange rate type in API requests
  2. Verify that you’re maintaining rates for the correct type
  3. Then address caching if discrepancies persist
  4. Finally, implement buffer refresh automation

The most common resolution is step 1 - adding explicit rate type specification to your API payload. This ensures the API uses the same rate type you’re maintaining in OB08, eliminating the mismatch. The caching and buffering issues are secondary factors that compound the problem but are less likely to be the root cause if rate types are misaligned.

Once you align the rate type between your maintenance process and API configuration, and implement buffer refresh after updates, your API should consistently return current exchange rates matching what you see in OB08.

3

Good point about the exchange rate type. I checked and our API requests don’t explicitly specify a rate type - we assumed it would use the default. When I look at OB08, I see rates maintained for type ‘M’ (standard) which is what I expect the API to use. Could the API be using a different default rate type than the standard one?

4

The API likely uses whatever rate type is configured as default in your pricing procedure or condition records. This might differ from the ‘M’ type you’re maintaining. Check table T001 for your company code settings - there’s a field for default exchange rate type. Also look at your pricing condition records to see if they specify a particular rate type. The API follows the same configuration as manual pricing, so if your condition records reference a different rate type, that’s what the API will use regardless of what you maintain in type ‘M’.

5

I’ve encountered this exact scenario before. The issue is usually that the API reads exchange rates from a buffered table rather than directly from TCURR. SAP uses table TCURV for exchange rate type definitions and TCURR for actual rates, but the pricing API often reads from an internal buffer that’s populated during nightly batch jobs. If your exchange rate updates happen after the buffer refresh, the API won’t see them until the next refresh cycle. Check transaction SE16 for table TCURF to see when rates were last buffered.