(Just picking up this thread again)
Yes, that would make sense too.
I can see two main strategies:
1. Use OrderItem level fields to represent to-be state and product-level for data recorded on the current product-instance.
2. Use OrderItem level fields to represent transient, order-time, data and product-level for to-be product state.
There are flaws in implementing both - you can't model to-be product characteristic values in (1) and you can't model order-time/transient characteristics in (2).
What others strategies are followed?
------------------------------
Alasdair MacLeod
BT Group plc
------------------------------
Original Message:
Sent: Aug 30, 2021 03:21
From: Koen Peeters
Subject: TMF622 OrderTerm vs ProductTerm
The conventions for this are not imposed by TMF in the current state of the openAPI.
This is my take on this:
- orderItem/itemTerm: used for terms that are relevant for the fulfillment process only e.g. expectCustomsClearanceDelay
- orderItem/product/productTerm: used for terms that have a lasting effect on the product: minimumContractDuration, terminationNoticePeriod.
But any other convention could be as good as mine.
------------------------------
Koen Peeters
Ciminko Luxembourg
Original Message:
Sent: Aug 26, 2021 17:26
From: Alasdair MacLeod
Subject: TMF622 OrderTerm vs ProductTerm
Hello,
TMF622 describes two term objects:
orderItem/itemTerm
orderItem/product/productTerm
Are there conventions for when each is used? The spec doesn't say much. There is no "role" or other discriminator in these blocks.
------------------------------
Alasdair MacLeod
BT Group plc
------------------------------