Search Results date_confirmed

Overview

The view CSP_PICKLIST_HEADERS_V is an APPS-owned, valid database object within the Oracle E-Business Suite Spares Management (CSP) module. As described in the ETRM documentation, it presents picklist header information, providing a denormalized, read-optimized projection of the base CSP_PICKLIST_HEADERS table enriched with a decoded status description. The view is defined as a join between CSP_PICKLIST_HEADERS and the FND_LOOKUPS view, resolving the PICKLIST_STATUS lookup code into a user-readable meaning through the CSP_PICKLIST_STATUS lookup type.

Because picklists represent the physical picking and staging of spare parts against field service and depot repair activity, this view serves as a convenient reporting and integration surface. Report developers and interface builders can query the view directly to obtain picklist header attributes without having to re-implement the lookup decode logic. The presence of the ROWID column and the standard WHO audit columns indicates that the view remains identifiable at the row level, supporting the Oracle Forms and OAF frameworks that rely on such constructs for maintaining entity integrity.

In EBS 12.1.1 and 12.2.2, the view behaves identically; 12.2.2 online patching does not alter its definition because it references only APPS synonyms and standard lookup infrastructure. The DATE_CONFIRMED column is of particular interest to users searching on that term, since it is one of the few columns that records a meaningful operational timestamp distinct from the audit CREATION_DATE.

Underlying Base Objects

The ETRM metadata documents three referenced objects behind this view:

• CSP_PICKLIST_HEADERS — exposed as a synonym in the APPS schema; this is the primary base table holding the picklist header transaction data.
• FND_LOOKUPS — a view over the application lookup tables, used here to supply the decoded status meaning.
• FND_GLOBAL — the standard EBS package supplying session context such as ORG_ID, which participates in multi-org security for the underlying table.

The view text shows an outer join (FL.LOOKUP_CODE(+)) constrained to LOOKUP_TYPE = 'CSP_PICKLIST_STATUS', ensuring that a picklist row is returned even when no matching lookup code exists, in which case the meaning is null. This design keeps the view resilient to incomplete lookup configuration.

Key Columns

The view exposes the full set of header columns plus the derived status name. Notable columns include:

• PICKLIST_HEADER_ID — primary identifier of the picklist header, used to join to lines and detail tables.
• PICKLIST_NUMBER — the user-facing picklist document number.
• PICKLIST_STATUS — the coded status value stored on the base table.
• PICKLIST_STATUS_NAME — the decoded description obtained from FND_LOOKUPS.
• DATE_CREATED — the business date on which the picklist was created.
• DATE_CONFIRMED — the timestamp recording when the picklist was confirmed; this is the column most frequently targeted by users searching for picklist confirmation history.
• ORGANIZATION_ID — the inventory organization context, relevant to multi-org filtering.
• WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the fifteen ATTRIBUTE flex columns, plus ATTRIBUTE_CATEGORY, supporting descriptive flexfield data.
• ROW_ID — the underlying row identifier supporting updateable frameworks.

Common Use Cases and Queries

Typical scenarios include reporting on picklist confirmation trends, building supplier or depot dashboards, and driving downstream interfaces. A representative query retrieving confirmed picklists for an organization is:

• SELECT picklist_number, picklist_status_name, date_confirmed FROM csp_picklist_headers_v WHERE organization_id = :org_id AND date_confirmed IS NOT NULL ORDER BY date_confirmed DESC;

To analyze throughput, developers aggregate on DATE_CONFIRMED and DATE_CREATED, comparing the elapsed time between creation and confirmation. To join to detail or line information, the PICKLIST_HEADER_ID is used as the foreign key. Because status meaning is resolved inline, status-based filtering can be applied directly against PICKLIST_STATUS_NAME for human-readable reporting, or against the coded PICKLIST_STATUS for programmatic logic.