This article will help to understand the Siebel architecture and servers; we will also discuss the

physical architecture of Siebel setup and the basic understanding of Siebel clients, Web Server,
Siebel Web Server Extensions (SWSE), .cfg, Siebel Enterprise Server, Siebel Gateway Name
Server, Siebel Database Server.
At a high level, the Siebel architecture consists of:

Web clients that access the business data

A Web server that handles interactions with the Web clients

Servers that manage the business data and provide batch and interactive services for
clients

A relational database and file system that store business data

Further drilling down on the Siebel environment we have

The Siebel Business Applications environment consists of the following entities:
Siebel Clients :

Includes Siebel Web client, Siebel Developer Web Client, Wireless Client, Mobile Web Client,
handheld client, and Siebel Tools Client

Displays the interactive Siebel application used to manage the Siebel data Runs in a variety
of environments

Web browsers

WML devices

o
PDAs (Windows CE and Palm)
Siebel Web Server:

Identifies and passes Siebel requests from Web clients to the Siebel servers Passes
completed HTML application pages back to Web clients

Consists of a third-party Web server with the following additional Siebel components
o

Virtual directories

Siebel Web Server Extensions (SWSE)

o
Configuration file (.CFG)
Siebel Enterprise Server:

A logical collection of Siebel Servers that support users accessing a single database server
and a single file system.

Logically groups Siebel Servers for common administration via Siebel Server Manager.

Supports sharing of common configuration information

Siebel Gateway Name Server:

Is a Windows service or Unix daemon process.

Dynamically registers Siebel Server and component availability.
Stores component definitions and assignments, operational parameters, and connectivity
information. Stored in siebns.dat file located in\\sea**\gtwysrvr\ADMIN

Includes the connection broker and name server for a single server deployment. (The name

server is a separate entity for multiple server deployments.).

Siebel Database Server:

Includes the RDBMS client software and Siebel tables, indexes, and seed data.

Stores data used by Siebel eBusiness Applications in a predefined database schema

Supports a variety of third-party relational database management system (RDBMS)

Siebel File System:

Stores the data and physical files used by Siebel clients and Siebel Enterprise Server.

Read/write access is controlled by the File System Manager server component

Is a shared directory that stores compressed files used by Siebel applications

o

Examples: Product literature, sales tools, presentations

Physical Architecture:
The Siebel Gateway Name Server, Siebel Server, Database Server, and File System can be implemented
on one machine or spread across multiple machines
The Siebel Server(s) should have a high-speed LAN connection to the Database Server

Share this:
S_PARTY model is the major change seen in Siebel 7.X and later version.
The S_PARTY table is the base table for all the party related entities: Person
(Contact), User, Employee, Partner User, Account, Division, Organization,
Partner Organization, Household, Access Group and User list.Party
components have M: M relationships among them. For each party record

stored in the S_PARTY table, the value of the PARTY_TYPE_CD column denotes
the party type. Along with the party type, extension tables provide the
primary differentiation between the different parties.

The Siebel Party Model and

Oracle BI Applications
Part 1/2
In this post Im focussing on the Siebel Party Model and how this is relevant
and brought over to the pre-built Oracle BI Applications for Analysis.
From a CRM perspective it is very important to model:

the own Organization

Internal Employees

Employee Hierarchy

Customers (of the own Organization)

Customers can be other Companys (in Siebel known as Accounts) in B2B or

Individual Persons in B2C Scenarios (in Siebel known as Contacts). This is
relevant as e.g. a specific Sales Employee of the own Organization sells a
Product to a purchase authorized Contact of another Company (Accounts).
To organizes all this, Siebel uses the Party Concept to relate all above
mentioned (and some more) entities such as: Person, Organization, Position,
Household etc. within a single entity: the Party.

