Search Results update_gl_date

Overview

OZF_GL_TRANSFER_PVT is an Oracle EBS private (PVT) PL/SQL package body owned by the APPS schema that supports general ledger transfer and Subledger Accounting (XLA) event date management for Oracle Trade Management (OZF) transactions. Its principal business role is to ensure that accounting events generated by Trade Management source documents carry valid general ledger dates that fall within an open GL period, rather than within a closed accounting period. This is significant because accrual, claim, and funds utilization transactions must be updated to the GL date of the earliest open period so that the corresponding XLA events can be processed without rejection by the accounting engine.

The package header references a sweep fix created under Bug#15949068 for entries stranded in a closed GL period. Its internal logic identifies XLA events in an unprocessed or incomplete process status whose event date precedes the earliest open period start date for the specified ledger, then calls the XLA Update API to realign the event date to that open period date. The package is classified as a private API, meaning it is intended for internal use by Trade Management and is not a public integration surface.

Key Procedures and Functions

The ETRM metadata documents a single procedure exposed by this package body: CREATEACCOUNTING. This procedure encapsulates the accounting creation workflow associated with the Trade Management GL transfer process, coordinating the update of event dates and the invocation of the XLA accounting APIs.

Internally, the package body contains a procedure named Update_GL_Date, which is visible in the source excerpt. Its documented purpose is to update the GL date of the Trade Management source transaction and to call the XLA Update API to reset the Event Date to the first date of the earliest open period. The procedure accepts an API version, an initialization message list flag, a commit flag, a validation level, and a ledger identifier, and returns a return status. It uses a cursor over XLA_EVENTS and XLA_TRANSACTION_ENTITIES_UPG to select eligible events for the ledger, and a second cursor over GL_PERIOD_STATUSES and OZF_SYS_PARAMETERS_ALL to determine the earliest open period start date. The procedure was created on 07-Dec-2012 and revised on 29-Jan-2013 following code review.

Tables Accessed

The package reads and writes a focused set of tables through APPS synonyms:

• GL_PERIOD_STATUSES — queried to determine the minimum open period start date for a given ledger and application, establishing the target GL date.
• OZF_SYS_PARAMETERS_ALL — provides the set of books / ledger configuration used to constrain the open period query.
• XLA_EVENTS and XLA_TRANSACTION_ENTITIES_UPG — joined to identify unprocessed accounting events for the ledger whose event date is earlier than the open period date, so they can be updated.
• OZF_CLAIMS_ALL and OZF_FUNDS_UTILIZED_ALL_B — the Trade Management source transaction tables whose GL dates are updated alongside the XLA events.
• OZF_TIME_ENT_YEAR — used for fiscal calendar and period derivation logic in Trade Management.
• FND_LANGUAGES — referenced for language-dependent lookups or message resolution.

Usage Notes

This package is a private API and is not referenced by any other documented package, indicating it is invoked directly by Trade Management processing logic rather than through a published dependency chain. It is typically triggered when GL transfer or accounting creation is executed for Trade Management claims, offers, or funds utilization transactions, particularly where prior accounting entries were dated in a period that has since closed. The sweep behavior is designed to be run for a specific ledger and will relocate affected event dates forward to the earliest open period, allowing XLA to complete accounting without manual intervention. Because the procedure exposes standard FND_API parameters including commit and validation level flags, callers can control transaction boundaries and validation depth. Customizations should avoid modifying this private package directly; instead, standard Trade Management concurrent programs and GL transfer flows should be used to invoke the underlying logic.