Search Results s_transaction_type

Overview

The view APPS.IGS_FI_FEE_AS is a reporting and integration artifact within the Oracle E-Business Suite (EBS) Release 12.1.1 and 12.2.2 environments, specifically belonging to the Oracle Student System / Financials integration layer. It provides a security-filtered, organization-aware projection of student fee assessment and transaction data. The view is defined over a single underlying base object, IGS_FI_FEE_AS_ALL, and exposes a curated set of columns reflecting fee assessments, transaction types, currency details, and audit metadata. Its principal role is to present a "current organization" slice of the underlying transactional data, enforcing multi-org access rules through the standard EBS CLIENT_INFO mechanism. Because the view is owned by APPS, it is commonly referenced by concurrent programs, Oracle Forms-based inquiries, and Reports/XML Publisher templates used in Higher Education institution deployments.

Underlying Base Objects

The view is defined over a single documented base table, IGS_FI_FEE_AS_ALL, with no other referenced objects documented in the ETRM metadata. The view text is a straightforward projection that renames the underlying columns and applies a WHERE clause implementing Row-Level Security (RLS). The predicate evaluates nvl(A.ORG_ID, ...) against the operating unit value decoded from the session's userenv('CLIENT_INFO') environment string, defaulting to -99 when no client context is established. The _ALL suffix on the base table indicates that it stores rows for multiple operating units; the view therefore acts as an operating-unit–filtered subset for the currently active organization.

Key Columns

The view exposes the standard EBS WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) alongside concurrency columns (REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE) that support auditing and traceability of DML performed by concurrent programs. ROW_ID is exposed to permit updatable/row-identifiable access. Business columns include PERSON_ID and TRANSACTION_ID, identifying the student and the fee transaction respectively; FEE_TYPE, FEE_CAL_TYPE, FEE_CI_SEQUENCE_NUMBER, and FEE_CAT describe the fee and its calendar context; COURSE_CD links the fee to a specific course; SPONSOR_CD captures sponsorship relationships; and NOTIFICATION_DT records communication milestones. Financial attributes include TRANSACTION_DT, TRANSACTION_AMOUNT, CURRENCY_CD, and EXCHANGE_RATE. Of particular interest to the searched term, S_TRANSACTION_TYPE is the system (internal) transaction type code that classifies each fee record; it is distinct from user-facing transaction type descriptions and is typically joined to a lookup or reference table to derive display values. LOGICAL_DELETE_DT supports soft deletion, allowing historical records to be retained without physical removal. ORG_ID exposes the owning operating unit.

Common Use Cases and Queries

Typical usage centers on fee assessment reporting, student account inquiries, and integration extracts where organization security must be honored. A canonical query filtering by transaction type is shown below:

• Reporting fee assessments for an organization: SELECT TRANSACTION_ID, PERSON_ID, FEE_TYPE, S_TRANSACTION_TYPE, TRANSACTION_AMOUNT FROM APPS.IGS_FI_FEE_AS WHERE TRUNC(TRANSACTION_DT) BETWEEN :p_start AND :p_end;
• Querying by the searched attribute: SELECT PERSON_ID, TRANSACTION_AMOUNT, CURRENCY_CD FROM APPS.IGS_FI_FEE_AS WHERE S_TRANSACTION_TYPE = :p_txn_type AND LOGICAL_DELETE_DT IS NULL;
• Joining to lookup views to resolve the system transaction type to a meaningful description for presentation in Reports/XML Publisher output.

Because the view enforces organization context through CLIENT_INFO, callers should initialize the multi-org environment (via FND_GLOBAL.APPS_INITIALIZE or equivalent) before querying; otherwise the predicate resolves to -99 and only records without a valid ORG_ID are returned. The view is read-oriented and is not intended to be used for direct DML; base-table access should be used for inserts and updates.