Automatic Fill Transactions
When you receive items that are tracked using the Kanban module, PO Shipper Receipt (5.13.20) automatically updates kanban card status and creates transaction history (kbtr_hist) to indicate that the kanban has been filled. Because the supplier’s shipping document does not include an kanban ID, the system searches for loops that have cards to be filled based on PO shipper data.
Important: Before selecting a loop that is eligible to have cards filled, the system validates that Kanban Supplier is Yes in Supplier Data Maintenance for the loop’s supplier. Otherwise, kanban data is not updated during receipt of PO shippers from that supplier.
To determine which loops can have cards selected, the system first attempts to match the purchase order and line from the PO shipper to loop records set up in Kanban Master Maintenance, first for discrete purchase orders and then for orders released from a blanket PO. If no loops are found, the system continues to search for loops based on item number and supplier address code. If the search does not find any qualifying loops, the system continues to process inventory receipts without creating kanban records.
Important: If the search results in the selection of multiple loops, the following fields in Kanban Master Maintenance must have the same values for all loops. Otherwise, an error message displays and the PO shipper cannot be received.
• Kanban Quantity
• Quantity Mismatch Method
• Rounding Threshold
After identifying one or more loops, the system calculates the required number of cards by dividing the quantity received (converted into the inventory unit of measure as required) by the kanban quantity in Kanban Master Maintenance.
If the quantity received is not a multiple of the kanban quantity, the system uses rounding rules defined in Kanban Master Maintenance. See
Quantity Mismatch Method.
The system then searches all eligible loops for active cards that can be filled without violating transaction sequence rules defined in Kanban Master Maintenance. It searches for cards across all loops in the following order, based on the latest recorded kanban transaction event, until it finds a sufficient number:
1 Ship
2 Acknowledge
3 Authorize
4 Consume
5 Fill
For multiple cards within an event status, the system selects cards based on the authorize date and time, with the oldest cards selected first. In some cases, this may result in the selection of cards from more than one loop.
The system then changes the card status to Full and creates a Fill kbtr_hist record for each selected card.
Note: There is not necessarily a one-to-one relationship between inventory transaction history (tr_hist) and kanban transaction history (kbtr_hist) records created by this program. For example, you receive a PO shipper line for a quantity of 100, with 50 into location 1 and 50 into location 2. This results in two tr_hist records. However, because the kanban quantity is 20, the system generates a kbtr_hist record for each of five cards. Each kbtr_hist record is linked to both tr_hist records.
Important: The PO shipper receipt process can be completed only if each individual line is received successfully. For example, if sufficient cards are not available to meet the received quantity requirement for a PO shipper line, the system displays an error message and rolls back the inventory and kanban transactions created by all lines on the shipper.