Search Results source_flag

Overview

OKS_REPROCESSING_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, registered under the OKS – Service Contracts product family. It is documented as a VALID database object in both ETRM 12.1.1 and 12.2.2 environments. The view exposes the contents of the OKS_REPROCESSING staging table, which is used by the Service Contracts module to capture contract, order, and subline processing records that require reprocessing due to failed or incomplete processing runs. Within the Oracle EBS architecture, this view functions as a read-oriented interface layer over the base table, allowing concurrent programs, forms, and external integration components to query reprocessing status without directly binding to the physical table definition.

The view is particularly significant because it surfaces the CONC_REQUEST_ID column, which links each reprocessing row back to the concurrent request that generated or last touched it. This column is frequently searched for by administrators and developers who need to trace which concurrent program run produced a given reprocessing record, for example when diagnosing mass contract updates, order import failures, or service contract renewal issues.

Underlying Base Objects

According to the documented view text, OKS_REPROCESSING_V is defined as a straightforward projection over a single base object:

• OKS_REPROCESSING — referenced through a synonym in the APPS schema. The view selects every documented column from this table without joins, filters, unions, or aggregations.

Because the view does not join to other Service Contracts tables, it does not denormalize data; it simply renames ROWID to ROW_ID and re-exposes the remaining columns with their original names. Consequently, the cardinality and row-level semantics of the view are identical to those of OKS_REPROCESSING. Any DML performed directly against the base table is immediately visible through the view. Because the view is a thin wrapper, it is also subject to the same indexing and partitioning characteristics as the base table, and query performance is driven entirely by the underlying OKS_REPROCESSING access paths.

Key Columns

• ROW_ID — the ROWID of the base table row, exposed for direct row identification and updates.
• ID — the primary identifier for the reprocessing record.
• ORDER_ID / ORDER_LINE_ID — references to the Order Management order and order line associated with the reprocessing event.
• CONTRACT_ID / CONTRACT_LINE_ID / SUBLINE_ID — references to the Service Contracts header, line, and subline being processed.
• ERROR_TEXT — the error message captured when processing failed, used for troubleshooting.
• SUCCESS_FLAG and REPROCESS_YN — status indicators showing whether the row processed successfully and whether it is flagged for another reprocessing attempt.
• SOURCE_FLAG — identifies the originating source of the reprocessing record.
• CONC_REQUEST_ID — the concurrent request identifier that generated the record, enabling traceability to the Concurrent Manager request log.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the EBS framework.
• SECURITY_GROUP_ID — multi-org security grouping identifier, retained for compatibility with the EBS security model.

Common Use Cases and Queries

Typical scenarios include identifying all failed reprocessing rows for a specific concurrent request, monitoring outstanding reprocessing backlogs, and reconciling order-to-contract processing errors. A representative query that answers the "conc_request_id" search is:

• SELECT id, order_id, contract_id, error_text, success_flag, reprocess_yn, conc_request_id FROM oks_reprocessing_v WHERE conc_request_id = :request_id;
• SELECT conc_request_id, COUNT(*) FROM oks_reprocessing_v WHERE success_flag = 'N' GROUP BY conc_request_id ORDER BY 2 DESC;
• SELECT id, contract_id, contract_line_id, error_text FROM oks_reprocessing_v WHERE reprocess_yn = 'Y' AND success_flag = 'N';

These queries are commonly executed from SQL*Plus, Oracle Forms customizations, or BI Publisher reports, and the CONC_REQUEST_ID column is the standard join key back to FND_CONCURRENT_REQUESTS for diagnostic tracing.