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

You can use the following table to understand the definition of different entities then read about how these entities work together later in this topic. This guide contains a chapter on each of these entities.

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 attributes which can be applied to a product specification or service specification. Once defined, an attribute can be reused on other product or service specifications. For more information, see Attributes Overview.
Product Offers	Product offers can be sold or ordered from the provider of the catalog or can be tracked as an asset. A product offer can be a simple offer or bundle offer. A simple product offer has attributes, features, and attributes but does not contain other product offers. A bundle product offer is an assembly 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 endure that all of the entity's resources are valid for the time period of the top-level entity. 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 their specific market offerings or open it up for usage across all or share amongst a few BUs. During product offering creation, the users BU would be set by default. Additionally, you could add more BUs to promote data sharing. During bundle product offering creation, the components would belong to the user BU only and will not contain components from different BU's. The same is applicable 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 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 have sharing and exclusivity options during modeling market offers.

The following are the high level steps involved in setting up a Business Unit:

1. Create Organization
2. Create Business Unit
3. Create Resource Organization
4. Create Resource User
5. Associate BU and User to Organization
6. Link Resource User to Security User (if security user is already created)

For setup details on business units, see Launch Cloud Service Implementation Guide.

The following are the access requirements:

• Communications Catalog Product Manager
• Communications Catalog Administrator