Search Results fun_interface_rejections

Overview

FUN_INTERFACE_REJECTIONS is a Financials Common Modules (FUN) staging and error-capture table in Oracle E-Business Suite 12.1.1 and 12.2.2. It records rows that failed validation or processing during inbound interface loads into the FUN schema, most notably the upgrade and conversion utilities that migrate transactional distributions from legacy or external sources. Each row preserves the identifiers of the rejected batch, the originating transaction, and the associated accounting distribution, together with the diagnostic code and textual reason that caused the rejection. The table therefore acts as an exception ledger: successful rows move forward into the target application tables, while failing rows remain here for correction, reprocessing, or audit.

From a data-modeling perspective, the mined metadata classifies this object heuristically as a standalone entity. In Data Vault terms this suggests it is best treated as a standalone satellite-like record rather than a true hub or link. Because it references only a single foreign key and holds no independent business identity of its own, it is more accurately modeled as a dependent error-capture or satellite structure attached to the parent interface batch. It is not part of the shipped production transaction model; it is transient diagnostic infrastructure.

Key Information Stored

The documented physical schema (ETRM 12.2.2) contains six columns. Several are identifier columns drawn directly from the parent interface context rather than surrogate keys generated for this table. There is no documented separate surrogate primary key; the meaningful identity is the composite of the batch and distribution identifiers.

• BATCH_ID — Identifier of the interface batch that was being processed when the rejection occurred. This is the principal grouping key for auditing a load run.
• TRX_ID — Identifier of the originating transaction whose row was rejected.
• DIST_ID — Identifier of the distribution record within the source transaction. This column is the documented foreign key, referencing OKL_UPG_TRNS_ACC_DSTRS_T, which ties the rejection back to the specific upgrade distribution being processed.
• BATCH_DIST_ID — The batch-level distribution identifier produced or expected during the load; used to reconcile the staged row against the batch manifest.
• REJECT_CODE — Short coded indicator of the failure category, suitable for grouping and dashboard aggregation.
• REJECT_REASON — Free-form descriptive text explaining why the row failed validation or mapping.

Because the schema is narrow, there are no documented unique indexes or alternate business keys beyond the identifier set. Any uniqueness is enforced implicitly by the combination of BATCH_ID, TRX_ID, and DIST_ID. The absence of a dedicated surrogate key is consistent with the table being a transient exception log rather than a permanent master entity.

Common Use Cases and Queries

The primary use case is interface reconciliation and error remediation. Implementation and support teams query this table after running a FUN conversion or upgrade load to quantify and diagnose failures. A typical diagnostic query counts rejections by code for a given batch:

• SELECT reject_code, COUNT(*) FROM fun.fun_interface_rejections WHERE batch_id = :p_batch GROUP BY reject_code; — summarizes failure categories.
• SELECT trx_id, dist_id, reject_code, reject_reason FROM fun.fun_interface_rejections WHERE batch_id = :p_batch ORDER BY trx_id; — enumerates individual rejected rows for correction.
• Joining to OKL_UPG_TRNS_ACC_DSTRS_T on DIST_ID reconstructs the full source distribution context behind each rejection, supporting root-cause analysis.
• Aggregate reporting over REJECT_CODE trends across batches supports load-quality monitoring and pre-go-live data cleansing.

Because the table is an exception staging area, standard practice is to clear or archive rows once the underlying data is corrected and the batch is successfully reloaded.

Related Objects

• OKL_UPG_TRNS_ACC_DSTRS_T — Referenced by the documented foreign key FUN_INTERFACE_REJECTIONS.DIST_ID → OKL_UPG_TRNS_ACC_DSTRS_T; the source upgrade transaction accounting distributions table.
• FUN interface batch and control tables — The BATCH_ID column logically joins to the FUN batch-header/control structure that governs the load run.
• FUN_INTERFACE / FUN staging tables — The target staging structures into which rejected rows were being loaded before validation failed.
• OKL upgrade and conversion tables — The broader ORACLE Leasing (OKL) upgrade lineage from which the distributions and transactions originated.
• FUN concurrent programs — The interface and upgrade concurrent requests that populate this table during execution.

Collectively these objects describe the FUN inbound interface and upgrade error-handling chain, in which FUN_INTERFACE_REJECTIONS serves as the final diagnostic checkpoint.