Relationship Manager

This chapter describes using Relationship Manager to view, create, and edit relationships among existing parties in the TCA Registry.

This chapter covers the following topics:

Relationship Manager Overview

Use Oracle Trading Community Architecture (TCA) Relationship Manager to create and manage relationships among existing parties in the TCA Registry.

Note: You view and manage only parties of type Organization and Person in Relationship Manager.

Using relationships to model the interactions among parties in the TCA Registry helps you make better business decisions. For example, you can analyze and manage relationships with competitors and partners, or corporate relationships between subsidiaries and parent corporations.

In Relationship Manager, you get a comprehensive view of the roles that a single party plays with respect to other parties in the Registry, as well as a hierarchical view for hierarchical relationships. Aside from viewing relationships, you can create, edit, and end relationships.

Your administrator can set up Relationship Manager. See: Setting Up Relationship Manager, Oracle Trading Community Architecture Administration Guide.

Related Topics

Relationships Overview

Major Features

Party Relationship Management Process

Using Oracle Trading Community Architecture

Relationships Overview

The TCA relationship model lets you record complex, real-life relationships among entities in the TCA Registry. You can analyze not only direct relationships such as those with your competitors, but also indirect ones such as your customers' customers. You can also manage hierarchical relationships to better understand, for example, the management hierarchy within an organization.

A relationship represents the way two entities interact with each other, based on the role that each entity takes with respect to the other. For example, the employment relationship between a person and an organization is defined by the role of the person as the employee and the organization as the employer.

In addition, every relationship is reciprocal. Each entity is either the subject or object, depending on the perspective, or direction. For example, if Joe is the employee of Oracle, then Joe is the subject and Oracle is the object. Oracle as the employer of Joe, which flips the subject and object, still describes the same relationship.

Relationship Phrase and Role Pairs

A relationship phrase and role pair contains a correlating phrase pair and role pair, which describes the reciprocal roles that the two entities play in the relationship. For example, a relationship phrase and role pair contains the Employee Of and Employer Of phrase pair as well as the Employee and Employer role pair.

Every relationship is based on a relationship phrase and role pair. Even though only phrase pairs are used in Relationship Manager, the corresponding role pair is still stored in the system for each relationship.

A phrase pair, such as Employee Of and Employer Of, describe the role of either entity in the relationship as the subject. For example, Joe as the subject of the relationship would have Employee Of as the phrase, and Oracle as the subject would have Employer Of. The other entity in the relationship would be the object.

A relationship role pair, such as Employee and Employer, describes the two entities no matter the direction of the relationship. For example, Joe has the Employee role and Oracle the Employer role, both as either the subject or object.

Each relationship phrase and role pair also determines the type of entities for the relationship. For example, the Employer Of phrase and Employer role can be defined so that the employer must be a party of type Organization and the employee a party of type Person.

When you create a relationship with a relationship phrase or role, the reverse direction of the relationship is automatically created with the other phrase or role in the pair. For example, if you define Joe as the employee of Oracle, Oracle as the employer of Joe is also created.

Relationship Type

Each relationship phrase and role pair belongs to a relationship type, which categorizes the types of relationships that you can create. For example, the relationship phrase and role pair described above would belong to an employment relationship type.

Relationship types determine if the relationships created with the type are hierarchical, and if not, whether they can be circular or not. For more information, see: Relationship Characteristics.

Every relationship type must contain at least one phrase and role pair. TCA provides seeded relationship types and phrase and role pairs, but your administrator can create new ones as needed. See: Administering Relationships, Oracle Trading Community Architecture Administration Guide and Seeded Relationship Types, Phrases, and Roles, Oracle Trading Community Architecture Reference Guide.

Relationship Date Range

Both directions of a relationship share a start and end date. The start date signifies when the relationship starts, not necessarily when it was created. Likewise, the end date is when the relationship ends.

The relationship date range helps you analyze the history of an entity's relationships. For example, you can see that Joe used to work for Oracle in a subsidiary location for the past two years but has been working at Oracle headquarters since last month.