All Entities surrounding (extending) the Party have at least one record stored
in the Party entity itself. The Party also has a Party
Type (S_PARTY.PARTY_TYPE_CD), which provides some further
aggregation/classification for the Party Entities.
The following Table describes the Party Entities (Extension Entities to the
Party Entity), the Physical table references and the associated Party
Types (S_PARTY.PARTY_TYPE_CD) in the Party Entity:

Party ext.
Entity

Person (or
Contact)

Phy. Table

S_CONTACT

Party
Type in
Party
Entity

Person

Description

A Person is an [real world]

individual who is represented by a
Person, Without additional
attributes, a Person has no
access to your database. E.g. An

employee at a customers
company

User

S_USER

Person

A User is a Person who can

log into your database and
has a responsibility that
defines what application
views are accessible

Partner
User

S_USER

Person

An employee at a partner
company, who is associated with
a position in a division within an
external organization. Therefore, a
Partner User is also an Employee,
but not an internal one.

Employee

S_EMP_PER

Person

An Employee is a User who is

associated with a position in a
division within your company.

Position

S_POSTN

Position

A job title within your company that

exists for the purpose of
representing reporting
relationships. Every position is
associated with a division. The
position is then also automatically
associated with one organization:
the organization with which the
division is associated. Thus, a
position within your company is
associated with a division and
isassociated with the organization
to which that
division belongs. Data is associated
with a Position, which drives the
Position Visibility.

Account

S_ORG_EXT

Organizatio A company with whom you do

n
business. An account is not a
division, an internal organization,

or an external organization. Can

have Parent and Child Accounts.

Division

S_ORG_EXT

Organizatio An organizational unit within your

company such as Manufacturing or
n

Corporate e.g. operating within a

