Search Results qa_in_lists_u1

Overview

QA.QA_IN_LISTS is a QA schema table in Oracle E-Business Suite that stores the individual list-of-values entries associated with an In or Not In operator within collection plan query definitions. In collection planning and quality data collection, operators such as In and Not In require an explicit set of comparison values; QA_IN_LISTS persists those values so the originating query predicate can be reconstructed and evaluated at runtime. The table is owned by the QA schema, carries FND Design Data registration, and has a status of VALID across the 12.1.1 and 12.2.2 releases. Its physical storage resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10.

The object is documented as standalone with respect to foreign key dependencies: it references no other database object and, within the documented dependency set, is referenced only by the APPS synonym QA_IN_LISTS. From a Data Vault modeling perspective, the metadata heuristic classifies QA_IN_LISTS as a standalone structure. It can therefore be treated as a candidate hub-like entity keyed on the list element identity, with the list membership attributes (LIST_ID, PARENT_BLOCK_NAME, VALUE) forming the natural business key.

Key Information Stored

• LIST_ELEM_ID — NUMBER; the surrogate primary key (QA_IN_LISTS_PK) that uniquely identifies a list element record.
• LIST_ID — NUMBER; the list identifier that groups elements belonging to the same In/Not In list definition. Together with PARENT_BLOCK_NAME and VALUE it forms the unique business key QA_IN_LISTS_U2.
• PARENT_BLOCK_NAME — VARCHAR2(50); the name of the parent block in which the in-list has been defined.
• VALUE — VARCHAR2(150); one of the values contained in the list, stored as text.
• VALUE_ID — NUMBER; the value identifier associated with the list entry.
• CHAR_ID — NUMBER; the collection element used in defining the list.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard Who columns providing audit and concurrency information.

Two unique indexes enforce the documented business constraints. QA_IN_LISTS_U1 guarantees uniqueness of LIST_ELEM_ID (the surrogate key). QA_IN_LISTS_U2 guarantees that no duplicate (LIST_ID, PARENT_BLOCK_NAME, VALUE) combination exists. Both indexes reside in the APPS_TS_TX_IDX tablespace, separating index storage from the APPS_TS_TX_DATA table data.

Common Use Cases and Queries

Reporting on in-list membership supports validation of collection plan predicates and auditing of list definitions before they are executed. A typical pattern retrieves all values for a given list and parent block:

• Reconstruct an in-list: SELECT VALUE FROM QA.QA_IN_LISTS WHERE LIST_ID = :list_id AND PARENT_BLOCK_NAME = :block_name ORDER BY VALUE;
• Cross-check duplicates using the business key: SELECT LIST_ID, PARENT_BLOCK_NAME, VALUE, COUNT(*) FROM QA.QA_IN_LISTS GROUP BY LIST_ID, PARENT_BLOCK_NAME, VALUE HAVING COUNT(*) > 1;
• Audit recent changes: SELECT LIST_ELEM_ID, LIST_ID, VALUE, LAST_UPDATE_DATE, LAST_UPDATED_BY FROM QA.QA_IN_LISTS WHERE LAST_UPDATE_DATE >= :since;
• Enumerate the full documented column set: SELECT LIST_ELEM_ID, LIST_ID, PARENT_BLOCK_NAME, VALUE, VALUE_ID, CHAR_ID FROM QA.QA_IN_LISTS;

These queries are useful when diagnosing a failing collection plan predicate, confirming which values were in scope at the time of collection, or extracting list metadata for downstream quality analytics.

Related Objects

• APPS.QA_IN_LISTS — the APPS synonym that exposes QA.QA_IN_LISTS to application-level queries.
• QA_IN_LISTS_PK — primary key constraint on LIST_ELEM_ID, the anchor for element-level joins.
• QA_IN_LISTS_U1 — unique index on LIST_ELEM_ID, supporting surrogate-key lookups.
• QA_IN_LISTS_U2 — unique index on (LIST_ID, PARENT_BLOCK_NAME, VALUE), supporting business-key enforcement and list reconstruction.

The documented dependency set records no additional FK relationships, so joins to collection plan or value-set tables should be confirmed against the deployed instance before being relied upon.