Software Release 2.1.0 September 2013 · Fulfillment Catalog Data Repository Dictionary ... TIBCO...

TIBCO® Fulfillment Catalog ProductCatalogSoftware Release 2.1.0September 2013

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDEDOR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITEDADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLEDSOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FORANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF ALICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT,OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENTWHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH ISDUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT ORCLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OFTHE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOURUSE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws and treaties.No part of this document may be reproduced in any form without the written authorization of TIBCO SoftwareInc.

TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator,TIBCO Enterprise Message Service, and TIBCO BusinessEvents are either registered trademarks or trademarks ofTIBCO Software Inc. in the United States and/or other countries.

EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of their respectiveowners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALLOPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAMETIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFICOPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGESARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATEDIN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/ORCHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANYTIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY,BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITEDTO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright © 2010-2013 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information.

TIBCO® Fulfillment Catalog Product Catalog

Contents

Preface..................................................................................................7Related Documentation............................................................................................................8

Typographical Conventions......................................................................................................9

Connecting with TIBCO Resources........................................................................................11

Chapter 1 Introduction: TIBCO Fulfillment Catalog......................13TIBCO Fulfillment Orchestration Suite...................................................................................14

Chapter 2 High Level Data Model...................................................17Fulfillment Catalog Data Model for the Telecommunications Product Catalog.......................19

Master Repositories.....................................................................................................19

Relationships...............................................................................................................20

Fulfillment Catalog Telco Overall UML Diagram..........................................................21

Fulfillment Catalog Data Repository Dictionary......................................................................22

Product........................................................................................................................22

Characteristic...............................................................................................................26

CharacteristicDataType...............................................................................................28

Price............................................................................................................................28

Allowance....................................................................................................................31

Discount.......................................................................................................................32

PolicyRule....................................................................................................................34

Segment......................................................................................................................37

Catalog........................................................................................................................37

Party............................................................................................................................38

PartyExtension............................................................................................................40

PlanFragment..............................................................................................................41

Milestone.....................................................................................................................41

Action...........................................................................................................................42

Project Tag...................................................................................................................42

Relationship Attributes.................................................................................................43

Sample Data Examples with the Fulfillment Catalog Telco Data Model.................................54

Segment Data..............................................................................................................54

Product Data................................................................................................................54

Devices/Hardware.......................................................................................................55

Tariffs...........................................................................................................................56

Services.......................................................................................................................56

Product........................................................................................................................57

Composite Products and Complex Product Offerings.................................................58


TOC | 5

Extensibility: Adding a new Product Component.........................................................59

Price............................................................................................................................60

Simple Price................................................................................................................61

Composite Pricing.......................................................................................................61

Composite Pricing Detail.............................................................................................62

Tariff Usage Group......................................................................................................63

Party Data....................................................................................................................63

Additional Class type for PRICE - Corporate Framework Agreement....................................65

Corporate Framework Agreement Definition...............................................................65

Corporate Framework Agreements - PRICE Class.....................................................65

Chapter 3 SID-based Data modeling for the Product Catalog.....73ProductOffering ABE and other Top-Level SID Entities for the Telco Product Catalog Model.74

SID Business Entities Below ProductOffering........................................................................75

SID Patterns for Complex Entities and Extensibility...............................................................76

Chapter 4 Interfaces........................................................................79Import Interfaces....................................................................................................................80

Export Interfaces....................................................................................................................81


6 | TOC

Preface

The preface contains information about documentation related to the current document, typographicalconventions, and information on how to contact TIBCO support.


Related Documentation

This section lists documentation resources you may find useful.

• TIBCO Fulfillment Catalog Installation and Configuration Read this manual for instructions on site preparation,installation, and configuration.

• TIBCO Fulfillment Catalog Product Catalog Read this manual for instructions on product catalog. It also providesdetails about the data models.

• TIBCO Fulfillment Catalog User's Guide This manual explains the features of TIBCO Fulfillment Catalog. Itprovides the details of the User and Administrator tasks.

• TIBCO Fulfillment Catalog Release Notes Read the release notes for a list of features. This document also containsthe list of known issues for this release.


8 | Preface

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1: General Typographical Conventions

UseConvention

Many TIBCO products are installed within the same home directory. This directoryis referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends

TIBCO_HOME

on the operating system. For example, on Unix systems the default value is<user_home>/tibco.

Other TIBCO products are installed to an installation environment. A productinstalled into an installation environment does not access components in other

ENV_NAME

installation environments. Incompatible products and multiple instances of the sameproduct must be installed into different installation environments. An installationenvironment consists of the following properties:• Name Identifies the installation environment. This directory is referenced in

documentation as ENV_NAME.• Description Provides information about what the environment contains or is

used for.• Path The directory into which the product is installed. This directory is referenced

in documentation as ENV_NAME. The value of ENV_NAME depends on theoperating system. For example, on Unix systems the default value is<user_home>/tibco.

MQ_HOME is the environment variable where TIBCO Collaborative InformationManager is installed. For example, /opt/tibco/cim/8.2.

MQ_HOME

TIBCO Fulfillment Catalog installs into a directory inside MQ_HOME. This directoryis referenced in documentation as AC_HOME. The value of AC_HOME depends on

AC_HOME

MQ_COMMON_DIR the operating system. For example, on UNIX systems the default value is$MQ_HOME/plugins/ac/2.1.

All standard configuration files for workflow and data validation as well as allcustomization are stored in the MQ_COMMON_DIR directory.

Code font identifies commands, code examples, file names, path names, and outputdisplayed in a command window. For example:

code font

Use MyCommand to start the foo process.

Bold code font is used in the following ways:bold code font

• In procedures, to indicate what a user types. For example: Type admin.• In large code samples, to indicate the parts of the sample that are of particular

interest.• In command syntax, to indicate the default parameter for a command. For

example, if no parameter is specified, MyCommand is enabled:

MyCommand [enable | disable]


Preface | 9

UseConvention

Italic font is used in the following ways:italic font

• To indicate a document title. For example: See TIBCO Fulfillment Catalog ProductCatalog.

• To introduce new terms. For example: A portal page may contain several portlets.Portlets are mini-applications that run in a portal.

• To indicate a variable in a command or code syntax that you must replace. Forexample: MyCommand pathname.

The note icon indicates information that is of special interest or importance, forexample, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to apply theinformation provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example, dataloss or corruption if certain steps are taken or not taken.

The important icon indicates information that is of special interest or importance,for example, an additional action required only in certain circumstances.


10 | Preface

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts—a place toshare and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs,and access to a variety of resources. To register, go to http://www.tibcommunity.com.

How to Access All TIBCO Documentation

After you join TIBCOmmunity, you can access the documentation for all supported product versions here:

https://docs.tibco.com.

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, please contact TIBCO Support asfollows:• For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this

site:

http://www.tibco.com/services/support

• If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a username and password. If you do not have a username, you can request one.


Preface | 11

http://www.tibcommunity.com

https://docs.tibco.com

http://www.tibco.com/services/support

https://support.tibco.com

Chapter

1Introduction:TIBCO Fulfillment Catalog

TIBCO® Fulfillment Catalog enables you to easily manage and maintain complex Product Offerings. The ProductOfferings, Services and rules for Pricing, Provisioning and Eligibility are actively maintained within the FulfillmentCatalog's Data Repository. A complete graphical user interface allows the users to create, edit, search, and maintaintheir data. User access, responsibilities and lifecycle workflows can be configured for the ongoing management ofthis information. The complete data model for your product offerings and their components can be exported tothe downstream order provisioning systems, such as TIBCO Fulfillment Order Management.

This document details the out of box data model supplied with TIBCO® Fulfillment Catalog. Specifically, thisdocument describes in detail:

Product Catalog Definition: TIBCO® Fulfillment Catalog provides a flexible mechanism for defining a completeproduct offering data model and maintaining the data objects in the repository. At run-time, TIBCO® FulfillmentOrder Management can provide fast access caching to send queries of the catalog to the querying application forthe data. The definition of Product Offerings not only includes the component building blocks of a Sales Offer, butalso:• Definition of Product or Services

– Underlying components– Characteristics– Features

• Definition of Prices and Price Sets• Definition of Rules Governing Product Validity

– Optional Components– Eligibility Rules– Compatibility Rules– Customer Type or other Segmentation Rules

