Search Results fnd_conc_pp_templates_pk

Overview

FND_CONC_PP_TEMPLATES is a base table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. It stores post-processing templates used by the concurrent processor. In Oracle EBS, concurrent programs generate output files and log files; post-processing templates define the named configurations that control how that output is handled after a concurrent request completes — for example, whether notification is raised to the submitting user when a post-processing error occurs. The table therefore acts as a small reference or setup repository for the Concurrent Managers' post-processing framework rather than as a transactional fact store.

Under the heuristic Data Vault classification mined from its foreign key structure, this object is best modeled as a link table. Its foreign keys to FND_USER and FND_LOGINS capture audit and session context (who created, who last updated, and which login last touched the row), which is the characteristic pattern of a link-style object connecting operational entities to identity/audit references. It is not itself a hub (its surrogate key is a locally-managed template identifier, not a shared business key), nor does it carry the wide, descriptive, time-varying payload typical of a satellite.

Key Information Stored

The documented physical schema contains eight columns in the 12.2.2 ETRM listing. The most significant are:

• TEMPLATE_ID — the surrogate primary key, defined by the constraint FND_CONC_PP_TEMPLATES_PK. This is the internal, system-generated identifier and should be used for joins.
• TEMPLATE_NAME — the business-key candidate, enforced by the unique constraint FND_CONC_PP_TEMPLATES_UK1. This is the human-readable name used to reference a post-processing template in concurrent program definitions and admin setup.
• NOTIFY_ON_PP_ERROR — a control flag indicating whether a notification should be sent when a post-processing error is encountered. This is the functional attribute that gives the template its behavior.
• CREATED_BY — FK to FND_USER; identifies the user who created the template row.
• LAST_UPDATED_BY — FK to FND_USER; identifies the user who most recently modified the row.
• LAST_UPDATE_LOGIN — FK to FND_LOGINS; records the login session associated with the most recent update.
• CREATION_DATE and LAST_UPDATE_DATE — standard WHO audit timestamp columns recording row creation and last modification times.

The surrogate key (TEMPLATE_ID) and the unique business key (TEMPLATE_NAME) are cleanly separated, which is typical of FND setup tables and supports stable references even if a template is renamed.

Common Use Cases and Queries

Typical uses center on reviewing or validating post-processing template configuration and on auditing who changed it. A representative query listing templates and their error-notification behavior:

• SELECT template_id, template_name, notify_on_pp_error FROM fnd_conc_pp_templates ORDER BY template_name;
• Relating templates to the creating/updating user: SELECT t.template_name, u.user_name, t.last_update_date FROM fnd_conc_pp_templates t, fnd_user u WHERE t.last_updated_by = u.user_id;
• Audit lookups joining LAST_UPDATE_LOGIN to FND_LOGINS to trace the session responsible for a change.
• Reporting on which templates will generate notifications on failure, useful when troubleshooting missing concurrent-processor error alerts.

Because the table is a small setup object, it is normally queried directly rather than through a public view, and changes are usually made through the Concurrent Managers / post-processing administration forms rather than by direct DML.

Related Objects

The FK metadata documents the following direct relationships, which are the primary objects to join against:

• FND_USER — referenced twice, via CREATED_BY and LAST_UPDATED_BY, providing the user audit context.
• FND_LOGINS — referenced via LAST_UPDATE_LOGIN, supplying session-level audit detail.
• FND_CONC_PP_TEMPLATES_PK / FND_CONC_PP_TEMPLATES_UK1 — the primary and unique constraints that define TEMPLATE_ID and TEMPLATE_NAME as the access paths of record.

Functionally, the template names defined here are consumed by the concurrent processing framework, so related configuration and runtime objects — concurrent program definitions, the concurrent manager request tables (FND_CONCURRENT_REQUESTS and its post-processing/log tables), and the standard FND WHO audit columns shared across FND tables — are the most relevant surrounding objects when analyzing how a template influences request post-processing behavior.