Search Results pn_opex_notes_n1

Overview

PN.PN_OPEX_NOTES_ALL is a transactional table in the Oracle E-Business Suite Procurement and Operations (PN) schema that stores free-form annotation records attached to Operational Expense (Opex) agreements and their associated reconciliations. It is the persistence layer behind the "Notes" region that appears on the various sub-tabs of an Opex Agreement in Oracle Property Manager / ETRM. Each row represents a single note, including its header, body text, a classification code, and audit information describing the user and timestamp of the last change.

The table is owned by the PN schema and resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10, while its indexes are stored separately in APPS_TS_TX_IDX. In Oracle EBS 12.1.1 and 12.2.2 the object is registered under the FND Design Data application as PN.PN_OPEX_NOTES_ALL and reports a VALID status. Because the table is a child of the agreement and reconciliation entities it carries descriptive flexfield columns (ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15, plus ORG_ID) that allow customer-specific extensions.

Under the heuristic Data Vault classification derived from the foreign key structure, this object is modeled as a hub: it has a single-column primary key (NOTE_ID) and no downstream dependents, so it functions as a standalone identity node. Analysts who prefer a normalized approach may instead treat it as a satellite of the agreement and reconciliation hubs, since the note text is descriptive and time-versioned by the WHO columns. Either interpretation is reasonable; the metadata itself does not commit to one.

Key Information Stored

The following columns carry the substantive business meaning of the table:

• NOTE_ID — the surrogate primary key (PN_OPEX_NOTES_PK) and the column behind the unique index PN_OPEX_NOTES_U1. It is the only documented business-key candidate; no other unique index exists.
• AGREEMENT_ID — the numeric identifier of the Opex agreement that owns the note. Indexed non-uniquely through PN_OPEX_NOTES_N1 and the primary access path for agreement-centric queries.
• NOTETYPE — a code classifying the note (for example, by sub-tab or business purpose). Indexed non-uniquely through PN_OPEX_NOTES_N2.
• NOTE_HEADER and NOTE_TEXT — the readable content, held in VARCHAR2(1000) and VARCHAR2(4000) respectively.
• RECON_ID and RECON_NAME — the reconciliation identifier and its unique display name, linking the note to a specific reconciliation record. RECON_ID carries a foreign key to PN_OPEX_RECON_ALL.
• PRINT_FLAG — controls whether the note is eligible for printing on agreement output.
• NOTESUSER — the login name of the user who created or last updated the note, distinct from the standard WHO columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — descriptive flexfield segments for client-specific data capture.
• ORG_ID — the operating unit identifier enabling Multi-Org security on the row.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard audit columns maintained by the EBS WHO framework.

Common Use Cases and Queries

Typical reporting requirements include extracting all notes for a given agreement, listing reconciliation-linked notes, and auditing note creation by user. The following patterns are representative:

• Notes for one agreement, ordered by creation: SELECT note_id, notetype, note_header, note_text FROM pn_opex_notes_all WHERE agreement_id = :agreement_id ORDER BY creation_date;
• Reconciliation notes joined to their parent reconciliation: SELECT n.note_text, r.* FROM pn_opex_notes_all n, pn_opex_recon_all r WHERE n.recon_id = r.recon_id;
• Printable notes only: filter on print_flag = 'Y'.
• User activity audit: group by notesuser or last_updated_by over a date range using last_update_date.

Because the table is Multiorg enabled, queries executed through the standard EBS views (or with an ORG_ID predicate) will respect operating-unit security. Reports that bypass the ORG_ID column will return notes across all operating units and should be restricted accordingly.

Related Objects

The most significant relationships are:

• PN.PN_OPEX_RECON_ALL — referenced by the RECON_ID foreign key; the authoritative source of reconciliation header data and RECON_NAME.
• PN.PN_OPEX_NOTES — the underlying table object named in the PN_OPEX_NOTES_U1 index; _ALL is the Multi-Org variant used at runtime.
• PN_OPEX_NOTES_PK / PN_OPEX_NOTES_U1 — primary key constraint and unique index on NOTE_ID.
• PN_OPEX_NOTES_N1 and PN_OPEX_NOTES_N2 — non-unique indexes supporting queries by AGREEMENT_ID and NOTETYPE.
• Opex Agreement tables in the PN schema that own AGREEMENT_ID, used to join notes back to their agreement header.
• FND descriptive flexfield definitions that populate ATTRIBUTE_CATEGORY and the ATTRIBUTE1–15 segments for this table.