Search Results fa_conventions_u1

Overview

FA.FA_CONVENTIONS is a reference and configuration table in the Oracle E-Business Suite Fixed Assets module (FA schema), shipped as part of the OFA product design data. It defines prorate conventions, the rules that determine how depreciation expense is calculated in the period an asset is added, adjusted, or retired relative to the period the transaction is placed in service. In Oracle EBS 12.1.1 and 12.2.2, this table underpins depreciation forecasting, asset additions, transfers, and retirements, ensuring period-based proration is applied consistently across the asset book.

Each row represents a specific prorate convention code valid over a defined date range. Because conventions can change over time, the table maintains effective-dated records rather than a single immutable definition. From a Data Vault modeling perspective, the metadata suggests this object leans toward a satellite classification. The natural business key is the prorate convention code combined with effective dates, meaning the table stores descriptive, time-variant attributes rather than acting as a pure hub or a link between two independent entities.

Key Information Stored

The table contains nine documented columns. The most significant are the proration definition and its effective dating.

• PRORATE_CONVENTION_CODE (VARCHAR2, 10) — the identifier for the prorate convention. It is a foreign key to FA_CONVENTION_TYPES and part of the composite primary key.
• START_DATE (DATE) — the date from which the convention definition becomes effective; part of the primary key.
• END_DATE (DATE) — the date through which the convention remains effective; included in unique index FA_CONVENTIONS_U1.
• PRORATE_DATE (DATE) — the referenced prorate date used to drive depreciation proration logic.
• CREATED_BY, CREATION_DATE — standard audit columns recording who created the row and when.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns capturing the most recent modification.

The surrogate primary key is FA_CONVENTIONS_PK (PRORATE_CONVENTION_CODE, START_DATE). The unique index FA_CONVENTIONS_U1 (PRORATE_CONVENTION_CODE, START_DATE, END_DATE) represents the business-key candidate, enforcing that no overlapping effective-dated records with an identical convention code and date range can exist. This effective-dated uniqueness pattern is the core integrity constraint governing the table.

Common Use Cases and Queries

Typical use cases center on resolving the active prorate convention for a given transaction date, validating convention setup, and auditing effective-dated changes. A query to retrieve all definitions for a convention sorted by effective date follows:

• SELECT PRORATE_CONVENTION_CODE, START_DATE, END_DATE, PRORATE_DATE FROM FA.FA_CONVENTIONS WHERE PRORATE_CONVENTION_CODE = :code ORDER BY START_DATE;
• Resolving the convention effective on a specific date: filter where :txn_date BETWEEN START_DATE AND END_DATE.
• Detecting effective-date gaps or overlaps by ordering records per code and comparing END_DATE to the next START_DATE.

Reporting scenarios include listing all conventions valid in the current period, reconciling PRORATE_DATE values against asset addition transactions, and auditing who changed a convention definition using the audit columns. Because the table is small and configuration-oriented, it is frequently joined to FA_CONVENTION_TYPES to present descriptive names alongside codes.

Related Objects

The documented relationship data identifies the following dependencies:

• FA_CONVENTION_TYPES — referenced by FA_CONVENTIONS.PRORATE_CONVENTION_CODE; supplies the convention type classification and joins on PRORATE_CONVENTION_CODE.
• APPS.FA_CONVENTIONS — the APPS-schema synonym or view through which the table is exposed, referenced by dependent objects.
• The FA_CONVENTIONS_PK primary key and FA_CONVENTIONS_U1 unique index — constraints the user searched for, enforcing uniqueness on PRORATE_CONVENTION_CODE, START_DATE, and END_DATE.

Downstream Fixed Assets processes — asset additions, depreciation forecasting, and book setup — rely on these definitions at transaction time. Any modification to effective dates should be performed with awareness of the U1 uniqueness constraint to avoid overlaps that would corrupt proration behavior.