Cost management API POST fails with unsupported currency error for multi-currency projects

PLM Windchill
, , , , , , , ,
1

We’re implementing cost tracking integration using Windchill REST API v12.0 CPS05. When posting new cost records for parts with different currencies, we consistently get ‘Unsupported currency code’ errors even though the currency codes are valid ISO 4217 (EUR, GBP, JPY).

The currency code configuration appears correct in Windchill preferences, and our API payload structure follows the documentation. We’ve also verified that user profiles have multi-currency access enabled. Here’s our typical request:

POST /Windchill/servlet/odata/ProdMgmt/CostRecords
{
  "PartNumber": "PUMP-2024-A",
  "CostAmount": 245.50,
  "CurrencyCode": "EUR"
}

The error response indicates currency validation failure, but we can manually enter EUR costs through the UI without issues. What are we missing in the API payload requirements or currency setup?

2

Exactly right. The currency needs to be passed as a navigation property reference. First GET the currency: /Windchill/servlet/odata/ProdMgmt/Currencies?$filter=Code eq 'EUR' to get the ID, then reference it in your POST payload using the @odata.bind syntax. Also make sure your Content-Type header is set to application/json and you’re authenticated with a user who has CostManager role assigned.

3

Thanks for the suggestions. I queried the Currency endpoint and can see the available currencies with their object IDs. So instead of passing “CurrencyCode”: “EUR”, I should be passing a reference to the currency object? That would explain why the validation fails - the API is looking for an object reference, not a string code. Can someone confirm the correct payload structure for this?

4

The payload structure is definitely your issue. You need to query available currencies first using GET on the Currency collection endpoint, then use the returned currency object reference in your POST. The API doesn’t accept plain ISO codes directly - it requires the Windchill internal currency object ID. This is a common gotcha with the cost management API that isn’t well documented.

5

The root cause here involves all three focus areas mentioned. Let me address each systematically:

Currency Code Configuration: The currencies must be enabled in Site > Utilities > Currency Manager, not just present in preferences. Each currency needs Active status and proper exchange rate definitions if you’re working with multiple currencies.

API Payload Requirements: The correct payload structure uses OData navigation properties. You cannot pass ISO codes directly. Here’s the proper format:

POST /Windchill/servlet/odata/ProdMgmt/CostRecords
{
  "PartNumber": "PUMP-2024-A",
  "CostAmount": 245.50,
  "Currency@odata.bind": "Currencies('OR:wt.currency.Currency:12345')"
}

First query currencies: GET /Windchill/servlet/odata/ProdMgmt/Currencies?$filter=Code eq 'EUR' to obtain the proper object ID.

User Profile Currency Access: The API authentication user must have:

  • CostManager role or equivalent permissions
  • Explicit access to each currency in their user profile (User > Preferences > Currency Access)
  • Organization-level permissions if working across multiple orgs

Additionally, verify your Content-Type header is application/json and you’re using proper OAuth2 or basic authentication. The error message ‘Unsupported currency code’ is misleading - it actually means the API couldn’t resolve the currency reference, not that the currency itself is invalid.

For bulk operations, consider caching the currency object IDs after the initial query rather than looking them up for each cost record. This significantly improves performance when posting multiple cost entries.

6

Check if the currencies are actually enabled at the organization level in Windchill. Just having them in preferences isn’t enough - they need to be activated in the Currency Manager under Site > Utilities. Also verify that the user account making the API call has explicit permission to use those specific currencies. We had a similar issue where the service account lacked currency access rights even though interactive users could use them fine.

7

I’ve seen this before. The API expects currency codes in a specific nested structure, not as a flat field. Your payload needs to reference the currency object properly with the internal identifier, not just the ISO code string.