Search Results mtl_kanban_cards_s

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

INV_KANBANCARD_PKG is a server-side PL/SQL package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It provides the core data-maintenance layer for Oracle Inventory kanban card records and their associated activity history. Kanban cards represent replenishment signals used within a pull-based manufacturing or distribution environment; each card corresponds to a container, bin, or supply location and carries a status that drives replenishment demand. This package encapsulates the row-level operations — querying, locking, inserting, updating, and deleting kanban card and card activity rows — so that the Kanban Workbench, the kanban replenishment concurrent processes, and the kanban public APIs do not have to embed direct SQL against the underlying transaction tables.

The package is classified as an OTHER API in the ETRM documentation. It is a low-level persistence package rather than a self-contained business API: the higher-level validation and business rules reside in INV_KANBAN_PVT, which INV_KANBANCARD_PKG references. Consistency with Oracle's application framework is achieved through dependencies on FND_API, FND_MESSAGE, FND_MSG_PUB, FND_GLOBAL, and APP_EXCEPTION, providing the standard message-stack and exception-handling conventions used throughout the Inventory application.

Key Procedures and Functions

Sixteen procedures and functions are documented for this package. The DML-oriented routines operate on a single row at a time and follow the conventional Application Object Library pattern:

• CHECK_UNIQUE — validates that a kanban card definition does not duplicate an existing card, supporting the uniqueness rules applied at card creation.
• QUERY_ROW — retrieves an existing kanban card row, typically into a record structure used by the calling form or API.
• LOCK_ROW — acquires a row-level lock on a kanban card in preparation for update or delete, preventing concurrent modification.
• INSERT_ROW — creates a new kanban card record in the base table.
• UPDATE_ROW — applies changes to an existing kanban card record.
• UPDATE_CARD_STATUS — changes the status of a kanban card; this is the operative step when a card is activated, emptied, or otherwise transitioned through its life cycle.
• DELETE_ROW — removes a single kanban card record.
• COMMIT_ROW / ROLLBACK_ROW — provide transaction boundary control for the row-level operations, allowing callers to commit or abandon a unit of work consistently.
• SUPPLY_STATUS_CHANGE_OK — evaluates whether a proposed supply status transition is permitted before the change is applied.
• DELETE_CARDS_FOR_PULL_SEQ — deletes all kanban cards belonging to a specified pull sequence, used when a pull sequence is removed or reorganized.
• INSERT_ACTIVITY_FOR_CARD — inserts an activity record documenting a card event in the card activity table.
• DELETE_ACTIVITY_FOR_CARD — deletes activity history for a single card.
• DELETE_ACTIVITY_FOR_PULL_SEQ — deletes activity history associated with a pull sequence.

Tables Accessed

The package reads and writes the four documented Inventory tables through APPS synonyms. MTL_KANBAN_CARDS and its companion _S table hold the master kanban card definitions and their attribute-level storage; these are the primary targets of INSERT_ROW, UPDATE_ROW, UPDATE_CARD_STATUS, DELETE_ROW, and the pull-sequence deletion routine. MTL_KANBAN_CARD_ACTIVITY and MTL_KANBAN_CARD_ACTIVITY_S store the historical activity records generated as cards change status or are replenished; the activity insertion and deletion routines write to these tables. DUAL is referenced for scalar evaluation within PL/SQL, and MFG_LOOKUPS supplies lookup-code validation for status and related code values.

Usage Notes

INV_KANBANCARD_PKG is typically invoked indirectly. The Kanban Workbench and related Inventory forms call into INV_KANBAN_PVT, which in turn delegates row persistence and status changes to this package. Concurrent programs that maintain or purge kanban data — for example, processing of a pull sequence or cleanup of activity history — also reach the package through the same higher-level call paths. Because the metadata records ten other packages referencing it, custom extensions and interfaces should treat INV_KANBANCARD_PKG as an internal implementation layer: direct calls are possible but bypass the validation performed by INV_KANBAN_PVT. Callers must manage the transaction explicitly using COMMIT_ROW and ROLLBACK_ROW, and should use LOCK_ROW before update or delete operations to avoid concurrency conflicts on card records.