Search Results xla_post_acct_progs_b




Overview
Explore in AI Chat

Overview

XLA_POST_ACCT_PROGS_B is a Subledger Accounting (XLA) configuration table that stores the Post-Accounting Programs registered within Oracle E-Business Suite. In the XLA architecture, Post-Accounting Programs are the executable units invoked after subledger accounting has created and accounted for journal entries (the Create Accounting process). These programs perform downstream processing such as transfer to General Ledger, reporting, or custom post-accounting logic. The table acts as a registry of the available post-accounting programs and their associated application ownership.

The table resides in the XLA schema and is marked VALID in the ETRM 12.2.2 documented physical schema. It is a low-volume configuration table rather than a transactional table. Its primary key is XLA_POST_ACCT_PROGS_B_PK, defined on the composite of PROGRAM_OWNER_CODE and PROGRAM_CODE. A second unique index, XLA_POST_ACCT_PROGS_B_U1, adds ZD_EDITION_NAME to that pair, indicating edition-aware uniqueness.

Applying heuristic Data Vault modeling, this object classifies as a standalone hub: it carries a stable business key (PROGRAM_OWNER_CODE, PROGRAM_CODE) with no mined foreign-key dependencies to other tables. Descriptive attributes such as APPLICATION_ID and the standard audit columns function as satellite-style attributes attached to that key, though no separate satellite is physically documented.

Key Information Stored

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

  • PROGRAM_OWNER_CODE — Identifies the product or owner that provides the post-accounting program. Part of the primary key and business key.
  • PROGRAM_CODE — The program's short identifier used for lookups and registration. The other half of the composite primary key.
  • APPLICATION_ID — The Oracle Applications identifier (from FND_APPLICATION) indicating the owning application context of the program.
  • ZD_EDITION_NAME — Editioning column supporting Oracle EBS online patching (12.2.x). Included in the U1 unique index, giving edition-aware uniqueness.
  • CREATION_DATE, CREATED_BY — Standard who-columns capturing the initial insert.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns recording the most recent change and session.

The surrogate primary key is XLA_POST_ACCT_PROGS_B_PK over (PROGRAM_OWNER_CODE, PROGRAM_CODE). The business-key candidate is XLA_POST_ACCT_PROGS_B_U1 over (PROGRAM_OWNER_CODE, PROGRAM_CODE, ZD_EDITION_NAME), which enforces edition-scoped uniqueness in patched environments.

Common Use Cases and Queries

Typical use cases include auditing the registry of post-accounting programs, diagnosing Create Accounting or transfer-to-GL failures tied to a missing or misconfigured program, and building custom post-accounting integrations that must validate the program exists before invocation.

A common query lists programs for a given owner:

  • SELECT program_owner_code, program_code, application_id FROM xla_post_acct_progs_b WHERE program_owner_code = :owner;

To resolve the owning application name, join to FND_APPLICATION:

  • SELECT p.program_owner_code, p.program_code, a.application_name FROM xla_post_acct_progs_b p, fnd_application a WHERE p.application_id = a.application_id;

Because the table is small and edition-aware, reporting should generally filter on the active edition when querying in a 12.2.x environment.

Related Objects

The metadata identifies this object as standalone, so no foreign keys terminate here. Conceptually related objects include:

  • FND_APPLICATION — joined on APPLICATION_ID to resolve the owning application name.
  • XLA_POST_ACCT_PROGS_TL — the translated (MLS) companion holding language-specific descriptions, keyed by the same program identifier pair.
  • XLA_ACCOUNTING_PROGRAMS and related XLA program registries — sibling configuration tables in the same XLA schema.
  • XLA_EVENTS / XLA_AE_HEADERS — downstream accounting artifacts produced before post-accounting programs execute.
  • FND_CONCURRENT_PROGRAMS — maps the executable concurrent program to its registration.

These relationships are functional and logical rather than enforced by documented foreign-key constraints.