Search Results print_label

Overview

INV_LABEL_PUB is a public PL/SQL package in the Oracle Inventory (INV) application that provides the supported API interface for printing item and transaction labels within Oracle E-Business Suite. The package serves as the publication layer over the internal INV_LABEL package, exposing a stable, FND_API-compliant entry point that shields callers from the underlying implementation in INV_LABEL. The body is owned by APPS and carries the source header tag INVPLABB.pls (version 120.1, dated 2005/06/20), indicating that the logic has been stabilized since the 11i era while remaining valid through 12.1.1 and 12.2.2. A notable structural feature is that INV_LABEL_PUB accepts a collection of transaction identifiers and iterates over them, delegating each element to the underlying INV_LABEL.print_label routine. This design allows a caller with multiple label requests—such as a receipt, move order, or shipment covering several transaction lines—to obtain all corresponding labels in a single API invocation. The procedure returns both the standard FND_API messaging outputs (return status, message count, message data) and a label-specific status output that reports the outcome of the label print request itself.

Key Procedures and Functions

The ETRM metadata documents a single public procedure, PRINT_LABEL, in this package body.

• PRINT_LABEL — The public entry point for submitting inventory label print requests. It accepts the standard FND_API parameter set (API version, initialization of the message list, and commit control) together with label-specific inputs identifying the business flow and the transaction(s) to be printed. It returns a return status, message count, message data, and a dedicated label status that indicates the disposition of the print request for the supplied transactions. Internally, the procedure initializes the return status to success, then loops over the incoming transaction identifier collection, invoking INV_LABEL.print_label once per element with a print mode of 1 and passing through the business flow code and transaction identifier. The outputs from the inner call are propagated back to the caller on each iteration.

The signature incorporates NOCOPY on the OUT parameters, a performance refinement introduced under Bug# 4380449 to avoid copying large VARCHAR2 and NUMBER outputs. The collection element type and the default null record used for the transaction identifier parameter are declared within the package specification, allowing callers to construct multi-transaction requests in a single call.

Tables Accessed

ETRM documents a single table reference, accessed through an APPS synonym:

• PLITBLM — The label printing table used by the underlying INV_LABEL logic. When INV_LABEL_PUB invokes INV_LABEL.print_label, the request is recorded and processed against PLITBLM, which holds the pending label print rows. The public package does no direct DML of its own; all data manipulation occurs inside the inner INV_LABEL call, so PLITBLM is the effective persistent store for the label print request lifecycle.

Usage Notes

INV_LABEL_PUB is the recommended integration point for any external or custom code that needs to trigger inventory label printing, because it is classified as a PUB (public) API, whereas INV_LABEL is the internal, unsupported implementation. ETRM records that the package is referenced by two other packages, confirming its role as a shared dependency within the Inventory module rather than a leaf utility.

Typical invocation scenarios include label printing from Oracle Forms transaction windows (for example, receiving, move order, and shipping flows), from concurrent programs that batch-print labels for large transaction sets, and from custom PL/SQL that processes inventory transactions programmatically. Because the procedure accepts a collection of transaction identifiers, a caller printing labels for many lines should populate the collection and make one call rather than looping in application code; the package performs the iteration internally. Callers should observe standard FND_API conventions: check x_return_status against FND_API.G_RET_STS_SUCCESS, inspect x_label_status separately for the print outcome, and invoke FND_MSG_PUB.initialize_msg_list or loop over the returned messages as appropriate when p_init_msg_list is set to fnd_api.g_true. The NOCOPY OUT parameters mean callers must not assume the previous contents of those variables survive the call.