Search Results get_group_id




Overview

AR_LL_RCV_GROUPING_HOOK is a hook package in the Oracle Receivables (AR) module that supports the grouping of receipt-related transactions in the context of the Latin American (LL) localization. The package forms part of the extensibility framework that Oracle E-Business Suite provides for localization-specific processing, allowing Receivables to associate customer transactions with grouping identifiers used during receipt application and reconciliation. The package spec header indicates a "noship" designation, meaning the package is delivered as part of the application schema but is not intended for direct invocation by end users; it is instead called by Oracle's internal localization logic or by customer extensions that follow the documented interface.

The package exposes a small, focused API surface. Its purpose centers on maintaining the linkage between source document keys stored on Receivables transactions and the grouping identifiers that downstream localization processes rely upon. This design supports the requirement that transactions sharing a common grouping key be retrievable and processable as a set, which is important in Latin American fiscal and legal reporting contexts where transactions must be grouped for reporting or for compliance with local numbering and document requirements.

Key Procedures and Functions

  • UPDATE_SOURCE_DATA_KEYS — A procedure that updates source data keys associated with a customer transaction. It accepts a customer transaction identifier as its input and is used to synchronize or refresh the grouping-related key values stored for that transaction. This is the only write-oriented routine in the package interface.
  • GET_GROUP_ID — A function that returns a numeric grouping identifier corresponding to a supplied pair of source data key values. This is the routine most commonly referenced by searches such as "get_group_id," because it provides the mapping from source document keys to the grouping ID used elsewhere in the localization flow.
  • GET_GROUP_NAME — A function that returns the descriptive name of the group associated with a pair of source data key values. It complements GET_GROUP_ID by supplying a human-readable grouping label, useful for display or reporting purposes.

The package signature is deliberately minimal: the two getter functions take a pair of source data key parameters, and the update procedure takes a transaction identifier. This reflects an intentionally narrow contract intended for hook-based extension rather than broad application use.

Tables Accessed

The documented table reference for this package is RA_CUSTOMER_TRX_LINES, accessed through APPS synonyms. RA_CUSTOMER_TRX_LINES stores the individual line records belonging to customer transactions in Receivables. The package reads from and, in the case of UPDATE_SOURCE_DATA_KEYS, potentially writes to these lines in order to maintain the grouping-related key data that the getter functions subsequently resolve. Given that grouping is tied to transaction lines rather than headers alone, this table is the natural source for the source data keys that parameterize GET_GROUP_ID and GET_GROUP_NAME.

Usage Notes

Because AR_LL_RCV_GROUPING_HOOK is a hook package, it is not designed for direct invocation from standard Oracle Receivables forms. Instead, it is typically called from localization-specific processing logic within Receivables, from concurrent programs that process grouped transactions, or from customer-written extensions that must conform to the same grouping conventions as the delivered localization. The package carries no recorded dependencies from other packages in the documented metadata, indicating a leaf-level utility whose contract is stable and whose callers are external to its own schema definition.

Developers working with the "get_group_id" query should treat GET_GROUP_ID as the authoritative lookup from source document keys to grouping identifier, and should reserve UPDATE_SOURCE_DATA_KEYS for controlled synchronization scenarios rather than routine transaction processing. Since the package is marked noship, any customization should be implemented as a wrapper or extension rather than by modifying the package body, ensuring upgrade safety across the 12.1.1 and 12.2.2 releases.