when you want to pass the subscriber's contact in product order, be it postal address or phone number, it is a contact medium of a partyrole having a role as subscriber, you can use relatedParty->partyOrPartyRole->PartyRole->contactMedium . For these resources , please refer to TMF669 - Party Role Management API.
Original Message:
Sent: Feb 08, 2024 10:08
From: Akshay Sahni
Subject: Characteristics resource modelling as per TMF 620 Open API
Hello Varun,
You might want to have a look at the TMF760 Product Configuration API. The configuration API has a "quantity" attribute to support configuration items. You may then map each configurationItem into a single/multiple productOrderItems.
------------------------------
Akshay Sahni
Orange
Original Message:
Sent: Jan 23, 2024 19:24
From: Varun Pandhi
Subject: Characteristics resource modelling as per TMF 620 Open API
Thanks Matthieu, this helps. But, there can be other cases as well where customer address might not point to exact location where service is to be installed and/or the contact details being passed on here be the contact details of end user and not some contact related to customer.
And, also would be great if someone can throw some light around interpreting cardinalities defined between product offerings in TMF 620 and interpreting in TMF 622 -
Can the cardinalities mentioned in BundleProductOfferingOption (e.g. 0..20) translate into single ProductOrderItem with quantity mentioned in ordering, meaning lets say, customer buys 10 instances of Analog Hardware, what could it translate to ?
- One ProductOrderItem (with quantity = 10) and Product instance in ProductOrder and ProductInventory APIs respectively, or,
- 10 ProductOrderItems having their own respective Product instances in Product Order and ProductInventory APIs respectively?
What is suitable/advised/possible/recommended as per TMF under which scenario?
------------------------------
Varun Pandhi
Infosys
Original Message:
Sent: Jan 18, 2024 04:41
From: Matthieu Hattab
Subject: Characteristics resource modelling as per TMF 620 Open API
TL;DR,
I wouldn't expect a building address for a virtual line...
assuming that the end-to-end process is done with orders, (product order, service order, ressource order). generic info about customer must be on the order header (we do that for customer data, which we never "store" at characteristic level).
your core commerce and Production domain should use the data available at order header level.
in IG1228 and GB922 Product , there are examples of product models that could inspire you.
you will see in these documents that there relationships between productspec can define dependencies: PS B requires PS A, which can help you normalise your characteristics.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jan 16, 2024 09:57
From: Varun Pandhi
Subject: Characteristics resource modelling as per TMF 620 Open API
Hi all,
We are trying to come up with TMF model for POTSOLVE product and export it in TMF 622 Open API compliant format. Sample product model for the same is depicted below (For the sake of simplicity, prices are ignored from the diagram, though they are present on the child product offerings like Analog Hardware, Onsite Install etc. BundledProductOfferingOption is depicted as cardinalities on top of the bundledProductOfferings for the sake of simplicity E.g. 0..20 meaning numberRelOfferLowerLimit = 0 and numberRelOfferUpperLimit = 20):
We have few characteristics which are common to all these child product offerings (List of characteristics below) and expected to be provided as input as part of the product order. These also need to be passed on to downstream activation and provisioning systems as they have provisioning impact, hence I believe should be present on CustomerFacingServiceSpecs as well?
- Building Address
- Demarc Point
- Contact Name
- Contact Email
- Contact Phone
How should we model such characteristics as per TMF best practices? Options -
Option 1: Create these characteristic specifications on each of the component Product Offerings and their ProductSpecifications in above model using ProdSpecCharValueUse and prodSpecCharacteristic respectively and further model them on CustomerFacingServiceSpec as well
Will result in proliferation of characteristics and with some magic rules needed in Ordering to request input for only one of those product offerings and copy values to others
Option 2: Create these characteristic specifications on each of the child Product offerings in above model using ProductOfferingCharValue and further model them on CustomerFacingServiceSpec as well (Don't model on ProductSpecification)
Will result in proliferation of characteristics and with some magic rules needed in Ordering to request input for only one of those product offerings and copy values to others
Option 3: Model a Product Specification for POTSOLVE SingleDemarcService product offering and its CustomerFacingServiceSpec as well and follow Option 1 or Option 2 for modelling characteristic specifications at ProductOffering, ProductSpecification and CustomerFacingServiceSpecification or at ProductOffering and CustomerFacingServiceSpecification only.
We could observe that Open API doesnt restrict us from creating a Product Specification for Product Offering (IsBundle = true), but SID doesn't incline to this thought.
Option 4: Create another mandatory child Product offering under "POTSOLVE SingleDemarcService" which will house all these characteristics as per option 1 or option 2
What could be best possible way forward here? Or are there any better alternatives?
On a side note, we have a fulfillment characteristic (Tracking ID) too which will be modelled at Product offering since its visible to the customer but the value will not be received until it is not filled in by provisioning systems.
One more question, the can the cardinalities mentioned in BundleProductOfferingOption (e.g. 0..20) translate into single ProductOrderItem with quantity mentioned in ordering, meaning lets say, customer buys 10 instances of Analog Hardware, what could it translate to ?
- One ProductOrderItem (with quantity = 10) and Product instance in ProductOrder and ProductInventory APIs respectively, or,
- 10 ProductOrderItems having their own respective Product instances in Product Order and ProductInventory APIs respectively?
What is suitable/advised/possible/recommended as per TMF under which scenario?
------------------------------
Varun Pandhi
Infosys
------------------------------