Search Results commit_row

Overview

INV_KANBANCARD_PKG is a PL/SQL package in the Oracle E-Business Suite Inventory (INV) module that encapsulates the core create, read, update, and delete logic for Kanban cards stored in the MTL_KANBAN_CARDS entity. Kanban cards represent replenishment signals used by pull-based (Kanban) manufacturing and distribution processes, where material movement is driven by consumption rather than by a scheduled push plan. The package centralizes validation, attribute handling, status transitions, and activity logging so that forms, concurrent programs, and other PL/SQL APIs manipulate Kanban card data through a single, controlled interface rather than by issuing direct DML against the underlying tables.

The package is declared with AUTHID CURRENT_USER, meaning that name resolution and privilege checking occur in the schema of the calling session (typically APPS). It was originally authored under the header INVKCRDS.pls, and the documented version 115.6 dates to 2003, indicating the interface has been stable across the 11i through 12.2 releases. It is documented in ETRM 12.2.2 with an API classification of OTHER, and is referenced by ten other packages, confirming it is a foundational building block in the Kanban card API layer.

Key Procedures and Functions

The package exposes both private utility routines and public DML procedures. The most commonly referenced routines include:

• CHECK_UNIQUE — a function that verifies a Kanban card number is unique within the specified organization, preventing duplicate card identifiers before an insert.
• SUPPLY_STATUS_CHANGE_OK — a function that validates whether a requested transition between supply statuses (and card status) is permitted, enforcing the Kanban status model.
• QUERY_ROW — a function returning a fully populated Kanban_Card_Rec_Type record from INV_Kanban_PVT for a given card ID.
• INSERT_ROW — inserts a new Kanban card, accepting the full attribute set (card number, item, organization, subinventory, supply status, source type, supplier, WIP line, document references, and descriptive flexfield attributes).
• UPDATE_ROW and UPDATE_CARD_STATUS — modify existing card data, with the latter specifically handling card status transitions.
• DELETE_ROW, DELETE_CARDS_FOR_PULL_SEQ — remove individual cards or all cards associated with a pull sequence.
• INSERT_ACTIVITY_FOR_CARD, DELETE_ACTIVITY_FOR_CARD, DELETE_ACTIVITY_FOR_PULL_SEQ — maintain the Kanban card activity/audit history.
• LOCK_ROW — acquires a row-level lock to serialize concurrent modifications.
• COMMIT_ROW and ROLLBACK_ROW — the routines surfaced by the search term "commit_row"; COMMIT_ROW issues a database commit on the current transaction while ROLLBACK_ROW discards it, giving callers explicit transaction control at the row level.

Tables Accessed

The package operates on the following documented tables via APPS synonyms:

• MTL_KANBAN_CARDS — the primary table holding Kanban card records; the target of INSERT_ROW, UPDATE_ROW, and DELETE_ROW.
• MTL_KANBAN_CARDS_S — the corresponding audit/shadow table populated when the INV:Audit Kanban Cards profile option is enabled.
• MTL_KANBAN_CARD_ACTIVITY — records the transaction history of each card (replenishment, consumption, status change).
• MTL_KANBAN_CARD_ACTIVITY_S — the audit counterpart to the activity table.
• DUAL — used for single-row validation and sequencing checks.

Usage Notes

INV_KANBANCARD_PKG is normally invoked indirectly through the Kanban Workbench and Kanban Card forms, and through concurrent programs that generate or replenish cards. The presence of COMMIT_ROW and ROLLBACK_ROW indicates that callers, rather than the package itself, control the transaction boundary: a calling form or program performs a sequence of DML operations and then explicitly commits or rolls back. Because the package is referenced by ten other packages, custom extensions should call these routines rather than issuing direct SQL, and should honor the expected commit/rollback semantics to avoid leaving open transactions. The package is unchanged in behavior between 12.1.1 and 12.2.2, so the same integration guidance applies to both releases.