Search Results qa_skiplot_log_u1

Overview

QA.QA_SKIPLOT_LOG is a diagnostic log table in the Oracle E-Business Suite Quality Management (QA) module, resident in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10. In the Oracle EBS 12.1.1 and 12.2.2 releases, the Skiplot (skip lot) feature allows an inspection plan to bypass routine sampling for a defined number of consecutive lots once supplier quality has been demonstrated. When the Skiplot concurrent program or its supporting PL/SQL routines encounter processing conditions — validation failures, plan evaluation exceptions, or informational events — those messages are written to QA_SKIPLOT_LOG rather than terminated silently. The table therefore functions as an auditable trail of Skiplot execution and error handling, and is typically interrogated by technical support and QA administrators diagnosing skipped-inspection behavior.

From a Data Vault modeling perspective, the mined metadata classifies this object heuristically as a standalone entity. It carries no foreign keys to other tables and holds a single-column surrogate primary key, so it is best understood as a self-contained record of events rather than a hub, link, or satellite participating in a modelled business key network.

Key Information Stored

The table contains nine documented columns. LOG_ID is a NUMBER column and serves as the surrogate primary key, enforced by the constraint QA_SKIPLOT_LOG_PK1. The same column is also the sole column of the unique index QA_SKIPLOT_LOG_U1 (NORMAL, UNIQUE, APPS_TS_TX_IDX), which means the surrogate is simultaneously the only documented business-key candidate; no natural or composite key is exposed, so LOG_ID is the unique handle by which any log entry must be identified and joined.

• LOG_ID — numeric primary key and unique-index column; the row identifier for each Skiplot log record.
• MODULE_NAME — VARCHAR2(50); identifies the program, package, or functional module that emitted the entry, enabling attribution of messages to a specific Skiplot routine.
• ERROR_MESSAGE — VARCHAR2(3000); the diagnostic text produced by the process, including error descriptions and exception details.
• COMMENTS — VARCHAR2(3000); free-form supplementary context accompanying the entry.
• CREATED_BY and CREATION_DATE — standard WHO columns recording the user or process that inserted the record and when it was created.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — standard WHO columns capturing the most recent modification and the login under which it occurred.

The two VARCHAR2(3000) message columns and the WHO chronological columns form the analytical core of the table; MODULE_NAME supplies the grouping dimension, and the creation/update timestamps supply the time dimension.

Common Use Cases and Queries

The most frequent use case is troubleshooting a Skiplot run that failed to skip a lot or that aborted partway through processing a supplier's inspection plan. Because the table is an append-oriented log, the practical query is a recency-ordered scan filtered by module and date.

• Recent error review: SELECT LOG_ID, MODULE_NAME, ERROR_MESSAGE, COMMENTS, CREATION_DATE FROM QA.QA_SKIPLOT_LOG WHERE TRUNC(CREATION_DATE) = TRUNC(SYSDATE) ORDER BY LOG_ID DESC;
• Module-specific diagnostics: filter on MODULE_NAME with a LIKE predicate to isolate messages from a single Skiplot program or package.
• Message pattern frequency: group by MODULE_NAME and count rows over a period to identify recurring failure signatures or a module that is generating repeated warnings.
• Audit and traceability: join CREATED_BY to per_all_people_f or fnd_user to translate the numeric WHO value into a user name when entries are attributed to a logged-in user rather than a concurrent request.
• Monitoring and purging: since entries carry no reference to a lot, plan, or supplier, retention policies should be time-based; a scheduled purge using LAST_UPDATE_DATE or CREATION_DATE keeps the APPS_TS_TX_DATA segment from growing unbounded.

Reporting usage is deliberately limited: the table supports operational diagnostics and error-rate trending, not transactional QA reporting. Analysts should treat ERROR_MESSAGE and COMMENTS as unstructured text and avoid exact-match predicates against them.

Related Objects

The documented dependency information records no foreign-key relationships: QA_SKIPLOT_LOG references no database object. The dependency listing states that it is referenced by the APPS synonym QA_SKIPLOT_LOG, which is how most application code and ad-hoc SQL resolve the QA schema object at runtime. Because the table is standalone, joins to the wider Quality schema are implicit and text-driven rather than constraint-driven; the following objects are the ones most commonly consulted alongside it when interpreting Skiplot activity.

• QA_SKIPLOT_LOG_U1 — the unique index on LOG_ID; the access path for single-row lookups.
• QA_SKIPLOT_LOG_PK1 — the primary-key constraint enforcing uniqueness of LOG_ID.
• APPS.QA_SKIPLOT_LOG — the APPS synonym, the presentation-layer entry point for queries from custom code.
• QA_SKIPLOT_HEADERS — the Skiplot plan header definition, referenced implicitly by module name when determining which plan was being evaluated.
• QA_SKIPLOT_LOTS — the skip-lot state table recording lot-level counters and skip decisions; the primary companion object when correlating log entries to skipped inspections.
• FND_USER and PER_ALL_PEOPLE_F — used to resolve CREATED_BY and LAST_UPDATED_BY into human-readable identities.
• FND_CONCURRENT_REQUESTS — used to associate a log entry's timestamp with the Skiplot concurrent request that produced it.

Note that the documented metadata records a single-level dependency only, so any join to QA_SKIPLOT_HEADERS, QA_SKIPLOT_LOTS, or elsewhere must be constructed from business columns such as MODULE_NAME and timestamps rather than from a declared key.