particular country. Exists for the
purposes of mapping a companys
physical structure into the Siebel
database and forproviding a
container for position hierarchies. A
division can have a Hierarchy with
parent division and have child
divisions. A division can be
associated with only one
organization. Datacannot be
associated directly with a division.
(Divisions that are not designated
as organizations do not drive
visibility.

Organizatio S_ORG_EXT
n

Organizatio An organizational unit within your

company. TheOrganization is a
n

Household

S_GROUP_ORG

Household

A group of people, typically a

family, who reside at the same
residence, who are economically
affiliated and share a common
purchasing or service interest.

User List

S_USERLIST

User List

A user list is a group of some

internal employees and some
partner users. It can have any

division that is designated as an

organization. Positions are not
assigned directly to Organizations to
drive Visibility, but only via
Divisions. An organization exists for
the purpose of providing a
container in which positions can be
associated with Data to drive
Position and Organization
Visibility.Organizations can also
have a Hierarchy like divisions.

combination of contacts, users,

employees, and partner users as
members

Access
Group

S_PARTY_GROUP Access
Group

An access group is a group of

any combination of parties of
type Position, Organization, and
User List. That is, it is a group of
groups

Business
Unit

S_BU

Not officiall
mentioned: Internal

Organization

Organizations
are also represented as Business
Units.

To model relationships between the own Organization (and own Employees)

and Customer Organizations (and their Employees) the most important
Party Types are:Organization and Person/Contact.
Person/Contact:

Organization:

What are the Entities for Party Type: Persons?

The Entity Contact/Persons represents everything necessary for Siebel to

model an Individual e.g. with First Name, Last Name, Date of Birth, Phone
Number. That might be a Purchasing authorized Person within a customers
company. A User can be assigned with a User Id to the Person to specify
the credentials like Login and password. If the User is an internal, it is
represented as Employee by assigning the Contact with aPosition within
the Organization.
How does this look in the Siebel UI?

To administer this, one needs to navigate to Administration User Screen

for setting upPersons/Contacts, Employees and Users.
As can be seen below, certain Person/Contacts also have been configured
with a Userfor Logging into the Siebel Application:

Using the Employee Screen it is also possible to assign the Employee to a

Organization and a Position for steering the Visibility. (Additionally the
Employee can also be assigned to a Division, however this doesnt affect
Visibility).

Detailed Screen of a single Employee Record:

Even though a Employee Record exists, the Employee needs to be assigned

with a User for being able to Login to the Siebel Application.
-The setup of Partner Users is not covered within this ArticleHow is this stored in the Siebel Database?
For Contacts:
1

select ou_id,fst_name,last_name,birth_dt,work_ph_num,login,

emp_flg,emp_num,sex_mf, priv_flg,status_cd,prospect_flg

from S_CONTACT;

For Users:
1

select LOGIN,USER_FLG,PASSWORD

from S_USER;

For Employees:
1

select CNTRCTR_FLG,BURDENED_RATE,CURR_SALARY_AMT,TERMINATION_DT,

EMP_STAT_CD from S_EMP_PER;

And for the Party of Type Person:

1

select ROW_ID,PARTY_TYPE_CD,PARTY_UID,PAR_PARTY_ID,NAME

from S_PARTY

where PARTY_TYPE_CD = 'Person';

The following is an example of joining all above mentioned the Information of

the Entities via the S_PARTY:
1

Select S_CONTACT.ou_id,S_CONTACT.fst_name,S_CONTACT.last_name,

S_CONTACT.birth_dt,S_CONTACT.work_ph_num,S_CONTACT.login,

S_CONTACT.emp_flg,S_CONTACT.emp_num,S_CONTACT.sex_mf,

S_CONTACT.priv_flg,S_CONTACT.status_cd,

5
6
7
8
9
10
11
12
13

S_CONTACT.prospect_flg --from S_CONTACT

,S_PARTY.PARTY_TYPE_CD,S_PARTY.Name AS "PARTY NAME" --from S_PARTY
,S_USER.LOGIN,S_USER.USER_FLG,S_USER.PASSWORD --from S_USER
,S_EMP_PER.CNTRCTR_FLG,S_EMP_PER.BURDENED_RATE,
S_EMP_PER.CURR_SALARY_AMT,S_EMP_PER.TERMINATION_DT,
S_EMP_PER.EMP_STAT_CD --from S_EMP_PER
from S_CONTACT INNER JOIN S_PARTY
ON S_PARTY.ROW_ID = S_CONTACT.PAR_ROW_ID
LEFT OUTER JOIN S_USER ON S_USER.PAR_ROW_ID = S_CONTACT.EMP_ID

14

LEFT OUTER JOIN S_EMP_PER ON S_PARTY.ROW_ID=S_EMP_PER.PAR_ROW_ID;

For this Ive used Outer Joins for User and Employee Entity since not every
Contact belongs to this Entity.
What are the Entities for Party Type: Organizations?

The Account is the representation of a Business Customers (also known as

Company in real life terms). The own Company is represented as:
Organizations (for steering Visibility), Divisions (not influencing Visibility)
and Business Units.

How does this look in the Siebel UI?

Accounts (or Business Customers are administered from the Account
List View:

The Contact/Persons within the Business Customer Company can be seen

below the Account (when clicking a particular Account) and each contact has
a certain role or Job Title within the Customer Account.:

The own Organization can be Administered using the

(internal) Organization (andBusiness Unit) and Divisions, from the
Administration Group Organization Screen:

And the Organizations List Screen:

And the detailed Screen e.g. to setup (internal) Organization Hierarchy:

The Divisions can be listed from the Divisions Screen:

The main Screen shows the association of Divisions with one (and maximum
only one) Organization:

And on the detailed Screen shows the Positions which are assigned to the
Division. (And from this link implicitly to the Organization):

How is this stored in the Siebel Database?

External Organizations, which represent Business Customers
as Accounts use the S_ORG_EXT Table.
1

select bu_id,par_bu_id, name,cmpny_name,legal_form_cd, accnt_flg,

accnt_type_cd,prospect_flg, int_org_flg,prtnr_flg,active_flg,

pay_type_cd

from S_ORG_EXT

where int_org_flg = 'N';

Previous Version of Siebel used a Table called S_ORG_INT for Internal

Organizations, however this Table is not used/part of the shipped Standard
Model any further. Its functionality is merged into S_ORG_EXT with
INT_ORG_FLG = Y and an associated S_BU record.
1

select S_BU.BU_FLG,S_BU.NAME,S_BU.ROW_ID,S_BU.PAR_ROW_ID,

/*S_ORG_EXT.ACCNT_FLG,*/S_ORG_EXT.ACTIVE_FLG,S_ORG_EXT.ROW_ID,

S_ORG_EXT.PAR_ROW_ID,S_ORG_EXT.BU_ID,S_ORG_EXT.DIVISION,

S_ORG_EXT.DIVN_CD,S_ORG_EXT.INT_ORG_FLG,S_ORG_EXT.NAME,

5
6
7

/*S_ORG_EXT.ACCNT_TYPE_CD,*/OU_NUM,OU_TYPE_CD,PAR_BU_ID,
PAR_DIVN_ID,PAR_OU_ID
from S_BU INNER JOIN S_ORG_EXT ON S_ORG_EXT.BU_ID = S_BU.ROW_ID
where BU_FLG ='Y' and INT_ORG_FLG = 'Y' ;

Divisions are also just stored in the S_ORG_EXT with INT_ORG_FLG = Y but
have no record in the S_BU table. :
1

select *

from S_ORG_EXT --no Record in S_BU Table

Where are the relationships maintained?

The relationships between the own Organization and Employees and the
customers Organization and Employees is maintained within the Party
Relationships and Party Members Table S_PARTY_REL and S_PARTY_PER.
The S_PARTY_REL must be used to model multiple relationships between the
same Entities e.g. when the same Contact has multiple roles (Purchase
Authorized, Business Owner, Fleet Manager) within the same one Account.
Because the S_PARTY_PER has unique indexes defined not allowing this
multiple Relationships.
How is this stored in the Siebel Database?
The S_PARTY_REL and S_PARTY_PER Table are used to relate the Party Entities.
1

select * from s_party_rel;

How is this modelled in BI Applications?

Within a next blog Post Ill cover how this is brought to BI Applications
covering:
How Contacts and Accounts are represented in the Oracle Business

Analytics Warehouse (OBAW) Data Model as Dimensions

How the Fact to relate Account and Contacts (W_PERSON_F) is

extracted using the S_PARTY_PER

How other Facts use the Account and Contact Dimensions, like

W_CAMP_HIST_F
PARTY DATA MODEL:

PARTY TYPE AND PARTIES:

1)
PARTY => PERSON (CONTACT)
PARTY TYPE => PERSON
E.G:

An employee at the customer company.

An employee at the competitors company

Features:

A Person is an individual who is represented by a Person record in the database

Without additional attributes, a Person has no access to your database

The base table (S_PARTY) and extension table (S_CONTACT) that define a contact or person. A person is
the simplest representation of an individual in the database
2)
PARTY => USER
PARTY TYPE => PERSON
E.G:

