data-model-reference-guide
Uploaded by
sara Hosseinjanidata-model-reference-guide
Uploaded by
sara HosseinjaniSiebel
Data Model Reference Guide
January 2020
Siebel
Data Model Reference Guide
January 2020
Part Number: F84298-01
Copyright © 1994, 2020, Oracle and/or its affiliates.
Authors: Siebel Information Development Team
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected
by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate,
broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display in any part, in any form, or by any means. Reverse engineering,
disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report
them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the
following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or
activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or
accessed by U.S. Government end users are "commercial computer software" or “commercial computer software documentation” pursuant to the
applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display,
disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated
software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer
documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The
terms governing the U.S. Government’s use of Oracle cloud services are defined by the applicable contract for such services. No other rights are
granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for
use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware
in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe
use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks
of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle
Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and
services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible
for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable
agreement between you and Oracle.
The business names used in this documentation are fictitious, and are not intended to identify any real companies currently or previously in existence.
Siebel
Data Model Reference Guide
Contents
Preface .................................................................................................................................. i
1 What’s New in This Release 1
What's New in Siebel Data Model Reference, Siebel CRM 19.1 Update ................................................................................ 1
What's New in Siebel Data Model Reference, Siebel 2018 ..................................................................................................... 1
2 Siebel Logical Model 3
Siebel Logical Model ...................................................................................................................................................................... 3
Overview of Siebel Data Model ................................................................................................................................................... 3
Entity Relationship Diagram Conventions ................................................................................................................................ 4
Entity Relationship Diagrams and Descriptions for Siebel Cross-Industry Applications ................................................ 7
Entity Relationship Diagrams and Descriptions for Siebel Industry Applications ......................................................... 122
3 Siebel Physical Model 227
Siebel Physical Model ................................................................................................................................................................ 227
Data Model Naming Conventions .......................................................................................................................................... 227
Data Model Type Definitions ................................................................................................................................................... 230
Columns of Numeric Physical Type ....................................................................................................................................... 233
Siebel System Fields .................................................................................................................................................................. 234
INTEGRATION_ID Columns ...................................................................................................................................................... 234
Include Only Field ...................................................................................................................................................................... 235
Siebel Repository ........................................................................................................................................................................ 235
Database Schema Version ........................................................................................................................................................ 235
Limit Checking for Data Types ................................................................................................................................................ 235
Validating the Siebel Schema .................................................................................................................................................. 236
Party Model Unifies Access to Data ...................................................................................................................................... 236
Generating a Report about Tables ......................................................................................................................................... 237
4 Schema Changes 239
Schema Changes ........................................................................................................................................................................ 239
Siebel
Data Model Reference Guide
New Tables Added to Innovation Pack 2017 ........................................................................................................................ 239
New Table Columns Added to Innovation Pack 2017 ......................................................................................................... 239
Modified Columns in Innovation Pack 2017 ......................................................................................................................... 241
New Table Indexes Added to Innovation Pack 2017 ........................................................................................................... 242
Table Index Columns That Have Been Added in Innovation Pack 2017 ......................................................................... 242
Siebel Preface
Data Model Reference Guide
Preface
This preface introduces information sources that can help you use the application and this guide.
Using Oracle Applications
To find guides for Oracle Applications, go to the Oracle Help Center at http://docs.oracle.com/.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website.
Contacting Oracle
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For
information, visit My Oracle Support or visit Accessible Oracle Support if you are hearing impaired.
Comments and Suggestions
Please give us feedback about Oracle Applications Help and guides! You can send an email to:
[email protected].
i
Siebel Preface
Data Model Reference Guide
ii
Siebel Chapter 1
Data Model Reference Guide What’s New in This Release
1 What’s New in This Release
What's New in Siebel Data Model Reference, Siebel CRM
19.1 Update
No new features have been added to this guide for this release. This guide has been updated to reflect only product
name changes.
What's New in Siebel Data Model Reference, Siebel 2018
No new features have been added to this guide for this release. This guide has been updated to reflect only product
name changes.
Note: Siebel 2018 is a continuation of the Siebel 8.1/8.2 release.
1
Siebel Chapter 1
Data Model Reference Guide What’s New in This Release
2
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
2 Siebel Logical Model
Siebel Logical Model
The entity relationship diagrams (ERDs) included in this chapter are those that are the most useful to individuals
involved in implementing or integrating Siebel Business Applications. These diagrams cover the application areas that
are most relevant to a functional understanding of the application.
The information on ERDs is organized as follows:
• Overview of Siebel Data Model
• Entity Relationship Diagram Conventions
• Entity Relationship Diagrams and Descriptions for Siebel Cross-Industry Applications
• Entity Relationship Diagrams and Descriptions for Siebel Industry Applications
Overview of Siebel Data Model
Oracle has made and continues to make a significant investment in modeling the business functions of sales,
marketing, and service organizations. The entity relationship diagrams included in this chapter represent the logical
model for the current release of Siebel Business Applications. In some areas, the model extends beyond the current
implementation. Published entities, therefore, might appear in the logical model that might not be implemented in the
physical model at the present time.
Oracle’s Siebel Data Model defines how the data used by Siebel Business Applications is stored in a standard relational
DBMS such as Oracle, DB2, or Microsoft SQL Server. The Siebel Data Model also defines some of the data integrity
constraints validated by Siebel Business Applications.
Note: The terms and conditions of your license agreement with Oracle permits use only of those portions of the
Siebel Data Model that correspond to the Siebel CRM products you have purchased. You are not entitled to use any
portion of the Siebel Data Model to support Siebel CRM products for which you have not purchased the required
licenses.
The Siebel Data Model is designed for speed and performance in data entry, running limited scope queries, and
managing processes like call scripting. These tasks are considered transactions, and the database used is called an
online transaction processing (OLTP) database.
Optimizing a database used for these purposes requires a design, or schema, that puts each unit of information in a
single location in the database. This allows you to update the data efficiently, since you do not need to update the same
unit of data in several different locations. Most tables in an OLTP database includes links, or join paths, to other tables,
sometimes to many other tables.
The database design used in an OLTP database is usually normalized. There are several levels of database
normalization, ranging from first to fifth normal form. The Siebel database is in third normal form.
The information in this reference is intended as an aid in configuring and using Siebel Business Applications.
3
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
CAUTION: Do not attempt to insert or update data in the Siebel Business Applications tables through non-Siebel
application products. Doing so can render your Siebel database unusable; additionally, you limit the ability of Oracle to
provide you with quality support.
To learn how to configure an application to insert, update, and delete data interactively, read the Siebel Developer's
Reference . To learn how to insert, update, and delete data in large quantities, see Siebel Enterprise Integration Manager
Administration Guide .
Note: The Siebel Bookshelf is available on Oracle Technology Network (http://www.oracle.com/technetwork/
indexes/documentation/index.html) and Oracle Software Delivery Cloud. It might also be installed locally on your
intranet or on a network location.
Entity Relationship Diagram Conventions
The Siebel logical model represents the following in Siebel Business Applications:
• Entities
• Relationships between entities
ERDs represent the significant entities and relevant relationships in a functional area. To enhance their readability, the
diagrams do not include every relationship and subtype. Some many-to-many relationships have also been preserved
instead of showing them as one-to-many relationships around intersection tables in the logical model.
This topic describes entity relationship diagram conventions, as follows:
• General Entities
• Exclusive Arc Relationship
• Recursive Relationship
General Entities
The following figure shows the diagram conventions for general entities used in this guide. The conventions are as
follows:
• A mandatory relationship is illustrated by a solid line.
• An optional relationship is illustrated by a dotted line.
• A one-to-many-relationship (1:M) has a "tripod" on one end of the relationship line.
• A many-to-many-relationship (M:M) has a "tripod" on both ends of the relationship line.
4
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Exclusive Arc Relationship
The following figure illustrates an example of the exclusive arc relationship. An exclusive arc is an arc across two or more
relationship ends; you can read each exclusive arc relationship as follows:
Each [entity] must be [relationship name] either to only one [entity]
OR [relationship name] to only one [entity]
For example, each Product Comparison must be to only one Product Internal or to only one Product External as shown
in the following figure.
5
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Recursive Relationship
The following figure illustrates an example of the recursive relationship. A recursive relationship is one in which an entity
has a relationship to itself. For example, each activity can be part of only one activity or each activity can be made up of
one or more activities.
Recursive relationships are almost always optional, and either one-to-many or many-to-many.
6
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Relationship Diagrams and Descriptions for Siebel
Cross-Industry Applications
The ERD descriptions and diagrams in this topic apply to Siebel Cross-Industry Applications. These applications are
designed for particular business activities and operate across industries. They include the Siebel Call Center, Siebel
Service, Siebel Sales, Siebel Marketing, and other applications. The following table provides a list of ERDs in alphabetic
order.
ERD Name Functional Area
Account General
Adjustment Group General
Asset Management General
Auction General
Auto Email Response Generator General
CG Promotion Planning Marketing
Compensation Planning Administration ERM
Compensation Planning Execution ERM
Competency Management System ERM
Content Management General
Contract Conditions General
Contracts General
Data Visibility General
Dun & Bradstreet Integration Sales and Marketing
Employee KPI ERM
Expense Reports General
7
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Field Service Inventory Service
Field Service Scheduler Service
Forecasts Sales and Marketing
High Tech Marketing Development Fund Marketing
In-Memory Next Best Action Marketing
Invoiceable Charges Service
Invoices Service
Lead Management Sales and Marketing
Marketing Budget Request Marketing
Marketing Campaign Marketing
Marketing Collaboration Marketing
Marketing Encyclopedia Sales and Marketing
Marketing Event Driven Dialogue Marketing
Marketing Events General
Marketing Plans Marketing
Marketing Program Marketing
Marketing Resource Management: Marketing
Document
Opportunity Management Sales
Order and Promotion General
Order Life Cycle General
8
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Orders General
Partner Collaboration General
Partner Program Registration General
Party Model General
Payments General
Performance Review ERM
Personal Account Industry-Specific
Personal Financial Review Industry-Specific
Pricing General
Pricing Comparison Energy
Product Promotion General
Product Quality Tracking General
Product Recommendation and Offer General
Products or Services Service
Professional Services General
Promotion Group General
Revenue General
Sales Hierarchy and Credit Assignment Sales
Sales Portfolio Management Sales
Service Agreement Service
Service Calendars and Work Shifts Service
9
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Service Request Service
Shipment General
Siebel Assistant General
Social Media General
Territory Management Sales
Territory Quota Rollup Sales
Textile, Apparel, and Footwear Consumer Sector
Time Sheet General
Trade Promotions General
Training Curriculum Course General
Training Test Engine General
Versioned Object Definition General
Warranty Service
Warranty Claim Service
Work Order Service
Account
This ERD (see the following figure) illustrates the account entity, a key entity in the Siebel Data Model. The account
entity appears in many diagrams in this publication, and is often referred to as an organization unit.
10
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
As shown in this figure:
• The account entity is a subtype of party composed of one or more people or contacts. An account is any
organization or subset of an organization that can be sold to or serviced. An account can represent a company,
a site, a subsidiary, a division, or any other subset of an organization. An account can also represent a
governmental agency, club, or other formal or informal group of individuals. Each account might be accessible
at one or more addresses.
• The account entity supports Global Account Views and Dynamic Hierarchy. This allows a universal view of all
customer interactions. The Global Account Views present accounts in the context of a customizable hierarchy,
allowing navigation to parent and child accounts. Roll-up and roll-down functionality gives users access
to account-specific information, and aggregate information including child accounts, activities, contacts,
opportunities, and the account team.
• Dynamic Hierarchy allows the Global Account Views to display a different hierarchy depending on the
business unit of the user. Each custom account hierarchy is represented completely in a relationship table. The
relationships are then denormalized into a separate table to be used for roll-up support.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Account Synonym S_ORG_SYN
Activity S_EVT_ACT
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
11
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Assignment Group (Territory) S_ASGN_GRP
Business Unit S_BU, S_ORG_EXT, S_PARTY
Characteristics S_CHRCTR
Dynamic Account Hierarchy S_DYN_HRCHY
Dynamic Account Hierarchy Node S_DYN_HRCHY_REL
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Industry S_INDUST
Market Segment S_MKT_SEG
Party S_PARTY
Payment Term S_PAYMENT_TERM
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Price List S_PRI_LST
Sales or Service Team Member S_ACCNT_POSTN
Adjustment Group
This ERD (see the following figure) illustrates the system for managing the various matrices for pricing, compatibility,
eligibility, product promotions, and so on. It allows the user to define a matrix, its dimensions, and all of its rules. This
new infrastructure allows the adjustment to be any value, not just a price amount.
12
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Adjustment Group S_ADJ_GROUP
Adjustment Group Dimension S_ADJ_GROUP_DIM
Product Compatibility Matrix Rule S_PRODCOMP_MTRX
Product Eligibility Matrix Rule S_PRODELIG_MTRX
Product Promotion Pricing Matrix Rule S_PROM_PMTRX
Standard Entitlement Pricing Matrix Rule S_STDENTL_PMTRX
Standard Product Pricing Matrix Rule S_STDPROD_PMTRX
Standard Training Pricing Matrix Rule S_STDTRNG_PMTRX
Asset Management
This ERD (see the following figure) illustrates how Siebel Business Applications track instances of assets. The diagram
shows how internal products can be made into assets and associated with an account or a contact to register ownership.
Additional relationships can be made between assets and accounts, contacts, and employees. Additional information
13
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
includes the related opportunities, the current business or personal address location of the asset, notes, and related
assets. There are also relationships with service requests, activities, and related part movements.
The following table shows the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Activity Part Movement S_ACTPART_MVMT
Asset Contact Relationship S_ASSET_CON
Asset Employee Relationship S_ASSET_EMP
Asset External Organization S_ASSET_ACCNT
Asset Feature S_ASSET_FEA
Asset Modification S_ASSET_TXN
Asset Relationship S_ASSET_REL
Business Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
14
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Competitive Metric S_CMPT_MTRC
Competitive Product Feature S_CMPT_PROD_FEA
Contact S_CONTACT, S_PARTY
Employee S_EMP_PER, S_CONTACT, S_PARTY
External Product S_PROD_EXT
Internal Product S_PROD_INT
Opportunity S_OPTY
Opportunity Asset S_OPTY_ASSET
Person S_CONTACT, S_PARTY
Personal Address S_ADDR_PER
Product Instance (Asset) S_ASSET
Service Request S_SRV_REQ
Auction
This ERD (see the following figure) illustrates how the Siebel Data Model represents the auctioning of goods or services
to bidders. An auction item can be a stand-alone offering, or can be a specific instance of an offering of a quantity of
product or of a particular asset for sale. An auction item must be listed by a corporate or individual user, but that user
can be either internal to or external to the Siebel-owning company. Auction items are displayed to bidders through one
or more categories in a catalog. Fulfillment of an auction item to the winning bidders can be tracked through one or
more order items. Finally, users can set up watched items, define alerts, and rate fellow listers or bidders.
15
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table shows the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Auction Alert Definition S_AUC_ALRT_DEF
Auction Item S_AUC_ITEM
Auction Item Bid S_AUC_BID
Auction Item Promotion S_AUC_ITM_PROMO
Auction Item Watch S_AUC_WATCH
Auction Lister/Bidder Rating S_AUC_RATING
Catalog S_CTLG
Catalog Category S_CTLG_CAT
Catalog Category Item S_CTLG_CAT_PROD, S_CTLGCAT_ASSET, S_CTLG_CAT_AUC
Order S_ORDER
Order Item S_ORDER_ITEM
16
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Party S_PARTY
Person S_CONTACT
Product S_PROD_INT
Triggered Auction Alert Item S_AUC_ALRT
User S_USER, S_CONTACT, S_PARTY
Auto Email Response Generator
This ERD (see the following figure) illustrates the data model for the automatic generation of a response to an inbound
communication. Incoming messages (inbound communications) are compared against a database of previously
categorized messages to categorize them in one or more categories. The categories are associated with predefined
template communication responses, used to generate a default response to each category of message. A notification
mechanism can be defined to alert a person whenever the usage of a category or template exceeds a predefined limit.
The following table lists the entities in this ERD and their corresponding tables.
17
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Activity S_EVT_ACT
Catalog S_CTLG
Catalog Category S_CTLG_CAT
Category Usage Notification S_COMM_CTG_NTFY
Communication Template Usage S_COMMTMPL_NTFY
Notification
Person S_CONTACT, S_PARTY
Problem Resolution Document S_RESITEM
Template Communication Response S_DMND_CRTN_PRG
CG Promotion Planning
This ERD (see the following figure) illustrates how Siebel Business Applications support the funding of trade promotions
in channel management and the Consumer Goods (CG) industry. Marketing development funds (MDFs) are defined for
an account, for a product line or product category, and for an accounting period. An MDF can be a fixed sum of money,
an accrual fund, or a mixture of the two. The value of the accrual fund is typically determined based on an accrual rate
multiplied by either the number of units sold, or the revenue in a given period from one or more specific products that
are representative of the product line or category of the fund. Planned expenses for the various tactics involved in the
planning and execution of product promotions can be allocated to one or more MDFs. Allocations that have not yet
been approved are considered fund requests. One or more such MDF allocations can be covered by a single payment to
the partner account.
Advanced Planning is a feature designed to address the process used by CG organizations to plan sales volume and
sales revenue at key accounts. Advanced Planning is part of a broader process called Trade Marketing. Trade Marketing
includes planning, executing, and analyzing sales.
18
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Authorized Product S_ORG_PROD
Fund Allocation S_MDF_ALLOC
Marketing Development Fund S_MDF
Marketing Event or Activity S_SRC
MDF Accrual S_MDF_ACCRUAL
Payment S_SRC_PAYMENT
Period S_PERIOD
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Price List S_PRI_LST
19
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Price List Item S_PRI_LST_ITEM
Product Internal S_PROD_INT
Product Line S_PROD_LN
Product Structure S_PROD_REL or S_PROD_ITEM
Promotion Plan S_SRC
Promotion S_SRC
Promotion Account S_SRC
Promotion Product S_SRC
Promotion Category S_SRC
Promotion Account Product S_SRC
Compensation Planning Administration
This ERD (see the following figure) illustrates the administration activities of compensation planning, which involve
setting up salary structures such as salary plan, salary grades, and job codes. In addition to salary structures, an
organization sets up compensation budgets, compensation types such as merit increase, bonus, promotion, and stock
options, planning periods, budget calculation and eligibility rules, guidelines and calculation of budget allocations for
employees.
20
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Business Unit S_BU
Compensation Budget Definition S_CP_BDGT
Compensation Budget Item S_CP_BDGT_ITEM
Compensation Budget Item For Employee S_CP_BDGT_EMP
Compensation Cycle Planning Period S_CP_PD_BDGTITM
Compensation Guideline Definition S_CP_GDLN
Compensation Guideline Factor LOV
Compensation Guideline Set S_CP_GDLN_SET
Compensation Guideline Table S_CP_GDLN_TBL
Compensation Planning Period S_CP_PERIOD
Compensation Region S_CP_REGN
Compensation Type LOV
21
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Compensation Valid Effectivity Date S_CP_EFF_DATE
Employee Eligibility S_APP_QUERY (PDQ)
Employee/Agent S_EMP_PER
Job Category LOV
Job Code S_JOB
Job Family S_JOB_FAMILY
Job Profile S_JOB_PRFL
Period S_PERIOD
Salary Grade S_SALARY_GRADE, S_SALPLAN_GRADE
Salary Plan S_SALARY_PLAN
Compensation Planning Execution
This ERD (see the following figure) illustrates the execution phase of compensation planning. In this phase, a workbook
is created for each of the authorized managers with the list of employees who report to them. The manager goes
through the planning process and decides on the merit, bonus, promotion, and stock option changes that he can grant
to his employees. Authorized persons such as managers, or HR personnel approve the plans. Totals are maintained for
each manager and organization.
22
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Business Unit S_BU
Compensation Budget Definition S_CP_BDGT
Compensation Budget Item S_CP_BDGT_ITEM
Compensation Budget Item For Employee S_CP_BDGT_EMP
Compensation Cycle Planning Period S_CP_PD_BDGTITM
Compensation Guideline Definition S_CP_GDLN
Compensation Guideline Set S_CP_GDLN_SET
Compensation Guideline Table S_CP_GDLN_TBL
Compensation Plan S_CP_PLAN
23
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Compensation Plan Comments S_NOTE_CP_PLAN
Compensation Plan For Employee S_CP_PLAN_EMP
Compensation Plan Item Detail S_CP_PLNITM_DTL
Compensation Plan Item For Employee S_CP_PLAN_ITEM
Compensation Plan Total S_CP_PLNITM_TOT
Compensation Planning Period S_CP_PERIOD
Compensation Type LOV
Compensation Valid Effectivity Date S_CP_EFF_DATE
Plan Approval S_CP_APPROVAL
Proxy Access To Plan S_USER_PROXY
Competency Management System
This ERD (see the following figure) illustrates how an organization can define a set of competencies that employees can
have or acquire over a period of time and an evaluation of employees' skill levels in those competencies. In addition,
information about an employee's past work experience, merits, honors, professional memberships and education
qualifications can be maintained. An organization can also define a list of courses and related skills which can be
associated with an employee when he or she complete those courses.
24
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Career Path S_JOB_PRFL_TRNS
Competency, Competency Category, Root S_CMPTNCY
Competency Category
Educational Qualification S_PER_EDU_QUAL
Employee Competency S_EMP_CMPTNCY
Employee Competency Change S_EMP_CMPT_CHG
Employee/Agent S_EMP_PER
Honors And Awards S_PER_AWARD
Job Code S_JOB
Job Profile S_JOB_PROFILE, S_JOBPRFL_CMPT
25
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Past Work Experience S_PER_WRK_EXP
Person S_USER, S_CONTACT
Professional Membership S_PER_PROF_MBR
Professional Qualification S_PER_PROF_CERT
Review Rating S_PERF_RATING
Review Rating Scale S_PERF_RTNG_SCL
Team Competency S_TEAM_CMPTNCY
Training Course S_PROD_INT_CRSE
Content Management
This ERD (see the following figure) illustrates how the Siebel Data Model supports the process of creating and
maintaining content through projects. A content project is made up of one or more content project items that represent
an item of master data, such as a product definition or an item of literature. Each content project item is an instance of
a content item type that is part of a content object. A content object is based on a business object and is published to
the production system through an EAI integration object. A workflow process governs the flow of the items in a content
project from conception through publication. Each item can be the responsibility of, reviewed by, or approved by one or
more Positions.
26
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Content Item Type S_CONTENT_TYPE
Content Object S_CONTENT_OBJ
Content Project S_CONTENT_PROJ
Content Project Item S_CONTENT_ITEM
Literature S_LIT
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Product S_PROD_INT
27
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Contract Conditions
This ERD (see the following figure) illustrates the usage of templates to create agreements. An agreement could
comprise one or more entitlements. A contracts administrator can define template entitlements, template benefits and
template conditions in addition to template terms. Template benefits and conditions could be for a specific product or
product line or product class or category. An entitlement could be created using the entitlement template and this would
create the corresponding benefits and conditions based on the corresponding template benefits and conditions. The
terms governing the agreement could be based on template terms.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Agreement S_DOC_AGREE
Benefit S_AGREE_BNFT
Category S_CTLG_CAT
Condition S_AGREE_COND
Condition Compliance S_AGR_COND_CMPL
Contract S_DOC_AGREE
Entitlement S_ENTLMNT
Entitlement Template S_ENTL_TMPL
28
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Object Class S_VOD, S_VOD_VER
Product S_PROD_INT
Product Line S_PROD_LN
Template Benefit S_ENTL_BNFTTMPL
Template Condition S_ENTL_CONDTMPL
Template Term S_AGR_TERM_TMPL
Term S_AGR_TERM_DESC
Contracts
This ERD (see the following figure) illustrates the significant entities related to general business contracts (quotes,
orders, agreements, and others). A contract is an agreement between two parties, usually to deliver goods or services in
exchange for payment. For example, a quote is an agreement between a company and a customer to guarantee a price
for a particular set of items if acted on within a specified time frame. The customer is usually an account, but can be a
person. The party on the other side of the contract is an internal or partner organization (or business unit). A contract is
composed of contract line items that specify the internal products, services, or assets to be covered under the terms of
the contract.
The following table lists the entities in this ERD and their corresponding tables.
29
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Account S_ORG_EXT, S_PARTY
Asset S_ASSET
Business Unit S_BU, S_ORG_EXT, S_PARTY
Contract S_DOC_AGREE, S_DOC_QUOTE, S_ORDER
Contract Line Item S_AGREE_ITEM, S_QUOTE_ITEM, S_ORDER_ITEM
Deleted Contract Item S_ORDER_ITM_DEL, S_QUOTE_ITM_DEL, S_ASSET_DEL
Internal Product or Service S_PROD_INT
Payment Term S_PAYMENT_TERM
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Price List S_PRI_LST
Data Visibility
The main business entities represented (see the following figure) in the Siebel Data Model fall into one of two super-
types: Master Data Item or Customer Data Item. A Master Data Item represents data set up and administered by
the company using Siebel Business Applications, such as products, literature, and price Lists. Master Data Items are
often categorized to make information more accessible. A user gains visibility to this data either through the person's
association with a business unit (multiple organization visibility) or through the person's access to items in a catalog
(access control). Access to items in a catalog is provided by making the category public, or by granting access to the
category to one or more access groups. Each access group can be made up of smaller access groups and can be made
up of one or more groups of users. Categories granted to a parent access group are automatically granted to all of its
child access groups, but categories granted to a child are not granted to its parents.
A Customer Data Item represents transactional data collected during the normal course of doing business such as
opportunities, quotes, orders, agreements, service requests, and activities. A user gains visibility to this data either
through the person's association with a business unit (multiple organization visibility) or more commonly through a
direct assignment of the person or the person's position to the item. A Customer Data Item is usually accessible to
one business unit, but is occasionally accessible to two or more business units. Each business unit can be made up
of smaller business units. A given type of customer data item is usually assigned to employees through position or
directly to the employee, but rarely both. Managers can be granted access to customer data items assigned to their
subordinates.
30
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Access Group S_PARTY
Account S_ORG_EXT
Activity S_EVT_ACT
Agreement S_DOC_AGREE
Business Unit S_BU, S_ORG_EXT, S_PARTY
Catalog S_CTLG
Category S_CTLG_CAT
Dynamic Account Hierarchy S_DYN_HRCHY
Dynamic Account Hierarchy Node S_DYN_HRCHY_REL
31
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Group S_PARTY
Internal/Partner Organization Unit S_ORG_EXT
Literature Item S_LIT
Opportunity S_OPTY
Order S_ORDER
Organization Unit S_ORG_EXT, S_PARTY
Party S_PARTY
Position S_POSTN, S_PARTY
Price List S_PRI_LST
Product S_PROD_INT
Quote S_DOC_QUOTE
Service Request S_SRV_REQ
Dun & Bradstreet Integration
This ERD (see the following figure) illustrates how Siebel Business Applications integrate with Dun & Bradstreet
Organization information. A D & B organization can be classified as doing business in one or more industries, and can
provide information about contacts at the organization and their management responsibilities. In addition, a D & B
organization can indicate its direct parent organization, its ultimate domestic parent, and its ultimate global parent. A
Siebel organization unit (for example, an account) can be related to its equivalent D & B organization and its associated
parent organizations. Contact information from one or more D & B organizations can be used to create one or more call
lists.
32
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Call List S_CALL_LST
Call List D & B Organization S_DNB_ORG_LST
D & B Contact Responsibility S_DNB_CON_MRC
D & B Management Responsibility Type S_DNB_MRC
D & B Organization S_DNB_ORG
D & B Organization Industry Classification S_DNB_ORG_SIC
D & B Standard Industry Classification S_DNB_SIC
Industry S_INDUST
Organization Industry Classification S_ORG_INDUST
33
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Organization Unit S_ORG_EXT, S_PARTY
Prospect S_PRSP_CONTACT
Employee KPI
This ERD (see the following figure) illustrates that Key Performance Indicators (KPI) can be defined and associated
with the objectives of an employee so that the employee and the manager of the employee manager can measure
achievement or current values against the goals set in the objectives of the employee.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
BUSINESS UNIT S_BU
EMPLOYEE PERFORMANCE S_EMP_PERF_MEAS
MEASUREMENT
GROUP, ACCESS GROUP S_PARTY
KEY PERFORMANCE INDICATOR S_KPI, S_KPI_AGRP
DEFINITION
KPI VALUE FOR EMPLOYEE S_EMP_KPI
34
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
KPI VALUE FOR OBJECTIVE S_PERF_MITM_KPI
KPI VALUE HISTORY S_EMPKPI_SNPSHT
ORGANIZATION UNIT, DIVISION S_ORG_EXT
PERFORMANCE MEASUREMENT ITEM S_PERF_MEAS_ITM
PERSON, EMPLOYEE/AGENT, OTHER S_CONTACT, S_EMP_PER, S_USER
PERSON
Expense Reports
This ERD (see the following figure) illustrates how Siebel Business Applications track employee expense reports.
Employees (for example, sales representatives, field service engineers, and professional services personnel) can track
expense items incurred for business purposes. These expenses can be associated with an account, an opportunity,
or a project, and can be related to an activity. Other employees or contacts involved in the expense can be associated
with the expense. The expenses in a specified reporting period can then be reported on an expense report for
reimbursement.
35
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Employee S_EMP_PER, S_CONTACT, S_PARTY
Expense Item S_EXP_ITEM
Expense Item Type S_EXP_ITM_TYPE
Expense Report S_EXP_RPT
Expense Report Approval S_EXP_RPT_APPR
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
36
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Party S_PARTY
Person S_CONTACT, S_PARTY
Project S_PROJ
Field Service Inventory
This ERD (see the following figure) illustrates how Siebel Business Applications track field service parts inventory.
Parts can be tracked in inventory as serialized assets or as nonserialized quantities of products. An instance of product
inventory defines a quantity of product in a given location with a given status and availability. Inventory quantities
cannot be modified directly. Instead, they are modified through inventory transactions that reflect each movement
of parts between locations, statuses, and availabilities. Inventory locations can be located at a third-party provider,
as well as within the internal organization. They can also be related to other inventory locations for the purposes of
replenishment or fulfillment.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Asset S_ASSET
Business Unit S_BU, S_ORG_EXT, S_PARTY
37
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Inventory Location S_INVLOC
Inventory Transaction S_INV_TXN
Organization Unit S_ORG_EXT, S_PARTY
Party S_PARTY
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Product Inventory S_PROD_INV
Product Inventory Category S_PROD_INV_CAT
Product Inventory Location S_PROD_INVLOC
Product or Service S_PROD_INT
Field Service Scheduler
This ERD (see the following figure) illustrates how the Siebel Data Model supports the scheduling of employees to
perform service activities within configured service regions. A service region corresponds to one or more ZIP codes
or other geographical representation, but can only be associated with a single time zone. The service region defines
a number of parameters, time duration maps, cost functions, and rule sets that constrain the scheduling of resources
within the region. A given service request or activity is assigned to a service region and then to an employee, based on
the employee's working hours and current schedule.
38
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Address S_ADDR_ORG (Siebel Cross-Industry Applications)
S_ADDR_PER (Siebel Industry Applications)
Employee S_EMP_PER, S_CONTACT, S_PARTY
Employee Exceptional Work Hours S_EMP_EXCPT_HRS
Scheduler Cost Function S_SCH_CSTFN
Scheduler Cost Function Variable S_SCH_CSTFN_VAR
Scheduler Parameter S_SCH_PARAM
Scheduler Parameter Set S_SCH_PARAM_SET
Scheduler Rule S_SCH_RULE
Scheduler Rule Node S_SCH_RULENODE
39
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Scheduler Rule Set S_SCH_RLST
Scheduler Time Map S_SCH_TMMAP
Scheduler Time Map Duration S_SCH_TMMAP_DUR
Service Activity S_EVT_ACT
Service Region S_SRV_REGN
Service Request S_SRV_REQ
Timezone S_TIMEZONE
Work Shift S_SCHED_CAL
Work Shift Exception S_EXCPT_CAL
Work Shift Exception Hour S_EXCPT_CAL_HRS
Work Shift Hour S_SCHED_CAL_HRS
Zipcode S_ZIPCODE
Forecasts
This ERD (see the following figure) illustrates the process of generating forecasts. A forecast series defines a set of
forecast periods in which forecasts must be submitted, and describes the appropriate number of periods to forecast
into the future for each forecast period. One or more positions are then assigned to submit forecasts under the defined
forecast series. When a forecast series is accessible to the public, it means the forecast series can be shared across
organizations. Each participant submits a forecast each period that is made up of forecast items. Each forecast item
can be attributed to different kinds of business transactions, and can be defined at any of a number of levels based on
business rules. These forecast items can be generated based on known revenue items. Forecasts that managers make
can contain items from the forecasts of their subordinates.
40
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Agreement S_DOC_AGREE
Forecast S_FCST
Forecast Item Detail S_FCST_ITEM_DTL
Forecast Period S_FCSTSER_DATE
Forecast Series S_FCSTSER
Forecasted Item S_FCST_ITEM
Marketing Event S_SRC
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Product Line S_PROD_LN
41
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Product or Service S_PROD_INT
Project S_PROJ
Quote S_DOC_QUOTE
Revenue Item S_REVN
Service Request S_SRV_REQ
High Tech Marketing Development Fund
This ERD (see the following figure) illustrates how Siebel Business Applications support the funding of trade promotions
in the high technology industry. Marketing Development Fund (MDF) is a pool of money made available to partners
for the organization of marketing activities (campaigns, events, and so on). An MDF can be a partner-specific fund or
general fund. MDFs (Programs) provide the brand owner with the ability to make marketing funds available to partners
in a programmatic way. Partner Specific funds are child funds of Programs. Within each Partner Specific fund, the
partner accrues funds under the given program. The partner creates a partner event activity (pre-approval) with several
associated event items. Event Items add granularity to the partner event activity. Partners create claims to redeem the
money in their partner-specific funds for marketing activities that were pre-approved by the brand owner.
The following table lists the entities in this ERD and their corresponding tables.
42
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Account, Partner, Other Account S_ORG_EXT
Claim Item S_SRC_PAYITM
Claim, Payment, Other Payment S_SRC_PAYMENT
Event Item S_SRC_COST
Fund Allocation S_MDF_ALLOC
General Fund S_MDF
Internal Product or Service S_PROD_INT
Market Segment S_MKT_SEG
Marketing Development Fund S_MDF
Marketing Event or Activity S_SRC
MDF Snapshot S_MDF_PERIOD
MDF Transaction S_MDF_TXN
Partner Event Activity S_SRC
Partner Program S_PRTNR_PROG
Partner Program Application S_PRTNRPRG_APPL
Partner Specific Fund S_MDF
Position S_POSTN
In-Memory Next Best Action
This ERD (see the following figure) illustrates how organizations can provide contextual recommendations to their
customers on all channels using Siebel In-Memory Next Best Action. Siebel In-Memory Next Best Action provides an
open, flexible, and configurable integration framework between Siebel Contact Center and Oracle Real-Time Decisions.
43
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
A closed-loop Response Action Framework provides feedback on the customer interaction in real time, and it tailors
product recommendations to the actions that the customer takes.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Request S_RTD_REQUEST
Request Parameter S_RTD_REQ_ATTR
Request Recommendation Response S_REQ_RECO_RESP
Message Response Action S_PROD_MSG_RESP, S_MSG_RESP_ACTN
Message Response Action Parameter S_RESPACTN_PARM
Invoiceable Charges
This ERD (see the following figure) illustrates how financial transactions, such as charges and credits, are handled.
Any charge or credit that could be invoiced is added to this table. This is based on defined consolidation plan rules to
consolidate charges and credits into invoice and invoice items.
44
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Agreement S_DOC_AGREE
Agreement Entitlement S_ENTLMNT
Agreement Line Item S_AGREE_ITEM
Asset S_ASSET
Auction Item S_AUC_ITEM
Expense Item S_EXP_ITEM
Financial Account S_ASSET
Invoiceable Charge S_INVOICE_CHRG
Invoice S_INVOICE
Invoice Item S_INVOICE_ITEM
45
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Invoice Item Reconciliation Entry S_INVC_ITM_DTL
Order S_ORDER
Order Line Item S_ORDER_ITEM
Part Movement S_ACTPART_MVMT, S_ORDPART_MVMT
Part Repair S_PART_RPR
Party S_PARTY, S_ORG_EXT, S_CONTACT, S_USER, S_BU
Payment S_SRC_PAYMENT
Payment Term S_PAYMENT_TERM
Product or Service S_PROD_INT
Project Item S_PROJITEM
Project Team Role S_PROJ_RSRC
Service Request S_SRV_REQ
Shipment S_SHIPMENT
Time Sheet Item S_TMSHT_ITEM
Invoices
This ERD (see the following figure) illustrates the invoicing and payment processes. An invoice can be considered a
receivable or a payable for the company. It can be generated to bill for an order, a project, a part repair, an agreement,
a service request, an activity, or a period of time for products or services delivered within a specific period of time.
Items on the invoice can be reconciled with one or more other entities as well. A payment can be made for one or more
Invoices, and an invoice can be paid through one or more payments.
46
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Agreement S_DOC_AGREE
Expense S_EXP_ITEM
Invoice S_INVOICE
Invoice Attachment S_INVOICE_ATT
Invoice Item S_INVOICE_ITEM
Order S_ORDER
Order Item S_ORDER_ITEM
Part Movement S_ORDPART_MVMT
47
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Part Repair S_PART_RPR
Payment S_SRC_PAYMENT
Period S_PERIOD
Product S_PROD_INT
Project S_PROJ
Service Request S_SRV_REQ
Shipment S_SHIPMENT
Lead Management
This ERD (see the following figure) illustrates how the lead management process is supported. A lead refers to a
new prospect or an existing customer who is interested in certain products or services and can be converted into
an Opportunity. A lead can be generated as a result of a marketing campaign, a marketing offer or other marketing
activities. A lead can be referred by a partner organization. A lead can be assigned to internal team members or
partners. Responses or various activities are tracked for each lead.
Steps in the lead management process include:
• Lead Entity. Views for sales users to create leads which are distinct from contacts/prospects, responses and
opportunities, and manage their leads.
• Lead Import. Import lists of customers, prospects, responses or leads from an outside party or another internal
source.
• Lead Quality Control. Rule-based user interface that enables the business user to create a formula or set of
rules that compute a score for a lead
• Lead Assignment. Lead-assignment rule system that can be fully administered by a sales operations user or
sales manager. Leads can also be assigned to partner organizations or partner users.
• Lead Conversion. End-user actions to convert a lead into an opportunity, quote or order in one step, reject the
lead or retire the lead.
48
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Lead S_LEAD
Lead Note S_NOTE_LEAD
Opportunity S_OPTY
Product S_PROD_INT
Marketing Import Task S_MKT_IMPRT_TSK
Lead Source S_SRC
Campaign Contact S_CAMP_CON
Marketing Offer S_DMND_CRTN_PRG
Response S_COMMUNICATION
Activity S_EVT_ACT
Prospect Contact S_PRSP_CONTACT
Contact S_CONTACT
49
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Business Unit S_BU
Position S_POSTN
Account S_ORG_EXT
Internal Organization S_ORG_EXT
Partner Organization S_ORG_EXT
Assigned External Organization S_ORG_EXT
Marketing Budget Request
This ERD (see the following figure) covers the Marketing Resource Management: budget request process. It illustrates
the relationships between budget requests and marketing tactics, marketing funds, and purchase orders. A budget
request can be managed by a team and defined against a dedicated marketing fund for a period and a region. It can be
associated with one or more industries, products, and product lines.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table(s)
Budget Request S_MKTG_BDGT_REQ
50
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table(s)
Purchase Request S_ORDER
Marketing Development Fund S_MDF
Marketing Plan S_SRC
Marketing Fund S_MDF
Marketing Tactics S_SRC
Tactics Expense S_SRC_COST
Purchase Request Line Item S_ORDER_ITEM
Marketing Campaign
This ERD (see the following figure) illustrates campaign management, execution, and evolution. Campaign
management can involve the focus of the campaign on a territory, as well as the responsibility of the various internal
divisions and teams for successful execution. Execution can include the production and distribution of literature to the
appropriate campaign contacts. Campaign evolution tracks the usage of call lists to identify campaign contacts and
generate leads. Campaign contacts can include prospective contacts purchased on a call list. If a prospective contact is
not promoted to a customer before the call list that names them expires, they are typically deleted from the database.
The following table lists the entities in this ERD and their corresponding tables.
51
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Activity S_EVT_ACT
Call List S_CALL_LST
Call List Member S_CALL_LST_CON
Campaign Call List S_CAMP_CALL_LST
Campaign Contact S_CAMP_CON
Fulfillment Recipient S_FUL_RECIP
Fulfillment Request S_EVT_FUL_REQ
Fulfillment Request Item S_FUL_REQ_ITEM
Literature Item S_LIT
Marketing Event S_SRC
Opportunity S_OPTY
Opportunity Contact S_OPTY_CON
Order S_ORDER
Organization Unit S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Prospective Contact S_PRSP_CONTACT
Response S_COMMUNICATION
Territory S_ASGN_GRP
52
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Marketing Collaboration
Collaborative marketing (see the following figure) assists marketers in maintaining the balance between the need for
consistent customer management among partners and effective brand building with local expertise. It includes two
features. Marketing program collaboration allows companies to develop marketing programs in a more collaborative
environment, resulting in reduced costs. It encourages collaboration on programs through the sharing of information
with key action groups (internal and external). Partner marketing enhancements provides the ability to associate and
track partner participation in marketing programs and campaigns to measure and report on opportunities, orders, and
ROI. It also closes the loop by providing the ability to track partner sources for responses/opportunities orders.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Internal Partner/Organization S_ORG_EXT, S_PARTY
Marketing Event or Activity S_SRC
Opportunity S_OPTY
Order S_ORDER
Organization Unit, Other Organization Unit S_ORG_EXT, S_PARTY
Partner Organization S_BU, S_PARTY
53
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Party, Other Party S_PARTY
Quote S_DOC_QUOTE
Response S_COMMUNICATION
Marketing Encyclopedia
This ERD (see the following figure) illustrates how Siebel Business Applications track competitive information about
products and companies. A standard set of metrics can be defined against which competitive organizations and
their products can be rated in comparison with the internal organization and products, respectively. Detailed product
specifications can be recorded. In addition, competitive literature can be associated both with organizations and with
products. The relevance of key decision issues to the various competitive metrics can be defined.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Company Literature S_CO_LIT
Competitive Company Feature S_CMPT_CO_FEA
Competitive Metric S_CMPT_MTRC
54
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Competitive Product Feature S_CMPT_PROD_FEA
Issue S_ISS
Literature Item S_LIT
Organization Unit S_ORG_EXT, S_PARTY
Product Comparison S_PROD_CMP
Product Detail S_PROD_SPEC
Product External S_PROD_EXT
Product Internal S_PROD_INT
Product Literature S_PROD_LIT
Marketing Event Driven Dialogue
The Event Driven Dialogue feature helps enable timely sales and services designed around specific customer needs.
Specific events are tracked for different customers and these events are used to trigger appropriate program stages
for the marketing program. This ERD (see the following figure) illustrates the various relationships between Marketing
Program, Stage, and Event Triggers. The wait period between stages is also tracked.
55
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Action List S_MKTPRGACT_LST
Call List S_CALL_LST
Campaign Contact S_CAMP_CON
Event Trigger S_MKT_EVT_TRG
Event Trigger History S_MKTEVTRG_HST
Event Trigger Mapping S_MKTEVTRG_MAP
Lead Source S_SRC
Marketing Campaign S_SRC
Marketing Event or Activity S_SRC
Marketing Program S_SRC
Marketing Program Action S_SRC
Marketing Stage S_SRC
Marketing Stage Wait S_MKT_STGWAIT, S_MKT_STGWT_REL
Offer S_DMND_CRTN_PRG
Party S_PARTY
Person S_CONTACT
Position S_POSTN
Response S_COMMUNICATION
56
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Marketing Events
This ERD (see the following figure ) illustrates how Siebel Business Applications support marketing events and activities
planning. A marketing event can be composed of one or more sessions, held at one or more venues such as a hotel or
convention center. The room for each session of an event can be chosen based on the size and equipment requirements
of the session matched to the size and available equipment of each room. Users can also create travel plans for
customers attending the events. Event vendors and sponsors can be tracked as well as the various offers or services
they provide. The event staff can be planned and attendees invited. Attendees can then register for the event or even
for specific sessions. Attendees can be quoted registration prices through a quote and purchase tickets to the event
through an order.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Contract Line Item S_ORDER_ITEM, S_QUOTE_ITEM
Equipment Requirement S_SRC_REQ_EQUIP
Event S_SRC_EVT, S_SRC
Event Cost S_SRC_COST
Event Location S_EVTLOC
57
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Event Registration S_SRC_EVT_REG
Event Session S_SRC_EVT, S_SRC
Event Vendor S_SRC_ORG
Event Venue S_SRC_VENUE
Literature Item S_LIT
Location Room S_EVTLOC_ROOM
Marketing Event or Activity S_SRC
Order S_ORDER
Organization Unit S_ORG_EXT, S_PARTY
Parent Event S_SRC_EVT, S_SRC
Position S_POSTN, S_PARTY
Price List S_PRI_LST
Product or Service S_PROD_INT
Quote S_DOC_QUOTE
Room Avail Equipment S_EVTLOC_RM_EQP
Travel Participant S_EVT_TRVL_PER
Travel Plan S_EVT_TRVL_PLAN
Vendor Offer S_EVT_VNDR_OFR
Vendor Review S_EVT_VNDR_RVW
Vendor Service S_EVT_VNDR_SVC
Venue S_ORG_EXT, S_PARTY
58
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Venue Offer S_EVT_VENUE_OFR
Venue Review S_EVT_VENUE_RVW
Venue Service S_EVT_VENUE_SVC
Marketing Plans
This ERD (see the following figure) illustrates how marketing plans are used in conjunction with the financial modeler
for the purposes of financial planning. Marketing plans are multilevel groupings of plan elements (campaigns) or sub-
plans. Financial goals and costs can be forecasted for each level of the plan, tracked against actual achievement after
campaign execution, and rolled up to the top-level plan. Funds can also be allocated for different plans in different
periods and used as inputs for accounting purposes or in financial calculations.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Call List S_CALL_LST
Marketing Development Fund S_MDF
Marketing Event Cost S_SRC_COST
59
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Marketing Event or Activity, Marketing S_SRC
Plan, Other Marketing Plan or Activity
Marketing Goal S_SRC_GOAL
Period S_PERIOD
Planned Marketing Development Fund S_MDF_ALLOC
Allocation
Product or Service, Product Line, Other S_PROD_INT, S_PROD_LN
Product or Service
Product Promotion S_PROD_INT_SRC
Marketing Program
This ERD (see the following figure) illustrates how Siebel Business Applications support the more complex program
planning and execution used for Database Marketing. Marketing segments are dynamic lists of people defined by a set
of database criteria and available to marketing programs. These criteria can be defined on measures and attributes by
using complex mathematical scores, ratios, and formulas applied to customer demographics or behavior data sourced
from the Siebel database or from external applications such as a data warehouse.
After a data dictionary describing the external data store has been defined, segment definitions can be created and
attached to one or more campaigns, together with purchased lists. Filters allow the exclusion of segment members
based on predefined clauses. Segment prioritization and deduplication make sure that individuals qualified for more
than one segment do not receive conflicting messages from more than one campaign. Waves can be generated as a
subset of the qualifying people within the targeted segments.
Recurring marketing programs can be defined in which each stage can be based on customer response behavior or any
other event. Marketers can define customer hierarchies, so that campaigns can be driven by data summarized from any
level of the hierarchy (for example household level and customer level). People to be contacted are listed as campaign
contacts for a specific campaign or wave.
Each campaign can be presented with one or more offers. An offer is a type of demand creation program that is directly
presented to a target audience. It is intended to generate awareness of or demand for one or more products. Responses
are tracked through Communications.
60
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Assignment Rule Group S_ASGN_RULE_GRP
Call List S_CALL_LST
Campaign Allocation S_CAMP_CALL_LST
Campaign Contact S_CAMP_CON
Campaign Load S_CAMP_LD_WAVE
Campaign Offer S_SRC_OFFR
Campaign Wave S_DD_CAMP_WAVE
Contact S_CONTACT, S_PARTY
Contact Status S_ SRCDCP_CONSTA
Deal S_DEAL
Filter S_DD_FILTER
Filter Clause S_DD_FILTER_DTL
61
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Load Wave S_CAMP_LD_WAVE
Marketing Activity S_SRC
Marketing Segment S_CALL_LST
Offer S_MKTG_OFFR
Offer Media Package S_DMND_CRTN_PKG
Program Segment S_CAMP_CALL_LST
Prospective Contact S_PRSP_CONTACT
Purchased List S_CALL_LST
Response S_COMMUNICATION
Marketing Resource Management: Document
This ERD (see the following figure) illustrates the marketing content processing of the enhanced Marketing Resource
Management module. It shows the relationship between the content and various entities such as project, offer media
package, and lead source. It also illustrates the process of managing content inventory by region and location, and
shows how fulfillment requests are completed through vendor bidding.
62
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Marketing Material S_CB_ASSET
Material Inventory by Location S_MKTG_DOC_INVT
Event Location S_EVTLOC
Region S_REGION
Material Fulfillment Request S_EVT_FUL_REQ
Material Fulfillment Item S_FUL_REQ_ITEM
Mat Fulfill Request Attachment S_NOTE_FUL_REQ
Vendor Bidding S_FUL_REQ_BID
Vendor Bidding Item S_FR_BID_LITM
External Organization S_ORG_EXT
Offer Media Package S_DMND_CRTN_PRG
Offer Document S_OFFR_CBAST
63
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Lead Source S_SRC
Lead Source Document S_SRC_CBAST
Project S_PROJ
Project Document S_PROJ_CBAST
Opportunity Management
This ERD (see the following figure) illustrates the significant entities related to an opportunity (or lead), including
relationships to contacts, employees (generally sales representatives), products, accounts, and so on.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Agreement S_DOC_AGREE
Contact S_CONTACT, S_PARTY
Employee S_EMP_PER, S_CONTACT, S_PARTY
64
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Event S_EVT_ACT
External Organization Unit S_ORG_EXT, S_PARTY
Issue S_ISS
Opportunity S_OPTY
Opportunity Relationship S_OPTY_REL
Opportunity Signature S_OPTY_SIGN
Organization Unit S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Product S_PROD_INT
Quote S_DOC_QUOTE
Sales Stage S_STG
Source S_SRC
Territory S_ASGN_GRP
Order and Promotion
This ERD (see the following figure) describes the relationship between Product Promotions and Order, Quote and
Assets.
65
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Order Item S_ORDER_ITEM
Product Promotion S_PROD_INT
Product Promotion Item S_PROM_ITEM
Product Promotion Operation S_PROM_OPER
Quote Item S_QUOTE_ITEM
Order Life Cycle
This ERD (see the following figure) illustrates how orders are tracked through their full life cycle by Siebel Business
Applications. The cycle starts with an opportunity that tracks the consideration of purchase of one or more products.
This opportunity leads to one or more quotes, composed of one or more quoted product items. A quote can then lead
to one or more orders. An order is composed of one or more ordered product items. Fulfillment of the order can be
tracked through a set of part movements of various types, culminating in a shipment of products to the customer, and
the invoicing for shipped goods.
66
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Invoice S_INVOICE
Invoice Item S_INVOICE_ITEM
Opportunity S_OPTY
Opportunity Product S_REVN
Order S_ORDER
Order Item S_ORDER_ITEM
Order Part Movement S_ORDPART_MVMT
Product or Service S_PROD_INT
67
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Shipment S_SHIPMENT
Orders
This ERD (see the following figure) illustrates the relationships between orders and significant entities related to orders
such as assets, products, inventory locations, part movements, inventory transactions, activities, and parties. Orders
include sales orders, service orders, purchase orders, and return material authorizations (RMAs) among others. The
fulfillment of an order results in one or more part movements according to the instructions of the order. Each part
movement results in one or more inventory transactions. Each order is usually the responsibility of a single internal or
partner organization, but sometimes two or more. An order can be assigned or credited to one or more positions.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Asset S_ASSET
Inventory Location S_INVLOC
68
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Inventory Transaction S_INV_TXN
Inventory Transaction Type S_INV_TXN_TYPE
Order S_ORDER
Order Item S_ORDER_ITEM
Order Type S_ORDER_TYPE
Part Movement S_ACTPART_MVMT, S_ORDPART_MVMT
Part Movement Type S_PARTMVMT_TYPE
Party S_PARTY, S_ORG_EXT, S_POSTN, S_CONTACT
Product S_PROD_INT
Partner Collaboration
Partner collaboration (see the following figure) allows the brand owner's partner companies to give other partners
visibility to their data. With this functionality, partners can more easily collaborate with other partners, without any
required intervention from the brand owner company. Partner companies can start collaborations and invite other
partners of the brand owner to join their collaborations. Once the invitation is accepted, individual partner companies
who are now part of the collaboration can pledge resources (Positions) to the collaboration, making the resources
available to all partners in the collaboration who might want to add the resource to a project or an opportunity.
69
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Business Unit S_BU
Collaboration S_PARTY_GROUP
Collaboration Resource S_PARTY_PER
Collaboration Invitation S_BRDCST_MSG
Party S_PARTY
Position S_POSTN
Partner Program Registration
Partner Program RegistrationPartner Program Registration (see the following figure) provides a system for the process
of configuration and deployment of registration of partner programs. Partner Program Registration consists of three
smaller and more manageable processes: a user registration process, a company registration process, and a partner
program registration process.
70
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Application Approval Team S_PRG_APPL_PSTN
Application Attachment S_PRG_APPL_ATT
Application Question Answer S_PRG_APPL_QA
Approval List S_PRTNRPRG_PRTN
Eligibility List S_PRTNRPRG_PRTN
Partner S_ORG_EXT
Partner Program S_PRTNR_PROG
Partner Program Application S_PRTNRPRG_APPL
Partner Program Group S_PRTNRPRG_GRP
Partner Program Membership S_PRTNRPRG_MBR
Program Team S_PRTNRPRG_PSTN
Renew List S_PRTNRPRG_PRTN
71
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Party Model
This ERD (see the following figure) illustrates the structure of the party entity, its significant subtypes, and relationships.
A party is either a person or some grouping of people such as an organization, a household, a position or a list of
users. A person can be an employee or agent of the company using Siebel Business Applications. A person can also be
considered a user if he or she has been granted user login credentials. An access group is a type of party that is made
up of one or more groups. Addresses can be tracked for a person, a household, or an organization.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Access Group S_PARTY
Account S_ORG_EXT, S_PARTY
Business Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Group S_PARTY
72
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Household S_ORG_GROUP, S_PARTY
Organization Relationship S_ORG_REL (Siebel Cross-Industry Applications) S_PARTY_REL (Siebel Industry Applications)
Organization Unit S_ORG_EXT, S_PARTY
Party S_PARTY
Party Relationship S_PARTY_REL
Person S_CONTACT, S_PARTY
Person Relationship S_PARTY_REL or S_CONTACT_REL
Personal Address S_ADDR_PER
Position S_POSTN, S_PARTY
User List S_PARTY
User Login S_USER
Payments
This ERD (see the following figure) illustrates the support for payments provided in the Siebel Data Model. The payment
entity supports payments made by customers to the company, as well as payments made by the company to customers,
vendors, or others. A payment can be made to directly settle an order or to settle one or more Invoices. An invoice can
be paid through one or more payments. A payment can be taken as a deduction from a prepayment balance available to
the paying party.
73
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Invoice S_INVOICE
Order S_ORDER
Organization Unit S_ORG_EXT, S_PARTY
Party S_PARTY
Payment S_SRC_PAYMENT
Person S_CONTACT, S_PARTY
Prepayment Balance S_PREPAY_BAL
74
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Performance Review
This ERD (see the following figure) illustrates how the Siebel Data Model supports employee performance reviews.
Review templates of various types (such as annual review, periodic review, customer satisfaction, MBO, KSO, and service
level) can be specified to contain one or more Components (such as shared objectives, training plan, rollup, 360-degree
evaluation, individual objectives, and skills). Components can consist of standard review metrics. The performance
review can then be created for a given employee and employee-specific objectives can be defined. At the end of the
review period, the performance review can be completed and ratings given for assigned objectives and for the standard
review metrics. Different rating scales can be defined and used for different types of reviews. Review templates can be
specified for different job families and internal organizations. Optionally, an employee can be separately reviewed for
performance in each of his or her assigned positions.
This diagram also illustrates how the Siebel Data Model supports employee performance review by other employees
within an organization. These employees can be employees at the same level, a higher level, or a lower level who
can provide performance reviews for an employee to the manager of that employee. A set of evaluation questions
can be defined and associated with different sets of employees. The reviewers answer the questions to evaluate the
performance of the employee.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
360 Evaluation S_PERF_360_EVAL
75
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Competency S_CMPTNCY
Employee Criteria (PDQ) S_APP_VER, S_RVW_360_CS
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Evaluation Script S_CS_PATH, S_CS_PATH_SCPT
Evaluation Script Answer S_CS_RUN, S_CS_RUN_ANSWR
Job Family S_JOB_FAMILY
Organization Unit S_ORG_EXT, S_PARTY
Party S_PARTY
Performance Measurement Item S_PERF_MEAS_ITM
Performance Review S_EMP_PERF_MEAS
Period S_PERIOD
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Review Component S_PERF_RVW_CMP
Review Component Language S_RVW_COMP_LANG
Review For Skill Item S_PERF_CMPTNCY
Review Metric S_PERF_RVW_MTRC
Review Rating S_PERF_RATING
Review Rating Scale S_PERF_RATING_SCL
Review Template S_PERF_RVW_TMPL
Review Template Component S_PERF_RVW_COMP
76
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Personal Account
This ERD (see the following table) illustrates how personal accounts (such as financial accounts or insurance policies)
are accessible by contacts and associated with accounts, and how addresses are relevant for each of these. Also
supported are associations between contacts and the membership of contacts in groups. Opportunities are associated
with personal accounts to track the source of existing business.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Activity S_EVT_ACT
Contact S_CONTACT, S_PARTY
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
77
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Personal Account S_ASSET
Personal Account Contact S_ASSET_CON
Personal Address S_ADDR_PER
Product S_PROD_INT
Service Request S_SRV_REQ
Personal Financial Review
This ERD (see the following figure) illustrates the information captured during the process of reviewing the financial
status of an individual customer. The financial review process itself is tracked as an activity and becomes the source of
the rest of the personal financial information of the contact, including assets, liabilities, income, expenses, and financial
needs (such as retirement savings). When the financial needs of the contact are not fully addressed by his or her current
financial product holdings, assets, or liabilities, the salesperson makes one or more financial recommendations. When a
financial recommendation leads to a purchased product, such as a savings account or mortgage, the product instance
can be associated with the recommendation that led to it. Assets can be located at a personal address and can be a
source of income. Similarly, a liability, such as a mortgage, can be secured by an associated asset and can have periodic
expenses associated with the liability.
The following table lists the entities in this ERD and their corresponding tables.
78
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Activity S_EVT_ACT
Activity Product Instance S_ACT_ASSET
Asset (Liability) S_FN_ASSET_LIAB
Asset (Liability) Contact S_FN_ASSET_LIAB_CON
Contact S_CONTACT, S_PARTY
Contact Relationship S_CONTACT_REL
Financial Need S_FN_NEED
Financial Recommendation S_FN_RCMD
Household/Account S_ORG_GROUP, S_PARTY
Income (Expense) S_FN_INCM_EXP
Income (Expense) Contact S_FN_INCM_EXP_CON
Need Contact S_FN_NEED_CON
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
Product S_PROD_INT
Product Instance S_ASSET
Product Instance Contact S_ASSET_CON
Received Product Instance S_FN_RCMD_ASSET
Recommendation Contact S_FN_RCMD_CON
79
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Pricing
This ERD (see the following figure) illustrates the pricing capabilities of Siebel Business Applications, including price
lists, pricing matrices, and pricing models, and how they are related to simple and complex products or services to be
priced. A price list is made up of price list items, each of which tracks the price for a given product or service. The list
prices can be adjusted for certain extended attributes as defined in a specified pricing matrix. They can be adjusted
based on changes to a customizable product through component price adjustments. They can also be modified through
a specified pricing model made up of pricing factors.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Component Price Adjustment S_PRI_CFG_ITEM
Object Class S_VOD, S_VOD_VER
Object Class Extended Attribute S_XA_ATTR
Price List S_PRI_LST
Price List Item S_PRI_LST_ITEM
Pricing Factor Item S_PRIFCTR_ITM
Pricing Factor Item Attrib S_PRIFCTITM_ATR
Pricing Matrix S_PRI_MTRX
80
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Pricing Matrix Attribute S_PRI_ATTR
Pricing Matrix Item S_PRI_MTRX_ITEM
Pricing Matrix Value S_PRI_MTRX_VAL
Pricing Model S_PRIMDL
Pricing Model Factor S_PRIMDL_FCTR
Product Extended Attribute S_PROD_INT_XA
Product or Service S_PROD_INT
Product or Service Structure S_PROD_ITEM
Pricing Comparison
This ERD (see the following figure) illustrates the pricing comparison feature. A competitor's customer is viewed as an
opportunity and by creating a quote using that competitor's price list the size of the opportunity can be quantified.
Comparison quotes are generated using products and services from the internal price list that are similar to the
competitor's offerings, to calculate the savings the customer could achieve by switching from the competitor.
Products and services provided by companies have complex pricing structures including tier-based pricing. Pricing also
varies by region, payment method, service type, credit risk, and so on. The tier prices are associated with the attributes
of the product or service that is provided.
81
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Object Class S_VOD, S_VOD_VER
Object Class Extended Attribute S_XA_ATTR
Opportunity S_OPPTY
Price List S_PRI_LST
Price List Item S_PRI_LST_ITEM
Pricing Matrix S_PRI_MTRX
Pricing Matrix Item S_PRI_MTRX_ITEM
Product Extended Attribute S_PROD_INT_XA
Product or Service S_PROD_INT
Product or Service Structure S_PROD_ITEM
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Quote Item Extended Attribute S_QUOTE_ITEM_XA
82
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Tier Price Value S_VDISCNT_ITEM
Tier Pricing S_VOL_DISCNT
Product Promotion
Product Promotion (see the following figure) provides a system for managing product promotions. Production
Promotion allows the user to fully define the promotion based on products, product templates, product attributes,
and so on. Product Promotion also allows the user to specify other information for the promotion including the terms,
charges, and pricing rules.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Conditional Charge Prorata Plan S_AGR_PR_PLAN
Product Promotion S_PROD_INT
Product Promotion Charge S_PROM_CHRG
Product Promotion Item S_PROM_ITEM
83
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Product Promotion Item Attribute S_PROM_ITEM_XA
Product Promotion Item Attribute Value S_PROMITM_VAL
Product Promotion Operation S_PROM_OPER
Product Promotion Operation Component S_PROM_OPER_CPT
Product Promotion Pricing Matrix Rule S_PROM_PMTRX
Product Promotion Term S_PROMITM_TRMS
Product Promotion Term Description S_PROD_TRM_DESC
Product Quality Tracking
This ERD (see the following figure) illustrates the significant entities related to product defect tracking. Defects can be
associated with service requests and can include associated activities defined to fix the defect. Associations can be
defined with various product or product versions to record which are affected by the defect, which are planned to fix
the defect, and which actually fix the defect. Additional relevant associations with external products can be recorded.
Defects can be associated with other, related defects.
84
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Defect Symptom S_PRDFCT_SYMP
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Organization Unit S_ORG_EXT, S_PARTY
Product or Service S_PROD_INT, S_PROD_EXT
Product Quality Item S_PROD_DEFECT
Project S_PROJ
Project Item S_PROJITEM
Resolution Item S_RESITEM
85
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Service Request S_SRV_REQ
Product Recommendation and Offer
This ERD (see the following figure) provides a method for managing product recommendations for up-sell or cross-
sell. Product Recommendation allows the user to clearly define the messages, the set of possible responses, and the
recommendation itself. Similarly, Product Offer allows the user to clearly define the messages, the set of possible
responses, the set of actions for the offer responses, the set of parameters for the offer response, and the offer itself
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Communication S_COMMUNICATION
Product Line S_PROD_LN, S_PROD_LN_PROD
Product Message S_PROD_MSG
Product Message Response S_PROD_MSG_RESP
Product Message Variable S_PROD_MSG_VAR
Product Offer S_PROD_INT
86
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Product Offer Response S_PROD_OFR_RESP
Product Offer Response Action S_PROD_OFR_ACTN
Product Offer Response Action Parameter S_PROD_OFR_PARM
Product or Service S_PROD_INT
Product Recommendation S_PROD_RECMNDTN
Products or Services
This ERD (see the following figure) illustrates the significant entities related to a product including product components
(product structure), substitute or competitive products (product comparison), the product's vendor, the product line or
lines to which the product belongs, and so on. In addition, this diagram illustrates the relationship between products
and product prices, as well as the language translations for some of these entities.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Catalog S_CTLG
Catalog Category S_CTLG_CAT
87
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Class Attribute S_XA_ATTR
Class of Product or Service S_VOD, S_VOD_VER
Language S_LANG
Price List S_PRI_LST
Price List Item S_PRI_LST_ITEM
Product Assembly Port S_PROD_ITEM
Product Line S_PROD_LN
Product or Service S_PROD_INT or S_PROD_EXT
Product or Service Attribute S_PROD_INT_XA
Product Structure S_PROD_ITEM, S_PROD_REL
Product User Defined Attribute S_PROD_USRDEFATR
Vendor S_ORG_EXT, S_PARTY
Professional Services
This ERD (see the following figure) illustrates how Siebel Business Applications support the planning and execution
of Professional Services projects. Projects can be defined for an external or internal client, as the responsibility of one
or more internal organizations, subcontracted to one or more partners, associated with a required skill set, and made
accessible to one or more positions. The definition of required project team roles allows project billings to be estimated
based on the billing rate and the number of hours required from the resource. An employee, a sub-contractor employee
or a contact can ultimately fill a team role from the client, but until then, a list of potential project resources can be
stored for the project or a specific project team role. Positions and project team roles can be associated with a service
billing product to define the billing rate for that entity from a billing rate list. Project issues can be tracked for a project,
assigned to a project team role, and detailed as a series of activities. Receivable Invoices billed to the client or payable
invoices from subcontractors can be associated with the project.
88
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Address S_ADDR_ORG (Siebel Cross-Industry Applications) S_ADDR_PER (Siebel Industry Applications)
Billing Rate List S_PRI_LST
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Internal/Partner Organization S_ORG_EXT, S_PARTY
Invoice S_INVOICE
Lead Source S_SRC
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Potential Project Resource S_PROJ_PTL_RSRC
89
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Project S_PROJ
Project Contact S_PROJ_CON
Project Issue S_PROJ_ISS
Project Team Role S_PROJ_RSRC
Skill S_PROJRSRC_SKL
Promotion Group
Promotion Groups (see the following figure) offer advanced product and service bundling and new community offerings
that tie various customer assets in a loosely-coupled network and they provide shared benefits and provisioning
functions.
Promotion Group Validation provides the ability to define and enforce validation rules for Promotion Groups, such as
eligibility and compatibility rules or rules validating the consistency in a Promotion Group.
Promotion Group pricing provides the ability to define and enforce all pricing-related aspects of a Promotion Group,
such as assigning charges to Promotion Group memberships or adjusting prices for Promotion Group components.
Promotion Group Access Control provides the ability to define and enforce business rules governing who can manage
the membership of a given Promotion Group.
Promotion Group Notification provides the ability to define the different types of notifications to be sent to Promotion
Group owners and members in response to business events like new or canceled membership.
90
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Adjustment Group S_ADJ_GROUP
Asset S_ASSET
Communication Template S_DMND_CRTN_PRG
Conditional Charge Prorata Plan S_AGR_PR_PLAN
Order Item S_ORDER_ITEM
Product Compatibility Matrix S_PRODCOMP_MTRX
Product Membership Compatibility S_PRODCOMP_MEM
Promotion Configuration Item S_PRO_CFG_ITEM
Promotion Group S_PROD_INT
Promotion Group Access S_PROMGRP_ACESS
Promotion Group Charge S_PROM_CHRG
Promotion Group Item S_PROM_ITEM
Promotion Group Member S_PROD_INT
Promotion Group Notification S_PROM_GRP_NTFY
Promotion Group Pricing Matrix Rule S_PROM_PMTRX
Promotion Group Term Description S_PROD_TRM_DESC
Quote Item S_QUOTE_ITEM
91
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Revenue
This ERD (see the following figure) illustrates how revenue items are tracked and analyzed in Siebel Business
Applications. Revenue Items can be defined for any number of confirmed or likely business transactions such as
opportunities, accounts, projects, marketing events or activities, agreements, invoices, and so on. Revenue is generally
attributed to a product, service, product line, or some description of the product or service offering. Credit for the
revenue can be spread across sales team members by breaking the revenue into a line for each sales team member with
their credit amounts. Recurring or incoming revenues over a period of time (weeks, months, or years) can be shown by
using the revenue schedule capabilities. A revenue template with detailed items can be created for this purpose.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Agreement S_DOC_AGREE
Agreement Item S_AGREE_ITEM
Invoice S_INVOICE
Invoice Item S_INVC_ITEM
Marketing Event S_SRC
Opportunity S_OPTY
Organization Unit S_ORG_EXT, S_PARTY
92
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Person S_CONTACT, S_PARTY
Position S_POSTN, S_PARTY
Product Line S_PROD_LN
Product or Service S_PROD_INT
Project S_PROJ
Revenue Item S_REVN
Revenue Template S_REVN_TMPL
Revenue Template Item S_REVN_TMPL_ITM
Service Request S_SRV_REQ
Sales Hierarchy and Credit Assignment
The Sales Hierarchy Module allows organizations to build sales hierarchies on top of sales territories and to assign sales
credits to territories and positions accordingly. A sales hierarchy (see the following figure) consists of sales territories,
which are made up of positions and crediting rules. The sales hierarchy can be versioned to accommodate ongoing
changes without losing track of its history. A position can be assigned to different territories or the same territory with
different start date and end date. A crediting rule can be applied to positions with allocation percentage defined. For a
given hierarchy version, the credit assignment engine is able to identify all the positions assigned to the territories and
all the applicable crediting rules by effective start date and end date. The crediting rules, their criteria and values are
read by Siebel Assignment Manager, which performs the assignments appropriately. The sales hierarchy needs to be
approved and validated before taking effect.
93
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Credit Allocation S_SLSCR_RL_PSTN
Credit Assignment Rule S_SLSCRDT_RULE
Credit Rule Criteria S_SLSCRDT_CRIT
Credit Rule Criteria Value S_SLSCRDT_VAL
Hierarchy Version S_SLS_HIER_VER
Hierarchy Version Territory S_SLS_HIER_TERR
Position S_POSTN, S_PARTY
Position Territory Assignment S_SLSTERR_POSTN
Sales Hierarchy S_SLS_HIER
Sales Territory S_SLS_TERR
94
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Sales Portfolio Management
This ERD (see the following figure) illustrates the process of creating and managing sales portfolios for employees in
sales positions within the sales organization. It shows the process for creating a sale portfolio, setting target accounts
for a given portfolio, and defining the business or service units for each associated account as well as their business
drivers and initiatives. Also illustrated are partners and partner's competitors associated with the portfolio accounts. In
addition, this ERD covers the marketing campaigns which are targeted at the accounts in the portfolios.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Sales Portfolio S_SLS_PORTFOLIO
Portfolio Category S_PRTFL_CTGRY
Portfolio Account S_PRTFL_ACCNT
Product Offering S_ENT_SOLN
Portfolio Partner S_PRTFL_PRTNR
Portfolio Attachment S_PRTFL_ATT
Portfolio Product Offering S_PRTFL_ENTSOLN
Account Prod Offering S_PRTFL_ACCSOLN
95
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Portfolio Sub_Account S_PRTFL_SUBACC
Portfolio Account Attachment S_PRTFL_ACC_ATT
Portfolio Business Driver S_PRTFL_BU_DRVR
Portfolio Business Initiative S_PRTFL_BU_INTV
Campaign S_SRC
Portfolio Account Campaign S_PRTFL_CAMP
Portfolio Partner Competitor S_PRTFL_CMPTR
Organization Unit S_ORG_EXT
Service Agreement
This ERD (see the following figure) illustrates how Siebel Business Applications support service agreements. A service
agreement is a contract that entitles one or more contacts at one or more organizations to provide service or support
on one or more items through entitlements. Entitlement items define coverage of products or specified instances of a
product. The entitlement can be constrained by a service calendar (to indicate 24x7 coverage, for example), and can be
subject to one or more metrics (that describe a guaranteed two-hour response, for example). For covered items, covered
labor and covered faults can be defined.
96
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Agreement S_DOC_AGREE
Agreement Entitlement S_ENTLMNT
Agreement Line Item S_AGREE_ITEM
Asset S_ASSET
Contact S_CONTACT, S_PARTY
Entitled Product or Asset S_ENTLMNT_ITEM
Entitled Service S_ENTL_ACT_TYPE
Expense Type S_EXP_ITEM_TYPE
Fault/Trouble Code S_FAULT_CODE, S_AGRITM_FLTCD
Labor Operation Code S_LAB_OPER_CODE, S_AGRITM_LABOPR
Material S_PROD_INT
Order S_ORDER
Preventive Maintenance S_PM_PLNITM
Price Adjustment S_ENTL_PRDPRI
Product S_PROD_INT
Service Calendar S_SCHED_CAL
Service Metric S_SVC_METRIC
Service Request S_SRV_REQ
Work Type S_PROJ
97
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Service Calendars and Work Shifts
This ERD (see the following figure) illustrates the structure of service calendars and work shifts. Both are made up of
a set of working hours for each day of the week with a single exception calendar defining planned holidays and other
exceptional working days. An employee can be assigned to a work shift to define his or her normal working hours with
exceptional working or non-working hours expressed as employee exception hours.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Employee S_CONTACT, S_EMP_PER, S_PARTY
Employee Exception Hours S_EXCPT_CAL_HRS
Exception Calendar S_EXCPT_CAL
Exception Calendar Hours S_EXCPT_CAL_HRS
98
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Person S_CONTACT, S_PARTY
Schedule Calendar S_SCHED_CAL
Schedule Calendar Hours S_SCHED_CAL_HRS
Service Calendar S_SCHED_CAL
Work Shift S_SCHED_CAL
Service Request
This ERD (see the following figure) illustrates how service requests are handled as a series of activities, each owned by a
specific employee. Relevant information includes the contact who reported the service request, the product with which
assistance is requested along with the customer's environment or profile, and specifically which third-party products
are in use and relevant to the service request.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Asset (Product Instance) S_ASSET
99
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
External Product Instance S_ORG_PRDEXT
Party S_PARTY, S_ORG_EXT, S_CONTACT, S_USER
Product or Service S_PROD_INT, S_PROD_EXT
Service Region S_SRV_REGN
Shipment
This ERD (see the following figure) illustrates the relationship between orders, quote, products, inventory locations,
and shipment related to orders. Delivery requests and delivery promises (date of delivery, delivery quantity) can be
associated with order items and quote items.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Inventory Location S_INVLOC
100
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Order S_ORDER, S_ORDER_SHIP
Order Item Delivery Request S_ORDPART_REQ
Order Line Item S_ORDER_ITEM
Order Part Movement S_ORDPART_MVMT, S_SHIPMENT_MVMT
Part Movement Type S_PARTMVMT_TYPE
Product Internal S_PROD_INT
Quote S_DOC_QUOTE, S_DOC_ORDER
Quote Item Delivery Promise S_QTE_ITM_DLVRQ
Quote Item Delivery Request S_QTE_ITM_DLVRQ
Quote Line Item S_QUOTE_ITEM
Shipment S_SHIPMENT
Siebel Assistant
This ERD (see the following figure) illustrates how Siebel Business Applications support the Siebel Assistant
functionality. Personal or corporate sales planning items can be defined to serve as template assessments or template
activity plans. Both types of sales planning items can be defined as relevant to one or more sales stages within one or
more sales methodologies. A template assessment contains one or more attributes, optionally validated by a set of
valid values. Actual Assessments are created from a template assessment during a specific sales stage to assess an
opportunity, an account, or a contact. A template activity plan is made up of one or more template activities. Actual
activity plans are created from a template activity plan during a specific sales stage to prompt the user to plan certain
activities copied from the template activities.
101
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Activity S_EVT_ACT
Activity Plan S_EVT_ACT
Activity Plan Template S_TMPL_PLANITEM
Assessment Template S_TMPL_PLANITEM
Assessment S_ASSESS
Assessment Attribute S_ASSESS_ATTRIB
Assessment Attribute Valid Value S_ASSESS_ATTVAL
Assessment Value S_ASSESS_VAL
102
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Employee/Agent S_EMP_PER, S_CONTACT, S_PARTY
Opportunity S_OPTY
Opportunity Stage S_OPTY_STG
Person S_CONTACT, S_PARTY
Sales Methodology S_SALES_METHOD
Sales Stage S_STG
Stage Plan Item S_STG_PLANITEM
Stage Recommendation S_STG_RECOMMEND
Template Activity S_EVT_ACT
Social Media
This ERD (see the following figure) illustrates how social media data is integrated with the Siebel application to generate
service requests, leads, and loyalty credits. Loyalty credits can be defined for customers who post information in social
media about a company's products or perform other activities that might result in customer adoption or increased
market awareness of the product.
103
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Employee/Agent S_CONTACT, S_USER, S_EMP_PER, S_PARTY
Contact Social Media Profile S_CON_SM_PROF
Contact Social Media Profile Attribute S_CON_SM_ATTR
Lead S_LEAD, S_SM_DATA_LEAD
Loyalty Transaction S_LOY_TXN
Person S_CONTACT, S_PARTY, S_SM_DTASRC_USR
Social Media Channel S_SM_CHANNEL
Social Media Data S_SM_DATA
Social Media Data Source S_SM_DTA_SOURCE
Service Request S_SRV_REQ
Territory Management START HERE
This ERD (see the following figure) illustrates that sales territories can be defined geographically, explicitly (using named
accounts, contacts, or assets), or a combination of both. Flexible territory hierarchies can be defined to capture the
relationship between territories. Multiple positions can be assigned to a given territory and multiple territories can be
assigned to a given position. Accounts, contacts, and assets can be assigned to sales representatives within a sales
force.
104
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Account Team Member S_ACCNT_POSTN
Account/Terr Mapping S_TERR_ACCNT
Asset S_ASSET
Asset Team Member S_ASSET_POSTN
Asset/Terr Mapping S_TERR_ASSET
Business Unit S_BU
Contact S_CONTACT
Contact/Terr Mapping S_TERR_CON
Contact Team Member S_POSTN_CON
Division S_ORG_EXT
Geo/Terr Mapping S_TERR_ZIP, S_TERR_REGION
105
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Position S_POSTN
Position Territory Assignment S_TERR_POSITION
Region S_REGION
Territory S_TERRITORY
Territory Hierarchy S_TERR_HIER
Territory Version S_TERRHIER_NODE
Zipcode (None)
Territory Quota Rollup
This ERD (see the following figure) covers sales quotas setup and quota rollup in the territory management system.
It illustrates assigning sales quotas to periods, contacts, accounts, regions, and ZIP codes. These assignments can be
spread over different periods. As each territory consists of a set of contacts, accounts, regions, and ZIP codes assigned
with quotas; the quotas can be rolled up to each territory or each territory for each period.
The following table lists the entities in this ERD and their corresponding tables.
106
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Sales Quota S_SLS_QUOTA
Territory S_TERRITORY
Territory Quota S_TERR_QUOTA
Account/Quota S_QUOTA_ACCNT
Contact/Quota S_QUOTA_CON
Geo/Quota S_QUOTA_REGN, S_QUOTA_ZIP
Quota Assignment Breakdown S_QTA_ACC_PD, S_QTA_CON_PD, S_QTA_REGN_PD, S_QTA_ZIP_PD
Contact/Terr Mapping S_TERR_CON
Account/Terr Mapping S_TERR_ACCNT
Geo/Terr Mapping S_TERR_REGION, S_TERR_ZIP
Terr/Qta/Geo S_TERR_QTA_REGN, S_TERR_QTA_ZIP
Terr/Qta/Con S_TERR_QTA_CON
Terr/Qta/Accnt S_TERR_QTA_ACCT
Accnt Quota Credit S_TRQT_ACC_CRDT
Contact Quota Credit S_TRQT_CON_CRDT
Geo Quota Credit S_TRQT_REGNCRDT, S_TRQT_ZIP_CRDT
Period Quota S_QTA_PD_BRKDN
Terr Quota Breakdown S_TRQT_PD_BRKDN
Textile, Apparel, and Footwear
This ERD (see the following figure) illustrates how Siebel Business Applications support the assortment planning
process in the textile, apparel, and footwear industries. A retailer can define the products that are sold in each season,
107
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
then associate each product with one or more market segments to define recommended product assortments. Rather
than complicating the assortment by specifying product entries for each combination of one or two attributes in which
a style is manufactured (such as size or color), the attributes can be specified through a seasonal or nonseasonal
product option range (for example, a shirt size range of S, M, L, and XL). The retailer can then further specify
recommended product option mixes that indicate the proportion of each product option attribute value to deliver when
ordering a style (for example, a mix preference of 20% S, 30% M, 30% L, and 20% XL), or each retail customer can create
its own mix preferences. When creating an assortment plan for a season, the retail customer chooses the styles from
the recommended product assortment for the season, modifies the assortment to fit its customers, and chooses the
desired product option mix for each product option. The total ordered quantity of each style is then further broken
down into the quantity to be delivered in each subperiod within the season (for example, each week in the season). This
assortment plan can then serve as a guideline for ordering throughout the season or even facilitate the generation of
orders in each delivery period in the season.
The shaded subtypes in the following figure indicate examples of the types of data that can be found within a
supertype. They are not intended to indicate strict subtypes.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Marketing Segment S_MKT_SEG
Order S_ORDER
108
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Order Item S_ORDER_ITEM
Organization External S_ORG_EXT
Period S_PERIOD
Period Relationship S_PERIOD_REL
Product Attribute Type S_LST_OF_VAL
Product Attribute Value S_LST_OF_VAL
Product Option Mix Preference S_PROD_OPT_MIX
Product Option Mix Proportion S_PROD_OPT_PCT
Product Option Range S_PROD_OPTION
Product Option Range Member S_PROD_OPT_VAL
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Time Sheet
This ERD (see the following figure) illustrates how Siebel Business Applications track employee time sheets. Employees
can track time spent for client billing or for other purposes. Time can be entered for projects, activities, service requests,
and so on. These time units can then be aggregated into time sheets through time sheet lines. A time sheet is reported
for a specified reporting period and lists time spent on specific project or nonproject work such as vacation, sick leave,
training, and so on. Each time sheet line is specific to a given day within the reporting period.
109
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Organization Unit S_ORG_EXT, S_PARTY
Period S_PERIOD
Person S_CONTACT, S_PARTY
Project S_PROJ
Project Team Role S_PROJ_RSRC
Service Request S_SRV_REQ
Time Unit S_TMSHT_ITEM
Timesheet S_TMSHT
110
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Timesheet Approval S_TMSHT_APPR
Timesheet Line S_TMSHT_LN
Work Type S_PROJ
Trade Promotions
This ERD (see the following figure) illustrates the planning and execution of a consumer goods promotion, including
definition of promotion-products, promotion-accounts, and promotion-account-products. Also supported are
promotion payments, promotion agreements, and observations of store conditions.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Contract S_D0C_AGREE, S_DOC_QUOTE, S_ORDER
111
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Contract Item S_AGREE_ITEM, S_QUOTE_ITEM, S_ORDER_ITEM
Fund Allocation S_MDF_ALLOC
Internal Product Presence S_ORG_PROD
Marketing Development Fund S_MDF
Marketing Event or Activity S_SRC, S_SRC_CHNL
Note S_NOTE_SRC
Order S_ORDER
Other Contract S_DOC_AGREE, S_DOC_QUOTE
Person S_CONTACT, S_PARTY
Product S_PROD_INT, S_PROD_EXT
Training Curriculum Course
This ERD (see the following figure) illustrates the entities and relationships relevant to the training business function. A
training curriculum is made up of one or more training courses, which are offered through one or more course offerings.
Both courses and curriculums target one or more audience types and have literature associated with them. A person
can be registered for one or more course offerings. Tests can be defined for one or more course offerings, including test
questions and possible answers. Tests taken by an Individual contain the answer given by that person to each question
and the score achieved by that person for each question.
112
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Catalog Category S_CTLG_CAT
Access Group S_PARTY
Employee Course S_EMP_CRSE
Employee Course Status S_EMP_CRSE_STAT
Training Test Engine
This ERD (see the following figure) illustrates the entities and relationships relevant to the training test engine business
function. Tests can be defined for one or more course offerings, or for one or more courses, including test questions
and possible answers, and can be available in one or more languages. Each test question can be either determined in
advance or pulled from a question pool at run time. Tests taken by an individual contain the exact question presented to
the individual, the individual's answer to each question, and the score achieved by that person for each question. It also
keeps track of whether the individual has attempted to answer the question.
113
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Course/Course Offering Test S_CRSE_OFFR_TST
Event Location S_EVTLOC
Individual’s Test S_CRSE_TSTRUN
Individual’s Test Answer S_CRSE_TSTRUN_A
Individual’s Test Category S_TSTRUN_CATSTS
Individual’s Test Question S_CRSE_TSTRUN_Q
Marketing Event or Activity S_SRC
Pool Question S_POOL_QUES
Product or Service S_PROD_INT
114
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Question/Possible Answer S_CRSE_TST_ANSR
Question/Question Pool, Question Pool, S_TST_QUES
Question
Question Category LOV
Test Available Language S_CRSE_TST_LANG
Test Question S_CRSE_TST_QUES
Topic/Objective S_CRSE_TOPIC
Training Course S_PROD_INT_CRSE, S_PROD_INT
Training Course Offering S_SRC_EVT, S_SRC
Training Test S_CRSE_TST
Versioned Object Definition
Versioned Object Definition (see the following figure) provides a system for managing the versioned objects in the
system, including Products, Product Templates (Classes), Attributes, Context Variables, and so on. Versioned Object
Definition replaces the Product Configurator infrastructure tables in all previous releases.
115
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Attribute Definition S_ISS_ATTR_DEF
Attribute Value S_ISS_ATTR_VAL
Joint Workspace S_ISS_JWS
Joint Workspace Item S_ISS_JWS_ITEM
Object Attribute S_ISS_OBJ_ATTR
Object Attribute Value S_ISS_OBATR_VAL
Object Definition S_ISS_OBJ_DEF
Object Definition S_VOD
Versioned Object Definition Version S_VOD_VER
116
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Warranty
This ERD (see the following figure) illustrates how Siebel Business Applications track product warranty coverages.
Warranty coverage is provided by an organization (often the vendor of the product) and covers one or more products.
The products covered under the warranty coverage are specified directly through product warranty coverage entries.
Warranty service can be provided by one or more authorized service providers.
The various warranty coverages are applied to an asset through a Warranty Policy. A warranty can be tracked
throughout its life, and can be applied to fully or partially compensate the service provider for service requested in a
service order. Warranties can also include coverage lists, exclusions from coverage, fault codes, trouble codes, repair
operation codes, and repair operation times associated with them.
A Supplier Warranty Policy is an agreement between the parts supplier and the original equipment manufacturer. Parts
are covered as line items of the agreement with the rules and conditions of compensation specified.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Asset S_ASSET
Asset Warranty Coverage S_ASSET_WRNTY
Contact S_CONTACT
Coverage List S_CVRG_LST, S_WRNTY_CVRGLST
117
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Exclusion S_EXCLUSION, S_WRNTY_EXLSN
Fault/Trouble Code S_FAULT_CODE
Labor Operation Code S_LAB_OPER_CODE, S_CVRGLST_LABOP
Labor Operation Time S_LAB_OPER_TM
Order S_ORDER
Order Item S_ORDER_ITEM
Organization Unit S_ORG_EXT, S_PARTY
Partner Labor Rate S_PRTNR_LAB_RATE
Position S_POSTN
Product S_PROD_INT, S_CVRGLST_PART
Product Line S_PROD_LN
Product Line Warranty Coverage S_PRDLN_WRNTY
Product Warranty Coverage S_PROD_WRNTY
User S_USER
Warranty Coverage S_WRNTY_CVRG, S_WRNTY_CVRG_X
Warranty Coverage Attachment S_WRNT_CVRG_ATT
Warranty Service Provider S_WRNTY_SRV_ORG
Warranty Claim
Warranty Claim (see the following figure) is the dealer's or service provider's claim for repair or replacement, or
compensation for nonperformance or under-performance, of an item as provided for in its warranty. Prewarranty
authorization is the request submitted by the dealer or service provider to seek approval to carry out the repair work
118
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
for the claim. Warranty claim items can relate to repair or replacement of certain parts of the asset. The compensation
details for the failures are included. Compensation can be claimed for repair or replacement of parts, labor charges, and
sublet charges.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Agreement S_DOC_AGREE
Asset S_ASSET
Asset Warranty Coverage S_ASSET_WRNTY
Business Unit S_BU
Campaign S_SRC
Contact S_CONTACT
Event Activity S_EVT_ACT
Exclusion S_EXCLUSION
Fault/Trouble Code S_FAULT_CODE
Labor Operation Code S_LAB_OPER_CODE
119
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Order S_ORDER
Order Item S_ORDER_ITEM
Partner Labor Rate S_PRTNR_LAB_RATE
Position S_POSTN
Product S_PROD_INT
Service Request S_SRV_REQ
Source Asset S_SRC_ASSET
Source Payment S_SRC_PAYMENT
Source Payment Item S_SRC_PAYMT_ITM
User S_USER
Validation Message S_ISS_VALDN_MSG
Warranty Claim S_WRNTY_CLAIM
Warranty Claim Attachment S_WRNTY_CLM_ATT
Warranty Claim Item S_WRNTY_CLM_IT
Warranty Claim Part S_WRNTY_IT_PROD
Work Order
A work order (see the following figure) is created when a dealer performs any kind of service, which can be part of a
warranty claim or a paid service on the asset. The work order is used to document all repair-related information. Work
Order Items can relate to replacement of certain parts of the asset. Compensation details for failures are included.
Compensation can be claimed for parts replacement, labor charges, and sublet charges.
A supplier recovery claim is the claim for failed parts supplied by the supplier. The claim is based on the supplier
warranty policy and made by the original equipment manufacturer to the supplier.
120
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Asset S_ASSET, S_ASSET_EXLSN
Asset Warranty Coverage S_ASSET_WRNTY
Business Unit S_BU, S_WRK_ORDR_BU
Contact S_CONTACT
Event Activity S_EVT_ACT
Exclusion S_EXCLUSION
Fault and Related Operation S_FLT_LABOPER
Fault and Related Trouble S_FLT_TRBL_REL, S_FAULT_CODE
Fault/Trouble Code S_FAULT_CODE
Labor Operation Code S_LAB_OPER_CODE
Order Item S_ORDER_ITEM
121
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Position S_POSTN, S_WRKORDR_POSTN
Product S_PROD_INT
Service Request S_SRV_REQ
User S_USER
Warranty Claim S_WRNTY_CLAIM
Warranty Claim Item S_WRNTY_CLM_IT
Work Order S_WORK_ORDER
Work Order Attachment S_WRKORDR_ATT
Work Order Item S_WRK_ORDR_ITEM
Work Order Part S_WRKORDER_PART
Entity Relationship Diagrams and Descriptions for Siebel
Industry Applications
The ERD descriptions and diagrams in this topic apply to Siebel Industry Applications. These applications are designed
for specific industries such as the pharmaceutical, energy, insurance, and healthcare industries. They include Siebel
Consumer Sector, Siebel Energy, Siebel Finance, Siebel High Tech and Manufacturing, Siebel Life Sciences, Siebel Public
Sector, and Siebel Travel and Transportation, and other applications. The following table provides a list of ERDs in
alphabetic order.
The following table provides a list of ERDs in alphabetic order.
ERD Name Functional Area
Account Targeting Consumer Sector
Activity Life Sciences
Affiliations and Best Times Life Sciences
122
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Agencies/Agent Financial Services
Automotive Retail Automotive
Brick Life Sciences
Clinical Study Management Life Sciences
Clinical Study Site Management Life Sciences
Clinical Training Planning and Tracking Life Sciences
Communications, Media, and Energy (CME) CME
Account
CME Agreement CME
CME Alert CME
CME Energy Products, Service, and Usage CME
CME Order Management CME
Commercial Banking Financial Services
Commercial Insurance Financial Services
Community/Chat Discussion Life Sciences
Dealer Sales and Service Promotion Automotive
Document ID and Tax ID Handheld
Event Tax Administration Hospitality
Financial Account Financial Services
Financial Account Application Financial Services
Financial Account Origination Financial Services
Financial Investments Financial Services
123
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Financial Products Financial Services
Financial Services Events Financial Services
Fleet Management Financial Services
Fleet Management - Location Financial Services
FLEXCUBE Universal Banking Integration Financial Services
Group Insurance Policies Financial Services
Group Pensions Financial Services
Health Provider and Provider Group Financial Services
High Tech Special Pricing Authorization Sales
Hospitality Category General
Hospitality - Meeting Package General
Institutional Sales Financial Services
Insurance Claims Financial Services
Insurance Policies Financial Services
Life Insurance Policy Financial Services
Loyalty General
Loyalty Flowchart and Formula General
Managed Care Life Sciences
Medical Education Event Management Life Sciences
Objectives Consumer Sector
Oracle Policy Automation Integration Financial Services, Public Sector
124
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Personalized Content Delivery Life Sciences
Public Sector Benefit Case Management Public Sector
Public Sector Case Lead Management Public Sector
Public Sector Child Welfare Public Sector
Public Sector Contact Identity Public Sector
Public Sector Evidence Management Public Sector
Public Sector Incident Management Public Sector
Public Sector Service Provider and Referral Public Sector
Management
Real-Time Scheduler Integration Service
Routes and Best Call Hours Sales
Sales Volume Planning Consumer Sector
Sample Management Life Sciences
Special Rate List Communications
Syndicated Data Life Sciences
Teller Administration Financial Services
Territory Alignment–Quota Assignment Sales
Territory Management - Consumer Sector Service
Territory Management - Life Sciences Sales
Universal Customer Master General
Vehicle Automotive
125
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
ERD Name Functional Area
Vehicle Collection Automotive
Vehicle Financing Automotive
Vehicle Sales Automotive
Account Targeting
This ERD (see the following figure) illustrates how Siebel Enterprise applications (Consumer Goods) support account
targeting as an extension of basic querying. Account targeting provides the capability to save the results of account
queries and apply those account lists when you schedule routes. The results that you save are called target lists. Target
lists consist of sets of accounts that meet the conditions defined by the query. Typically, the target lists you create in
account targeting are for a specific purpose and period of time. For example, the target lists might be used to support a
promotion, a campaign, or an objective.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Criteria S_CG_QUERY_ITEM
Employee S_CONTACT, S_PARTY
Objective S_SRC
Query S_CG_QUERY
126
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Route S_ACCNTRT
Activity
This ERD (see the following figure) illustrates how activities, contact calls, account calls, attendee calls, and meetings
are managed. Every activity belongs to the employee creator and other employees assigned to the activity. Activities
can be associated with one or more contacts and one account. Contact calls are associated with the employee creator
and the contact, and can be associated with other employees who have been assigned, product details, samples,
promotional items, and decision issues. Account calls are associated with the employee creator and an account, and
can be associated with other employees who have been assigned, product details, and multiple attendee calls. Each
attendee call is associated with the product details from the account call and one contact, and can be associated with
samples, promotional items, and decision issues. Meetings include the employee who owns the meeting, the contacts
invited to attend, the account where the meeting is taking place, and the product to be discussed at the meeting.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Activity S_EVT_ACT
Contact S_CONTACT
Employee S_EMP_PER, S_CONTACT, S_PARTY
127
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Indication S_PROD_APPLCTN
Issue S_PROD_ISS
Person S_CONTACT, S_PARTY
Product S_PROD_INT
Affiliations and Best Times
This ERD (see the following figure) illustrates how contacts and accounts can be affiliated with one another, and how
best times can be stored. Contacts can have multiple account affiliations, and can store multiple types or roles and
best times for each account affiliation. Contacts can have multiple addresses and can share address records with
other contacts. Contacts can also have a primary address for each position that is on the team. Accounts can also
have multiple addresses and can share address records with other accounts. Contacts and accounts can share address
records. Best times are stored for each address for each contact. Best times are also stored for each account.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account Affiliation S_PARTY_PER
Address S_ADDR_PER
Address Usage S_CON_ADDR
128
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Best Times (Account) S_BEST_CALL_HRS
Best Times (Account Affiliation) S_PARTY_PER_HRS
Best Times (Contact Address) S_CON_ADDR_HRS
Organization S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Person Position S_POSTN_CON
Position S_POSTN, S_PARTY
Type S_PARTY_PER_DTL
Agencies/Agent
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of internal organization
units (such as insurance agencies) that can use external organization units or agencies (such as insurance brokers)
as well as individual agents to distribute their products. Each external organization unit agency or agent can be
associated with details (such as licensing, appointments, commission contracts, and NASD registrations, and other
selling agreements).
129
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Agency Line of Business S_AGNC_LCNSLOB
Agent Line of Business S_AGENT_LCNSLOB
Agent Detail S_AGENT_DETAIL
Agency Detail S_AGENCY_DETAIL
Contact S_CONTACT, S_PARTY
Organization Unit S_ORG_EXT, S_PARTY
Product Line S_PROD_LN
Automotive Retail
This ERD (see the following figure) illustrates the Automotive retail process at dealerships. Sales goals are defined for
every sales representative as well as the dealership for a period (month, quarter, and so on.). These goals are for new
and used vehicles or a fleet of vehicles. The sales process could comprise several steps and an opportunity to sell a
130
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
vehicle might involve some of these sales steps. The sales steps taken by every sales representative are aggregated for
the period to determine the effectiveness of each sales step.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Asset S_ASSET
Employee S_EMP_PER, S_CONTACT, S_USER
Employee Budget/Forecast S_AT_PER_FCST
Opportunity S_OPTY, S_OPTY_ATX
Opportunity Sales Step S_OPTY_SLS_STEP
Organization S_ORG_EXT, S_BU
Period S_PERIOD
Person S_CONTACT, S_CONTACT_ATX, S_CONTACT_BU
131
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Sales Step S_SALES_STEP
Sales Step Goal S_FCST_SLS_STEP
Showroom Log Entry S_COMM_LOG
Store Budget/Forecast S_AT_ORG_FCST
Vehicle S_ASSET, S_ASSET_ATX
Brick
This ERD (see the following figure) illustrates how region (brick and mini brick) is used in Siebel Life Sciences. Area can
be associated with multiple positions. Area is defined at the address level for organizations and at the contact level. Area
is tracked for activities. Syndicated data is also available at the area level.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Account Address S_CON_ADDR
Address S_ADDR_PER
Contact S_CONTACT, S_PARTY
Organization S_ORG_EXT, S_PARTY
132
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Position S_POSTN
Region S_REGION
Syndicated Data S_SYND_DATA
Clinical Study Management
This ERD (see the following figure) illustrates how clinical trials are managed. Each clinical trial starts with a protocol
for a specific compound (product). Each protocol is conducted by sites and managed by site personnel. A protocol can
have many versions and multiple protocols can roll up to a single program. Protocols can also roll up to regions. Subjects
are screened and enrolled at protocol sites for specific protocol versions. Protocol sites are paid, based on the activities
they complete. Visits and activities are generated for subjects based on templates defined for the protocol. The Clinical
Research Associates perform site initiation activities for protocol sites and submit periodic trip reports. A protocol can
also be associated with one or more projects. For a complete layout of projects, refer to Professional Services.
The following table lists the entities in this ERD and their corresponding tables.
133
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Account S_ORG_EXT, S_PARTY
Activity S_EVT_ACT
Address S_ADDR_PER
Affiliation S_PTL_ST_CON_LS, S_PTL_STCONHIST
Application S_CL_PGM_APP_LS
Clinical Payment S_SRC_PAYMENT
Contact S_CONTACT, S_PARTY
Contract S_DOC_AGREE
Design S_CL_DSGN_LS
Exception Activity S_CL_ACT_EXC_LS
Position S_POSTN
Product S_PROD_INT
Program S_CL_PGM_LS
Project S_PROJ
Project Subcontractor S_PROG_ORG
Project Subcontractor Contact S_PROJ_ORG_CON
Protocol S_CL_PTCL_LS
Protocol Site S_PTCL_SITE_LS
Subject S_CL_SUBJ_LS
Subject Status S_CL_SUBJ_ST_LS
Subject Template S_SUBJ_TMPL_LS
134
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Template Version S_SBJTMP_VER_LS
Template Visit S_TMPL_PLANITEM
Trip Report S_EVT_ACT
Visit S_EVT_ACT
Clinical Study Site Management
This ERD (see the following figure) is an extension of Clinical Study Management and illustrates:
• Activities related to subjects participating in clinical studies and the list of visit types to be scheduled for this
subject.
• How site visit logs are maintained. Clinical Research Associates visit different targeted sites depending on
research requirements and their visits are logged.
• How organizations, such as vendors, sponsors, clinical research organizations, central laboratories, and
institutional review boards, are associated with clinical protocol and clinical protocol sites.
• How summaries of subject visits are organized by visit type and by protocol site.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
135
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Activity S_EVT_ACT
Address S_ADDR_PER_S_CON_ADDR
Affiliation S_PTCL_ST_CON_LS
Contact S_CONTACT, S_PARTY
Protocol S_CL_PTCL_LS
Protocol Site S_PTCL_SITE_LS
Protocol Organization S_PTCL_ORG_LS
Protocol Site Organization S_PTCLST_ORG_LS
Site Status Summary S_CL_SIT_ST_SUM
Subject S_CL_SUBJ_LS
Subject Status S_CL_SUBJ_ST_LS
Subject Template S_SUBJ_TMPL_LS
Subject Visit Type S_CL_SUBJVST_TP
Template Version S_SBJTMP_VER_LS
Template Visit S_TMPL_PLANITEM
Visit S_EVT_ACT
Visit Log S_SITE_VST_LOG
Clinical Training Planning and Tracking
This ERD illustrates how administrators create training and training plans for clinical site personnel and how the training
is managed and tracked.
136
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Training Topic S_TRG_TOPIC_LS
Training Plan S_TRG_PLAN_LS
Training Rule S_TRG_RULE_LS, S_TRG_PLAN_LS, S_CL_PTCL_LS
Training Plan Version S_TRG_VER_LS, S_TRG_PLAN_LS
Protocol Site S_PTCL_SITE_LS
Clinical Protocol Training S_CL_PTCL_TRG, S_CL_PTCL_LS, S_TRG_TOPIC_LS
Assessment S_ASSESS
Clinical Program S_CL_PGM_LS
Communications, Media, and Energy (CME) Account
This ERD (see the following figure) illustrates how complex hierarchies of accounts are maintained in Siebel
Communications and Siebel Energy. Profiles are the way an account is further described. Addresses are associated with
contacts and accounts. Addresses are unique in the database. Trouble tickets (service requests) and activities can be
associated at the accounts level.
137
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Activity S_EVT_ACT
Address S_ADDR_PER
Billing Profile S_INV_PROF
Contact S_CONTACT, S_PARTY
Exemption Profile S_SUBSIDY
Financial Profile S_FINAN_PROF
Trouble Ticket S_SRV_REQ
CME Agreement
This ERD (see the following figure) illustrates how an agreement is managed in Siebel Business applications. An
agreement can be associated with many accounts. Terms and entitlements are associated with an agreement. An
agreement covers service instances and products through the account with which it is associated.
138
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Accounts S_ORG_EXT, S_PARTY
Agreement S_DOC_AGREE
Agreement Note S_NOTE_AGR_CUT
Agreement Terms S_AGREE_TERMS
Event Activity S_EVT_ACT
Parameter S_QUOTE_ITEM_XA
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Solution Set S_QUOTE_ITEM
CME Alert
This ERD (see the following figure) illustrates how credit and fraud alerts are managed for communications and utilities
customers. A fraud alert is associated with an account. Profile attributes provide more information about the fraud
139
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
threshold for an account. A credit alert is related to an account and a statement. Activities can be performed on both
types of alerts.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Activity S_EVT_ACT
Alert Attachment S_ALERT_ATT_CUT
Alerts S_ALERT_CUT
Asset S_ASSET
Bill Transactions S_BILL_MAINT
Billing Profile S_INV_PROF
Energy Consumption S_USAGE
Fraud Profile S_FRD_PROF_CUT
CME Energy Products, Service, and Usage
This ERD (see the following figure) illustrates how products and services in use, inactive, or planned are associated
with, tracked, and maintained by account. Assets are instances of internal products with the Siebel products catalog
and can represent equipment, services designated by the administrator. Services are represented as assets that consist
140
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
of specific commodities or energy service with corresponding rates or prices (for example, commercial electric service
with rate CE5). Each of these services can be further associated with one or multiple meters. After a service has been
established as an asset with corresponding rate and meter detail, the utility consumption is recorded for each period,
and an invoice is generated.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Address S_ADDR_PER
Asset S_ASSET
External Product Presence S_ORG_PRDEXT
Invoice S_INVOICE
Invoice Adjustment S_INVOICE_ADJ
Invoice Item S_INVOICE_ITEM
Payment S_SRC_PAYMENT
Period S_PERIOD
Product: External S_PROD_EXT
Product: Internal S_PROD_INT
141
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Service Instance S_ASSET
Usage S_USAGE
CME Order Management
This ERD (see the following figure) illustrates order management. Companies provide products and services to their
customers over an extended period of time. Quotes and orders are used to capture the changes to a customer's
installed services. The cycle starts when a customer requests the initial installation of a product or service in the form
of a quote. The quote is converted to an order and that order is provisioned. At that time, the products and services
described in the order are converted into assets associated with the customer's account. Subsequent changes to the
configuration, disconnect instructions, or additions to the installed assets are captured in further quotes and orders.
Order synchronization failures can also be tracked.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Asset S_ASSET
Asset Attribute S_ASSET_XA
142
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Order S_ORDER
Order Item S_ORDER_ITEM
Order Item Attribute S_ORDER_ITEM_XA
Product or Service S_PROD_INT
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Quote Item Attribute S_QUOTE_ITEM_XA
Failed Service Order S_SRV_ORD_FAIL
Service Request S_SRV_REQ
Commercial Banking
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of a commercial loan
(or facility) application by portfolio type. Each application is associated with many organizations as borrowers or lenders.
The application tracks the collateral, policies, prices of a facility, and documents used in the application process, for
example, trailing documents and attachments. An application must undergo several stages of approvals before it is
finally approved to become a financial account.
143
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Approval S_FN_APPR
Attachment S_OPTY_ATT
Borrower S_OPTY_ORG
Collateral S_FN_OFFR_COLT
Correspondence S_EVT_FUL_REQ
Employee S_EMP_PER, S_CONTACT, S_PARTY
Exception S_OPTY_ORG_FNXM
Facility S_REVN
Facility Detail S_OPTY_PROD_FNXM
Facility Organization S_OPTYPRD_ORG
Fee S_FN_OFFR_FEE
144
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Financial Account S_ASSET
Note S_NOTE_OPTY
Opportunity S_OPTY
Opportunity Detail S_OPTY_DTL
Organization S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Portfolio Type S_MKT_SEG
Product S_PROD_INT
Rating S_OPTY_ORG_FNXM
Revenue S_REVN
Revenue S_REVN
Trailing Document S_OPTY_DOC
Underwriting Standard S_MKT_SEG_VAL
Commercial Insurance
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of group classes of
insured items covered by an insurance policy. An insured item can belong to either one or two group classes, including a
region (such as a state), a location, (such as physical location), or a class (such as an employee). Insurance coverage can
be associated with either one or two group classes.
145
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Contact S_CONTACT,S_PARTY
Group Class S_FN_GRP_CLASS
Insurance Coverage S_APPLD_CVRG
Insured Item S_INS_ITEM
Policy Contact S_ASSET_CON
Community/Chat Discussion
This ERD (see the following figure) illustrates how topics can be created for chat or discussion purposes for a disease
state (market product). Users can register to chat for a particular topic or they can post messages to the discussion.
146
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Contact S_CONTACT, S_PARTY
Discussion Post S_MESG_BRD_LS
Product S_PROD_INT
Registration S_TOPIC_CON_LS
Topic S_TOPIC_LS
Dealer Sales and Service Promotion
This ERD (see the following figure) illustrates how a call list can be created by searching on specific attributes of vehicle,
person, sales history, or service history. A person might qualify to be on the call list by virtue of possessing a specific
vehicle, having the car serviced with the dealership in the past (the next service might be due), and so on. The dealer
can start a campaign for sales or service specials and include one or more call lists to be targeted through the campaign.
147
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Call List S_CALL_LST
Call List Contact S_CALL_LST_CON
Call List Contact Vehicle S_C_LST_CON_AST
Campaign S_SRC
Campaign Call List S_CAMP_CALL_LST
Campaign Contact S_CAMP_CON
Campaign Contact Vehicle S_CAMP_CON_AST
Marketing Event or Activity S_SRC
Person S_CONTACT, S_CONTACT_ATX
Vehicle S_ASSET, S_ASSET_ATX
148
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Document ID and Tax ID
This ERD (see the following figure) illustrates how document identification numbers are generated and assigned to each
user. Typically, document IDs are used to support a legal requirement to print unique numbers on legal documents,
such as invoices and receipts. Governments provide specifications on the document ID formats, and these formats can
be used to generate a document ID mask within the Siebel application. After the mask is created, it must be assigned
to individual users who have the authority to use them. When the user prints from the handheld device, a unique
sequence of numbers are printed onto each legal document defined with the document ID mask.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Authorized Product S_ORG_PROD
149
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Document Mask Component S_DOC_NUM_SEG
Document Types S_DOC_NUM
Document Values S_DOC_NUM_VAL
Invoice S_INVOICE
Order S_ORDER
Order Item S_ORDER_ITEM
Price List S_PRI_LST
Price List Item S_PRI_LST_ITEM
Event Tax Administration
This ERD (see the following figure) illustrates how the Siebel Hospitality application supports tax and service charge
calculation for invoices. An event is hosted at a property such as a hotel or convention center. Event functions and
associated subfunctions are conducted in rooms at the property. A team of events managers and operations staff at
the property work together to plan and execute the event. The event functions use assets that are specific instances
of products at each property. Each product is associated with a category and subcategory. Both categories and
subcategories are associated with charge codes. Each charge code is composed of taxes and service charges, which
might be taxable. The taxes and service charges linked with the charge code apply to the product.
150
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Category S_CTLG_CAT
Charge Code S_EVT_CHRG_LST
Event/Function S_SRC
Event Location Room S_EVTLOC_ROOM
Position S_POSTN
Price List S_PRI_LST
Price List Item S_PRI_LST_ITM
Product S_PROD_INT
151
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Property S_ORG_EXT, S_PARTY
Tax Code/Service Code S_PRI_LST
Team Member S_USER, S_PARTY
Financial Account
This ERD (see the following figure) illustrates how Siebel Financial Services supports tracking of financial accounts
(instances of products or assets). A financial account can be owned by an organization, or a number of contacts.
The owners can track the activities, service requests, balance history, and transactions on their accounts, as well as
the balance of their external accounts using Siebel Financial Services. The manager can track the profitability of his
customers through contact and account profitability.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account Aggregation Service S_FN_AAG_SVC
Account Analysis S_FN_SRVC_TXN
Account Profitability S_ORG_PRFTBLTY
Activity S_EVT_ACT
Address S_ADDR_PER
152
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Asset Relationship S_ASSET_REL
Assignment Group S_ASGN_GRP
Attachment S_ASSET_ATT
Authorization S_ASSETCON_AUTH
Balance History S_FN_ACCNT_BAL
Contact S_CONTACT, S_PARTY
Contact Profitability S_CON_PRFTBLTY
Fee S_FN_ACCNT_FEE
Financial Account S_ASSET
Financial Account Contact S_ASSET_CON
Financial Transaction S_FN_ACCNT_TXN
Note S_NOTE_ASSET
Organization Unit S_ORG_EXT, S_PARTY
Product S_PROD_INT
Schedule S_FN_ACCNT_SCHD
Service Request S_SRV_REQ
Financial Account Application
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of a financial product
(loan, mortgage, or similar) application by a consumer (contact) or an organization. The applicant is assessed based
on incomes, expenses, assets, and liabilities. Fees and collateral are associated with the application, and when it is
approved, it generates a financial account (asset).
153
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Address S_ADDR_PER, S_CON_ADDR
Application S_OPTY
Application Contact S_OPTY_CON
Application Product S_REVN
Assessment S_ASSESS
Assessment Value S_ASSESS_VAL
Asset Liab Contact S_FN_ASTLB_CON
Asset Liability S_FN_ASSET_LIAB
Collateral S_FN_OFFR_COLT
Contact S_CONTACT, S_PARTY
Credit Report S_FN_CRDT_RPT
154
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Credit Report Item S_CRDT_RPT_ITEM
Fee S_FN_OFFR_FEE
Financial Account S_ASSET
Inc. Exp. Contact S_FN_INCEXP_CON
Income/Expense S_FN_INCM_EXP
Note S_NOTE_OPTY
Organization S_ORG_EXT, S_PARTY
Product S_PROD_INT
Quote S_DOC_QUOTE
Sales Stage S_STG
Trailing Document S_OPTY_DOC
Financial Account Origination
This ERD (see the following figure) illustrates how to create an applicant group and how to include one or more
individual applicants or organizations for a financial product, such as loans, mortgages, savings, or checking, in the
applicant group. The organization that is included can also be an applicant or a legal entity, such as a law firm associated
with the applicant. Individual applicants can also include guarantors, those who hold power of attorney, and so forth.
Identity information about individuals, such as passport or driver's license information, can be captured and used to
create multiple actions using the customer order management process. These actions can include opening accounts,
ordering forms, ordering credit or ATM cards, and so forth, and can be integrated with back-office applications.
155
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY, S_APPLNTGRP_ACC
Applicant Group S_APPLNT_GRP
Applicant Group Contact S_APPLNTGRP_CON
Applicant Group Contact Identity S_APPLNT_IDENT
Contact (Person) S_CONTACT, S_PARTY
Literature S_LIT
Order S_ORDER
Order Document S_ORDER_DOC, S_ORDR_DOC_LIT
Order Item S_ORDER_ITEM
Order Item Document S_ORDERITM_DOC, S_ORDITMDOC_LI
Quote S_DOC_QUOTE, S_DOC_ORDER
Quote Item S_QUOTE_ITEM
156
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Financial Investments
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of financial investments
and other relevant associations with organizations, financial accounts, holdings, distribution, and transactions. The
major entities are depicted in the lower half of the diagram (security and external organization).
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Contact S_CONTACT,S_PARTY
Distribution S_FNSEC_DSTRBTN
External Organization S_ORG_EXT, S_PARTY
Earning S_FNSEC_ERNG
Financial Account S_ASSET
157
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Holding S_FN_HLDNG
Industry S_INDUST
Literature S_LIT
Security S_PROD_INT
Transaction S_FN_ACCNT_TXN
Financial Products
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of financial products
and other relevant associations. Internal products, rates, fees, and product line information is also depicted. The major
entities are depicted in the lower half of the diagram (Product Internal).
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Benefit S_PROD_BNFT
158
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Condition S_PROD_COND
Feature S_PROD_SPEC
Fee S_PROD_FEE
Product S_PROD_INT
Product Line S_PROD_LN
Rate S_PROD_RATE
Financial Services Events
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of marketing events in
a three-level hierarchy (parent events, sub events, and sessions). An event can be associated with many opportunities,
product lines, regions, or industries. It includes a list of registrants (contacts or organizations). Vendors, venues, and
suppliers are tracked for the event in the organization entity. For persons, tracks the registration procedure and travel
plans they might participate in to attend the event.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
159
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Equipment Requirement S_ORDER_ITEM, S_QUOTE_ITEM
Event Cost S_SRC_COST
Event Location S_ORG_EXT, S_PARTY
Event Registration S_SRC_EVT_REG
Event Session S_SRC_EVT, S_SRC
Event Venue S_SRC_VENUE
Industry S_INDUST
Literature Item S_LIT
Location Room S_EVTLOC_ROOM
Marketing Event or Activity S_SRC
Organization Unit S_ORG_EXT, S_PARTY
Person S_EMP_PER, S_CONTACT, S_PARTY
Position S_POSTN
Product S_PROD_INT
Product Line S_PROD_LN
Region S_REGION
Room Avail Equipment S_EVTLOC_RM_EQP
Travel Participant S_EVT_TRVL_PER
Travel Plan S_EVT_TRVL_PLAN
Vendor S_SRC_ORG
Vendor Offer S_EVT_VNDR_OFR
160
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Vendor Review S_EVT_VNDR_RVW
Vendor Service S_EVT_VNDR_SVC
Venue S_ORG_EXT, S_PARTY
Venue Offer S_EVT_VENUE_OFR
Venue Review S_EVT_VENUE_RVW
Venue Service S_EVT_VENUE_SVC
Fleet Management
Fleet Management enables transportation management customers to perform order capture, rating, and order
management of transportation orders. The following figure shows the Fleet Management ERD.
Return Route Orders functionality allows multiple stops to be created for a given location and allows both origin and
destination locations to reference the same location.
Order Revision Enhancements functionality provides stricter constraints for revising, rejecting, and cancelling orders.
Users will not be able to revise any inactive order or rejected order. Furthermore, users will not be able to revise any
order in which there is a relationship with a cancelled order.
After completing the order, the customer service representative submits the order to Oracle Transportation
Management. Oracle Transportation Management takes over the fulfillment of the order from the Siebel application.
The marketing department of the transportation provider defines the targeted lanes; that is, the lanes where the
company wants to focus on selling transportation routes. A lane is a route between an origin and a destination, using a
given line of business. Whenever Oracle Transportation Management sends information that an order is complete, the
Siebel application adds information about this order to its order history. The order history aggregates weekly orders for
each account for each lane.
161
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Address S_ADDR_PER
Business Unit S_BU
Contact S_CONTACT
Favorite Product Action S_PRDFAVITM_ACT
Favorite Product Item S_QUOTE_ITEM
Fleet Management Location S_LOCATION
Fleet Management Location Role S_LOC_ROLE
Fleet Management Order S_ORDER
Fleet Management Order Detail S_ORDER_FM_DTL
Fleet Management Order History S_FM_ORDER_HIST
Order Account S_ORG_EXT
162
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Order Item S_ORDER_ITEM
Order Item Stop S_ORDITEM_STOP
Order Stop S_ORDER_STOP
Order Stop Action S_ORDSTOP_ACTN
Order Stop Detail S_ORDERSTOP_DTL
Quote S_DOC_QUOTE
Quote Item S_QUOTE_ITEM
Rating Solution S_RTNG_SLTN
Rating Solution Detail S_RTNG_SLTN_DTL
Rating Solution Detail Pricing S_SLTN_DTL_PRC
Targeted Lane S_TARGETED_LANE
Fleet Management - Location
This ERD (see the following figure) illustrates how geographic locations related to fleet management can be modeled
to optimize deliveries or pickups for a given location. In this model, a given location is the persons and organizations
located in that general area and the addresses associated with the parties in that area.
163
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Contact S_CONTACT, S_PARTY, S_LOC_CONTACT
Account S_ORG_EXT, S_PARTY, S_LOC_ACCNT
Address S_ADDR_PER, S_ADDR_CON, S_LOC_ADDR
Location S_LOCATION
Location Role S_LOC_ROLE
FLEXCUBE Universal Banking Integration
The FLEXCUBE Universal Banking Integration ERD (see the following figure) describes the integration of Siebel CRM
with an external banking system. It provides new features, such as financial plans, goals, and limits that can be specified
for a customer.
Financial plans are investment plans created for customers after analyzing the customer’s financial position, expected
future cash-flows, inflation, returns, and goals. Financial goals include but are not limited to education, retirement,
investment, buying property, and so forth. The individual's goals are used as guidelines to map a course of action to
reach those goals. A financial limit specifies the total liabilities of the customer arising out of the credit facilities used by
the customer. A customer can also provide financial mandates, which are instructions to initiate payment transactions
at a predetermined future time or frequency or for such future transactions.
The following table lists the entities in this ERD and their corresponding tables.
164
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Account S_ORG_EXT, S_ORG_EXT_FNX
Branch S_ORG_EXT
Contact S_CONTACT, S_CONTACT_FNX
Financial Account S_ASSET, S_FN_ACCNT1_FNX
Financial Goal S_FN_GOAL
Financial Limit S_FN_LIMIT
Financial Mandate S_FN_MANDATE
Financial Plan S_FN_PLAN
Offer S_DMND_CRTN_PRG
Party S_PARTY
Product S_PROD_INT
Group Insurance Policies
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of a group policy
instance, which can be either a group health or a group life policy, or other types of employee benefits. One organization
can own many policy instances. Each organization's employee is a primary policy contact, and determines the type of
coverage and the elements of coverage they enjoy. Each contact covered by a policy instance includes an insurance
coverage role, and the contact's dependents are stored as coverage elements. The coverage role provides each coverage
element with multiple possible benefits.
165
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Census S_ORG_CENSUS
Census Detail S_CENSUS_DETAIL
Class S_VOD, S_VOD_VER
Class Attribute S_XA_ATTR
Contact S_CONTACT,S_PARTY
Coverage Role S_FN_CVRG_ROLE
Employee Class S_FN_GRP_CLASS
Instance Attribute S_ASSET_ITEM_XA
Organization Unit S_ORG_EXT, S_PARTY
Policy Instance S_ASSET
Primary Policy Member S_ASSET_CON
Product Attribute S_PROD_INT_XA
166
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Product Class S_FN_HLDNG
Product Class Rate S_FN_HLDNG_RATE
Product Component S_PROD_ITEM
Product Enrollment S_FNCVRG_ELMNTS
Product For Member S_APPLD_CVRG
Product Instance S_ASSET_ITEM
Product Internal S_PROD_INT
Rate Band S_PROD_RATE
Group Pensions
This ERD (see the following figure) illustrates how Siebel Financial Services supports group pension plans. The
group pensions module is designed to meet the needs of sales and service professionals, managers, and pension
administrators. Users can define group pension plans, plan classes, plan eligibility rules, and plan funding vehicles.
When a pension plan is defined, users can track eligible and enrolled participants, participant contribution and
investment allocations, and participant beneficiary information.
The following table lists the entities in this ERD and their corresponding tables.
167
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Allocation S_APPLD_CVRG
Beneficiary S_FN_CVRG_ROLE
Employee Class S_FN_GRP_CLASS
Funding Vehicle S_PROD_REL
Group Pension Participant S_CONTACT, S_PARTY
Group Pension Plan S_ASSET
Group Pension Plan Contact S_ASSET_CON
Organization Unit S_BU
Pension Plan Offering S_PROD_INT
Person S_CONTACT, S_PARTY
Health Provider and Provider Group
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of heath-related
organizations (such as hospitals) and providers (such as physicians). A provider can be affiliated with one or more
organizations and can deliver a health product (a medical service) to a contact or a patient during an encounter. Siebel
Financial Services also stores payments made to a provider by an organization, as well as the specialty, language, and
schedule of the provider.
168
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Contact S_CONTACT,S_PARTY
Encounter S_FN_HLTH_ENCTR
Health Product S_PROD_INT
Language S_CONTACT_FNXM
Organization S_ORG_EXT, S_PARTY
Payment S_SRC_PAYMENT
Provider Group Schedule S_ORG_TIME
Provider Schedule S_CON_LOCTN
Specialty S_CONTACT_FNXM
169
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
High Tech Special Pricing Authorization
This ERD (see the following figure) illustrates the special pricing authorization business process for Siebel High Tech,
which uses the Meet Competition Quote and Design Registration features. The quote or design registration opportunity
leads to an Agreement with Entitlements for discounts on products. Point of sale data includes claim items, which can
refer to agreed upon entitlements.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Address S_ADDR_PER
Agreement S_DOC_AGREE
Claim Item S_POS_CLAIM_ITM
Design Registration S_OPTY_DSGN_REG
Entitlement S_ENTLMNT
Entitlement Product Price S_ENTL_PRDPRI
170
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Meet Competition Quote S_DOC_QUOTE
Opportunity S_OPTY
Point of Sale Header S_POS
Point of Sale Item S_POS_ITEM
Product S_PROD_INT
Quote Line Item S_QUOTE_ITEM
Hospitality Category
This ERD (see the following figure) illustrates how Siebel Hospitality supports the categorization for revenue. There
can be N levels of the revenue category in the hierarchy. One parent category can include one or more categories, and
one category can include one or more subcategories. The subcategory is defined for the charge code and product,
and a report is generated by category for each function and quote. Function and quote revenue by category hierarchy
supports the hierarchical category. A macro estimate for the opportunity and quote is generated at the category level.
The following table lists the entities in this ERD and their corresponding tables.
171
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Hospitality Category S_CTLG_CAT
Parent Category S_CTLG_CAT
Category S_CTLG_CAT
Subcategory S_CTLG_CAT
Category Revenue S_AVG_VAL_TNT, S_FN_CATRV_TNT, S_QUO_CATRV_TNT
Function Average Level S_AVG_VAL_TNT
Function Revenue by Category S_FN_CATRV_TNT
Quote Revenue by Category S_QUO_CATRV_TNT
Quote Macro Revenue Estimate S_QUO_MEST_TNT
Opportunity Macro Revenue Estimate S_OPTY_MEST_TNT
Charge Code S_EVT_CHRG_LST
Function Business Type by Date S_BIZ_TP_DT_TNT
Function S_FUNC_TNT
Function Report Section S_FUNC_RPT_SECT
Property Report Section S_PROP_RPT_SECT
Report Section S_RPT_SECT_TNT
Property/Asset S_ORG_EXT
Quote S_DOC_QUOTE
Opportunity S_OPTY
Product or Service S_PROD_INT
Tax/Service List S_PRI_LST
172
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Hospitality - Meeting Package
This ERD (see the following figure) illustrates how offerings from a hospitality organization can be packaged as
a product. Products can include one or more functions, such as breakfasts, dinners, weddings, receptions, board
meetings, or share holders' meetings, as well as facilities used for the functions, such as rooms, conference halls, and
dining halls. The package can also include video and audio equipment, and so forth.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Display Abbreviation S_PTY_LOV_ABBR
Meeting Function S_MTG_FNCTN
Meeting Function Item S_MTG_FNCTN_ITM
Meeting Package S_PROD_MTG_PKG, S_PROD_INT
Meeting Package Item S_MTG_PKG_ITEM
Meeting Package Room S_MTG_PKG_ROOM
Meeting Package Room Price S_MTG_PKGRM_PRI
Product S_PROD_INT
Quote/Order S_DOC_QUOTE, S_DOC_ORDER, S_QTE_MTG_PKG
173
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Institutional Sales
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of a product or security
traded in the stock market. One or more positions (such as institutional salespeople) can cover a product. A position
owns and prepares a call list containing one or more contacts, who are the objects of the calls associated with any
number of products. Siebel Financial Services also tracks security or product line interests of a contact, as well as
the securities held by an organization unit (such as a company). Siebel Financial Services creates many-to-many
relationships when storing the literature associated with employees, activities, and products. A position can send any
number of pieces of literature to a contact within one activity.
174
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Call List S_CALL_LST
Contact S_CONTACT, S_PARTY
175
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Employee S_EMP_PER, S_CONTACT, S_PARTY
Industry S_INDUST
Literature S_LIT
Organization Unit S_ORG_EXT, S_PARTY
Position S_POSTN, S_PARTY
Product S_PROD_INT
Product Line S_PROD_LN
Insurance Claims
This ERD (see the following figure) shows the important entities in the Insurance Claim recording and handling process.
It illustrates the relationship between claims and claim elements and the various parties to the claim. It covers the
association of invoices, invoice line items, payments and recoveries to claims. Also illustrated is the relationship between
claim and insurance policy, activity, service request, document, appraisal, and so forth. The diagram also shows the
metadata that supports claims and claim elements.
The following table lists the entities in this ERD and their corresponding tables.
176
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Activity S_EVT_ACT, S_EVT_ACT_FNX
Assignment Group (Territory) S_ASGN_GRP, S_INSCLM_TERR
Claim Account S_INSCLM_ORG
Claim Appraisal S_INSCLM_APRSL
Claim Appraisal Attachment S_INSCLM_AP_ATT
Claim Contact S_INSCLM_CON, S_INSCLMCON_ORG
Claim Document S_INSCLM_DOC
Claim Element S_INSCLM_ELMNT
Claim File Attachment S_INSCLM_CL_ATT
Claim Payment S_SRCPAY_INSCLM
Claim Property S_INSCLM_PRPTY
Claim Recovery S_INSCLM_RECVRY
Contact S_CONTACT, S_PARTY, S_CONTACT_FNX
Default Coverage S_DEFAULT_ADMIN
Injury S_INSCLM_INJURY
Insurance Claim S_INS_CLAIM S_INSCLM_FRAUD S_INSCLM_SBRGTN S_INSCLM_UW
Insurance Policy S_ASSET
Insurance Policy Item S_INS_ITEM
Invoice S_INVOICE, S_INVC_PAYMENT
Invoice Line Item S_INVOICE_ITEM
Loss Code S_INS_LOSS_CODE, S_LOSSCD_PLNITM
177
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Loss Code Coverage S_INS_LOSCD_COV
Loss Event S_INSCLM_EVT
Organization S_ORG_EXT S_PARTY S_ORG_EXT_FNX
Party S_PARTY
Payment S_SRC_PAYMENT S_SRCPAYMT_CON S_SRCPAYMT_ORG S_INVC_PAYMENT
Position S_POSTN, S_PARTY
Reserve Code S_INS_RSRV_CODE
Service Request S_SRV_REQ, S_SRV_REQ2_FNX
Insurance Policies
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of insurance policies
and related insurance policy items. The major entities are insurance policy and insurance policy items. Insurance policies
relate to households as well as contacts. Policy coverages, discounts, payment plans, and claim summaries are also
supported.
178
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Claim Summary S_INS_CLAIM
Condition S_INSITEM_CNDTN
Contact S_CONTACT,S_PARTY
Discount S_APPLD_DISCNT
Drivers License S_DRVR_LICENSE
Household S_ORG_GROUP, S_PARTY
Household Contact S_GROUP_CONTACT
Insurance Coverages S_APPLD_CVRG
Insurance Document Item S_INS_DOC
179
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Insurance Policy S_ASSET
Insurance Policy Item S_INS_ITEM
Insurance Policy Item Account S_INSITEM_ACCNT
License Restriction S_DL_RSTRCT
Payment Plan S_PAY_PLAN
Policy Contact S_ASSET_CON
Life Insurance Policy
This ERD (see the following figure) illustrates how Siebel Financial Services supports generation of life insurance policies
and annuities as assets. Each asset can be owned by an organization or a number of contacts, and the owners can
specify the coverage and beneficiaries under the policy. The owner can execute a multitude of operations on the asset
such as transfers, payments, withdrawals, and surrenders.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
180
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Assessment S_ASSESS
Assessment Value S_ASSESS_VAL
Asset Contact S_ASSET_CON
Beneficiary S_FN_CVRG_ROLE
Beneficiary Class S_FN_BENFCLASS
Bill Account S_INS_BILLACCT
Coverage Option S_CVRG_OPTION
Financial Account S_ASSET
Financial Transaction S_FN_ACCNT_TXN
Financial Transfer S_FN_ASSET_TXFR
Holding S_FN_HLDNG
Insurance Claim S_INS_CLAIM
Insurance Coverage S_APPL_CVRG
Organization S_ORG_EXT, S_PARTY
Pay Plan S_PAY_PLAN
Person S_CONTACT, S_PARTY
Product S_PROD_INT
Service Request S_SRV_REQ
Withdrawal/Surrender S_PAYMT_REQ
181
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Loyalty
This ERD (see the following figure) illustrates how programs and promotions are created for customer loyalty. Partner
companies can have an association with a loyalty hosting company to create a loyalty program. A program is the highest
level entity in Siebel Loyalty. Members, tiers, promotions, point values, and so on are all specific to a single program. The
members of the loyalty program can be individuals, households or accounts. A loyalty member can accrue or redeem
points based on their individual transactions. Pricing rule, Pricing Range, Point Subtype, Incentive Choice, and Partner
Statement entities support enhancements to features such as Post-Paid and Pre-Paid Partnership Management,
Promotion Registration Service and so on.
Accrual, redemption, promotion, enrollment, member administration, partner administration and other functions are
described in more detail as follows:
• Accrual Processing. Allows unified partner point type for simplified billing. Accrual templates are used for
configurable transaction validations. Multiple partner debits for joint promotions enable cost sharing among
partners. User-defined controls and billing triggers are provided to manage partner point balance. Allows joint
rewards to benefit the organization for employee’s business transactions.
• Promotion. Supports range-based points calculation as well as issuing vouchers as an accrual reward.
Promotion criteria now includes product and partner attributes and leverages target lists of members linked to
marketing campaigns or generated using analytics.
• Redemption. Supports distance-based zones to support air redemption pricing used by some airlines and
carriers. Multiple currency and multiple modes of payment are allowed. Automated point loans can be assigned
to members with an insufficient balance for redemption, based on their tier status. Variable redemption pricing
enables member differentiation. OOTB business services support end-to-end redemptions from third-party
interfaces. A voucher-based redemption model supports service awards.
• Member Administration. Automated tier upgrades recognize member relationships. Tier assessment
enhancements support additional models like anniversary-based, fixed-date and rolling-period models.
Tier change approvals prevent key members from automatic downgrade of their membership status. Bulk
member administration facilitates effective service recovery through dynamic targeted rewards. User-defined
membership statuses manage the membership life cycle.
• Enrollment. The member data model has been enhanced for enriched analytics and segmentation. Batch
enrollment processing has been enabled for bulk member creation and pre- created memberships enable
instant member acquisition.
• Outbound Communication. Outbound communication will be triggered when certain events occur. Content is
now generated in XML format for compatibility with third-party fulfillment applications.
• Post-Paid and Pre-Paid Partnership Management. Supports both post-paid and pre-paid partnerships. Post-
paid partners are billed based on a pay-as-you-go basis. The bill frequency can be based on time or a threshold
value. Credit limits can be set for pre-paid partners; the partners cannot reward points to the members beyond
the limit. After the limit is reached, they have to reorder for points. Partner statements can be generated.
• Point sub-type related data-model enhancements. Point subtype information is captured to aid points
administration.
• Points Reactivation: Enables reactivation of points. Loyalty members’ point balances expire if not used for a
given expiration period. Upon request by a loyalty member, these points can be reactivated with some charges
applied to the member’s account.
• Gift Miles Service. Loyalty members are allowed to gift accrued points to other members.
• Promotion Registration Service. Incentive choices are available at the promotion level.
182
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
• Airport-Zone Map for Coterminal Identification. Tracks zone details of airports. Loyalty programs can use
zone details to allow members to accrue points based on zone travel.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Accrual Item S_LOY_ACRL_ITM
Accrual Item Detail S_LOY_ACRL_DTL
Accrual Template S_LOY_ACRL_RULE,S_ACRL_RULE_ITM
Activity S_EVT_ACT_LOYX
Attribute Definition S_LOY_ATTRDEFN
Bucket S_LOY_BUCKET
Hosting Company S_ORG_EXT
Household S_ORG_GROUP
Incentive Choice S_LOYPR_ICHOICE
Individual S_CONTACT
183
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Loan S_LOY_LOAN
Loyalty Program S_LOY_PROGRAM
Loyalty Program Member S_LOY_MEMBER
Loyalty Promotion S_LOY_PROMO
Loyalty Transaction S_LOY_TXN
Loyalty Transaction Log S_LOY_TXN_LOG, S_LOY_TXNEN_LOG
Membership Card S_LOY_CARD
Package Product S_LOY_TXN_ITEM
Partner Product Offering S_PGM_ORG_PROD
Partner Statement S_PROGORG_STMT
Partner Transaction S_LOY_PRT_TXN
Point Type S_LOY_ATTRDEFN
Point Subtype S_LOY_PTSUBTYP
Pricing Options S_LOY_PROD_PT
Pricing Rule S_LOY_PRI_RULE
Pricing Range S_LOY_PRI_RANGE
Product S_PROD_INT
Program Partner S_ORG_EXT, S_LOY_PROG_ORG
Purchase Transfer Limits S_LOY_PURTRN_LM
Redemption Activity S_LOY_RDM_ACT
Redemption Item S_LOY_RDM_ITM
184
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Service Product Association S_LOY_SRV_PROD
Statement S_LOY_STMT
Status Restriction S_LOY_MSTAT_PRF
Tier S_LOY_TIER
Tier Class S_LOY_TIER_CLS
Tier Reward S_LOY_REWARD
Travel Information S_LOY_TRVL_INFO
Voucher S_LOY_MEM_VCHR
Loyalty Flowchart and Formula
This ERD (see the following figure) illustrates how Loyalty Promotion flowcharts help to execute promotions in a
particular sequence. They can be used to validate the sequence of the promotions and calculate the points awarded for
a particular flow.
Loyalty Formulas are used to create and store a set of objects and operators specific to a loyalty program. Values
can be calculated based on input from third parties and then the resulting value can be taken into account within a
promotion. A formula can be available for use by a promotion only if it is associated with the same loyalty program as
that promotion. Once validated, a formula is available for use in promotion criteria and actions. When used in promotion
criteria and actions, the object is the formula and the attributes are a list of user-defined formulas.
185
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Attribute Definition S_LOY_ATTRDEFN
Loyalty Flow Connector S_LOY_FLW_CNCTR
Loyalty Flow Step S_LOY_FLOW_STEP
Loyalty Formula Step S_LOY_FRML_STEP
Loyalty Process Flowchart S_LOY_PROC_FLOW
Loyalty Program S_LOY_PROGRAM
Loyalty Program Formula S_LOY_PRG_FRML
Loyalty Promotion S_LOY_PROMO
Loyalty Promotion Phase S_LOY_PHASE_PRM
Program Partner S_ORG_EXT, S_LOY_PROG_ORG
186
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Managed Care
This ERD (see the following figure) illustrates how plan design, formulary, and formulary product are used in Siebel
Life Sciences. An account contains plan designs, which have relationships to contacts. Each plan design contains
formularies, which are associated with markets that are essentially products. Each formulary contains formulary
products, which are child products for the market with which the formulary is associated.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Formulary S_INSPLN_FRMLY
Formulary Product S_PLNFRMLY_PROD
Health Care Professional S_CONTACT, S_PARTY
Managed Care Plan S_INS_PLAN
Plan Design Contact S_INSPLAN_CON
Product, Market S_PROD_INT
187
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Medical Education Event Management
This ERD (see the following figure) illustrates the significant entities related to medical education events including plans,
subplans, funds, events, sessions, products, and team members (employees). Medical education event planning also
supports the allocation and aggregation of medical education budgets and expenditures for individual team members.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Event S_ME_EVT_LS
Event Invitee S_ME_EVT_INV_LS
Event Position S_ME_EVT_POS_LS
Fund S_MDF, S_ME_PLN_MDF_LS
188
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Literature S_ME_SES_LIT_LS
Material S_ME_SES_MAT_LS
Period S_PERIOD
Person S_CONTACT, S_PARTY
Plan S_ME_PLN_LS
Position S_POSTN, S_PARTY
Product S_ME_SES_PRD_LS, S_ME_EVT_PRD_LS, S_ME_PLN_PRD_LS, S_PROD_INT
Session S_ME_SES_LS
Session Invitee S_ME_SES_INV_LS
Objectives
This ERD (see the following figure) illustrates how the Siebel Consumer Goods application supports the objective
process as part of retail execution. The retail execution process begins with the creation of an objective. Objectives
are generated to help facilitate the process of accomplishing certain goals. This model shows that an objective can be
applied to many accounts, including accounts with multiple contacts. There are generally multiple activities that belong
to an objective, activities which require follow-through to help bring the objective to fruition. The objective must be
executed by personnel who are assigned to the objective, its accounts, and activities.
189
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_PARTY, S_ORG_EXT
Activity Details S_EVT_ACT
Contact S_PARTY, S_CONTACT
Objective S_SRC
Position S_POSTN
Oracle Policy Automation Integration
This ERD (see the following figure) describes the integration of Siebel CRM with an Oracle Policy Automation (OPA)
tool. Policy administrators can create policies in the OPA tool or they can access the same data-input forms seamlessly
through Siebel web services.
Interview Service is a web service exposed by OPA that interacts with other applications such as Siebel CRM
Applications. The Interview Service provides metadata about the data-input form.
190
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Session S_INTV_SES_INFO
Decision Report S_INTV_DCSN_RPT
OPA Rule Base S_INTG_RULE_VER
Interview S_INTV_MAP
Interview Attribute S_INTV_MAP_PRM
Personalized Content Delivery
The Personalized Content Delivery feature allows pharmaceutical sales representatives to deliver a sales communication
to general practitioners and medical specialists using multimedia visualizations. This ERD (see the following figure)
illustrates how a Message Plan is associated with Messages, Products Presentation Details and Party Entities such as
Account, Contact, Position and Business Unit.
191
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
ACCOUNT S_PARTY, S_ORG_EXT
ACTIVITY S_EVT_ACT, S_EVT_ACT_LSX
ASSESSMENT TEMPLATE S_TMPL_PLANITEM
BUSINESS Unit S_PARTY, S_BU
CONTACT S_PARTY, S_CONTACT
DECISION ISSUES S_ISS
MESSAGE S_LIT, S_LIT_LSX
MESSAGE PRODUCT APPLICATION S_LIT_PROD_APPL
MESSAGING Plan S_MSG_PLAN
MESSAGING Plan Item S_MSGPLAN_ITM
OBJECTIVE S_SRC
Offer S_DMND_CRTN_PRG
192
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Period S_PERIOD
Position S_PARTY, S_POSTN
PRESENTATION DETAILS S_PCD_DETAIL
PRODUCT S_PROD_INT
Public Sector Benefit Case Management
This ERD (see the following figure) illustrates how Benefit Case Management supports benefits determination and case-
information verification, specifically:
• Eligibility Determination. Provides the capability to develop benefits plans that allow caseworkers to
make eligibility changes in program rules that impact benefit disbursement while reducing the number of
overpayments. The feature provides the ability to submit individual or household profiles to a rules engine for
eligibility determination. Enhancements for Siebel 8.2 include Benefits Plan History, Lock Benefits, Reassess
Circumstances, and Payment History.
This ERD illustrates that a Benefit Plan is created under a Benefit Program that consists of one or more Benefit
Program Items. Benefit Program Items include one or more Products. A Benefit Plan also consists of Benefit
Plan Items that are associated with a Recipient, provided by a Provider and associated with a Product. This ERD
also shows that a Benefit Plan belongs to a Case and that a Case can have a Change of Circumstance which
might or might not be associated with a Benefit Plan.
• Effective Dating. Allows the application to capture, store and output change history for an effective-dating
enabled (ED-enabled) business component in terms of its field data as well as its relationship to other business
components. Using the change history, the system can reconstruct data for a given point in time. Effective
Dating is preconfigured for the Contact, Household and Income Business Components.
• Supporting Tasks. Helps a caseworker verify information during the intake process, where the caseworker uses
the Public Sector application to document that the information was verified, how verification was accomplished
and who verified the information. The caseworker performing quality assurance is presented with cases based
upon random selection, queued, or high-risk profiles.
As the ERD shows, a Case Verification Template is associated with a Case and can consist of one or more Case
Verification Items. The Case Verification Template Items can be associated with a submitter and a verifier. This
feature can also help a quality-assurance worker review cases following a checklist for adherence to standards
and ensuring that each case is reviewed in the same way.
193
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
ACCOUNT S_PARTY, S_ORG_EXT
ACTIVITY S_EVT_ACT
Benefit Plan S_CASE_BNFTPLAN
Benefit Plan Item S_BNFT_PLAN_ITM
Benefit Plan Item Payment S_SRC_PAYMENT
Benefit Program S_BNFT_PGM
Benefit Program Item S_BNFT_PGM_ITM
Case S_CASE, S_CASE_PSX
Case VERIFICATION Item S_ASSESS_ATTRIB
Case VERIFICATION TEMPLATE S_TMPL_PLANITEM
CHANGE OF CIRCUMSTANCE S_CASE_CHGOFCCM
CONTACT S_PARTY, S_CONTACT
194
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Party S_PARTY
Product S_PROD_INT
Quality Assurance Items S_ASSESS_ATTRIB
Quality Assurance TEMPLATE S_TMPL_PLANITEM
User S_PARTY, S_CONTACT, S_USER
Public Sector Case Lead Management
This ERD (see the following figure) illustrates how an investigative lead is related to incident and case. It shows how
a party, such as a person, organization, or group, becomes involved in the investigative lead, and the positions of
team members assigned to work on it. This ERD also shows evidence/supporting documentation as the trigger of the
investigative lead. The physical object used, location of the investigative lead, as well as the related activity, disease,
and service request are shown. This ERD covers the features of applications received from users and their supporting
documents as well as their visibility to various organizations.
New features in 8.1 include:
• Submitted applications are reviewed on the Siebel side and information uploaded from the applications into
Siebel objects such as case and contacts.
• Applications received from users/citizens for benefits, visa, immigration, and so forth are taken into account.
The supporting documents for a given application, as well as any scanned images of the application, are stored
in file systems. The visibility of an application to various organizations is also managed.
• Data from the application form, as filled out by the citizen or employee, is transferred to the Siebel application
so that the agency has a historical record of the data as submitted at that point in time. Employees will then
upload the application into the system. During the upload process, relevant data from the form(s) is imported
into the appropriate Siebel contact, household and case records.
195
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
INVESTIGATIVE CASE LEAD S_CASE_LEAD
PARTY S_PARTY
PERSON S_CONTACT, S_USER, S_CONTACT_PSX
ORGANIZATION/GROUP S_ORG_EXT, S_ORG_GRP_PSX
POSITION S_POSTN
ADDRESS S_ADDR_PER
SERVICE REQUEST S_SRV_REQ
ACTIVITY S_EVT_ACT
CASE S_CASE, S_CASE_PSX
PHYSICAL OBJECT S_ASSET
DISEASE S_DISEASE
EVIDENCE/SUPPORTING DOCUMENT S_EVIDENCE
196
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
INCIDENT S_INCIDENT
PERSON DESCRIPTION S_SUBJECT
APPLICATION S_PS_APPL
APPLICATION ATTACHMENT S_PS_APPL_ATT
APPLICATION/BUSINESS UNIT VISIBILITY S_PS_APPL_BU
Public Sector Child Welfare
The Child Welfare feature addresses the intake and case management needs of social service agencies working to
provide child welfare services. Intake, Screening Decision, Assessment Management, Court Processing Interface, and
Service Plan Creation functions are included. As the ERD (see the following figure) depicts, a Case can have one or
more Incidents and one or more Benefit Plans. An Incident can have multiple Assessments, can be approved by one or
more Positions, can have one or more Contacts and uses an Approval Template. An Incident can also have one or more
Allegations that can be allegations on one or more Contacts associated with the Incident. A Benefit Plan can have one or
more Court Hearings and a Court Hearing can have one or more Court Decisions.
The following table lists the entities in this ERD and their corresponding tables.
197
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Allegation S_ALLEGATION
Approval Template S_APPR_TEMPLATE
Assessment S_ASSESS
Benefit Plan S_CASE_BNFTPLAN
Case S_CASE, S_CASE_PSX
Contact S_CONTACT, S_PARTY
Court Decision S_COURT_DECISN
Court Hearing S_EVT_ACT
Incident S_INCIDENT
Position S_POSTN, S_PARTY
Service Plan S_CASE_BNFTPLAN
Time Sheet S_TMSHT
Time Sheet Item S_TMSHT_ITEM
Time Sheet Line S_TMSHT_LN
Public Sector Contact Identity
Public Sector Contact Identity (see the following figure) allows you to track the identity of an individual, including
personal attributes, marital status changes, place of residence, and so on over time so that the responsible organization
can react swiftly to the legality of the individual. Public Sector Contact Identity also tracks the entry and departure
information of the individual into and out of the country. Public Sector Contact Identity is used mainly for the purposes
of homeland security.
198
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
IDENTITY S_PS_IDENTITY
CREDENTIAL S_PS_CREDENTIAL
STAY S_PS_STAY_LOG
PUBLIC SECTOR CONTACT S_PS_CONTACT
ORGANIZATION/GROUP S_ORG_EXT, S_BU
PARTY, CONTACT S_PARTY, S_CONTACT
Public Sector Evidence Management
This ERD (shown in the following figure) illustrates how evidence and supporting documents are related to the incident
and case and acts as the trigger of the investigative lead. It shows how a party, such as a person, organization, or group,
is included in the evidence and supporting documents. The ERD describes the positions of team members assigned to
handle the incident and approve the documents. This ERD also shows how the items are supported by the documents.
The location of the incident, physical object used in the incident, as well as the activity and service request related to the
evidence are shown.
199
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
EVIDENCE/SUPPORTING DOCUMENT S_EVIDENCE
PARTY S_PARTY
PERSON S_CONTACT, S_USER
ORGANIZATION/GROUP S_ORG_EXT
POSITION S_POSTN
ADDRESS S_ADDR_PER
PHYSICAL OBJECT S_ASSET
QUOTE ITEM S_QUOTE_ITEM
ORDER ITEM S_ORDER_ITEM
QUOTE S_DOC_QUOTE
ORDER S_ORDER
200
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
SERVICE REQUEST S_SRV_REQ
ACTIVITY S_EVT_ACT
INVESTIGATIVE LEAD S_CASE_LEAD
INCIDENT S_INCIDENT
CASE S_CASE
Public Sector Incident Management
This ERD (see the following figure) illustrates how an incident is related to investigative lead and case. It shows how
a party, such as a person, organization, or group, becomes involved in the incident in different roles such as victim,
offender, witness, suspect, or owner of the incident. It includes the offense committed and any arrest initiated by the
incident or case. The physical object used in the offense, arrest, and incident, as well as the activity and the service
request related with the incident, are also shown.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
INCIDENT S_INCIDENT
201
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
PARTY S_PARTY
PERSON S_CONTACT, S_USER
ORGANIZATION/GROUP S_ORG_EXT
INCIDENT ACCOUNT S_INCIDNT_ACCNT
INCIDENT CONTACT S_INCIDENT_CON
INJURY S_INCTCON_INJRY
INCIDENT VICTIM TYPE S_INCDNT_VCTMTP
CIRCUMSTANCE S_CIRCUMSTANCE
SERVICE REQUEST S_SRV_REQ
ACTIVITY S_EVT_ACT
INVESTIGATIVE LEAD S_CASE_LEAD
CASE S_CASE
PHYSICAL OBJECT S_ASSET
ARREST S_ARREST
ARREST FORCE S_ARREST_FORCE
OFFENSE S_OFFENSE
OFFENSE CRIMINAL ACTIVITY S_OFFENSE_ACT
Public Sector Service Provider and Referral Management
The Service Provider and Referral Management feature allows social service agencies to locate service providers and
manage the referral process. Features include Service Provider Information Management, Service Provider Contract
202
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Management, Service Provider Transaction Management, Service Provider Portal, Service Provider Portal Resource and
Inventory Control, Service Provider Locator, Service Provider Referral and Benefits Administration.
This ERD (see the following figure) illustrates that Service Providers can have a Profile, be the subject of Contracts and
own Assets. Contracts consist of Contract Items for Products that are made into Asset instances. Benefit Plans with
Benefit Plan Items can be associated with a Case. Benefit Plan Items are also associated with a Product and a Service
Provider who provides the Benefit. A Benefit Plan is created under a Benefit Program that consists of Benefit Program
Items. Each Benefit Plan Item is associated with a Product and can have one or more Orders (created as part of Referral)
that are serviced by Service Providers and are composed of Order Items. Order Items are associated with the Product,
which is also associated with the related Benefit Plan Item.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Benefit Fund S_BNFT_FUND
Benefit Plan S_CASE_BNFTPLAN
Benefit Plan Item S_BNFT_PLAN_ITM, S_BNFT_PLNIT_XA
Benefit Plan Item Payment S_SRC_PAYMENT
Benefit Program S_BNFT_PGM
Benefit Program Item S_BNFT_PGM_ITEM
Case S_CASE, S_CASE_PSX
203
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Contract Header S_DOC_AGREE
Contract Item S_AGREE_ITEM
Internal Product or Service S_PROD_INT
Order S_ORDER, S_ORDER_PSX
Order Line Item S_ORDER_ITEM
Other Organization S_ORG_EXT, S_PARTY
Party S_PARTY
Service Provider Profile S_ORG_EXT_ATTR, S_ORG_EXT_LANG
Service Provider S_ORG_EXT, S_ORG_EXT_PSX, S_PARTY
Real-Time Scheduler Integration
In a typical field service scenario, technicians are sent to a customer's location to do a job such as performing an
installation, upgrade, or repair. Real-Time Scheduler is an external application that performs the scheduling ERD (see
the following figure for an example). Scheduling involves matching an available service technician with a job or service
request. Each job includes a set of necessary skills. For example, installation of a set-top box might require a skill, such
as training in electrical wiring. Each technician has a distinct set of skills. The job of the scheduler is to find the best
technician who is available and has the necessary skills to perform the job.
The following information is mastered and stored in the Siebel application:
• Technician details (name, phone number, and so on.)
• Technician schedule and availability
• Technician skill set
• Job details
• Job skills (skills required to accomplish the job)
• Service requests for jobs
Real-Time Scheduler can use this information to prepare a schedule that contains a timetable for each technician. To
enable this, the Siebel application must use the Real-Time Scheduler Web service to pass the skills needed to do the job
to the Real-Time Scheduler.
204
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Address S_ADDR_PER
Buscomp S_BUSCOMP
Buscomp Field S_FIELD
Business Object S_BUSOBJ
Resource Scheduler Rule Criteria Value S_RS_CRIT_VAL
Resource Scheduler Object Link S_RS_OBJ_LNK
Resource Scheduler Object Link Relation S_RS_OBJLNK_REL
Resource Scheduler Skill Rule Criteria S_RS_RULE_CRIT
Resource Scheduler Rule Definition S_RS_RULE_DEF
Resource Schedule Item S_RS_SCHD_EVENT
Resource Scheduler Skill Item S_RS_SKILL_ITM
Resource Scheduler Skill Set S_RS_SKILL_SET
Technician S_USER
205
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Routes and Best Call Hours
This ERD (see the following figure) illustrates how the Siebel Consumer Goods application supports the use of best call
hours in the context of retail execution. Simply stated, each external organization or retailer, is part of one or multiple
routes which are predefined logical groupings of stores. These routes exist for the purpose of facilitating the visit
execution of a mobile field force. To coordinate the most logical order in which these external organizations should be
visited, each includes a coordinating best call hour that specifies the time(s) at which the retailer should be visited.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Best Call Hour S_BEST_CALL_HRS
Organization External S_ORG_EXT, S_PARTY
Route S_ACCNTRT
Sales Volume Planning
This ERD (see the following figure) illustrates how Siebel Business applications (Consumer Goods) support sales
volume planning (SVP). A sales volume plan is the targeted sales volume (cases or currency) for a period. This volume
206
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
is calculated based on historical data within a period. Algorithms used to calculate the SVP could be a flat percentage
change over a period, or it could be a trended volume. While planning, an authorized employee can allocate down an
account, or an account product category tree. Prior to allocating, historical data must be aggregated up these trees.
After the initial aggregation, allocation and aggregation can occur any number of times until the plan is committed or
until historical data within the plan's period is entered into the application.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Authorized Product S_ORG_PROD
Authorized Product Detail S_ORG_DIST_LST
Category S_CTLG_CAT
Category Baseline S_CG_CAT_BASELN
Consumption Category S_CG_CAT_CONSUM
Employee S_CONTACT, S_PARTY
External Organization S_ORG_EXT, S_PARTY
Internal Product S_PROD_INT
Marketing Event S_SRC
Period S_PERIOD
Planned Volume S_PROD_BASELINE, S_CG_CAT_BASELN, S_PROD_TARGET, S_CG_CAT_TARGET
207
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Product Baseline S_PROD_BASELINE
Product Consumption S_PROD_CONSUME
Product Line S_PROD_LN
Product Shipment S_PROD_SHIPMENT
Product Target S_PROD_TARGET
Sales Volume Planning Action S_CG_SVP_ACTION
Shipment Category S_CG_CAT_SHIP
Target Category S_CG_CAT_TARGET
Sample Management
This ERD (see the following figure) illustrates how product samples can be tracked in inventory. Inventory is for a
particular employee and for a specified period. All transactions involving samples such as disbursement, shipments, and
sample orders can be tracked and each active inventory period can be reconciled after a physical inventory count.
Use of samples for product promotion by pharmaceutical companies around the world is governed by local country
legislation. The Life Science Sampling, Sample Management and Compliance feature details requirements for sample
management and compliance processes in a pharmaceutical company to ensure that the company’s processes
comply with regulations. Sample Audit and Compliance Administration functionality enables companies to adhere to
government guidelines.
208
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Audit Report Attachment S_INVADTRPT_ATT
Call S_EVT_ACT
Contact S_CONTACT, S_PARTY
Employee S_EMP_PER, S_CONTACT, S_PARTY
Internal Product S_PROD_INT
Inventory Audit Report S_INV_AUDIT_RPT
Order Item S_SMPL_TXN_ITEM
Person S_CONTACT, S_PARTY, S_USER
Product Inventory S_STOCK_EMP
Sample Order S_SAMPLE_TXN
Sample Transaction S_SAMPLE_TXN
Sample Transfer S_SAMPLE_TXN
209
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Signature Audit S_EMP_AUDITSIGN
Stock Period S_STK_PERD_EMP
Transaction Attachment S_SMPL_TXN_ATT
Transaction Item S_SMPL_TXN_ITEM
Transfer Item S_SMPL_TXN_ITEM
Validation Result S_VALDN_RESULT
Special Rate List
Special Rate List (see the following figure) is a list of phone numbers, country codes, area codes, and so on, to be
used for special rates in telephone rate plans. This list is defined for a telephone user account in the communications
industry. This special rate list is subsequently used in quotes and orders for the customer in relation to the telephone
owned by the customer.
210
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Asset S_ASSET
Order Item S_ORDER_ITEM
Quote Item S_QUOTE_ITEM
Special Rate List S_SPL_RATE_LST
Special Rate List Item S_SPL_RATE_ITEM
211
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Syndicated Data
This ERD (see the following figure) illustrates how the syndicated data (sales and prescription information) is associated
with a period, plan, account, contact, postal code, territory, and area.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT, S_PARTY
Contact S_CONTACT, S_PARTY
Period S_PERIOD
Plan S_INS_PLAN
Position S_POSTN, S_PARTY
Postal Code S_ZIPCODE
Product S_PROD_INT
Region S_REGION
Syndicated Data S_SYND_DATA
212
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Territory S_ASGN_GRP
Teller Administration
This ERD (see the following figure) illustrates how Siebel Financial Services supports the administration of a tellers
activities at a financial institution branch. A set of employee, transaction, and container limits are defined for each
branch, as well as a multiple containers. Each teller is associated with a set of containers, where they execute different
activities and service requests for the customer.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Activity S_EVT_ACT
Activity Batch S_FN_ACT_BATCH
Activity Settle S_FN_ACT_SETTL
Bait S_FN_BAIT
Contact S_CONTACT, S_PARTY
Container S_FN_CONTAINER
213
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Container Limits S_FNCONTNR_LMTS
Employee S_EMP_PER, S_CONTACT, S_PARTY
Employee Teller Limits S_EMP_TLR_LMTS
Holdover S_FN_TXN_HLDVR, S_FN_HLDVR_CTF
Organization Unit S_ORG_EXT, S_PARTY
Person S_CONTACT, S_PARTY
Service Request S_SRV_REQ
Transaction Limits S_FN_TXN_LMTS
Territory Alignment–Quota Assignment
This ERD (see the following figure) shows how to set up territory alignment to determine whether the results of quota
assignments are as expected. It covers assigning quotas to alignments, breaking these assignments down by contacts,
accounts, regions, or ZIP codes and changes included in a given alignment.
The following table lists the entities in this ERD and their corresponding tables.
214
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Sales Quota S_SLS_QUOTA
Territory S_TERRITORY
Alignment Terr Quota S_ALGN_QTA_TERR
Alignment Terr/Qta Breakdown S_ALGN_QT_BRKDN
Period S_PERIOD
Alignment Quota S_TERRALGN_QTA
Territory Alignment S_TERRALGN
Contact/Terr Mapping Change S_TERRALGN_CON
Con/Quota Change S_ALGN_QTA_CON
Account/Terr Mapping Change S_TERRALGN_ACCT
Accnt/Quota Change S_ALGN_QTA_ACCT
Geo/Terr Mapping Change S_TERRALGN_REGN, S_TERRALGN_ZIP
Territory Management - Consumer Sector
This ERD (see the following figure) shows how multiple representatives can call on the same account to carry out
different roles on a regular basis. The Territory Management module within Siebel Consumer Goods supports a system
for creating territories and modifying them to meet the needs of the consumer goods industry.
215
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
Account Team Member S_ACCNT_POSTN
Account Team Role S_ACCNT_POSROLE
Account/Terr Mapping S_TERR_ACCNT
Activity S_EVT_ACT
Business Unit S_BU
Catalog Category S_CTLG_CAT
Contact S_CONTACT
Contact Team Member S_POSTN_CON
Contact/Terr Mapping S_TERR_CON
Division S_ORG_EXT
Position S_POSTN
216
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Position Territory Assignment S_TERR_POSITION
Position Role (LOV type TERR_POSITION_ROLE)
Territory S_TERRITORY
Territory Hierarchy S_TERR_HIER
Territory Position Role S_TERR_POS_ROLE
Territory Version S_TERRHIER_NODE
Territory Management - Life Sciences
For Life Science companies, a key business process is territory alignment (sales force alignment). This ERD (see the
following figure) illustrates how territory alignments can be defined encompassing territories, sales representatives,
business rules, territory roll-ups, and so on. Historical alignments can be maintained for reference and comparison.
Future alignments can be staged and analyzed concurrently, thus facilitating simultaneous evaluation of multiple
strategies for a sales force.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Account S_ORG_EXT
217
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Account/Terr Mapping Change S_TERRALGN_ACCT
Asset S_ASSET
Asset/Terr Mapping Change S_TERRALGN_AST
Business Unit S_BU
Contact S_CONTACT
Contact/Terr Mapping Change S_TERRALGN_CON
Division S_ORG_EXT
Geo/Terr Mapping Change S_TERR_REGION, S_TERR_ZIP
Position S_POSTN
Position Territory Assignment Change S_TERRALGN_PSTN
Region S_REGION
Territory S_TERRITORY
Territory Alignment S_TERRALGN
Territory Alignment Condition S_TERRALGN_COND
Territory Hierarchy S_TERR_HIER
Territory Version S_TERRHIER_NODE
Zipcode (None)
Universal Customer Master
This ERD (see the following figure) illustrates how Universal Customer Master works with external applications and
the Siebel application. This ERD also shows the UCM engine schematics including the survivorship rule set and its
218
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
relationship with repository-based information, UCM objects, and operations such as deduplication, merge, and history
of changes.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Attribute Group S_UCM_ATGP
Attribute Group Field Mapping S_UCM_ATGP_FLD
Attribute Group Rule S_UCM_ATGP_RULE
Attribute Group Update History S_UCM_CON_ATGP, S_UCM_ORG_ATGP, S_UCM_OGP_ATGP
Confidence Level S_UCM_CONF_LVL
Contact Additional Name S_CONTACT_NAME
Contact Identity S_CON_IDNTY_DOC
External Information System S_CIF_EXT_SYST
External Information System Mapping S_CIF_CON_MAP, S_CIF_ORGRP_MAP, S_CIF_ORG_MAP
External System Privilege S_CIF_SYS_DTL
219
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Named Hierarchy S_DYN_HRCHY
Named Hierarchy Account S_DYN_HRCHY_REL
Rule Set S_UCM_RULE_SET
UCM Address S_UCM_ADDR_PER
UCM Asset S_UCM_ASSET
UCM Child Object S_UCM_CON_CHILD, S_UCM_OGP_CHILD, S_UCM_ORG_CHILD
UCM Decay Indicator S_UCM_CON_DECAY, S_UCM_ORG_DECAY
UCM Deduplication S_UCM_DEDUP
UCM Merge Association S_UCM_MRG_ASSOC
UCM Merge History S_UCM_CON_MERGE, S_UCM_ORG_MERGE, S_UCM_ORGRP_MRG
UCM Merge Request S_UCM_MERGE_REQ
UCM Named Hierarchy S_UCM_HRCHY
UCM Named Hierarchy Account S_UCM_HRCHY_REL
UCM Object S_UCM_CONTACT, S_UCM_ORG_EXT, S_UCM_ORGGRP
UCM Party Ext S_PARTY_UCMX, S_CONTACT_UCMX
UCM Privacy S_UCM_PRIVACY
UCM Social Media Profile of Contacts S_UCM_CN_SMPROF, S_CONSMPROF_UPD, S_CIF_SMPROFMAP
UCM Social Media Profile Attribute of S_UCM_CN_SMATTR, S_CIF_SMATTRMAP
Contacts
220
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Vehicle
This ERD (see the following figure) illustrates how Siebel Automotive tracks the configuration and relationships
associated with a vehicle. Vehicles represent a physical asset based on a product that can be related to one or more
contacts, organizations, accounts, and positions. In addition to the attributes inherited from the product upon which it is
based, a vehicle can also have one or more options (also products) associated with it. A vehicle's sales history, financial
detail, service history and service requests can be tracked through its life cycle.
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Contact S_CONTACT, S_PARTY
Dealer S_ORG_EXT, S_PARTY
221
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Features S_PROD_SPEC
Financial Detail S_VHCL_FIN_DTL
Installed Option S_ASSET_REL
Option S_PROD_REL
Position S_POSITION, S_PARTY
Product S_PROD_INT
Product Features S_PROD_SPEC
Sales History S_VHCL_SALES
Service History S_VHCL_SRV
Service Request S_SRV_REQ
Specifications S_PROD_SPEC
Vehicle S_ASSET, S_ASSET_ATX
Vehicle Product S_PROD_INT
Vehicle Collection
This ERD (see the following figure) illustrates how the Siebel application helps an automotive captive finance company
deploy collections processes. Relevant information includes that a customer's car can be impounded by a government
agency, or a customer might abandon the car during the life cycle of vehicle ownership. Captive Finance allows the
capture of multiple promises to pay (PTPs) for a given account. When the customer breaks a promise to pay, a Service
Request is created for an impound, a repossession, or a cure process.
222
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Bankruptcy S_BANKRUPTCY, S_BK_PARTY
Service Request S_SRV_REQ, S_SRV_REQ1_FNX
Promise to Pay S_CF_PTP
Party S_PARTY, S_ORG_EXT, S_CONTACT, S_USER
Asset, Financial Account S_ASSET
Vehicle Insurance S_CF_INSURANCE
Vehicle Financing
Asset financing (see the following figure) refers to the niche area of capital financing where an asset is converted into a
working cash flow in exchange for a security interest in the asset. For example, an auto dealer might offer a customer
a lease option, where the customer pays a fixed monthly charge in exchange for using the vehicle for a predetermined
period of time. In this form of leasing, the lessee has the right to use the vehicle, but does not own the vehicle. The
lessee pays an up-front cost and pays monthly payments to get the right to use the vehicle. At the end of the lease,
the lessee usually has several options: to buy the vehicle or pay the end-of-lease cost and walk away. The lessor must
now deal with remarketing the vehicle. The lessor can lease it to another lessee or auction the vehicle to dealers or
consumers.
223
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
The following table lists the entities in this ERD and their corresponding tables.
Entity Table
Asset S_ASSET
Contract S_DOC_AGREE
Financial Account S_ASSET
Financial Account State S_FN_ACCNT_STAT
Historical Auction Price S_VHCL_AUC_REF
Historical FMV Price S_VHCL_FMV_REF
Historical Residual Value S_VHCL_RSDL_REF
Product S_PROD_INT
Service Request S_SRV_REQ
Vehicle Consignment S_VHCL_CNSGNMNT
Vehicle Consignment Details S_VHCL_CNSGNDTL
Vehicle Consignment Fees S_VHCL_CNSGNFEE
224
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Entity Table
Vehicle FMV S_VHCL_FMV
Vehicle Inspection S_VHCL_INSPCTN
Vehicle Inspection Charges S_VHCL_INSPCHRG
Vehicle Option at Lease S_FNACC_AST_OPT
Vehicle Title Log S_VHCL_TITLELOG
Vehicle Turn In S_VHCL_TURN_IN
Vehicle Sales
This ERD (see the following figure) illustrates the vehicle sales process at automotive dealerships. A prospective buyer
could come into a dealership as a result of a marketing activity by the dealership such as an advertisement campaign,
direct mailer, and so on. This could result in an opportunity to sell a vehicle to the prospective buyer. A showroom log
entry is created by a sales representative to record the visit of the prospective buyer. The sales representative could
call and pursue the opportunity with the prospect. If the vehicle is sold, the sale is recorded with the team of sales
representatives involved in the sale. The sale data could be made visible to affiliated dealerships.
The following table lists the entities in this ERD and their corresponding tables.
225
Siebel Chapter 2
Data Model Reference Guide Siebel Logical Model
Vehicle Sales ERD Entities and Tables
Entity Table
Contact Access Log S_CON_ACCSS_LOG
Employee S_EMP_PER, S_CONTACT, S_USER
Marketing Event or Activity S_SRC
Opportunity S_OPTY, S_OPTY_ATX
Organization S_ORG_EXT, S_BU
Person S_CONTACT, S_CONTACT_ATX, S_CONTACT_BU
Showroom Log Entry S_COMM_LOG
Vehicle S_ASSET, S_ASSET_ATX
Vehicle Sale S_VHCL_SALES, S_VHCL_SALES_BU, S_VHCL_SALE_EMP
226
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
3 Siebel Physical Model
Siebel Physical Model
This chapter describes the Siebel physical model, which encompasses the tables, their columns, and their indexes. It
covers the following topics:
• Data Model Naming Conventions
• Data Model Type Definitions
• Columns of Numeric Physical Type
• Siebel System Fields
• INTEGRATION_ID Columns
• Include Only Field
• Siebel Repository
• Database Schema Version
• Limit Checking for Data Types
• Validating the Siebel Schema
• Party Model Unifies Access to Data
• Generating a Report about Tables
Data Model Naming Conventions
This topic describes the following conventions:
• Table Naming Conventions
• Index Naming Conventions
• Column Naming Conventions
• Abbreviations Used in the Physical Model Listings
Table Naming Conventions
Tables in the Siebel database use a three-part naming convention. The syntax is: PREFIX_NAME_SUFFIX.
PREFIX Table names in Siebel Business Applications have a one- to three-letter prefix (EIM_, S_, W_, and so on)
to distinguish them from other tables in your application.
NAME A unique table name that is generally an abbreviation of the entity supertype name.
SUFFIX A supertype name can be followed by the entity subtype. For example, the supertype EVT (event)
includes ACT (activity) as one of its subtypes. Thus, the name becomes S_EVT_ACT.
227
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
The prefix indicates the part of the Siebel schema to which a table belongs. The following table provides some of the
prefixes and their descriptions.
Prefix Meaning
EIM_ Interface tables for Siebel Enterprise Integration Manager.
S_ Siebel base table. (Exception: Tables with names of the form S_<name>_IF are obsolete interface
tables.)
W_ Oracle Business Analytics Warehouse table, described in Oracle Business Analytics Warehouse Data
Model Reference.
The suffix indicates a table type. The following table provides some of the suffixes and their descriptions.
Suffix Meaning
_ATT File attachment table.
_REL A table that supports a many-to-many relationship from an entity back to itself.
_SS A table that stores Siebel-to-Siebel integration information.
_V A table that represents a database view.
_X One-to-one extension table, available for customers to add attributes to the Siebel database.
_XA A table that stores extended attributes associated with an object class.
_XM One-to-many extension table, available for customers to add attributes to the Siebel database.
Index Naming Conventions
Indexes are named the same as the table on which they are created plus a one-character to four-character suffix, see
the following table.
228
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Suffix Value Unique or Not
Unique
_F# Foreign key index. Not unique
_II Index on INTEGRATION_ID columns that are used for integrating Siebel Business Not unique
Applications with back-office applications.
_P# Primary key index. Unique
_U# Primary key index of the user. Unique
_V# Special routing visibility rule index; usually on primary child foreign key and system Not unique
foreign key columns not ordinarily indexed (for example, primary address, primary
contact, creator, and so on).
_M# Miscellaneous index. Any index that does not fit into one of the previous categories. Not unique
CAUTION: Before modifying or deleting indexes, create a service request (SR) on My Oracle Support. Modifying
or deleting indexes can negatively affect the performance of Siebel Business Applications and can render the
applications unusable. Alternatively, you can phone Global Customer Support directly to create a service request or
get a status update on your current SR.
Column Naming Conventions
Suffixes are used to indicate columns that must contain specific values. The following table shows the standard suffixes
for column names and their possible values.
Suffix Value
_AMT This column contains a currency amount.
_CD The column value is based on the contents of the List of Values (LOV).
_DT This column contains a date or datetime value.
_FLG This column contains a Boolean value where Y indicates Yes or True; N indicates No or False.
_ID This column contains ROW_ID values.
_NUM This column contains a number or an identifying alphanumeric value.
_TEXT This column contains text data.
229
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Suffix Value
_TM This column contains a time value.
_TS This column contains a timestamp value.
Abbreviations Used in the Physical Model Listings
Descriptions that appear in the physical model listings might use the abbreviations, see the following table.
Abbreviation or Phrase Meaning
fk Foreign key; a column that references a primary key of another table.
pk Primary key; the unique row identifier of a table.
SEA Siebel Enterprise Applications.
Siebel System Field One of theSiebel Enterprise Applications system fields described in the table in topic Siebel System
Fields.
Data Model Type Definitions
This topic contains the following type definitions:
• Table Type Definitions
• Table Status Definitions
• Column Type Definitions
• Domain Type Definitions
Table Type Definitions
The following table provides descriptions of the types of tables in the Siebel database.
Table Type Description
Data (Intersection) Data (Intersection) tables contain application or end-user data. An intersection table implements a
many-to-many relationship between two data tables. The name of an intersection table is usually
composed by concatenating the two table names, abbreviated if needed. For example S_OPTY_POSTN
230
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Table Type Description
is the intersection table between tables S_OPTY and S_POSTN. Intersection tables cannot be extended
using extension tables, but can be extended using extension columns, subject to database restrictions.
Data (Private) Data (Private) tables contain application administration or system data. Private tables cannot be
extended using extension tables or extension columns.
Data (Public) Data (Public) tables contain application or end-user data. Public data tables can be extended using
extension tables and, subject to database restrictions, extension columns.
Database View Database View objects appear as tables with regular columns. These tables represent database views.
Objects of this table type are not created by the ddlimp Siebel database utility. Underlying views are
created by SQL scripts during install and upgrade.
Dictionary S_APP_VER is the only table in this category. This table has only one row and contains information
about the application such as major and minor version, application name, unicode flag, and so on. This
table contains information about the data dictionary.
Extension Extension tables implement a one-to-one relationship with a data table to provide additional columns
to the data table. These tables are named with an _X suffix and contain generic columns with the
ATTRIB_ prefix, which are useful to define customized fields in a business component. These tables
can be further extended using extension columns, subject to database restrictions.
Note that there are also tables that implement a many-to-one relationship to a data table. Those tables
have an _XM suffix and their columns have generic names with the ATTRIB_ prefix. However, they are
not considered extension tables. Their type is Data (Public).
Extension (Siebel) Extension (Siebel) tables also implement a one-to-one relationship with a data table to provide
additional columns to the data table. However, these columns are configured in advance in Siebel
Business Applications. Do not use extension tables for any other purpose. These tables can be
extended using extension columns, subject to database restrictions, but cannot be extended through
extension tables.
External External tables are tables that reside outside the Siebel database. The Siebel object manager provides
some support for accessing data in these tables through business components. In Siebel Tools, the
Table object type includes properties that support external tables.
Interface Interface tables are EIM tables, which are used when moving data between the Siebel application and
external applications.
Log Log tables are used to log events. There are three Log tables: S_DCK_INST_LOG, S_PROC_INST, and S_
PROC_INST_LOG.
Repository Repository tables contain information about the Siebel Repository. Data in some of these tables might
be compiled into the Runtime Repository.
Virtual Table Virtual tables represent database tables or data in an operating system file that resides outside the
Siebel database. Virtual business components are defined on these tables.
Warehouse Warehouse tables are used byOracle Business Analytics in theOracle Business Analytics Warehouse
table. These tables have names starting with 'W_'.
231
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Note: Tables of the following types: Data(Public), Data(Intersection), Extension(Siebel), and Extension are designed to
hold user data. These tables, as well as some of their columns, are occasionally marked as obsolete in the comments
whenever they are no longer used by the current version of Siebel Business Applications. The status of the table or
column indicates the support that will be provided for it in future versions of the Siebel database schema, see the
following table.
Table Status Definitions
The following table provides descriptions of the types of table status in the Siebel database.
Table Status Description
Active Actively used and supported in Siebel Business Applications.
Inactive Dropped or removed from Siebel Data Model and no longer supported. Customers must remove every
reference to these tables or columns in their configurations.
EOL End of Life. Supported as is in this release but will be dropped in a future release of Siebel Business
Applications. Use alternate active tables or columns.
Not Used Not currently used by Siebel Business Applications, but might be used by customers.
Column Type Definitions
The following table provides descriptions for the types of columns in the Siebel database.
Column Type Description
Data (Public) This is the general type for most columns.
Denormalized This is the type for a column that holds a value denormalized from another column. Denormalized
columns are only supported in special situations and cannot be added as part of customization.
Extension These are columns that belong to an extension table or extension columns in a base table. Those
columns are used to define customized fields in a business component.
System This is the type for System Fields, which are described in the following table.
232
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Domain Type Definitions
The following table provides descriptions for the domain types of certain columns in the Siebel database.
Domain Meaning Domain Contains
Type
FK Foreign Key column The name of the table referenced by this Foreign Key column.
PC Primary Child The name of the table in which the Primary Child is found. For example, an account
(S_ORG_EXT) can be associated with multiple industries (S_INDUST) through the
intersection table S_ORG_INDUST. One of these industries is the primary industry
of the account: column S_ORG_EXT.PR_INDUST_ID points to the foreign key
column INDUST_ID of the primary child table S_ORG_INDUST (the column S_ORG_
INDUST.INDUST_ID is a foreign key to the base table S_INDUST and so it points to
S_INDUST.ROW_ID).
LOV List of Values The intended List of Values type for this column. List of values types are defined
in the table S_LST_OF_VAL accessible through Siebel Tools: Screens > System
Administration > List of Values.
LOVB List of Values Bounded The List of Values type against which this column is validated. In the LOVB case,
end users must specify a value from the list, whereas in the LOV case, the user can
enter a value not contained in the list.
MLOV Multilingual List of Values The List of Values type against which this column is validated, in multiple
languages. End users must specify a value from the list, but see the values in their
preferred language.
MLS Multiple Language Support The name of the table in which the translation in an alternate language can be
found.
DNRM Denormalized The path to the original column, used by the Object Manager to synchronize the
values, in the form of [foreign key column].[original column]. For example, the
ACCNT_NAME column of table S_ACCNT_POSTN is denormalized; its domain is
[OU_EXT_ID].[NAME]. In other words, the contents of column NAME of the table
referenced by OU_EXT_ID (S_ORG_EXT) are replicated into column ACCNT_NAME
of table S_ACCNT_POSTN. Denormalization is used to improve query performance.
(blank) There is no domain specified for this column.
Columns of Numeric Physical Type
Columns of a numeric physical type must have the properties Precision and Scale set, for example: Number (22, 7), or
Number (10, 0). The first value (22 and 10, in these examples) represents the precision, which is the total length of the
column including the decimal places. The second number (7 and 0, in these examples) represents the scale, which are
233
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
the decimal places after the decimal point. Siebel Tools sets the Length property to 22 by default; Length is a required
column in Siebel Tools, but this property does not play any role in columns of a numeric physical type.
Siebel System Fields
Every Siebel table contains the system fields described in the following table. Do not alter the contents of these fields.
Column Name Description
CONFLICT_ID Unique value used to resolve Siebel remote routing conflicts if necessary; otherwise, value is zero.
CREATED Date the record was entered.
CREATED_BY User who entered the record (foreign key to S_USER).
DCKING_NUM No longer used.
DB_LAST_UPD Date and time the record was last changed in the database.
DB_LAST_UPD_SRC Source of the instance or operation that changed the record in the database.
LAST_UPD Date and time the record was last changed.
LAST_UPD_BY User who last changed record (foreign key to S_USER).
MODIFICATION_NUM Internally incremented number used for locking and to identify records for incremental updates of the
Siebel Business Data Warehouse.
ROW_ID Unique row identifier.
INTEGRATION_ID Columns
Many tables contain a column called INTEGRATION_ID that is used to support integration with back-office applications.
Customers use this column to store the unique reference identifiers for corresponding records in their back-office
application. For Application Integration Architecture (AIA) integrations, use AIA_INTEG_ID columns.
234
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Include Only Field
Include Only is an index column field, and is either blank or checked. It applies only to DB2. When checked, it adds the
column into the leaf pages of the unique index. This avoids access to table pages when the column is the only other
piece of data retrieved from the table other than the indexed columns. Included columns do not contribute to the
unique constraint.
Siebel Repository
Siebel Business Applications include a set of tables referred to as the Siebel repository tables. These tables store the
full definition of a given configuration of Siebel Business Applications, including the database schema and the client
configuration. As with other Siebel tables, do not manipulate information in the Siebel repository tables directly. Instead,
use Siebel Tools. For more information on how to use Siebel Tools, see Using Siebel Tools . To learn more about the
information stored in the repository, see Siebel Object Types Reference .
Database Schema Version
Each Siebel Business Applications database installation is stamped with a database schema version. You can learn the
schema version of a Siebel installation by choosing Help, then Technical Support from your Siebel client. The schema
version is listed in the format 41.XX.YY.ZZ, where XX, YY, and ZZ are one or two digit integers.
Limit Checking for Data Types
The Object Manager imposes limit checking on data of specific types to make sure that every input, regardless of its
source, is within specified limits (see the following table) Sources of inputs include Oracle’s Siebel application, EIM,
and connectors. For example, if you do a bulk import using EIM, you must make sure the dates are within the specified
range, otherwise the Object Manager returns an SQL error for each out-of-range date.
Data Type Limit Checking
Dates Dates must be in the range of January 1, 1753 to December 31, 4712.
Long Maximum size of 16K
Text Maximum size of 16K
CLOB Maximum size of 128K
235
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
Validating the Siebel Schema
To make sure that there are no inconsistencies between the Siebel Database Server and the physical database schema,
use the Siebel Server utility dbchck.exe (Windows) or dbchck (UNIX). You can use the dbchck utility to validate data
relationships, including foreign keys and the list of values. You can also use the DICTUTL utility to verify that all doc
objects and rule definitions are correct. For more information about how to use these utilities, see Siebel Enterprise
Integration Manager Administration Guide .
Party Model Unifies Access to Data
The party model is a means of unifying all access to data about relationships. This covers relationships between your
company and people (contacts, employees, partner employees, users) and other businesses (accounts, divisions,
organizations, partners). The base table for all such access is S_PARTY. Related tables are implicitly joined as extension
tables. The following table lists the extension tables and their corresponding EIM interface tables.
Data Type Extension Table to S_PARTY EIM Interface Table
Accounts S_ORG_EXT EIM_ACCOUNT
Business Units S_BU EIM_BU
Contacts S_CONTACT EIM_CONTACT
Employees S_CONTACT EIM_EMPLOYEE
Groups S_ORG_GROUP EIM_GROUP
Organizations S_ORG_BU EIM_ORG_BU
Positions S_POSTN EIM_POSITION
Users S_USER EIM_USER
Because the extension tables are implicitly joined to S_PARTY, you do not need to configure anything to access them
through S_PARTY. Some data types have a many-to-many relationship. For example, any contact can be associated with
multiple accounts or partners. To model these relationships there are preconfigured intersection tables: S_PARTY_PER
and S_PARTY_REL. Use S_PARTY_REL to implement relationships between parties in the S_PARTY table. In this case,
records in S_PARTY are both parent (PARTY_ID) and child (PERSON_ID).
Use S_PARTY_PER to implement relationships between members:
• Access groups and members
236
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
• Accounts and contacts
• Employees and positions
• User lists and users
Generating a Report about Tables
You can generate a report that displays selected properties of each table and lists the columns. The name, physical type,
length, comments, and various other properties are identified for each column.
To generate a table report
1. Log in to the Siebel application, and navigate to the Administration - Application screen, then Tables view.
2. From the Menu menu, choose New Query.
3. In the Name column, enter the name of the table for which the report is to be generated, and press Enter.
4. Click the Reports icon in the icon bar.
5. Select Tables Report from the drop-down list.
The Output Type dialog box appears.
6. Select the output format for the report from the drop-down list.
7. Click Submit to generate the report.
The File Download dialog box appears.
8. Choose to open, save or cancel the report.
Note: For more information about generating reports, see Siebel Reports Guide .
237
Siebel Chapter 3
Data Model Reference Guide Siebel Physical Model
238
Siebel Chapter 4
Data Model Reference Guide Schema Changes
4 Schema Changes
Schema Changes
This chapter lists the table, table column, and table index changes in the schema that have been implemented in Siebel
Innovation Pack 2017. It includes the following information:
• New Tables Added to Innovation Pack 2017
• New Table Columns Added to Innovation Pack 2017
• Modified Columns in Innovation Pack 2017
• New Table Indexes Added to Innovation Pack 2017
• Table Index Columns That Have Been Added in Innovation Pack 2017
New Tables Added to Innovation Pack 2017
The following table lists tables that have been added to Innovation Pack 2017. All of these new tables are active.
Table Type Project
S_ORDER_SIGN Data (Public) Table Order
New Table Columns Added to Innovation Pack 2017
The following table lists table columns that are new to Innovation Pack 2017. All of these tables are active. Some of the
column headings are abbreviated as follows:
• Opt indicates optional.
• Len indicates length.
• Prec indicates precision.
• Def indicates default.
N/A in a row indicates not applicable.
Table Column Type Opt Data Type Len Prec Scale Def
S_APP_VIEW_RESP WS_ID Data (Private) Y Varchar 15 N/A N/A N/A
S_APP_VIEW_RESP WS_INACTIVE_FLG Data (Private) N Char 1 N/A N/A N
239
Siebel Chapter 4
Data Model Reference Guide Schema Changes
Table Column Type Opt Data Type Len Prec Scale Def
S_APP_VIEW_RESP WS_MIN_VER Data (Private) Y Number 22 10 0 0
S_APP_VIEW_RESP WS_SRC_ID Data (Private) Y Varchar 15 N/A N/A N/A
S_ASSESS_ATTRIB CATEGORY_CD Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_ATTVAL TYPE_CD Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_VAL ATTRIB_01_VALUE Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_VAL ATTRIB_02_VALUE Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_VAL CATEGORY_CD Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_VAL CONSIDERATIONS Data (Public) Y Varchar 1500 N/A N/A N/A
S_ASSESS_VAL DTCTBLTY_SCORE Data (Public) Y Number 22 10 0 N/A
S_ASSESS_VAL FUNCPLAN_IMPACT_CD Data (Public) Y Varchar 30 N/A N/A N/A
S_ASSESS_VAL PROBABILITY_SCORE Data (Public) Y Number 22 10 0 N/A
S_ASSESS_VAL PROG_PTCL_CD Data (Public) Y Varchar 30 N/A N/A N
S_ASSESS_VAL RATIONALE Data (Public) Y Varchar 256 N/A N/A 10000
S_ASSESS_VAL TOTAL_SCORE Data (Public) Y Number 22 10 0 0
S_LST_OF_VAL WS_ID Data (Private) Y Varchar 15 N/A N/A N/A
S_LST_OF_VAL WS_INACTIVE_FLG Data (Private) N Char 1 N/A N/A N
S_LST_OF_VAL WS_MAX_VER Data (Private) Y Number 22 10 0 10000
S_LST_OF_VAL WS_MIN_VER Data (Private) Y Number 22 10 0 0
S_LST_OF_VAL WS_SRC_ID Data (Private) Y Varchar 15 N/A N/A N/A
S_UI_CTRL_STYLE WEB_TEMPLATE Data (Private) Y Varchar 75 N/A N/A N/A
S_WS_WEBSERVICE TYPE_CD Data (Public) Y Varchar 30 N/A N/A N/A
240
Siebel Chapter 4
Data Model Reference Guide Schema Changes
Table Column Type Opt Data Type Len Prec Scale Def
Modified Columns in Innovation Pack 2017
The following table describes table columns that have been modified in Innovation Pack 2017.
Table Column Type of Change Old Value New
Value
S_AGREE_TERMS CC_NUMBER Column Length Changed 50 250
S_ASSESS_ATTRIB DESC_TEXT Column Length Changed 250 1500
S_CONTACT_FNX YL_PASSWD Column Length Changed 90 500
S_DOC_ORDER CCV_NUMBER Column Length Changed 20 100
CC_NUMBER Column Length Changed 50 250
S_INV_PROF CCV_NUMBER Column Length Changed 20 100
CC_NUMBER Column Length Changed 50 250
S_NAV_LINK_LANG CONFLICT_ID Default Value added N/A 0
S_ORDER CC_NUMBER Column Length Changed 50 250
S_PTY_PAY_PRFL PAY_ACCNT_NUM Column Length Changed 50 250
VERIFICATION_NUM Column Length Changed 20 100
S_SRC_PAYMENT CC_NUM Column Length Changed 50 250
S_USER CHALLENGE_ANSWER Column Length Changed 250 1200
CHALLENGE_QUESTION Column Length Changed 250 1200
241
Siebel Chapter 4
Data Model Reference Guide Schema Changes
New Table Indexes Added to Innovation Pack 2017
The following table lists table indexes that are new to Innovation Pack 2017. All of these tables are active.
Table Index Unique Columns
S_LST_OF_VAL S_LST_OF_VAL_M3 N (WS_ID,WS_SRC_ID)
Table Index Columns That Have Been Added in
Innovation Pack 2017
The following table lists table index columns that have been added in Innovation Pack 2017. This table is active and
unique.
Table Index Existing Columns Additional Columns
S_APP_VIEW_RESP S_APP_VIEW_RESP_U1 • VIEW_ID • WS_ID
• RESP_ID • WS_MIN_VER
• CONFLICT_ID
S_LST_OF_VAL S_LST_OF_VAL_U1 • TYPE • WS_ID
• VAL • WS_MIN_VER
• LANG_ID
• SUB_TYPE
• BU_ID
• CONFLICT_ID
S_LST_OF_VAL S_LST_OF_VAL_U2 • TYPE • WS_ID
• NAME • WS_MIN_VER
• LANG_ID
• SUB_TYPE
• BU_ID
• CONFLICT_ID
242
You might also like
- Invoking Static BOPF Action From Custom Pop Up in Fiori Elements AppNo ratings yetInvoking Static BOPF Action From Custom Pop Up in Fiori Elements App29 pages
- Birmingham Garretts Green MPTC Car Routes 1-5No ratings yetBirmingham Garretts Green MPTC Car Routes 1-55 pages
- Modern Analytics Academy - Data ModelingNo ratings yetModern Analytics Academy - Data Modeling12 pages
- Modul 9 - Data Warehousing and Business Intelligence - DMBOK2No ratings yetModul 9 - Data Warehousing and Business Intelligence - DMBOK259 pages
- Power BI Deployment Pipelines CheatSheet 1731972155No ratings yetPower BI Deployment Pipelines CheatSheet 173197215510 pages
- The Chief Data Officer Management Handbook: Set Up and Run An Organization's Data Supply Chain 1st Edition Martin Treder100% (4)The Chief Data Officer Management Handbook: Set Up and Run An Organization's Data Supply Chain 1st Edition Martin Treder62 pages
- modern-data-sharing-for-data-driven-organizationsNo ratings yetmodern-data-sharing-for-data-driven-organizations21 pages
- A Data Engineer's Guide To Semantic Modelling - Ilaria MaresiNo ratings yetA Data Engineer's Guide To Semantic Modelling - Ilaria Maresi50 pages
- Non-Profit Solution For Microsoft Dynamics CRM: Users GuideNo ratings yetNon-Profit Solution For Microsoft Dynamics CRM: Users Guide55 pages
- Data Management Maturity: Assessment ReviewNo ratings yetData Management Maturity: Assessment Review44 pages
- DAMA DMBOK 2nd Edition Data Management Body of Knowledge Dama International - Download the ebook now for full and detailed access100% (4)DAMA DMBOK 2nd Edition Data Management Body of Knowledge Dama International - Download the ebook now for full and detailed access65 pages
- Big Educational Data & Analytics SurveyNo ratings yetBig Educational Data & Analytics Survey23 pages
- Instant Access to Data Teams: A Unified Management Model for Successful Data-Focused Teams Jesse Anderson ebook Full Chapters100% (5)Instant Access to Data Teams: A Unified Management Model for Successful Data-Focused Teams Jesse Anderson ebook Full Chapters50 pages
- Ebook - Analytics-Trends-2024 - v1 - 180124 2No ratings yetEbook - Analytics-Trends-2024 - v1 - 180124 211 pages
- Blockchain Techonology in Healthcare Mangement SystemNo ratings yetBlockchain Techonology in Healthcare Mangement System7 pages
- Vector Format, Easy Color Change: IconsNo ratings yetVector Format, Easy Color Change: Icons10 pages
- Data Modeling Powerdesigner Da Data SheetNo ratings yetData Modeling Powerdesigner Da Data Sheet4 pages
- The Forrester Wave™ - Privacy Management Software, Q1 2020 PDFNo ratings yetThe Forrester Wave™ - Privacy Management Software, Q1 2020 PDF18 pages
- Project Workbook Information: Suggested Sheets For All ProjectsNo ratings yetProject Workbook Information: Suggested Sheets For All Projects23 pages
- 4 - Finding and Fixing Data Quality IssuesNo ratings yet4 - Finding and Fixing Data Quality Issues48 pages
- Composition Media Discover Media Generation 2gp Manual EngNo ratings yetComposition Media Discover Media Generation 2gp Manual Eng127 pages
- A Survey of Maturity Models in Data Management 1No ratings yetA Survey of Maturity Models in Data Management 113 pages
- Applies To:: Oracle Retail 16.0.x Data Models (Doc ID 2200398.1)No ratings yetApplies To:: Oracle Retail 16.0.x Data Models (Doc ID 2200398.1)3 pages
- Information Management Training: Info@dmadvisors - Co.ukNo ratings yetInformation Management Training: Info@dmadvisors - Co.uk17 pages
- it_Establish_Data_Governance_Phases_1_3_v7No ratings yetit_Establish_Data_Governance_Phases_1_3_v7108 pages
- A Step-By-Step Guide To Improve Data QualityNo ratings yetA Step-By-Step Guide To Improve Data Quality93 pages
- Data Literacy Fundamentals: Understanding the Power & Value of DataFrom EverandData Literacy Fundamentals: Understanding the Power & Value of DataNo ratings yet
- Laboratory Record Note Book: Rajalakshmi Institute of TechnologyNo ratings yetLaboratory Record Note Book: Rajalakshmi Institute of Technology102 pages
- Data Base Management Systems - CSE & IT - B.Tech - II - II - R18 - OCT - 2020No ratings yetData Base Management Systems - CSE & IT - B.Tech - II - II - R18 - OCT - 20202 pages
- File System: File System Management and Optimization Example File SystemsNo ratings yetFile System: File System Management and Optimization Example File Systems33 pages
- Symantec NetBackup Interview Questions and Answers Tecz PDFNo ratings yetSymantec NetBackup Interview Questions and Answers Tecz PDF3 pages
- Benchmarking ETL Workflows: Presented by Kevin WilkinsonNo ratings yetBenchmarking ETL Workflows: Presented by Kevin Wilkinson48 pages
- Enhanced Data Models For Advanced Applications91% (11)Enhanced Data Models For Advanced Applications15 pages
