Search Results pa_ap_ei_date_default

Overview

PA_AP_INTEGRATION is a public PL/SQL package owned by APPS that governs the interface between Oracle Projects and Oracle Payables in Oracle E-Business Suite 12.1.1 and 12.2.2. Its core purpose is to maintain consistency between Payables supplier and invoice activity and the corresponding Projects cost, commitment, and expenditure records. The package is part of the Project Costing cost distribution infrastructure and is tightly coupled to the accounting flow that moves AP invoice distributions into PA expenditure items.

It originated as a private, "noship" header (PAAPINTS.pls, version 120.3, dated 2006/05/08) and has since been reclassified as an API of type OTHER in the ETRM 12.2.2 documentation. It exposes eight documented procedures and functions and is referenced by eight other packages, indicating that it is invoked indirectly by higher-level cost distribution and supplier merge logic rather than exclusively by end-user forms.

Key Procedures and Functions

The documented program units cover four functional areas:

• UPD_PA_DETAILS_SUPPLIER_MERGE — Updates Projects detail rows when two Payables suppliers are merged, propagating the old vendor identifier to the new one and returning staging and status indicators to the caller.
• ALLOW_SUPPLIER_MERGE — A validation function that determines whether a given supplier is eligible to participate in a supplier merge, thereby preventing merges that would corrupt Projects supplier references.
• GET_ASSET_ADDITION_FLAG — Returns the asset addition flag for a project, used to determine whether invoice distributions should be treated as capitalizable asset additions.
• GET_PROJECT_TYPE — Returns the project type for a supplied project identifier, supporting downstream branching in integration logic.
• GET_SI_COST_EXP_ITEM_DATE — The function matched by the user's search. It returns dates for the PA_AP_EI_DATE_DEFAULT profile option, handling invoice transactions (invoice_date), PO- or receipt-matched invoice transactions (invoice_date), RCV transactions (transaction_date), and payments and discounts (AP distribution exp_item_date). It is the transaction-date variant of the two date retrieval functions described in the Bug 5201382 header comments.
• GET_SI_DEFAULT_EXP_ORG — Retrieves the default expenditure organization for self-service invoice (SI) cost processing.
• GET_PO_MATCH_SI_EXP_ITEM_DATE — Returns the purchase order expenditure item date for PO-matched self-service invoice cases when the profile option is set to "PO Expenditure Item Date/Transaction Date"; the value may be null when the PO does not supply one.
• VALIDATE_EI_DATE — Validates an expenditure item date before it is accepted into the cost distribution flow.

Tables Accessed

The package reads and writes Projects, Payables, Purchasing, Grants, and HR tables through APPS synonyms. AP_INVOICES_ALL and AP_INVOICE_DISTRIBUTIONS_ALL supply invoice and distribution attributes, including the assets addition flag and payment status. PA_EXPENDITURE_ITEMS_ALL, PA_COST_DISTRIBUTION_LINES_ALL, PA_EXPENDITURES_ALL, PA_BC_COMMITMENTS_ALL, PA_BC_PACKETS, and PA_BUDGET_LINES hold the resulting expenditure, distribution, commitment, and budget records. PA_PROJECTS_ALL, PA_IMPLEMENTATIONS_ALL, and PA_CI_SUPPLIER_DETAILS provide project and implementation context and supplier cross-reference data. PO_DISTRIBUTIONS_ALL supplies PO-matched distribution dates. GMS_AWARDS_ALL and GMS_AWARD_DISTRIBUTIONS support grants-funded projects, while HR_ALL_ORGANIZATION_UNITS_TL resolves expenditure organization names.

Usage Notes

PA_AP_INTEGRATION is normally invoked indirectly: the Payables Invoice Workbench and the Payables supplier merge process call into it during invoice validation, accounting, and vendor merge, and the Projects cost distribution concurrent programs use its date and organization functions when profile PA_AP_EI_DATE_DEFAULT drives expenditure item date derivation. Custom code should treat the package as a supported API but must respect the profile option semantics documented in the header comments, particularly the distinction between transaction date, transaction GL date, and PO expenditure item date. Because the header carries a "noship" designation in earlier versions, implementers should verify the packaged specification shipped with the target release before building direct dependencies on individual signatures.