Search Results insert_distributions_log

Overview

PSA_MFAR_UTILS is a shared PL/SQL utility package in the APPS schema that supports the Oracle EBS Public Sector Applications (PSA) Multifund Accounts Receivable (MFAR) feature set. Its central purpose is to resolve accounting flexfield combinations (code combinations), derive receivable and cash control accounts, and persist distribution line information for grant and fund accounting transactions created in the PSA receivables stream. In 12.1.1 and 12.2.2 the package remains a supporting library used by the MFAR transaction, adjustment, and receipt processing programs rather than a user-facing component.

The package acts as the accounting infrastructure layer for fund accounting: it determines the chart of accounts context, validates whether a code combination identifier already exists, inserts new combinations when required, and writes distribution records that downstream General Ledger transfer programs consume. Because the PSA Multifund modules post to a dedicated fund accounting set of books, PSA_MFAR_UTILS also handles the book and organization context resolution used when building those accounting entries.

Key Procedures and Functions

The package exposes ten documented program units. Their purposes are as follows:

• GET_USER_CATEGORY_NAME — retrieves the user-defined transaction category name used to classify PSA receivable transactions for accounting and reporting.
• OVERRIDE_SEGMENTS — applies segment overrides to an accounting flexfield combination, allowing fund, grant, or program dimensions to be substituted according to MFAR rules.
• INSERT_DISTRIBUTIONS_LOG — writes distribution information into the MFAR distributions log table, creating the audit and staging records used by the GL transfer process.
• PSA_MF_ORG_DETAILS — returns organization and operating unit detail used when attributing fund accounting entries to the correct entity.
• GET_AR_SOB_ID — resolves the set of books identifier associated with the receivables ledger, establishing the accounting context for subsequent processing.
• GET_REC_CCID — obtains the code combination identifier for the receivables control account applied to MFAR transactions.
• GET_COA — returns the chart of accounts identifier valid for the operating context.
• ACCOUNTING_METHOD — determines the accounting method applied to the transaction, driving whether cash or accrual style distributions are generated.
• INSERT_CCID — creates a new code combination identifier when a valid combination does not yet exist.
• IS_CCID_EXISTS — validates whether a given code combination identifier is already defined, preventing duplicate account creation.

Tables Accessed

The package reads key flexfield definition and value tables, including FND_ID_FLEX_STRUCTURES, FND_ID_FLEX_SEGMENTS, FND_FLEX_VALUES, and FND_SEGMENT_ATTRIBUTE_VALUES, to validate and construct accounting combinations. It accesses GL_CODE_COMBINATIONS for code combination creation and verification, GL_SETS_OF_BOOKS for ledger context, GL_JE_CATEGORIES for journal categorization, and FND_APPLICATION for application validation.

Receivables and PSA-specific data come from AR_SYSTEM_PARAMETERS, RA_CUSTOMER_TRX_ALL, and RA_CUST_TRX_LINE_GL_DIST_ALL, which supply ledger parameters, transaction headers, and receivable distribution lines. PSA_IMPLEMENTATION_ALL, PSA_MF_ACCOUNT_MAPPING_ALL, and PSA_MF_ACCT_MAP_HEADER_ALL provide implementation and account mapping rules, while PSA_MF_DISTRIBUTIONS_LOG is written by the logging routine. PLITBLM appears as an internal PL/SQL table type reference rather than a physical application table.

Usage Notes

PSA_MFAR_UTILS is not invoked directly by end users. It is called by MFAR processing packages such as PSA_MFAR_TRANSACTIONS, PSA_MFAR_ADJUSTMENTS, PSA_MFAR_RECEIPTS, PSA_MFAR_VAL_PKG, and the GL transfer packages PSA_MF_GL_TRANSFER_PKG, PSA_AR_GL_POST_PKG, PSA_XFR_TO_GL_PKG, and PSA_MF_MISC_PKG. These packages are in turn driven by concurrent programs, forms, and PSA workflows responsible for creating and posting multifund receivable activity. Customizations should call the documented procedures rather than replicating account derivation logic, and should treat the package as dependent on correct implementation and account mapping setup.