Search Results itr_submit

Overview

APPS.IGI_ITR_CHARGE_HEADERS_V is a reporting and integration view in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 that exposes charge header records used by the Oracle ETRM (Expense and Travel Reporting Management / intercompany transaction reporting) subsystem. The view is defined over the IGI_ITR_CHARGE_HEADERS base table and decorates each charge record with human-readable descriptions resolved from lookup, user, and journal category sources. Its principal purpose is to present charge submissions with denormalized, presentation-ready columns so that concurrent programs, OAF pages, and custom reports do not have to perform the join logic themselves.

The view is particularly relevant to the search term "itr_submit" because the SUBMIT_FLAG column of the base table is resolved against the IGI_LOOKUPS view using the lookup type ITR_SUBMIT. This lookup type encodes the submission state of a charge record, and the view returns its meaning through the SUBMIT_DESC alias. In this way the view is the canonical source for interpreting submission status.

Underlying Base Objects

The view is defined over four referenced objects, per the documented ETRM metadata for 12.2.2:

• IGI_ITR_CHARGE_HEADERS — the driving synonym and source of all charge header attributes, aliased as HEADER.
• IGI_LOOKUPS — a view used to translate SUBMIT_FLAG values via LOOKUP_TYPE = 'ITR_SUBMIT'.
• FND_USER — the Oracle Applications user table, aliased as FU, providing the originator's user name.
• GL_JE_CATEGORIES_TL — the translated journal entry categories table, aliased as GJC, supplying the user-facing category name.

The joins are strict inner joins: the lookup join requires LOOKUPS.LOOKUP_CODE = HEADER.SUBMIT_FLAG with the ITR_SUBMIT lookup type; the user join requires FU.USER_ID = HEADER.IT_ORIGINATOR_ID; and the category join requires GJC.JE_CATEGORY_NAME = HEADER.IT_CATEGORY with GJC.LANGUAGE resolved from the session language through userenv('LANG'). A charge header row will therefore not appear if any of these joins fails.

Key Columns

• ROW_ID — the ROWID of the charge header row, suitable for update-through-view operations on the base table.
• IT_HEADER_ID — the primary key of the charge header.
• NAME, DESCRIPTION — identification and free-text description of the charge.
• SUBMIT_FLAG and SUBMIT_DESC — the raw submission code and its translated meaning, derived from the ITR_SUBMIT lookup type.
• ORIGINATOR_NAME — the FND_USER user name of the originator (IT_ORIGINATOR_ID).
• IT_CATEGORY and CATEGORY_DISPLAY — the internal category code and the user-facing journal category name.
• IT_PERIOD_NAME, GL_DATE, SUBMIT_DATE — the accounting period, general ledger date, and submission timestamp.
• SET_OF_BOOKS_ID, CODE_COMBINATION_ID, ENCUMBRANCE_TYPE_ID, CURRENCY_CODE — accounting context for the charge.
• ENTERED_DR, ENTERED_CR — entered debit and credit amounts.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The view is typically queried to list charge submissions by status, to report by originator or period, and to drive workflow or OAF pages that step a charge through the ITR_SUBMIT lifecycle. A representative query filters on the resolved submission description:

SELECT it_header_id, name, submit_flag, submit_desc, originator_name, it_period_name, gl_date, currency_code, entered_dr, entered_cred FROM apps.igi_itr_charge_headers_v WHERE submit_desc = 'Submitted';

A second common pattern aggregates charges by originator and period:

SELECT originator_name, it_period_name, COUNT(*) charge_count, SUM(entered_dr) total_dr, SUM(entered_cr) total_cr FROM apps.igi_itr_charge_headers_v GROUP BY originator_name, it_period_name ORDER BY originator_name, it_period_name;

Because the category and submit descriptions are language-dependent and resolved at query time, reports that consume this view automatically honor the session language. When writing custom code, developers should remember that the inner joins suppress headers lacking a matching lookup, user, or category translation, and should therefore rely on this view only for fully populated records.