Search Results c_pss_api
Overview
PAY_PPMV4_UTILS_SS is a server-side PL/SQL utility package in the Oracle E-Business Suite Payroll (PAY) module, classified under the OTHER API category. Its name indicates a Payroll Payment Method (PPM) utility ("UTILS") implemented as a server-side ("_SS") stub or support package. In the context of Oracle EBS 12.1.1 and 12.2.2, this package supports the Personal Payment Method (PPM) self-service flows and the integration of external payment method data with Oracle Workflow and the underlying PPM transaction model. The package header (pyppmv4u.pkh, version 120.0.12010000.1) declares a substantial set of constants and a record type, t_ppmv4, that mirrors the columns of PAY_PSS_TRANSACTION_STEPS and PAY_PERSONAL_PAYMENT_METHODS_F. The package therefore acts as a bridge between the transaction-step state machine used by PPM self-service and the Workflow configuration and activity data used to drive user review and processing.
Key Procedures and Functions
ETRM documents twelve procedures/functions in this package. PROCESS_API is the primary entry point and is also exposed through the C_PSS_API constant, which resolves to 'PAY_PPMV4_SS.PROCESS_API'; it is the API called to process PPM transactions. READ_WF_CONFIG_OPTION is the routine that reads a Workflow configuration option, typically to determine how a PPM workflow step or review action should be configured at runtime. The Workflow-related constants in the header (P_PROCESSED_FLAG, P_TRANSACTION_STEP_ID, P_REVIEW_PROC_CALL, P_REVIEW_ACTID, HR_REVIEW_REGION_ITEM, PAY_PSS_ASSIGNMENT_ID, PAY_PSS_EFFECTIVE_DATE) supply the argument names used with this and related routines.
The conversion/mapping routines PPM2HRTT, PPM2TT, and TT2PPM translate data between the Personal Payment Method representation, the transaction-step (TT) representation, and an HR transaction-table representation. CHANGEDPPM detects or handles changes to a personal payment method and propagates the appropriate action; VALIDATEPPM performs validation of a PPM record before it is committed. NEXTENTRY implements sequencing or entry selection logic within the transaction flow; GETPRIORITIES retrieves the priority values used to order processing (the header defines C_MAX_PRIORITY 99, C_MIN_PRIORITY 1, and C_NO_PRIORITY -1). GET_BANK_SEGMENTS retrieves the bank account key flexfield segment values needed when constructing or validating an external account; SETERRORSTAGE records error handling state when a transaction step fails. Together these procedures implement the read, validate, convert, process, and error-reporting cycle of the PPM self-service workflow.
Tables Accessed
The package reads and writes several APPS synonym-backed tables. PAY_PSS_TRANSACTION_STEPS holds the transaction-step rows whose state drives PPM processing and supplies the columns reflected in the t_ppmv4 record type (transaction_id, transaction_step_id, source_table, state). PAY_PERSONAL_PAYMENT_METHODS_F and PAY_ORG_PAYMENT_METHODS_F store the personal and organizational payment method definitions, including object version numbers used for concurrency control. PAY_EXTERNAL_ACCOUNTS holds external bank account details accessed by GET_BANK_SEGMENTS and the payment-method validation logic. PER_ALL_ASSIGNMENTS_F supplies assignment context, referenced through the PAY_PSS_ASSIGNMENT_ID constant. WF_ACTIVITY_ATTRIBUTES and WF_ACTIVITY_ATTR_VALUES hold the Workflow activity attribute definitions and values read by READ_WF_CONFIG_OPTION. PLITBLM is the PL/SQL table/list utility used for in-memory collections.
Usage Notes
PAY_PPMV4_UTILS_SS is typically invoked indirectly rather than directly by end users. It participates in PPM self-service flows driven by Oracle Workflow, where PROCESS_API is called as the transaction API and READ_WF_CONFIG_OPTION inspects the configured workflow option before a review activity. The package is referenced by one other package in the EBS codebase, indicating that it is consumed by higher-level PPM processing logic rather than acting as a top-level public API. Customizations should avoid modifying the package directly; instead, the documented entry points can be called from custom PL/SQL or extensions that follow the existing Workflow configuration conventions. Because the constants and record type are declared in the package header, dependent code should reference them by name (for example C_PSS_API or PAY_PSS_ASSIGNMENT_ID) rather than hard-coding literal values.