Search Results response_exclusion_code

Overview

IES_SVY_RESP_ENTRIES_V is a reporting view owned by the APPS schema within the IES – Scripting product family of Oracle E-Business Suite. It exposes survey response entries captured by the Scripting (IES) survey engine, presenting a flattened, read-optimized projection of the underlying response entry records. In Oracle EBS 12.1.1 and 12.2.2, this view functions as the principal access point for extracting survey response data without querying the base table directly. It carries a VALID status in the data dictionary and is defined over a synonym that resolves to the underlying transaction table.

The view is significant because it surfaces the RESPONSE_EXCLUSION_CODE column, which allows reporting layers to distinguish responses that were deliberately excluded from scoring, analysis, or downstream processing (for example, abandoned, invalidated, or test responses) from responses that count toward survey results. Its presence in the view text makes it the search target for analysts investigating why specific survey responses were omitted from aggregate calculations.

Underlying Base Objects

The view is defined over IES_SVY_RESPONSE_ENTRIES (referenced through its APPS synonym), aliased as REA in the view text. The view performs a direct column projection with no joins, aggregations, filters, or calculations, meaning every row in the base table appears once in the view. This one-to-one relationship preserves the base table’s row count, primary key behavior, and object versioning semantics. Because no WHERE clause is applied, the view does not implicitly exclude soft-deleted records; filtering on the F_DELETEDFLAG column remains the responsibility of the querying application or report.

Key Columns

• RESPONSE_ID – Primary identifier for the survey response entry.
• SURVEY_DEPLOYMENT_ID – Links the response to the specific deployment of a survey instrument.
• SURVEY_LIST_ENTRY_ID – Associates the response with the survey list entry (typically the subject or participant).
• TRANSACTION_ID / INTERACTION_ID – Connect the response to the originating transaction or interaction record.
• RESPONSE_SEQUENCE – Ordinal position of the response within the collection flow.
• RESPONSE_COLLECTED_DATE – Timestamp when the response was captured.
• RESPONSE_MEDIA_TYPE_CODE – Channel or medium through which the response was collected.
• PASSTHROUGH_REQUIRED_CODE – Indicates whether a passthrough operation was required for this entry. Note that the documented view text contains a typographical discrepancy in the alias (PASSTHROUGH__REQUIRED_CODE with a double underscore); the exposed column name itself is PASSTHROUGH_REQUIRED_CODE.
• RESPONSE_EXCLUSION_CODE – The critical column for exclusion analysis, identifying the reason a response was excluded from results.
• F_DELETEDFLAG – Soft-delete indicator; must be checked to avoid returning logically deleted responses.
• SECURITY_GROUP_ID – Multi-tenant / security grouping discriminator.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard EBS audit and optimistic locking columns.

Common Use Cases and Queries

Typical uses include excluding logic validation, response volume reporting, and integration feeds to analytics platforms. The following examples filter soft-deleted records and surface responses carrying an exclusion code:

• Identify excluded responses: SELECT RESPONSE_ID, SURVEY_DEPLOYMENT_ID, RESPONSE_EXCLUSION_CODE FROM APPS.IES_SVY_RESP_ENTRIES_V WHERE F_DELETEDFLAG = 'N' AND RESPONSE_EXCLUSION_CODE IS NOT NULL;
• Count valid versus excluded responses per deployment: SELECT SURVEY_DEPLOYMENT_ID, RESPONSE_EXCLUSION_CODE, COUNT(*) FROM APPS.IES_SVY_RESP_ENTRIES_V WHERE F_DELETEDFLAG = 'N' GROUP BY SURVEY_DEPLOYMENT_ID, RESPONSE_EXCLUSION_CODE;
• Retrieve responses for a specific interaction: SELECT RESPONSE_ID, RESPONSE_SEQUENCE, RESPONSE_COLLECTED_DATE FROM APPS.IES_SVY_RESP_ENTRIES_V WHERE INTERACTION_ID = :interaction_id AND F_DELETEDFLAG = 'N' ORDER BY RESPONSE_SEQUENCE;

Because the view is a straight projection, queries gain no performance benefit over the base table; indexing and security policies defined on IES_SVY_RESPONSE_ENTRIES govern access behavior. Customizations should treat the view as read-only and apply F_DELETEDFLAG = 'N' filtering consistently.