Search Results igs_ad_addrusage_int




Overview
Explore in AI Chat

Overview

The IGS_AD_ADDRUSAGE_INT view is a public synonym-backed dictionary view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the IGS – Student System product family. It exposes the address usage interface staging area that the Student System (and by extension the Trading Community Architecture/Receivables address model) uses to load or update address usage assignments in batch from external or feeder systems. In EBS 12.1.1 and 12.2.2, this view is a thin passthrough layer over the IGS_AD_ADDRUSAGE_INT_ALL base table, presenting the same column set plus a synthesized ROW_ID derived from the underlying table's physical row identifier.

The view is primarily relevant to reporting and integration development rather than to end-user forms. It allows developers, interface programs, and reconciliation reports to query address usage interface records without addressing the _ALL table directly, and it participates in the standard EBS multi-tenant style of interface tables where ORG_ID and the interface primary key columns drive concurrent-program processing. Because it is a view and not a table, it carries no independent constraints, indexes, or DDL of its own; all integrity rules live on the underlying table.

Underlying Base Objects

The object is defined over a single documented base object, IGS_AD_ADDRUSAGE_INT_ALL. The view text is a straightforward projection:

No other base tables, views, or synonyms are documented as referenced by this view. Because the view is a simple one-to-one projection, it is inherently updatable under Oracle's rules for simple views, and DML through the view resolves to the underlying table for rows that satisfy the key-preserved conditions.

Key Columns

The columns most relevant to interface development and reconciliation are:

  • INTERFACE_ADDR_ID — the interface address identifier, the key that the user search "interface_addr_id" targets. It links the usage record to the address row being loaded.
  • INTERFACE_ADDRUSAGE_ID — the interface primary key for the address usage record itself.
  • SITE_USE_CODE — the usage code (for example, a billing, shipping, or other site use classification) to be applied to the address.
  • STATUS and ERROR_CODE — the interface processing outcome; STATUS indicates whether the row is pending, processed, or in error, while ERROR_CODE carries the validation failure code when import fails.
  • MATCH_IND — indicates whether the row was matched to an existing usage or represents a new insertion.
  • ORG_ID — the operating unit / organization context, essential when the same interface table serves multiple organizations.
  • The WHO and concurrent-program columns (REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE) — used to trace which concurrent request loaded each row.

Common Use Cases and Queries

Typical scenarios include troubleshooting a failed address usage import, reconciling pending interface rows before running the Student System address load, and auditing which request introduced a given usage record. A common query filters on the interface address identifier the user searched for:

SELECT interface_addr_id, interface_addrusage_id, site_use_code,
status, error_code, match_ind, org_id, request_id
FROM apps.igs_ad_addrusage_int
WHERE interface_addr_id = :p_interface_addr_id;

A second pattern identifies all rows still awaiting processing:

SELECT interface_addr_id, site_use_code, status, error_code
FROM apps.igs_ad_addrusage_int
WHERE status <> 'PROCESSED'
ORDER BY creation_date;

A third reconciles a specific concurrent request:

SELECT request_id, program_id, interface_addr_id, status, error_code
FROM apps.igs_ad_addrusage_int
WHERE request_id = :p_request_id;

Because the view is read-mostly in practice, queries should be limited by ORG_ID, INTERFACE_ADDR_ID, or REQUEST_ID to avoid full scans of what is typically a high-volume interface table. Error rows should be inspected via ERROR_CODE and corrected either through the standard interface API or by direct DML on the base table where the view is key-preserving.