• Definition of Fulfillment rules– Sequencing– Provision Processes– Dependencies

Topics

• TIBCO Fulfillment Orchestration Suite


TIBCO Fulfillment Orchestration Suite

TIBCO Fulfillment Orchestration provides a comprehensive suite of products that accelerates theconcept-to-cash cycle for multi-play Communications Service Providers (CSPs) by automating the end-to-endprocess from product definition and design to the efficient, accurate fulfillment of the orders.

Concept to Cash is defined as following:

• Businesses that provide their customers a multitude of 'Sales Packages' of bundled goods and services.Sales Packages often re-use existing Products or Services and need to react quickly to changing marketconditions and opportunities.

• The different Sales Packages or underlying goods and services often have complex rules governing priceand validity based on any number of factors.– Seasonality– Customer type– Existence of compatible or incompatible services for the customer

• Products and Services may require a provisioning or fulfillment process before being usable to the customer– Provisioning processes are complex– Depend on many factors

– What else was purchased– The results of previous steps in the process. For example, was the copper line sufficient to provide

high-speed internet?

• The complete life-cycle, therefore is:– Product offering definition

– Up-front definition of product offerings

– Offer Validation– Product definition allows systematic and automatic validation of orders based on the rules defined

– Order Fulfillment– Provisioning process automatically determined based on the original complete Definition of the

Product Offering

Advantages

• Reduced time to market• React to customer, market, competitor actions• Reduction in provisioning time• Increase in efficiency• Reduction in order errors• Reduction in fulfillment errors

Benefits

• Cost savings in process efficiency• Increased revenue through market agility and customer satisfaction

The Suite is architected in a modular approach using TIBCO's infrastructure software products. Each softwarein the Suite is loosely coupled with other via the use of industry standard JMS messaging and XML messages.This architecture provides scalability, fault tolerance and load balancing.

The Suite set consists of:

TIBCO® Fulfillment Catalog


14 | Introduction: TIBCO Fulfillment Catalog

Fulfillment Catalog provides the Product Catalog component of the offering. It is a J2EE application that runsin an application server, and uses relational database as data store. The Fulfillment Catalog is a plug-in forTIBCO Collaborative Information Manager.

TIBCO® Fulfillment Order Management

Fulfillment Order Management provides the Offering Configuration and Validation component of the offering.It is based on TIBCO's complex events, rules, and BPM software products.

TIBCO® Fulfillment Provisioning

Fulfillment Provisioning automates the activation of underlying network services and the allocation ofnetwork resources.

The following diagram describes the solution placement in an enterprise architecture.

Figure 1: Fulfillment Orchestration Suite


Introduction: TIBCO Fulfillment Catalog | 15

Chapter

2High Level Data Model

The description below is composed of the following parts:

1. The extensible Data Model for TIBCO® Fulfillment Catalog.

2. UML Diagrams of the Data Model.

3. Additional SID Concepts within the Fulfillment Catalog Data Model for Extensibility and Composite Entities.

4. The Fulfillment Catalog Data Model using Sample Data from the TIBCO Telco Product Catalog.

TIBCO® Fulfillment Catalog is, by design, an extensible and dynamic Master Data Repository, able to handle anytype of Master Data Modeling.

This document provides the Telecommunications Industry a complete schema for a Product Catalog Data Modelthat can handle a customer's specific needs, while conforming to SID modeling and extensible principles. Specifically,the TIBCO Fulfillment Catalog Telco Data Model uses a recursive, component-based building block approach tomodel complex product, prices (including tariffs), and product price policy rules for the Telecommunicationsindustry.

The data model outlined here can be used as is, extended, or used as a starting point to build out a customer'sspecific data model and terminology. SID compliance is maintained via internal identifiers and data models whileBusiness Users view their information in the context of their own terminology .

Figure 2: Fulfillment Catalog Illustrating the Internal Master Repositories of Data for each main type of SIDABE

Topics

• Fulfillment Catalog Data Model for the Telecommunications Product Catalog• Fulfillment Catalog Data Repository Dictionary


• Sample Data Examples with the Fulfillment Catalog Telco Data Model• Additional Class type for PRICE - Corporate Framework Agreement


18 | High Level Data Model

Fulfillment Catalog Data Model for the Telecommunications ProductCatalog

The Fulfillment Catalog Data Model is designed to maintain all Business Entities, Rules, and Relationshipsrequired to define complex Product Offerings. Although the data concepts described here may apply to anumber of Industries, the examples and nomenclature described in the rest of this document uses terminologyand examples from the Telecommunications industry. The Model handles Product Definition, Tariff Definition,Product Offering Definition, Product Pricing (Simple and Matrix), Tariff Charges, Discounts, Promotions,Allowances, as well as Policy Rules to define additional policies not automatically expressed within therelationships between the Business Entities.

Master Repositories

TIBCO Fulfillment Catalog models and manages its SID-based objects in the following separate repositories:

Table 2: Repository details

DescriptionRepository name

Each record in the Product repository represents a Component. Componentscomprise other Components, which may include other Components. Depending

Product

on the complexity of the data there is no limit to the level of componentization youwish to model. From a SID perspective, a top-level Component is called a Product.Sub-components are known as Composite Products (if made of a distinct group ofcomponents) or simply Components. In turn, TIBCO Fulfillment Catalog alsoallows the user to classify their components into logical types (Device, Tariffs,Services, Options, and so on).

