Search Results update_br_assignment




Overview

AR_BILLS_CREATION_PUB is a public PL/SQL package in the Oracle E-Business Suite Receivables (AR) module that provides the core application programming interface for creating and maintaining Bills Receivable records. In Oracle EBS 12.1.1 and 12.2.2, Bills Receivable represent a customer's formal, negotiable promise to pay an outstanding receivable balance, and the package encapsulates the business logic required to generate, revise, and retire these instruments at the header, assignment, and transaction-extension levels.

The package body carries the version identifier ARBRCREB.pls 120.11, and its internal global constants define the standard Bills Receivable statuses (INCOMPLETE, PENDING_ACCEPTANCE, CANCELLED) together with the DELETE action constant and the standard FND_MSG_PUB message-level flags used across EBS public APIs. As a PUB-classified package, it is intended for external invocation and follows Oracle's standard API conventions, including the FND_API parameters p_api_version, p_init_msg_list, p_commit, and p_validation_level.

Key Procedures and Functions

The package exposes twelve documented entry points organized around three functional areas.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

  • AR_PAYMENT_SCHEDULES — The central Receivables table holding payment schedule and BR status information.
  • AR_RECEIPT_METHODS — Supplies receipt method validation and defaulting for BR creation.
  • AR_TRANSACTION_HISTORY — Records audit and status-change history for the BR lifecycle.
  • RA_CUSTOMER_TRX — The customer transaction header against which Bills Receivable are originated.
  • RA_CUSTOMER_TRX_LINES — Transaction lines that supply the receivable amounts assigned to a BR.

Usage Notes

AR_BILLS_CREATION_PUB is typically invoked by Receivables forms, concurrent programs, and custom PL/SQL code that need to create or maintain Bills Receivable programmatically. Callers should supply a valid p_api_version, optionally request message-list initialization, and decide whether the API performs its own commit via p_commit or leaves transaction control to the caller. The LOCK procedures should be used in multi-user or batch scenarios to prevent concurrent modification of the same BR header or assignment. Because the package is a published API, direct DML against its underlying tables should be avoided; integration and extension points should call these documented procedures instead to preserve validation and audit integrity. The package is referenced by three other packages, indicating a degree of internal dependency within the Receivables codebase. Environments running 12.1.1 and 12.2.2 should verify the installed ARBRCREB.pls version to confirm behavioral consistency.