Search Results gms_funds_posting_pkg




Overview
Explore in AI Chat

Overview

GMS_FUNDS_POSTING_PKG is an Oracle Grants Management (GMS) funds-checking integration package owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its purpose is to interpret and translate funds-checking responses generated by the General Ledger budget-control engine and the GMS budget engine, and to propagate the appropriate return and partial-funding codes back to the originating transaction. The package header explicitly documents that the API is called during PO/AP funds-checking "AUTONOMOUS code," meaning it is designed to execute as an autonomous transaction so that status write-backs persist independently of the caller's transaction. This behavior is essential in funds-checking flows, where a transaction may ultimately fail or roll back but the budget-control result and packet status must still be recorded. The header comment notes the package was included as an 11.5.10 deliverable, which establishes its lineage across the EBS 12.x releases.

Key Procedures and Functions

The package exposes a single documented procedure: GMS_GL_RETURN_CODE. Its contract centers on receiving the return codes that emerge from the GL and GMS funds-checking evaluation and reconciling them against a specific budget-check packet. The procedure accepts an error code and error stage (both IN OUT), the GL return code (IN OUT), a packet identifier, a processing mode, the GMS return code, and a GMS partial-funding flag. The IN OUT NOCOPY parameters allow the procedure to both read and revise the caller's error and return-code state in place, which is important because the caller typically needs the updated status to decide its next action.

Functionally, GMS_GL_RETURN_CODE maps the combination of the packet context and the raw GL return code into a GMS-appropriate outcome. When funds are only partially available, the partial flag is used to signal that condition rather than a hard failure, allowing downstream awards processing to distinguish "insufficient" from "no funds at all." The procedure serves as the translation layer between the two funds-checking engines so that AP and PO distributions reflect a consistent budget verdict. No other public procedures or functions are documented in the package metadata.

Tables Accessed

The package reads and writes a focused set of tables through APPS synonyms. AP_INVOICE_DISTRIBUTIONS_ALL, PO_DISTRIBUTIONS_ALL, and PO_REQ_DISTRIBUTIONS_ALL represent the AP invoice and purchasing distribution lines whose funds status is being finalized. GMS_AWARD_DISTRIBUTIONS holds the award-side distribution detail against which grant funds are checked. The budget-check packet tables GMS_BC_PACKETS and GL_BC_PACKETS store the packet records created during funds checking and are the primary targets for status and return-code updates. GMS_BUDGET_VERSIONS identifies the budget version used in the check, while PA_PROJECTS and PA_PROJECTS_ALL supply the project context that ties an award and its distributions together. DUAL, DBMS_SQL, and PLITBLM are utility references; DBMS_SQL indicates dynamic SQL is used internally, likely for flexible lookups or updates.

Usage Notes

GMS_FUNDS_POSTING_PKG is not an end-user-facing API. It is invoked programmatically by the AP and PO funds-checking infrastructure as part of the autonomous posting routine that runs after a distribution is evaluated against grant budgets. Because the header specifies AUTHID CURRENT_USER, privileges are resolved against the calling user rather than the definer, so execute grants must be managed carefully on custom callers. There are no referencing packages documented within the ETRM metadata, confirming it is a leaf-level integration point rather than a shared library. Developers troubleshooting the search term "gms_gl_return_code" should treat the procedure of that name as the entry point: it is the mechanism by which GL budget-control return codes are translated into GMS results and written to the BC packet tables. Custom code should call it only within a properly formed funds-checking context, supplying a valid packet identifier and the return codes produced by the preceding budget check, and should honor the IN OUT semantics of the error and return-code parameters.