Results for “user_type_code”

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

Overview

IBY_F_T_CRDT_APP_REVS is a table in the IBY (Payments) product schema of Oracle E-Business Suite, available in both release 12.1.1 and 12.2.2. The object status is VALID and it is owned by the IBY schema. In functional terms, this table stores revision history records for credit card application objects used by Oracle Payments. Each row represents a discrete revision of a credit application, capturing the state of that application at a point in time along with the identity of the user who made the change and the type of revision performed. This makes the table a version-tracking or audit-oriented store rather than a transactional master.

The ETRM relationship data classifies this object, heuristically, as satellite-leaning. Under a Data Vault modeling interpretation, this is a suggestion that the table functions as a satellite attached to a parent hub or link (the credit application), holding descriptive and historical attributes keyed to a revision identifier. The classification is derived from the foreign key structure and should be treated as a modeling hint rather than a functional specification.

Key Information Stored

The documented physical schema for 12.2.2 contains 14 columns. The most significant are:

• REVISION_ID — the surrogate primary key, enforced by IBY_F_T_CRDT_APP_REVS_PK and also carried by the unique index IBY_F_T_CRDT_APP_REVS_U1. This is the column that uniquely identifies each revision row.
• CREDIT_APP_ID — the foreign key linking the revision to its parent credit application record in IBY_F_T_CRDT_APPS_ALL_B. This is the join path from history to master.
• CREDIT_APP_REV_NUM — the sequential revision number of the credit application, providing the human-readable ordering of versions.
• REVISION_TYPE_CODE — the code describing the nature of the revision event (for example, creation versus subsequent modification).
• REVISION_XML_DOC_ID — reference to the stored XML document containing the revision payload, which is where the actual snapshot content is held rather than in discrete columns.
• USER_ID and USER_TYPE_CODE — the identifier and classification of the user who performed the revision.
• SECURITY_GROUP_ID — the foreign key to FND_SECURITY_GROUPS, supporting multi-organization data access control.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the Oracle Application Framework to detect concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO columns present on practically all Oracle EBS transactional tables.

The surrogate key is REVISION_ID; the unique index on the same column confirms it as the business-key candidate documented by ETRM.

Common Use Cases and Queries

Typical uses of this table center on reconstructing the history of a credit application: auditing who changed an application and when, comparing successive revisions, and troubleshooting payment processing issues that depend on a prior version of an application.

• Listing all revisions for a given credit application:

  SELECT revision_id, credit_app_rev_num, revision_type_code, user_id, last_update_date FROM iby.iby_f_t_crdt_app_revs WHERE credit_app_id = :credit_app_id ORDER BY credit_app_rev_num;

• Identifying the latest revision for each application, commonly via a correlated subquery or analytic ranking on CREDIT_APP_REV_NUM partitioned by CREDIT_APP_ID.
• Audit reporting that joins USER_ID to the application user table to resolve the person responsible for each revision.
• Joining REVISION_XML_DOC_ID to the XML document store to retrieve the full revision payload for a specific change.

Queries should always filter on SECURITY_GROUP_ID where the environment is multi-org enabled, and should avoid selecting XML payloads in list-style reports.

Related Objects

• IBY_F_T_CRDT_APPS_ALL_B — the parent credit application table, joined on CREDIT_APP_ID.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID for data access control.
• IBY_F_T_CRDT_APP_REVS_PK — the primary key constraint on REVISION_ID.
• IBY_F_T_CRDT_APP_REVS_U1 — the unique index supporting the business key on REVISION_ID.
• Payment-related XML document storage objects referenced by REVISION_XML_DOC_ID.

Because the ETRM metadata for this object is relatively limited, the relationships above are the authoritative documented dependencies; broader functional context should be validated against the Oracle Payments data model in the target release.