2 Catalog Entities

Learn about the catalog entities in Oracle Communications Launch Cloud Service application and how they relate to and work with each other.

How Entities Work Together

Use the following sections to understand the various entities in the Launch application and how they work together.

Types of Entities

Use the following table to understand the different entities and how they work together. Each entity is covered in a separate chapter later in this guide.

Table 2-1 List of Entities

Entity	Definition
Initiative	An initiative or project is a business requirement that encapsulates catalog definitions, enabling you to publish these entities to spoke systems. Spoke systems are downstream applications configured as Destinations in Oracle Communications Launch Cloud Service that receive catalog, pricing, and eligibility data published from Launch. For more information, see Initiatives Overview.
Service Specification	Service specifications reflect the attributes associated with a service, for example, data service or voice service. For more information, see Service Specification Overview.
Product Specification	Product specifications, also known as product types, consist of a detailed descriptions of attributes that are made externally available through the product offer. These are the attributes associated with a product offer and define its technical aspects. For more information, see Product Specification Overview.
Attributes	Attributes are data elements that can be associated with product specifications and service specifications. Once created, an attribute can be reused across multiple product and service specifications. For more information, see Attributes Overview.
Product Offers	Product offers represent products and services that can be sold, ordered, or managed as customer assets. A product offer can be either a simple offer or a bundle offer. Simple offers contain attributes and features but do not include other product offers. Bundle offers are composed of two or more product offers. For more information, see Creating Product Offer Using a Guided Flow.
Product Offer Pricing	Product offer pricing refers to different pricing structures, such as one-time, recurring, usage fees, or attribute-based pricing, that you associate with product offers. For more information, see Pricing Overview.
Promotions	Promotions or promotional events refer to additional discounts, reductions, or awards on offers for customers who meet predefined criteria. For more information, see Promotions Overview.
Catalogs and Categories	Categories are used to group product offers into logical containers. A product category can contain other categories. Each product offering in a product catalog combines pricing and availability information with product specifications that describe the relationships between products, the services used to realize the products, and the resources they require. For more information, see Create a Catalog.
Rules	Rules are different types of conditions that you can set for product offers and product specifications. Using rules, you can set conditions that validate the eligibility or compatibility of offers or specifications, verify when offers or specifications can be downgraded or upgraded, or check recommendations. For more information, see Rules Overview.
Product Lines	Product lines group similar product offers. For more information, see Product Lines Overview.

Understanding Entity Relationships

Here's how the entities are related to each other.

A product (defined by a product specification) is usually a service or a resource instantiated. Product specifications are detailed descriptions of tangible or intangible objects available to users in the form of a product offer.

Product offers are created as simple or bundle offers. A simple offer is an atomic offer, whereas a bundle offer is a grouping of simple offers or nested bundle offers. An example of a bundle offer is a home-based internet service that combines three simple offers, such as internet connection, e-mail service, and home security.

After you decide the offer type, based on product specifications, you can associate prices to the offer. You can use a simple or advanced pricing model. A simple pricing model comprises a one-time fee, a recurring fee, or a usage fee. An advanced pricing model includes allowances, tiered pricing, attribute-based pricing, and overages. You can set up price plans to avoid proliferation of offers and help manage pricing structures. In addition to this pricing, you can define alterations, such as adjustments and discounts. Price alterations like discounts and markups can be specified on specific price types for service bundles, packages, or commercial bundles. A price type is the charging mechanism associated with a product offer, which determines when and how the customer is billed.

You can also add promotions to an offer to provide additional benefits such as discounts, reductions, or awards over a short duration to a customer who has met predefined criteria.

Further, you can add rules to help determine how a product offer is made available in the market. Eligibility rules specify the parameters, compatibility rules specify the inclusion or exclusion of a combination of products, recommendation rules provide cross-sell and up-sell opportunities, and upgrade and downgrade rules define the permissible offers to migrate to or migrate from.

The product offers are also grouped into catalogs and categories, which represent the collection of product offers. The product offers can also be grouped based on product lines. After you have defined all aspects of a product offer, you can publish it to the market, making it available to customers.

Initiatives tie all the entities together to help manage their lifecycle statuses and publish them into a production environment. Initiatives also determine which entities you can access when creating new entities inside that initiative. For example, when you create offers, the product specifications drop-down list will contain only those specifications that are associated with the initiative you have selected.

Working with Catalog Entities

Top-level entities contain validations that ensure all of the entity's resources are valid for the duration of the top-level entity's time period. For example, a product specification valid from October 1, 2018 to December 31, 2018 cannot be used to create an offer valid from November 1, 2018, to March 30, 2019. You can only create a product offering for a period that is within the validity period of its parent product specification.

You can use the search option on the landing page of each top-level entity to narrow down your search within the listed entities.

The search filters include the following options:

• Auto complete

• Type ahead

• Recent

• Tags

• Count

• Lifecycle status

Support for Multiple Business Units

A Communications Service Provider (CSP) organization can have many Business Units (BU) either geographical or based on lines of business. Having such divisions allows the CSPs to have different sets of catalog definitions for products and services as well as, if needed, shared catalog definitions that cross BUs.

Launch supports multiple business units to share or have exclusivity for product offerings and price lists. You can restrict the usage of product offers and price lists to a particular BU for its specific market offerings, or open it up for usage across all BUs, or share it among a few BUs. During product offering creation, the user's BU is set by default. Additionally, you could add more BUs to promote data sharing. During bundle product offering creation, the components will belong only to the user’s BU and will not include components from different BUs. The same applies to price list entity. Business unit striping does not apply to other entities such as product offering price, specifications, attributes, catalog, categories, rules, terms or initiatives. These entities are common across all BUs.

When you use multiple BUs:

• Users who do not have a BU association can view all offers and price lists.
• Users who should be restricted to a BU should have that BU added to their user profile.
• You can also, if needed, define a default BU for your business.
• Organizations and BUs have a one-to-one relationship.
• Users can remove the BU association from offerings to make it available for all BUs

For example, a CSP has 2 BUs (BU1 and BU2). Offers and price lists for BU1 can either be shared or exclusive to BU1. Likewise, offers and price lists created as part of BU2 can be either shared or made exclusive to BU2.

This allows multiple business units to share market offers or define them as exclusive during offer modeling.