Search Results altcoa_id




Overview

IGF_GR_ALT_EXP is a multi-organization view owned by the APPS schema in Oracle E-Business Suite, registered under FND Design Data as IGF.IGF_GR_ALT_EXP. It exposes data related to alternate expense records used by the Grants Accounting module (the IGF product family). In EBS 12.1.1 and 12.2.2 the object is documented as VALID but explicitly marked "No longer used," meaning that while the view still exists in the data dictionary and remains queryable, Oracle no longer supports it as part of the active application flow. Its principal value today is therefore investigative: it allows support staff, upgrade analysts, and reporting developers to inspect historical alternate expense and alternate chart-of-accounts assignments that were captured before the functionality was retired.

The view is defined as a multi-org view, so queries return only rows belonging to the current operating unit identified by the session's ORG_ID context, ignoring data in other operating units. A user searching for altcoa_id has likely encountered this column in legacy code, an old report, or a data-migration mapping and wants to know where it originates.

Note that the ETRM query text shown for this object is a stub — the excerpt reveals the column list but not the actual SELECT definition, and the dependents section identifies APPS.IGF_GR_ALT_EXP_ALL as the base table. In practice the "view" is a thin, secured projection over that _ALL table.

Underlying Base Objects

The documented dependency is APPS.IGF_GR_ALT_EXP_ALL, which is the multi-org base table storing alternate expense records for all operating units. The view IGF_GR_ALT_EXP filters that table by the current ORG_ID, which is precisely why the ORG_ID column appears in the view's column list and why the view is classified as a multi-org view. The ETRM metadata states that IGF_GR_ALT_EXP is not referenced by any other database object, confirming that no other views, packages, or application modules depend on it — consistent with its "no longer used" status.

Because the base object carries the _ALL suffix, the view follows the standard Oracle multi-org pattern: the _ALL table holds data for every operating unit, and the non-_ALL view applies an org security predicate. Any custom SQL that reads the view will only see rows for the operating unit currently set in the user's session.

Key Columns

  • ROW_ID (ROWID) — The physical row identifier of the underlying base table row.
  • ORG_ID (NUMBER) — Operating unit identifier; drives the multi-org filtering applied by the view.
  • ALTEXP_ID (NUMBER) — Primary key of the alternate expense record.
  • ALTCOA_ID (NUMBER) — Identifier of the associated alternate chart of accounts. This is the column most frequently referenced in legacy queries and is the key link between an alternate expense definition and the alternate COA it belongs to.
  • EXP_START / EXP_END (NUMBER) — Numeric start and end values delimiting the expense or effective range of the record.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns maintained for every EBS transactional table.

Common Use Cases and Queries

Typical usage is diagnostic rather than operational. Analysts may query the view to confirm whether legacy alternate expense data still exists for an operating unit, or to resolve a stray altcoa_id seen in a historical extract.

To list all alternate expense rows for the current operating unit:

  • SELECT altexp_id, altcoa_id, exp_start, exp_end FROM apps.igf_gr_alt_exp ORDER BY altexp_id;

To find records tied to a specific alternate chart of accounts:

  • SELECT altexp_id, org_id, exp_start, exp_end FROM apps.igf_gr_alt_exp WHERE altcoa_id = :p_altcoa_id;

To bypass org security and see rows across all operating units, query the base table directly:

  • SELECT altexp_id, org_id, altcoa_id FROM apps.igf_gr_alt_exp_all WHERE altcoa_id = :p_altcoa_id;

Because the object is deprecated, these queries should be treated as read-only forensic checks; no new development should be built against it, and any data it exposes should be validated against the current Grants Accounting tables before use.