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?
------------------------------
Lutz Bettge
Deutsche Telekom AG
------------------------------