Search Results fnd_notifications




Overview
Explore in AI Chat

Overview

FND_NOTIFICATIONS is a table owned by the PO (Purchasing) schema in Oracle E-Business Suite. Its ETRM documentation status is VALID, and its documented physical schema in release 12.2.2 contains 59 columns. The critical fact that governs any technical discussion of this object is that the documented description states the table is obsolete in release 11. It therefore carries no functional role in Oracle EBS 12.1.1 or 12.2.2; it persists as a legacy structure retained for backward compatibility and occupies space without participating in application processing. The table retains its primary key constraint and index definitions from earlier releases, and its columns remain physically present, but no supported Oracle EBS functionality reads from or writes to it in 12.1.1 or 12.2.2.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is standalone. This is a modeling suggestion rather than a documented property: although the table carries a foreign key to PSB_EMPLOYEES on EMPLOYEE_ID, that reference is residual and does not establish a meaningful link relationship in current releases. A standalone classification is appropriate because the table does not function as a hub, link, or satellite within any active integration model.

Key Information Stored

Among the 59 documented columns, the following are the most significant, and all are retained in an obsolete state:

The 32 ATTRIBUTE columns and the DATE1 through DATE4 columns are derived from the Oracle Applications flexfield convention. Because the table is obsolete, they should be treated as unmapped legacy placeholders rather than functional descriptive fields.

Common Use Cases and Queries

There are no functional use cases. The table should not be referenced in new customizations, reports, or integrations. The practical scenarios are confined to validation and remediation:

  • Object validation and dependency review against the ETRM dictionary, confirming owner PO, VALID status, and the 59-column structure in 12.2.2.
  • Determining whether any custom code still references the object prior to cleanup, for example SELECT COUNT(*) FROM po.fnd_notifications to establish data volume.
  • Detecting residual references in the data dictionary: SELECT * FROM dba_dependencies WHERE referenced_name = 'FND_NOTIFICATIONS'.
  • Confirming the primary key definition: SELECT constraint_name, constraint_type FROM dba_constraints WHERE table_name = 'FND_NOTIFICATIONS' AND owner = 'PO'.

Any historical reporting that once targeted this table should be redirected to whatever replacement mechanism the customer implemented during the release 11 upgrade, since the documented metadata provides no successor object.

Related Objects

The documented relationship data is deliberately narrow. The following are the significant associated objects:

  • PSB_EMPLOYEES — referenced via FND_NOTIFICATIONS.EMPLOYEE_ID; the only documented foreign key target.
  • FND_NOTIFICATIONS_PK — the unique index on NOTIFICATION_ID, the sole documented business-key candidate.
  • SYS_C0013522 — the system-named primary key constraint on NOTIFICATION_ID referenced in the original search.
  • FND_* notification infrastructure — in older releases this table was conceptually related to the application notification framework; in 12.1.1 and 12.2.2 that role belongs to the Oracle Workflow notification schema rather than to PO.FND_NOTIFICATIONS.

Because the Data Vault classification is standalone and the table is obsolete, no additional dependent views, APIs, or link tables should be expected from the documented metadata.