Search Results relationship_type_group_name




Overview
Explore in AI Chat

Overview

APPS.FUN_NET_RELATED_CUSTOMERS_V is a reporting view in the Oracle E-Business Suite Receivables (AR) and Trading Community Architecture (TCA) data model that exposes netted customer hierarchies for related-party and "pay top-down" / "pay any" processing scenarios. The view returns the set of customers that are related to a given parent party under payment relationship type groups, resolved through the HZ_HIERARCHY_NODES and HZ_RELATIONSHIP_TYPES model. It is central to netting logic in Oracle Receivables, where a parent organization may pay on behalf of, or receive payment from, a group of related customer accounts.

The view returns rows pairing a subject party (party_id) with a related customer account, together with the relationship type group category that qualified the pairing. Two distinct relationship semantics are surfaced: the 'PARTY_REL_GRP_AR_PAY_TOP_DOWN' group (top-down payment responsibility) and the 'PARTY_REL_GRP_AR_PAY_ANY' group (any-party payment). This dual output makes the view suitable for both reporting and programmatic resolution of net-paying relationships.

Underlying Base Objects

The view is built on TCA synonyms: HZ_HIERARCHY_NODES, HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_RELATE_ALL, HZ_PARTIES, HZ_RELATIONSHIP_TYPES, and HZ_CODE_ASSIGNMENTS. The first branch joins HZ_HIERARCHY_NODES (as the parent/child hierarchy) to HZ_CUST_ACCOUNTS (as the related customer account), filtered by relationship types assigned to the PARTY_REL_GRP_AR_PAY_TOP_DOWN code via HZ_CODE_ASSIGNMENTS and HZ_RELATIONSHIP_TYPES. Both subject and object types are restricted to ORGANIZATION parties.

The second branch performs a UNION ALL, traversing hierarchy nodes to locate top parents that participate in the AR_PAY_ANY group. HZ_CUST_ACCT_RELATE_ALL is documented as a referenced base object, supporting the account-to-account relationship resolution that underpins netting.

Key Columns

  • party_id — The parent party (organization) acting as the paying or asked-to-pay entity.
  • related_party_id — The party of the related customer account on the child side of the hierarchy.
  • related_cust_account_id — The customer account identifier for the related party.
  • cust_account_name — The customer account name used for display and reporting.
  • cust_account_number — The account number (a common key for reporting, e.g. "top 20 customers").
  • hierarchy_type — The relationship type name from HZ_HIERARCHY_NODES that defines the hierarchy edge.
  • relationship_type_group_name — Either PARTY_REL_GRP_AR_PAY_TOP_DOWN or PARTY_REL_GRP_AR_PAY_ANY, indicating which netting regime produced the row.

Effective dating is enforced with SYSDATE BETWEEN hn.effective_start_date AND hn.effective_end_date, and only active assignments (status = 'A') are considered.

Common Use Cases and Queries

A frequent reporting need is identifying the most significant customers by account. The view supports this because it exposes cust_account_number and cust_account_name alongside netting relationships. The following query lists the top 20 related customers by account count for a given parent:

  • SELECT related_cust_account_id, cust_account_name, cust_account_number, COUNT(*) AS rel_count FROM apps.fun_net_related_customers_v GROUP BY related_cust_account_id, cust_account_name, cust_account_number ORDER BY rel_count DESC OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY (or use ROWNUM <= 20 in 12.1.1).
  • Filter by relationship_type_group_name = 'PARTY_REL_GRP_AR_PAY_TOP_DOWN' to isolate top-down netting obligations.
  • Join back to HZ_PARTIES or HZ_CUST_ACCOUNTS to obtain profile, site, and contact details for reconciliation.
  • Combine with AR_PAYMENT_SCHEDULES_ALL or AR_CASH_RECEIPTS_ALL to analyze netted receipts against related customers.

Because the view unions both group semantics, always qualify queries with the desired relationship_type_group_name to avoid double counting, and be aware that only active, effective-dated hierarchy edges are returned.