Search Results header_interface_main

Overview

The APPS.IGC_CC_OPEN_INTERFACE_PKG package is a PL/SQL interface component within the Oracle E-Business Suite Contracts (formerly Oracle Projects/IGC) module. It belongs to the Contracts Core (CC) schema family and serves as the inbound integration layer for bringing external data into the Contracts application tables. The package is classified as an OTHER API, indicating that it is not a public, supported open interface with a published parameter specification but is instead an internal interface used primarily by concurrent programs and upstream feeder processes to load and validate records.

The package operates on three distinct interface entity types: contract headers, accounting lines, and detail performance obligation (PF) records. Each entity type is handled by a paired validation and main procedure, following the standard Oracle interface pattern of staging, validating, and then importing data into base transaction tables. The package status is documented as VALID in the APPS schema in both Oracle EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented interface exposes six procedures, organized as three logical pairs:

• HEADER_INTERFACE_MAIN — Drives the import of contract header interface records into the base header structures, orchestrating the transition from staging to final tables.
• HEADER_INTERFACE_VALIDATE — Performs validation of header interface rows prior to import, checking referential and business-rule prerequisites and flagging rejected records.
• ACCT_LINE_INTERFACE_MAIN — Executes the main processing logic that moves validated accounting line interface records into the contract accounting line tables.
• ACCT_LINE_INTERFACE_VALIDATE — Validates accounting line interface rows, verifying code combinations, periods, and required attributes before import.
• DET_PF_INTERFACE_MAIN — Processes detail performance obligation interface records into the corresponding base tables.
• DET_PF_INTERFACE_VALIDATE — Validates detail PF interface rows, ensuring structural and business constraints are met prior to main processing.

The consistent MAIN/VALIDATE pairing reflects a two-phase load design: validation is performed first to isolate errored rows, and the main routine processes the clean set. Parameter lists are not published in the ETRM metadata and should not be assumed.

Tables Accessed

The package reads and writes several categories of tables through APPS synonyms:

• Interface (staging) tables: IGC_CC_ACCT_LINES_INTERFACE, IGC_CC_DET_PF_INTERFACE — source rows for validation and import.
• Base transaction tables: IGC_CC_ACCT_LINES, IGC_CC_ACCT_LINES_S, IGC_CC_DET_PF, IGC_CC_DET_PF_S — targets for imported records, with the _S variants indicating key-flex or attribute-flex storage.
• Setup and reference: FINANCIALS_SYSTEM_PARAMETERS, FND_APPLICATION, FND_USER, HR_ALL_ORGANIZATION_UNITS, IGC_CC_BC_ENABLE — used for defaults, validation lookups, and organizational context.
• Accounting context: GL_CODE_COMBINATIONS, GL_PERIODS, GL_PERIOD_STATUSES — used to validate accounting flexfield combinations and confirm open accounting periods.
• Concurrency control: GL_BC_PACKETS_S — supports balancing/transfer packet handling where accounting integration is required.

Usage Notes

IGC_CC_OPEN_INTERFACE_PKG is referenced by no other packages in the documented dependency graph, indicating it is a top-level entry point rather than a shared library. It is typically invoked through concurrent programs that perform open interface imports for contracts, or through wrapper logic in feeder applications that populate the _INTERFACE tables. Custom code should treat this as an internal interface: rows should be inserted into the interface tables and the package invoked to validate and import them, rather than calling individual procedures directly without understanding the MAIN/VALIDATE sequencing. Because it is classified OTHER, it is not a supported public API subject to Oracle's interface guarantee; customizations should reference the documented interface tables and validate their own data assumptions against the GL and HR reference checks performed internally.