Results for “third_party_number”

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

Overview

XLA_THIRD_PARTIES_V is a Subledger Accounting (XLA) view owned by the APPS schema and registered as VALID in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents a consolidated list of third-party entities — suppliers and customers — together with a derived third-party identifier, a single-character third-party type indicator, and a source-system reference number. The view exists primarily to satisfy the "third party" attributes required by the Subledger Accounting architecture, which tags accounting entries, journal line definitions, and supporting references with the party that originated or received a transaction.

Its role in reporting and integration is to unify two otherwise unrelated master-data sources into a single queryable set. Rather than requiring downstream developers to write bespoke UNION logic against payables and receivables tables, the view supplies a consistent three-column projection: THIRD_PARTY_ID, THIRD_PARTY_TYPE, and THIRD_PARTY_NUMBER. The user's search term "third_party_number" maps directly to the third column, which carries the human-recognizable reference — SEGMENT1 for a supplier and ACCOUNT_NUMBER for a customer — while THIRD_PARTY_ID holds the internal primary key of the respective entity.

Underlying Base Objects

The view text is a UNION ALL of two SELECT statements defined over referenced base objects documented as AP_SUPPLIERS (SYNONYM) and HZ_CUST_ACCOUNTS (SYNONYM). The supplier branch reads VENDOR_ID, a literal 'S', and SEGMENT1 from AP_SUPPLIERS. The customer branch reads CUST_ACCOUNT_ID, a literal 'C', and ACCOUNT_NUMBER from HZ_CUST_ACCOUNTS.

Because UNION ALL is used rather than UNION, no deduplication occurs; every supplier row and every customer row is returned, preserving row counts and avoiding a sort/distinct operation that would degrade performance on large trading-partner populations. The APPS synonyms resolve to the underlying applications tables at runtime, so the view inherits standard EBS security, grants, and any row-level controls applied to the base tables. The view itself is a simple projection and contains no joins, no aggregation, and no filtering predicates.

Key Columns

• THIRD_PARTY_ID — The internal unique identifier for the party. It holds VENDOR_ID for suppliers and CUST_ACCOUNT_ID for customers. Values are not globally unique across the two branches; uniqueness is only guaranteed when combined with THIRD_PARTY_TYPE.
• THIRD_PARTY_TYPE — A single-character discriminator. 'S' designates a supplier entry originating from AP_SUPPLIERS; 'C' designates a customer entry originating from HZ_CUST_ACCOUNTS. This column must always be used with THIRD_PARTY_ID when resolving the source record.
• THIRD_PARTY_NUMBER — The user-facing reference number. For type 'S' it is the supplier number (AP_SUPPLIERS.SEGMENT1); for type 'C' it is the customer account number (HZ_CUST_ACCOUNTS.ACCOUNT_NUMBER). This is the column most frequently searched and displayed.

Common Use Cases and Queries

The view is typically used to resolve a third-party number from an identifier stored on Subledger Accounting records, or to validate that a party exists before insert into a custom table. A straightforward lookup of a supplier or customer number by internal ID follows this pattern:

• SELECT third_party_type, third_party_number FROM xla_third_parties_v WHERE third_party_id = :id AND third_party_type = 'S';
• Reverse lookup: SELECT third_party_id FROM xla_third_parties_v WHERE third_party_number = :number AND third_party_type = 'C';
• Population listing: SELECT third_party_type, third_party_id, third_party_number FROM xla_third_parties_v ORDER BY third_party_type, third_party_number;
• Ambiguity check when the type is unknown: SELECT party.* FROM xla_third_parties_v party WHERE party.third_party_number = :number;

Practical applications include building Subledger Accounting reconciliation reports that display trading-partner numbers alongside journal lines, mapping legacy party references during data conversion, and powering LOV or lookup queries in custom concurrent programs. Because the view performs no filtering, callers should always supply a WHERE clause on THIRD_PARTY_ID, THIRD_PARTY_TYPE, or THIRD_PARTY_NUMBER to avoid full scans against both supplier and customer populations.