Search Results get_role_responsibility_rec

Overview

APPS.HZ_CUST_ACCOUNT_ROLE_V2PUB is a public PL/SQL API package within the Oracle Trading Community Architecture (TCA) / Receivables (HZ) product family. Its stated purpose, per the package header, is to provide the public APIs for customer account roles and role responsibilities. In Oracle EBS, customer account roles associate a party (such as a contact person) with a specific customer account or customer account site in a defined capacity — for example, billing contact, statement recipient, or dunning contact. This package is the supported programmatic entry point for creating and maintaining those relationships, encapsulating the validation, defaulting, and denormalization logic that would otherwise have to be reimplemented in custom code.

The package is classified as a public API under the HZ product, governs the business entity HZ_ACCOUNT_CONTACT, has an active lifecycle, and is documented in the Oracle Trading Community Architecture Technical Implementation Guide (120hztig.pdf). It is referenced by 22 other packages in the E-Business Suite, indicating that it is used internally by higher-level TCA and Receivables APIs in addition to being called directly by customers.

Key Procedures and Functions

The package exposes six documented entry points, covering the two principal entities it manages: customer account roles and role responsibilities.

• CREATE_CUST_ACCOUNT_ROLE — Creates a new customer account role record, associating a party with a customer account and optionally a customer account site, with a specified role type and primary flag.
• UPDATE_CUST_ACCOUNT_ROLE — Updates an existing customer account role. This is the procedure most commonly associated with the search term "update_cust_account_role": it modifies attributes of a role that already carries a valid CUST_ACCOUNT_ROLE_ID, rather than inserting a new row.
• GET_CUST_ACCOUNT_ROLE_REC — Retrieves a single customer account role and returns its attributes into the CUST_ACCOUNT_ROLE_REC_TYPE record structure defined in the package specification.
• CREATE_ROLE_RESPONSIBILITY — Creates a role responsibility, linking a responsibility (identified by RESPONSIBILITY_ID) to an existing customer account role, with a responsibility type.
• UPDATE_ROLE_RESPONSIBILITY — Updates an existing role responsibility assignment.
• GET_ROLE_RESPONSIBILITY_REC — Retrieves a role responsibility into the ROLE_RESPONSIBILITY_REC_TYPE record structure.

Parameter lists are intentionally omitted here; the documented API signature and parameter semantics should be taken from the technical implementation guide. As with most V2PUB APIs, callers pass a record structure plus a return status and message, and should check the returned status before committing.

Tables Accessed

The package operates against three documented tables, reached through APPS synonyms:

• HZ_CUST_ACCOUNT_ROLES — the base table holding customer account role records. It is inserted into by CREATE_CUST_ACCOUNT_ROLE, modified by UPDATE_CUST_ACCOUNT_ROLE, and queried by GET_CUST_ACCOUNT_ROLE_REC. Nearly every column in CUST_ACCOUNT_ROLE_REC_TYPE (identifiers, primary_flag, role_type, source_code, attribute_category, attribute1–25, orig_system, orig_system_reference, status, created_by_module, application_id) corresponds to a column in this table.
• HZ_PARTY_SITES — the party site table, used to validate or derive site-level context when a role is tied to a customer account site (CUST_ACCT_SITE_ID).
• HZ_ROLE_RESPONSIBILITY — the table storing the responsibility assignments created and maintained by CREATE_ROLE_RESPONSIBILITY and UPDATE_ROLE_RESPONSIBILITY, and read by GET_ROLE_RESPONSIBILITY_REC.

Usage Notes

HZ_CUST_ACCOUNT_ROLE_V2PUB is the correct interface for custom code, interfaces, and conversions that need to create or update customer account roles and role responsibilities. Rather than writing directly to HZ_CUST_ACCOUNT_ROLES or HZ_ROLE_RESPONSIBILITY, callers should invoke this package so that validation, identifier generation, WHO columns, and any denormalized values are populated consistently with both Oracle EBS 12.1.1 and 12.2.2 releases.

Typical invocation patterns include:

• Custom PL/SQL called from concurrent programs performing bulk assignment of contacts to customer accounts.
• Form-based or OAF personalizations and extensions that must persist a role change through supported APIs.
• Internal use by the other 22 packages that reference this one, particularly during customer, contact, and site creation flows.

Because the package is a public API, its signature is stable across the two releases in question. All calls should be wrapped in the standard API error-handling pattern — inspect the returned status and message, and issue COMMIT only after a success indication. Changes should never be committed by the API itself, allowing the caller to control transaction boundaries and rollback on validation failure.