Search Results csi_mass_edit_entries_pk

Overview

CSI_MASS_EDIT_ENTRIES_B is the base table that stores individual transaction entries generated by the Install Base mass edit process in Oracle E-Business Suite. It resides in the CSI schema and belongs to the CSI - Install Base product family. The object is documented as a base table, which typically implies the presence of a corresponding translation or interface companion table (for example, an _TL or _A variant) depending on whether translatable columns exist. In the context of both EBS 12.1.1 and 12.2.2, this table captures the granular rows produced when a mass edit program processes a batch of install base instances, recording scheduling information, execution status, and audit metadata for each affected transaction line.

From a data modeling perspective, the mined Data Vault classification is standalone, suggesting this object functions as an independent satellite-like structure that records the outcome of a batch process rather than acting as a conventional hub or link. The classification is heuristic and should be treated as a modeling suggestion, not a definitive architectural directive.

Key Information Stored

The table contains 19 documented columns. The surrogate primary key is ENTRY_ID, enforced through the CSI_MASS_EDIT_ENTRIES_PK constraint. A secondary unique index, CSI_MASS_EDIT_ENTRIES_U01, is defined on TXN_LINE_ID, making that column the principal business-key candidate and ensuring one entry per transaction line.

• ENTRY_ID — surrogate primary key uniquely identifying each mass edit entry.
• TXN_LINE_ID — the business-key candidate linking the entry to the underlying transaction line being processed.
• STATUS_CODE — current processing state of the entry (for example, pending, completed, or error).
• SCHEDULE_DATE — the date the entry is planned to be executed by the mass edit process.
• START_DATE / END_DATE — the effective window during which the entry applies or is valid.
• BATCH_TYPE — categorizes the mass edit batch that generated the entry, supporting downstream reporting and retry logic.
• REQUEST_ID — the concurrent request identifier, essential for tracing the entry back to the submitting mass edit program run.
• PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — standard concurrent program stamps indicating which executable produced the row and when it last ran.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard who-column audit fields.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle Applications Framework.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-tenant data security.
• SYSTEM_CASCADE — indicator controlling whether changes propagate to dependent instances.

Common Use Cases and Queries

Typical usage centers on monitoring, troubleshooting, and auditing mass edit activity across the install base. Support engineers frequently query the table by REQUEST_ID to determine which entries a specific concurrent request generated and whether any remain in an error state.

• Error triage: SELECT ENTRY_ID, TXN_LINE_ID, STATUS_CODE, REQUEST_ID FROM CSI.CSI_MASS_EDIT_ENTRIES_B WHERE STATUS_CODE = 'ERROR';
• Batch progress: aggregate counts grouped by STATUS_CODE and BATCH_TYPE to track completion rates.
• Scheduling review: filter on SCHEDULE_DATE and START_DATE/END_DATE to identify overdue or overlapping entries.
• Concurrent program lineage: join on REQUEST_ID to FND_CONCURRENT_REQUESTS to surface program names and run durations.
• Security-scoped reporting: constrain results by SECURITY_GROUP_ID for restricted access environments.

Because the table records working-level entries rather than final instance state, most operational reports join it to transaction and instance tables to enrich the context.

Related Objects

• FND_SECURITY_GROUPS — referenced by CSI_MASS_EDIT_ENTRIES_B.SECURITY_GROUP_ID; drives data security partitioning.
• CSI_MASS_EDIT_ENTRIES_PK — primary key constraint on ENTRY_ID.
• CSI_MASS_EDIT_ENTRIES_U01 — unique index on TXN_LINE_ID enforcing one entry per transaction line.
• CSI_MASS_EDIT_HEADERS / batch tables — related mass edit parent structures summarizing the batch that produced entries.
• CSI_TXN_LINES / transaction line objects — the TXN_LINE_ID column links entries to their originating transaction lines.
• FND_CONCURRENT_REQUESTS — joined via REQUEST_ID for program execution tracing.
• CSI_INSTANCE_* instance tables — downstream consumers affected by mass edit changes.
• CSI_ITEM_INSTANCES — the primary install base instance entity whose records are mass edited.

Collectively, these relationships position CSI_MASS_EDIT_ENTRIES_B as the operational entry point for diagnosing and reconciling mass edit activity within the Install Base module.