Results for “pa_agreement_types_pk”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PA_AGREEMENT_TYPES is a Projects (PA) module setup table that stores implementation-defined classifications of customer agreements in Oracle E-Business Suite 12.1.1 and 12.2.2. Each row defines an agreement type that users can assign when creating or maintaining customer agreements, enabling organizations to categorize contracts by commercial treatment — for example, time and materials, fixed price, or cost-plus arrangements. Because rows are created by the customer rather than seeded by Oracle, the table functions as a controlled reference list that enforces consistent agreement categorization across the enterprise.

From a data-modeling perspective, the documented foreign-key topology suggests a satellite-leaning classification: the table carries a unique business key (AGREEMENT_TYPE) plus descriptive and effective-dating attributes, and it is referenced by a transactional parent, PA_AGREEMENTS_ALL, rather than participating in a many-to-many link. The single outbound foreign key to RA_TERMS_B positions the table as a dependent reference entity rather than an independent hub.

Key Information Stored

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

• AGREEMENT_TYPE — the primary key and business-key column, defined by the PA_AGREEMENT_TYPES_PK constraint and the unique index PA_AGREEMENT_TYPES_U1. It holds the short identifier used throughout the application and in PA_AGREEMENTS_ALL.
• DESCRIPTION — the user-facing name or explanation of the agreement classification.
• TERM_ID — foreign key to RA_TERMS_B, associating a default payment term with the agreement type.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective-dating window controlling when the type is selectable.
• REVENUE_LIMIT_FLAG — a configuration flag governing revenue-limit behavior for agreements of this type.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF/descriptive flexfield segment, allowing implementations to capture additional attributes without schema changes.

Note that there is no separate surrogate sequence-generated key; AGREEMENT_TYPE serves simultaneously as primary key and business key, which is typical of low-volume setup tables.

Common Use Cases and Queries

Typical scenarios include validating that agreements reference active types, joining agreement transactions to their classification for reporting, and extracting setup data during migrations or audits.

• List active agreement types: SELECT agreement_type, description FROM pa_agreement_types WHERE SYSDATE BETWEEN start_date_active AND NVL(end_date_active, SYSDATE + 1);
• Count agreements by classification:

  SELECT a.agreement_type, t.description, COUNT(*)
  FROM pa_agreements_all a, pa_agreement_types t
  WHERE a.agreement_type = t.agreement_type
  GROUP BY a.agreement_type, t.description;

• Identify agreement types with associated payment terms: SELECT t.agreement_type, r.name FROM pa_agreement_types t, ra_terms_b r WHERE t.term_id = r.term_id;
• Detect orphaned or inactive classifications used by live agreements during data cleanup and period-close validation.

Related Objects

• PA_AGREEMENTS_ALL — the principal dependent table; its AGREEMENT_TYPE column references this table, making it the direct transactional consumer.
• RA_TERMS_B — referenced through TERM_ID to supply default payment terms for each agreement type.
• PA_AGREEMENT_TYPES_PK — the primary key constraint on AGREEMENT_TYPE.
• PA_AGREEMENT_TYPES_U1 — unique index reinforcing AGREEMENT_TYPE as the business-key candidate.
• Projects APIs and agreement validation logic that read this table to restrict the list of valid values presented to users.

Together these objects form the setup-to-transaction relationship that governs how customer agreements are classified, defaulted, and reported throughout the Projects module.