Hello,
thanks for the question and response - we are currently facing the same questions.
We have the requirement to also add, in addition to product-related key/value information, any other cart-related fields that might be required by systems retrieving transaction/order information once the payment has been completed.
Our goal is to define distinct and clear guidelines for the consumer of our TMF-compliant API TMF663.
Example 1 - contractID via setting:
For a specific product it is required to define a contractID when it is sold. This is reflected via characteristic/configuration of a product.
Solution 1a:
- The information/configuration that a contractID is required, is reflected via productCharacteristic (most likely also in TMF620).
- The contract itself is persisted in a custom key/value object (TMF663 enhancement) within the cartItem.
-> The guideline would be that only fields/keys also reflected in the product master data will result in productCharacteristics.
Solution 1b:
- The information/configuration that a contractID is required, is reflected via productCharacteristic (most likely also in TMF620).
- The contractID will also be stored as a productCharacteristic as its necessity is defined via productCharacteristic.
Example 2 - contractID via business logic:
For products, it is required to define a contractID when it is sold. This is not configured but is implicitly defined by the cart-creating system.
Solution 2a:
- The contract itself is persisted in a custom key/value object (TMF663 enhancement) within the cartItem.
Solution 2b:
- The contractID will also be stored as a productCharacteristic as its necessity is defined via productCharacteristic.
@ Jonathan Goldberg what is your view on the preferred solution?
Many thanks!
------------------------------
Robert Owen
NTS Retail KG
------------------------------
Original Message:
Sent: Feb 04, 2022 02:46
From: Jonathan Goldberg
Subject: 622 ProductOrder API - How do model the "expectedCompletionDate" on line level?
Hi Justin
Absolutely the first option, not the second. We should not "pollute" product inventory with characteristics/attribute that relate to the order.
As it happens, there is a rather old Jira issue on this, which you can see here if you are a member of the Open API project. If not, the salient text is to add the following at Item level:
- completionDate
- exepectedCompletionDate
- requestedStartDate
- requestedCompletionDate
@Ludovic Robert what do you say?
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Feb 03, 2022 13:49
From: Justin Yue
Subject: 622 ProductOrder API - How do model the "expectedCompletionDate" on line level?
Hi, we have a requirement to capture the "Expected/estimated Completion Date" on the line level as well. Currently we have the field on the ProductOrder, what's the recommended approach to have the extra date fields on the line level? A couple of options I can think about:
1) Extend the ProductOrderItem sub-resource to support additional date fields
2) Use ProductCharacteristic to host the date information
@Jonathan Goldberg
------------------------------
Justin Yue
Salesforce
------------------------------