Search Results get_next_value

Overview

GMO_DOCUMENT_NUMBERS_GRP is the group-level (GRP) API layer of the Oracle E-Business Suite Process Manufacturing document numbering facility. It belongs to the GMO product family, which supports Oracle Quality and Process Manufacturing (OPM) document control, and resides in the APPS schema. In Oracle EBS 12.1.1 and 12.2.2, the GRP layer follows the standard three-tier PL/SQL architecture: a private (PVT) package performs the substantive logic, a group (GRP) package exposes a thin, message-aware public interface, and a user-facing API or form calls the group layer. This package therefore provides the supported entry point through which callers obtain, generate, and validate document numbers assigned to process manufacturing documents such as quality specifications, recipes, batch records, and related controlled documents.

The header revision ($Header: GMOGDNMB.pls 120.3 2006/01/19 09:27 swasubra noship $) indicates the package body has been stable since the 11i era and is unchanged in the 12.x code lines, making it a legacy but still supported component invoked by internal OPM flows.

Key Procedures and Functions

The package exposes three documented routines:

• GET_DOCUMENT_NUMBER_TYPE — Resolves the document number type associated with a given organization and transaction type. As shown in the source excerpt, it validates the API version through FND_API.COMPATIBLE_API_CALL, optionally initializes the message list via FND_MSG_PUB.INITIALIZE, delegates to the private routine GMO_DOCUMENT_NUMBERS_PVT.GET_DOCUMENT_NUMBER_TYPE, and then retrieves any accumulated messages using FND_MSG_PUB.COUNT_AND_GET. It follows the standard EBS API error-handling pattern, trapping FND_API.G_EXC_UNEXPECTED_ERROR, setting X_RETURN_STATUS to FND_API.G_RET_STS_UNEXP_ERROR, and logging unexpected conditions through FND_LOG.MESSAGE at FND_LOG.LEVEL_UNEXPECTED.
• GET_NEXT_VALUE — The routine most frequently sought by developers. It returns the next available document number from the numbering scheme configured for the applicable organization and transaction context. This is the procedural equivalent of requesting a sequence value for a user-defined document numbering rule.
• DOES_DOCUMENT_NUMBER_EXIST — A validation routine that verifies whether a proposed or existing document number already exists within the numbering scheme, supporting duplicate prevention and manual entry validation.

Consistent with EBS API conventions, each routine is expected to return the standard X_RETURN_STATUS, X_MSG_COUNT, and X_MSG_DATA out parameters, although parameter lists should be confirmed against the deployed source rather than assumed.

Tables Accessed

The ETRM metadata for this package lists no directly referenced tables via APPS synonyms. This is expected: GMO_DOCUMENT_NUMBERS_GRP is a pure delegation layer and performs no SQL of its own. All table access—typically the OPM document numbering setup and document number assignment tables queried by GET_NEXT_VALUE and DOES_DOCUMENT_NUMBER_EXIST—occurs inside the private package GMO_DOCUMENT_NUMBERS_PVT that this group layer wraps. Any dependency analysis or impact assessment should therefore target the private package and the numbering setup tables it maintains.

Usage Notes

This package is invoked through the Oracle Forms UI when users create or manually key process manufacturing documents requiring controlled numbering, and by concurrent programs, workflows, and custom PL/SQL that need to obtain or validate a document number programmatically. It is referenced by at least one other package in the ETRM inventory, reflecting reuse across OPM application modules.

Developers integrating with this package should call the GRP routines rather than the PVT routines, initialize the message list where appropriate, and always inspect X_RETURN_STATUS before consuming returned values. Because the body has remained at version 120.3 across 12.1.1 and 12.2.2, customizations built against it remain portable between both releases, though the standard EBS recommendation to avoid direct modification of APPS-owned code continues to apply.