A registered customer on (your) Web site

A self-registered partner user, that is, one who has no position.

Features:

A User is a Person who can log into your database and has a responsibility that defines what
application views are accessible.

A self-registered partner on a Siebel partner application has a responsibility, but does not

have a position like a full Partner User has.

The base table (S_PARTY) and extension tables that define a user (S_CONTACT and S_USER) form User
Data Model. A User is a person with following added qualities
1)

The S_USER table contains a login for this user

2)

The S_PER_RESP intersection table specifies the responsibility for this user

3)
It is possible to promote a contact to a user. For example, adding a User ID value for a person in
the All Persons view in the Administration User screen causes the person to appear as a user in the
Users view.
3)
PARTY => EMPLOYEE
PARTY TYPE => PERSON
E.G:

An Employee at your company An Employee is a User who is associated with a position in

a division within your company

Base table (S_PARTY) and the extension tables (S_CONTACT, S_USER, and S_EMP_PER) define
employee. This includes internal employees and Partner users.
An Employee is a User with the following added qualities:
1.

S_EMP_PER provides employee data for this user.

1.

A position defined using the S_POSTN table is typically (but not necessarily)
associated with an employee.

2.

If the organization to which the position belongs is not a partner organization,

then the employee is an internal employee.

3.

If the organization is a partner organization, then the employee is a partner