Relationship Group

In general, relationship groups are used to determine which relationship roles and phrases are displayed in specific application user interfaces. Groups can also be used to categorize roles and phrases for other functional uses.

Note: Relationship groups do not apply to Relationship Manager. All seeded and user-created relationship phrases are available.

Relationship Characteristics

Relationships have additional characteristics that relationship types determine.

Hierarchical Relationships

A hierarchical relationship ranks one entity above the other. For example, in an employment relationship, the employer is ranked above the employee. In the employment hierarchy, the employee would be a child that appears below its parent, the employer. Hierarchical relationships are created with phrase and role pairs that belong to a hierarchical relationship type.

Circular Relationships

If a relationship type allows for circular relationships, you can create a relationship from Party A to Party B to Party C and back to Party A. For example, Party A is a competitor of Party B, which is a competitor of Party C, which is a competitor of Party A.

Hierarchical relationships cannot be circular. For example, if Alan's manager is Jenny, and Jenny's manager is Chris, then Chris's manager cannot be Alan.

Nonhierarchical relationship types can either allow or prevent circular relationships. For example, marital relationships cannot be circular, while competitive relationships described above can.

Major Features

Relationship Manager provides these features for relationships between existing parties in the TCA Registry:

Relationship Hierarchy

Relationship Manager displays hierarchical relationships in a hierarchy, a visual representation of the how parties rank among one another within a given relationship type. For any party in the hierarchy, all parties displayed one level below are its children, and the party displayed a level above is its parent.

For any party in the hierarchy, you can:

If you batch load data from D&B or acquire the Enterprise Management global data product (GDP) through online purchase, you can view the provided corporate structure relationships for a specific business in a relationship hierarchy. See: Introduction to D&B.

Related Topics

Relationship Manager Overview

Party Relationship Management Process

Party Relationship Management Process

This diagram describes the general process flow of managing party relationships with the Relationship Manager.

the picture is described in the document text

  1. Search for the party that you want to view and manage relationships for and select the party from the search results. See: Searching for Parties and Viewing Results.

    Note: If you want to see a relationship hierarchy, keep in mind that the party you search for is the root of the hierarchy.

  2. View the party's overview information as well as the relationship types that it is involved in.

    From here, you have three options:

    • View relationships of selected relationship types. See: Viewing Relationships.

    • Create new relationships with a relationship type that the party is not currently involved in. See: Creating Relationships.

      After you create relationships, Relationship Manager takes you back to view the party's information and relationship types.

    • View the hierarchy of a hierarchical relationship type. See: Viewing Relationship Hierarchies.

  3. If you choose to view relationships, you can also:

    After you edit or create a relationship, Relationship Manager takes you back to view the relationships.

  4. If you choose to view a hierarchy, you can also:

    After you move parties or create relationships, Relationship Manager takes you back to the hierarchy view.

Related Topics

Relationship Manager Overview

Searching for Parties and Viewing Results

Use the Party page to search for and select the party that you want to view and manage relationships for. This search includes parties of type Organization or Person.

If you want to see a relationship hierarchy, keep in mind that the party you search for is the root of the hierarchy. For example, if you view the corporate hierarchy for Party B, you can see Party C as the subsidiary of Party B but cannot see that Party B is a subsidiary of Party A. For more information, see: Viewing Relationship Hierarchies.

From the search results, you select the party that you want and bring up the Overview page. View the party's overview and relationship type information, including:

If available, you can access more information about the party from the Additional Details field.

From the Overview page, you can choose to:

Note: You can also access the Overview page from other pages in Relationship Manager by clicking the party name.

Related Topics

Party Relationship Management Process

Relationships Overview

Viewing Relationships

Use the View Relationships page to view the relationships of the selected party. You can view relationships for some or all of the relationship types that the party is involved in.

The selected party is the subject party of all displayed relationships. You also see the object party name and Registry ID, the date range of the relationship, and the source of the relationship, for example user entered or third party. Even relationships with passed end dates are included.

