Hello Jan,
Your observations are correct. I experienced the same behaviour.
What you ask is what I call this "pre-pick" pricing, meaning prices are calculated after the item is picked (isSelected=true) (which can be derived from isDefault=true if the POST QUERY is the first creation of a computed ProductConfiguration).
basic rules:
there are several options, I will just share two as this is a long discussion.
This is not a TMF forum API/ODA component problem, so my preferred solution is to manage this elsewhere. A good solution is the fan-out, catalogue driven approach. A component can do:
-
-
fetch the Product Characteristic values from TMF620 (or equivalent)
-
for each Value, build one queryProductConfigurationItem (same PO, different selected configurationCharacteristic value).
- Hint: Derive its id and name from the PO and charValue for traceability
-
One TMF760 call, x requests, x ProductConfiguration computations in the response.
That component could be anything, UI, BFF, middleware, Experience Data Orchestration. That's your call.
It's a more complex approach but it's chemically pure, you don't touch the TMF API and it's scalable and reusable. It also enforces the separation between frontend and backend principle.
else, if you're vendor independent, you can also extend the API. Incidentally, this is what we chose ππ± (main reason was this was a POC and we wanted a solution that can be implemented in just a few days). I do not recommend it but it's do-able.
for instance:
"configurationCharacteristic": [
{
"@type": "ConfigurationCharacteristic",
"name": "bandwidth",
// + other attributes
"configurationCharacteristicValue": [
{
"@type": "ConfigurationCharacteristicValue",
// + other attributes
"characteristicValue": {
"@type": "StringCharacteristic",
"name": "bandwidth",
"value": "100 Mbps",
// + other attributes
},
"valueConfigurationPrice": [
{
"@type": "ConfigurationPrice",
"name": "Monthly charge",
"priceType": "recurring",
"productOfferingPrice": {
"@type": "ProductOfferingPriceRef",
"id": "pop-100",
"@referredType": "ProductOfferingPrice"
},
"price": {
"@type": "Price",
"taxIncludedAmount": { "value": xxx, "unit": "xxx" }
}
}
]
It only extends the schema, it's not harming anything else in the API. API will be compliant and interoperability is the same.
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------
Original Message:
Sent: Aug 14, 2025 11:55
From: Jan Brnka
Subject: Prices per characteristic in practice when using TMF760
Hello all,
I'm working on a TMF-compliant front-end using TMF760 β Product Configuration as part of an order capture flow (similar to TMFS003's "Fibre Contract" example).
In the UI mock-up from TMFS003, characteristic options (e.g. "Basic Speed", "Apple Green Box", "Max Storage") are displayed alongside their respective prices. That makes perfect sense for a good customer experience β the user sees the impact of each selection in real time.
However, I've noticed that TMF760's ConfigurationCharacteristic schema doesn't provide a direct link to pricing. The only pricing object is ConfigurationPrice, which isn't explicitly associated with a given characteristic value in the API model.
From the TMF760 user guide, the product configurator is expected to:
On user input, product configurator is invoked to recompute the product configuration. This may include recomputing characteristic values, list of (allowed) values, bundled offerings, pricing, and discounts.
And TMFS003 explicitly mentions that changes to configurable values have an immediate impact on displayed prices:
The front-end user can change any configurable value of the product
characteristics, and he can also unselect any option, with an immediate
impact on the prices displayed
At product offering level several product offering price rules are proposed, some of them
depending on the configuration of the product commercialized.
The Product Configuration API uses product
catalog data, policy data, and existing product inventory data to assist
engagement management systems with product configuration. Product
configuration may include setting and restricting characteristic values,
enforcing min/max on bundle offering groups and options, and
calculation of prices and discounts.
The Front-End deals directly with the Product Configurator to check user
choices, display impacts on prices but also possible other selection,
configuration - or configuration issue.
Moreover, TMFC027 says:
Product Configurator: It supports the Product Order Capture and Validation component (TMFC002) to:
-
Product configuration includes computation of characteristics values, allowed values, bundled and related product offering, pricing and discounts
Relevant TMF760 model structure (simplified)
Characteristic
-
ID / Name β Unique identifier and label.
-
Value Type β Data type (text, numeric, etc.).
-
Relationships β Links to other characteristics.
ConfigurationCharacteristic
-
ID / Name / Description β Identifiers and human-readable details.
-
Cardinality β Min/max number of values allowed.
-
Value Type β The kind of value (text, numeric, etc.).
-
Is Configurable β Whether the user can set this value.
-
Relationships β Dependencies between characteristics.
-
Characteristic Values β List of selectable or assigned values.
ConfigurationCharacteristicValue
-
Is Selectable / Is Selected β Whether the value can be chosen and whether it is currently chosen.
-
Range Interval β Whether range values are inclusive/exclusive.
-
Unit of Measure β E.g. GB, months, metres.
-
Value From / Value To β Numeric ranges where applicable.
-
Characteristic Value β Points back to the base Characteristic.
ConfigurationPrice
-
Name / Description β Identifiers and purpose of the price.
-
Product Offering Price Ref β Reference to a price in the catalogue.
-
Recurring Charge Period β Period for recurring charges.
-
Unit of Measure β If price is usage-based (e.g. GB, SMS).
-
Price Amounts β Tax included, duty free, percentage, tax rate.
-
Price Alterations β Discounts or allowances applied.
-
Price Type β Recurring or non-recurring.
The gap: There is no defined attribute to directly associate a ConfigurationPrice with a specific ConfigurationCharacteristicValue. This makes it unclear how to return prices "per option" in a standard-compliant way.
My question is:
How are people modelling or returning prices per characteristic in practice when using TMF760, given that the API spec itself doesn't define a direct linkage?
Important note: Displaying raw prices directly from the product catalogue on UI isn't an option in this case. All prices can be influenced by policies and contextual factors β such as customer segment, sales channel, active opportunity or quote, existing product usage, and more. There should be a single point of truth for pricing, with all calculations performed in one place β is it the product configurator? This way, both prices shown in the UI and prices stored in the quote will originate from the same source.
------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------