Search Results ap_other_periods




Overview
Explore in AI Chat

Overview

AP_OTHER_PERIODS is a Payables (AP) module reference table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores time-period definitions used by several distinct Payables features. Unlike the General Ledger accounting calendar, which defines the fiscal periods used for journal posting, AP_OTHER_PERIODS holds auxiliary period calendars that drive recurring invoice generation, key indicator (KPI) reporting periods, payment term schedules, and withholding tax period logic. Each row defines one named period belonging to a specific module or functional area, within an application context.

From a Data Vault modeling perspective, the documented foreign-key structure — with only a single outbound reference to FND_APPLICATION — suggests a satellite-leaning classification. The table primarily carries descriptive, time-bounded attributes (start date, end date, period year, period number, status) rather than acting as a hub of business entities or a link between entities. It is best understood as a configuration or reference dimension whose grain is (application, module, period type, period name).

Key Information Stored

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

  • APPLICATION_ID — Identifies the owning application (foreign key to FND_APPLICATION).
  • MODULE — Distinguishes which Payables feature consumes the period definition (e.g., recurring invoices, payment terms, withholding tax, key indicators).
  • PERIOD_TYPE — Further qualifies the period category within a module.
  • PERIOD_NAME — The user-visible period identifier.
  • PERIOD_YEAR and PERIOD_NUM — Numeric ordering attributes enabling sequencing and range filtering.
  • START_DATE and END_DATE — Bound the period’s effective range.
  • DUE_DATE — Supports payment-term due-date derivation.
  • ENTERED_PERIOD_NAME — The period in which the definition was entered.
  • STATUS — Active/inactive flag controlling availability.
  • DESCRIPTION — Free-text purpose description.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15, plus CONTEXT — The standard EBS descriptive flexfield (DFF) columns.

The surrogate primary key is AP_OTHER_PERIODS_PK, defined on (APPLICATION_ID, PERIOD_NAME, PERIOD_TYPE, MODULE). Two documented unique indexes act as business-key candidates: AP_OTHER_PERIODS_U1 (APPLICATION_ID, PERIOD_TYPE, PERIOD_NAME, MODULE) and AP_OTHER_PERIODS_U2 (APPLICATION_ID, MODULE, PERIOD_TYPE, PERIOD_YEAR, PERIOD_NUM). Both enforce that period definitions remain unique within their application and module context.

Common Use Cases and Queries

Typical uses include validating that a Payables period exists for a module before generating recurring invoices, populating period list-of-values, and joining to transaction tables that reference period names. A representative query to list active recurring-invoice periods is:

  • SELECT period_name, start_date, end_date, status FROM ap_other_periods WHERE application_id = 200 AND module = :module AND period_type = :type AND status = 'A' ORDER BY period_year, period_num;
  • Reporting joins against FND_APPLICATION to resolve the application name: SELECT a.period_name, f.application_name FROM ap_other_periods a, fnd_application f WHERE a.application_id = f.application_id;
  • Range filtering by START_DATE and END_DATE to determine which period covers a given transaction date.

Related Objects

The only documented foreign key is to FND_APPLICATION via APPLICATION_ID, making that the primary upstream dependency. Functionally, AP_OTHER_PERIODS is referenced by Payables features whose period-driven configuration depends on these definitions, including recurring invoice and payment-term scheduling logic and withholding tax period processing within the AP module. Reporting and integration layers typically join AP_OTHER_PERIODS to AP_INVOICES_ALL and AP_PAYMENT_SCHEDULES_ALL when recurring or term-based periods must be reconciled against posted transactions, and to FND_APPLICATION for application-name resolution. Because the table is narrow reference data, extraction into a staging or dimensional model is common for period-conformance checks in reconciliations.