Results for “amount_type”

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

Overview

GL_LOOKUPS_AMOUNT_TYPES_V is a reporting view owned by the APPS schema and registered in Oracle E-Business Suite under the General Ledger (GL) product family. It exposes a filtered, presentation-ready projection of the underlying lookup repository, restricted to a single lookup type. The view is documented as 10SC ONLY, indicating that its availability and intended use are scoped to the 10SC configuration of the E-Business Suite rather than to the general GL application surface. Because it is a view and not a base table, it carries no independent storage; every row returned is derived at query time from the lookup definition data maintained in the application.

The view performs a simple column rename and filtering function. Rather than requiring callers to remember the internal lookup type code and the raw column names of the lookup table, it presents three well-labelled columns: AMOUNT_TYPE, SHOW_AMOUNT_TYPE, and DESCRIPTION. This abstraction is typical of EBS lookup views, which exist to decouple consumer code and reports from the physical lookup structures and to present only the rows relevant to a specific domain.

Underlying Base Objects

The view is defined over a single documented base object: GL_LOOKUPS, which in EBS is itself exposed as a view over the lookup definitions. The definition applies a WHERE predicate on the lookup type:

• LOOKUP_TYPE = 'PTD_YTD' — only lookup codes belonging to the PTD_YTD lookup type are returned.
• LOOKUP_CODE from GL_LOOKUPS is aliased as AMOUNT_TYPE.
• MEANING from GL_LOOKUPS is aliased as SHOW_AMOUNT_TYPE.
• DESCRIPTION from GL_LOOKUPS passes through unchanged.

Because GL_LOOKUPS is itself a view, GL_LOOKUPS_AMOUNT_TYPES_V is a view layered on a view, and it inherits the validation and enabled/disabled semantics maintained by the lookup maintenance forms. The PTD_YTD lookup type corresponds to the amount-type distinction of period-to-date versus year-to-date, which is why the resulting rows are surfaced under the AMOUNT_TYPE naming convention.

Key Columns

• AMOUNT_TYPE — the stored lookup code, used as the machine-readable identifier for the amount type (for example, the PTD or YTD code values defined for the PTD_YTD lookup type). This is the value typically compared or joined against in application logic.
• SHOW_AMOUNT_TYPE — the translated MEANING of the lookup code, intended for display. This is the value that should appear on reports, LOVs, and user-facing output, since it reflects the language-specific meaning maintained in the lookup definition.
• DESCRIPTION — the free-text description attached to the lookup code, providing additional descriptive context beyond the short meaning.

The three columns follow the standard EBS lookup-view convention of separating the code (for logic) from the meaning (for display), which prevents hard-coded display strings in customizations and reports.

Common Use Cases and Queries

The primary use case is populating a list of valid amount types in a report parameter, concurrent program LOV, or custom form without querying GL_LOOKUPS directly. A second use is joining the view to fact or summary data to render human-readable amount-type labels, for instance in a period-to-date versus year-to-date comparison report.

A basic query to enumerate the available amount types is:

• SELECT amount_type, show_amount_type, description FROM apps.gl_lookups_amount_types_v ORDER BY amount_type;

To translate a stored code into its display meaning in a larger query, the view can be joined on the code column:

• SELECT t.amount_type, v.show_amount_type FROM my_amounts t, apps.gl_lookups_amount_types_v v WHERE t.amount_type = v.amount_type;

Because the view already filters to LOOKUP_TYPE = 'PTD_YTD', consumers do not need to add that predicate themselves, reducing the risk of inconsistent filtering across reports. Callers should, however, respect the documented 10SC ONLY scope before relying on the view in other configurations, and should ensure the APPS schema is qualified or synonymed appropriately in their environment.