user.
4)
PARTY => POSITION
PARTY TYPE => POSITION
E.G:

A job title within (your) company

A job title within the partner company

Base table (S_PARTY) and extension table (S_POSTN)
Features:

Position exist for the purpose of representing reporting relationships

A position within your company is associated with a division and is associated with the
organization to which that division belongs.

A position can be associated with one division only.

A position may have a parent position. It may also have child positions

One or more employees can be associated with an internal position, and one or more
partner users can be associated with an external position.

An employee or partner user can be associated with more than one position, but only one

position is active at any time.

5)
PARTY => ACCOUNT
PARTY TYPE => ORGANIZATION
Account is a company or group of individuals with whom you do business.
An account is typically made up of contacts It can have parent and child accounts.
An account can be promoted to partner organization, but it is not a division, an internal or external
organization.
Base Table (S_PARTY) and extension table (S_ORG_EXT) defines Account data Model.
6)
PARTY => DIVISION
PARTY TYPE => ORGANIZATION
Division is an organizational unit within a company such as Manufacturing or Corporate unit.
It can also refer to a group of people operating within a particular company.
Features:
A division exists for the purposes of mapping a companys physical structure into the Siebel Database
and for providing a container for position hierarchies.
A division may have a parent division. It may also have child divisions.
Data cannot be associated directly with a division. (Divisions that are not designated as organizations do
not drive visibility.)
Base table (S_PARTY) and extension table (S_ORG_EXT) define division data model along
with INT_ORG_FLG=Y (in S_ORG_EXT) table
This flag specifies that division is an internal organization.
NOTE: For Account this flag is set to N
7)
PARTY => ORGANISATION
PARTY TYPE => ORGANISATION
E.G:
An Organizational unit within the company such as Asian organization and
A partner company
Features:
An organization is a division that is designated as an organization.
An organization exists for the purpose of providing a container in which positions can be associated with
data.

An organization can be internal or it can be a partner organization.

A division can be associated with only one organization: itself or an ancestor division that is also an
organization.
Base Table (S_PARTY) and extension tables (S_ORG_EXT and S_BU) define Organizational data model.
An Organization, sometimes known as a business unit, is also a Division, but has a record in the S_BU
table.
Partner Organization Data Model:
The base table and extension tables (S_ORG_EXT, S_BU, and S_ORG_PRTNR) define a Partner
Organization.
A Partner Organization is the same as an Organization but the flag PRTNR_FLG in S_ORG_EXT qualifies it
as a Partner Organization
8)
PARTY => HOUSEHOLD
PARTY TYPE => HOUSEHOLD
Base table (S_PARTY) and household (S_ORG_GROUP) defines Household.
A group of people, typically a family, who reside at the same residence forms Household
A group of purchasers who live in different residences are also included.
Typically, a household is a group of individual consumers who are economically affiliated and share a
common purchasing or service interest.
A household may have any combination of contacts, users, employees, and partner users as members.
An individual can belong to more than one household.
9)
PARTY => USER LIST
PARTY TYPE => USER LIST
Base table (S_PARTY) and extension table (S_USERLIST) defines User list.
E.G:
A support team made up of some internal employees and some partner users.
Features:
A user list is an ad hoc group of people. It may have any combination of contacts, users, employees, and
partner users as members
A user list cannot have a parent or children.
10)
PARTY => ACCESS GROUP
PARTY TYPE => ACCESS GROUP
Base table (S_PARTY) and extension table (S_PARTY_GROUP) defines access group
E.G:
Partner IT service providers and business-to-business customer companies that buy networking
equipment.

