Search Results psa_ar_gl_post_pkg




Overview
Explore in AI Chat

Overview

PSA_AR_GL_POST_PKG is an Oracle EBS PL/SQL package owned by the APPS schema that supports the Oracle Public Sector / Projects accounting integration flow (PSA module). Its principal business function is to transfer accounting entries originating from Receivables (AR) and related subledger processing into the General Ledger (GL). The package header carries a source control identifier of PSAMFG1S.pls (version 120.0), indicating it is part of the PSA manufacturing and accounting posting family delivered within the E-Business Suite codebase. In release 12.1.1 and 12.2.2, this package participates in the standard accounting cycle by moving summarized or detailed distributions through the GL interface so that they can be journalized, posted, and reported.

The package is classified in the ETRM metadata as "OTHER," reflecting that it is an internal, undocumented-for-public-use program unit rather than a formally published public API. It is referenced by zero other packages, confirming that it operates as a top-level utility invoked directly by concurrent programs or wrapper logic rather than as a shared library called by sibling packages.

Key Procedures and Functions

The ETRM metadata documents a single procedure in the package specification:

  • TRANSFER_TO_GL — The sole documented entry point. Its purpose is to perform the transfer of accounting data to the General Ledger for a specified accounting window. The procedure accepts date boundaries (a start date and a posting-through date) that scope which transactions are eligible for transfer. It also receives a parent request identifier and a posting control identifier, which tie the execution to the concurrent request that launched it and to the posting run being processed. A summary flag controls whether entries are transferred in summarized or detail form. A status code is returned as an OUT parameter to communicate the outcome of the transfer to the calling program. No other procedures or functions are exposed in the documented specification.

Tables Accessed

The package interacts with a defined set of APPS synonyms, each serving a distinct role:

  • PSA_IMPLEMENTATION_ALL — The core PSA implementation/configuration table, used to determine installation-specific settings that govern how posting should behave for the current operating unit or ledger.
  • FND_APPLICATION — Provides application registration details, used to resolve the owning application context for the posting activity.
  • FND_USER, FND_RESPONSIBILITY, and FND_ORACLE_USERID — Standard Oracle Application Object Library tables referenced for security, responsibility, and database user context, ensuring the posting run executes under valid credentials and responsibility context.
  • ALL_OBJECTS — The data dictionary view, typically consulted for object existence or dependency validation during processing.

Collectively these tables support initialization, context validation, and control of the transfer operation rather than the storage of the journal lines themselves.

Usage Notes

PSA_AR_GL_POST_PKG is normally invoked from a concurrent program within the PSA/Projects accounting submission flow. The presence of the parent request ID and posting control ID parameters indicates the procedure is designed to be called by a concurrent manager child process, with the parent request representing the submission and the posting control ID identifying the specific posting batch. Callers must supply valid date ranges; rows outside the start-date and post-through-date window are excluded. Custom code should not call this package directly unless the same control identifiers and date semantics are preserved, because the procedure depends on FND context tables to validate the execution environment. Because the package is classified as OTHER and is not a published API, Oracle does not guarantee backward compatibility of its signature across patches; implementations extending it should validate behavior after each family pack or release upgrade. Its status code output should be checked by any wrapper to confirm successful transfer before downstream GL journal import and posting are initiated.