Search Results upload_factor_table3_interface




Overview

APPS.FEM_WEBADI_FACT_TAB_UTILS_PVT is a private (PVT-classified) PL/SQL package within the Oracle Enterprise Performance Foundation (now Profitability Management / Enterprise Tax, Revenue and Management, "ETRM") schema of Oracle E-Business Suite. Its role is to support the WebADI-driven upload of factor table definitions and associated factor rules into the ETRM repository. Factor tables in ETRM are user-defined structures that hold allocation, distribution, or rate factors keyed by one or more matching dimensions, with optional distribution dimensions and hierarchical relationships. Rather than forcing users to key these definitions directly into the application, WebADI provides a spreadsheet-based interface that lets business users populate a factor table, and this package performs the server-side transformation of each uploaded row into the underlying rule, version, dimension, and factor records. The package also handles the resolution of hierarchical descriptor rows for each matching dimension, materialising the detail and dimension entries that back each factor table. It is called internally by the WebADI integration and is not intended as a public API.

Key Procedures and Functions

  • UPLOAD_FACTOR_TABLE1_INTERFACE — Processes an uploaded factor table definition for the one-matching-dimension variant. It accepts the rule header attributes (rule name, folder, description, version name, start and end dates, version description, factor type), the single matching dimension with its hierarchy, hierarchy version, level, and hierarchy relationship, plus the distribution dimension, force-to-hundred flag, object access code, matching and distribution dimension members, and the amount. It creates or updates the corresponding factor table rule and version records.
  • UPLOAD_FACTOR_TABLE2_INTERFACE — The two-matching-dimension equivalent of the above. It carries the same header and distribution attributes but supplies matching dimension and hierarchy details for two dimensions, two hierarchy relationship specifications, and two member identifiers.
  • UPLOAD_FACTOR_TABLE3_INTERFACE — The three-matching-dimension equivalent, extending the pattern to three matching dimensions, three hierarchy relationships, and three member identifiers. This is the procedure most commonly reached when a user searches for "upload_factor_table3_interface" in the context of a three-dimensional factor table WebADI template.
  • POPULATE_RULE_DETAILS — Builds the detail rows that describe a rule and its version, writing the header, version, and hierarchy descriptor records required before factor rows can be associated with the table.
  • POPULATE_FACTOR_TABLE_DIMS — Resolves and inserts the dimension rows for a factor table, mapping the supplied matching dimensions, hierarchies, levels, and members into the factor table dimension structures.

Tables Accessed

The package reads and writes the core Profitability Management factor table model. FEM_FACTOR_TABLES stores the factor table header, while FEM_FACTOR_TABLE_DIMS holds the dimensional composition of each table and FEM_FACTOR_TABLE_FCTRS holds the individual factor values. FEM_FACTORS_ROW_NUM_SEQ supplies row numbering for factor entries. Rule and version metadata is persisted through FEM_OBJECT_CATALOG_B, FEM_OBJECT_CATALOG_TL, FEM_OBJECT_DEFINITION_B, and FEM_OBJECT_DEFINITION_TL, with FEM_OBJECT_ID_SEQ and FEM_OBJECT_DEFINITION_ID_SEQ providing primary keys. FND_LANGUAGES is referenced to resolve the appropriate language rows for the translated catalog and definition tables, and DUAL is used for sequence and constant lookups.

Usage Notes

FEM_WEBADI_FACT_TAB_UTILS_PVT is invoked indirectly through the WebADI integration framework when a user uploads a factor table spreadsheet. The relevant interface procedure is selected based on the number of matching dimensions defined in the template (one, two, or three), so a three-dimension upload routes to UPLOAD_FACTOR_TABLE3_INTERFACE. Because the package is classified PVT and is referenced by zero other packages in the documented metadata, it should be treated as internal implementation: custom code should not call it directly. Site-specific customisations should instead use supported ETRM public APIs or the supported WebADI upload path, since the parameter signatures of these private procedures are subject to change between releases without notice.