Search Results oe_batch_pricing




Overview
Explore in AI Chat

Overview

OE_BATCH_PRICING is an Oracle E-Business Suite Order Management PL/SQL package owned by the APPS schema that provides a mechanism for repricing sales order lines in bulk rather than one order at a time. In Oracle EBS 12.1.1 and 12.2.2, pricing is normally triggered at order entry through the Order Management window, where the pricing engine derives list, selling, and adjusted prices for each line. OE_BATCH_PRICING complements that interactive flow by exposing a single callable entry point that accepts a broad set of selection criteria and applies the pricing engine across every matching order or line. This is the programmatic foundation behind the seeded concurrent program used to reprice orders when price lists, discounts, formulas, or qualifiers have changed after orders were originally booked or entered.

The package is classified in the ETRM repository as an "OTHER" API, meaning it is a supporting utility rather than a formally published open interface. Its source header (OEXBPRIS.pls, version 120.0.12010000.2) reflects the 12.1.x file lineage, and the package remains present and callable in 12.2.2.

Key Procedures and Functions

Only one procedure is documented in the package specification.

  • PRICE — The single public procedure. Its signature declares two standard concurrent-program OUT parameters, ERRBUF and RETCODE, followed by a substantial set of IN parameters that define both the mode of execution and the range of orders to be processed. Notable parameter groups include: a preview mode flag, a pricing level indicator, an operating unit (ORG_ID), order number low/high bounds, order type and line type identifiers, customer and address identifiers (ship-to, invoice-to, ship-from), customer class code, salesperson, price list, inventory item, and item category. A series of date-range parameters further constrain selection by order date, order creation date, line creation date, booked date, pricing date, and schedule ship date. Additional parameters allow the caller to restrict processing to booked orders and to target specific headers, a line count, or an explicit line list. Collectively these parameters let the procedure scope a repricing run narrowly (for example, a single header or item) or broadly across an operating unit.

Tables Accessed

The documented tables reflect the pricing engine's need to resolve parties, item categorization, transaction type, and the orders themselves.

  • OE_ORDER_HEADERS and OE_ORDER_LINES — the primary order data read for selection and written with recalculated prices.
  • OE_TRANSACTION_TYPES_TL — supplies translated order and line transaction type information used to interpret the type identifiers passed in.
  • HZ_CUST_ACCOUNTS and HZ_PARTIES — the Trading Community Architecture tables that identify the customer and party behind an order, supporting customer and customer-class based selection and pricing qualifiers.
  • MTL_ITEM_CATEGORIES, MTL_DEFAULT_CATEGORY_SETS, and the category set references — resolve item category assignments, which feed category-based pricing criteria.
  • DUAL and PLITBLM — general-purpose utility references; PLITBLM is a standard EBS helper used for numeric and string list manipulation.

Usage Notes

OE_BATCH_PRICING is typically invoked in three ways. First, through the seeded Order Management concurrent program for batch repricing, which supplies the ERRBUF/RETCODE contract and passes the selection criteria from the concurrent program request form. Second, from custom PL/SQL or concurrent-program wrappers in implementations that need to reprice orders as part of a data fix, a post-import operation, or a scheduled maintenance job. Third, indirectly during upgrade and patching activities where order prices must be reconciled after pricing setup changes.

Because the procedure writes to OE_ORDER_HEADERS and OE_ORDER_LINES, it should be run within the correct operating unit context and during controlled windows, and callers should honor preview mode when available to validate selection scope before committing updates. As the package is classified as a non-published API, direct calls carry the usual caveat of unsupported customization, and organizations should test behavior carefully across 12.1.1 and 12.2.2, where the underlying pricing engine and Multi-Org access behavior differ.