Search Results get_customer_id

Overview

ASP_INVOICE_ALERT_AGENT is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its documented purpose is to evaluate invoice-related alert conditions and to resolve the set of subscribers that should receive notifications for those alerts. The package was created on 10-Aug-2005 (header revision 120.5, source file aspadiab.pls, noship designation) and is classified as an "OTHER" API rather than a public interface, meaning it is intended for internal use by the alerting framework rather than for direct customer invocation.

Functionally, the package sits in the notification layer of the Oracle Advanced Pricing / Receivables alerting infrastructure. Alerts in EBS are condition-driven: a monitored event or query result triggers evaluation, and if the condition evaluates true, the alerting engine must determine who is subscribed to receive the message. ASP_INVOICE_ALERT_AGENT encapsulates that subscriber-resolution logic for invoice alerts, supporting the SMS and EMAIL delivery channels.

Key Procedures and Functions

The ETRM metadata documents exactly one public routine for this package:

• EVALUATE_ALERTS — The single documented procedure. Per the source comment, it "finds all the subscribers of this alert for SMS and EMAIL Channels." It evaluates the alert condition and returns or processes the subscriber list for both notification channels. No parameter list is documented and none should be assumed; the specification (package header) is the authoritative source for its signature.

All other content in the body is private: constants identifying the package name and source file, and private datatype and variable declaration sections. No private routines are documented in the excerpt. Because the package is classified as OTHER and referenced by zero other packages, EVALUATE_ALERTS is not a dependency of any other PL/SQL unit in the documented EBS schema graph.

Tables Accessed

The package reads the following tables through APPS synonyms:

• AR_PAYMENT_SCHEDULES_ALL — The Receivables payment schedule table. This is the core invoice data source: payment schedules hold invoice amounts, due dates, aging buckets, and status, which are the natural inputs to an invoice alert condition.
• HZ_CUST_ACCOUNTS_ALL — The Trading Community Architecture customer account table. Used to resolve the customer account associated with the invoice and to drive subscriber lookup.
• HZ_PARTIES — The TCA party table, holding the underlying person or organization entity. Joined with HZ_CUST_ACCOUNTS_ALL to reach party-level contact information used for EMAIL and SMS delivery.
• PLITBLM — The standard EBS PL/SQL table-type index-by-table (character-string) definition used throughout Oracle Forms and PL/SQL for in-memory collections. It is not a business table; it supports the package's internal array handling, likely for accumulating subscriber or recipient lists.

No inserts or updates to these tables are documented; the package is a read-oriented evaluator.

Usage Notes

Given its name and structure, the package is invoked by the Oracle Alert Manager framework when an invoice alert fires, rather than being called directly from a form or concurrent program. The typical invocation path is a scheduled alert (concurrent program) or an event-driven alert in the Alert Manager, which calls the agent package to resolve recipients before dispatching EMAIL and SMS messages.

The "get_customer_id" search term that led to this object reflects the most common reason an EBS developer inspects this body: locating where a customer identifier is derived from an invoice or payment schedule. In this package, that derivation would occur inside EVALUATE_ALERTS, using AR_PAYMENT_SCHEDULES_ALL joined to HZ_CUST_ACCOUNTS_ALL and HZ_PARTIES. Developers extending or debugging invoice alerting should treat ASP_INVOICE_ALERT_AGENT as internal, non-shipped API: the noship designation in the header indicates it is not a supported extension point, and the absence of documented parameters means any wrapper code must rely on the package specification rather than this body. Custom code should not call it directly; instead, subscription and alert definitions should be maintained through the Alert Manager setup, letting the framework invoke the agent on the code's behalf.