Search Results okx_cust_trx_types_v




Overview
Explore in AI Chat

Overview

The OKX_CUST_TRX_TYPES_V view is a Contracts Integration (OKX) reporting object within the Oracle E-Business Suite applications schema (APPS). Its documented purpose is to expose the transaction types used for a customer's invoices, commitments, and credit memos, so that contract integration logic and dependent reporting can select a valid Receivables transaction type when generating or referencing customer transactions. The view is registered as VALID across EBS 12.1.1 and 12.2.2 and is owned by APPS, which means it is a predefined, product-delivered object rather than a customer-created one.

Functionally, the view acts as a simplified projection over the underlying Receivables transaction type definition. It renames several source columns to present a consistent naming convention expected by OKX integration handles, and it adds a literal placeholder column. Because it is a view rather than a table, it stores no data of its own; it materializes values at query time from the base table, inheriting that table's multi-org and set-of-books security semantics where enforced by the calling form or report.

Underlying Base Objects

The view is defined exclusively over RA_CUST_TRX_TYPES_ALL, referenced in the metadata as a SYNONYM resolving to the APPS table of the same name. RA_CUST_TRX_TYPES_ALL is the Receivables table that stores the complete set of customer transaction type definitions, including both seeded Oracle types and user-defined types, across all organizations (the _ALL suffix indicates the table is not filtered by an operating unit view at the table level).

The view text performs a straightforward SELECT from CTT (the alias for RA_CUST_TRX_TYPES_ALL), mapping source columns to exposed columns. No joins, unions, or analytical constructs are present, so the view is a thin, low-overhead wrapper. Because it does not itself apply ORG_ID or SET_OF_BOOKS_ID predicates, callers must supply their own filtering when results should be constrained to a specific operating unit or ledger.

Key Columns

  • STATUS — Sourced directly from CTT.STATUS; indicates whether the transaction type is active ('A') or inactive ('I').
  • NAME — The user-facing name of the transaction type, sourced from CTT.NAME.
  • DESCRIPTION — Free-text description of the transaction type.
  • TYPE — The class of transaction (for example invoice, commitment, credit memo, debit memo, chargeback), sourced from CTT.TYPE.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — The effective date range, aliased from the source START_DATE and END_DATE columns.
  • SET_OF_BOOKS_ID — The ledger (set of books) to which the transaction type belongs.
  • ORG_ID — The operating unit identifier, supporting multi-org filtering.

Two additional columns are exposed that are not customer data: ID1, mapped from CUST_TRX_TYPE_ID, which is the primary key of the transaction type, and ID2, a literal '#' placeholder retained for integration handle compatibility.

Common Use Cases and Queries

Typical usage includes populating a List of Values for transaction type selection during contract or invoice integration, validating that a chosen type is active and within its effective dates, and restricting selection to a given operating unit or ledger.

To retrieve all active invoice transaction types:

  • SELECT cust_trx_type_id ... is not exposed directly; use the alias ID1: SELECT id1, name, description, type, start_date_active, end_date_active FROM okx_cust_trx_types_v WHERE status = 'A' AND type = 'INV' ORDER BY name;

To scope to a specific operating unit and ledger:

  • SELECT id1, name, type FROM okx_cust_trx_types_v WHERE org_id = :p_org_id AND set_of_books_id = :p_sob_id AND status = 'A';

Because the view is unfiltered, always include STATUS (and effective-date) predicates to avoid returning obsolete or inactive types. The ID1 value should be carried forward as CUST_TRX_TYPE_ID when inserting or referencing a customer transaction in integration logic.