Search Results create_linelevel_adjustment

Overview

AR_ADJUST_PUB is the public application programming interface for creating, modifying, approving, and reversing adjustments against Oracle Receivables transactions. An adjustment represents a change to the amount owed on a transaction — for example a write-off, a credit, a debit memo, or a chargeback-related correction — and it directly affects the customer's open balance and the corresponding payment schedules. The package encapsulates the validation, approval-limit checking, and persistence logic required to perform these operations in a controlled and auditable manner, allowing both Oracle Forms and external or custom code to manipulate adjustments without bypassing Receivables business rules.

The package body begins with a standard FND message-level declaration block and a private validation routine, Validate_Adj_Insert, which performs the input checks used during adjustment creation. This private helper invokes a series of routines in the AR_ADJVALIDATE_PVT package to validate adjustment type, payment schedule, amount, receivables transaction CCID, dates, reason code, document sequence, associated receipt, USSGL code, descriptive flexfield, and creation source, while also honoring approval-limit and amount-checking flags. The API is part of the AR (Receivables) product family and is owned by APPS.

Key Procedures and Functions

The ETRM 12.2.2 metadata documents five public procedures and functions in APPS.AR_ADJUST_PUB:

• CREATE_ADJUSTMENT — Creates a new adjustment against a Receivables transaction. It validates the supplied adjustment record, applies approval-limit and amount checks as requested, and inserts the resulting adjustment and its activity trail.
• MODIFY_ADJUSTMENT — Updates an existing adjustment. It re-validates the changed attributes and persists the modification, keeping the adjustment and related balances consistent.
• REVERSE_ADJUSTMENT — Reverses a previously applied adjustment, restoring the transaction's balance to the state before the original adjustment was made. This is the procedure most directly associated with the search term "reverse_adjustment," which users commonly use to locate the adjustment-reversal capability in this package.
• APPROVE_ADJUSTMENT — Applies the approval action to an adjustment that requires authorization, typically after automated or manual approval-limit evaluation.
• CREATE_LINELEVEL_ADJUSTMENT — Creates an adjustment at the transaction line level, supporting line-level correction and adjustment scenarios that differ from header-level adjustments.

Tables Accessed

The package operates against the core Receivables tables, accessed through APPS synonyms:

• AR_ADJUSTMENTS — The primary adjustment table, holding the inserted, modified, or reversed adjustment records.
• AR_PAYMENT_SCHEDULES — Stores the installment and balance information that adjustments affect, and which must remain reconciled with the adjustment.
• AR_RECEIVABLE_APPLICATIONS — Records application activity, including adjustments applied against transactions.
• AR_ACTIVITY_DETAILS — Captures the activity audit trail generated when adjustments are created, changed, or reversed.
• AR_LLCA_ADJ_TRX_LINES_GT and AR_LLCA_ADJ_TRX_ERRORS_GT — Global temporary tables used by the line-level adjustment processing to hold transaction lines and any validation errors encountered.
• PLITBLM and V$TIMER — Supporting utility objects used for PL/SQL table handling and timing/measurement during processing.

Usage Notes

AR_ADJUST_PUB is normally invoked rather than called directly by end users. It is referenced by approximately nine other packages and is typically driven from Receivables forms such as the Adjustments and Transactions windows, from concurrent programs that process or approve adjustments in bulk, and from custom extensions that need to create, approve, or reverse adjustments programmatically. When integrating, the API follows standard Oracle EBS API conventions: callers should invoke the procedures within a properly initialized FND message environment, check the returned status, and handle the resulting error messages. Because the package writes to AR_ADJUSTMENTS and AR_PAYMENT_SCHEDULES and records activity details, custom code should not update those tables directly; the public API is the supported route for all adjustment-related data changes, including reversals.