Search Results as_script_actual_answers_v

Overview

AS_SCRIPT_ACTUAL_ANSWERS_V is a Sales Foundation (AS) reporting view that exposes the answers captured when a sales script is executed during an interaction. Where the underlying transaction table AS_SCRIPT_ACTUAL_ANSWERS stores the raw answer rows tied to a script, interaction, and question, the view joins each answer to its predefined answer definition and resolves the answer's processing status into a readable meaning. This makes it the standard access point for reporting on script responses, questionnaire outcomes, and their lifecycle status.

The view is significant to the user's search term "processing_status" because its STATUS column is populated from the AS_LOOKUPS table using the lookup type 'PROCESSING_STATUS'. In other words, STATUS_CODE holds the internal code value and STATUS holds the corresponding user-facing meaning. Any report, concurrent program, or integration that needs the human-readable processing status of a script answer should select STATUS rather than decoding STATUS_CODE manually against FND_LOOKUPS or AS_LOOKUPS.

The object is documented as a view (not a table) and is described in the ETRM repository as "Script actual answers view." It is a query-only construct, so it carries no update, insert, or DML semantics of its own.

Underlying Base Objects

The documented view text identifies three source objects in the FROM clause:

• AS_SCRIPT_ACTUAL_ANSWERS (alias AA) — the driving table holding the captured answer rows, including SCRIPT_ACTUAL_ANSWER_ID, SCRIPT_ID, INTERACTION_ID, QUESTION_ID, STATUS_CODE, COMMENTS, and the fifteen descriptive flexfield attribute columns.
• AS_SCRIPT_PRE_DEFINED_ANSWERS (alias PDA) — the predefined answer definitions, joined on PDA.SCRIPT_PRE_DEF_ANSWER_ID = AA.PRE_DEF_ANSWER_ID. This supplies ENABLED_FLAG, QUESTION_SEQ, LABEL, and ANSWER.
• AS_LOOKUPS (alias ASLKP) — the lookup source joined on AA.STATUS_CODE = ASLKP.LOOKUP_CODE and ASLKP.LOOKUP_TYPE = 'PROCESSING_STATUS', supplying the MEANING that becomes the STATUS column.

Both the predefined-answer join and the status-code join are outer joins (+), so an answer row is retained even when no matching predefined answer or lookup meaning exists. The ETRM metadata records no separately documented base objects and notes "Not implemented in this database," indicating the view is delivered as part of the AS schema but is instantiated only where the Sales Foundation script feature is installed.

Key Columns

• SCRIPT_ACTUAL_ANSWER_ID — primary identifier for the captured answer row.
• SCRIPT_ID / INTERACTION_ID — identify the script and the interaction in which the answer was recorded.
• CUSTOMER_ID, ADDRESS_ID, CONTACT_ID, EVENT_OFFERING_ID — the parties and offering context associated with the answer.
• PRE_DEF_ANSWER_ID, QUESTION_ID, QUESTION_SEQ, ANSWER_LABEL, ANSWER, ANSWER_ENABLED_FLAG — question and predefined-answer detail; QUESTION_SEQ orders questions, while ANSWER carries the answer text or choice.
• STATUS_CODE and STATUS — the coded value and its 'PROCESSING_STATUS' meaning. This is the column pair most relevant to the user's query.
• COMMENTS — free-text notes captured with the answer.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the descriptive flexfield segments for site-specific extensions.
• WHO columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical scenarios include auditing script responses per interaction, monitoring answers by processing status, and feeding downstream analytics. The following query groups answers by their readable status:

• SELECT STATUS, COUNT(*) FROM AS_SCRIPT_ACTUAL_ANSWERS_V GROUP BY STATUS;
• SELECT SCRIPT_ID, INTERACTION_ID, QUESTION_SEQ, ANSWER_LABEL, ANSWER, STATUS FROM AS_SCRIPT_ACTUAL_ANSWERS_V WHERE STATUS = 'Processed' ORDER BY SCRIPT_ID, QUESTION_SEQ;
• SELECT SCRIPT_ACTUAL_ANSWER_ID, CUSTOMER_ID, STATUS_CODE, STATUS FROM AS_SCRIPT_ACTUAL_ANSWERS_V WHERE INTERACTION_ID = :p_interaction_id;

Because STATUS is an outer-joined lookup meaning, statuses that lack a matching PROCESSING_STATUS lookup row will surface a NULL STATUS; reports should test STATUS_CODE where completeness matters.