Search Results insert_rows_pd
Overview
APPS.POA_PORTAL_POPULATE_C is a PL/SQL package in Oracle E-Business Suite that supports the Procurement Operations Analysis (POA) portal, a business intelligence and analytics framework used to aggregate purchasing, receiving, supplier performance, and financial indicator data into summary structures for reporting. The package functions as a data population and staging utility, extracting transactional detail from source tables and materializing it into the POA portal summary and distribution tables that back the portal's dashboards and analytic views.
The header comment indicates a 2005 origin (version 120.0), and the object is classified as an "OTHER" API rather than a public, supported interface, which means it is intended for internal use by the POA portal infrastructure. It resides in the APPS schema and references source objects through APPS synonyms, consistent with standard EBS deployment practice. The package is not referenced by any other documented package, indicating that it is a top-level driver invoked by concurrent programs or portal setup logic rather than a reusable library component.
Key Procedures and Functions
The package exposes nine documented procedures. Two are top-level entry points: populate_poa and populate_poa_fii, which carry the standard concurrent-program parameter convention (Errbuf and Retcode) and orchestrate the overall population of the POA portal, with the FII variant targeting the financial indicator integration data set.
The remaining procedures are individual loaders, each responsible for a specific data domain:
- insert_rows_pd — loads purchase order distribution data, accepting a date range and a quarter identifier and returning a processed row count and a success flag. This is the procedure associated with the "insert_rows_pd" search term.
- insert_rows_sr — loads supplier-related summary rows for the reporting period.
- insert_rows_cm — loads comparison or commitment-oriented rows within the supplied date range.
- insert_rows_sp — loads supplier performance data.
- insert_rows_rcv — loads receiving transaction data.
- insert_rows_cross — loads cross-domain or cross-reference rows that support composite analysis.
- truncate_tables — clears target staging or summary tables before a reload, taking a numeric type discriminator and returning a success indicator.
Each insert procedure follows a consistent pattern: a start date, an end date, an output row count, and an output success flag. The consistent signature allows the orchestrating procedures to invoke them in sequence for a given reporting window.
Tables Accessed
The package draws on two categories of tables. The first is the EDW reference and master set — EDW_ITEMS_M, EDW_LOOKUP_M, EDW_ORGANIZATION_M, EDW_TIME_M, and EDW_TRD_PARTNER_M — which supply item, lookup, organization, calendar, and trading-partner dimensions used to enrich and conform the transactional extracts.
The second category consists of fact and summary targets. POA_EDW_PO_DIST_F, POA_EDW_RCV_TXNS_F, and POA_EDW_SUP_PERF_F hold purchase distribution, receiving transaction, and supplier performance facts. POA_PORTAL_PDIST, POA_PORTAL_PDIST1, and POA_PORTAL_PDIST2 are the portal distribution summary tables, and POA_PORTAL_RCPT_SUM holds receipt summaries. FII_AP_OP_INDICATOR_SUMMARY, FII_AP_TRANS_BACKLOG_SUMMARY, and POA_PORTAL_FII_SUMMARY support the financial indicator integration path exercised by populate_poa_fii.
Usage Notes
In Oracle EBS 12.1.1 and 12.2.2, this package is normally executed through the POA portal concurrent programs rather than called interactively. Administrative users schedule the population program to run on a periodic basis, typically after the close of a reporting period or quarter, so that the portal reflects current purchasing and receiving activity. The populate_poa and populate_poa_fii procedures supply the Errbuf and Retcode parameters expected by the concurrent manager, making them suitable as the program entry point.
Because the object is classified as OTHER and carries a stale header version, it should be treated as internal and unsupported. Custom code that calls it directly risks breakage on patching or upgrade, since Oracle does not guarantee the signature or behavior of non-public APIs. When direct invocation is unavoidable, the insert_rows_* procedures should be called only after truncate_tables has cleared the relevant targets, and the returned success flag should be checked before proceeding to dependent steps.