Supplier Management

Get Involved. Join the Conversation.

Topic

    Piyush Singh
    Party Sharing Impacts and Managing Parties
    Topic posted October 29, 2018 by Piyush SinghGold Trophy: 10,000+ Points, tagged Supplier Creation, Tip 
    78 Views, 1 Comment
    Title:
    Party Sharing Impacts and Managing Parties
    Summary:
    Party sharing impacts and points to consider in managing parties.
    Content:

    Oracle Cloud provides a party model with mechanism to have a central storage and maintenance of all the external parties created in cloud applications. In this model, when you create a new business entity (supplier for example), a new party is created in the central data model along with some of the profile information entered for the business entity. The party created will have a relationship of a supplier. When this supplier enters in another relationship with the organization (customer relationship for example), you can use the party for establishing this new customer relationship rather than creating a new party with customer relationship.

    Party sharing allows a seamless integration across Cloud applications and helps organizations:
    1. Better manage their external parties that they do business with by reducing the profile maintenance overheads. For example, if a customer is to be configured as a supplier too, you do not need to create a new supplier as a party and re-enter all the information. Rather, you need to establish a new ‘supplier’ relationship for the existing customer. Using Supplier Import or data quality management, you can associate the customer with the organization as a supplier too (details of this process will be provided in another post). This ensures no duplicate records exist in the application.
    2. Improves tax reporting by consolidating all tax transactions by a party. This is achieved since the same tax information is captured for all the business functions that the party performs.
    Party sharing ensures a reduced maintenance overhead. However, it also requires users to be careful when creating or maintaining these parties. Refer to the following pointers that a user must consider when managing parties:
     
    1. When a party exists with multiple relationships, say customer and supplier, both the supplier and customer pages will show same information for a certain set of attributes including Name, D-U-N-S Number, Tax Registration Number, Contacts etc. When user edits any of shared attributes from either of the UIs, the change reflects on the other UI too. 
     
    Point to consider: When you edit these attributes for a supplier, you should confirm with the customer management team too for the change.
     
    2. Registering or creating an organization as a supplier, when the organization already exists in the application as a non-supplier party, will result into duplicate parties in the application. In such case, only one of the parties can have the Tax Registration Number captured if you have configured not to allow duplicate TRNs for parties.
     
    Point to consider: If you have Data Quality Management enabled, it will help identify potential duplicates. However, if Data Quality Management is not enabled, registration approval will help validate for duplicate Tax Registration Number (when configured so). 
    In absence of Tax Registration Number, you must review the supplier data before creating a supplier or approving a supplier registration request. If an organization exists in the application as a non-supplier party, create a supplier relationship for that party rather than creating/registering a new supplier as a party.
     
    3. If user incorrectly establishes a new relationship with an existing party, the information provided for the new relationship overwrites the existing party’s profile information. For example, when you create a customer using registry ID of an existing supplier/party, the information provided when creating the customer overwrites the saved information of the supplier. 
     
    Point to consider: When creating new relationships for an existing party ensure the registry ID entered belongs to the right party. If the intent is to create a new party with manually entered registry ID, ensure it does not belong to any existing party in the application. You can use BI publisher to query for existing registry IDs. In case registry ID of an existing party is entered, a new relationship, not a new party, is created. If this happens, one of the relationships will have to be inactivated.
     
    For example, a supplier ‘Electric Devices Inc.’ exists with registry ID: 12345 and user creates a new customer ‘ITL Services’ with registry ID: 12345, a new customer relationship is created for the supplier Electric Devices Inc. and the party name is updated to ‘ITL Services’. When this happens, inactivate the customer relationship, correct the supplier name and then create a new customer with a new registry ID (not associated to any party).

    Comment