Search Results ozf_request_headers_all_tl




Overview
Explore in AI Chat

Overview

The OZF_REQUEST_HEADERS_ALL_TL table is a core data object within the Oracle E-Business Suite (EBS) Trade Management module (OZF). It functions as a translation table, storing language-specific textual descriptions for request headers. These headers represent the master records for funding or pricing requests, specifically for soft funds and special pricing programs. The table's primary role is to support the application's multi-language (NLS) capabilities, ensuring that descriptive information for requests is available in the user's preferred language. It operates in conjunction with its base table, OZF_REQUEST_HEADERS_ALL_B, which holds the non-translatable transactional data.

Key Information Stored

The table stores translated attributes for request headers, keyed by a language code and the primary identifier from the base table. While the full column list is not detailed in the provided metadata, the structure of Oracle EBS translation tables is standardized. The critical columns typically include:

  • REQUEST_HEADER_ID: The primary key, which is a foreign key to the base table (OZF_REQUEST_HEADERS_ALL_B). It uniquely identifies the request header for which translations are provided.
  • LANGUAGE and SOURCE_LANG: Columns that store the language code (e.g., 'US', 'FR') and the original source language of the data, respectively. These are essential for the application's NLS architecture.
  • Translatable descriptive columns, which likely include fields such as REQUEST_NAME or DESCRIPTION. These columns hold the user-facing text in the specified language.
The table's primary key constraint, OZF_REQUEST_HEADERS_ALL_TL_PK, is defined on the REQUEST_HEADER_ID and LANGUAGE columns, ensuring a unique translation per language for each request header.

Common Use Cases and Queries

This table is primarily accessed by the Oracle application's internal NLS engine to display localized text on forms and reports. Common technical and reporting use cases include generating multi-language documentation for funding requests or auditing translated content. A typical query to retrieve a request header's description in a specific language would join this table with its base table. For example:

SELECT b.request_number, tl.description
FROM ozf_request_headers_all_b b,
     ozf_request_headers_all_tl tl
WHERE b.request_header_id = tl.request_header_id
AND tl.language = USERENV('LANG')
AND b.request_header_id = :p_request_id;

Another common pattern is to check for missing translations by comparing the SOURCE_LANG against installed languages or to update translations via standard APIs provided by the OZF module, rather than through direct DML operations.

Related Objects

The table has a direct and critical relationship with its corresponding base table, as documented in the provided metadata.

  • OZF_REQUEST_HEADERS_ALL_B: This is the primary transactional table for request headers. The foreign key relationship is defined from OZF_REQUEST_HEADERS_ALL_TL.REQUEST_HEADER_ID to OZF_REQUEST_HEADERS_ALL_B.REQUEST_HEADER_ID. All translation records are dependent on a corresponding record in this base table.

In practice, views such as OZF_REQUEST_HEADERS_ALL (a union of the '_B' and '_TL' tables) are commonly provided for reporting and application logic. Integration points, such as the public APIs in the OZF_FUND_REQUEST_PVT or OZF_SPECIAL_PRICING_PVT packages, will also internally reference this table to manage the creation and update of request header data, including its translations.