Characteristics or Usages that a Product or Price may relate to. A record can beboth a characteristic and a usage at the same time (for example, a handset has an

Characteristic

"SMS" characteristic. "SMS" is also be defined as a type of "Usage" that can becharged for. Characteristics often contain values that describe the amount of theCharacteristic. Such values may be defined once (500 Free Minutes), user or systeminput at time of order (MSISDN = ?), or may be "Instanced" and vary per ProductOffering (Sales Package has the "Free Minutes" Characteristic. The value of FreeMinutes for the Sales Package = 1000).

Additional information for Characteristic.CharacteristicDataType

The data repository used to maintain price and price matrices, as well as usagecharge information for products that have associated fixed, usage, recurring, simple,or one-time charges.

Price

Allowance information that can modify Price (for example, 250 minutes free, thenthe normal 10 cents per minute thereafter).

Allowance

Discount information that can modify Price (for example, 25% off from 10 - 14February, 50 Euros off the cost of installation)

Discount

Rule definitions that may be applied to Products to further specify uniquequalification rules or events for a ProductOffering (for example, "this product onlysellable to females", "after one year get something free")

PolicyRule


High Level Data Model | 19

DescriptionRepository name

Contains a list of other reference entities that may impact the definition of Products(for example, Product may be available only to Corporate customers, or Pricingmay differ based on Customer Risk).

Segment

List of subset of offerings, to allow for management of multiple catalogs ofProductOfferings.

Catalog

List of Party Entities that may be used to further define compatibility of Products,Prices, or Policies with specific Parties. Parties may be defined as Organizations,

Party

Roles or People. Organizations may be individual Corporations, or Corporationsand their subsidiaries (Corporate Hierarchies). A Role represents a group of people(for example, IT Staff, Administrator, Senior Management). People represent actualnamed, individuals (for example, John Smith).

Additional information associated with Parties.PartyExtension

It provides configuration information for a Process Component/Plan Fragment ofBPM Engines. It has information for SLA.

PlanFragment

Representation of the start and end of part of an executing plan item.Milestone

It stores meta information for valid fulfillment actions and provides you theflexibility to define your own set of actions. This repository defines all valid actions

Action

that may be used to describe how a particular fulfillment process should bemodeled.

It provides a central repository to manage the Project Tag Names. These tag namesare later used across other repositories.

PROJECTTAG

Relationships

TIBCO Fulfillment Catalog Relationships also allow the definition of relationship types within and betweenFulfillment Catalog Repositories, conforming to SID entity relationship modeling.

The SID-compliant Relationships applicable for all Repositories are the following:

• ComprisedOf- Used to denote bundled ABE's within a repository (using SID terminology, containsrelationships express composite entities)

• ExtensionEntity- Expresses any future new data models that are extensions to an existing model

Other ABE's within the Fulfillment Catalog Repository use a host of other relationships, (for example,ProdValuedByPrice). These are documented in the subsequent section for each Repository/Business EntityData Dictionary.



Fulfillment Catalog Telco Overall UML Diagram

Figure 3: Fulfillment Catalog Telco Overall UML Diagram

Some secondary relationships have been omitted from this model for clarity.



Fulfillment Catalog Data Repository Dictionary

The following table describes the Fulfillment Catalog Telco Data Repository. Each Repository is extensible.The attributes described below use the TIBCO Telco Product Catalog structure as the starting point.

Product

Principal SID Entities within the Product Repository: Product, CompositeProductOffering,CompositeProductSpecification, and ProductSpecification.

Attributes DescriptionData TypeDisplay Name

Product IdentifierString(255)PRODUCTIDProductID

Product typeString(35)ClassRECORD_TYPE

Unit of measureString(40)UOMUOM

Internal NameString(255)NameName

Second level classificationString(255)SubClassSubsetType

Short DescriptionString(2000)Short DescriptionSHORTDESC

Long DescriptionString(2000)Long DescriptionLongDesc

Single use flag for provisioningBooleanSingleUseSingleUse

Must complete flag for provisioningBooleanMustCompleteMustComplete

Concurrent order flag for validationBooleanConcurrentOrderConcurrentOrder

System that maintains the record that theproducts are created by Fulfillment

String(255)OwnerOwner

Catalog or imported from FulfillmentProvisioning (INFO group).

Supporting ImageFileImageImage

Start Date for the record to be effective(if applicable)

DateStart DateStartDate

Start Time for the record to be effective(if applicable)

String(40)Start TimeStartTime

End Date for the record to be effective (ifapplicable)

DateEnd DateEndDate




End Time for the record to be effective(if applicable)

String(40)End TimeEndTime

Additional information for customersupport to understand

String(4000)MemoMemo

Any media to attachFileSupporting DocumentSupportingDocument

Standard time to deliver productDecimalStandard DeliveryStandardDeliveryTime

Unit of MeasureString(255)Standard DeliveryUOM

StandardDeliveryUOM

Premium time to deliver productDecimalPremium DeliveryPremiumDeliveryTime

Unit of MeasureString(256)Premium DeliveryUOM

PremiumDeliveryUOM

Delivery type offeredString(255)Delivery TypeDeliveryType

Standard contract lengthDecimalContract LengthContractLength

Contract Unit of MeasureString(255)ContractUOMContractUOM

Timeframe for cancellationDecimalCancellation PeriodCancellationPeriod

Display image for the Order Entry UI.String(255)ImageUrlImageUrl

Status of Record within (Retired, Active,etc)

String(255)Record Statuslifecyclestatus

References Technical plans to allow anorder and/or provisioning system knowhow to provision the product

String(255)Provide PlanProvidePlan

References Technical plans to allow anorder and/or provisioning system know

String(255)Update PlanUpdatePlan

how to update the product for thecustomer


String(255)Cancel PlanCancelPlan

how to cancel the product for thecustomer


String(256)Cease PlanCeasePlan




how to cease the product for thecustomer

Affinity group typeString(256)Affinity TypeType

References technical plans to allow anorder provisioning system to know howto provision a product when grouped.

String(256)AffinityProvideAffinityProvide

References technical plans to allow anorder provisioning system to know howto cancel a product when grouped.

String(256)AffinityCancelAffinityCancel

References technical plans to allow anorder provisioning system to know howto cease a product when grouped.

String(256)AffinityCeaseAffinityCease

References technical plans to allow anorder provisioning system to know howto update a product when grouped.

String(256)AffinityUpdateAffinityUpdate

Xpath expression for Affinity condition.Varchar(2000)AffinityConditionAffinityCondition

Xpath expression to specify String usedfor Affinity Group.

Varchar(2000)AffinityCorrelationAffinityCorrelation

Immediate Parent Only (True or False.BooleanAffinityParentGroupAffinityParentGroup

Same Action Only (True or False).BooleanAffinityActionGroupAffinityActionGroup

Xpath expression for an Order Action.Varchar(2000)AffinityActionValueAffinityActionValue

An identifying group number to allowlogical grouping between children.

IntegerGroupNumberGroupNumber

Minimum quantity of children withinthe same GroupNumber (if applicable).

DecimalMinimum QuantityGroupMinQty

Maximum quantity of children withinthe same GroupNumber (if applicable).

DecimalMaximum QuantityGroupMaxQty

BooleanOptionalGroupOptional

Tag name for repository instance.String(256)Project Tag NameProjectTagName

Product: ProductType

DescriptionDisplay ValueValue

Represents a sellable offering of bundledproducts. (Display names based on TIBCO Telco

BundleProduct

PC, underlying data naming conform to SIDModeling).



Product: ProductType


Represents a composite product (collection ofother products) that can then be treated as anyother single product.

GroupCompositeProduct

Physical Devices.DeviceDeviceProductSpecification

Tariff information.TariffTariffProductSpecification

Optional Service information.OptionOptionProductSpecification

Product Relationships

Relates toProductType ApplicableName of Relationship

CharacteristicAllCharacteristic

CharacteristicAllCompatibleCharacteristic

PartyAllCompatibleParty

Other Included ProductsAllCompatibleProduct

SegmentAllCompatibleSegment

CharacteristicAllIncompatibleCharacteristic

PartyAllIncompatibleParty

Other Included ProductsAllIncompatibleProduct

SegmentAllIncompatibleSegment

CatalogAllOfferingPublishedInCatalog

Other Included ProductsProduct, CompositeProductProductComprisedOf

PolicyRuleAllProductGovernedBy

PriceAllProductPricedBy

Other Included ProductsAllProductRequiredFor

PlanFragmentAllProductHasProvidePlanFragment

PlanFragmentAllProductHasUpdatePlanFragment



Product Relationships


PlanFragmentAllProductHasCeasePlanFragment

PlanFragmentAllProductHasCancelPlanFragment

PlanFragmentAllProductHasCustomPlanFragment

DiscountAllProductRequiredForDiscount

ProductProducts as applicableCompatibleWithProduct

ProductProducts as applicableComprisingProduct

ProductProducts as applicableProductDependsOn

PriceAllProductRequiredForPrice

AllowanceAllProductRequiredForAllowance

ProductProducts as applicableIncompatibleWithProduct

ProductProducts as applicableDependentProduct

ProductProducts as applicableProductRequiredBy

PolicyRuleAllProductRequiredForPolicyRule

Characteristic

Principal SID Entities within the Characteristic Repository: ProductSpecCharacteristic, Characteristic, andUsage.

Repository:Characteristic

DescriptionData TypeDisplay NameAttributes

Record IdentifierString(255)PRODUCTIDProductID

Short DescriptionString(2000)Short DescriptionShortDesc

Characteristic typeString(35)ClassRECORD_TYPE


Sequence number for displayingcharacteristics on a user interface

IntegerDisplay SequenceDisplaySequence

NameString(256)NameName

Mandatory or Optional (if applicable)BooleanMandatoryMandatory

Default or Instance Value (if applicable)String(255)Default ValueDefaultValue



Repository:Characteristic


If input required where is it sourced fromString(255)SourceSource

Data Type of the characteristic (ifrequiring an input)

String(255)Date TypeDataType

Maximum data input lengthIntegerInput LengthInputLength

Flag indicating if this feature should beavailable to Charge records (for example,

BooleanIs this FeatureChargeable

IsChargeable

is there a usage charge associated withthis feature)

Range of valid values for thecharacteristic

String(256)RangeValueRangeValue

Flag indicating if characteristic value isto be stored in inventory

BooleanPersist Value inSubscriber Inventory

PersistValue



Auxiliary identifier for current entity.StringPRODUCTIDEXTPRODUCTIDEXT

Name or location of a picture file for thisrecord

FileIMAGEIMAGE

Unit of measureStringUOMUOM

ContainsStringCONTAINSCONTAINS


Characteristic:CharacteristicType


Feature characteristics describes a certain aspect of a product. AFeature can be a distinct feature or capability of a product. In

FeatureFeature

general, features distinguish a product from other products of thesame class. For example features of a mobile device might include:SMS, Voice, MMS, 4G, Stereo Wireless Headset, Keyboard, etc.Features could also be chargeable or non-chargeable. For instance,for billing purposes, a device that provides SMS capability couldmean it may need a SMS capable billing plan

Input characteristics represent information values that need to becaptured and associated with the product at time of order/order

InputInput

fulfillment. They generally represent information that needs to be



Characteristic:CharacteristicType


propagated to other systems OR will impact the fulfillment process.Input characteristics generally have no values until the order isplaced/fulfilled. An example of an Input characteristic could be anMSISDN (phone number) allocated to a mobile device, or a "ContactAddress" captured for a business internet product at time of order

Instance characteristics are similar to Feature. The feature inquestion has measurable quantity that is defined for each related

InstanceInstance

product. For instance, a discrete "Free 500 SMS Package" productcould have an "Instance" characteristic called "Free SMS". Thischaracteristic would have a relationship value = 500. Anothersimilar product could be created and called "Free 1000 SMSPackage". It would have the same "Free SMS" characteristicassociated with it but have a relationship value = 1000.

It indicates that the attribute is sharedSharedShared

Characteristic Relationships

Relates toCharacteristicType ApplicableName of Relationship

Other records in CharacteristicAllCharacteristicComprisedOf

CharacteristicDataTypeAllHasDatatype

CharacteristicDataType

Repository:CharacteristicDataType


Characteristic data typeString(35)ClassRECORD_TYPE

ID type nameString(255)PRODUCTIDProductID

Data type nameString(255)Product ID ExtensionProductIDExt

Data type descriptionString(2000)Short DescriptionSHORTDESC

Data type definition regular expressionString(4000)Data Type DefinitionRegEx

Flag indicating if this data type permitsvariable length data

BooleanVariable LengthVariableLength


Price

Principal SID Entities within the Price: Price, CompositeProdOfferingPrice, ProductPrice, CompositeProdPriceProdOfferPriceCharge, and ProductPriceCharge.



Repository: Price


Charge IdentifierString(255)PRODUCTIDProductID

Charge identifier extensionString(255)Product ID ExtensionProductIDExt

Type of Charge Entity (See table belowfor list of valid Types)

String(35)ClassRECORD_TYPE



Commercial NameString(255)Commercial NameProductName








DateEnd DateEndDate



Duration of the chargeIntegerDurationDuration

Duration unit of measure for the chargeString(10)DurationUOMDurationUOM

Characteristic that is being charged (SMS,3G, etc)

String(255)UsageUsageCharacteristic

The fee to chargeDecimalCharge AmountChargeValue

Per measurement unitString(255)PerChargeUOM

The starting range of when to apply thischarge

DecimalCharge FromChargeMinBoundary

The endpoint when this charge no longerapplies

DecimalCharge ToChargeMaxBoundary



Repository: Price


If the customer has or is buying a productthat provides a similar charge, this

DecimalCharge PriorityChargePriority

provides the system a way to choosewhich Charge to bill.

Status of Record (Retired, Active, etc)String(240)Record StatusLifeCycleStatus


Price: ChargeType


Collection of other chargesTariff UsageTariffUsage

Fee based on usageUsageUsage

Fixed rate chargeFixedFixed

Recurring feeRecurringRecurring

One time chargeOne-TimeOne-Time

Special one-time charges (example:Activation fee)

FeeFee

Group of pricing applying to oneproduct. Price based on conditions

Price MatrixCompositePrice

Simple Price of a ProductProductProduct

Price Relationships


CharacteristicAllCharacteristicCharge

AllowanceAllPriceAlteredByAllowance

DiscountAllPriceAlteredByDiscount

Other charges in PriceAllPriceComprisedOf

PolicyRuleAllPriceGovernedBy



Price Relationships


CharacteristicAllPriceRequiresCharacteristic

PartyAllPriceRequiresParty

Product RepositoryAllPriceRequiresProduct

Segment RepositoryAllPriceRequiresSegment

Allowance

Principal SID Entities within the Allowance Repository: ProdOfferPriceAlteration andAllowanceProdOfferPriceAlteration.

Repository: Allowance


Allowance IdentifierString(255)PRODUCTIDProductID

Type of Allowance Entity (See tablebelow for list of valid Types)












DateEnd DateEndDate



Usage Characteristic that is being alteredby this allowance




Repository: Allowance


Amount to allowDecimalCharge AmountAllowanceValue

Per measurement unitString(256)PerAllowanceUOM

Number of units to allowDecimalLength of AllowanceAllowancePeriod




Allowance: AllowanceType


Composite allowance bundleGroupCompositeAllowance

Allowance EntityAllowanceAllowance

Allowance Relationships


Other allowances in AllowanceAllAllowanceComprisedOf

PolicyRuleAllAllowanceGovernedBy

CharacteristicAllAllowanceRequiresCharacteristic

PartyAllAllowanceRequiresParty

ProductAllAllowanceRequiresProduct

SegmentAllAllowanceRequiresSegment

Discount

Principal SID Entities within the Discount Repository: ProdOfferPriceAlteration andDiscountOfferPriceAlteration.

Repository: Discount


Discount IdentifierString(255)PRODUCTIDProductID



Repository: Discount


Type of Discount Entity (See table belowfor list of valid Types)

String(35)ClassRecord_Type











DateEnd DateEndDate



Characteristic that is being discounted(SMS, 3G, etc)


The discount to applyDecimalDiscount AmountDiscountValue

Percent or Absolute discountString(255)Percent or FlatDiscountUOM




FileIMAGEIMAGE






Discount: DiscountType


Composite allowance bundleGroupCompositeDiscount

Allowance EntityDiscountDiscount

Discount Relationships


Other discounts in DiscountAllDiscountComprisedOf

PolicyRuleAllDiscountGovernedBy

CharacteristicAllDiscountRequiresCharacterisitc

PartyAllDiscountRequiresParty

ProductAllDiscountRequiresProduct

SegmentAllDiscountRequiresSegment

PolicyRule

Principal SID Entities within the PolicyRule Repository: PolicyRule, PolicyGroup, PolicyEvent, PolicyAction,and PolicyCondition.

Repository:PolicyRule


Product IdentifierString(255)PRODUCTIDProductID

Type of Product Entity (See table belowfor list of valid Types)
















DateEnd DateEndDate



Minimum PriceDecimalMinimum PriceMinPrice

Maximum PriceDecimalMaximum PriceMaxPrice

Minimum Order PriceDecimalMinimum Order PriceMinOrderPrice

Maximum Order PriceDecimalMaximum Order PriceMaxOrderPrice

Minimum Contract LengthDecimalMinimum ContractLength

MinContractLength

Maximum Contract LengthDecimalMaximum ContractLength

MaxContractLength

Sales Conditions: evaluate the last N ofsales

DecimalNumber of SalesNumberOfSales

Value of the last N sales thresholdDecimalTotal ValueTotalValue

Trigger if exceeding or below thresholdBooleanGreater or LowerGreaterOrLower

The duration until an early terminationfee is waived

DecimalPenalty PeriodPenaltyPeriod

If Policy is evaluating the values inputfor a particular characteristic

String(255)Evaluate CharacteristicEvaluateCharacteristic

The characteristic's value must be equalto this

String(255)Characteristic EqualsEvaluateEqual

The characteristic's range must be withinthe two values

String(256)Characteristic MinRange

EvaluateMinRange





The characteristic's range must be withinthe two values

String(255)Characteristic MaxRange

EvaluateMaxRange

Entire Order is invalid if conditions ofthe policy are not met

BooleanInvalid Order if PolicyFailed?

InvalidIfFail

The Price policy attached to this policyis an exclusive offer not combinable andsuperseding any other price alterations.

BooleanActs as an exclusiveoffer?

ExclusivePolicy

Alerts the order system to perform thespecified event to fulfill the Policy (query

String(255)Operation Event toPerform

TriggerEvent

a promotional partner for customer'seligibility)


String(256)Record StatusLifeCycleStatus


PolicyRule: PolicyType


Additional criteria to evaluateDiscounts, Promotions, Allowances

AlterationAlteration

Additional criteria to evaluatevalidity of the order

ValidityCheckValidityCheck

PolicyRule Relationships

Relates toPolicyType ApplicableName of Relationship

PolicyRulePolicySetPolicyRuleComprisedOf

CharacteristicAllPolicyRuleRequiresCharacteristic

PartyAllPolicyRuleRequiresParty

ProductAllPolicyRuleRequiresProduct

Segment RepositoryAllPolicyRuleRequiresSegment



Segment

Principal SID Entities within the Segment Repository: Any ABE's not within the Product Domain but impactProduct (Market Domain, Customer Domain, Geography Domain, etc)

Repository: Segment


A record within the segment's domain(Market Segment has records: Consumer,SME, Corporate)

String(255)PRODUCTIDProductID

Name of a particular Segment ABE(Market, Customer, Credit Rating,Geography, see list below)

String(255)Product ID ExtensionProductIDExt



Description of record entity.StringSHORTDESCSHORTDESC

Defines record type for current recordStringRECORD_TYPERECORD_TYPE


FileIMAGEIMAGE




Segment: SegmentIDExt

ListSegment

Online, Store, Customer Service RepresentativeChannel

Consumer, SME, CorporateMarket

Low, Medium, HighCustomer Risk

Low, Standard, ExcellentCustomer Rating

PostPaid, PrePaidCustomer Type

(Extendable List of ID's)(Extendable list of BEs)

Catalog

Principal SID Entities within the Catalog Repository: Catalog, and ProdCatOffering.



Repository: Catalog


Name of a particular catalog (SpainOnline, Czech Store)

String(255)ProductIDProductID

Catalog extension nameString(255)Product ID ExtensionProductIDExt

Description of record entity.StringSHORTDESCSHORTDESC

Defines record type for current recordStringRECORD_TYPERECORD_TYPE


FileIMAGEIMAGE




catalog Example

OfferIDExtCatalogID

Bundle_Web_&_TalkSpain Online

Bundle_XSpain Online

Bundle_Web_&_TalkCzech Store

Bundle_Mobile_OfficeCzech Store

Bundle_Surf_&_TalkCzech Store

(Extendable List of ID's)(Extendable list of Catalogs)

Party

Principal SID Entities within the Party Repository: Product, Party, Organization, Individual, and PartyRole.

Repository: Party


Unique identifier for current entity.String(255)PRODUCTIDProductID

Description of record entity.String(2000)Short DescriptionSHORTDESC

Defines record type for current recordString(35)ClassRECORD_TYPE




Repository: Party




Override FlagBooleanOverrideOverride

inclusive or exclusiveString(256)Affinity TypeType


String(255)Record StatusLifeCycleStatus

LocaleString(256)LocaleLOCALE

Primary LanguageString(256)Primary LanguageLanguage

Primary PhoneString(256)Primary Phonetelephone

Primary EmailString(256)Primary Emailemail

Primary ContactString(256)Primary ContactContact

Primary ContactString(256)Primary Address 1Address1

Primary Address 2String(256)Primary Address 2Address2

Primary CityString(256)Primary CityCity

Primary State or ProvinceString(256)Primary State orProvince

Region

Primary Post CodeString(256)Primary Post CodePostCode

String(256)Primary CountryCountry


Party: PartyType


A Corporation. May be a subsidiary of anotherOrganization Party Type

CorporationOrganization

A group of peopleRoleRole



Party: PartyType


PersonPersonPerson

Party Relationships

Relates toPartyType ApplicableName of Relationship

Other Organizations in PartyOrganizationHasOrgs

Relates an Organization to Role or People; ORrelates a Role to People in Party

Role, PersonHasPeople

SegmentAllPartyCompatibleWithSegment

SegmentAllPartyHasSegment

SegmentAllPartyIncompatibleWithSegment

PartyExtension

Repository:PartyExtension


Extension attribute nameString(255)PRODUCTIDProductID

Related party nameString(255)Product ID ExtensionProductIDExt

Extension attribute valueString(2000)Short DescriptionSHORTDESC


PartyExtension:PartyExtensionType

Display ValueClass

ORGANIZATIONORGANIZATION

ROLEROLE

PERSONPERSON

PartyExtension Relationships

Relates toName of Relationship

PARTYDataForParty



PlanFragment


Unique identifier for a Plan FragmentString(255)PRODUCTIDPRODUCTID

Identifier or name of process componentString(255)Plan Fragment NamePLANFRAGMENTNAME

Version of process componentString(255)Plan Fragment VersionPLANFRAGMENTVERSION

System on which the Plan Fragment isexecuted. The Attribute group is 'Info'

String(255)OwnerPLANFRAGMENTTYPE

Class of plan fragment. The Default valueis 'Process' (for read only) and theAttribute group is 'Info'


Error handler to use in case of failureString(255)Error HandlerERRORHANDLER

Flag to indicate if the engine defaultvalues for retry are overridden or not

BooleanRetry OverrideRETRYOVERRIDE

Flag to indicate if the failed plan itemsshould be retried or not

BooleanRetry FailedRETRYFAILED

Number of times the failed plan item isretried

IntegerRetry CountRETRYCOUNT

Delay in milliseconds between calls whenfailed plan item is retried

IntegerRetry DelayRETRYDELAY


PLANFRAGMENT Relationships


MilestonePlanFragmentHasMilestone

Milestone


Unique identifier for a MilestoneString(255)PRODUCTIDPRODUCTID

Name of the Milestone . For instance,'START'

String(255)Milestone NameMILESTONENAME

ID of the Plan Fragment to which theMilestone belongs

String(255)Plan Fragment IDPLANFRAGMENTID




MILESTONE Relationships


MilestoneMilestoneToMilestone

MilestoneMilestoneDependsOn

Action

All the attributes are created under the INFO attribute group type. The attributes for action repository areas follows:

Default ValueDisplayinRecordList

DescriptionDataType(Length)

Display NameAttributes

YesVerb used to describe afulfillment action, for

String(255)PRODUCTIDProductID

example, Cancel, Cease,Provide , Update

YesInformation on theaction

String(4000)ShortDescription

ShortDesc

YesClassification for ActionString(40)ClassRecord_Type 1. PROVIDE2. CEASE3. UPDATE4. CANCEL

NOAuxiliary identifier forcurrent entity

String(255)Record IDExtension

PRODUCTIDEXT

NOContainsString(4000)Related RecordsCONTAINS

YesTag name for repositoryinstance.

String(256)Project TagName

ProjectTagName

Project Tag


Unique identifier for a Project Tag NameString(255)PRODUCTIDPRODUCTID

Project Tag NameString(256)NameName

Project Tag Name descriptionString(400)DescriptionDescription

Auxiliary identifier for current entity.String(255)Record ID ExtensionPRODUCTIDEXT

Contains.String(4000)Related RecordsCONTAINS



Relationship Attributes

Relationship Attributes for Relationships

• ProductHasProvidePlanFragment

• ProductHasUpdatePlanFragment

• ProductHasCeasePlanFragment

• ProductHasCancelPlanFragment

• ProductHasCustomPlanFragment


For a plan, this is the sub-action forselecting a particular plan. This has

String(255)Plan FragmentAction Mode

PLANFRAGMENTACTIONMODE

no meaning within IPC, however itwill be used to further differentiatewhich plan fragment should bechosen for particular order lineconfiguration

For a plan this flag indicates if a planfragment should be affinity grouped

BooleanAffinityAFFINITY

For a plan this is the type of affinitygrouping required

StringAffinity TypeAFFINITYTYPE

Xpath expression for Affinitycondition.

Varchar(2000)AffinityConditionAffinityCondition

Xpath expression to specifiy Stringused for Affinity Group.

Varchar(2000)AffinityCorrelationAffinityCorrelation

Immediate Parent Only (True orFalse.

BooleanAffinityParentGroupAffinityParentGroup

Same Action Only (True or False).BooleanAffinityActionGroupAffinityActionGroup

Xpath expression for an OrderAction.

Varchar(2000)AffinityActionValueAffinityActionValue


SearchableDisplayinRecordList

LengthTypeDisplay NameRelationship for PRODUCTrepository:HasCustomPlanFragment

Attribute for theHasCustomPlanFragmentRelationship

NoYes256StringActionACTIONID

Relationship Attributes for MilestoneToMilestone Relationship


Typical duration for the defined section.IntegerTypical DurationTYPICALDURATION

Maximum Duration for the definedsection.

IntegerMaximum DurationMAXIMUMDURATION





Relationship Attributes for MilestoneDependsOn Relationship


Conditional expression value to evaluatewhether or not to include theintermediate milestone dependency.

StringConditionCONDITION


Additionally, for the various relationships, the following relational attributes are stored on the relationshipinternally within the Fulfillment Catalog repository. These general relationship attributes further define theexact nature of the relationship between a parent and its children.


Instance Value specific to a particular useof the relationship.

String(255)RelationshipValueRelationshipValue

Minimum Quantity of Children withinthe same GroupNumber (if applicable).

DecimalMinimum QuantityGroupMinQty

Maximum Quantity of Children withinthe same GroupNumber (if applicable).

DecimalMaximum QuantityGroupMaxQty

Start Date for the relationship to beeffective (if applicable).


End Date for the relationship to beeffective (if applicable).

DateEnd DateEndDate

Sequence of provisioning (Provideaction) step for this child records (ifapplicable).

DecimalSequenceNumberSequenceNumber

Sequence number for Cease action.DecimalCease SequenceCeaseSequenceNumber

Sequence number for Update action.DecimalUpdate SequenceUpdateSequenceNumber

Autoprovision.BooleanAuto ProvisionAutoProvision

Relationship Attributes for ProductComprisedOf Relationship

Name of Relationship:ProductComprisedOf

DescriptionDisplay inRecord List

LengthDataTypeDisplayName

Attribute

Include if performing thespecified fulfillment action.

Yes255StringActionActionID



Name of Relationship:ProductComprisedOf

DescriptionDisplay inRecord List

LengthDataTypeDisplayName

Attribute

Tag name for repositoryinstance.

Yes256StringProjectTagName

ProjectTagName

To develop the ProductDependsOn feature, following relationship attributes are added to theProductRequiredFor relationship

Relationship Attributes for productRequiredFor Relationship

Name of Relationship:productRequiredFor

SearchableDisplay in RecordList

LengthDataTypeDisplay NameAttribute

No.Yes256StringSourceActionsourceAction

No.Yes256StringTargetActiontargetAction

No.YesBooleanOCVValidationReqOCVValidationReq

NoYes256StringProject Tag NameProjectTagName

Relationship Attributes for ProductDependsOn Relationship

Name of Relationship:productDependsOn

SearchableDisplay inRecord List

LengthDataTypeDisplay NameAttribute

No.Yes256StringSourceActionsourceAction

No.Yes256StringTargetActiontargetAction

NoYes256StringProject TagName

ProjectTagName

Relationship Attributes for CharacteristicCharge Relationship

Name of Relationship:CharacteristicCharge


Display NameAttribute

Relationship Value.String(256)Relationship ValueRelationshipValue

Tag name for relationship instance.String(256)Project Tag NameProjectTagName

Relationship Attributes for PriceRequiresCharacteristic Relationship



Name of Relationship:PriceRequiresCharacteristic





Relationship Attributes for CompatibleCharacteristic Relationship

Name of Relationship:CompatibleCharacteristic





Relationship Attributes for IncompatibleCharacteristic Relationship

Name of Relationship:IncompatibleCharacteristic





Relationship Attributes for Characteristic Relationship

Name of Relationship:Characteristic




Evaluation Priority.String(4000)Evaluation PriorityEvaluationPriority

Include if performing the specifiedfulfillment action.

String(255)ActionActionID


Relationship Attributes for AllowanceComprisedOf Relationship

Name of Relationship:AllowanceComprisedOf




Relationship Attributes for AllowanceGovernedBy Relationship



Name of Relationship:AllowanceGovernedBy




Relationship Attributes for AllowanceRequiresCharacteristic Relationship

Name of Relationship:AllowanceRequiresCharacteristic




Relationship Attributes for AllowanceRequiresParty Relationship

Name of Relationship:AllowanceRequiresParty




Relationship Attributes for AllowanceRequiresProduct Relationship

Name of Relationship:AllowanceRequiresProduct




Relationship Attributes for AllowanceRequiresSegment Relationship

Name of Relationship:AllowanceRequiresSegment




Relationship Attributes for CharacteristicComprisedOf Relationship

Name of Relationship:CharacteristicComprisedOf




Relationship Attributes for HasDatatype Relationship



Name of Relationship:HasDatatype




Relationship Attributes for DiscountComprisedOf Relationship

Name of Relationship:DiscountComprisedOf




Relationship Attributes for DiscountGovernedBy Relationship

Name of Relationship:DiscountGovernedBy




Relationship Attributes for DiscountRequiresCharacteristic Relationship

Name of Relationship:DiscountRequiresCharacteristic




Relationship Attributes for DiscountRequiresParty Relationship

Name of Relationship:DiscountRequiresParty




Relationship Attributes for DiscountRequiresProduct Relationship

Name of Relationship:DiscountRequiresProduct




Relationship Attributes for DiscountRequiresSegment Relationship



Name of Relationship:DiscountRequiresSegment




Relationship Attributes for HasOrgs Relationship

Name of Relationship:HasOrgs




Relationship Attributes for HasPeople Relationship

Name of Relationship:HasPeople




Relationship Attributes for PartyCompatibleWithSegment Relationship

Name of Relationship:PartyCompatibleWithSegment




Relationship Attributes for PartyHasSegment Relationship

Name of Relationship:PartyHasSegment




Relationship Attributes for PartyIncompatibleWithSegment Relationship

Name of Relationship:PartyIncompatibleWithSegment




Relationship Attributes for DataForParty Relationship



Name of Relationship:DataForParty




Relationship Attributes for PlanFragmentHasMilestone Relationship

Name of Relationship:PlanFragmentHasMilestone




Relationship Attributes for PolicyRuleComprisedOf Relationship

Name of Relationship:PolicyRuleComprisedOf




Relationship Attributes for PolicyRuleRequiresCharacteristic Relationship

Name of Relationship:PolicyRuleRequiresCharacteristic




Relationship Attributes for PolicyRuleRequiresParty Relationship

Name of Relationship:PolicyRuleRequiresParty




Relationship Attributes for PolicyRuleRequiresProduct Relationship

Name of Relationship:PolicyRuleRequiresProduct




Relationship Attributes for PolicyRuleRequiresSegment Relationship



Name of Relationship:PolicyRuleRequiresSegment




Relationship Attributes for PriceAlteredByAllowance Relationship

Name of Relationship:PriceAlteredByAllowance




Relationship Attributes for PriceAlteredByDiscount Relationship

Name of Relationship:PriceAlteredByDiscount




Relationship Attributes for PriceComprisedOf Relationship

Name of Relationship:PriceComprisedOf




Relationship Attributes for PriceGovernedBy Relationship

Name of Relationship:PriceGovernedBy




Relationship Attributes for PriceRequiresParty Relationship

Name of Relationship:PriceRequiresParty




Relationship Attributes for PriceRequiresProduct Relationship



Name of Relationship:PriceRequiresProduct




Relationship Attributes for PriceRequiresSegment Relationship

Name of Relationship:PriceRequiresSegment




Relationship Attributes for CompatibleParty Relationship

Name of Relationship:CompatibleParty




Relationship Attributes for CompatibleProduct Relationship

Name of Relationship:CompatibleProduct




Relationship Attributes for CompatibleSegment Relationship

Name of Relationship:CompatibleSegment




Relationship Attributes for IncompatibleParty Relationship

Name of Relationship:IncompatibleParty




Relationship Attributes for IncompatibleProduct Relationship



Name of Relationship:IncompatibleProduct




Relationship Attributes for IncompatibleSegment Relationship

Name of Relationship:IncompatibleSegment




Relationship Attributes for OfferingPublishedInCatalog Relationship

Name of Relationship:OfferingPublishedInCatalog




Relationship Attributes for ProductGovernedBy Relationship

Name of Relationship:ProductGovernedBy




Relationship Attributes for ProductPricedBy Relationship

Name of Relationship:ProductPricedBy






Sample Data Examples with the Fulfillment Catalog Telco DataModel

The following screenshots illustrate key data concepts of the Fulfillment Catalog Data Model in a real-worldscenario, based on the TIBCO Telco Product Catalog structure.

Segment Data

Segment data represent Business Entities outside of the Product Catalog domain that may be used to definerule conditions for a Product Offering, Price, or Policy Rule.

Figure 4:The list of defined Market Segments (Consumer, Corporate, SME)

Figure 5: Segments are used to define conditions for Products or Prices.Tariff "TA_000017" is availableto Post paid Corporate or SME Customers only

Product Data

From a data modeling perspective, Products are broken into Product Offerings, Composite Products, andComponents. A Component can be a physical device, a Tariff, Options or Services that a Customer mighthave. Components can have any number of Characteristics or Features that define the Component's capabilities.Components can be classified by an extensible Class and Subclass. The following examples demonstratecommon types of components: Device, Tariffs, Services, and Options. Further classes can always be addedto meet new product requirements.



Recursive levels of Product Data

As stated above, a top level logical distinction of a Product Offering may contain one or many CompositeProducts and/or one or many Components. The data model itself allows for any of these entities to berecursively nested to any number of Component levels. This means that a Component may be composed ofa lower level of Components, which in turn may be composed of still lower level components. A simpleexample can be a Device component, for example, Modem, composed of two lower level (and mutuallyexclusive as a choice) Option components (Self Install versus Installation Service). The data model allowsfurther levels of componentization (for example, the Self Install Component, might be comprised of an "IPAddress Provisioning Component" and a "Service Start Component".

Figure 6: An example list of different components, product offerings (bundles), and composite products.The classification type can be extended at any time to classify additional components.

Devices/Hardware

A Modem with optional services underneath (install options). The Modem has the characteristic of providingADSL capability.



Figure 7: Devices Hardware

Tariffs

Products can express compatibilities with other Products or Characteristics. Tariffs, for instance can be definedto be compatible with characteristics. In this manner Tariffs need not be tied to a list of distinct devices, butmay instead be declared as compatible with any device that provides a specific characteristic. In this example,the Fixed Line Flat Tariff is defined to be compatible with any device that provides ADSL capability:

Figure 8:Tariffs

Services

Services are standalone optional services offered to a customer. Often they modify a usage charge a customeralready has from a Tariff, or they may represent new services charged separately.

In the example below, the Service Product is modeled below, with the associated billing charge defined bythe PRODUCTPRICEDBY relationship.



Figure 9: Services Relationship

The Charge for the service is defined below. Note that the fixed charge of 5 Euros applies to the first 40 SMSmessages, as defined by the "Charge From" and "Charge To" parameters. Also note that the Charge Priorityof 1 means that this price overrides any other SMS charges that the customer may have on any other Tariffs:

Product

Product represent bundled Products that can be offered or sold to customers. At the basic level, a Productcontains other Products, and can then be further refined to express compatibility or other requirements forthe bundle as a whole:



Composite Products and Complex Product Offerings

Products may also be composites of other products. In this example three Composite Groups have beencreated that is used later in a more complex Product Offering Bundle:

The Group Mobile Office A is comprised of a selection of Tariffs, a Device, and an entire Bundled ProductOffering:

The composite groups themselves are not sellable offerings, but they are then used to define a more complexProduct Offering (Mobile Office Bundle consists of three separate packages, represented by Groups A, B, andC). Note that at any level, additional compatibility or other rules may be added to further define the conditionsfor offering/purchasing the product:



An expanded view of the sub-component within the Composite component "Group_Mobile_Office_A" ofthe Bundle component "Mobile Office Bundle":

Extensibility: Adding a new Product Component

The Telco Product Catalog is designed to be flexible to support future sellable products and offerings. Logicallythe Product Catalog is divided into Product, Composite Products, and Components. Components are furtherclassified by Class Type. Common Component Classes include Device, Tariffs, and Services. Entirely newclassifications may be created and added to support future device or service classifications. In the followingexample, a new generic "Component" classification has been added to the list of Component Types:



Components and Product Hierarchies

Any new component represents a logical classification, and components may be built up from othercomponents (for example, a Device component might be composed of other Device components). It is importantto note, therefore, that the list of component classifications does not represent the number of levels allowedwhen creating a product offering, it merely represents common classifications of a component. To state thingsmore succinctly, the complexity of the products you model is not limited by the TIBCO CollaborativeInformation Manager Telco data model, for example, you can have a Product Offering consisting of anynumber of components, that in turn may be built up by other components, recursing down to however manylevels of componentization you desire.

New components can then immediately be created and maintained within the Catalog, classified by the newclassification (in this example the new component class is a generic "Component"):

Price

The Product Catalog stores ProductPrice, Simple, Price Group (or Price Matrix), and Tariff Usage Chargeinformation. The following image displays the various tariff charges that are modeled and linked to theappropriate Product Component.



An example classification list of price entities:

Simple Price

A simple price or usage charged is defined as Product Offering Price record. In the case of a Usage Charge,the type of usage is captured in order to match the usage fee to the feature being used:

Figure 10:

Figure 11:

Figure 12:

Composite Pricing

More often, usage charges define a range of pricing based on number of uses, type of use, or other factors.Such groupings are represented by composite charges:



Composite Pricing Detail

The price breakdown for each tier is often defined by segmentation. In this example different charge amountsare applied depending on the network usage (seen in the PRICEREQUIRESSEGMENT relationships, a chargeof .10 cents is applied for Fixed National or other mobile networks, versus .05 for SMS messaging on ownnetwork):

Charge Group A 1 Detail:

Charge Group A 2 Detail:



Tariff Usage Group

For PRICE that represent the charge information for Tariffs, each Price record is further grouped into a TariffUsage class. This lets any number of complex charge information to be easily linked to the appropriate Tariff.

In the example below, Charge Group A is linked to the Product Tariff A (seen in the PRICEOF relationshiplink).

Tariff A charges are comprised of a flat Monthly Tariff Charge, along with charges applied to Voice, SMS,and MMS usage:

Party Data

Simple Corporate Hierarchy:





Additional Class type for PRICE - Corporate Framework Agreement

Below is the additional definition of 'Corporate Framework Agreement' as a Class Type for PRICE. It representsa top-level Price Plan that may apply to a Party or Several Parties. The Corporate Framework Agreement canhave lower level (child) price elements describing any combination of special product pricing relevant onlyto the Party, particular subsidiaries or Roles/People specified.

PRICE: PRICEType


Top-Level Price Plan associatedwith a Party Entity. May have child

Corporate Framework AgreementCorporate Framework Agreement

price plans to further describeprices for the associated Party orParties.

Corporate Framework Agreement Definition

A Corporate Framework Agreement is designed to be the top-level record that describes a complete set ofprice lists and product offerings available to a Party (Corporation), describing global discounts and productprice lists, as well as any specific price/product lists for the corporation's subsidiaries and or employee roles(for example, special pricelists/product lists for Senior Management). By definition it is designed to ALWAYSrequire a Party or Parties to apply to.

Together with the Party Entity, the Corporate Framework agreement is a complex object describing entireprice agreements for Corporations.

Corporate Framework Agreements - PRICE Class

The screens describe the creation of a Corporate Framework Agreement (CFA) for the fictional corporation,ACME Worldwide. The major price agreement examples are:

1. Defining the Corporate Framework Agreement and applying it to ACME Worldwide.

2. Adding Child Price entities in two equally valid ways:a. Adding specific price entities for ACME worldwide that identify negotiated fixed prices for products

in the ProductOffering repository.b. Alternatively using standard price entities (for example, non-ACME, generic price entities) and applying

ACME-specific price discount entities.

3. Creating a specific price object that applies only to an ACME subsidiary or Employee Role.4. The modeling described in the above bullet points may be created ad infinitum to create as many specific

price objects necessary to fully describe a complete CFA.

Scenario

ACME Worldwide CFA agreement calls for the following:

For ACME Worldwide and all Subsidiaries the following has been agreed

1. SMS usage is a flat 5 cents per SMS message for all employees.2. A 10% discount off the standard price will apply if an employee purchases any from a list of specified

devices.3. Voice usage charges will be charged at a 10% Discount against the Standard Tariff A price.4. Senior Management may purchase any GSM device for free.



Example 1: ACME Worldwide, is a multi-subsidiary Corporation modeled with 2 subsidiaries and 2 EmployeeRoles as displayed:

Let us create a simple Corporate Framework Agreement for ACME.

The Top Level Corporate Framework Agreement is created as a "container" and associated with the Party"ACME Worldwide": The CFA class does not normally specify pricing, as it is meant to group more complexprice objects underneath it.

Example 2a. We can now create and add "Child" price entities to the CFA. The first price entity we create isan ACME specific price for SMS usage (.05 per use):



The Tariff is for SMS usage (the Usage=Characteristic, and the CharacteristicsCharge Relationship specifies"SMS"). Also note that we have made this price object a child of the CFA_1 price object. Therefore, this Tariffwill apply only to ACME worldwide, since it is part of ACME's CFA_1 price agreement.

Example 2b Instead of creating a specific price object for ACME we can instead use standard price objectsand apply PriceDiscounts. The next examples demonstrate this method.

Modeling a 10% discount against a existing standard prices Before we model an ACME Discount, Beloware definitions for standard price objects for various Devices:

Standard Price object for ALL GSM devices (For example, no Discount specified):

Standard Price for Wireless router, no Discount specified:



Creating a specific ACME Price Discount object:

We now create a Price Discount object specific to ACME Worldwide and referencing the above standardprice objects. We create a discount of 10 Percent for One-Time charges (for example, the price of the device).We make the Discount require the Party "ACME Worldwide", and attach it to the Standard Price Objects thatwe want the discount to apply to. Finally, we also add the discount to the CFA_1 Corporate FrameworkAgreement:

the repository name is PriceDiscount. Discounts and Allowances are in separate repositories (mastercatalogs) and are used to MODIFY Prices in the PRICE repository.

Modeling a 10% discount against an existing, standard Tariff. This is another example that shows modelingan ACME specific discount against a more complex price object: the Tariff.

Typically, a Tariff price is composed of a price matrix of charge "bands". A Voice Tariff, for example mightbe composed of two charge bands:

1. For voice usage up to 500 minutes, there is no charge

2. For voice usage over 500 minutes, a charge of .10 per minutes is assessed.

Typically a Tariff price is composed of a price matrix of charge "bands". A Voice Tariff, for example mightbe composed of two charge bands:

The Tariff A has no charges related to itself, instead it has two child price objects that specify a chargeband of 0 cents per minute and 10 cents per minute.



The detailed charges of the two child records (Voice_0_500, Voice_500_and_Over) is below

Figure 13: Voice_0_500

Figure 14: Voice_500_and_Over



Creating a specific ACME Price Discount object:

We now create a Price Discount object specific to ACME Worldwide and apply it to this group of TariffCharges. We create a discount of 10 Percent for "Feature" charges (for example, use of the specified featureon the standard price object). We make the Discount require the Party "ACME Worldwide", and attach it toVoice_Tariff_A price object. Finally, we also add the discount to the CFA_1 Corporate Framework Agreement:

The catalog name is Discount. Discounts and Allowances are in separate repositories (master catalogs)and are used to MODIFY Prices in the PRICE repository.

Example 3. The next example displays how to add specific rules that apply to a subsidiary or specific employeerole within a Corporation. In this example, let us model the requirement that Senior Managers get GSMdevices for Free (overriding the already modeled 10% discount). For this example we create a specific PriceObject and make it require the Senior Management role for ACME. To complete it we also attach it to theCFA_1 Corporate Framework Agreement:



Example 4 : Complete CFA

The complete CFA object is displayed as:



Chapter

3SID-based Data modeling for the Product Catalog

The concepts for SID define self-describing Business Entities that can be extended or added to as the businessrequires. You can use all or some of the entities described below as they see fit.

The SID data modeling concepts described in this section are logical data diagrams only. SID describeslogical constructs, not an actual database dictionary. This chapter includes the details of how such constructsare physically mapped into the TIBCO® Fulfillment Catalog Data Model in the next section.

Topics

• ProductOffering ABE and other Top-Level SID Entities for the Telco Product Catalog Model• SID Business Entities Below ProductOffering• SID Patterns for Complex Entities and Extensibility


ProductOffering ABE and other Top-Level SID Entities for the TelcoProduct Catalog Model

From a SID perspective, the TIBCO® Fulfillment Catalog Product Catalog model uses the following top-levelSID Business Entities.

At the top-level, Product Offerings make up a Base Product Catalog, which are then related to other ABE'sas displayed:

Figure 15: Base Product Catalog

A Product Offering is the Atomic Business Entity (ABE) that describes an offer able product to a customer,be it a simple product or a composite of multiple products. For both SID and Fulfillment Catalog's Telco DataModel, the Product Offering Entity is the main object for the Product Domain.

SID also allows Product Offering Entities to be related to other Business Domain entities to express conditionson which an Offering is available. For instance, an Offering may only be valid for on-line sales (Sales ChannelABE), or may be offered to business but not consumers (Market Segment ABE). This can be modeled fromeither the Product Offering Entity (making the relationship always true) or for Subset ProductCatalogOfferings(making the relationship true only in the context of the specific catalog).

ProductOfferings may be offered to customers all together, or they may be filtered into any number of subsetcatalogs exposed to customers. Subset Product Catalogs in SID are called ProductCatalogs and representspecific offerings available to customers, based on a variety of factors. They can represent an On-Line catalogor a Small/Medium Enterprise catalog, or any other delineation.


74 | SID-based Data modeling for the Product Catalog

SID Business Entities Below ProductOffering

The SID Data Model expresses numerous Business Entities and methods for modeling data objects. For theTIBCO Collaborative Information Manager Data Model, the principal Business Entities modeled within ourdatabase were listed next to each Data Dictionary Object in Section 2 of this document, you may refer to otherSID documentation for further details.

Figure 16: A SID Product Example

TIBCO Collaborative Information Manager Uses the logical entities expressed in SID’s Product Domain andexpresses then within it’s own Data Dictionary. Each Fulfillment Catalog repository, relationship, and attributeuse the SID names for internal reference. However, display names to the business user are always allowedto be as customer-centric as you wish.


SID-based Data modeling for the Product Catalog | 75

SID Patterns for Complex Entities and Extensibility

Conceptually, Fulfillment Catalog utilizes the SID Pattern of Atomic/Composite Entities to model groupingand containment of complex entities, and fully supports the extensible data modeling concept expressed inSID:

Atomic/Composite Entities within Fulfillment Catalog:

The Fulfillment Catalog Data Model supports the SID concept of Composite/Atomic Data Models. Thisallows for Fulfillment Catalog to Model complex Product Offerings that may be bundles of other ProductOfferings).

In Fulfillment Catalog, each repository can contain both Atomic Entities and Composite Entities. For CompositeEntities, the TIBCO Collaborative Information Manager relationship of "…CompositeComprisedOf is usedto link Composite Entities with their Atomic constituents:

Figure 17: Example of Composite and Atomic ProductOfferingStructure within TIBCO CollaborativeInformation Manager

Extending Existing Entities within the Fulfillment Catalog Data Model


76 | SID-based Data modeling for the Product Catalog

Fulfillment Catalog's Business Entities can be extended by either:

• adding new Attribute Groups directly into the existing Data Repository.

Or• by creating a new Extension Data Repository, with a relationship to the original ABE Data Repository.

For Fulfillment Catalog, new Attribute Groups within an existing Data Repository can be treated as "logically"separate objects, with their own security, access control, read/write, and integration.

Because of this either method of extending the Fulfillment Catalog Data Model is valid from a SID perspective:

Fulfillment Catalog Data Model Extension via AdditionalData Repository and Relationships

Fulfillment Catalog Data Model Extension via AttributeGroups (Single Data Repository, logically separated byAttribute Group)


SID-based Data modeling for the Product Catalog | 77

Chapter

4Interfaces

Topics

• Import Interfaces• Export Interfaces


Import Interfaces

TIBCO® Fulfillment Catalog uses TIBCO Collaborative Information Manager's standard Import capabilities.Data may be maintained manually using the web-based user interface, or the following integration methodsapply:• Web Services• Flat file import• Database import

For details, refer to the TIBCO Collaborative Information ManagerTM documentation.


80 | Interfaces

Export Interfaces

Model Publishing

TIBCO® Fulfillment Catalog publishes to downstream systems via an XML doc. By default, the interfacemethod is over JMS (TIBCO Enterprise Message Service). The data model publish can be performed as acomplete data export, or as incremental update based on the past history of exports.

The data models published are described in the following XML schema files:• ProductModel.xsd (Main Product and Service Model Definition).• CustomerModel.xsd (Party entity information).• Segment.xsd (Segmentation information).• PlanFragmentModel.xsd (PlanFragment information).• ActionModel.xsd (ActionModel information).

These .xsds are available($AC_HOME/schema/models) for any third party to use for the purposes of interfacingwith TIBCO® Fulfillment Catalog. The complementary product, TIBCO® Fulfillment Order Managementnatively accepts these data schemas.

Enterprise Data Export

TIBCO Fulfillment Catalog provides capability to export enterprise data in a format which can be used toimport the data in a different enterprise. The data exported here can be the complete enterprise data whichis called Full Data Export. Or it can be selective data based on the Project Tag Name attribute and is calledPartial Data Export.


Interfaces | 81

Date post:	09-Jun-2018
Category:	Documents
Upload:	vanthu
View:	213 times
Download:	0 times

Software Release 2.1.0 September 2013 · Fulfillment Catalog Data Repository Dictionary ... TIBCO...

Documents