Search Results unregister_data_location
Overview
FEM_DIMENSION_UTIL_PKG is a foundational utility package within the Oracle Enterprise Performance Foundation (EPF) / Enterprise Resource Management (ETRM) foundation layer of Oracle E-Business Suite, owned by the APPS schema and declared with AUTHID CURRENT_USER. As its header comment in FEMDIMAPS.pls states, the package provides functions and procedures that assist in querying against the EPF dimension tables and views, and in registering and maintaining the metadata that describes applications, ledgers, datasets, calendars, budgets, and dimension members. It does not execute financial calculations itself; rather, it establishes and validates the reference data on which the FEM (Financial Enterprise Management) analytical and consolidation engines depend. The package has evolved continuously since 2004, with bug-fix history covering the rename of the set-of-books concept to fem_ledger (Bug 3570753), the introduction of the New_Budget API (Bug 3824427), the Relative_Cal_Period_ID function (Bug 4005877), the altered Register_Data_Location signature (Bug 3824701), and the addition of Get_Dim_Member_Name (Bug 5473131). Because it is referenced by roughly 130 other packages, it functions as a shared service layer for the entire EPF schema and is the entry point users reach through the FEM_INITIALIZE routine.
Key Procedures and Functions
The documented API surface contains 49 procedures and functions. The initialization suite (FEM_INITIALIZE) prepares session-level context used by downstream FEM calls. Identity and grouping helpers — APPLICATION_GROUP_ID, GLOBAL_VS_COMBO_ID, LOCAL_VS_COMBO_ID, and DIMENSION_VALUE_SET_ID — resolve surrogate keys and value-set mappings for applications and dimension combinations. Calendar utilities include RELATIVE_CAL_PERIOD_ID, EFFECTIVE_CAL_PERIOD_ID, and GET_CAL_PERIOD_ID, which translate relative or effective dates into calendar period identifiers.
Validation is handled by IS_RULE_VALID_FOR_LEDGER. Registration and maintenance of metadata objects is performed by REGISTER_DATA_LOCATION and UNREGISTER_DATA_LOACTION (used to attach and detach data sources), NEW_DATASET, NEW_BUDGET, REGISTER_BUDGET, NEW_LEDGER, REGISTER_LEDGER, NEW_ENCUMBRANCE_TYPE, and REGISTER_ENCUMBRANCE_TYPE. Member generation and lookup are provided by GENERATE_MEMBER_ID, the overloaded GENERATE_DEFAULT_LOAD_MEMBER, and the display/name helpers such as GET_DIM_MEMBER_DISPLAY_CODE and GET_DIM_MEMBER_NAME. Parameter lists are not reproduced here; callers should consult the current package specification for exact signatures, as several have been altered across patch levels.
Tables Accessed
The package reads and writes the core FEM metadata tables via APPS synonyms. Dimensional definitions reside in FEM_DIMENSIONS_B and FEM_DIMENSIONS_TL, with group hierarchies in FEM_DIMENSION_GRPS_B and member-level attributes in FEM_DIM_ATTRIBUTES_B. Ledger and calendar structures are stored in FEM_CALENDARS_B, FEM_CALENDARS_B_S, FEM_CALENDARS_ATTR, FEM_CAL_PERIODS_B, and FEM_CAL_PERIODS_ATTR. Dataset and budget metadata occupy FEM_DATASETS_B_S, FEM_DATASETS_ATTR, FEM_BUDGETS_B, and FEM_BUDGETS_ATTR. Application registration is supported by FEM_APPLICATIONS, and cost center organization data by FEM_CCTR_ORGS_B_S. These tables supply the identifiers and descriptive attributes the package returns to callers.
Usage Notes
FEM_DIMENSION_UTIL_PKG is typically invoked indirectly rather than by end users. EPF setup forms and concurrent programs call it to initialize session context, resolve dimension and calendar identifiers, and register ledgers, budgets, datasets, and encumbrance types during configuration. Custom code and integrations extending FEM should call the documented APIs rather than manipulating the underlying tables directly, since the package enforces the referential and validation rules that keep FEM metadata consistent. Because the package is referenced by a large number of dependent objects, modifications to its behavior carry broad impact, and the overloaded signatures mean custom callers must pass parameters that match the version present in the target release. In 12.1.1 and 12.2.2 the package remains an unsupported internal API, so extensions should be tested carefully against each patch level.