Search Results po_notes




Overview
Explore in AI Chat

Overview

The PO_NOTES table resides in the PO (Purchasing) schema of Oracle E-Business Suite and is documented in ETRM as "No longer used" and "Not implemented in this database" for the 12.1.1 / 12.2.2 releases. Despite this designation, the table remains fully defined in the physical data model with 34 documented columns and a primary key constraint, PO_NOTES_PK, on the PO_NOTE_ID column. Its structure indicates it was originally intended as a central repository for reusable note text referenced by purchasing documents, including requisitions, purchase orders, and note cross-reference records. Because it is marked as not implemented, the table typically exists in the schema for backward compatibility and structural completeness rather than active transactional use.

Under the heuristic Data Vault classification derived from its foreign key topology, PO_NOTES is characterized as hub-leaning. In Data Vault terms, a hub represents a table that owns a unique business key and is referenced by other tables. The single inbound reference from PO_USAGES via USAGE_ID and the eleven outbound references from dependent tables are consistent with a hub-and-satellite pattern, where PO_NOTES serves as the central identity anchor and its descriptive columns function as satellite attributes. This classification is a modeling suggestion, not an Oracle-imposed constraint.

Key Information Stored

The surrogate primary key is PO_NOTE_ID, enforced by both PO_NOTES_PK and the unique index PO_NOTES_U1. Although this column is the sole documented unique index, in practice it functions as a system-generated identifier rather than a business key. The most significant descriptive columns are:

Common Use Cases and Queries

Because the table is not implemented, it is rarely the target of transactional SQL in a live 12.1.1 or 12.2.2 instance. Typical usage is investigative: confirming whether stale rows survive from an earlier upgrade, assessing impact before a schema cleanup, or tracing legacy note identifiers carried on purchasing interface records. A representative query looks up a note by its surrogate identifier:

  • SELECT po_note_id, title, note_type, document_id, note FROM po.po_notes WHERE po_note_id = :id;
  • SELECT n.po_note_id, n.title, u.* FROM po.po_notes n JOIN po.po_usages u ON n.usage_id = u.usage_id;
  • SELECT * FROM po.po_note_references r WHERE r.po_note_id = :id;

Reporting use cases include auditing orphaned note references, reconciling requisition interface staging rows that carry NOTE1_ID through NOTE10_ID values, and documenting data lineage prior to archiving obsolete purchasing tables.

Related Objects

The most significant dependent objects are identified through the documented foreign key relationships:

  • PO_USAGES — referenced by PO_NOTES.USAGE_ID; defines note usage semantics.
  • PO_NOTE_REFERENCES — references PO_NOTES.PO_NOTE_ID, linking notes to specific purchasing entities.
  • PO_REQUISITIONS_INTERFACE_ALL — carries ten foreign keys (NOTE1_ID through NOTE10_ID) pointing at PO_NOTES.PO_NOTE_ID, so interface staging rows can resolve up to ten note identifiers.

Given the "not implemented" status, developers should treat PO_NOTES as a dormant structural artifact and prefer currently supported purchasing note mechanisms when building new integrations or reports.