Offer and Price Engine Price Model

OPE uses the price models to get the prices configured in the price catalog and correlates these prices to a given product based on relationship.

Price models can be loaded in the engine using the offline or the online integration, or both online and offline integration with TIBCO Fulfillment Catalog. For more information on integrating the price models offline, see Integrating TIBCO Fulfillment Catalog Price Models Offline. For more information on integrating the price models online, see Integrating TIBCO Fulfillment Catalog Discount Model Offline.

Pricing Fields

The following pricing fields are the basic fields applicable to all price types.

Pricing Field Description
RECORD_TYPE

This field defines the price type of the price. The valid values are TARIFFUSAGE, USAGE, FIXED, RECURRING, COMPOSITE, ONE_TIME, and MIGRATION_FEE.

Record Satus

This characteristic defines if a price is valid. If it is set to true the price is used for the calculation. If not, the price is ignored.

Start Date/Start Time, End Date/End Time, Duration/Duration UOM

These characteristics are used to define the validity of a price in a certain time frame. None of these fields are mandatory. If the End Date/End Time is not present, it is calculated based on the Start Date/Start Time and the Duration/Duration UOM if they are present. Duration UOM can have Year, Month, Week and Day as valid parameters. If only Start or End parameters are defined, only that boundary is taken into account to verify the validity of that price.

Charge Value

This characteristic is used to specify the amount in a dot separated manner.

Currency

This characteristic is used to specify the type of currency for the price.

Charge Priority

This characteristic is used if a product provides several prices, whereby the priority provides the system a way to choose what charge to bill the customer. Therefore the price with the higher Charge Priority is taken. Lower the number the higher the priority.

Min Amount

This field attributes the minimum amount a price can have. If a price is reduced by multiple discounts, it is possible to reduce the price to a negative amount. The MinAmount attribute prevents that as it sets the amount to the specified value if the price value falls below that limit. In the end, all kinds of price and discount selections are done and all discounts, which are attached to the price, are returned even, if they have not been applied due to the MinAmount.

Price Types

The following pricing types can be used in the OPE Price Model:

Price Type Description
ONE_TIME price

This type specifies a non-recurring (one-off) charging element defined as fixed monetary values. This is modeled as a One-Time Price. One_Time prices are created by setting the Class to 'ONE_TIME'. CHARGE_PER, CHARGEMINBOUNDARY and CHARGEMAXBOUNDARY are not used.

RECURRING Price This type specifies recurring charging elements defined as monetary values. This is modeled in TIBCO Fulfillment Catalog as a RECURRING price. Recurring prices are created by setting the class to RECURRING.
Note: Prices with Boundaries should not be attached directly to a Product. The reason is that it is nearly impossible to distinguish if the Prices should coexist for a Product or if they rule each other out. To accomplish this coexistence, use a composite price and attach appropriate prices with boundaries as children to that composite price.
Usage Price
This type specifies usage-based charging elements defined as monetary values. This is modeled in TIBCO Fulfillment Catalog as a usage price. Usage prices are created by setting the class to USAGE.
Note: Prices with Boundaries should not be attached directly to a Product. The reason is that it is supported to distinguish if the Prices should coexist for a Product or if they rule each other out. To accomplish this coexistence use a composite price and attach appropriate prices with boundaries as children to that composite price.
COMPOSITE The composite price is not calculated as a price itself but is meant as a container for child prices. This container can be used to reuse the existing prices as children and put one discount on all these children.

Relationships

Restrictive relationships are used to make a price applicable only to certain compositions of products, segments or characteristics in a request. The following table explains the different types of relationships used and their behavior.

Relationship Description
ProductPricedBy

Prices are attached to a product using the ProductPricedBy relationship. This relationship has an attribute ChargePriority, which specifies the priority in which the charges should be applied in case there are multiple prices associated. If the ChargePriority attribute is equal for several prices, in a case of multiple prices of the same type, prices are chosen based on the restrictions it has. So if there are two valid prices configured for a product, the application takes the price with more and higher valued restrictions first.

Note: Choosing a mechanism is only performed for prices of the same class attached to the same product. For example, ONE TIME prices are not to be compared to RECURRING prices.
PriceRequiresSegment

The PriceRequiresSegment relationship is used to model prices, which should be offered only to customers belonging to a certain segment. Prices can have PriceRequiresSegment relationships to multiple Segments. In that case, the price only is only taken if all the segments are passed in the getPrices request.

Note: PriceRequiresSegment relationship is considered as the most important relationship when choosing between different prices for a product.
PriceRequiresProductGroup

The PriceRequiresProductGroup relationship is used to model prices which should only be offered when ordering a certain composition of products. The PriceRequiresProductGroup relationship is considered as the second highest after PriceRequiresSegment relationship when choosing between different prices for a product.

The PriceRequiresProductGroup repository has three flags in the Scope tab named CalculatedProducts, RelatedProducts and LinkedOnly. The CalculatedProducts and RelatedProducts flags define if the RequiresProductGroup only 'searches' in CalculatedProducts and in RelatedProducts passed in with the request. The LinkedOnly parameter defines if the search is only restricted to other CalculatedProducts and RelatedProducts sharing the same defined LinkDefinitions as the one the price must needs to be applied to both products to have the same Subscriber.

The default values for CalculatedProducts and RelatedProducts is true and false for LinkedOnly, the engine looks for all products specified in the request unless it is specifically configured in a different fashion in the RequiresProductGroup. If LinkDefinitions is not configured, it is set to SubscriberID by default.

PriceRequiresCharacteristic
The PriceRequiresCharacteristic relationship is used to model different prices for a product based on their characteristic value. Prices can have PriceRequiresCharacteristic relationships to multiple Characteristics.
Note: The PriceRequiresCharacteristic relationship is considered as the least important relationship when choosing between different prices for a product.
PriceComprisedOf Relationship for Price and Product

Prices on a bundle level are either aggregated prices of the underlying offerings or set directly on the bundle level and ignore the prices of the underlying offerings. Both product and price can have children, which are aggregated towards the parent. The SubClass attribute with value Override prevents this, and the price acts as an override. PriceComprisedOf relationship fulfills these requirements, but the Price.PriceComprisedOf relationship can be used to reuse multiple existing prices as children and attach a discount on all children by using the PriceAlteredByDiscount relationship on the parent level of the containing price. The override behavior of parent prices are transferred to all child prices. A child price has to have the same class as the parent otherwise it will be ignored on run time. To group multiple prices with different types, the composite price has to be used.