Search Results fii_ar_util_pkg




Overview

APPS.FII_AR_UTIL_PKG is a shared PL/SQL utility package body in the Oracle E-Business Suite Financial Intelligence and Enterprise TRM (FII) application family. Its principal business function is to supply the common analytical and setup logic required by the Accounts Receivable (AR) reporting components, most notably Days Sales Outstanding (DSO) and related receivables trend analyses. The package acts as a reusable service layer: it resolves operating unit context, retrieves profile-driven setup values, manages the display and global currency conventions, and constructs the dynamic SQL predicates and materialized-view filters consumed by the AR analytical reports.

The package is validated and resides in the APPS schema. The ETRM repository records no incoming database references — the object is not referenced by any database object — but it is referenced by twenty-five other packages, confirming its role as a foundational dependency in the FII reporting stack. It is classified as OTHER, indicating it is an internal utility rather than a published public API.

Key Procedures and Functions

Twenty-two documented procedures and functions are exposed. They fall into four functional groups.

Procedure parameters are not documented in the source metadata and are therefore not reproduced here.

Tables Accessed

The package reads and writes the following documented objects, primarily through APPS synonyms:

Usage Notes

FII_AR_UTIL_PKG is an internal utility rather than a user-facing API. It is normally invoked indirectly by the AR analytical report packages and concurrent programs that make up the FII receivables analytics suite, and it is referenced by twenty-five dependent packages. Because it depends on BIS PMV parameter structures (BIS_PMV_PAGE_PARAMETER_REC, BIS_PMV_PARAMETER_TBL, BIS_PMV_PARAMETERS_PUB) and on FND_PROFILE, it is best treated as read-only from a custom-code perspective. Customers extending DSO or receivables trend reporting should call the parent report packages rather than this utility directly, and should avoid invalidating it, as a change in status would cascade to all twenty-five dependent objects.