Search Results je_batch_bc_status




Overview
Explore in AI Chat

Overview

The view APPS.GL_LOOKUPS_MJE_FUNDS_STATUS_V is a lightweight lookup projection in the Oracle E-Business Suite General Ledger module. It exposes the funds status codes used by the Multi-Je Batch / Batch Control (BC) process, presenting them as a simple two-column list of code and description. The view does not store data; it is a filtered, denormalized slice of the generic Oracle lookups table GL_LOOKUPS, restricted to the lookup type JE_BATCH_BC_STATUS. This lookup type is the value list that governs the "Funds Status" attribute on journal batches processed through budgetary control and funds checking.

In practice, the view serves reporting, integration, and personalization purposes. Rather than forcing report authors, concurrent programs, or external interfaces to know the internal lookup type name and remember to filter on it, the view provides a stable, self-describing interface. Its column aliases, FUNDS_STATUS and SHOW_FUNDS_STATUS, communicate intent directly, which makes it suitable for embedding in BI Publisher data models, Oracle Reports, OAF pages, and inbound/outbound interface extracts.

Underlying Base Objects

According to the documented ETRM metadata for release 12.2.2, the view is owned by APPS and is defined over a single referenced base object: GL_LOOKUPS, which is itself exposed as a view in the APPS schema. The definition is a straightforward select with an equality predicate, as shown below.

  • SELECT l.lookup_code FUNDS_STATUS, l.meaning SHOW_FUNDS_STATUS
  • FROM gl_lookups l
  • WHERE l.lookup_type = 'JE_BATCH_BC_STATUS'

The relationship to GL_LOOKUPS is therefore one of filtering and aliasing only. Every row returned by GL_LOOKUPS_MJE_FUNDS_STATUS_V corresponds to exactly one enabled lookup row in GL_LOOKUPS whose lookup type equals JE_BATCH_BC_STATUS. No joins, aggregations, or transformations are applied. Because GL_LOOKUPS is the repository for all Oracle General Ledger lookup types, maintenance of the values presented here is performed through the standard lookup maintenance responsibility, not through the view.

Key Columns

  • FUNDS_STATUS — aliased from GL_LOOKUPS.LOOKUP_CODE. This is the internal code stored on the journal batch or journal header record that carries the funds-checking outcome (for example, values indicating that funds are available, insufficient, or not checked).
  • SHOW_FUNDS_STATUS — aliased from GL_LOOKUPS.MEANING. This is the user-facing translatable description displayed on forms and reports in place of the code.

Because the query does not filter on the ENABLED_FLAG column of GL_LOOKUPS, consumers that require only currently enabled statuses should apply their own predicate or join back to GL_LOOKUPS. This is an important consideration when constructing validation lists for interfaces, since disabled lookup codes may still be returned by the view.

Common Use Cases and Queries

The view is most commonly used to decode the funds status value on journal batches, to populate selection lists in custom forms and OAF pages, and to provide valid values for interface staging tables. A typical decode query joins the view to journal batch or header data as follows.

  • Decoding batch funds status: SELECT b.batch_name, v.show_funds_status FROM gl_je_batches b, gl_lookups_mje_funds_status_v v WHERE b.funds_status = v.funds_status ORDER BY b.batch_name;
  • Listing available statuses for a validation list: SELECT lookup_code, meaning FROM gl_lookups WHERE lookup_type = 'JE_BATCH_BC_STATUS' ORDER BY lookup_code;
  • Reporting rejected or pending funds checks: SELECT batch_name, funds_status FROM gl_je_batches WHERE funds_status IN (SELECT funds_status FROM gl_lookups_mje_funds_status_v);

When the abbreviations returned by FUNDS_STATUS must be presented to end users, the view eliminates the need to hard-code meanings in report logic. Because the view derives from GL_LOOKUPS, any change to the meaning of a status code is immediately reflected in dependent reports and interfaces without code modification, provided the lookup remains in the underlying table.