The Open API doesn't do formal multiple inheritance, although in principle you could "inherit" (by inclusion) fields from multiple parent entities by having multiple $allof statements.
I would venture that appointment handling is more complex than a simple boolean. Typically you would need to know the skillset of the technician and the amount of work needed, and maybe additional information. I would suggest tentatively that you model this information as characteristics on ProductSpecification (presumably non-configurable at runtime), and these will then be available in the Search Time Slot task (TMF 646) in the Related Entity field (which would point to the Product Order, containing the Product and pointing to the Product Spec).
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Jul 23, 2019 03:00
From: Shibin CK
Subject: FieldOperationProductSpec
Hi,
The SID Product document referes to a sub class of ProductSpecification called FieldOperationProductSpec where an appointment is required for things like product installation. This Appointment object has to be captured from CRM and passed on to the order management via the appointment attribute of OrderItem in ProductOrder. The appointment is not part of Product characteristics. How should the ProductSpecification be modelled? Will it be as simple as adding an attribute "isAppointmentRequired" and changing @ type to FieldOperationProductSpec and @ baseType to ProductSpecification?.
I have a related question on the @ type. How should multiple inheritance be handled. What if it is both a FieldOperationProductSpec and a GoodsProductSpec. What should be the @ type ?
------------------------------
Shibin CK
Tecnotree
------------------------------