To view relationships for a party:

  1. Navigate to the Overview page for the party that you want to view relationships for. See: Searching for Parties and Viewing Results.

  2. Select at least one relationship type and click the View Relationships button.

  3. The View Relationships page displays relationships for the party within your selected relationship types.

  4. You can choose to:

Related Topics

Party Relationship Management Process

Relationships Overview

Creating Relationships

Use the Create Relationships page to create new relationships between existing parties in the TCA Registry. You can choose to create relationships from three pages:

For example, a relationship phrase pair consists of: Organization is Headquarters Of Organization, and Organization is a Subsidiary Of Organization. If you are working on the party Oracle HQ, you would create a relationship with your party as the subject party and use the appropriate relationship phrase: Oracle HQ is the headquarters of Oracle Branch.

The reverse direction of the relationship, Oracle Branch as the subsidiary of Oracle HQ, is automatically created. You would see this direction of the relationship when you view relationships for Oracle Branch.

You can create multiple relationships between the same two parties, with different relationship phrases, even if relationship date ranges overlap. To use the same relationship phrase for multiple relationships between the same two parties, however, the relationship date ranges must not overlap.

To create relationships:

  1. Navigate to the Overview page for the party that you want to create relationships for. See: Searching for Parties and Viewing Results.

    Select the relationship type that you want to create relationships for and click the Go button. The available types that you can create relationships for exclude the types that the party is already involved in.

    To create relationships with a type that the party is already involved in, you must first view the relationships within that type. This restriction ensures that you review the existing relationships for a type so that you do not create duplicate relationships.

    After viewing current relationships, you select the type to create relationships for and click the Go button. The available types include only the types that you are viewing. See: Viewing Relationships.

    Tip: You can also create relationships for any party in a relationship hierarchy. See: Viewing Relationship Hierarchies.

  2. The Create Relationships page displays your selected relationship type as the type for the new relationship, and the selected party is the subject party.

  3. Select a relationship phrase and object party for the relationship, with respect to the subject party.

  4. Optionally change the start date of the relationship, which defaults with the current date.

    If you use the current date, the relationship's start time is the system time. If not, the start time is at the beginning of the start date.

  5. Optionally enter an end date.

    The relationship's end time is at the end of the end date.

  6. Click the Add Another Row button to create another relationship for the subject party with this same relationship type. Repeat steps 4 through 6.

  7. Click the Apply button.

    The confirmation takes you back to the page from where you chose to create relationships. Your new relationships are reflected in that page.

Related Topics

Party Relationship Management Process

Relationships Overview

Editing Relationships

Use the Edit Relationship page to edit a selected relationship for the party that you are viewing relationships for. This party is the subject party, which, along with relationship type and object party, cannot be changed. What you can update in the relationship are:

Any changes that you make to the direction of the relationship with your party as the subject applies to the opposite direction of the relationship. For example, the direction you are editing is: Oracle is the employer of Joe. If you end this relationship, Joe as the employee of Oracle also ends.

Tip: You can also edit hierarchical relationships by moving parties within the hierarchy of a relationship type, which changes the object party. See: Updating Relationships by Moving Parties in a Hierarchy.

To edit a relationship:

  1. Navigate to the View Relationships page for a party with the relationships that you might want to edit. See: Viewing Relationships.

  2. Click the Edit icon for the relationship that you want to edit.

    Note: You can edit only relationships with the User Entered source.

  3. In the Edit Relationship page, change the relationship phrase, start date, end date, or any combination of the above.

  4. Click the Apply button.

    The confirmation takes you back to the View Relationships page, where you can see the results of your changes.

Related Topics

Party Relationship Management Process

Relationships Overview

Viewing Relationship Hierarchies

Use the Hierarchy page to view a structured hierarchy of the relationships in a given hierarchical relationship type. For example, you get a visual representation of how a corporate structure is set up.

Your selected party is the root at the top of the hierarchy. You can see its children, or parties ranked lower in relationships, but not its parents.

