Search Results ar_charge_schedules




Overview
Explore in AI Chat

Overview

AR_CHARGE_SCHEDULES is a Receivables (AR) module table owned by the AR schema that stores user-defined charge schedule definitions. Charge schedules in Oracle EBS describe recurring charge arrangements — for example, freight, handling, or service fees applied over a defined period or in defined increments — and are referenced when generating invoices, debit memos, and other Receivables transactions that carry scheduled charges. The table functions as a configuration/reference object rather than a transactional posting table: it holds the header-level definition of a schedule (its name, description, and descriptive flexfield attributes), while the individual scheduled lines are stored in separate detail tables that reference the schedule by SCHEDULE_ID.

With respect to data vault modeling, the supplied metadata classifies AR_CHARGE_SCHEDULES as standalone (a heuristic derived from the absence of inbound or outbound foreign keys in the mined FK structure). As a modeling suggestion, this supports treating it as a hub-like reference entity: the stable business key SCHEDULE_ID (and secondarily SCHEDULE_NAME) identifies each schedule, and the descriptive columns form satellite-style attributes. The table participates in few, if any, referential relationships within the documented metadata, which is consistent with a lookup/definition table consumed by application logic and validated via unique constraints rather than enforced foreign keys.

Key Information Stored

The table is documented with 25 columns in the Oracle EBS 12.2.2 physical schema. The most significant columns are:

  • SCHEDULE_ID — The surrogate primary key, enforced by AR_CHARGE_SCHEDULES_PK and also by the unique index AR_CHARGE_SCHEDULES_U1. This is the value referenced by any dependent charge-schedule detail or transaction-usage records.
  • SCHEDULE_NAME — The business-key candidate, enforced by the unique index AR_CHARGE_SCHEDULES_U2. It is the user-visible identifier by which a charge schedule is selected and reported.
  • SCHEDULE_DESCRIPTION — Free-text descriptive information used to explain the purpose or content of the schedule.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — The descriptive flexfield (DFF) context and segment columns. These hold customer-specific, client-extensible information captured through the Receivables descriptive flexfield on the charge schedule.
  • OBJECT_VERSION_NUMBER — The optimistic locking/versioning column used by the Oracle Application Framework and forms to detect concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard Oracle EBS who-columns recording audit and stewardship information for each row.

The distinction between SCHEDULE_ID and SCHEDULE_NAME is important: SCHEDULE_ID is the immutable surrogate key that should always be used in joins, while SCHEDULE_NAME is the unique business key that users recognize. DFF attributes are optional and are only meaningful when ATTRIBUTE_CATEGORY is populated.

Common Use Cases and Queries

Typical uses include retrieving the identifier for a named schedule, producing a reference listing of all schedules for configuration review, and exposing DFF attribute values in custom reports. Because the table is standalone, most queries are simple lookups. For example, to resolve a schedule name to its key:

  • SELECT schedule_id, schedule_name, schedule_description FROM ar_charge_schedules WHERE schedule_name = :p_name;
  • SELECT schedule_id, schedule_name, attribute_category, attribute1 FROM ar_charge_schedules WHERE attribute_category IS NOT NULL ORDER BY schedule_name;
  • SELECT COUNT(*) FROM ar_charge_schedules WHERE last_update_date >= :since; — used for incremental extract or audit review.

Reporting scenarios commonly join this table to charge-schedule detail and transaction tables on SCHEDULE_ID to display the human-readable SCHEDULE_NAME alongside transactional data, or to validate that an active schedule definition exists before generating charges. Extracts for data migration or system-to-system interfaces typically select SCHEDULE_ID, SCHEDULE_NAME, SCHEDULE_DESCRIPTION, the DFF attributes, and the audit columns.

Related Objects

Based on the documented relationship data, AR_CHARGE_SCHEDULES is standalone — the mined FK structure shows no foreign-key dependencies in either direction — so relationships to other objects are functional rather than enforced by the database. The most significant related objects are:

  • AR_CHARGE_SCHEDULE_DETAILS (or equivalent schedule-line table) — holds the individual scheduled charge lines, joined by SCHEDULE_ID.
  • AR_CHARGE_SCHEDULES_PK / AR_CHARGE_SCHEDULES_U1 — the primary key and unique index on SCHEDULE_ID that guarantee uniqueness of the surrogate key.
  • AR_CHARGE_SCHEDULES_U2 — the unique index on SCHEDULE_NAME that guarantees the business key is unique.
  • Receivables transaction tables (e.g., charges and invoice lines that reference a schedule) — joined functionally through the schedule identifier stored on the transaction.
  • Receivables DFF metadata tables (FND_DESCRIPTIVE_FLEXS and related segment tables) — define the ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 columns exposed on this table.
  • Receivables public APIs (e.g., the AutoInvoice interface) — consume schedule definitions when generating scheduled recurring charges.

Because the table is standalone, integrators should treat SCHEDULE_ID and SCHEDULE_NAME as the authoritative keys and apply their own referential validation rather than relying on database-level FK enforcement.