Search Results po_note_attributes_pk

Overview

PO_NOTE_ATTRIBUTES is a Purchasing (PO) module reference table in the Oracle E-Business Suite 12.1.1 and 12.2.2 releases. It is owned by the PO schema and holds the master list of note attributes — the discrete, code-level categories that classify or tag the various notes and usage attributes associated with purchasing documents such as purchase orders, requisitions, quotations, and their associated business flows. Rather than storing transactional note text itself, PO_NOTE_ATTRIBUTES functions as a lookup and control table that defines the valid set of attribute values that downstream transactional tables can reference.

Under a heuristic Data Vault classification mined from its foreign-key structure, PO_NOTE_ATTRIBUTES is hub-leaning. It is the referenced (parent) side of a relationship, with dependent tables holding the descriptive or usage-specific detail. This suggests modeling it as a hub, where the business key NOTE_ATTRIBUTE is the natural identifier and the remaining descriptive columns (description, audit columns) behave in a satellite-like manner.

Key Information Stored

The table contains eleven documented columns. The most significant are:

• NOTE_ATTRIBUTE — the primary key and business identifier, defined by the constraint PO_NOTE_ATTRIBUTES_PK. It uniquely identifies each note attribute category.
• DESCRIPTION — the human-readable label describing the note attribute, used for display in forms, reports, and lookup windows.
• CREATED_BY, CREATION_DATE — standard who-columns capturing the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns tracking the most recent modification, its user, and the login session.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Oracle concurrent program context columns, identifying the concurrent request and program responsible for the last data change.

NOTE_ATTRIBUTE serves as both the surrogate primary key and the business-key candidate, since the primary key constraint is defined directly on this column with no distinct separately-documented unique index. The audit and concurrent program columns follow Oracle Applications' standard WHO and "Who/When" conventions and are populated automatically and should not be treated as user-maintained business data.

Common Use Cases and Queries

Typical uses include resolving note attribute codes to descriptions in reports, validating values presented in Purchasing setup forms, and joining to dependent tables for note-related reporting. Two representative query patterns follow.

Resolving codes to descriptions:

• SELECT note_attribute, description FROM po.po_note_attributes ORDER BY note_attribute;

Joining to dependent usage data:

• SELECT pna.note_attribute, pna.description, pua.* FROM po.po_note_attributes pna, po.po_usage_attributes pua WHERE pna.note_attribute = pua.note_attribute;

Reporting scenarios include listing the available note attribute categories for configuration reviews, auditing which attributes are actually in use via the dependent table, and driving LOV (list of values) queries in custom OAF or Forms extensions.

Related Objects

The most significant dependent object documented is:

• PO_USAGE_ATTRIBUTES — references PO_NOTE_ATTRIBUTES through the foreign-key column PO_USAGE_ATTRIBUTES.NOTE_ATTRIBUTE, making it the primary child and consumer of this table's business key.

Because the documented metadata identifies PO_USAGE_ATTRIBUTES as the sole foreign-key dependent, other interaction is primarily through the standard PO schema. The note attribute values feed the Purchasing document setup and note-definition flows exposed through the Purchasing setup and document entry forms. Any extension or integration consuming note attributes should join through NOTE_ATTRIBUTE to preserve referential integrity with PO_USAGE_ATTRIBUTES.