This chapter covers the following topics:
Use Source System Management (SSM) to manage source systems that provide data for the TCA Registry, and determine how that data is displayed and used. The key features of SSM are:
Source Systems: Define the source systems you use to import data into the TCA Registry. The definition not only enables tracking between a TCA record and its data sources, but also provides operational links whereby updates can be sent and received in both directions between the TCA record and the source systems.
See: Source Systems Overview.
Single Source of Truth (SST): Data from multiple content sources, including source systems and end users, can coexist in the TCA Registry. Set up the SST record, in which attribute values within a record can come from different data sources. Oracle applications display and use the SST record for party profile entities. For the SST record, you also define privileges for users to overwrite data from source systems, and for source systems to overwrite user-entered data.
Security for Other Entities: Define user privileges to create user-entered records and update data from source systems. These rules apply only to specific entities other than those used in SST.
Related Topics
Administering Source System Management
Introduction to Administration
Tip: You should perform these administration steps when no users are logged into Oracle Applications. It is recommended that you do not frequently change the setup.
Prerequisites
Define the source system. See: Creating and Updating Source Systems.
If you have at least one source system enabled for Single Source of Truth, set up display rules to determine the SST record. See: Setting Up Display Rules.
Run the Third Party Data Integration Update program to regenerate the SST record. See: Third Party Data Integration Update Program.
Define user privileges to overwrite data from source systems in the SST record. See: Setting Up User Overwrite Rules.
Note: Perform this step only for attributes that have display rules with the Rank method and at least one source system ranked above User Entered.
Assign user overwrite rules using the HZ: User Overwrite Rules profile option. See: Profile Options and Profile Option Categories.
Whether you have source systems enabled for SST or not, you can define user privileges to create and update data in Other entities. See: Setting User Create and Update Rules.
Assign user create and update rules using the HZ: User Create and Update Rules for Other Entities profile option. See: Profile Options and Profile Option Categories.
Ask your system administrator to restart Apache or the Web server after you perform any of the setup steps so that your changes take effect.
Related Topics
Source System Management Overview
Source System Management maintains references between the TCA Registry and any defined source system, such as a legacy or third party system, that loads data into the Registry. The source ID, or ID of the record in that external system, is mapped to the Registry ID of the TCA record, such as the party or contact point.
For example, you load a record with the ID 12345 from the Gorman system into the TCA Registry. That record is assigned the Registry ID 100 in the TCA Registry. The source ID, 12345, is referenced to Registry ID 100.
Note: By defining source systems, you ensure that when you load data from that system, a mapping record is created to maintain the reference between the source ID and the Registry ID.
Source System Management allows multiple source system references to one Registry ID. Examples of TCA entities that support multiple source references include the Party, Location, and Customer Account entities. The mappings can be between one Registry ID and source IDs from multiple source systems, or, if enabled, between one Registry ID and multiple source IDs from the same source system.
For example, Registry ID 100 is mapped to source ID 12345 from the Gorman system and source ID 99999 from the Elcaro system. If multiple references from the same source is allowed for the entity, Registry ID 100 can be mapped to source IDs 12345 and 67890 from the same Gorman system.
By mapping the IDs from the sources of your customer data to the TCA Registry IDs, your source systems can continue to operate, sending updates to and receiving updates from TCA. This operational mapping between the TCA Registry and multiple source systems allows you to:
Consolidate multiple customer databases, stored in various applications across different platforms, into the TCA Registry.
Create, maintain, share, and leverage an operational, single view of your customer information, or customer hub, across your enterprise.
Related Topics
Source System Management Overview
This example shows how you can implement and use source systems.
You define a source system, for example, Gorman.
You load data from an external system into the TCA Registry, specifying both the source system name and source ID.
For example, you load a record for a party named Joe Smith from Gorman. You specify that the source system name is Gorman and that the source ID, or ID of Joe Smith in Gorman, is 12345.
Note: If you specify only the source ID, the mapping is only inserted for customer account level entities with unique references, with the source system name defaulted to UNKNOWN.
Users of an application that has implemented SSM can specify the source system name and source ID when they create or update records in the TCA Registry. They can also query records in the Registry using the source system name and source ID.
For example, the user enters a record for the party named Joe Smith and specify that the source system is Gorman and the source ID is 12345. Then, the user can query for Joe Smith using 12345 as the source ID and Gorman as the source system name.
You can encounter additional situations, for example:
When a source system is no longer used to provide data to one or more entities, you update the source system definition from Step 1 to indicate that the source system is inactive.
This inactivation prevents additional mapping records from being created for that source system and all TCA entities. Existing mappings to the source system remain active.
For example, you do not want to continue maintaining mappings between the Gorman source system and the TCA Registry for any new loaded data. You inactivate the Gorman system. The mappings between the Joe Smith record in the TCA Registry and the Joe Smith record in Gorman remain untouched.
When a party record is inactivated in the source system, the reference between the source ID and the Registry ID is not affected.
For example, the Joe Smith record in the Gorman system is inactivated. The mapping between Gorman 12345 and Joe Smith's Registry ID remains unchanged.
When a party record is inactivated in the TCA Registry, the reference between the source ID and the Registry ID is not affected. A BES callout for the party record inactivation is raised and applications that subscribe to the event are notified of the inactivation.
For example, the Joe Smith record in the HZ_PARTIES table is inactivated. The mapping between Gorman 12345 and Joe Smith's Registry ID remains unchanged. A BES callout from HZ_PARTIES is raised due to the inactivation, notifying subscribing applications.
Related Topics
To administer source systems, you can:
Source systems can be one of these types:
Spoke: A spoke system, such as a legacy system.
Purchased: A third party data provider, such as D&B, that you need to purchase data from.
Source system references are maintained only for active source systems. Only source systems defined as enabled for Single Source of Truth are available to provide data for the SST record. See: Single Source of Truth Overview.
Related Topics
The HZ_ORIG_SYS_MAPPING table stores information about source systems and the TCA entities that the systems can provide data for. The HZ_ORIG_SYSTEM_REFERENCES table stores information about the references between source IDs and TCA Registry IDs.
For both tables, you can set up flexfields to store additional information. Flexfields are additional data fields that can be customized for your organization's business needs. You must compile the flexfield Source System Entity Mapping (HZ_ORIG_SYS_MAPPING) for the Receivables (AR) application before using it. See: Overview of Setting Up Flexfields, Oracle E-Business Suite Flexfields Guide.
If flexfields in the HZ_ORIG_SYS_MAPPING table are set up, you can enter flexfield values when you define entity settings as part of creating or updating source systems.
For example, you set up a First Import Date flexfield to store the date when the source system is first used to import data. You then create a source system, select First Import Date for additional details, and enter a date for specific entities. See: Creating and Updating Source Systems.
Related Topics
Even though you cannot enter nonalphanumeric characters for the source system code, you can for the source system name and description. Use the name and description to provide information that is more descriptive than the code. Alternatively, you can enter the same value for the source system code and name.
Source system codes are used in the mapping records, for references between source IDs and Registry ID, for example to query mapping records. Users should enter the source system code when they load data into the TCA Registry.
Important: You cannot update the source system code or type after you first define them.
You can also create a source system in the context of any of the following:
Party
Party Site (Address)
Organization Contact Purpose
Contact Points - Phone Numbers, Email, and URL
Account
Accounts
Account Contacts and Account Site Contact
Account Site
Account Site Purpose
You can specify the status of the source system only when you update, not create, it.
See: Single Source of Truth Overview.
The source system can provide data for all displayed entities. Optionally select the type of additional details to enter for the entities. Aside from the seeded Source System Table Name, other additional details are available if flexfields are set up. See: Flexfields for Defining Entities.
Note: For any entity, you cannot allow multiple references from the D&B source system to one TCA record.
Related Topics
The overview provides information about the source system and settings for entities. You can update most of this information. See: Creating and Updating Source Systems.
Related Topics
Data from source systems coexist with user-entered data as separate records in the TCA Registry. For the party profile entities, Organization Profile and Person Profile, you can set up a Single Source of Truth (SST) record for a single view of the most accurate party profile information across data sources. The attributes in the SST record can contain information from different data sources, depending on the defined display rules.
Note: If the TCA Registry does not contain data from source systems, then you do not need to set up Single Source of Truth.
Oracle applications display and use the Single Source of Truth record for organization and person party profile information. If SST is not set up, or if the setup does not allow for data from source systems, then Oracle applications always use the user-entered information.
Note: Even though source system data, for example all purchased data from D&B, are stored in TCA tables, some information might not appear in user interfaces, based on SST display rules.
Display rules determine how the Single Source of Truth record gets its attribute values. For each attribute, you define the rule based on a display method:
Rank: Attribute value is from the highest ranked data source that contains data.
For example, D&B is ranked as the highest source for the D-U-N-S Number attribute, followed by user entered. For party 1, if both D&B and user-entered records have a D-U-N-S Number attribute value, then the SST record takes the value from D&B. If party 2 has only a user-entered record, then the user-entered D-U-N-S Number is used.
Note: If no data source has a value for a specific attribute, Oracle applications display nothing and the user can enter a value for that attribute.
Date: Attribute value is from the data source with the most recently updated value.
For each party in the TCA Registry, Oracle applications uses the SST display rule for each attribute to determine the value to display in user interfaces.
To maintain accurate information in the TCA Registry, you can define rules that control data overwrite in the SST record. Overwrite rules do not apply to attributes defined with the Date display method.
Note: Only source systems ranked higher than User Entered can be included in these rules.
User overwrite rules: Determine user privileges to overwrite data from source systems in the SST record.
For example, data sources are ranked as follows for the Last Name attribute:
D&B
User Entered
Gorman
For a specific party, the user-entered value is Smyth, and the D&B value is Smith. Due to the ranking, Smith is used as the SST value in Oracle applications.
Only D&B, ranked higher than User Entered, is available for user overwrite rules, and a rule is defined to allow users to overwrite last names from D&B. If this rule is assigned to Joe, then he can overwrite the SST last name Smith with Smythe in an Oracle application. The user-entered and SST records now have Smythe, and the D&B record remains with Smith.
Important: If a user is not assigned to a user overwrite rule, then the default behavior allows him to overwrite all SST values, even those from a data source ranked higher than User Entered. To enforce the data source ranking, you must create and assign a user overwrite rule that prevents overwrite of all data sources ranked higher than User Entered.
For example, you can create one user overwrite rule that prevents overwrite of all data sources, for all attributes with the Rank display method. Essentially, the rule mirrors and enforces the display rule for all those attributes. Assign this rule to the site level, so that it applies to all users by default. For the above example, this rule would prevent overwrite of D&B values for the Last Name attribute.
If you want to allow overwrite for specific users, you can then define additional user overwrite rules as desired, and assign the rules at the user or responsibility level. For the above example, you would create a rule that allows overwrite of last names from D&B, and assign the rule to Joe or his responsibilities.
Source system overwrite rules: Determine which source systems can provide new data and overwrite existing user-entered data in the SST record. The rules apply only to user-entered data that previously overwrote source system data, according to user overwrite rules.
For example, Joe has overwritten the D&B value for the Last Name attribute in the SST record, as the user overwrite rule assigned to him allows. Only D&B, ranked higher than User Entered, is available for the source system overwrite rule, and the rule for Last Name grants D&B overwrite privileges.
If a new last name, Smeeth, is acquired from D&B for that party, then Smeeth will overwrite Joe's value, Smythe in the SST record, and replace Smith in the D&B record. The user-entered record with Smythe is untouched.
If source system overwrite is not allowed for D&B, then Smeeth replaces only Smith in the D&B record. The SST and user-entered record remain with Smythe.
Note: The source system value does not overwrite the user-entered value if the source system value has not changed, for example, if the newly acquired D&B data still has Smith as the last name.
Related Topics
Single Source of Truth Example for Rank Display Method
Administering Single Source of Truth
Source System Management Overview
Some of the attributes in the party profile entities are grouped and displayed together, separated by slashes, for example CEO Name / CEO Title. You apply the same display and overwrite rules to the entire group.
Each attribute group has a primary attribute. When the Single Source of Truth record is regenerated after you run the Third Party Data Integration Update program, all nonprimary attributes in each group are populated from the same data source as their primary attribute, even if that source gives the nonprimary attributes a null value. See: Third Party Data Integration Update Program. This functionality applies to both the Rank and Date display methods.
If the highest ranked source has no data for the primary attribute, then the SST record takes the value from the next highest ranked source that does. If none of the data sources has data for the primary attribute, the other attributes in the group are treated like regular individual attributes in the SST record.
Even though the same overwrite rule applies to the entire group, an attribute can be updated without requiring the other attributes in the group to be also updated by the same data source.
Important: The SIC Code and SIC Type group has additional validations. These attributes must always have values from the same data source, and both must have values or none at all.
The SST record uses the data source that meets both of these requirements:
Is the highest ranked or has the last updated value for the primary SIC Code attribute
Has values for both attributes
This table shows the Organization Profile attribute groups, including the primary attributes and the other attributes in each group.
| Primary Attribute | Other Attributes in Group |
|---|---|
| CEO Name | CEO Title |
| D-U-N-S Number | Displayed D-U-N-S Party Identifier Enquiry D-U-N-S Number |
| Headquarters or Branch Indicator | Branch Indicator |
| Local Activity Code | Local Activity Code Type |
| Local Business Identifier | Local Business Identifier Type |
| Minority Owned Indicator | Minority Owned Type |
| Organization Name | Phonetic Organization Name |
| Principal Name | Principal Title |
| SIC Code | SIC Code Type |
This table shows the Person Profile attribute groups, including the primary attributes and the other attributes in each group.
| Primary Attribute | Other Attributes in Group |
|---|---|
| Person Identifier Number | Person Identifier Type |
Related Topics
Attribute Groups Example for Rank Display Method
Single Source of Truth Overview
This example shows how the Single Source of Truth setup for some party profile attributes affect the functionality in Oracle applications. Some of these attributes are primary attributes that belong to attribute groups, but the example treats the primary attributes as if on their own. For an example of attribute group setup, see: Attribute Groups Example for Rank Display Method.
For the Organization Profile entity, you set up display rules with the Rank method for the attributes shown in this table. This table also shows the available records for a specific party and the values that populate the Single Source of Truth record based on the setup.
| Attribute | Data Source Ranking | User-Entered Value | D&B Value | SST Value |
|---|---|---|---|---|
| Organization Name | 1. D&B 2. User Entered |
Company A | Company A | Company A |
| Year Established | 1. D&B 2. User Entered |
1992 | 1990 | 1990 |
| CEO Name | 1. D&B 2. User Entered |
Joe Lee | <Not Available> | Joe Lee |
| Total Employees | 1. User Entered 2. D&B |
<Not Available> | 100 | 100 |
| SIC Code | 1. User Entered 2. D&B |
2520 | 2521 | 2520 |
User Overwrite Rule
This table shows a user overwrite rule for the five attributes.
| Attribute | Source Systems That Users Can Overwrite |
|---|---|
| Organization Name | <None.> |
| Year Established | D&B. |
| CEO Name | D&B. |
| Total Employees | <None. The rule cannot be defined because D&B is not ranked higher than User Entered.> |
| SIC Code | <None. The rule cannot be defined because D&B is not ranked higher than User Entered.> |
User Enters Data
This table describes what happens when a user, who is assigned the above user overwrite rule, tries to enter data. The table shows the SST values from above, the data sources of each value, the highest ranked data sources, as well as the new user-entered values and the new SST values, whether the user updated them or not.
| Attribute | Highest Ranked Data Source | Current SST Data Source | Current SST Value | New User Entered Value | New SST Value |
|---|---|---|---|---|---|
| Organization Name | D&B | D&B | Company A | Company B | Company A |
| Year Established | D&B | D&B | 1990 | 1992 | 1992 |
| CEO Name | D&B | User Entered | Joe Lee | Joey Lee | Joey Lee |
| Total Employees | User Entered | D&B | 100 | 1000 | 1000 |
| SIC Code | User Entered | User Entered | 2520 | 2522 | 2522 |
The user overwrite rule applies only to attribute values that have D&B as the current SST and highest ranked data source. This table describes which attributes the rule applies to.
| Attribute | Rule Definition | Rule Is Applied | Description |
|---|---|---|---|
| Organization Name | Prevent Overwrite | Yes | The user overwrite rule prevents the user-entered value from overwriting the highest ranked D&B value in SST record. |
| Year Established | Allow Overwrite of D&B | Yes | The user overwrite rule allows the user-entered value to overwrite the highest ranked D&B value. |
| CEO Name | Allow Overwrite of D&B | No | The current SST data source is already user entered, and data still does not exist for the highest ranked D&B source, so the user can modify the user-entered record and accordingly update the SST record, regardless of the user overwrite rule. |
| Total Employees | Prevent Overwrite | No, D&B is not ranked higher than User Entered, so the rule is not defined | Even though the current SST value is from D&B, the user can overwrite it because user entered is the highest ranked source. |
| SIC Code | Allow Overwrite of D&B | No, D&B is not ranked higher than User Entered, so the rule is not defined | The current SST data source is already user entered, and the highest ranked source is user entered, so the user can definitely update the SST value. |
This table shows the source system overwrite rule for the five attributes.
| Attribute | Source Systems That Can Overwrite User-Entered Data |
|---|---|
| Organization Name | <None> |
| Year Established | D&B |
| CEO Name | <None> |
| Total Employees | <None. The rule cannot be defined because D&B is not ranked higher than User Entered.> |
| SIC Code | <None. The rule cannot be defined because D&B is not ranked higher than User Entered.> |
New D&B Data is Acquired
This table shows what happens when D&B data is subsequently acquired. The table shows the SST values from above, the data sources of each value, the previous data sources, the highest ranked data sources, as well as the new D&B values and the new SST values, whether D&B updated them or not.
| Attribute | Highest Ranked Data Source | Previous Data Source | Current SST Data Source | Current SST Value | New D&B Value | New SST Value |
|---|---|---|---|---|---|---|
| Organization Name | D&B | D&B | D&B | Company A | Company AA | Company AA |
| Year Established | D&B | D&B | User Entered | 1992 | 1991 | 1991 |
| CEO Name | D&B | User Entered | User Entered | Joey Lee | Joseph Lee | Joseph Lee |
| Total Employees | User Entered | D&B | User Entered | 1000 | 2000 | 1000 |
| SIC Code | User Entered | User Entered | User Entered | 2522 | 2520 | 2522 |
The third party overwrite rule applies only to attributes that have a current user-entered value that previously overwrote a highest ranked D&B value. This table describes which attributes the rule applies to.
| Attribute | Rule Definition | Rule Applies | Description |
|---|---|---|---|
| Organization Name | Prevent Overwrite | No | The SST record always had a D&B value, which is highest ranked, so the new D&B value updates the SST record. |
| Year Established | Allow D&B to Overwrite | Yes | The current user-entered value previously overwrote a highest ranked D&B value in the SST record. The rule allows the new D&B value to overwrite the user-entered value. |
| CEO Name | Prevent Overwrite | No | Even though the current SST value is user entered and the highest ranked source is D&B, the current SST value did not previously overwrite a D&B value. The new D&B value can overwrite the user-entered value because D&B is the highest ranked source. |
| Total Employees | Prevent Overwrite | No, D&B is not ranked higher than User Entered, so the rule is not defined | Even though the current SST value is user entered and previously overwrote a D&B value, D&B is not the highest ranked source. The new D&B value cannot overwrite the user-entered value because the highest ranked source is user entered. |
| SIC Code | Prevent Overwrite | D&B is not ranked higher than User Entered, so the rule is not defined | The SST record always had a user-entered value, which is highest ranked, so the new D&B value cannot update the SST record. |
This example shows how attribute groups in the SST record are populated and subsequently updated. For more information, see: Attribute Groups.
This table shows the primary attribute and the other attribute in the group.
| Primary Attribute | Other Attribute in Group |
|---|---|
| CEO Name | CEO Title |
| SIC Code | SIC Code Type |
This table shows the available records for a specific party and the values that populate the Single Source of Truth record based on display rules with the Rank method. The setup for the primary attribute determines the setting for the other attribute in the group.
| Attribute | Data Source Ranking | User-Entered Value | D&B Value | SST Value |
|---|---|---|---|---|
| CEO Name | 1. D&B 2. User Entered |
Jennie Lee | Jennifer Lee | Jennifer Lee |
| CEO Title | 1. D&B 2. User Entered |
CEO | <Not Available> | <None> |
| SIC Code | 1. User Entered 2. D&B |
<Not Available> | 2952 | 2952 |
| SIC Code Type | 1. User Entered 2. D&B |
<Not Available> | 1977 SIC | 1977 SIC |
Primary attributes in the SST record are populated like individual attributes, but the other attributes in the group are populated based on the primary attributes' data source. For example, the CEO title attribute takes the D&B value, which is nothing, because the primary attribute, CEO name, takes a D&B value.
Important: The SIC Code and SIC Type group has additional validations. At all times, they both must have values from the same data source or none at all.
User Overwrite Rule
This table shows a user overwrite rule for the four attributes. The setup for the primary attribute determines the setting for the other attribute in the group.
| Attribute | Source Systems That Users Can Overwrite |
|---|---|
| CEO Name | D&B |
| CEO Title | D&B |
| SIC Code | <None> |
| SIC Code Type | <None> |
User Enters Data
This table describes what happens when a user, who is assigned the above user overwrite rule, tries to enter data. The table shows the SST values from above, the data sources of each value, the highest ranked data sources, as well as the new user-entered values and the new SST values, whether the user updated them or not.
| Attribute | Highest Ranked Data Source | Current SST Data Source | Current SST Value | New User Entered Value | New SST Value |
|---|---|---|---|---|---|
| CEO Name | D&B | D&B | Jennifer Lee | <No Action> | Jennifer Lee |
| CEO Title | D&B | D&B | <None> | CEO | CEO |
| SIC Code | User Entered | D&B | 2952 | 2999 | 2999 |
| SIC Code Type | User Entered | D&B | 1977 SIC | 1987 SIC | 1987 SIC |
The user overwrite rule applies only to attribute values that have D&B as the current SST and highest ranked data source. This table describes which attributes the rule applies to and how attributes within a group can be updated separately except for the SIC code and type group.
| Attribute | Rule Definition | Rule Applies | Description | New SST Data Source |
|---|---|---|---|---|
| CEO Name | Allow Overwrite of D&B | Yes | The user does nothing and leaves the D&B value in the SST record. | D&B |
| CEO Title | Allow Overwrite of D&B | Yes | Even though the primary attribute, CEO name, is still a D&B value, the user can overwrite the D&B CEO title in the SST record. | User Entered |
| SIC Code | Prevent Overwrite | No | Even though the current SST value is from D&B, the user can overwrite it because user entered is the highest ranked source. | User Entered |
| SIC Code Type | Prevent Overwrite | No | The user must also overwrite the D&B SIC code type in the SST record because SIC code and type must always have the same data source. | User Entered |
To administer Single Source of Truth:
Define and update display rules for Organization Profile and Person Profile entities. See: Setting Up Display Rules.
If the display method is Rank, you can define source system overwrite rules for the same attributes that you define display rules for.
For display rules changes to take effect, you must run the Third Party Data Integration Update program. You can run the program immediately after defining display rules, or submit the program at any time. See: Third Party Data Integration Update Program.
Define and update user overwrite rules. See: Setting Up User Overwrite Rules.
Related Topics
Single Source of Truth Overview
To define Single Source of Truth display and source system overwrite rules:
View attributes for the entity you want to work on.
Select the attributes to update display rules for.
You can define the same rule for all or some attributes, or use a different rule for every attribute.
Select the SST display method.
Select data sources. See: Selecting Data Sources.
For the Rank display method, also define the source system overwrite rule. See: Overwrite Rules for Attributes with Rank Method.
Run the Third Party Data Integration Update program. See: Third Party Data Integration Update Program.
Note: Multiple attributes separated by slashes belong to the same attribute group. The same display and source system overwrite rules apply to all attributes in the group. See: Attribute Groups.
Select data sources for either the Rank or Date display method.
Note: For both methods, the User Entered data source must always be selected for SST.
For the Rank method, you must also rank the selected sources.
For the data source ranking, only sources in the Ranked Data Sources box are considered for the Single Source of Truth record, with the uppermost as the highest ranked.
The ranking not only determines the SST attribute values, but also:
Which source systems can potentially overwrite user-entered data in the SST record. For the selected attributes, you can define the source system overwrite rule only with systems ranked higher than User Entered.
The overwrite rule between source systems for the selected attributes. For example, for D-U-N-S Number, D&B is ranked above the Gorman legacy system, and the SST record currently has a D-U-N-S Number from Gorman. If you later acquire a D-U-N-S Number from D&B for this party, then the D&B value overwrites the Gorman value in SST because D&B is ranked higher.
Related Topics
Creating and Updating Source Systems
Administering Single Source of Truth
Single Source of Truth Overview
Use the Third Party Data Integration Update program to regenerate the Single Source of Truth record for all parties in the TCA Registry. The new SST values are based only on the display rules and the existing availability of data. It does not matter which data sources the current SST values come from, and none of the overwrite rules apply.
Run this program at the end of the display rule update process, or at a later time from Standard Request Submission. Your display rule changes do not take effect in Oracle applications until you run this program.
Note: You do not need to run this program after updating only overwrite rules. Updated overwrite rules automatically apply to new records, user actions, or data import from source systems.
Define display rules for the first time or update display rules. See: Setting Up Display Rules.
Commit Size: Enter the number of new or updated records to be included in each commit to the database.
Number of Workers: Enter the number of parallel workers that you want to use for this program. Workers are processes that run at the same time to complete a task that would otherwise take longer with a single process.
Run Mode: Select the mode in which the program is to be run, either Regenerate Single Source of Truth for all parties, or Generate underlying infrastructure packages only. Select Generate underlying infrastructure packages only to generate only the packages. Selecting this option does not regenerate the SST record.
Define as many user overwrite rules as needed. Each rule includes all attributes from the party profile entities. You can give the same setting to all or some attributes, or use a different setting for every attribute. See: Overwrite Rules for Attributes with Rank Method.
Note: Multiple attributes separated by slashes belong to the same attribute group. The same user overwrite privilege applies to all attributes in the group. See: Attribute Groups.
Note: A seeded rule specifies that the user can never overwrite a D-U-N-S Number from the D&B data source. You cannot modify this rule, and the D-U-N-S Number attribute is not available for you to include in other user overwrite rules.
Use the HZ: User Overwrite Rule profile option to assign rules. See: Profile Options and Profile Option Categories. If you are assigning only at the site level, you need to define only one user overwrite rule. If you do not define nor assign any rules, the default functionality allows user overwrite of all attributes.
You can delete user overwrite rules at any time. If you delete a rule that is assigned to users, the rule from the next assigned level would then apply to these users. For example, rules are assigned at the user, application, and site levels. If you delete the user level rule, the application level rule takes effect.
Related Topics
Administering Single Source of Truth
Single Source of Truth Overview
Other entities are entities other than the party profile entities used in Single Source of Truth. This table maps the Other entities to their relevant tables.
User create and update rules determine user privileges to create new data for each Other entity, and to update Other entity data from source systems. Even if no data currently exists for an Other entity, users cannot create data for that entity if their assigned rule prevents it. Users can always update existing user-entered records for all Other entities.
Note: For location-based tax validation purposes, an address cannot be updated when transactions are associated with the address, or party site. When you acquire new address information from source systems, if the new address significantly differs from the existing address, the old address would be deactivated. The new, active third party address replaces the previous address for the party site.
Source System Management Overview
Administering Source System Management
Define as many user create and update rules as needed. Each rule includes all Other entities, and you set create and update privileges at the entity level.
Use the HZ: User Create and Update Rule for Other Entities profile option to assign rules. See Profile Options and Profile Option Categories. If you are assigning only at the site level, you need to define only one user create and update rule. If you do not define nor assign any rules, the default functionality for all Other entities allows users to create data and but not to update any source systems data.
You can delete rules at any time. If you delete a rule that is assigned to users, the rule at the next assigned level would then apply to these users. For example, rules are assigned at the user, application, and site levels. If you delete the user level rule, the application level rule takes effect.
Related Topics