An access group is a group of any combination of parties of type Position, Organization, and User List.
That is, it is a group of groups
An access group may have a parent access group. It may also have child access groups.
Parties relation to each other:
Divisions, organizations, and accounts are instances of the Organization party type.

A division, internal or partner, is also an organization if its internal organization flag is TRUE
(INT_ORG_FLG = Y) and it has an associated S_BU record.

Every division is associated with one organization: either itself or the closest ancestor
division that is also an organization.

Every position is associated with a division. The position is then also automatically
associated with one organization: the organization with which the division is associated.

Persons (contacts), users, employees, partner users are instances of the Person party type.

Typically, you associate each employee and partner user with one or more positions. The
employee or partner user has only one active position at one time. The employee or partner
user is automatically associated with one division and one organization at a timethe
division and organization associated with the active position.

For purposes of granting visibility to data, associations of parties of type Person with other
types of parties are stored using the S_PARTY_PER table. For example, accounts are
associated with contacts, users are associated with positions, and so on. A user associated
with a position can see data for accounts or opportunities assigned to the position (when
this is the active position). Relationships stored in S_PARTY_REL also affect data routing for
mobile users.

For purposes of storing ad hoc, informational relationships between parties, such

associations are stored using the S_PARTY_REL table. For example, a company and its
accounting firm may both be stored as accounts. Assuming that your application provides
the capability to define this relationship, it can be stored in the S_PARTY_REL table.

Ad hoc and informational relationships between parties are stored in the table
S_PARTY_REL. For example, a company and its accounting firm may both be stored as
accounts. The relationship between these two accounts can be stored in the S_PARTY_REL
table, assuming that your application has been configured to define these relationships.

Party Data Model

The S_PARTY table is the base table for all of the parties listed in Table 9-1,
"Party Types and Parties": Person (Contact), User, Employee, Partner User,
Position, Account, Division, Organization, Partner Organization, Household,
User List, and Access Group.

For each party record stored in the S_PARTY table, the value of the
PARTY_TYPE_CD column denotes the party type. Along with the party type,
extension tables provide the primary differentiation between the different
parties.
For information about how joins are used to draw data from multiple
tables into a single business component, such as is done for Employee,
Account, and other business components for party-type data,
see Configuring Siebel Business Applications.
In Figure 9-10, the base table and extension tables that make up the party
data model are shown within the Party boundary box (all of the shaded
area). The three tables shown outside of the Party boundary are used to
define relationships among parties. Sections that follow illustrate how the
party data model applies to various particular parties.
Figure 9-10 Party Data Model

How Parties Relate to Each Other

Parties have some required relationships, as described below.

Divisions, organizations, and accounts are instances of the

Organization party type.

A division, internal or partner, is also an organization if its internal

organization flag is TRUE (INT_ORG_FLG = "Y") and it has an
associated S_BU record.

Every division is associated with one organization: either itself or the

closest ancestor division that is also an organization.

Every position is associated with a division. The position is then also

automatically associated with one organization: the organization
with which the division is associated.

Persons (contacts), users, employees, partner users are instances of

the Person party type.

Typically, you associate each employee and partner user with one or
more positions. The employee or partner user has only one active
position at one time. The employee or partner user is automatically
associated with one division and one organization at a time; the
division and organization associated with the active position.

Caution:
Merging employee records is not recommended. You can
disrupt party relationships to a significant extent and get
unexpected results.

For purposes of granting visibility to data, associations of parties of

type Person with other types of parties are stored using the
S_PARTY_PER table. For example, accounts are associated with
contacts, users are associated with positions, and so on. A user
associated with a position can see data for accounts or opportunities
assigned to the position (when this is the active position).
Relationships stored in S_PARTY_REL also affect data routing for
mobile users.

Nonstructured and informational relationships between parties are

