Search Results ap_aging_period_lines_pk

Overview

AP_AGING_PERIOD_LINES is a Payables (AP) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores individual aging period information used by the Payables Aging reports and related aging analysis functionality. Each row defines a single aging bucket — a discrete interval of days — that belongs to a governing aging period definition. The table is owned by the AP schema and is documented as VALID in the ETRM repository, with a physical schema of 32 columns and a single unique index (AP_AGING_PERIOD_LINES_U1) on the AGING_PERIOD_LINE_ID column.

From a dimensional modeling perspective, the mined foreign-key structure suggests a satellite-leaning classification. The table carries a single foreign key, AGING_PERIOD_ID, pointing to AP_AGING_PERIODS, and its columns describe the descriptive attributes of a parent aging period entity. This suggests it may be modeled as a satellite table attached to an AP_AGING_PERIODS hub or parent, rather than as an independent hub or a link table. Practitioners building reporting extracts against Payables should treat AP_AGING_PERIOD_LINES as a child detail table whose grain is one aging bucket per row.

Key Information Stored

The surrogate primary key is AGING_PERIOD_LINE_ID, defined by the AP_AGING_PERIOD_LINES_PK constraint and reinforced by the unique index AP_AGING_PERIOD_LINES_U1. The sole documented foreign key, AGING_PERIOD_ID, links each line back to its parent aging period in AP_AGING_PERIODS.

The most operationally significant columns define the aging interval itself:

• PERIOD_SEQUENCE_NUM — orders the bucket within its aging period definition.
• DAYS_START and DAYS_TO — the lower and upper day boundaries that determine how an invoice falls into the bucket.
• TYPE and BASE_DATE — classify the bucket and establish the reference date from which days are counted.
• REPORT_HEADING1, REPORT_HEADING2, REPORT_HEADING3 — user-defined column headings rendered on aging output.
• NEW_LINE — controls page or row breaks in aged reporting layouts.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield (DFF) segment columns for customer-defined extensions.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — mandatory audit trail columns maintained automatically by EBS.

Common Use Cases and Queries

The primary use case is configuration validation and aging report analysis. Because aging buckets are normally created and maintained through the Payables aging period setup UI, direct SQL is most often used for auditing, migration, and reporting. A typical query retrieves the ordered buckets for a given aging period:

• SELECT AGING_PERIOD_LINE_ID, PERIOD_SEQUENCE_NUM, DAYS_START, DAYS_TO, TYPE, REPORT_HEADING1 FROM AP_AGING_PERIOD_LINES WHERE AGING_PERIOD_ID = :p_aging_period_id ORDER BY PERIOD_SEQUENCE_NUM;
• Joining to AP_AGING_PERIODS to resolve the period name: SELECT a.NAME, l.DAYS_START, l.DAYS_TO, l.REPORT_HEADING1 FROM AP_AGING_PERIOD_LINES l, AP_AGING_PERIODS a WHERE l.AGING_PERIOD_ID = a.AGING_PERIOD_ID ORDER BY a.NAME, l.PERIOD_SEQUENCE_NUM;
• Detecting overlapping or gapped bucket definitions for data-quality assurance: comparing DAYS_TO of one sequenced line with DAYS_START of the next.
• Extracting the DFF attributes (ATTRIBUTE1–ATTRIBUTE15) for downstream analytics or legacy-system migration mapping.

These queries are commonly embedded in custom aging reports that reproduce or extend the standard Payables Aging reports.

Related Objects

The most significant related object is the parent table AP_AGING_PERIODS, joined by AP_AGING_PERIOD_LINES.AGING_PERIOD_ID. This parent-child relationship is the only documented foreign-key dependency and defines the core join path for all reporting. The unique index AP_AGING_PERIOD_LINES_U1 supports the primary-key lookup path. Downstream, the configured buckets drive the standard Payables Aging reports and any custom aging extracts that consume the AP_AGING_PERIODS and AP_AGING_PERIOD_LINES configuration pair. Because the metadata documents only these relationships, practitioners should confirm any additional dependencies against the applicable ETRM release before relying on undocumented joins.