Search Results doc_state_rec_type




Overview
Explore in AI Chat

Overview

PO_DOCUMENT_ACTION_UTIL is a utility package in the Oracle Purchasing module (APPS schema) that centralizes the logic governing document state transitions, employee/buyer resolution, and action-history maintenance for purchasing documents. Its methods are consumed internally by Oracle Purchasing's document approval and control workflow — that is, when a requisition, purchase order, or related document is submitted, approved, forwarded, rejected, or cancelled, this package supplies the checks and updates that keep the document's authorization state, action history, and preparer/agent information consistent. It is not an end-user-facing API but an internal helper layer.

Because the package is classified as a UTIL object in ETRM, it is intended to be referenced by other Oracle Purchasing packages (it is documented as referenced by seven other packages) and does not constitute a standalone business API. Customizations generally call it only when extending the standard approval/control workflow.

Key Procedures and Functions

  • CHECK_DOC_STATE (function) — Evaluates whether a document (optionally at line or shipment level) currently satisfies an allowed combination of authorization states, closed states, hold/frozen flags, and reservation status. It returns a boolean result and an out return status, making it the primary gate used before permitting a document action.
  • GET_DOC_PREPARER_ID — Returns the preparer identifier associated with a given document and document type.
  • GET_EMPLOYEE_ID — Resolves the FND user identifier supplied as input to the corresponding HR employee identifier. It returns a flag indicating whether an employee record was found along with the employee id. This is the procedure surfaced by the search term "get_employee_id".
  • GET_EMPLOYEE_INFO — An extended form of employee resolution that additionally returns the employee name, location id and code, and a flag indicating whether the employee is a buyer.
  • CHANGE_DOC_AUTH_STATE — Performs the transition of a document's authorization state in response to an action, carrying forward the target approval path, forwarding recipient, note, new status, and notification details.
  • HANDLE_CTL_ACTION_HISTORY — Records or maintains action-history entries for document control actions.
  • UPD_IDV_QTY_AMT / UPD_IDV_QTY_AMT_HDR — Update quantity and amount values associated with supplier/individual (IDV) document lines and headers.
  • UPDATE_DOC_AUTH_STATUS — Persists the authorization status of a document after a state change.

The package also declares the global types DOC_STATE_ARRAY_TBL_TYPE and DOC_STATE_REC_TYPE, which bundle allowed authorization states, closed states, and hold/frozen/reservation flags used by CHECK_DOC_STATE.

Tables Accessed

The package reads and writes the core purchasing document tables — PO_HEADERS / PO_HEADERS_ALL, PO_LINES / PO_LINES_ALL, PO_LINE_LOCATIONS / PO_LINE_LOCATIONS_ALL, and PO_LINE_UCAS — to resolve and update document state. PO_DISTRIBUTIONS_ALL is touched for distribution-level context, and PO_DRAFTS / PO_LINES_DRAFT_ALL support draft documents. PO_ACTION_HISTORY is written by HANDLE_CTL_ACTION_HISTORY; PO_AGENTS and FND_USER are used for preparer, buyer, and employee resolution; PO_DOC_STYLE_HEADERS supplies document style configuration; and FINANCIALS_SYSTEM_PARAMETERS provides system-level defaults governing approval behavior.

Usage Notes

PO_DOCUMENT_ACTION_UTIL is normally invoked indirectly through the standard Oracle Purchasing approval and document-control flows rather than by end users. Custom forms, workflow functions, or concurrent programs that extend purchasing approvals may call individual methods — most commonly GET_EMPLOYEE_ID or GET_EMPLOYEE_INFO to map an FND_USER to an HR employee or buyer, and CHECK_DOC_STATE to validate whether a document may be actioned. Because it is an internal utility package, its specification is not guaranteed stable across releases, and behavior should be verified separately for EBS 12.1.1 and 12.2.2 environments before custom code depends on it.