stored in the table S_PARTY_REL. For example, a company and its
accounting firm might both be stored as accounts. The relationship
between these two accounts can be stored in the S_PARTY_REL
table, assuming that your application has been configured to define
these relationships.

Person (Contact) Data Model

In Figure 9-11, the base table and extension table (S_CONTACT) that
define a Person, or Contact, are highlighted. A Person is the simplest
representation of an individual in the database.
Figure 9-11 Person (Contact) Data Model

User Data Model

In Figure 9-12 the base table and extension tables (S_CONTACT and
S_USER) that define a User are highlighted. A User is a Person with the
following added qualities:

The S_USER table contains a login for this user.

The S_PER_RESP intersection table (not shown) specifies a

responsibility for this user.

It is possible to promote a contact to a user. For example, adding a

User ID value for a person in the All Persons view in the
Administration - User screen causes the person to appear as a user
in the Users view.

Figure 9-12 User Data Model

Employee Data Model

In Figure 9-13 the base table and extension tables (S_CONTACT, S_USER,
and S_EMP_PER) that define an Employee are highlighted. Internal
Employees and Partner Users are each represented as Employee records.
An Employee is a User with the following added qualities:

S_EMP_PER provides employee data for this user.

A position defined using the S_POSTN table is typically (but not

necessarily) associated with an employee.
o

If the organization to which the position belongs is not a

partner organization, then the employee is an internal
employee.

If the organization is a partner organization, then the

employee is a partner user.

Figure 9-13 Employee Data Model

Position Data Model

In Figure 9-14 the base table and extension table (S_POSTN) that define a
Position are highlighted.

Note:
In positions, as in other areas of your Siebel application, foreign
key references are implemented with the ROW_ID column in the
base tables. The ROW_ID column is not visible in the user
interface and cannot be changed manually. This is because the
integrity between the various base tables would be lost if users
were allowed to change this value. Changing a position name
does not affect the foreign keys (the ROW_ID in the underlying
base table).

Figure 9-14 Position Data Model

Account Data Model

In Figure 9-15, "Account Data Model" the base table and extension table
(S_ORG_EXT) that define an Account are highlighted.

Note:
Accounts, Divisions, Organizations, and Partner Organizations
share many of the same data model elements.

Figure 9-15 Account Data Model

Division Data Model

In Figure 9-16 the base table and extension table (S_ORG_EXT) that define
a Division are highlighted. In S_ORG_EXT, the flag INT_ORG_FLG = Y
specifies that a division is an internal organization. (For an account, this
flag is set to N.)

Note:
Accounts, Divisions, Organizations, and Partner Organizations
share many of the same data model elements.

Figure 9-16 Division Data Model

Organization Data Model

In Figure 9-17 the base table and extension tables (S_ORG_EXT and S_BU)
that define an Organization are highlighted. An Organization, sometimes
known as a business unit, is also a Division, but has a record in the S_BU
table.

Note:
Accounts, Divisions, Organizations, and Partner Organizations
share many of the same data model elements.

Figure 9-17 Organization Data Model

Partner Organization Data Model

In Figure 9-18 the base table and extension tables (S_ORG_EXT, S_BU, and
S_ORG_PRTNR) that define a Partner Organization are highlighted. A
Partner Organization is the same as an Organization but the flag
PRTNR_FLG in S_ORG_EXT qualifies it as a Partner Organization.

Note:
Accounts, Divisions, Organizations, and Partner Organizations
share many of the same data model elements.

Figure 9-18 Partner Organization Data Model

Household Data Model

In Figure 9-19 the base table and extension table (S_ORG_GROUP) that
define a Household are highlighted.
Figure 9-19 Household Data Model

User List Data Model

In Figure 9-20 the base table and extension table (S_USERLIST) that define
a User List are highlighted.
Figure 9-20 User List Data Model

Access Group Data Model

In Figure 9-21 the base table and extension table (S_PARTY_GROUP) that
define an Access Group are highlighted.
Figure 9-21 Access Group Data Model

Account organization unit