Search Results igsbv_party_charges

Overview

IGSBV_PARTY_CHARGES is a read-only database view belonging to the Oracle E-Business Suite IGS (Student System) product family, a module that is documented as obsolete in the current ETRM metadata for releases 12.1.1 and 12.2.2. The view presents a consolidated, charge-level picture of the fees and amounts owed by a person (party) within the student financials invoicing flow. It joins header-level invoice information to line-level charge detail, producing one row per invoice line for each person, and is intended to support reporting and integration scenarios where a flattened, human-readable representation of charges is preferable to querying the underlying interface tables directly.

Because the object is a business view (BV naming convention) rather than a table, it exposes no writable data and carries the WITH READ ONLY clause, confirming that it is designed exclusively for query access. It does not appear in the current database implementation, meaning it may remain only as a definitional artifact for backward compatibility or documentation purposes.

Underlying Base Objects

The view is defined over two base objects, both of which are interface (staging) tables rather than final transactional stores:

• IGS_FI_INV_INT_ALL — the invoice header interface table, aliased as INV, supplying person, invoice, amount, currency, calendar, bill, waiver, and course attributes.
• IGS_FI_INVLN_INT_ALL — the invoice line interface table, aliased as INVLN, supplying line-level amounts, accounting codes, GL dates, and credit-point detail.

The join condition is a simple equi-join on INV.INVOICE_ID = INVLN.INVOICE_ID, so each row reflects the intersection of one invoice header and one of its constituent lines. Although the ETRM metadata lists no referenced base objects, the view text explicitly names these two tables, and the columns exposed are drawn directly from them.

Key Columns

The column list begins with identity and descriptive fields central to charge reporting:

• PARTY_IDENTIFIER (PERSON_ID) and INVOICE_IDENTIFIER (INVOICE_ID) — the primary keys linking charges to a person and a specific invoice.
• INVOICE_LINE_IDENTIFIER — uniquely identifies each charge line.
• INVOICE_NUMBER and INVOICE_LINE_NUMBER — user-facing document references.
• INVOICE_AMOUNT, INVOICE_LINE_AMOUNT, and INVOICE_AMOUNT_DUE — monetary values at header and line level.
• CURRENCY_CODE and EXCHANGE_RATE — currency context for the charge.
• FEE_CALENDAR_TYPE and FEE_CAL_INST_SEQUENCE_NUMBER — tie the charge to a fee calendar and its instance.
• DEBIT_ACCOUNT_CODE / CREDIT_ACCOUNT_CODE and their GL CCIDs — accounting distribution of the charge.
• FEE_TYPE and FEE_CATEGORY — classification of the fee.
• BILL_NUMBER, BILL_DATE, and BILL_PAYMENT_DUE_DATE — billing cycle references.
• INVOICE_LINE_GL_DATE and GL_POSTED_DATE — GL posting timeline.
• WAIVER_FLAG, WAIVER_REASON, and WAIVER_NAME — waiver handling.
• ERROR_STRING and ERROR_ACCOUNT — validation or posting errors from the interface load.

Two derived columns use descriptive-flexfield lookup substitutions: _LA:TRANSACTION_TYPE and _LA:S_CHG_METHOD_TYPE, returning the meaning values from the IGS_LOOKUP_VALUES lookup on the transaction type and charge method.

Common Use Cases and Queries

Typical usage involves charge statements, reconciliation of interface loads, and student account inquiries. A simple retrieval of all charges for a party is shown below:

SELECT party_identifier,
       invoice_number,
       invoice_line_number,
       invoice_line_amount,
       currency_code,
       fee_type
FROM   igsbv_party_charges
WHERE  party_identifier = :p_person_id
ORDER  BY invoice_creation_date DESC, invoice_line_number;

Analysts also aggregate charges to check fee category totals or isolate interface errors before posting:

SELECT party_identifier,
       invoice_number,
       SUM(invoice_line_amount) total_charges
FROM   igsbv_party_charges
WHERE  error_string IS NULL
GROUP  BY party_identifier, invoice_number;

Because the view reads from interface tables, results reflect staging data and should be validated against the final financial tables before being treated as posted balances.