Search Results ar_bpa_items_s

Overview

AR_BPA_UTILS_PKG is a utility package body in the APPS schema that supports the Oracle Receivables Billing Publishing Architecture (BPA), the framework that generates formatted, customer-facing billing documents such as invoices, credit memos, and statements. The package consolidates the recurring "lookup and derivation" logic required when building these documents: resolving billing and shipping contact information, determining tax printing behavior, and retrieving tax rate, tax name, and tax code values at the line, group, and header levels. Because the ETRM metadata classifies the API as OTHER, AR_BPA_UTILS_PKG is not a public, supported interface; it is an internal helper package used primarily by sibling BPA packages and by the BPA template and content area infrastructure. Its status is VALID and it currently references twenty tables and three other packages, while being referenced by three dependent packages. The heavy concentration of AR_BPA_* objects among its dependencies confirms its role as the shared service layer for BPA item and content-area processing.

Key Procedures and Functions

The package exposes twenty-three documented procedures and functions. They fall into several logical clusters. Header-level attribute resolution is handled by functions that determine header-level "sold-to" and "customer" behavior and the profile class name, all of which drive how downstream template substitutions and layout rendering behave.

• Contact and address utilities: functions to retrieve billing line-level data, contact name, telephone number, and fax number, drawing on the Trading Community Architecture (HZ) tables.
• Tax utilities: functions returning the tax printing option, line-level tax rate, tax name, and tax code, plus parallel group-level functions for tax rate, tax name, tax code, and a group-level "tax applicable" indicator. GET_TAX_DESCRIPTION returns formatted tax text suitable for printing on billing documents.
• Structure utilities: FN_TRX_HAS_GROUPS determines whether a transaction contains line groups, influencing template selection and loop structures; FN_GET_LINE_DESCRIPTION retrieves descriptive text for a billing line.
• Maintenance utilities: CREATE_DUP_AREAS and DELETE_FLEXFIELD_ITEMS perform administrative operations on content areas and descriptor flexfield items within the BPA configuration.

Parameter lists are not published in the ETRM excerpt and are not enumerated here; the names above are taken verbatim from the documented procedure inventory.

Tables Accessed

The package reads configuration and definition data held in the AR_BPA_* family. AR_BPA_CONTENT_AREAS_B, _S, and _TL hold the base, sequence, and translated definitions of document content areas; AR_BPA_AREA_ITEMS and AR_BPA_AREA_ITEMS_S hold the items assigned to those areas; AR_BPA_ITEMS_B, _S, _TL, and the AR_BPA_ITEMS_VL view hold the billing item definitions and their translations. AR_BPA_ITEMS_PKG is invoked to reach item logic rather than duplicating it.

Customer and contact data comes from the HZ tables: HZ_PARTIES, HZ_CONTACT_POINTS, HZ_CUST_ACCOUNT_ROLES, HZ_RELATIONSHIPS, HZ_CUSTOMER_PROFILES, and HZ_CUST_PROFILE_CLASSES, supporting the contact-name, phone, fax, and profile-class functions. Tax data comes from ZX_TAXES_VL, ZX_RATES_VL, and ZX_EXEMPTIONS, which supply the tax name, rate, code, and exemption determinations. Transaction data is read from RA_CUSTOMER_TRX and RA_CUSTOMER_TRX_LINES. AR_SYSTEM_PARAMETERS supplies system-level defaults, while FND_PROFILE, FND_LOOKUPS, and FND_LOG provide profile option values, lookup meanings, and debug logging.

Usage Notes

AR_BPA_UTILS_PKG is invoked internally by the three dependent packages and by the Receivables billing publishing flow rather than being called directly from standard Oracle EBS forms menus. It executes whenever a billing document is generated, supplying the derived attributes that templates consume. Because it reads many configuration and tax tables per call, extensions or custom content area definitions should be tested for performance impact. Custom code that calls these functions directly should treat the package as unsupported and pinned to the APPS schema, and must not rely on parameter signatures that are not published in the ETRM documentation.