Results for “cash_account_code”

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

Overview

IGSBV_AD_APPL_FEE is an Oracle E-Business Suite 12.1.1 / 12.2.2 read-only view owned by the APPS schema and registered against the IGS - Student System product. Its documented purpose is to hold an applicant's admission fee detail, exposing the fee-processing and accounting attributes recorded on an admission application request alongside the identifying information of the person who submitted it. The view is defined with a WITH READ ONLY clause, so it is intended strictly for query and reporting access rather than for data maintenance; all DML must be directed to the underlying admission application request table.

Because the view joins the fee record to party and person profile data, it presents a denormalised, human-readable projection: an application request identifier paired with a party number and formatted person name, the admission application number, nominated course, fee type and status, the fee amount and reference number, and the distribution accounting identifiers (CCIDs and account codes) for both the revenue and cash sides of the accounting entry. It is therefore a convenient source for reporting on admission fee activity, reconciliation of fee postings, and interfaces that need application-level fee detail without navigating the full Student System entity relationships.

Underlying Base Objects

The documented view text is defined over three base objects:

• IGS_AD_APP_REQ (aliased APR) — the admission application request table, which supplies every fee-related column: APP_REQ_ID, PERSON_ID, ADMISSION_APPL_NUMBER, NOMINATED_COURSE_CD, SEQUENCE_NUMBER, APPLICANT_FEE_TYPE, APPLICANT_FEE_STATUS, FEE_DATE, FEE_AMOUNT, REFERENCE_NUM, REV_GL_CCID, CASH_GL_CCID, REV_ACCOUNT_CD, CASH_ACCOUNT_CD, GL_DATE, GL_POSTED_DATE, POSTING_CONTROL_ID, and the standard audit columns.
• HZ_PARTIES (aliased P) — the Trading Community Architecture party table, supplying PARTY_NUMBER. It is joined on APR.PERSON_ID = P.PARTY_ID, which fixes the party as the applicant.
• HZ_PERSON_PROFILES (aliased PP) — the person profile table, supplying PERSON_NAME. It is joined on P.PARTY_ID = PP.PARTY_ID, with the outer-join filter PP.CONTENT_SOURCE_TYPE (+) = 'USER_ENTERED' and an effective-dating predicate (SYSDATE BETWEEN PP.EFFECTIVE_START_DATE AND NVL(PP.EFFECTIVE_END_DATE, SYSDATE)). The (+) notation makes the profile join optional, so fee rows survive even where no current user-entered person profile exists; PERSON_NAME will simply be null in those cases.

No additional base objects are documented in the ETRM metadata. The admission request table is the driving table, and the two HZ joins are attribute lookups that enrich each fee row with party identity.

Key Columns

• APP_REQ_ID / APPLICATION_REQUIREMENT_ID — primary identifier linking the fee row back to the admission application request.
• PERSON_ID, PARTY_NUMBER, PERSON_NAME — applicant identity: internal party identifier, the public party number, and the current effective user-entered name.
• ADMISSION_APPL_NUMBER, NOMINATED_COURSE_CD, SEQUENCE_NUMBER — the application number, the nominated course code, and the application instance sequence number.
• APPLICANT_FEE_TYPE, APPLICANT_FEE_STATUS — classification and processing state of the admission fee.
• FEE_DATE, FEE_AMOUNT, REFERENCE_NUM — when the fee was taken, the amount, and the external receipt or reference.
• REV_GL_CCID, CASH_GL_CCID, REV_ACCOUNT_CD, CASH_ACCOUNT_CD — the revenue and cash accounting distribution identifiers and their concatenated account code strings. CASH_ACCOUNT_CD (searched as "cash_account_code") is the concatenated cash account for the fee, the natural complement to the revenue account code on the same row.
• GL_DATE, GL_POSTED_DATE, POSTING_CONTROL_ID — the accounting date, the date the entry was posted to the general ledger, and the posting control reference used to group the accounting event.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard audit columns inherited from the base request record.

Common Use Cases and Queries

Typical uses include fee collection reporting, cash-versus-revenue account reconciliation for admission fees, aged unposted fee analysis, and extraction of applicant fee detail into downstream financial or student interfaces. Because the cash account code is exposed directly, the view is an efficient starting point for queries that resolve the cash side of an admission fee posting without joining to GL_CODE_COMBINATIONS.

Applicant fee detail with account codes:

• SELECT admission_application_number, person_number, person_name, applicant_fee_type, applicant_fee_status, fee_amount, cash_account_code, revenue_account_code, gl_date FROM igsbv_ad_appl_fee WHERE cash_account_code IS NOT NULL;

Fees not yet posted to the general ledger:

• SELECT admission_application_number, person_number, fee_amount, cash_account_code, gl_date FROM igsbv_ad_appl_fee WHERE gl_posted_date IS NULL ORDER BY gl_date;

Aggregate fee amounts by cash account and status:

• SELECT cash_account_code, applicant_fee_status, COUNT(*) fee_count, SUM(fee_amount) total_fee FROM igsbv_ad_appl_fee GROUP BY cash_account_code, applicant_fee_status;

Because the view is read-only and performs no aggregation internally, the accounting columns reflect the values stored on IGS_AD_APP_REQ at the moment of query; statuses and posting dates may change as the fee workflow and the accounting process progress.