Search Results igs_fi_invln_int




Overview
Explore in AI Chat

Overview

IGS_FI_INVLN_INT is an Oracle E-Business Suite view owned by the APPS schema within the IGS (Student System) product family. Its name reflects its function: an interface view over invoice line data (FI = Financials, INVLN = Invoice Line, INT = Interface). It exposes the contents of the invoice line interface staging table used by the Student System's financial integration processes, which feed charge, billing, and receivable transactions into Oracle Financials and General Ledger.

The view is defined as a row-level secured projection of the underlying IGS_FI_INVLN_INT_ALL table. The WHERE clause restricts rows by ORG_ID, derived from the session's USERENV('CLIENT_INFO') context, returning only records whose ORG_ID matches the current operating unit (or the sentinel value -99 when the client information is blank or unavailable). In a multi-org context, this ensures users see only the invoice interface lines belonging to their operating unit.

Because it surfaces both control columns (POSTING_CONTROL_ID, REQUEST_ID, PROGRAM_ID) and diagnostic columns (ERROR_STRING, ERROR_ACCOUNT), this view serves a dual purpose: it is both an integration staging surface for downstream posting programs and an error-diagnosis surface for support and reconciliation.

Underlying Base Objects

The ETRM 12.2.2 metadata documents a single referenced base object: IGS_FI_INVLN_INT_ALL, the multi-org table holding all invoice line interface records across operating units. The view adds no joins and performs no aggregation; it is a straight SELECT of the full column list with an ORG_ID security predicate. Consequently, every column in the view maps one-to-one to a column in the base table, and the set of records returned is always a strict subset governed by the operating unit context. No other base tables are documented as referenced, so any enrichment (student, account, or GL code combination data) must be obtained by joining to other IGS or Financials views separately.

Key Columns

  • INVOICE_LINES_ID / INVOICE_ID / LINE_NUMBER — Primary identifiers and sequencing for each interface invoice line.
  • S_CHG_METHOD_TYPE, CHG_ELEMENTS, DESCRIPTION, AMOUNT — Charge method, charge breakdown, descriptive text, and monetary value of the line.
  • UNIT_ATTEMPT_STATUS, EFTSU, CREDIT_POINTS, UNIT_TYPE_ID, UNIT_LEVEL — Academic context: the student's unit attempt status, effective full-time student units, credit points, unit type, and level of study attached to the charge.
  • REC_ACCOUNT_CD / REV_ACCOUNT_CD, REC_GL_CCID / REV_GL_CCID, GL_DATE, GL_POSTED_DATE — Receivable and revenue accounting string codes and GL code combinations, along with the intended and actual GL posting dates.
  • POSTING_ID, POSTING_CONTROL_ID, SOURCE_TRANSACTION_ID, REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID — Traceability and reconciliation columns linking the interface row to its source transaction and to the concurrent program run that created or processed it.
  • ERROR_STRING / ERROR_ACCOUNT — The columns most relevant to users searching for "error_string". ERROR_STRING captures the diagnostic message written when the posting or validation process rejects a line; ERROR_ACCOUNT identifies the accounting element that failed validation. Together they allow support staff to pinpoint why a particular invoice line did not transfer to GL or Receivables.
  • ATTRIBUTE1–ATTRIBUTE20 — The standard EBS descriptive flexfield columns, available for client-specific extensions.
  • ORG_ID plus audit columns — LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATE_LOGIN, and related who-columns for standard EBS auditing.

Common Use Cases and Queries

The most frequent query pattern involves retrieving failed interface lines and their error messages. For example, to list all lines in the current operating unit that failed processing:

SELECT invoice_lines_id, invoice_id, line_number, amount,
       error_string, error_account, gl_date
 FROM apps.igs_fi_invn_int
 WHERE error_string IS NOT NULL
 ORDER BY invoice_id, line_number;

A second common scenario is reconciling lines posted during a specific GL period by joining the view to GL date ranges or by filtering on GL_POSTED_DATE, using POSTING_CONTROL_ID or REQUEST_ID to group results by posting run. Support and implementation teams also use the view to validate that REC_GL_CCID and REV_GL_CCID are populated before the posting program executes, since missing accounting combinations are a frequent cause of ERROR_STRING entries. Because the view applies operating-unit security automatically, any query executed under a properly configured IGS responsibility returns only the rows relevant to that unit, making it suitable for direct use in personalizations, BI Publisher reports, and ad hoc troubleshooting without additional org filters.