Search Results csi_mass_edit_entries_u01

Overview

CSI.CSI_MASS_EDIT_ENTRIES_B is a transactional base table within the Oracle E-Business Suite Customer Intelligence (CSI) schema. It stores Instance Mass Edit Transaction Entries — that is, the individual line-level records generated when a mass edit operation is executed against installed-base instance data. In Oracle EBS 12.1.1 and 12.2.2, mass edit processing is used to bulk-apply changes (such as status, ownership, or attribute updates) across many customer product instances without editing them one at a time. This table is the staging and tracking layer that holds one row per mass edit transaction line, along with scheduling and processing timestamps and outcome status.

The object resides in the APPS_TS_TX_DATA tablespace and is designated VALID in the ETRM repository, with FND Design Data mapping CSI.CSI_MASS_EDIT_ENTRIES_B. Its unique index CSI_MASS_EDIT_ENTRIES_U01 resides in the APPS_TS_TX_IDX tablespace, reflecting the standard EBS separation of transactional data and index storage.

Based on the documented foreign key to FND_SECURITY_GROUPS and the absence of outbound references beyond that lookup, the table is classified heuristically as a standalone structure. In Data Vault terms, this suggests treating it as a satellite-like entity: its rows describe state and lifecycle events (status, schedule, start, end) attached to a transaction-line business key, rather than acting as a connection between two hubs. This classification is a modeling suggestion only; the physical table is a conventional transactional table.

Key Information Stored

The table contains 19 documented columns. The most operationally significant are:

• ENTRY_ID — the surrogate primary key, enforced by CSI_MASS_EDIT_ENTRIES_PK, uniquely identifying each mass edit transaction entry.
• TXN_LINE_ID — the transaction line identifier. This is the documented business-key candidate, enforced by the unique index CSI_MASS_EDIT_ENTRIES_U01 in APPS_TS_TX_IDX.
• STATUS_CODE — VARCHAR2(30) holding the processing status of the mass edit entry, driving which records are pending, in progress, successful, or failed.
• SCHEDULE_DATE, START_DATE, END_DATE — the lifecycle timestamps: when the entry was scheduled, when processing began, and when it completed.
• BATCH_TYPE — VARCHAR2(30) identifying the batch category of the mass edit run.
• SYSTEM_CASCADE — a flag indicating whether the entry was produced by a system-originated cascade rather than direct user action.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context, used for Party/Account Merge processing and for reconciling entries back to the concurrent request that generated them.
• SECURITY_GROUP_ID — security group identifier, referenced by the foreign key to FND_SECURITY_GROUPS and used for multi-org style data isolation.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER — standard WHO audit columns plus optimistic locking via the object version number.

Common Use Cases and Queries

The dominant use case is monitoring and troubleshooting mass edit runs. Support and operations teams query pending or failed entries, reconcile completed batches by request, and measure elapsed processing time.

Typical query patterns include:

• Retrieving all entries for a specific concurrent request: SELECT TXN_LINE_ID, STATUS_CODE, START_DATE, END_DATE FROM CSI.CSI_MASS_EDIT_ENTRIES_B WHERE REQUEST_ID = :request_id;
• Listing failed or incomplete entries: SELECT ENTRY_ID, TXN_LINE_ID, STATUS_CODE, SCHEDULE_DATE FROM CSI.CSI_MASS_EDIT_ENTRIES_B WHERE STATUS_CODE NOT IN ('COMPLETE','SUCCESS');
• Measuring throughput by batch type using START_DATE and END_DATE.
• Identifying cascade-generated rows via SYSTEM_CASCADE for impact analysis.
• Joining to the security group lookup to confirm which security group owns a set of entries.

Because the table is a base ("_B") table without a documented "_TL" translation counterpart, reporting is straightforward and does not require language-join logic.

Related Objects

The ETRM metadata documents one outbound foreign key and the table's own primary key. The significant related objects are:

• FND_SECURITY_GROUPS — referenced through SECURITY_GROUP_ID; join on SECURITY_GROUP_ID to resolve security group context.
• CSI.CSI_MASS_EDIT_HEADERS — the header table for mass edit runs; the entry rows are the line detail beneath a header.
• CSI.CSI_MASS_EDIT_ENTRIES_PK — primary key constraint on ENTRY_ID.
• CSI_MASS_EDIT_ENTRIES_U01 — the unique index on TXN_LINE_ID that functions as the business-key candidate.
• FND_CONCURRENT_REQUESTS — join on REQUEST_ID to associate entries with their concurrent program run.
• CSI_INSTANCE_* instance tables — the installed-base records that a mass edit entry ultimately updates.

No other tables are documented as referencing this object, which is consistent with its standalone classification.