Open APIs

Hi

We are looking to implement pricing dependent on ProductSpecificationCharacteristics. For ex. Data volume = 500 Mb, has a recurring charge of 5$, for 1 GB Data volume recurring charge of 10$ and so on…

Our earlier understanding was that we could achieve this by defining policy rules. However, on further examining the V5 specification of the TMF620, we found that:

The ProductOfferingPrice entity can be associated to a ProductSpecificationCharacteristic of the corresponding ProductSpecification.  

Query: Are we correct in assuming, that the intended use case for associating the " ProductSpecificationCharacteristic" to the "ProductOfferingPrice" entity is to manage use case  listed above?

Also, in case our understanding is correct, would you recommend using the POP->PSCharacteristic association, over policy rules? (This would greatly simplify the definition of different charges, rather than creating an additional object of policy rule for the end user/CSR executive)

thanks

Salut Olivier,

You can use Policy (I'm myself investigating for a policy software component) if you want 100% of pricing rules to be managed in a single entity.
but in this case, the TM Forum recommendation is to use the "valueuse" pattern, which allows you to associate a POP with a characteristic or a characteristic/value pair.

Outside Telecom, we typically call this "attribute-based pricing".

You should definitely check this community, we have talked about it (inlcuding its limitation, possible improvement like variant pricing), search for "ProductSpecificationCharacteristicValueUse"

Here is an example of how we use it today for digital sales:

business view of the offer:

and this is what the TMF620 API returns (GET) when I query the default price
(In the interest of comprehension, I simplified the JSON)

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PPSCVU0050",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {        "isDefault": true,                    "key": "100_100",                    "value": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                },                {                    "isDefault": false,                    "key": "150_150",                    "value": "150/150 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

If you model an offer with a single ProductSpecificationCharacteristicValueUse, there are other options to explore.

This is available in the V4 API spec, policy is available from V5.

hope this helps!

Hi

We are looking to implement pricing dependent on ProductSpecificationCharacteristics. For ex. Data volume = 500 Mb, has a recurring charge of 5$, for 1 GB Data volume recurring charge of 10$ and so on…

Our earlier understanding was that we could achieve this by defining policy rules. However, on further examining the V5 specification of the TMF620, we found that:

The ProductOfferingPrice entity can be associated to a ProductSpecificationCharacteristic of the corresponding ProductSpecification.  

Query: Are we correct in assuming, that the intended use case for associating the " ProductSpecificationCharacteristic" to the "ProductOfferingPrice" entity is to manage use case  listed above?

Also, in case our understanding is correct, would you recommend using the POP->PSCharacteristic association, over policy rules? (This would greatly simplify the definition of different charges, rather than creating an additional object of policy rule for the end user/CSR executive)

thanks

Salut Olivier,

You can use Policy (I'm myself investigating for a policy software component) if you want 100% of pricing rules to be managed in a single entity.
but in this case, the TM Forum recommendation is to use the "valueuse" pattern, which allows you to associate a POP with a characteristic or a characteristic/value pair.

Outside Telecom, we typically call this "attribute-based pricing".

You should definitely check this community, we have talked about it (inlcuding its limitation, possible improvement like variant pricing), search for "ProductSpecificationCharacteristicValueUse"

Here is an example of how we use it today for digital sales:

business view of the offer:

and this is what the TMF620 API returns (GET) when I query the default price
(In the interest of comprehension, I simplified the JSON)

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PPSCVU0050",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {        "isDefault": true,                    "key": "100_100",                    "value": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                },                {                    "isDefault": false,                    "key": "150_150",                    "value": "150/150 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

If you model an offer with a single ProductSpecificationCharacteristicValueUse, there are other options to explore.

This is available in the V4 API spec, policy is available from V5.

hope this helps!

Hi

We are looking to implement pricing dependent on ProductSpecificationCharacteristics. For ex. Data volume = 500 Mb, has a recurring charge of 5$, for 1 GB Data volume recurring charge of 10$ and so on…

Our earlier understanding was that we could achieve this by defining policy rules. However, on further examining the V5 specification of the TMF620, we found that:

The ProductOfferingPrice entity can be associated to a ProductSpecificationCharacteristic of the corresponding ProductSpecification.  

Query: Are we correct in assuming, that the intended use case for associating the " ProductSpecificationCharacteristic" to the "ProductOfferingPrice" entity is to manage use case  listed above?

Also, in case our understanding is correct, would you recommend using the POP->PSCharacteristic association, over policy rules? (This would greatly simplify the definition of different charges, rather than creating an additional object of policy rule for the end user/CSR executive)

thanks

Hi Matthieu

thanks, it's very clear.

best regards

Olivier

Salut Olivier,

You can use Policy (I'm myself investigating for a policy software component) if you want 100% of pricing rules to be managed in a single entity.
but in this case, the TM Forum recommendation is to use the "valueuse" pattern, which allows you to associate a POP with a characteristic or a characteristic/value pair.

Outside Telecom, we typically call this "attribute-based pricing".

You should definitely check this community, we have talked about it (inlcuding its limitation, possible improvement like variant pricing), search for "ProductSpecificationCharacteristicValueUse"

Here is an example of how we use it today for digital sales:

business view of the offer:

and this is what the TMF620 API returns (GET) when I query the default price
(In the interest of comprehension, I simplified the JSON)

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PPSCVU0050",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {        "isDefault": true,                    "key": "100_100",                    "value": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                },                {                    "isDefault": false,                    "key": "150_150",                    "value": "150/150 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

If you model an offer with a single ProductSpecificationCharacteristicValueUse, there are other options to explore.

This is available in the V4 API spec, policy is available from V5.

hope this helps!

Hi

We are looking to implement pricing dependent on ProductSpecificationCharacteristics. For ex. Data volume = 500 Mb, has a recurring charge of 5$, for 1 GB Data volume recurring charge of 10$ and so on…

Our earlier understanding was that we could achieve this by defining policy rules. However, on further examining the V5 specification of the TMF620, we found that:

The ProductOfferingPrice entity can be associated to a ProductSpecificationCharacteristic of the corresponding ProductSpecification.  

Query: Are we correct in assuming, that the intended use case for associating the " ProductSpecificationCharacteristic" to the "ProductOfferingPrice" entity is to manage use case  listed above?

Also, in case our understanding is correct, would you recommend using the POP->PSCharacteristic association, over policy rules? (This would greatly simplify the definition of different charges, rather than creating an additional object of policy rule for the end user/CSR executive)

thanks

Thanks Matthieu for your exposition. I am not convinced that the current POP model is the most efficient way to express price variations for characteristic values, especially if there are multiple dimensions for price. Policy can certainly be used for this (in v5), but also that leads to complexity. I would like to see a simpler representation for price variation with characteristics. I may be able to devote some time to this after we've calmed down from the v5 publication and DTW in the coming weeks.

@Ola Olagoke as to your question you can use the fields directive, as described in the design guidelines TMF630, to limit the amount of data (payload size) that returns on GET.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Sep 12, 2023 12:58
From: Olivier Arnaud
Subject: TMF620 Product Catalog policy vs price-spec association

Hi Matthieu

thanks, it's very clear.

best regards

Olivier

------------------------------
Olivier Arnaud
Orange

Original Message:
Sent: Aug 31, 2023 07:21
From: Matthieu Hattab
Subject: TMF620 Product Catalog policy vs price-spec association

Salut Olivier,

You can use Policy (I'm myself investigating for a policy software component) if you want 100% of pricing rules to be managed in a single entity.
but in this case, the TM Forum recommendation is to use the "valueuse" pattern, which allows you to associate a POP with a characteristic or a characteristic/value pair.

Outside Telecom, we typically call this "attribute-based pricing".

You should definitely check this community, we have talked about it (inlcuding its limitation, possible improvement like variant pricing), search for "ProductSpecificationCharacteristicValueUse"

Here is an example of how we use it today for digital sales:

business view of the offer:

and this is what the TMF620 API returns (GET) when I query the default price
(In the interest of comprehension, I simplified the JSON)

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PPSCVU0050",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {        "isDefault": true,                    "key": "100_100",                    "value": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                },                {                    "isDefault": false,                    "key": "150_150",                    "value": "150/150 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

If you model an offer with a single ProductSpecificationCharacteristicValueUse, there are other options to explore.

This is available in the V4 API spec, policy is available from V5.

hope this helps!

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Aug 30, 2023 16:59
From: Olivier Arnaud
Subject: TMF620 Product Catalog policy vs price-spec association

Hi

We are looking to implement pricing dependent on ProductSpecificationCharacteristics. For ex. Data volume = 500 Mb, has a recurring charge of 5$, for 1 GB Data volume recurring charge of 10$ and so on…

Our earlier understanding was that we could achieve this by defining policy rules. However, on further examining the V5 specification of the TMF620, we found that:

The ProductOfferingPrice entity can be associated to a ProductSpecificationCharacteristic of the corresponding ProductSpecification.  

Query: Are we correct in assuming, that the intended use case for associating the " ProductSpecificationCharacteristic" to the "ProductOfferingPrice" entity is to manage use case  listed above?

Also, in case our understanding is correct, would you recommend using the POP->PSCharacteristic association, over policy rules? (This would greatly simplify the definition of different charges, rather than creating an additional object of policy rule for the end user/CSR executive)

thanks

------------------------------
Olivier Arnaud
Orange
------------------------------