Search Results populate_target_balances
Overview
CE_LEVELING_UTILS is a PL/SQL package owned by the APPS schema within the Oracle Cash Management (CE) application. It provides the core utility logic for cash leveling, cash pooling, and automated fund transfer processing in Oracle E-Business Suite releases 12.1.1 and 12.2.2. The package status is VALID in the referenced environment, and the ETRM metadata classifies it as an "OTHER" API type rather than a formal public API. In practical terms, CE_LEVELING_UTILS functions as the internal engine that determines how surplus or deficit balances across bank accounts within a cash pool or cash concentration structure should be redistributed.
Cash leveling is the process by which a treasury organization automatically sweeps funds between a parent (concentration) account and its subordinate accounts in order to maintain target balances, minimize interest exposure, or satisfy zero-balance account (ZBA) arrangements. CE_LEVELING_UTILS supports this by calculating proposed transfers, evaluating cashpool hierarchies, populating nested account structures, and generating the output records that downstream processes consume. Its dependency listing shows that it references SYS.STANDARD (the standard PL/SQL package) and that it is referenced by CE_LEVELING_UTILS itself and by CE_ZBA_DEAL_GENERATION, confirming its role as a shared utility called both recursively and from ZBA deal generation logic.
Key Procedures and Functions
The ETRM documentation records ten procedures and functions in the package. The principal entry points are:
- CASH_LEVELING — The central routine that executes the cash leveling calculation, determining the amounts to be moved between accounts in a pool.
- GENERATE_FUND_TRANSFER — Produces the fund transfer records that represent the movements identified by the leveling logic.
- GENERATE_BUTTON — Supports user-driven leveling from the Cash Management interface by assembling the data required when a leveling action is triggered from a form.
- POPULATE_NESTED_ACCOUNTS — Builds the hierarchical (parent/child) account structure used when cash pools contain nested levels of sub-accounts.
- DELETE_SUB_ACCOUNTS — Removes sub-account associations when a pool structure is changed or regenerated.
- UPDATE_PARENT_NESTED_ACCOUNTS — Maintains parent-level nested account information as the pool hierarchy evolves.
- POPULATE_TARGET_BALANCES — Calculates and stores the target balance figures that drive leveling decisions.
- POPULATE_BAT_PAYMENT_DETAILS — Populates bank account transfer (BAT) payment detail records used in funding transactions.
- UPDATE_BANK_ACCOUNT_ID — Maintains the bank account identifier on records processed by the package.
- MATCH_CASHPOOL — Resolves and matches the appropriate cashpool definition for a given account or transaction context.
Parameter lists are not documented in the available metadata; consumers should treat these as internal routines whose signatures may change between patch levels.
Tables Accessed
The package operates against a focused set of Cash Management tables through APPS synonyms. CE_BANK_ACCOUNTS and CE_CASHPOOLS provide the account and pool definitions; CE_CASHPOOL_SUB_ACCTS and CE_CASHPOOL_SUB_ACCTS_S hold the sub-account hierarchy. CE_CP_WORKSHEET_LINES stores worksheet-level leveling proposals, while CE_PROPOSED_TRANSFERS receives the generated transfer proposals. CE_FORECAST_ROWS and CE_STATEMENT_LINES supply balance and statement information used to compute leveling amounts. CE_TRXNS_SUBTYPE_CODES classifies transactions, and CE_LEVELING_MESSAGES plus CE_LEVELING_MESSAGES_S hold the messages surfaced to users during leveling. FND_APPLICATION and FND_NEW_MESSAGES provide application registration and message lookup services.
Usage Notes
CE_LEVELING_UTILS is normally invoked indirectly. In standard EBS flows it is called from the Cash Management leveling and cashpool worksheets, from concurrent programs that process proposed transfers, and from CE_ZBA_DEAL_GENERATION during zero-balance account processing. Custom code should avoid calling these procedures directly unless the dependency on internal table structures and column semantics is fully understood, since the package is not published as an open API and its behavior is tightly coupled to the CE data model. Any customization should be regression-tested after Cash Management patches or upgrades, particularly between 12.1.1 and 12.2.2, where table and view definitions may differ.