Open APIs

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

I am comparing the unitOfMeasure attribute defined by Quantity object, usually under ProductOfferingPrice with the CartPrice in Shopping Cart (TMF 663)

"unitOfMeasure": { "amount": 28, "units": "mbps"  }

Regards,

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

If you store bandwidth values in UoM. I understand you would have a problem with TMF663. UoM has a dependency on priceType.

in your example, a specChar should represent the bandwidth and the charValue represent the 28 Mbps speed value.
But I agree with you that consistencies between entities, attributes etc are important.

@Jonathan Goldberg, in the next version of the APIs, could you add some relevant examples?
there's been a few recent discussions from members who need clarification on UoM in TMF620 and/or other commerce APIs.
especially examples that illustrate how UoM relate to priceType

I am comparing the unitOfMeasure attribute defined by Quantity object, usually under ProductOfferingPrice with the CartPrice in Shopping Cart (TMF 663)

"unitOfMeasure": { "amount": 28, "units": "mbps"  }

Regards,

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

Hi

The xxxPrice schemas (CartPrice, OrderPrice, ProductPrice, etc.) all have a price element that gives actual money amounts (value and currency). They also have this unitOfMeasure element whose purpose, to be honest, is not clear to me. My guess is that they are trying to say that the price is per GB, or SMS volume, or whatever. However, the actual quantity is not part of these schemas but rather in some characteristic on the product within the order/cart (and no indication here about which characteristic).

This does not look like an ideal contract to me, and maybe the model needs to be rethought, but I can't imagine that any change will happen now in v5 since some of the APIs are already published. I'll in any case open a JIRA for internal discussion, but my inclination would be to ignore the unitOfMeasure property completely, and eventually deprecate/delete it.

Apologies for the delayed response.

If you store bandwidth values in UoM. I understand you would have a problem with TMF663. UoM has a dependency on priceType.

in your example, a specChar should represent the bandwidth and the charValue represent the 28 Mbps speed value.
But I agree with you that consistencies between entities, attributes etc are important.

@Jonathan Goldberg, in the next version of the APIs, could you add some relevant examples?
there's been a few recent discussions from members who need clarification on UoM in TMF620 and/or other commerce APIs.
especially examples that illustrate how UoM relate to priceType

I am comparing the unitOfMeasure attribute defined by Quantity object, usually under ProductOfferingPrice with the CartPrice in Shopping Cart (TMF 663)

"unitOfMeasure": { "amount": 28, "units": "mbps"  }

Regards,

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

Hi Jonathan,

we are using the unitOfMeasure in the price elements exactly for the purpose you mention; but it is a Quantity, so it is easier to parse, and also can be taken over from the corresponding elements in the catalog.

We also added a "quantity" attribute (or type Quantity) to Product, so it is possbile to state how much resp. how many of the ProductOffering has been purchased; this is important in two cases:

• when there is no way or does not make sense to identify individual instances of the product, e.g. when it is a length of cable, size or weight of something, etc.
• when it is not necessary to distinguish the individual instances of the product, because they do not carry any characteristics that distinguish them from each other; for example the licenses of a business software; for a large enterprise customer with thousands of employees, it does not make sense to have a separate Product for each license, but it is sufficient to just count the licenses.

With this information we then can calculate the proce to be charged, by (1) deviding the Product.quantity by ProductPrice.unitOfMeasure, including conversion of units when necessary, (2) rounding up to the next integer, and (3) multiplying with the ProductPrice.Price.dutyFreeAmount/taxIncludedAmount.

To be able to do that without having to parse a string, we changed unitOfMeasure to Quantity.

Hi

The xxxPrice schemas (CartPrice, OrderPrice, ProductPrice, etc.) all have a price element that gives actual money amounts (value and currency). They also have this unitOfMeasure element whose purpose, to be honest, is not clear to me. My guess is that they are trying to say that the price is per GB, or SMS volume, or whatever. However, the actual quantity is not part of these schemas but rather in some characteristic on the product within the order/cart (and no indication here about which characteristic).

This does not look like an ideal contract to me, and maybe the model needs to be rethought, but I can't imagine that any change will happen now in v5 since some of the APIs are already published. I'll in any case open a JIRA for internal discussion, but my inclination would be to ignore the unitOfMeasure property completely, and eventually deprecate/delete it.

