Search Results gl_wf_customization_pkg

Overview

The GL_WF_CUSTOMIZATION_PKG package body is a customization hook within the Oracle General Ledger workflow framework. It provides a set of PL/SQL procedures that Oracle Workflow calls during execution of the Journal Approval workflow to determine routing decisions and authority checks. The package is intentionally structured as an empty-shell customization point: each procedure returns a hard-coded result value and contains comments marking where customer-specific logic may be inserted. This design allows implementers to override standard journal approval behavior without modifying the seeded workflow definition itself.

In Oracle EBS 12.1.1 and 12.2.2, General Ledger journal batches can be routed through Oracle Workflow for approval. The workflow process invokes PL/SQL functions and procedures at decision points to evaluate whether a batch is valid, whether it requires approval, and who is authorized to approve it. The GL_WF_CUSTOMIZATION_PKG object supplies the default behavior for these decision points. The package body is marked with a source control header indicating version 120.2, last updated in 2002, and reflects the long-standing stability of this customization interface across EBS releases.

Key Procedures and Functions

The package body exposes four documented procedures, each conforming to the Oracle Workflow standard PL/SQL API signature (itemtype, itemkey, actid, funcmode, and a result OUT parameter).

• IS_JE_VALID — Determines whether the journal batch being processed is valid. When the workflow invokes the procedure in RUN mode, it returns COMPLETE:Y, indicating the journal batch is valid and the workflow takes the "Yes" transition branch. Returning COMPLETE:N would indicate the batch is not valid and route the workflow down the "No" branch.
• DOES_JE_NEED_APPROVAL — Establishes whether the journal batch requires approval. The default implementation returns COMPLETE:Y in RUN mode, signifying the batch needs approval. A COMPLETE:N result would signal that approval is unnecessary and the workflow would bypass or complete the approval path.
• CAN_PREPARER_APPROVE — Evaluates whether the preparer of the journal batch is permitted to approve their own work. This is a segregation-of-duties control point. The procedure may be evaluated in different funcmode states depending on the workflow configuration.
• VERIFY_AUTHORITY — Confirms whether the current approver possesses the authority to approve the journal batch, typically in relation to approval limits or signing authority established in General Ledger. This procedure is the object most frequently associated with the "verify_authority" search term, as it governs the authorization check step of the journal approval workflow.

Tables Accessed

The ETRM metadata for GL_WF_CUSTOMIZATION_PKG does not document any tables accessed through APPS synonyms. This is consistent with the package's role as a customization skeleton — the shipped procedures contain only conditional logic on funcmode and return hard-coded result values, performing no database reads or writes. Any table access would be introduced by customer-specific code inserted at the designated comment locations within each procedure body, or through calls to standard GL packages such as GL_JE_BATCHES_PKG or GL_JE_HEADERS_PKG.

Usage Notes

GL_WF_CUSTOMIZATION_PKG is invoked by the Oracle Workflow engine during execution of the Journal Approval workflow (typically based on the GL Journal Approval item type). Customers customize approval routing by editing the package body in APPS and adding logic to the four procedures. Typical use cases include implementing amount-based approval routing, enforcing segment-based approval hierarchies, applying cross-validation or budget checks, and integrating external authorization rules.

The package is referenced by zero other PL/SQL packages according to ETRM, confirming that its only consumers are workflow definitions. After modifying the package body, implementers must recompile it in the APPS schema and restart any workflow background processes or agents so the updated logic takes effect. Because the workflow invokes procedures dynamically by name, changes to the procedure names or signatures would break the workflow configuration; only the internal logic should be altered.