Figure Pr.05c - BundleProductOffering Details : Class diagram
Created: 3/28/2022 3:51:09 PM
Modified: 4/29/2022 3:12:54 PM
Project:
Advanced:
In some cases, there are limits to the number of ProductOfferings that can be procured as part of a BundledProductOffering.  For example, when subscribing to a mobile telephone service up to five phones can be procured at a special price.  The BundledProdOfferOption handle these cases by allowing lower and upper limits to be set for ProductOfferings that comprise a BundledProductOffering as shown in Figure Pr.5c. The figure also shows via the defaultRelOfferNumber attribute that is used to initialize the number of ProductOffering instances when ordering the ProductOffering that is contained within an instance of BundledProductOffering.<br/>Some Information Framework users may want a ProductOffering instance that is part of a BundledProductOffering instance to not be individually procurable. For example, a free SMS offering cannot be procured by itself. A separate SimpleProductOffering can be created to allow for add-on SMS service. Other Information Framework users may feel that that this may result in ProductOffering instance explosion. They want a ProductOffering instance that is part of a BundledProductOffering instance to be individually procurable rather than creating another instance of ProductOffering that is individually procurable. <br/>Prior to release 17.5 of this guide book these two options were described as implementation options. In release 17.5 an isSellableStandAlone attribute shown in Figure Pr.5c was added satisfy the needs of both groups of users. If the isSellableStandAlone attribute is TRUE, it indicates that a ProductOffering instance, which is part of a BundledProductOffering instance, can also be offered stand-alone, if FALSE means that the ProductOffering instance can only be acquired within a BundledProductOffering instance. NOTE: This attribute only applies to offering instances (bundles and simple offerings) that are part of a BundledProductOffering instance.<br/>There are some considerations that can be taken into account to assist in determining when this attribute should be set to FALSE or TRUE for applicable instances of ProductOffering.<br/>If the attribute is set to FALSE there is an increase in the number of ProductOffering instances as previously mentioned.<br/>If the attribute is set to TRUE and associations to all related entity instances, such as, but not limited to, ProductOfferingPrice and ProdSpecCharValueUse, remain the same there are no other considerations.<br/>If the attribute is set to TRUE and some associations, such as, but not limited to, ProductOfferingPrice and ProdSpecCharValueUse, are to different instances of these entities then there are other considerations. Note that this is not a complete list of considerations, but each association should be should be analyzed to determine if the ProductOffering instance is related to different entity instances:<br/>        • Requires the use of the Product Offering Price Rule ABE to define a rule to determine the price for the ProductOffering in the bundle and the price for the stand-alone ProductOffering. This introduces approximately 20 policy entity instances to define the rules rather than creating an additional instance of a ProductOffering.<br/>        • For a ProductOffering instance there may be different instances of ProdSpecCharValueUse that apply to the offering when it is part of a bundle versus when it is sellable stand-alone. For example, a single device color may be made available in a bundle, but multiple colors available for the stand-alone offering. It appears that this consideration may require the creation of an association between ProdSpecCharValueUse and BundledProdOfferOption; the current association between ProductOffering and ProdSpecCharValueUse could be used for the stand-alone offering.<br/>        • For a ProductOffering instance there may be different instances of ProductOfferingTerm that apply to the offering when it is part of a bundle versus when it is sellable stand-alone. For example, a device in a bundle may have a different agreement length than for the stand-alone offering. It appears that this consideration may require the creation of an association between ProductOfferingTerm and BundledProdOfferOption; the current association between ProductOffering and ProductOfferingTerm could be used for the stand-alone offering.<br/>        • This is a catalog consideration that is based on if there is a price for the stand-alone offering and different price for the offering in a bundle. If the price is the same then it could appear once in the catalog as part of the bundle with a notation that it can be individually acquired. If there are different prices then a determination must be made on how to represent the prices. For example, both prices could be shown for the offering with a notation on the price for when the offering is acquired stand-alone.<br/>