Search Results process_suppinv_dtls

Overview

PAAP_PWP_PKG is a PL/SQL package owned by APPS in the Oracle E-Business Suite Projects (PA) module. The acronym "PWP" associates the package with the Project Workbench / Project PWP supplier invoice processing functionality, whose purpose is to populate staging tables (pa_pwp_ap_inv_hdr and pa_pwp_ap_inv_dtl) by processing supplier invoices that pertain to a given project. The package header declares a collection type InvoiceId (a table of AP_INVOICES_ALL.INVOICE_ID%TYPE) and a set of package-level globals that cache project and invoice context — including G_Project_Id, G_Invoice_Id, G_From_Curr (introduced via Bug# 7830751), G_Task_Id, G_Expenditure_Item_Date, and G_Draft_Inv_Num — along with project functional, project, and accounting currency code and cost-rate variables. These constructs indicate that the package is designed to iterate over multiple invoices while retaining currency and rate context across procedure calls, supporting the Projects-to-Payables (P2P) reconciliation and billing workflow.

Key Procedures and Functions

The ETRM metadata documents five callable units within APPS.PAAP_PWP_PKG. The primary processing entry points are PROCESS_SUPPINV_DTLS and its numbered variant PROCESS_SUPPINV_DTLS1, which drive the population of the supplier invoice header and detail staging tables for a supplied project. The documented header comment confirms that PROCESS_SUPPINV_DTLS processes all supplier invoices pertaining to the passed project_id and returns a status indicator through X_return_status, with valid values S (success), E (business rule violation), and U (unexpected error). Both procedures share the same business purpose and differ by version/wrapper lineage.

The user-requested member GET_PROJ_CURR_AMT is a function that returns an amount expressed in the project currency. It is used to convert or derive a monetary value against the project's functional or project currency, leveraging the package globals (ProjFunc_Currency, Proj_Currency, and the associated cost-rate date and rate-type variables) that are loaded from PA_PROJECTS_ALL. PAAP_RELEASE_HOLD and PAAP_APPLY_HOLD are complementary procedures that release and apply holds on the related Payables documents, operating against AP_HOLDS_ALL and the payment schedules. Together these units support the end-to-end invoice validation, currency translation, and hold management lifecycle for project-related supplier invoices.

Tables Accessed

The package reads and writes across both Projects and Payables schemas via APPS synonyms. Core Projects tables include PA_PROJECTS_ALL (project definition and currency/rate attributes), PA_TASKS, PA_EXPENDITURE_ITEMS_ALL, PA_CUST_REV_DIST_LINES, and PA_DRAFT_INVOICE_ITEMS (billing and revenue distribution context). Payables tables include AP_INVOICES_ALL and AP_INVOICE_DISTRIBUTIONS_ALL (invoice header and line detail), AP_INVOICE_PAYMENTS_ALL, AP_PAYMENT_HIST_DISTS, AP_PAYMENT_SCHEDULES_ALL, AP_PREPAY_APP_DISTS, and AP_HOLDS_ALL (hold application and release). Reference data is drawn from FND_LOOKUP_VALUES, GL_DAILY_CONVERSION_TYPES, and GL_PERIOD_STATUSES, which supply lookup codes, currency conversion rate types, and open/closed accounting period validation respectively — all essential to correctly valuing and dating project currency amounts returned by GET_PROJ_CURR_AMT.

Usage Notes

PAAP_PWP_PKG is classified as "OTHER" in the ETRM API taxonomy, meaning it is not a public, supported integration API but an internal package. It is referenced by one other package and is typically invoked from concurrent programs, Oracle Forms within the Projects workbench, or custom PL/SQL that needs to stage supplier invoice data for a project and obtain project-currency amounts. Because it manipulates staging tables and touches Payables hold and payment records, callers should respect the X_return_status convention, handle the E and U outcomes explicitly, and ensure the package globals are initialized (project id, currency, and rate context) before invoking GET_PROJ_CURR_AMT. As an undocumented internal API, it should not be called without validating behavior against the specific EBS release (12.1.1 or 12.2.2).