Results for “jtot_object1_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IEX_EXCLUSION_HIST_B is a transactional table in the Oracle E-Business Suite Collections (IEX) module. It stores the history of contracts that have been excluded from delinquency reports, allowing collections personnel to suppress specific transactions, agreements, or customer obligations from aging and dunning analysis while retaining an auditable record of the exclusion. In Oracle EBS 12.1.1 and 12.2.2 the object resides in the IEX schema and is validated as of the 12.2.2 ETRM documentation set.

The table is the base ("_B") entity of an exclusion history pair, with the corresponding translation table conventionally holding the "_TL" suffix. It is managed in the Oracle Forms-based Collections application framework and follows the standard EBS WHO-column audit pattern.

From a Data Vault modeling perspective, the mined relationship heuristic classifies this object as standalone, meaning the documented schema exposes no outgoing foreign keys. A reasonable modeling suggestion is therefore to treat it as a satellite or a hub-like standalone entity keyed by EXCLUSION_HISTORY_ID, with the descriptive exclusion attributes as payload. This is a heuristic classification, not a documented EBS design statement.

Key Information Stored

The table contains 32 documented columns. The most significant are:

• EXCLUSION_HISTORY_ID — surrogate primary key, enforced by the IEX_EXCLUSION_HIST_B_PK constraint. This is the column referenced by the search term iex_exclusion_hist_b_pk.
• OBJECT1_ID1 and OBJECT1_ID2 — the identifying values of the excluded object (for example, a customer or transaction identifier pair).
• JTOT_OBJECT1_CODE — the object type code (JTF Object Type) that qualifies what OBJECT1_ID1/ID2 represent.
• EXCLUSION_REASON — the reason the contract was excluded from delinquency reporting.
• EFFECTIVE_START_DATE and EFFECTIVE_END_DATE — the date range over which the exclusion applies.
• CANCEL_REASON and CANCELLED_DATE — capture manual cancellation of an active exclusion.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the OAF/Forms layer.
• ORG_ID — multi-org operating unit discriminator.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the standard EBS descriptive flexfield segment columns.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — WHO audit columns.

Only the surrogate key is documented as a primary key. No secondary unique index is documented in the supplied metadata, so business-key candidates such as OBJECT1_ID1/OBJECT1_ID2 combined with EFFECTIVE_START_DATE remain unverified.

Common Use Cases and Queries

Typical use is to report which contracts are currently suppressed from delinquency output and why.

• List active exclusions for an operating unit within a date range.
• Audit who excluded or cancelled an exclusion and when.
• Trace historical exclusions for a specific customer or transaction.
• Reconcile delinquency reports against exclusions to explain missing records.

Representative SQL:

SELECT h.exclusion_history_id,
       h.object1_id1,
       h.object1_id2,
       h.jtot_object1_code,
       h.exclusion_reason,
       h.effective_start_date,
       h.effective_end_date
  FROM iex.iex_exclusion_hist_b h
 WHERE h.org_id = :org_id
   AND TRUNC(SYSDATE) BETWEEN h.effective_start_date
                          AND NVL(h.effective_end_date, SYSDATE);

SELECT h.exclusion_history_id,
       h.cancel_reason,
       h.cancelled_date,
       h.last_updated_by,
       h.last_update_date
  FROM iex.iex_exclusion_hist_b h
 WHERE h.cancelled_date IS NOT NULL
   AND h.last_update_date >= :since_date;

For current-state reporting, filter on EFFECTIVE_START_DATE/EFFECTIVE_END_DATE and on the absence of CANCELLED_DATE.

Related Objects

The mined relationship data classifies IEX_EXCLUSION_HIST_B as standalone with no documented foreign keys, so the relationships below are derived from naming conventions and the EBS Collections functional model rather than enforced constraints:

• IEX_EXCLUSION_HIST_TL — translation table sharing EXCLUSION_HISTORY_ID.
• JTF_OBJECTS_B / JTF_OBJECTS_TL — resolve JTOT_OBJECT1_CODE to an object type name.
• IEX_DELINQUENCIES and the delinquency reporting tables — consume exclusion records when generating aging and dunning output.
• HZ_CUST_ACCOUNTS / HZ_CUST_ACCT_SITES_ALL — customers whose obligations are excluded.
• AR_PAYMENT_SCHEDULES_ALL and RA_CUSTOMER_TRX_ALL — transactions referenced by OBJECT1_ID1/OBJECT1_ID2.
• The Collections exclusion maintenance form/OAF page, which inserts, updates, and cancels rows via this table.

Because no FK constraints are documented, join predicates on OBJECT1_ID1/OBJECT1_ID2 and ORG_ID should be validated against the specific object type code in use before being relied upon in production queries.