Search Results ar_paying_relationships_v




Overview
Explore in AI Chat

Overview

AR_PAYING_RELATIONSHIPS_V is an Oracle Receivables (AR) view owned by the APPS schema. Its documentation is explicitly scoped to Release 11.5, yet the view remains present and VALID in Release 12.1.1 and 12.2.2, where it continues to expose customer paying relationships derived from Oracle Trading Community Architecture (TCA) hierarchy data. The view answers a specific business requirement: identifying which customer accounts may pay on behalf of, or be paid by, another party within a defined relationship hierarchy. Its relationship semantics are governed by two relationship type groups, PARTY_REL_GRP_AR_PAY_TOP_DOWN and PARTY_REL_GRP_AR_PAY_ANY, which the view emits in the RELATIONSHIP_TYPE_GROUP_NAME column.

Functionally, the view flattens the TCA hierarchy model into a two-column party pairing: a parent-side PARTY_ID and a child-side RELATED_PARTY_ID, joined to the corresponding customer account. This makes it suitable for receivables reporting, payment consolidation logic, and integration extracts that must resolve a party's related paying accounts without navigating hierarchy nodes directly.

Underlying Base Objects

The view is defined over four documented base objects, all accessed through APPS synonyms:

  • HZ_HIERARCHY_NODES — supplies the parent/child party relationships, hierarchy type, and effective dating used to build each pairing.
  • HZ_CUST_ACCOUNTS — resolves each related child party to its customer account, providing RELATED_CUST_ACCOUNT_ID.
  • HZ_RELATIONSHIP_TYPES — determines which relationship types qualify as paying relationships (subject and object type must be ORGANIZATION).
  • HZ_CODE_ASSIGNMENTS — maps relationship types into the two AR paying relationship type groups used as the filter.

The definition is a UNION ALL. The first branch resolves direct children under a given parent party, with the parent table and object type constrained to HZ_PARTIES and ORGANIZATION. The second branch walks a multi-level path (GETTOP, TOP, HN), computing an effective date range using GREATEST for the start date and LEAST for the end date across all participating hierarchy nodes. An EXISTS subquery on HZ_CODE_ASSIGNMENTS and HZ_RELATIONSHIP_TYPES restricts results to relationships belonging to the AR pay type groups, with a PUSH_SUBQ hint to encourage index-driven evaluation.

Key Columns

  • PARTY_ID — the paying (parent or top) party identifier.
  • RELATED_PARTY_ID — the related party on the child side of the relationship.
  • RELATED_CUST_ACCOUNT_ID — the customer account tied to the related party; this is the effective join key for receivables transactions.
  • HIERARCHY_TYPE — the TCA relationship type governing the pairing.
  • RELATIONSHIP_TYPE_GROUP_NAME — either PARTY_REL_GRP_AR_PAY_TOP_DOWN (direct children) or PARTY_REL_GRP_AR_PAY_ANY (any-level relationships).
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — validity window of the relationship; consumers should filter on SYSDATE between these values.

Common Use Cases and Queries

Typical usage includes determining which accounts a party can pay for, validating payment relationships during receipt application, and extracting related account mappings for reporting. A representative query is:

  • SELECT party_id, related_party_id, related_cust_account_id FROM ar_paying_relationships_v WHERE party_id = :p_party_id AND SYSDATE BETWEEN effective_start_date AND effective_end_date;
  • Join RELATED_CUST_ACCOUNT_ID to RA_CUSTOMER_TRX_ALL or AR_CASH_RECEIPTS_ALL to identify transactions eligible under a paying relationship.
  • Filter RELATIONSHIP_TYPE_GROUP_NAME = 'PARTY_REL_GRP_AR_PAY_TOP_DOWN' when only direct children are relevant, avoiding the multi-level UNION ALL branch.