Search Results get_accounting_flex




Overview
Explore in AI Chat

Overview

PO_AME_SETUP_PVT is an internal Oracle E-Business Suite package owned by APPS and classified as a private (PVT) API. Its principal business function is to supply the Oracle Approvals Management (AME) engine with the runtime attributes and setup determinations required to evaluate approval rules for purchasing documents. In release 12.1.1 and 12.2.2, approval routing for requisitions and purchase orders is delegated to AME rather than the legacy PO approval hierarchy. AME requires a set of document-specific attribute values — currency, rate type, accounting flexfield segments, changed document totals, and approver eligibility flags — in order to select the correct approver list. PO_AME_SETUP_PVT encapsulates the SQL and PL/SQL logic that produces those values, keeping the AME integration layer separate from the core purchasing transaction APIs.

The package is declared AUTHID CURRENT_USER, meaning its unqualified references resolve to the schema of the invoking session, and its objects are accessed through APPS synonyms. It is a private package: Oracle does not publish a supported public interface for it, and it is not intended for direct customer invocation.

Key Procedures and Functions

The ETRM metadata documents fourteen functions across the base and _PO variants. The functions most relevant to the approval attribute set include:

  • GET_FUNCTION_CURRENCY — returns the functional currency applicable to a requisition header, used by AME to normalize monetary attributes.
  • GET_RATE_TYPE — returns the currency rate type associated with a requisition header. This is the function returned by the get_rate_type search and is used when AME evaluates currency conversion for approval rule conditions and approval limits.
  • GET_ACCOUNTING_FLEX — returns the accounting flexfield value for a named segment on a given requisition distribution, enabling account-based approval routing (for example, by cost center or company segment).
  • GET_CHANGED_REQ_TOTAL — returns the net changed amount of a requisition, supporting rules that fire only when the modification value exceeds a threshold.
  • GET_NEW_REQ_HEADER_ID — maps an original requisition header to the header identifier generated during a change or revision, preserving approval continuity.
  • IS_SYSTEM_APPROVER_MANDATORY — indicates whether the system-level approver must be included in the approval list for the document.
  • CAN_PREPARER_APPROVE — determines whether the requisition preparer is permitted to approve the document, supporting segregation-of-duties rules.

The _PO counterparts — GET_ACCOUNTING_FLEX_PO, CAN_PREPARER_APPROVE_PO, IS_SYSTEM_APP_MANDATORY_PO, GET_FUNCTION_CURRENCY_PO, and GET_RATE_TYPE_PO — provide the equivalent determinations for purchase orders, while GET_MODIFICATION_AMOUNT and GET_MOD_AMOUNT_FOR_WARRANT return modification and warranty-basis amounts for threshold evaluation.

Tables Accessed

All table access is performed through APPS synonyms. Requisition data is read from PO_REQUISITION_HEADERS, PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES, and PO_REQ_DISTRIBUTIONS_ALL; purchase order lines are read from PO_LINES_ALL and PO_LINES_DRAFT_ALL. Document type and approval configuration are read from PO_DOCUMENT_TYPES_ALL_B, PO_REQ_DISTRIBUTIONS_ALL, and FINANCIALS_SYSTEM_PARAMS_ALL. User and profile context is obtained from FND_USER and FND_PROFILE_OPTION_VALUES. The package is predominantly read-only, deriving values rather than writing transactional data; its output is consumed by the AME rule engine during approval list generation.

Usage Notes

PO_AME_SETUP_PVT is invoked internally by the Purchasing AME integration layer, not by end users. In a typical flow, a requisition or purchase order is submitted for approval, the AME engine calls the attribute functions to resolve values for the active approval rule set, and the resulting approver list is applied. Two other packages reference it directly, consistent with a shared internal utility. Customers customizing approval rules generally touch documented AME attributes rather than this package. Any custom code that calls PO_AME_SETUP_PVT directly assumes unsupported-API risk, because Oracle may change signatures between patch levels. Diagnosing approval-routing issues attributable to currency, rate type, or account-based rules typically begins by inspecting the values returned by GET_FUNCTION_CURRENCY, GET_RATE_TYPE, and GET_ACCOUNTING_FLEX for the affected header.