Open APIs

In TMF620 (Product Catalog), the attribute unitOfMeasure of ProductOfferingPrice, ProductOfferingPriceRefOrValue, POPAlteration has type Quantity, i.e. two sub-attributes unit and amount.

In TMF637 (Product Inventory), the corresponding unitOfMeasure attributes of ProductPrice, PriceAlteration has type String, described as "Could be minutes, GB...", i.e. a unit only, no amount. Probably one could concatenate both into the string, but would it not be better to have type Quantity as well?

The same problem exists for other APIs containing Product and Price information, e.g. TMF622 (Product Ordering), TMF648 (Quote), TMF663 (Shopping Cart), TMF679 (Product Offering Qualification), even the DRAFT of TMF760 (Product Configuration) and should be corrected as well.

Also, I understand the unitOfMeasure is meant to represent some kind of amount of the Product to which the price has to be paid; correct?

What seems to be missing is some kind of "quantity" attribute into Product itself, so that one could state how much of a product has been bought (e.g. length of cable, weight of something, number of items if it does not make sense to represent each individual item as separate instance of class Product). That quantity (also having type Quantity, i.e. amount and unit) would then have to be devided by the unitOfMeasure to which the price relates, and multiplied by the price (which then is the pricePerUnitOfMeasure), i.e. by the price attributes in the Price object.

One might then also add "totalPrice" attributes to the Price object, for conveniance of consumers so that they do not have to do the described calculation, and to ensure that the calculation result does not differ between consumers (e.g. if the Productquantity is in GB, unitOfMeasure in MB, consumers might apply different rounding methods).

Does this make sense?

unitOfMeasure and priceType definition are not consistent across TM Forum documentation (SID, various APIs) the only correct definition I've read is in TMF645. Other definition are different and unclear.

example: the ProdOffer is "fiber optic cable" that you sell by 50 meters. There are many ways to model how customer can enter their desired quantity and how it is priced. Let's make easy and we let customer can enter an integer value in the prodSpecCharValue entity that is a multiple of 50.
the related price would have priceType = one-time and unitOfMeasure = {amount = 50, units = meter) and price = €250

customer needs 120 meters, so they must enter 150 meters (by rule) 
the price would then be calculated as 150m * 250/50.

for a mobile data plan, it's similar.

prodoffer is a monthly subscription that includes 20GB of 5G mobile data. It has 2 prices:

price 1 would have priceType = recurring and unitOfMeasure = {amount = 20, units = GB) and price = €10
-> the unitOfMeasure has no impact on the price, customer pays €10 per month no matter what.

price 2 would have priceType = usage and unitOfMeasure = {amount = 100, units = MB) and price = €3

-> the unitOfMeasure is used to calculated the price and the price is only calculated and charged if customer has emptied their monthly bucket (20GB)

In TMF620, it sure doesn't make sense. TMF663 and similar APIs (order, quote) already have it.
Where do you want it?

In TMF620 (Product Catalog), the attribute unitOfMeasure of ProductOfferingPrice, ProductOfferingPriceRefOrValue, POPAlteration has type Quantity, i.e. two sub-attributes unit and amount.

In TMF637 (Product Inventory), the corresponding unitOfMeasure attributes of ProductPrice, PriceAlteration has type String, described as "Could be minutes, GB...", i.e. a unit only, no amount. Probably one could concatenate both into the string, but would it not be better to have type Quantity as well?

The same problem exists for other APIs containing Product and Price information, e.g. TMF622 (Product Ordering), TMF648 (Quote), TMF663 (Shopping Cart), TMF679 (Product Offering Qualification), even the DRAFT of TMF760 (Product Configuration) and should be corrected as well.

Also, I understand the unitOfMeasure is meant to represent some kind of amount of the Product to which the price has to be paid; correct?

What seems to be missing is some kind of "quantity" attribute into Product itself, so that one could state how much of a product has been bought (e.g. length of cable, weight of something, number of items if it does not make sense to represent each individual item as separate instance of class Product). That quantity (also having type Quantity, i.e. amount and unit) would then have to be devided by the unitOfMeasure to which the price relates, and multiplied by the price (which then is the pricePerUnitOfMeasure), i.e. by the price attributes in the Price object.

One might then also add "totalPrice" attributes to the Price object, for conveniance of consumers so that they do not have to do the described calculation, and to ensure that the calculation result does not differ between consumers (e.g. if the Productquantity is in GB, unitOfMeasure in MB, consumers might apply different rounding methods).

Does this make sense?