The hierarchy represents a structure of relationships for the date that you specify in the As Of field. The hierarchy displays all relationships that fit both of these criteria:

This table shows an example of three relationships and their date ranges.

Relationship Start Date End Date
A January 1 January 10
B January 10 January 30
C January 15 None

This table shows examples of which relationships the hierarchy would display depending on the date in the As Of field.

As Of Included Relationships
January 1 A
January 10 B
January 15 B and C
January 30 C

For each node in the hierarchy, Relationship Manager displays the party's:

If you have batch loaded data or acquired the Enterprise Management GDP through online purchase, you can also view the corporate hierarchy that D&B provides. See: D&B Hierarchy.

To view a relationship hierarchy:

  1. Navigate to the Overview page for the party that you want to view relationship hierarchies for. See: Searching for Parties and Viewing Results.

    Note: Search for and select the party that you want as the highest level, or root, in the hierarchy.

  2. Click the Hierarchy icon for the relationship type that you want to view. Hierarchies are available only for hierarchical relationship types.

  3. Enter the date that you want to view the hierarchy for in the As Of field and click the Go button. By default, the hierarchy is displayed for the current date.

  4. To view the relationships within the hierarchy, click the arrows to expand or collapse levels.

    Tip: You can click the Focus icon for the party that you want to view as the root of the hierarchy. Clicking the name of any party in the hierarchy displays the party's overview information and does not render that party as the root of the hierarchy.

  5. Click the Details icon for the party that you want to view additional information for, if available.

  6. Repeat steps 3 to 5 as needed.

  7. From the Hierarchy page, you can choose to:

Related Topics

Party Relationship Management Process

Relationships Overview

D&B Hierarchy

The D&B hierarchy contains hierarchical corporate relationships that D&B provides through the Enterprise Management global data product (GDP). To access this hierarchy, you select the D&B Hierarchy relationship type, which includes the following relationship phrase pairs:

The Domestic Ultimate is the highest ranking entity within a country, while the Global Ultimate is the uppermost entity within the global corporate hierarchy. D&B creates a reporting structure from the lowest level of a corporate hierarchy to the Global Ultimate, providing a complete hierarchical organization structure.

When you purchase the Enterprise Management GDP for any entity, D&B provides a hierarchy containing all the related parents up to the Global Ultimate, but not other entities on the same or lower levels. For example, if you purchase data for a headquarters, then the provided hierarchy includes its Domestic and Global Ultimate, but not its branches or other headquarters reporting to the same Domestic or Global Ultimate. When you subsequently purchase the GDP for entities on the same or lower levels, then the hierarchical links to the original entity are established.

The structure of the D&B hierarchy depends on many additional factors, including the countries that the entities are in, the entity that you purchase the D&B data for, and so on. For more clarification and illustrations of other rules and regulations, see: D&B Hierarchy Examples.

Important: Do not use the Create Relationship API to create D&B hierarchy relationships. See: Create Relationship API, Oracle Trading Community Architecture Technical Implementation Guide.

Related Topics

Viewing Relationship Hierarchies

Data Products

D&B Hierarchy Examples

These examples illustrate how the information that you acquire from D&B appear in Relationship Manager as the D&B hierarchy.

Example 1

In this example, you purchase D&B data for a branch, which has its headquarters within the same country. This table shows the information that you acquire from D&B, including the corporate structure with respect to the branch.

Name Role Country
Vision Global Global Ultimate Japan
Vision US Domestic Ultimate US
Vision HQ Headquarters US
Vision Branch Branch US

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as shown in this table:

Hierarchy Level Name Relationship Phrase Parent Name
1 Vision Global None None
2 Vision US Global Subsidiary Of Vision Global
3 Vision HQ Domestic Subsidiary Of Vision US
4 Vision Branch Division Of Vision HQ

The Global Ultimate is always at the top of a D&B hierarchy, no matter which country it is in. The Domestic Ultimate is displayed above the headquarters because they are in the same country, and the Domestic Ultimate is the highest ranking within a country. The Domestic Ultimate is always in the same country as the entity that you purchase D&B data for, by definition.

