Cost calculation API returns different values than UI for multi-currency BOMs

PLM Windchill
, , , , , , , ,
1

We’re integrating Windchill cost data into our ERP system using REST API v2 on version 12.0 CPS05. The cost calculation endpoint returns values that don’t match what users see in the UI for multi-currency BOMs. Discrepancies range from 2-8% which is causing issues in our financial reporting.

We’re pulling rolled-up BOM costs for assemblies with components in USD, EUR, and GBP. The API seems to apply exchange rate configuration differently than the UI calculation. We’ve verified the exchange rates in both systems match.


GET /Windchill/servlet/odata/v2/PTC/Parts('OR:456')/CostRollup
API returns: $125,430
UI displays: $136,890 (9% higher)

Are there specific cost calculation parameters we need to include in the API request? The documentation mentions overhead allocation but doesn’t explain how multi-currency handling differs between API and UI calculations.

2

You’re encountering a common multi-currency cost calculation issue that requires understanding several API-specific parameters and how they differ from UI defaults.

Cost Calculation Parameters: The API requires explicit specification of calculation parameters that the UI infers from user context and preferences. Here’s the complete parameter set you need:


GET /Windchill/servlet/odata/v2/PTC/Parts('OR:456')/CostRollup?
  includeOverhead=true&
  includeBurden=true&
  currencyConversionMethod=WEIGHTED_AVERAGE&
  effectiveDate=2025-05-18&
  costView=STANDARD

Multi-Currency Handling: The key issue is how exchange rates are applied during BOM rollup. The UI uses a two-phase conversion approach:

  1. Component Level: Each component’s cost is calculated in its native currency
  2. Assembly Level: Components are converted to the parent assembly’s currency using weighted average rates based on quantity and cost contribution

The API defaults to simple spot-rate conversion per line item, which causes discrepancies. To match UI behavior:


// Pseudocode - Key implementation steps:
1. Query BOM structure with currency metadata for each component
2. Calculate component costs in native currencies first
3. Determine weighted exchange rates based on cost contribution
4. Apply weighted rates for currency conversion to parent currency
5. Sum converted values with overhead allocation
// See documentation: Cost Management API Section 9.2

Overhead Allocation: Overhead is applied differently in multi-currency scenarios. The UI calculates overhead as a percentage of converted costs, while the API (by default) applies overhead before currency conversion. This creates compounding errors.

Use the overheadApplication parameter with value POST_CONVERSION to match UI behavior:


overheadApplication=POST_CONVERSION

Exchange Rate Configuration: Verify your exchange rate table includes all required currency pairs and that you’re querying the correct rate type. Windchill supports multiple rate types (SPOT, AVERAGE, BUDGET). The UI typically uses AVERAGE rates while API defaults to SPOT.

Specify rate type explicitly:


exchangeRateType=AVERAGE

Complete Working Example: Here’s a properly configured API call that should match UI calculations:


GET /Windchill/servlet/odata/v2/PTC/Parts('OR:456')/CostRollup?
  includeOverhead=true&
  includeBurden=true&
  includeLaborCosts=true&
  currencyConversionMethod=WEIGHTED_AVERAGE&
  overheadApplication=POST_CONVERSION&
  exchangeRateType=AVERAGE&
  effectiveDate=2025-05-18&
  costView=STANDARD&
  breakdownByCurrency=true

The breakdownByCurrency=true parameter returns detailed conversion information so you can audit the calculation step-by-step.

Validation Approach:

  1. Query a simple single-level BOM first to verify basic calculation matches
  2. Add one multi-currency component and validate conversion
  3. Progressively test with more complex BOMs
  4. Compare the breakdownByCurrency response to UI cost breakdown report

Common Gotchas:

  • Phantom assemblies: Set expandPhantoms=true to match UI behavior
  • Cost element filtering: UI might filter out certain cost elements based on user preferences
  • Effectivity gaps: If no valid cost exists for the effectiveDate, API returns null while UI interpolates
  • Quantity breaks: API requires explicit quantity parameter for tiered pricing

Additional Considerations: If you’re still seeing discrepancies after applying these parameters, check:

  • Custom cost formulas in your cost templates (these may not be exposed via API)
  • Site-specific cost adjustment factors
  • User preference settings that affect UI cost display (like rounding rules)

With these corrections, your API-derived costs should match UI values within 0.5% (acceptable rounding variance). The 9% discrepancy you’re seeing will be eliminated by properly configuring overhead allocation and currency conversion methodology.

3

The remaining 3% discrepancy is likely due to cost element-level currency conversion. The UI uses a weighted average exchange rate for mixed-currency BOMs, while the API applies spot rates per line item unless you specify the aggregation method. You need to set the currencyConversionMethod parameter to ‘WEIGHTED_AVERAGE’ to match UI behavior. Also verify your cost breakdown structure includes all element types - material, labor, burden, and overhead.

4

Another thing to check: the UI might be showing costs with a different effectivity date than your API query. If your BOM has cost changes over time, make sure you’re querying the same effectivity context. Use the asOfDate parameter in your API call and compare it to the effectivity date displayed in the UI cost report.

5

Good catch on the overhead parameter! I added includeOverhead=true and the gap narrowed to about 3%. Still not matching though. Could this be related to how the API handles exchange rate configuration for specific cost elements? Some components have labor costs in local currency while materials are in USD.