Apologies for the delayed response.

If you store bandwidth values in UoM. I understand you would have a problem with TMF663. UoM has a dependency on priceType.

in your example, a specChar should represent the bandwidth and the charValue represent the 28 Mbps speed value.
But I agree with you that consistencies between entities, attributes etc are important.

@Jonathan Goldberg, in the next version of the APIs, could you add some relevant examples?
there's been a few recent discussions from members who need clarification on UoM in TMF620 and/or other commerce APIs.
especially examples that illustrate how UoM relate to priceType

I am comparing the unitOfMeasure attribute defined by Quantity object, usually under ProductOfferingPrice with the CartPrice in Shopping Cart (TMF 663)

"unitOfMeasure": { "amount": 28, "units": "mbps"  }

Regards,

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.

We discussed this briefly in the Open API governance call today.

I think we first need to understand what is the meaning of the property xxxPrice.price - this contains the money amounts before and after tax. Could be

• EITHER - the final money amount, with no additional calculations needed
• OR - the money amount subject to additional calculations as Lutz described in his reply (e.g. for quantity, or for unit price)

In my opinion, there is no question that the first option is far more appropriate - the final money amount. Consider that consumers of these APIs will be retrieving product orders or products, e.g. for display the cost to end customers. It makes no sense that the API consumer will need to make additional calculations. Consumers cannot be responsible for financial calculations.

Hi Jonathan,

we are using the unitOfMeasure in the price elements exactly for the purpose you mention; but it is a Quantity, so it is easier to parse, and also can be taken over from the corresponding elements in the catalog.

We also added a "quantity" attribute (or type Quantity) to Product, so it is possbile to state how much resp. how many of the ProductOffering has been purchased; this is important in two cases:

• when there is no way or does not make sense to identify individual instances of the product, e.g. when it is a length of cable, size or weight of something, etc.
• when it is not necessary to distinguish the individual instances of the product, because they do not carry any characteristics that distinguish them from each other; for example the licenses of a business software; for a large enterprise customer with thousands of employees, it does not make sense to have a separate Product for each license, but it is sufficient to just count the licenses.

With this information we then can calculate the proce to be charged, by (1) deviding the Product.quantity by ProductPrice.unitOfMeasure, including conversion of units when necessary, (2) rounding up to the next integer, and (3) multiplying with the ProductPrice.Price.dutyFreeAmount/taxIncludedAmount.

To be able to do that without having to parse a string, we changed unitOfMeasure to Quantity.

Hi

The xxxPrice schemas (CartPrice, OrderPrice, ProductPrice, etc.) all have a price element that gives actual money amounts (value and currency). They also have this unitOfMeasure element whose purpose, to be honest, is not clear to me. My guess is that they are trying to say that the price is per GB, or SMS volume, or whatever. However, the actual quantity is not part of these schemas but rather in some characteristic on the product within the order/cart (and no indication here about which characteristic).

This does not look like an ideal contract to me, and maybe the model needs to be rethought, but I can't imagine that any change will happen now in v5 since some of the APIs are already published. I'll in any case open a JIRA for internal discussion, but my inclination would be to ignore the unitOfMeasure property completely, and eventually deprecate/delete it.

Apologies for the delayed response.

If you store bandwidth values in UoM. I understand you would have a problem with TMF663. UoM has a dependency on priceType.

in your example, a specChar should represent the bandwidth and the charValue represent the 28 Mbps speed value.
But I agree with you that consistencies between entities, attributes etc are important.

@Jonathan Goldberg, in the next version of the APIs, could you add some relevant examples?
there's been a few recent discussions from members who need clarification on UoM in TMF620 and/or other commerce APIs.
especially examples that illustrate how UoM relate to priceType

I am comparing the unitOfMeasure attribute defined by Quantity object, usually under ProductOfferingPrice with the CartPrice in Shopping Cart (TMF 663)

"unitOfMeasure": { "amount": 28, "units": "mbps"  }

Regards,

There are several unitOfMeasure in TMF620. Which one are you trying to compare with the shopping Cart API?

The unitOfMeasure attribute defined in the CartPrice entity is a String (as shown below).  

Whereas the same unitOfMeasure attribute in TMF620 Product Catalog is defined as an object (as shown below)

This inconsistency needs to be removed, since the client application needs to do some juggulery to consume both the APIs.