Example 2

In this example, you purchase D&B data for a branch, which has its headquarters in another country. This table shows the information that you acquire from D&B, including the corporate structure with respect to the branch.

Name Role Country
XYZ Global Global Ultimate US
XYZ US Domestic Ultimate US
XYZ HQ Headquarters Japan
XYZ Branch Branch US

With the information that you acquire from D&B for the branch, Relationship Manager displays the D&B hierarchy as follows in this table:

Hierarchy Level Name Relationship Phrase Parent Name
1 XYZ Global None None
2 XYZ US Global Subsidiary Of XYZ Global
2 XYZ HQ Global Subsidiary Of XYZ Global
3 XYZ Branch Division Of XYZ HQ

The Domestic Ultimate and headquarters are displayed on the same level in the hierarchy because they do not necessarily have any relationship to each other. In the previous example, they are in the same country, so the Domestic Ultimate ranks higher by default. In this example, they are in different countries.

The branch appears only as a child of the headquarters, not also of the Domestic Ultimate, because the reporting structure is based on the headquarters/division and parent/subsidiary relationships only. The Global and Domestic Ultimates do appear in the hierarchy with respect to the entity that you purchased D&B data for.

Example 3

In this example, you purchase D&B data for Vision HQ from Example 1, which also has its headquarters in the same country. This table shows the information that you acquire from D&B, including the corporate structure with respect to Vision HQ as the branch.

Name Role Country
Vision Global Global Ultimate Japan
Vision US Domestic Ultimate US
Vision Parent Parent US
Vision HQ Subsidiary US

With the information that you acquire from D&B first for Example 1 and then 3, Relationship Manager displays the D&B hierarchy as follows in this table:

Hierarchy Level Name Relationship Phrase Parent Name
1 Vision Global None None
2 Vision US Global Subsidiary Of Vision Global
3 Vision Parent Domestic Subsidiary Of Vision US
4 Vision HQ Subsidiary Of Vision Parent
5 Vision Branch Division Of Vision HQ

As you subsequently purchase more D&B data for other entities within the Vision corporate hierarchy, you accordingly fill out its D&B hierarchy and establish more concrete reporting relationships with the hierarchy.

Updating Relationships by Moving Parties in a Hierarchy

Use the Hierarchy and Move Parties pages to move selected parties within a hierarchy, accordingly updating affected relationships. You can select one or more parties that you want to move under a new parent in the same hierarchy. The parties that you move and the new parent can be on any level of the hierarchy.

Each move ends the existing relationship and creates a new one based on the new structure in the hierarchy. The current date is the end date of the existing relationship as well as the start date of the new relationship.

Note: If you need to change start or end dates after moves, use the Edit Relationships page. See: Editing Relationships.

For example, the current hierarchy has Party A as the parent of Party B, which is the parent of Party C, which is the parent of Party D. You move Party C and select Party A as its new parent. This move ends the relationship for Party B as the parent of Party C and creates a new relationship for Party A as the parent of Party C. Party D moves along with Party C and remains a child of Party C.

This diagram shows the hierarchy before and after the move:

the picture is described in the document text

The relationship phrase of the moved relationship stays the same with respect to parties that you move. For example, if Party C was a subsidiary of Party B, it would then be the subsidiary of Party A, and Party D is still a subsidiary of Party C.

To update relationships by moving parties in a hierarchy:

  1. Navigate to the Hierarchy page for the hierarchy that you want to view and manage. See: Viewing Relationship Hierarchies.

    Important: To ensure accurate results when you move parties, use the current date as the as of date. All moves are based on the hierarchy as it is today.

  2. Select the party or parties that you want to move and click the Move button.

    Note: You cannot move parties with the relationship start date in the future.

  3. In the Move Parties page, expand the hierarchy as necessary to find the new parent party.

  4. Select the new parent party and click the Apply button.

    The confirmation takes you back to view the results of your move in the updated relationship hierarchy.

Related Topics

Viewing Relationship Hierarchies