Search Results posting_run_id




Overview
Explore in AI Chat

Overview

APPS.GL_GLPPOS_PKG is a small, wrapper-oriented PL/SQL package body within the Oracle General Ledger (GL) posting infrastructure. Its role is to serve as an integration and delegation layer that sits alongside the core posting engine rather than performing posting logic itself. The package body exposes two documented procedures, each of which forwards control to another subsystem: glphk delegates to JG_GLPPOS_PKG.glphk, and after_final_journals_update delegates to IGI_POST.IGI_POST_GL_POSTING. Both procedures accept a single posting_run_id parameter, which is the internal identifier for a given execution of the General Ledger posting program. The package therefore acts as a stable, APPS-owned entry point that isolates callers from the underlying implementation, which is consistent with Oracle EBS layering conventions where integration hooks are kept in thin passthrough packages. The header comment ($Header: glupohkb.pls 120.8.12000000.2 2007/10/20 07:21:24 aktelang ship $) confirms that the file has been shipped as part of the GL product family and has not been substantially revised since the 12.0 code line, making the same behavior applicable to both 12.1.1 and 12.2.2.

Key Procedures and Functions

  • GLPHK — The primary documented procedure. It accepts a posting run identifier and immediately invokes JG_GLPPOS_PKG.glphk, passing the same value through unchanged. Because JG_GLPPOS_PKG is a Global Accounting Engine (JG) sibling package, this procedure exists to provide a GL-namespace entry point to the JG posting hook, allowing callers in the GL posting flow to trigger JG-specific processing without a hard dependency on the JG package name.
  • AFTER_FINAL_JOURNALS_UPDATE — The second documented procedure. Following the final update of journal data during a posting run, this procedure calls IGI_POST.IGI_POST_GL_POSTING, the IGI (Oracle Financials Intelligence/internal controls) posting integration routine. Its name indicates its invocation point: it is meant to run after final journals have been updated, so that downstream consumers receive notification of the completed posting run.

Neither procedure contains business logic of its own; both are single-statement delegation wrappers around the posting_run_id value supplied by the caller.

Tables Accessed

The documented metadata for GL_GLPPOS_PKG lists no tables referenced through APPS synonyms. This is consistent with the package body source, which performs no direct SQL against GL tables. All database reads and writes occur inside the delegated procedures — JG_GLPPOS_PKG.glphk and IGI_POST.IGI_POST_GL_POSTING — which operate on the posting and journal tables for the run identified by posting_run_id. Callers should therefore consult the documentation for those target packages to determine the actual table footprint (for example, the GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES family of posting tables). The absence of direct table dependencies is deliberate, keeping this package cheap to compile and free of invalidation when posting tables change.

Usage Notes

Because the package is classified as OTHER rather than as a public API, it should be treated as an internal component of the posting pipeline and invoked only by Oracle-standard code, not by customizations.

  • Posting flow invocation — The procedures are called by the General Ledger posting program as it moves through its stages. glphk is reached during the posting hooks phase for environments running the Global Accounting Engine, and after_final_journals_update is called at the completion of the final journal update step.
  • Parameter semantics — Both procedures require a valid posting_run_id, the same identifier used throughout a posting execution. Because the parameter is passed straight through, an invalid identifier surfaces as an error from the delegated package rather than from GL_GLPPOS_PKG.
  • Customization guidance — Custom code should not call APPS.GL_GLPPOS_PKG directly. If notification or extension of posting behavior is required, use the supported hooks and events exposed by the underlying JG and IGI packages, or the standard GL posting APIs.
  • Version applicability — The shipped and largely unchanged nature of the source means behavior is the same on 12.1.1 and 12.2.2; no version-specific variations in the wrapper logic are documented.