Search Results notify_customer




Overview

The concurrent program NOTIFY_CUSTOMER is a standard Oracle E-Business Suite component owned by the IEX – Collections module. It is exposed to users under the user-facing name IEX: Notify Customer and carries the description "Notify customer of intent to report." The program is enabled by default in both Oracle EBS 12.1.1 and 12.2.2 and is classified as an Oracle Proprietary, Confidential Information object within the ETRM reference documentation.

Functionally, the program supports the collections and credit management lifecycle by generating outbound notification of a customer's intent to be reported — for example, to a credit bureau or a similar external reporting agency — when delinquent receivables remain unresolved. It forms part of the automated dunning and escalation framework that collections agents use to apply consistent pressure on overdue accounts without manual intervention. The notification is produced on behalf of the operating unit and customer identified by the submission arguments, and it is intended to precede or accompany formal reporting actions.

Execution Details

The ETRM metadata documents the following execution characteristics:

  • Executable: NOTIFY_CUSTOMER
  • User Name: IEX: Notify Customer
  • Execution Method: PL/SQL Stored Procedure
  • Argument Method: Standard
  • Execution Filename: iex_open_interface_pub.notify_customer
  • Subroutine Name: (not specified)
  • Enabled: Yes

Because the execution method is a PL/SQL Stored Procedure, the runtime entry point is the packaged procedure iex_open_interface_pub.notify_customer. This places the program within the IEX public API layer, which is a common design pattern in Collections for logic that can also be invoked programmatically. The Standard argument method indicates that the program accepts ordinary concurrent program parameters rather than a single structured or special argument type.

How to Run

Users submit IEX: Notify Customer through the standard Submit Request (SRS) window, typically from the Collections responsibility or from a collections-specific workbench where dunning and reporting actions are grouped. Because the metadata records only the Standard argument method and does not enumerate parameter definitions, the exact parameter list should be verified in the target instance's Concurrent Programs form. In practice, submissions of this program generally require selections such as the operating unit or business unit, the customer or account identifier, and a reporting or notification date. Administrators should confirm the active parameter set before scheduling the request, since parameter availability can vary by configuration and patch level.

The program can be run on demand by a collections agent or scheduled as part of a recurring dunning cycle. When scheduled, it is advisable to align the run frequency with the collections strategy so that intent-to-report notices are issued consistently and only for accounts meeting the defined delinquency criteria. Output is directed to the standard concurrent request output and log files, where the generated notification content or a processing summary is recorded for audit purposes.

Related Objects

The program is delivered within the IEX Collections schema and shares the iex_open_interface_pub package with other open-interface processing routines. Related objects commonly encountered alongside it include the IEX Collections open interface tables used to stage customer and account data, the Collections dunning and strategy components that determine when notification is warranted, and standard IEX reports that summarize collections activity and delinquency status. Because the program executes a public API procedure, integration points that call iex_open_interface_pub directly will produce the same underlying business behavior as the concurrent submission.