Search Results print_fcn_label




Overview

ARP_MAINTAIN_PS is a private PL/SQL package body owned by APPS that provides the core maintenance logic for Oracle Receivables payment schedules. In Oracle EBS 12.1.1 and 12.2.2, a payment schedule represents the installment-level detail of a receivable: the individual due dates, amounts, and statuses derived from a transaction line. The package encapsulates the programmatic creation, update, and adjustment of that schedule data so that other Receivables modules—autoaccounting, credit memo processing, and transaction entry—can manipulate schedules without directly issuing DML against the underlying tables.

The body carries the standard EBS header marker (ARTEMPSB.pls) and derives its runtime constants and shared record types from arp_global and arp_trx_global, including the system_info and profile_info records passed through most entry points. Debug output is governed by the AFLOG_ENABLED profile option, so developers can enable diagnostic tracing without modifying the package. Internally the package declares a control_rec_type record that carries the process mode, customer transaction identifier, payment schedule identifier, line amount, and tax amount across its internal calls, and defines user exceptions such as invalid_parameters and invalid_mode for defensive error handling.

Key Procedures and Functions

  • INIT — Initialization routine that prepares package-level state, including the translated error messages and shared records, before other entry points execute.
  • MAINTAIN_PAYMENT_SCHEDULES — The primary public entry point. It applies the requested insert, update, or delete action to payment schedule rows for a given transaction, using the control record to carry the process mode and amounts.
  • TEST_BUILD_DOC_COMBO_SQL — Test/diagnostic helper that constructs the dynamic SQL used to validate document sequence combinations.
  • TEST_BUILD_DOC_UPDATE_ADJ_SQL — Test helper that builds the dynamic SQL for updating adjustment document numbers.
  • TEST_BUILD_DOC_INS_AUDIT_SQL — Test helper that builds the dynamic SQL for inserting adjustment audit records.
  • TEST_UPDATE_ADJ_DOC_NUMBER — Test entry point that exercises the adjustment document-number update path, primarily used to validate dynamic SQL generation without committing production data.

The TEST_* routines exist to support the adjustment document numbering logic that backs the MAINTAIN_PAYMENT_SCHEDULES flow; they are not intended for production invocation.

Tables Accessed

The package references AR_PAYMENT_SCHEDULES, the central table it maintains, together with AR_ADJUSTMENTS, AR_ADJUSTMENTS_S, and AR_ADJUSTMENT_NUMBER_S for adjustment creation and document numbering. It reads RA_CUSTOMER_TRX and RA_CUSTOMER_TRX_LINES to resolve transaction and line context, RA_CUST_TRX_TYPES to determine transaction class behavior, and AR_SYSTEM_PARAMETERS for system-level defaults. AR_DISTRIBUTIONS and AR_RECEIVABLE_APPLICATIONS are touched to keep accounting distributions and application records consistent with schedule changes. The Subledger Accounting tables XLA_EVENTS and XLA_TRANSACTION_ENTITIES are referenced so that schedule modifications generate the appropriate accounting events. DBMS_SQL is used for the dynamic SQL paths described above, and DUAL supports simple scalar lookups. All access occurs through APPS synonyms.

Usage Notes

ARP_MAINTAIN_PS is normally invoked indirectly, called by other Receivables packages—ETRM lists four dependent packages—rather than from a form or concurrent program directly. Its most common callers are autoaccounting and credit memo routines that must regenerate or adjust payment schedules as transactions are created, updated, or adjusted. Custom code should invoke only the supported public entry point, MAINTAIN_PAYMENT_SCHEDULES, after populating the system_info and profile_info records through arp_trx_global, and should not call the TEST_* procedures outside a development environment. Because the package performs subledger accounting event generation, any custom invocation must respect the standard API transaction boundaries and commit points used by Receivables.