Search Results update_header_cover




Overview
Explore in AI Chat

Overview

ARP_PROCESS_CREDIT_UPD_COVER is a covered PL/SQL package body owned by the APPS schema within the Oracle E-Business Suite Receivables (AR) module. Its name reflects its role in the credit transaction processing path: it provides a wrapper (or "cover") routine that centralizes the update logic applied to the header-level attributes of a credit memo or credit transaction. The package exists to decouple the transactional forms layer from direct Data Manipulation Language (DML) against the core Receivables transaction tables. By exposing a single, well-typed entry point, Oracle standardizes how header changes are validated, propagated, and persisted whenever a credit transaction is created or modified through the Receivables transaction workbench. The "cover" designation indicates that it is a helper or interface package rather than a standalone business transaction API; callers pass the already-resolved transaction identifiers, dates, currency information, and party/address references, and the package performs the header update in a controlled manner. As APPS-owned code, it may be modified only through Oracle-provided patching, since direct alteration invalidates the support agreement and can affect upgrade pathing from 12.1.1 to 12.2.2.

Key Procedures and Functions

The ETRM metadata documents exactly one program unit within this package body:

  • UPDATE_HEADER_COVER — the sole documented procedure. Consistent with the "update_header_cover" search term, this routine is responsible for applying header-level changes to a customer transaction. Based on the parameter set visible in the source excerpt, it accepts the transaction identity context (p_customer_trx_id, p_trx_number, p_prev_customer_trx_id, p_initial_customer_trx_id), the transaction attributes to be updated (transaction date, GL date, completion flag, batch and batch source, transaction type, invoicing rule, credit method for rules, split term method, primary sales representative), currency and exchange information (p_currency_code, exchange date, exchange rate type, exchange rate), and the bill-to and ship-to party, address, site-use, and contact identifiers. It also receives form context parameters (p_form_name, p_form_version) that allow the procedure to behave appropriately depending on the calling form. No parameter list is invented here; the description is limited to the parameters evidenced in the documented source excerpt.

No public functions or additional procedures are documented for this package. The metadata records an API classification of OTHER, indicating that this is not a published, externally supported API in the Receivables open interface family but an internal cover routine.

Tables Accessed

The package interacts with the following tables through APPS synonyms:

  • RA_CUSTOMER_TRX — the primary target of the header update; holds the credit transaction header record being modified.
  • RA_CUST_TRX_LINE_GL_DIST — the distribution table whose GL date is supplied and potentially adjusted as part of the header update.
  • RA_BATCHES — provides batch context for the transaction being reparented or reassigned.
  • RA_BATCH_SOURCES — supplies batch source validation and defaulting logic.
  • RA_CUST_TRX_TYPES — used to validate the transaction type and derive type-dependent behavior.
  • RA_CUSTOMER_TRX_LINES — referenced for line-level consistency when header changes affect downstream lines.
  • FND_CURRENCIES — used to validate the currency code and exchange rate context.

These tables represent the core header, line, distribution, and reference data footprint of a Receivables transaction, confirming the procedure's role in maintaining header integrity.

Usage Notes

ARP_PROCESS_CREDIT_UPD_COVER is invoked indirectly. The zero inbound references reported in the metadata indicate that no other PL/SQL package calls it directly; instead, it is reached from Oracle Forms event logic in the Receivables transaction forms, where a user action triggers the header update. When extending functionality, developers should not call this cover package from custom code, because it is internal and unsupported. The supported integration points for credit transactions remain the Receivables AutoInvoice interface and the documented Customer Transaction APIs. For 12.1.1 and 12.2.2, this object ships as part of the AR patching stream; any customization should be applied through form personalization or table-level extensions rather than modification of the package body itself, and callers must ensure the required transaction and currency context is resolved before invocation.