This chapter covers the following topics:
The Party Merge and Account Merge functionalities are part of the Data Quality Management (DQM) tools provided by Trading Community Architecture (TCA). You can use party and account merge to identify and resolve duplicates that exist in the Trading Community registry.
Use the party merge Web service to merge parties and retrieve party merge information and the account merge Web service to retrieve account merge information. The Party Merge Web service has two operations – the Create Party Merge Request, to create a request for merging parties and the Get Party Merge Details to retrieve details about a party merge. The Account Merge Web service has one operation – Get Account Merge Details to retrieve details about a customer account merge. See: Web Services Implementation Overview, Oracle Trading Community Architecture Administration Guide.
Different applications across the Oracle E-Business Suite have data associated with both parties and customer accounts. Any references to parties and accounts are updated when parties or accounts are merged. This ensures data integrity across the Oracle E-Business Suite.
This chapter describes the results of the party and account merge processes initiated in Oracle E-Business suites applications. For most applications the descriptions include what information is merged or transferred and any validations that occur before completion of the process.
Knowing how data throughout the Oracle E-Business Suite is affected when you run either the Party Merge or Account Merge processes helps you determine:
Impact of running the merge process.
Changes to the data for parties and customer accounts.
This information is intended for end-users who are interested in understanding the implication of running either a party merge or an account merge process.
This document assumes that the reader understands the basic concepts of the various applications in the E-Business Suite. For detailed information regarding the entities affected during merge, please refer to respective application user's guide and the electronic technical reference manual (eTRM) located in My Oracle Support
Related Topics
Party Merge Impact Reference by Application
Account Merge Impact Reference by Application
This section provides details regarding how party merge affects the data in different applications within the e-Business Suite.
When parties are merged, any records containing different types of balances such as profitability balance, expense balance, transaction balance and summarized (YTD) balances, for a party are transferred to the master party.
Intercompany organizations are entities that reference the party record in TCA. When parties are merged, the Intercompany organization and related tables are transferred to the master party. The information that will be transferred include:
Intercompany transaction batches
Intercompany transaction headers
Intercompany transaction distribution lines
Intercompany customer associations
Intercompany supplier associations
The merge will be vetoed if the party to be merged is an Intercompany organization with existing transactions applied, and if the party is not associated to the same legal entity as the master party.
The following information transfers to the master party record:
Pricing Qualifiers: Parties and party sites can be used as pricing qualifiers in Advanced Pricing. Any record referring to the candidate party as the pricing qualifier is updated to look at the master party record.
The pricing qualifier information is transferred to the master party record after ensuring that a similar qualifier does not exist for the master party.
The following information is transferred to the master party:
The Customer link on an Oracle Applications login account, such as any login pointing to the old party will now be pointing to the new party.
Documents attached to the candidate party.
Bank and branch information is stored in the Cash Management application. If any of the parties that have been identified for merge are either banks or branches, the merge will be vetoed.
Information regarding delinquencies associated with a party is stored in the Collections application. When parties are merged, the delinquency information is transferred to the master party.
When two parties are merged, the following information is transferred to the master party:
Collections scores for delinquencies, sites, accounts and parties
Delinquencies of a party
Collections communications sent to parties; party, account and site
Strategies applied to parties, accounts, and sites in order to recover debt
Promises to pay debt made by customers.
The following information merges with the master party record:
Information about documents or manuals provided by the supplier of a product
Additional information about the party that supplied the document or manuals
Additional information about the party that received the documents
Document subscription information such as subscription type, frequency, and so on that is associated with a party
Information about the revisions to a document and details about the party that approved the revision
Information about standard and non-standard maintenance operations associated with parties
Current and draft routes which consist of one or more operations
The following is transferred to the master party record:
Information required to perform the following types of transactions with a third party organization: service, exchange, loan, and borrow
The merge takes place only if the master party does not have similar dependent records
If Oracle Purchasing application has been installed, then the subscription information is associated to a supplier and not a party. Therefore, the merge operation does not take place.
If Human Resources is installed, then the revision of documents and the approver of a revision comes from the HR tables. Therefore, the merge operation does not take place.
When parties are merged the following information is transferred to the master party:
Current versions of all contracts
The following information is merged into the master party record:
Temporary placement of fulfillment content to be previewed and then either submitted for dispatch or deleted associated with the duplicate party
Information requests that have been processed by the Fulfillment Server for the duplicate party
Fulfillment content history for every content corresponding to a template
During party merge, all interactions associated with the duplicate party are transferred to the master party record.
Resource manager allows users to access and define CRM specific resource attributes for parties. Therefore, when two parties are merged, additional resource information defined for the party is transferred to the master party.
The resource is not transferred if the master party already has a resource defined in the resource manager application.
The following information transfers to the master party record:
Tasks that are associated with the duplicate party
Contact information associated with the tasks
Task audit information
Task references associated with the duplicate party
Notes and note context associated with the party
If the party records are identified as duplicates, then the territory definition values that are based on parties are transferred.
If the party has an associated named account, then an error is raised and party merge cannot be completed. In other words, if a party is assigned to a territory group that party cannot be merged to another party.
In User Management, you can define approvers for a given organization (customer). These approvers are responsible for processing account requests for this customer. The following changes can be seen in User Management when party merge process takes place:
Pending requests to be approved are transferred from the duplicate party to the master party.
All of the approvers associated with the duplicate party are inactivated.
If no approver list is defined for master party, then the requests are assigned to the default list.
The Customer Care merge process transfers information to the master party about relationship plans, which allow companies to automate their customer service practices and provide a proactive and consistent way to take care of the customers needs.
If no relationship plans exist on the master party record, then the relationship plan from the duplicate party is transferred to the master party.
If the duplicate and master parties have identical relationship plans, then the relationship plan from the duplicate party is merged to the master party's relationship plan. Otherwise, the duplicate party's relationship plan transfers to the master party.
The E-Business Tax application stores transaction tax information related to the tax setup of a party or a party site, or both. The tax information stored include fiscal tax classifications, tax registrations, exemptions, tax accounts, and subscription options.
When parties are merged in TCA, the following changes will take place:
Tax classifications will be merged if there is an equivalent record in the master party; otherwise, the information will be transferred.
Tax accounts will be merged if there is an equivalent record in the master party; otherwise, the information will be transferred.
The E-Business Tax's tax registration record will be copied rather than transferred so that historic data held in the Tax Repository is retained for audit purposes.
Note: Exemptions will neither be transferred nor merged to avoid conflicting exemptions from appearing in the tax setup for the master party.
The merge will be vetoed when the parties' E-Business Tax registrations for a given Tax, Tax Jurisdiction, and Tax Regime differ in key registration attributes: registration number, set invoice values as tax inclusive, and set for self assessment or reverse.
Note: Veto will not occur for differing TCA registration numbers. The TCA registration number of the merge-to party record will be kept on the surviving party record.
The following information is transferred in case of person-party merge:
Person information, such as graduation date, field of study, area of specialization, school name, and degrees
A person's biosketch information
Information pertaining to a person's role and percentage effort on a given proposal
Information pertaining to a person's completed proposals and awards
The following information is transferred in case of organization-party merge:
The organization along with its multiple locations
If the master party has any information associated with it in Grants Proposal product, then the merge cannot be completed.
The following information transfers to the master party record:
Corresponding personal information for employees, applicants, ex-employees, ex-applicants, contacts and other people
Records from educational institutions that a person is attending or has attended and the dates of attendance
Competence information or description of knowledge, skills, abilities or other characteristics of a person
Information about interviews and other events related to a person
Address and phone number information for the following people:
Current or former employees
Current or former applicants
Employee contacts
Records of educational qualification, certificates, licenses, and so on for a person
Previous employment information for a person
The following information transfers to the master party record:
Item instance's associated parties, its locations (if the location is a party site) and contacts
System's install location and all of the contacts
Transactions pertaining to the line details, system, party associations and location
The information is transferred only if an equivalent record does not exist for the master party.
You cannot merge a party that is defined as the internal party in Install Base Install parameter setup. The Install Base application setup requires that you set up the party owning the enterprise data as an internal party in the Install Base installation parameters table. After you define this party as an installation parameter, you cannot merge the party with any other party. This preserves the integrity of the current data in the Install Base data.
If you attempt to merge this internal party with another party, then an exception will be raised and the merge will not take place.
The following information is affected when party merge takes place:
Duplicate party's shopping lists will always be transferred to the master party.
Pre-IBE.O (11.5.9) If the master party does not have express checkout setting, the duplicate party's records will be transferred. If the master party already has a record in this table, then the duplicate party's record will be deleted.
IBE.O (11.5.9) Duplicate Party's record will always be deleted.
If a master party does not have a minisite access restriction, the duplicate party's access restrictions (records) are transferred to the master party. If master party already has minisite party access restrictions, then the duplicate party's record will be end-dated.
If the shared cart is shared with both the master party and the duplicate party, the shared cart record for the duplicate party will be deleted from this table. Otherwise all the shared carts will be transferred to the master.
Duplicate party's active cart will always be deleted.
When parties are merged, the following entities are transferred to the master party from the merge-from party:
Payment preferences of suppliers and supplier addresses
Business classifications used in supplier profile management
Supplier profile change requests for prospective and approved suppliers
When parties are merged, the following entities are neither merged nor transferred to the master party from the merge-from party:
Requests from the supplier to assign bank account to a supplier address
Change requests from supplier on supplier addresses
Notes for supplier addresses
Temporary supplier address data created during upgrade
Change requests from supplier on contacts
Temporary supplier contact data created during upgrade
Change requests from supplier on supplier address and supplier contacts
Supplier registration data
Temporary supplier data created during upgrade
Vetoed if the merged-from party is identified as the enterprise party created by iSupplier to represent the deploying company
Vetoed if there are pending change requests in the supplier profile management tables:
POS_ACNT_ADDR_REQ: Stores requests from supplier to assign account to a supplier address
POS_ADDRESS_REQUEST: Stores change requests from supplier on supplier addresses
POS_CONT_ADDR_REQUESTS: Stores change requests for association between supplier address and supplier contact
POS_PRODUCT_SERVICE_REQUEST: Stores change requests for product service offerings
POS_BUS_CLASS_REQS: Stores change requests for supplier classifications
When parties are merged, the following entities are transferred to the master party from the merge-from party:
Assessment owners
Constraint creators
Certification owners
Violation creators
Auditors of audit procedures
The following information transfers to the master party record:
Lease invoice details
External insurance provider and agent details
Asset location detail
Shipping instructions identified during the Asset Return process
When parties are merged and the merge-from party is a legal authority, the following legal information will be transferred to the master party:
Legal functions that a legal entity or an establishment should perform for a given registration.
Registration information of legal entities or establishments.
When parties are merged and the merge-from party is a legal contact, the following legal information will be transferred to the master party:
Legal associations between business and legal objects.
The merge is vetoed if the either the merge-from or merge-to parties are legal contacts, and the taxpayer ID's are not the same for both the merge-from parties and the master party.
When the merge involves any party that is a first party legal entity (FPLE) or an establishment of a first party legal entity, the merge is vetoed.
When parties are merged, the following are transferred from the merge-from party to the master party:
Performance
Event association
Class and learning path enrollment data
The following information transfers to the master party record:
Loan information
Loan participants (borrower, co-borrower, and guarantor) information
The following information transfers to the master party record:
Partners who source the funds to run marketing campaigns, events, offers, and so on.
Partners associated with a marketing activity such as campaigns
Associations of parties to the marketing medium such as newspaper, radio, and so on.
Information about the party that is registering for the event
Information about the party attending the event
Contact information for the registering party
Contact information for the party attending the event
Extra information regarding the origin and mapping details when party records are imported into the TCA registry
Trade profile defined at party level
Organizations that are affiliates
Resources associated with an event
Vendors for a marketing medium
Venues such as conference centers, rooms, and so on, which can be used to hold an event
Agenda information containing track and sessions
Contact history (used by fatigue rules)
Fatigue projections for a target group
The following information is merged into the master party:
Information in the table containing the list bought from an external company that should be imported as part of any marketing activity
Information in the table containing customers/contacts/target/ prospects generated for a list, to be used for mailshots, telemarketing, and so on.
Imported records from the list import process
Parties with products competing in the same market as the deploying company
Parties belonging to a market segment
The following information is merged to the master party record:
Customer contacts associated to offers
Offer qualifier that is associated to the party
The following information transfers to the master party record:
The header data for an order capture quotation
Order line or quote information which includes the item, item organization, unit of measure, quantity ordered, and so on
Shipping information for a quote
In Advanced Pricing, you can use pricing qualifiers, which reference a party or party site when defining pricing modifiers. When orders are created, these price adjustment attributes are captured within the Order Management application. When the party or party site is merged, any references to the price adjustments are updated with the master party information.
When two parties are merged, the following actions take place:
All partner memberships are terminated for the party being merged.
Any pending or incomplete enrollment requests submitted by the party being merged are canceled.
Profile information for the party being merged is not migrated.
When two parties are merged, the following information is transferred to the master party:
Transaction level information for leads, opportunities, referrals, deal registrations, fund requests, and special pricing requests
Lead assignment history
When two parties are merged, the channel manager assignment may not be qualified based on the territory setup for Oracle Partner Manager usages. To assign a correct channel team after the party merge, run the concurrent request program PV: Territory assignment for partners in TOTAL or INCREMENTAL mode, available under the PRM Concurrent Requests responsibility and select INCREMENT mode.
When parties are merged, the following entities are transferred to the master party from the merge-from party:
None
When parties are merged, the following entities are merged to the master party from the merge-from party:
Invoices
Payments
Suppliers
Supplier Sites
Party merge will be vetoed in the following cases:
The associated Supplier/Supplier Sites have not been merged.
There are unpaid invoices associated with the merged-from Party/Party Site.
Note: Even if the user selected ALL in the Supplier Merge, that is not a guarantee that all invoices are transferred. After the merge, the user could have deleted the Inactive On date and entered new transactions, so in this case you cannot just rely on the Accounts Payables merge table to determine if all invoices have been merged.
The user has not selected the Transfer PO checkbox on the Supplier Merge form.
Note: To create new purchase orders for a deactivated supplier, first activate the supplier.
A Supplier/Supplier Site is associated with the merged-from Party/Party Site but there is not a Supplier/Supplier Site associated with the merged-to Party/Party Site.
Payables must confirm that the merged-from Party/Party Site and merged-to Party/Party Site are correlated with the same merged-from Supplier/Supplier Site and merged-to Supplier/Supplier Site. For example, if Supplier A is merged into Supplier B and Supplier B is then merged into Supplier C, the user cannot merge Party A into Party C. In this case, the corresponding merged-from Party and merged-to Party are not the same.
When a party is merged, Oracle Payments checks to see the Taxpayer ID is the same for the parties. If it is, then any active payment instruments such as credit cards, debit cards, or bank accounts associated with any party is moved under the master party. If the Taxpayer ID is different, then the merge will be prevented and the user has to inactivate any payment instruments under the parties that will be merged into the surviving party.
In addition to the payment instruments, a party that is a payee or payer will have payment attributes. These attributes are copied over to master party if they don't already exist there. The list of payment methods associated with the master party will include all the payment methods that were associated with any of the merged parties.
Transactions for the party or parties being merged into the surviving party will be transferred to the master party.
Party Merge processes will be vetoed only when active credit cards or bank accounts exist on the merge-from party and if the taxpayer ID's are not the same.
In Project Contracts, all the existing funding records from the duplicate party are merged into the master party record.
The following information transfers to the master party record:
The total funding for a funding pool contributed by a party
Current and historic information regarding contract funding associated with the party
The following information transfers to the master party record:
Project set owner
External organization playing a role on a project
Control items (Owner, Closed By, Last Modified by, and Assigned to Action)
Progress (Published by)
You cannot merge a party that is defined as a key member on a project.
The following information is transferred to the master party record:
Sales proposals created for the party
Information about the e-mail recipients who received the email with the proposal document
The following information transfers to the master party record:
Party data elements on collection plans
Note: If an electronic record snapshot has been made for the merge from party, it will contain the original party name, even though the Quality Result will have the name of the master party.
For improved performance, create a custom database index on QA_RESULTS.PARTY_ID before performing a party merge, if the following conditions are met:
Oracle Quality is installed.
One or more collection plans that include Party as a collection element have been defined.
These collection plans contain a large amount of results.
The following information transfers to the master party record:
Credit request associated with the party
Case folder associated with the party
Phone and fax information associated with the contact points for a party
The following information merges with the master party record:
Information about a product in which the party is interested
Information about sales leads associated with a party
Information about the contact associated with the sales lead
Forecast information for opportunities associated with a party
Information about sales opportunities associated with a party
Sales credits assigned to partner identified by the party
Associations between a party contact and opportunity
Information about competitors that exist for a sales opportunity
Employee access to a party, opportunity and lead
Changes to the parties and lead information that has been modified by a territory definition
Information about the current environment of a party
The following information transfers to the master party record:
Customer account plan information
The following information merges with the master party record:
Service request information associated with parties
Service request incident location
Audit information for service requests
Contact point for a service request that is associated with a party
Any party site used on a charge line
Any site and site use that is associated to a party for a service request
If a service request has more than one contact, these contacts are merged.
If duplicate contact points exist for the two contacts that were merged, and these duplicate contact points are then merged, it could result in duplicate records in CS_HZ_SR_CONTACT_POINTS. In this case, the duplicate records are deleted.
The following information transfers to the master party record:
Billing profiles: One or more billing profiles for a party
Global contract defaults: Information that has to be defaulted when renewing a service contract or when creating a service contract from an order is associated with the duplicate party
Service availability: Exceptions to services availability for the party
Pricing Qualifiers: Parties and party sites can be used as pricing qualifiers against a service contract. Any record referring to the candidate party as the pricing qualifier is updated to look at the master party record.
Party merge cannot be completed if:
The duplicate party is a freight carrier
The duplicate party has sites where a load can be tendered by the shipper
Party Merge processes will be vetoed only if the organization for which the records are being merged is WMS enabled and there is a change in ship-to address for shipment lines which are staged (picked) and packed but not yet confirmed for shipment.
From Site management a party of type REAL ESTATE is created whenever a internal Site is associated with a Legal Entity. Also an external site can be associated with some external party in Site Management.
If two parties are merged and if from party is associated with an External Site in Site Management , the existing association is replaced with a new association with new To party in Site Management after merge.
If two parties are merged and if from party is associated with an External Site in Site Management , the existing association is replaced with a new association with new To party in Site Management after merge.
Merge is not allowed if either the merge-from or the merge-to parties are real estate parties which are created from Site Management.
If a merge request includes either parties or party sites originally created for use in Oracle iSupplier Portal or Oracle Sourcing, the request will be denied.
The following information transfers to the master party record:
Move-order header information associated with a party
Pack list containing information about the parts that were shipped
If a merge request includes parties that have related records in Oracle Student Systems, the request will be denied.
Note: Named accounts are setup on the party site rather than on the party.
When party sites are merged and both merge-from and merge-to party sites are named accounts:
If both the named accounts belong to the same parent territory, then the merge-from named account and the associated sales team are deleted.
If the named accounts belong to different parent territories, then the merge-to named account is added to the parent territory of the merge-from named account with the sales team of the merge-from named account. The merge-from named account is then deleted.
When party sites are merged, and the merge-from party site is setup as a named account and the merge-to party site is not a named account:
If the merge-from named account belongs to a territory whose matching rule is either DUNS or REGISTRY ID, and if the party of the merge-to party site already exists as a named account in the territory, then the merge-from named account and the associated sales team are deleted.
If the merge-from named account belongs to a territory whose matching rule is either DUNS or REGISTRY ID, and if the party of the merge-to party site does not exist as a named account in the territory, then the merge-to party site will replace the merge-from party site as a named account.
If the merge-from named account belongs to a territory whose matching rule is neither DUNS nor REGISTRY ID, then the merge-to party site replaces the merge-from party site as a named account.
When party sites are merged, and the merge-from party site is not a named account while the merge-to party is:
No transfers or deletes.
The following information transfers to the master party record:
Broker and contact information for claims and claim history
Buying group on a claim line and claim line history
Trade profiles
Code conversion mappings
Partner and partner contact for a resale batch
Billing party and contact for a resale header
Billing, shipping and sold from party and contacts for a resale interface line
Billing, shipping and sold from party and contacts for a resale line
End customer, reseller and partner for a special price or soft fund request
Party, buying group contact and autopay party for an offer
Parent party and rollup party for customer targets
Budget source and vendor for budgets
For details regarding the TCA entities affected during Party Merge, see: Party Merge Overview, Oracle Trading Community Architecture User Guide.
The following information transfers to the master party record:
Facilities
A party can be defined as a trading partner in the XML Gateway application. Therefore, if two parties are merged, then references to the trading partners is also merged.
When parties are merged the following information is transferred to the master party:
Trading partner header information
Any document logs for inbound, outbound and pass through messages
Any outbound transactions logs
Related Topics
Party Merge Impact Reference by Application
Party and Account Merge Impact Overview
This table shows the results of merging parties using applications in the Oracle E-Business suite, describing the affected tables, the transfer or merge action, and the validations performed for each application prior to completion of the party merge process.
| Product Name | Tables affected | Action | Validations |
|---|---|---|---|
| Activity Based Management | FEM_PARTY_PROFITABILITY | Merged | None |
| Advanced Global Intercompany System (AGIS) | FUN_TRX_BATCHES FUN_TRX_HEADERS FUN_DIST_LINES FUN_CUSTOMER_MAPS FUN_SUPPLIER_MAPS |
Transferred | Vetoed if Intercompany org has existing transactions and does not have the same legal entity. |
| Advanced Pricing | QP_QUALIFIERS | Conditionally transferred | The pricing qualifier information is transferred to the master party record after ensuring that a similar qualifier does not exist for the Master Party. |
| Applications Object Library | FND_ATTACHED_DOCUMENTS FND_USER |
Transferred | None |
| Cash Management | CE_BANK_MERGE_V CE_BANK_BRANCHES_MERGE_V |
None | Merge is vetoed in all cases. |
| Collections | IEX_CASE_CONTACTS IEX_DELINQUENCIES_ALL IEX_DUNNINGS IEX_PROMISE_DETAILS IEX_SCORE_HISTORIES IEX_STRATEGIES |
Transferred | None |
| Complex Maintenance, Repair, and Overhaul | AHL_DOC_REVISIONS_B AHL_DOCUMENTS_B AHL_OPERATIONS_B AHL_OSP_ORDERS_B AHL_RECIPIENT_DOCUMENTS AHL_ROUTES_B AHL_SUBSCRIPTIONS_B AHL_SUPPLIER_DOCUMENTS |
Conditionally transferred | The merge takes place only if the master party does not have a similar dependent records. If Oracle Purchasing application has been installed, then the subscription information is associated to a supplier and not a party. Therefore, the merge operation does not take place. If Human Resources is installed, then the revision of documents and the approver of revision comes from HR tables. Therefore, the merge operation does not take place. |
| Contracts Core | OKC_K_PARTY_ROLES_B OKC_RULES_B OKC_K_ITEMS |
Transferred | None |
| OKC_CONTACTS | Transferred | If the contact already exists for the master party, the contact is not transferred. | |
| CRM Foundation | JTF_FM_CONTENT_HISTORY_V JTF_FM_PREVIEWS_V JTF_FM_PROCESSED_V |
Merged | None |
| CRM Foundation - Interaction History | JTF_IH_INTERACTIONS | Transferred | None |
| CRM Foundation - Resource Manager | JTF_RS_RESOURCE_EXTNS | Conditionally transferred | The resource is not transferred if the master party already has a resource defined in the resource manager application. |
| CRM Foundation - Tasks and Notes | JTF_NOTES_B JTF_NOTE_CONTEXTS JTF_PERZ_QUERY_PARAM JTF_TASK_ASSIGNMENTS JTF_TASK_AUDITS_B JTF_TASK_CONTACTS JTF_TASK_PHONES JTF_TASK_REFERENCES_B JTF_TASKS_B |
Transferred | None |
| CRM Foundation - Territories | JTF_TTY_NAMED_ACCTS | Conditionally transferred | If the party has an associated named account an error is raised and party merge cannot be completed. In other words, if a party is assigned to a territory group that party cannot be merged to another party. |
| CRM Foundation - User Management | JTF_UM_APPROVERS | The records are end-dated | None |
| Customer Care | CSC_CUST_PLANS CSC_CUST_PLANS_AUDIT CSC_CUSTOMERS CSC_CUSTOMERS_AUDIT_HIST CSC_CUSTOMIZED_PLANS |
Merged or transferred | If no relationship plans exist on the master party record, then the relationship plan from the duplicate party is transferred to the master party. If the master party has a relationship plan associated with it, then the relationship plan from the duplicate party is merged to it if the two plans are identical. Otherwise, the relationship plan from the duplicate party is transferred to the master party. |
| E-Business Tax | ZX_PARTY_TAX_PROFILE ZX_REGISTRATIONS |
Merged | None Veto if key fields are for same registration. |
| ZX_EXEMPTIONS | None | Veto if key fields are different for same exemptions. | |
| HZ_CODE_ASSIGNMENTS ZX_REPORT_CODES_ASSOC |
Transferred | None | |
| Grants Proposal | IGW_PERSON_BIOSKETCH IGW_PERSON_DEGREES IGW_PROP_LOCATIONS IGW_PROP_PERSON_SUPPORT IGW_PROP_PERSONS |
Conditionally transferred | If the master party has any information associated with it in Grants Proposal product, then the merge will not go through. |
| Human Resources | PER_ADDRESSES PER_ALL_PEOPLE_F PER_COMPETENCIES PER_ESTABLISHMENT_ATTENDANCES PER_EVENTS PER_PHONES PER_PREVIOUS_EMPLOYERS PER_QUALIFICATIONS |
Transferred | The parties should be of type person. |
| Install Base | CSI_I_PARTIES CSI_ITEM_INSTANCES CSI_SYSTEMS_B CSI_T_PARTY_DETAILS CSI_T_TXN_LINE_DETAILS CSI_T_TXN_SYSTEMS |
Conditionally transferred | The information is transferred only if an equivalent record does not exist for the master party. You cannot merge a party that is defined as the internal party in the Install Base Install parameter setup. The Install Base application setup requires that the party owing the enterprise data be setup as an internal party in the Install Base installation parameters table. Once defined as an installation parameter in Install Base, this party cannot be merged with any other party to preserve the integrity of data already existing in Install Base. If you try to merge this internal party with another, an exception will be raised and the merge will not take place. |
| iStore | IBE_ACTIVE_QUOTES_ALL IBE_MSITE_PRTY_ACCSS IBE_ORD_ONECLICK_ALL IBE_SH_QUOTE_ACCESS IBE_SH_SHP_LISTS |
Transferred | If master party doesn't have minisite access restriction, the duplicate party's access restrictions (records) will be transferred to the master party. If master party already has minisite party access restrictions, then the duplicate party's record will be end-dated. If the shared cart is shared with both the master party and the duplicate party, the shared cart record for the duplicate party will be deleted from this table. Otherwise all the shared carts will be transferred to the master party. |
| iSupplier Portal | POS_ACNT_PAY_PREF POS_ADDRESS_NOTES POS_SUPPLIER_REGISTRATIONS |
None | |
| POS_BUS_CLASS_ATTR POS_SUPPLIER_MAPPINGS |
Transferred | ||
| POS_ADDRESS_UPGRADE POS_CONTACT_UPGRADE POS_VENDOR_UPG_TMP |
None | Not needed after upgrade to R12. | |
| POS_ACCT_ADDR_REQ POS_ADDRESS_REQUESTS POS_CONT_ADDR_REQUESTS POS_CONTACT_REQUESTS |
None | Veto merge if there is a pending request in the table. | |
| Internal Control Management | AMW_ASSESSMENTS_B AMW_CONSTRAINTS_B AMW_CERTIFICATION_B AMW_VIOLATIONS AMW_AP_EXECUTIONS |
Transferred | None |
| Lease Management | OKL_CNSLD_AR_HDRS_B OKL_EXT_SELL_INVS_B OKL_INS_POLICIES_B OKL_OPEN_INT OKL_RELOCATE_ASSETS_B OKL_TRX_AR_INVOICES_B OKL_TXL_ITM_INSTS OKL_TXL_RCPT_APPS_B |
Transferred | None |
| Legal Entity Configurator | XLE_ENTITY_PROFILES XLE_ETB_PROFILES |
Veto Merge | Vetoed for FPLE only. Vetoed for FP Establishments only. |
| XLE_ASSOCIATIONS XLE_REGISTRATIONS XLE_REG_FUNCTIONS |
Transferred | Vetoed if taxpayer ID is not the same. None None |
|
| Learning Management | OTA_ATTEMPTS OTA_SCORM_OBJ_ATTEMPTS OTA_SCORM_OBJ_PERFS OTA_SCORM_OBJECTIVES OTA_LO_SCORM_OBJECTIVES OTA_EVENT_ASSOCIATIONS OTA_DELEGATE_BOOKINGS OTA_LP_ENROLLMENTS OTA_LP_MEMBER_ENROLLMENTS |
Transferred | None |
| Loans | LNS_LOAN_HEADERS_ALL LNS_PARTICIPANTS |
Transferred | None |
| Marketing | AMS_IMP_SOURCE_LINES AMS_LIST_ENTRIES AMS_PARTY_SOURCES AMS_PARTY_MARKET_SEGMENTS AMS_COMPETITOR_PRODUCTS_B |
Merged | None |
| AMS_AGENDAS_B AMS_IBA_PL_SITES_B AMS_ACT_PARTNERS AMS_ACT_RESOURCES AMS_CHANNELS_B AMS_EVENT_REGISTRATIONS AMS_TCOP_CONTACTS AMS_TCOP_CHANNEL_SUMMARY AMS_TCOP_CONTACT_SUMMARY AMS_TCOP_PRVW_CONTACTS AMS_TCOP_PRVW_FTG_DTLS AMS_VENUES_B |
Transferred | None | |
| Offers | AMS_OFFER_PARTIES | Merged | None |
| Order Capture | ASO_QUOTE_HEADERS_ALL ASO_QUOTE_LINES_ALL ASO_SHIPMENTS |
Transferred | None |
| Order Management | OE_PRICE_ADJ_ATTRIBS | Transferred | None |
| Partner Management | PV_ASSIGNMENT_LOGS PV_ENTY_ATTR_VALUES PV_LEAD_ASSIGNMENTS PV_LEAD_PSS_LINES PV_SEARCH_ATTR_VALUES PV_GE_PARTY_NOTIFICATIONS PV_PARTNER_ACCESSES PV_TAP_ACCESS_TERRS PV_TAP_BATCH_CHG_PARTNERS PV_REFERRALS_B PV_GE_PTNR_RESPS |
Transferred | The responsibilities stored in the PV_GE_PTNR_RESPS table for the party being merged are revoked. The responsibilities stored in the PV_GE_PTNR_RESPS table associated with the master party are granted to the users of the party being merged. |
| PV_PG_ENRL_REQUESTS | Cancelled | All incomplete or submitted Enrollment Requests for the party being merged are canceled. | |
| PV_PG_MEMBERSHIPS | Terminated | All memberships for the party being merged are terminated. | |
| PV_PARTNER_PROFILES | Merged | The status of the party being merged is set to M. The Profile is not migrated. | |
| Payables | AP_SUPPLIERS AP_SUPPLIER_SITES_ALL AP_INVOICES_ALL AP_CHECKS_ALL |
Transferred | If no veto. |
| Payments | IBY_CREDITCARD | Merged | Taxpayer ID is the same. |
| IBY_ACCOUNT_OWNERS IBY_EXTERNAL_PAYEES_ALL IBY_EXTERNAL_PAYERS_ALL IBY_PMT_INSTR_USES_ALL |
Merged or Transferred | Taxpayer ID is the same. | |
| IBY_DOCS_PAYABLE_ALL IBY_EXT_PARTY_PMT_METHODS IBY_FNDCPT_TX_EXTENSIONS IBY_PAYMENTS_ALL IBY_TRXN_SUMMARIES_ALL |
Transferred | Taxpayer ID is the same. | |
| Project Contracts | OKE_K_FUNDING_SOURCES OKE_K_FUNDING_SOURCES_H OKE_POOL_PARTIES |
Transferred | None |
| Projects | PA_CI_ACTIONS PA_CONTROL_ITEMS PA_PERCENT_COMPLETES PA_PROJECT_REQUESTS PA_RESOURCE_TXN_ATTRIBUTES PA_CI_IMPACTS PA_PROJECT_SETS_B |
Conditionally transferred | You cannot merge a party that is defined as a key member on a project. |
| Proposals | PRP_EMAIL_RECIPIENTS PRP_PROPOSALS |
Transferred | None |
| Quality | QA_RESULTS | Transferred | None |
| Receivables | AR_CMGT_CASE_FOLDERS AR_CMGT_CREDIT_REQUESTS AR_CUSTOMER_CALLS_ALL AR_CUSTOMER_CALLS_TOPICS |
Transferred | None |
| Sales | AS_ACCESSES_ALL AS_CHANGED_ACCOUNTS_ALL AS_CURRENT_ENVIRONMENT AS_INTERESTS_ALL AS_LEAD_COMPETITORS AS_LEAD_CONTACTS_ALL AS_LEADS_ALL AS_OPP_WORKSHEET_LINES AS_SALES_CREDITS AS_SALES_CREDITS_DENORM AS_SALES_LEAD_CONTACTS AS_SALES_LEADS |
Merged | None |
| AS_ACCOUNT_PLANS | Transferred | None | |
| Service | CS_ESTIMATE_DETAILS CS_HZ_SR_CONTACT_POINTS CS_INCIDENTS_ALL_B CS_INCIDENTS_ AUDIT_B | Merged | If a Service Request has more than one contact, then these contacts are merged. If duplicate contact points exist for the two contacts that were merged, and these duplicate contact points are then merged, then it could result in duplicate records in CS_HZ_SR_CONTACT_POINTS. In this case, the duplicate records are deleted. |
| CS_CHG_SUB_RESTRICTIONS | Transferred | None | |
| Service Contracts | OKS_BILLING_PROFILES_B OKS_K_DEFAULTS OKS_SERV_AVAIL_EXCEPTS OKS_QUALIFIERS |
Transferred | None |
| Shipping Execution | WSH_CARRIERS WSH_CARRIER_SITES |
None | If the party has been used as a freight carrier or has carrier sites, then the merge cannot be completed. |
| Site Management | RRS_SITES_B | Merged | If party is not a real estate party. |
| Sourcing | PON_ATTRIBUTE_LISTS PON_AUCTION_EVENTS PON_AUCTION_HEADERS_ALL PON_AUCTION_TEMPLATES PON_BIDDERS_LISTS PON_BIDDING_PARTIES PON_BID_HEADERS PON_CONTRACTS PON_DISCUSSIONS PON_PARTY_PREFERENCES PON_TE_RECIPIENTS PON_TE_VIEW_AUDIT PON_THREADS PON_THREAD_ENTRIES |
None | If the party has a Sourcing use, then the merge request will be denied. |
| Spares Management | CSP_MOVEORDER_HEADERS CSP_PACKLIST_HEADERS |
Transferred | None |
| Student Systems | All tables with an IGS_ prefix | None | If the party is linked to records in any Student Systems table, the merge request will be denied. |
| Territory Manager | JTF_TERR_VALUES_ALL JTF_TTY_NAMED_ACCTS |
Transferred Transferred or Deleted |
None |
| Trade Management | OZF_CLAIMS_ALL OZF_CLAIMS_HISTORY_ALL OZF_CLAIM_LINES_ALL OZF_CLAIM_LINES_HIST_ALL OZF_CUST_TRD_PRFLS_ALL OZF_CODE_CONVERSIONS_ALL OZF_RESALE_BATCHES_ALL OZF_RESALE_LINES_INT_ALL OZF_RESALE_HEADERS_ALL OZF_RESALE_LINES_ALL OZF_REQUEST_HEADERS_ALL_B OZF_OFFERS OZF_ACTIVITY_CUSTOMERS OZF_ACCOUNT _ALLOCATIONS OZF_ACT_BUDGETS |
Transferred | None |
| Trading Community Architecture | See: Party Merge Overview, Oracle Trading Community Architecture User Guide. | ||
| Transportation Execution | FTE_LOCATION_PARAMETERS | Transferred | None |
| XML Gateway | ECX_DOCLOGS ECX_OUTBOUND_LOGS ECX_TP_HEADERS |
Transferred | None |
Related Topics
Party and Account Merge Impact Overview
This section provides details regarding how account merge affects the data in different applications within the Oracle E-Business Suite.
When two customer accounts are merged, the master account will replace the merge-from account in any netting agreements including the merge-from account. Similarly, the master account site use will replace the merge-from account site use in any netting agreements including the merge-from account site use.
If the merge results in having duplicate entries of customers or customer site uses in a given netting agreement, the lower priority customer or customer site use entry will be removed from the netting agreement.
The Advanced Pricing merge process transfers the following information to the master account:
Customer accounts and account sites can be used as pricing qualifiers in the Advanced Pricing application. Any record referring to the candidate customer account or site as the pricing qualifier is updated to look at the master customer account or site record.
Any agreements associated with the customer account or account sites.
The following information transfers to the master account record:
The debtor's promise to pay
Promise to pay history associated with the customer account
The following information transfers to the master account record:
Customer account in contract tables
Customer account, customer address and customer site mentioned in rules
References to contract line and item that has been associated with the duplicate account or account site
If the accounts belong to different parties, then the party role record is updated with the master party information
During account merge, all interaction activity information associated with the duplicate account is transferred to the master account record.
Tasks can be opened by a customer or on their behalf. The task has to be associated to the correct customer account or account site. Therefore, when customer accounts are being merged, the tasks are transferred to the master customer account.
The following logic has been incorporated to ensure that the tasks look at the correct account site information:
If the accounts being merged belong to the same party then the party site information is not updated.
If the accounts being merged belong to different parties and duplicate account has both party site and corresponding, account site information then the task is updated to look at the surviving party, party site and account.
If the accounts being merged belong to different parties and duplicate account has both party site does NOT have corresponding account site information then the merge is declined.
The Customer Care merge process transfers information to the master account about relationship plans, which allow companies to automate their customer service practices and provide a proactive and consistent way to take care of the customers needs.
Validations
If the addresses are set up for tax validation in Geography Hierarchy, then the address elements defined in the tax usage must match. If one address is created with different values for these address elements, then you cannot merge these two addresses. See: Managing Validations, Oracle Trading Community Architecture Administration Guide.
For example, Address 1 is created in a country that is set up with City, County and State as fields that are mandatory for tax validation. Address 2 is created in the same country. To merge these two addresses, the city, county, and state for both addresses must be exactly the same.
If the addresses are not set up for tax validation in Geography Hierarchy, then you can merge the addresses as long as the country is the same.
If you have addresses, one who is setup for tax validation and one who is not, then you cannot merge the addresses.
If the duplicate account belongs to an exchange user, then the exchange application does not allow the merge to go through.
The following information transfers to the master account record:
Customer finance charge information associated with the account
AR/AP netting customer vendor reference information
Interagency information used by the FMS Form 224 Statement of Transaction report, SF 1081 Voucher and Schedule of Withdrawals and Credit process
Cash receipt batch information used by the Federal Cash receipt process
Finance charges information associated with invoices entered in Receivables
Receivables transactions created by the IPAC Transaction process
Cash receipt batch information associated to the account site use
When two customer accounts are being merged, accounting events are generated. An accounting event is a note in Oracle Applications to indicate that something relevant has occurred and that accounting entries should be generated. Later, when they are translated, these accounting events generate new accounting entries against the control accounts of the candidate and the master records. This has the net effect of transferring the control account balances from the candidate record to the master record.
The impact of account merge on the data in Global Financials is as follows:
Oracle Receivables lets you charge interest against customers who have overdue or late invoices. The interest charged on a customer's overdue invoices and late payments are charged to the customer account. When two customer accounts are merged, the Interest invoices are transferred from the duplicate customer account to the master customer account's bill-to site.
The Oracle Financials for Korea has some global descriptive flexfield information associated at the account site level. This information is merged when two customer accounts are merged.
When you merge accounts using the Receivables module in the Oracle Financials for Brazil, this transfers the following information to the master account:
Bank return documents associated with the customer account.
Remittance occurrences for collection documents.
Related follow up occurrences for the remittance occurrence.
Payment schedule information.
Accounting entries that have been successfully transferred from the subledgers to Oracle General Ledger.
Oracle Financials for Brazil also has some global descriptive flexfield information (Tax Payer ID) associated at the account site level. This information is merged when two customer accounts are merged.
For the Receivables module of Oracle Financials for Latin America, the following information is deleted when two accounts are merged:
Tax profile information which determines tax for a customer account site
Exceptions to determine tax for a customer account site
Legal messages for tax rules defined for the customer account
Rules for determining tax that is associated with the account or account site
Oracle Financials for Argentina has some global descriptive flexfield information (Tax Payer ID) associated at the account level. This information is merged when two customer accounts are merged.
Oracle Financials for Chile has some global descriptive flexfield information (Tax Payer ID) associated at the account level. This information is merged when two customer accounts are merged.
Oracle Financials for Colombia has some global descriptive flexfield information (Tax Payer ID) associated at the account level. This information is merged when two customer accounts are merged.
The following information transfers to the master account record:
Award information regarding grants received from a funding agency for execution of projects
Contact information for the awards
The send-to information for the reports present for the award and installments being transferred
The following information is transferred to the master customer account:
Transactional data collected from external systems such as Receivables and stored in interface table in Sales Compensation application
The same transactional data that is validated and loaded into the Commission headers table
The following information transfers to the master account record:
Instance's owner party account, bill-to and ship-to addresses
System's owner account, bill-to and ship-to addresses
Transactions pertaining to system's bill-to and ship-to addresses
Transactions pertaining to party accounts and their bill-to and ship-to addresses
The following information merges with the master account record:
Items demand and reservation information associated with a customer account
Record of every material transaction of a serialized unit in the inventory that is associated with a customer account
The following information is taken care of as part of account merge:
Duplicate account's shopping lists will always be transferred to the master account.
Pre-IBE.O (11.5.9) If master account does not have express checkout setting, the duplicate account's records will be transferred. If master account already has a record in this table, then the duplicate account's record will be deleted.
IBE.O (11.5.9) Duplicate account's record will always be deleted.
If the shared cart is shared to both the master account and the duplicate account, the shared cart record for the duplicate account will be deleted from this table. Otherwise all the shared carts will be transferred to the master.
Duplicate party's active cart will always be deleted.
iStore account merge doesn't allow merge across organizations.
The following information transfers to the master account record:
Loan information
Loan participants (borrower, co-borrower, and guarantor) information
The following information transfers to the master account record:
Forecast consumption information associated with the customer account
Material requirements forecasts associated with the customer account
Forecast over-consumption entries associated with the customer account
Information regarding changes to sales order that affects forecast consumption
Sourcing information of an item in an organization
Information about the relationship between a credit limit and a credit usage rule set can be associated with a customer account or with a customer account site. The credit usage rule defines the set of currencies that shares a predefined credit limit during the credit checking process. When two customer accounts are merged, the credit usage information for the duplicate customer account is deleted.
The following information transfers to the master account record:
The header data for an order capture quotation that is associated with a customer account
Order line or quote information, which includes the item, item organization, unit of measure, quantity ordered, and so on
Shipping information for a quote
The following information transfers to the master account record:
Order header and header history information
Order header acknowledgment information
Order line details and history information
Order line acknowledgment information
Attachment rules of an order
Defaulting rules associated with the customer account or account sites
Processing constraint associated with the account or site
Holds defined to halt the processing of orders and returns
Hip tolerances for an item that is at the account or account site level
Sets for an order for shipping at site level
The following information merges with the master account record:
Partner referrals and deal registrations
Payables stores the bank information related to the customer. When you merge customer accounts, the bank accounts are transferred to the master customer account or account site uses.
If the master customer account or account site use has more than one primary bank for the same currency, the primary flag of the most recently updated customer account or site use is cleared.
When customer accounts are merged, then any active payment instruments such as credit cards, debit cards, or bank accounts associated with any merging account are moved under the master account.
In addition to the payment instruments, an account will have payment attributes. These attributes are copied over to the master account if they don't already exist there. The list of payment methods associated with the master account will include all the payment methods that were associated with any of the merged accounts.
Transactions for the account or accounts being merged into the surviving account will be transferred to the master account.
When two customer accounts merge, the following information is updated to look at the master customer account:
Project information
Project customer and customer billing contribution
Project customer bill-to and ship-to addresses
Project customer contacts
Customer billing retention setup
Work sites defined at the task level
Agreements
Invoice information
Draft invoice bill-to and ship-to addresses
Draft invoice lines work site
Inter-company billing customer
If the resulting customer account has more than ninety-nine agreements, then the merge cannot be completed.
The following information transfers to the master account record:
Billing terms of leases associated with the duplicate customer account
Billing items associated with the billing terms
Space assignments belonging to a customer account
In Service Fulfillment Manager, when two customer accounts are merged, the following information is affected:
SFM Order headers are transferred to the master customer account
The Install at site at the SFM Order Line level is set to the new customer site
The following information transfers to the master account record:
Dialog unit, which is a collection of transactions requiring approval of Oracle Receivables and Payables sub-ledger transactions
Transaction unit, which consists of dialog units batched together for approval
Dunning charges linked to dunned payment schedules
Extensions of the dunning letter set lines which holds the values for multiple currencies for each letter in the dunning letter set
Associations between customer accounts and suppliers
Standard charge information for generating periodical invoices
Records for deriving transactions available for netting purposes
Information on single third party netting transactions
In purchasing, the following information is impacted when two customer accounts are merged:
For requisition lines sourced internally (Internal requisitions), the deliver to location is updated to point to the location associated with the new Customer Account
The following information transfers to the master account record:
Record of the calls made for a past due customer account or transaction
Correspondence information such as account statements, dunning letters, and customer calls available for an account
Consolidated billing invoice information associated with the duplicate customer account
Receipt information associated with the customer account
Information about any activity that occurs against an invoice, debit memo, chargeback, credit memo, on-account credit, or receipt
Invoice, debit memo, commitment, bills receivable, and credit memo header information associated with the customer account
Transaction header and line information
Tax exemption details for either customer accounts and sites
Transactions present in the AutoInvoice interface tables
Receipts present in the Postbatch interim tables
Credit request associated with the customer account
Case folder associated with the customer account
Transactions present in the summary tables and associated with the customer account
The following information is transferred to the master customer account or account site:
Cumulative accounting (CUM) key values associated with the account or site
Header and line level schedule information associated with accounts
All the service requests associated with the customer accounts are merged with the records in the merge master account.
The following information transfers to the master account or site:
The billing profile contains the customer's billing address, as well as other billing information such as summary or detailed bill and so on. The billing profile information attached to the duplicate record is transferred to the master account site.
Accounts and account sites can be used as pricing qualifiers against a service contract. Any record referring to the candidate account or account site as the pricing qualifier is updated to look at the master account or account site record.
The following information transfers to the master account record:
Picking rules associated with the account.
Picking batches associated with the account.
Delivery information associated with the account.
Trip stop information associated with the customer account.
Calendar information associated with the customer account.
The following information is transferred to the master record during account or site merge:
Calendar assignments associated with accounts or account sites.
If the delivery lines are shipped, then that information is transferred to the account or site.
If the delivery lines are not shipped, not packed, and not assigned to a delivery, then the lines, account and locations are transferred.
If delivery lines are not shipped, packed into a container, and not assigned to a delivery, then lines account and locations are transferred, lines are unpacked from container, and exception is logged against the immediate container.
If delivery lines are not shipped or assigned to a delivery but not packed, then lines account and locations are transferred.
After transfer, if a delivery happens to have delivery lines with more than one location, then the transferred delivery lines are unassigned from the delivery and an exception is logged against the delivery.
If delivery lines are not shipped, packed into a container, and assigned to a delivery, then lines account and locations are transferred.
After transfer, if a delivery happens to have delivery lines with more than one location, then the transferred delivery lines are unpacked and unassigned from the delivery and an exception is logged against the delivery.
Open deliveries, their associated containers account, and locations are transferred. After transfer, if a stop happens to have delivery with more than one location, then the transferred delivery is unassigned from the trip stop and an exception is logged against the trip stop.
Stop's locations associated with transferred deliveries are transferred.
Open empty deliveries account and locations are transferred.
The locations for completed shipments are not merged.
Account Merge processes will be vetoed only if the organization for which the records are being merged is WMS enabled and there is a change in ship-to address for shipment lines which are staged (picked) and packed but not yet confirmed for shipment.
Resources with ship to address can be assigned to a customer account. When two customer accounts are merged, the resource is merged with the record associated with the master customer account.
The following information is transferred to the master account record:
Account and product information required by Account Manager Dashboard
Account for customer targets
Beneficiary and account for an offer
Billing and shipping account and account relationship information for a claim and claim history
Buying group on a claim line and claim line history
Code conversion mappings
End customer, partner and reseller account for a request header
Funds utilized
Retail price information for products
Trade profiles
In TCA the following information is transferred when two accounts are merged:
Roles that a party performs in relation to a customer accounts
Account relationships associated with the customer account
The following information is copied to the master customer account
Account sites associated with the duplicate customer account
Contact points associated with the customer account if the two customer accounts being merged belong to different parties
Contacts are copied if a matching record cannot be found in the master record
The following information is merged during customer account merge:
Customer profile classes
Customer profile class amounts
The following information transfers to the master account record:
Information related to customer's agreement
Information about student enrollment
Finance charge information associated with an account
Information regarding the relationship between an event or a class with a customer account
Training history associated with the customer account
Related Topics
Account Merge Impact Reference by Application
Party and Account Merge Impact Overview
This table shows the results of merging customer accounts using applications in the Oracle E-Business suite, describing the affected tables, the transfer or merge action, and the validations performed for each application prior to completion of the account merge process.
| Product Name | Tables affected | Action | Validations |
|---|---|---|---|
| Advanced Global Intercompany System (AGIS) | FUN_NET_CUSTOMERS_ALL | Transferred | None |
| Advanced Pricing | QP_QUALIFIERS OE_AGREEMENTS_B |
Conditionally transferred | The pricing qualifier information is transferred to the master party record after ensuring that a similar qualifier does not exist for the Master account or account site. |
| Collections | IEX_PROMISE_DETAILS | Transferred | None |
| Contracts Core | OKC_K_ITEMS OKC_K_PARTY_ROLES_B OKC_RULES_B |
Transferred | None |
| CRM Foundation - Interaction History | JTF_IH_ACTIVITIES | Transferred | None |
| CRM Foundation - Tasks | JTF_TASKS_AUDITS_B JTF_TASKS_B JTF_PERZ_QUERY_PARAM |
Transferred | The following logic has been incorporated to ensure that the tasks look at the correct account site information: If the accounts being merged belong to the same party, then the party site information is not updated If the accounts being merged belong to different parties and duplicate account has both party site and corresponding account site information, then the task is updated to look at the surviving party, party site and account. If the accounts being merged belong to different parties and the duplicate account does not have corresponding account site information, then merge is declined. |
| Customer Care | CSC_CUST_PLANS CSC_CUST_PLANS_AUDIT CSC_CUSTOMERS CSC_CUSTOMERS_AUDIT_HIST CSC_CUSTOMIZED_PLANS |
Merged | None |
| E-Business Tax | ZX_PARTY_TAX_PROFILE | Both Merge and Transfer | None |
| E-Business Tax | HZ_GEO_NAME_REFERENCES | None | Vetoed in certain conditions. |
| Exchange | None | If the party has an Exchange use, then the request will be denied. | |
| Federal Financials | FV_CUST_FINANCE_CHRGS_ALL FV_CUST_VEND_XREFS FV_INTERAGENCY_FUNDS_ALL FV_INTERIM_CASH_RECEIPTS_ALL FV_INVOICE_FINANCE_CHRGS_ALL FV_IPAC_TRX_ALL |
Transferred | None |
| Global Accounting Engine | AX_EVENTS | Transferred | New accounting entries are created which have the effect of transferring information |
| Global Financial - Financials Common country | JG_ZZ_INTEREST_INVOICES_ALL | Transferred | None |
| Global Financials Latin America - Localization | For Brazil: JL_BR_AR_BANK_RETURNS JL_BR_AR_OCCURENCE_DOCS JL_BR_AR_PAY_SCH_UPD JL_BR_BALANCES_ALL JL_BR_JOURNALS_ALL |
Transferred | None |
| For LTE: JL_ZZ_AR_TX_CUS_CLS_ALL JL_ZZ_AR_TX_EXC_CUS_ALL JL_ZZ_AR_TX_LGL_MSG_ALL |
Transferred | None Deleted |
|
| Grants Accounting | GMS_AWARDS_ALL GMS_AWARDS_CONTACTS GMS_DEFAULT_REPORTS GMS_REPORTS |
Transferred | None |
| Incentive Compensation | CN_COMM_LINES_API_ALL CN_COMMISSION_HEADERS_ALL |
Transferred | None |
| Install Base | CSI_IP_ACCOUNTS CSI_ITEM_INSTANCES CSI_SYSTEMS_B CSI_T_PARTY_ACCOUNTS CSI_T_TXN_SYSTEMS |
Transferred | None |
| Inventory | MTL_DEMAND MTL_UNIT_TRANSACTIONS |
Merged | None |
| iStore | IBE_ACTIVE_QUOTES_ALL IBE_ORD_ONECLICK_ALL IBE_SH_QUOTE_ACCESS IBE_SH_SHP_LISTS |
iStore account merge doesn't allow merge across organizations. If the shared cart is shared to both the master account and the duplicate account, the shared cart record for the duplicate account will be deleted from this table. Otherwise all the shared carts will be transferred to the master account. |
|
| Loans | LNS_LOAN_HEADERS_ALL LNS_PARTICIPANTS |
Transferred | None |
| Master Schedule and Planning | MRP_FORECAST_DATES MRP_FORECAST_DESIGNATORS MRP_FORECAST_UPDATES MRP_SALES_ORDER_UPDATES MRP_SR_ASSIGNMENTS |
Transferred | None |
| Multi-Currency Credit checking | HZ_CREDIT_USAGES | Deleted | None |
| Order Capture | ASO_QUOTE_HEADERS_ALL ASO_QUOTE_LINES_ALL ASO_SHIPMENTS |
Transferred | None |
| Order Management | OE_ATTACHMENT_RULE_ELEMENTS OE_CUST_ITEM_SETTINGS OE_SETS OE_DEF_ATTR_DEF_RULES OE_DEF_CONDN_ELEMS OE_DROP_SHIP_SOURCES OE_HEADER_ACKS OE_HEADERS_IFACE_ALL OE_HOLD_SOURCES OE_LINE_ACKS OE_LINES_IFACE_ALL OE_ORDER_HEADER_HISTORY OE_ORDER_HEADERS_ALL OE_ORDER_LINES_ALL OE_ORDER_LINES_HISTORY OE_PC_VTMPLT_COLS |
Merged | None |
| Partner Management | PV_REFERRALS_B | Merged | None |
| Payables | AP_BANK_ACCOUNTS_ALL | Transferred | None |
| Payments | IBY_CREDITCARD | Merged | Taxpayer ID is the same. |
| IBY_ACCOUNT_OWNERS IBY_EXTERNAL_PAYEES_ALL IBY_EXTERNAL_PAYERS_ALL IBY_PMT_INSTR_USES_ALL |
Merged or Transferred | Taxpayer ID is the same. | |
| IBY_DOCS_PAYABLE_ALL IBY_EXT_PARTY_PMT_METHODS IBY_FNDCPT_TX_EXTENSIONS IBY_PAYMENTS_ALL IBY_TRXN_SUMMARIES_ALL |
Transferred | Taxpayer ID is the same. | |
| Projects | PA_AGREEMENTS PA_DRAFT_INVOICE_ITEMS PA_PROJECT_CONTACTS PA_PROJECT_CUSTOMERS PA_TASKS PA_IMPLEMENTATIONS_ALL |
Transferred | If the resulting customer account has more than ninety-nine agreements, then the merge cannot be completed. |
| Property Manager | PN_PAYMENT_TERMS_ALL PN_SPACE_ASSIGN_EMP_ALL |
Transferred | None |
| Provisioning | XDP_ORDER_HEADERS XDP_ORDER_LINE_ITEMS |
Transferred | None |
| Public Sector Financials (International) | IGI_DUN_CHARGE_ALL IGI_DUN_CUST_LETTER_SET_LINES IGI_EXP_DIAL_UNIT_DEF_ALL IGI_EXP_TRAN_UNIT_DEF_ALL IGI_PO_VENDORS IGI_RA_CUSTOMERS IGI_RPI_STANDING_CHARGES_ALL IGI_STP_CANDIDATES_ALL IGI_STP_PACKAGES_ALL |
Transferred | None |
| Purchasing | PO_REQUISITION_LINES_ALL | Transferred | None |
| Receivables | AR_CASH_RECEIPTS AR_CMGT_CASE_FOLDERS AR_CMGT_CREDIT_REQUESTS AR_CONS_INV AR_CORRESPONDENCES AR_CUSTOMER_CALL_TOPICS AR_INTERIM_CASH_RECEIPT_LINES AR_INTERIM_CASH_RECEIPTS AR_PAYMENT_SCHEDULES AR_TRX_BAL_SUMMARY AR_TRX_SUMMARY RA_CUSTOMER_TRX RA_INTERFACE_LINES RA_TAX_EXEMPTIONS RA_TAX_EXEMPTIONS_ALL |
Transferred | None |
| Release Management | RLM_CUST_ITEM_CUM_KEYS RLM_INTERFACE_HEADERS RLM_INTERFACE_LINES RLM_SCHEDULE_HEADERS RLM_SCHEDULE_LINES |
Transferred | Vetoed under certain conditions |
| Service | CS_INCIDENTS_ALL_B | Merged | None |
| Service Contracts | OKS_BILLING_PROFILES_B | Transferred | None |
| Shipping Execution | WSH_CALENDAR_ASSIGNMENTS WSH_DELIVERY_DETAILS WSH_NEW_DELIVERIES WSH_TRIP_STOPS WSH_PICKING_BATCHES WSH_PICKING_RULES |
Transferred | Vetoed under certain conditions. |
| Spares Management | CSP_RS_CUST_RELATIONS | Merged | None |
| Trade Management | OZF_CLAIMS_ALL OZF_CLAIMS_HISTORY_ ALL OZF_CLAIM_LINES_ALL OZF_CLAIMS_LINES_HIST_ALL OZF_CUST_TRD_PRFLS_ALL OZF_CODE_CONVERSIONS_ALL OZF_FUNDS_UTILIZED_ALL_B OZF_REQUEST_HEADERS_ALL_B OZF_OFFERS OZF_ACTIVITY_CUSTOMERS OZF_ACCOUNT_ALLOCATIONS OZF_CUST_DAILY_FACTS OZF_RETAIL_PRICE_POINTS |
Transferred | None |
| Trading Community Architecture | HZ_CUST_ACCOUNT_ROLES HZ_CUST_RELATE_ALL |
Transferred | None |
| HZ_CONTACT_POINTS HZ_CUST_ACCT_SITE_USES HZ_CUST_ACCT_SITES HZ_ORG_CONTACTS |
Copied | The contact points are copied if the customer accounts being merged belong to different parties. The org contacts are copied if a matching record does not exist in the master customer account. |
|
| HZ_CUST_PROFILE_CLASS_AMTS HZ_CUST_PROFILE_CLASSES |
Merged | None | |
| Training Administration | OTA_BOOKING_DEALS OTA_DELEGATE_BOOKINGS OTA_FINANCE_HEADERS OTA_EVENT_ASSOCIATIONS OTA_NOTRNG_HISTORIES |
Transferred | None |
Related Topics