Results for “jai_om_cust_address_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The view APPS.JAI_OM_CUST_ADDRESS_V is a localization object shipped with the JA (Asia/Pacific Localizations) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its status in the ETRM repository is VALID, and it is owned by the APPS schema. The view exposes a normalized, bidirectional representation of customer account relationships recorded in the Oracle Receivables and Trading Community model, and is consumed primarily by Order Management (OM) localization logic in the Asia/Pacific region.

The name prefix JAI_OM_ indicates that the object is a JA-localization artifact used within the Order Management flow. Rather than acting as a true address view in the narrow sense, the object flattens the parent-child account relationship defined in Receivables into a two-row-per-relationship structure using a UNION ALL of the same base table. This design lets downstream OM localization code resolve either direction of a customer-account relationship — from customer to related customer, and from related customer back to customer — using a single query and a code discriminator.

Underlying Base Objects

The view is defined exclusively over the synonym HZ_CUST_ACCT_RELATE_ALL, which resolves to the Trading Community Architecture (TCA) table storing customer account relationships. That table records, for each row, a CUST_ACCOUNT_ID, a RELATED_CUST_ACCOUNT_ID, and a relationship type, along with control flags such as CUSTOMER_RECIPROCAL_FLAG.

Because the view is layered directly on this relationship table and performs no joins to HZ_CUST_ACCOUNTS, HZ_PARTIES, or HZ_LOCATIONS, it exposes account identifiers only — not party names, addresses, or site data. Any consumer requiring descriptive address or party attributes must join the output of this view back to the TCA customer and party tables.

Key Columns

• RELATED_CUSTOMER_ID — In the first branch of the UNION ALL, this is the RELATED_CUST_ACCOUNT_ID from HZ_CUST_ACCT_RELATE_ALL; in the second branch, it is the CUST_ACCOUNT_ID. It therefore represents the counterparty account identifier from the perspective of the driving branch.
• CUSTOMER_ID — The mirror of the column above, sourced from CUST_ACCOUNT_ID in the first branch and from RELATED_CUST_ACCOUNT_ID in the second branch. It identifies the "primary" customer account for the row.
• CODE — A hard-coded discriminator. A value of 1 identifies rows originating from the first SELECT (relationships where the reciprocal flag is Y), and a value of 2 identifies rows from the second SELECT, which is unaffected by the reciprocal flag. This allows consumers to distinguish direction and to filter to the relationship orientation they require.

Common Use Cases and Queries

Typical use is resolving the counterparty account when processing an order for a customer that participates in a reciprocal account relationship. A representative query is:

• SELECT customer_id, related_customer_id, code FROM apps.jai_om_cust_address_v WHERE customer_id = :p_cust_account_id;
• SELECT customer_id, related_customer_id FROM apps.jai_om_cust_address_v WHERE code = 1 AND related_customer_id = :p_related_id;

Because a single relationship produces both a CODE = 1 row (only when the reciprocal flag is Y) and a CODE = 2 row, queries should filter on CODE to avoid duplicate output. The view should not be treated as an address source; address and party attributes require additional joins to the TCA tables.