Hi,
my understanding so far is different: "
the class name is a bit misleading, it shouldn't contain the term "valueUse" because it doesn't represent values, but characteristics"
Ig you look at it from the product definition process side, "ValueUse" totally makes sense: You first define the PS with its Characteristics and possible values (e.g. a mobile phone might have "Color" with values "Black", "White", "Gold", and the decide on the PO level that for your specific PO (that you sell to a specific market segment or only thriugh one channel ...) you offer only the "Black" and "White" ones, but not the "Gold", i.e. your PO "uses" only two of the possible values.
And yes, then you can use the link from the POP to the ValueUse to differentiate the price according to the chosen color.
My case is then that the Characteristic does not have enumerable values like the color, but is from some range; on PS level I would only express through a Value that the range is from/to; and for one PO I would then like to be able to subdevide the range into intervals, and for each interval to assign a different price; for another PO for the same PS, I might need different intervals.
Vance in his above solution states that on the PS I would need to have a Value with from/to expressing the whole possible range, and for the PO I would need for each interval a ValueUse, each "containing" a new Value with respective from/to;
this will work, but the problem that I have with this is that the Value objects "belong" to both levels, that of the PS and the PO; this could easily be avoided if one adds a from/to to the ValueUse, then we do not need the additional Value objects.
------------------------------
Lutz Bettge
Deutsche Telekom AG
------------------------------
Original Message:
Sent: Jun 10, 2022 03:59
From: Matthieu Hattab
Subject: How to model staggered prices
Hi,
I assume you want to talk about API TMF620.
The problem is that ProductSpecificationCharacteristicValueUse does not have valueFrom/valueTo attributes.
That's correct, in my opinion, the class name is a bit misleading, it shouldn't contain the term "valueUse" because it doesn't represent values, but characteristics
You do have valueUse in the child class CharacteristicValueSpecification
you have an illustration of POP -> char -> charvalue class relationships on page 43 in the API documation.
A simplified JSON of POP with the "Use"
pattern would look like:
GET /tmf-api/productCatalogManagement/v4/productOfferingPrice/1234
returns:
id = 1234
name = Recurring Charge 1-10GB
price = €10
[...]
prodSpecCharValueUse [
name = Size or Storage
@type = ProductSpecificationCharacteristicValueUse
productSpecCharacteristicValue [
id = 110
valueFrom = 1
valueto = 10
unitOfMeasure = GB
@type = CharacteristicValueSpecification
]
]
@Vance Shipley, you show valueFrom and valueTo at ProductSpecificationCharacteristicValueUse level. in our implementation, we will put them at CharacteristicValueSpecification level, that how we understood the API documentation.
PS: POP and the Use pattern is the same as with PO and you have an example of PO with Use on page 41
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jun 09, 2022 09:33
From: Lutz Bettge
Subject: How to model staggered prices
Hi folks,
we are trying to model staggered prices in the Product Catalog. The price of Products (instances of a given ProductOffering) depends on the actual value of a ProductCharacteristic (e.g. the size of storage), where the range of possible values is devided into intervals, and the price of the Products depends on the interval; e.g. from 1 to 10 GB there is a different price as from 11 to 30 GB etc.
I imagin that for the ProductOffering's ProductSpecification there is a ProductSpecificationCharacteristic "size or storage", and a ProductSpecificationCharacteristicValue defining via valueFrom/valueTo that the possible values are in the range of 1GB to 100GB.
On the ProductOffering side one should then have for each of the intervals a ProductSpecificationCharacteristicValueUse, each defining by a valueForm/valueTo attributes the interval; then one could link different ProductOfferingPrices to each of the ProductSpecificationCharacteristicValueUseValueUse.
With that the actual Charcteristic.value for a Product could be matched against the ProductSpecificationCharacteristicValueUseValueUse, and the corresponding POPrice coudl be identified.
The problem is that ProductSpecificationCharacteristicValueUse does not have valueFrom/valueTo attributes.
Is there any other way to model such a staggered price?
Or should valueFrom/valueTo be added to ProductSpecificationCharacteristicValueUseValueUse?
Cheers,
Lutz
------------------------------
Lutz Bettge
Deutsche Telekom AG
------------------------------