Search Results qa_skiplot_log




Overview
Explore in AI Chat

Overview

QA_SKIPLOT_LOG is a table in the Oracle E-Business Suite Quality (QA) module, owned by the QA schema. Its documented description is "Skip Lot Logs," indicating that it functions as a diagnostic and audit repository recording events, errors, and messages encountered during Skip Lot processing. Skip Lot is a sampling technique in Oracle Quality in which the frequency of inspection for a given item or supplier is reduced when a defined number of consecutive lots are accepted, and increased again when a rejection occurs. Because the Skip Lot engine evaluates sampling rules programmatically, it produces log entries that describe what the engine did, which module invoked it, and what went wrong when processing could not complete.

In Oracle EBS 12.1.1 and 12.2.2 the table resides in the QA schema and is exposed at the database tier as QA.QA_SKIPLOT_LOG. The primary key is QA_SKIPLOT_LOG_PK1, defined on the LOG_ID column, and a unique index QA_SKIPLOT_LOG_U1 also exists on LOG_ID. The table contains nine documented columns and is present with VALID status in both releases. From a Data Vault modeling perspective, the mined FK structure classifies this object as standalone, so a heuristic suggestion is to model it as a satellite or a standalone hub, since it does not participate in documented foreign key relationships with other QA entities. In practice, treat it as a technical log table rather than a transactional business entity.

Key Information Stored

The table holds nine documented columns, of which the following are the most significant:

  • LOG_ID — The surrogate primary key and the column behind both QA_SKIPLOT_LOG_PK1 and the unique index QA_SKIPLOT_LOG_U1. It is the sole documented unique business-key candidate, meaning the log is addressed by a generated identifier rather than a natural composite key.
  • MODULE_NAME — Identifies the calling module or process that generated the entry, allowing administrators to trace which Skip Lot routine, concurrent program, or integration produced the log line.
  • ERROR_MESSAGE — The diagnostic text captured when Skip Lot evaluation fails or encounters an exception. This is the primary troubleshooting payload of the table.
  • COMMENTS — Free-form supplementary notes recorded by the process, typically providing context that is not captured in the structured error text.
  • LAST_UPDATE_DATE and LAST_UPDATED_BY — Standard EBS WHO columns recording when and by which application user the row was last changed.
  • CREATION_DATE and CREATED_BY — Standard WHO columns recording row creation timestamp and creating user; these are the effective audit trail for the log entry.
  • LAST_UPDATE_LOGIN — The login identifier of the session responsible for the most recent update, used for session-level auditing.

No foreign key columns are documented; the table is self-contained and keyed only by LOG_ID.

Common Use Cases and Queries

The most frequent use case is troubleshooting Skip Lot behavior when inspection frequency is not changing as expected, or when a concurrent process aborts. Support and technical teams query the table by time window and module to isolate failures:

  • Recent failures: SELECT LOG_ID, MODULE_NAME, ERROR_MESSAGE, CREATION_DATE FROM QA.QA_SKIPLOT_LOG WHERE CREATION_DATE > SYSDATE - 7 ORDER BY CREATION_DATE DESC;
  • Module-specific triage: SELECT * FROM QA.QA_SKIPLOT_LOG WHERE MODULE_NAME = :module ORDER BY LOG_ID DESC;
  • Volume and trend reporting: SELECT TRUNC(CREATION_DATE), MODULE_NAME, COUNT(*) FROM QA.QA_SKIPLOT_LOG GROUP BY TRUNC(CREATION_DATE), MODULE_NAME;
  • Audit lookup by identifier: SELECT * FROM QA.QA_SKIPLOT_LOG WHERE LOG_ID = :log_id;

Because the table is a log, typical reporting focuses on error frequency, repeat offenders by MODULE_NAME, and purge strategy. Administrators frequently pair it with a housekeeping concurrent request to delete entries older than a retention threshold, joining only on CREATION_DATE rather than on foreign keys. Direct DML should be avoided; the table is maintained by application code.

Related Objects

The documented metadata classifies QA_SKIPLOT_LOG as standalone with no FK relationships, so no join columns to parent tables are available. The following objects are the most relevant surrounding context in the QA module:

  • QA_SKIPLOT_HEADERS — Defines Skip Lot sampling plans; the engine that populates QA_SKIPLOT_LOG operates against these definitions.
  • QA_SKIPLOT_LINES — Detail rows of Skip Lot plans, governing item or supplier level sampling behavior.
  • QA_SKIPLOT_HISTORY — Historical Skip Lot state transitions; complements the operational log for auditing.
  • QA_PLANS and QA_PLAN_CHARACTERISTICS — Sampling and collection plans that consume Skip Lot results.
  • FND_LOG_MESSAGES and FND_LOG_METADATA — The generic EBS logging framework, useful for correlating QA module messages with application-level debug output.
  • FND_CONCURRENT_REQUESTS — Concurrent program executions that commonly trigger Skip Lot processing and therefore generate log rows.

Where FK data is absent, joins should be performed on MODULE_NAME, CREATION_DATE, or other non-key columns rather than on undocumented key relationships.