FIFO Issuing by Lot in a Manufacturing Warehouse: Lot Status, Deviations, and Atomic Stock Updates

FIFO issuing by lot is a way of issuing stock from the lot that arrived first (first in, first out), with stock and status recorded per lot. The system suggests the oldest available lot, rejects lots that are unfit to leave, and asks for a recorded reason when the operator deviates. The result is a traceable order of stock usage.

In manufacturing warehouses, goods are often picked from the lot that is closest or easiest to reach, not the oldest one. Old stock then piles up, and when a quality issue appears it is hard to say which lot went to whom. This article explains how to design FIFO picking in a manufacturing warehouse: validation rules, lot status, deviations allowed with a reason, and atomic stock updates.

The content describes general practice, not a standard and not a guarantee of results. To discuss your issuing flow, contact our team. Picking features in a WMS are covered in the WMS outbound and picking article, and the service overview is on the WMS service page.

What Is FIFO Issuing by Lot?

FIFO (first in, first out) is the rule that goods received earlier are issued earlier. A lot is a group of identical goods received or produced together and given a single identity, so they can be tracked as one unit. FIFO issuing by lot means the issue order is decided by lot, not by rack location or operator habit.

FIFO picking in a manufacturing warehouse is picking goods for shipment or consumption in that order. The system shows the suggested lot, which is the oldest lot still available, and the operator scans the barcode of the goods actually picked.

Keeping stock per lot gives every item a history: when it arrived, how much remains, and where it has gone. Without per-lot data, FIFO is only a recommendation that depends on memory. With per-lot data, FIFO becomes a rule the system can check on every scan, and the result of the check is stored as a record, not an assumption.

What Is the Difference Between FIFO and FEFO?

FIFO orders by arrival date. FEFO (first expired, first out) orders by expiry date. The choice depends on the nature of the goods, not preference. Goods without a shelf life, such as many metal components, commonly use FIFO. Goods that can expire, such as certain chemicals or adhesives, often suit FEFO better.

Both rules follow the same pattern: the system computes the suggested lot, checks the operator's choice, and records deviations. The design in this article therefore applies to both; only the sorting column changes. The plant decides which rule applies to which type of goods. That decision is best written as policy and mapped to the item master, so operators do not have to choose a rule themselves while working.

Why Does Lot Status Decide Whether a Lot Can Be Issued?

Lot status is a marker of a lot's condition, for example available, on hold, or under quality inspection. Names and the number of statuses differ between plants. What matters is that only a lot with status available (AVAILABLE) may be issued; a lot with any other status must be rejected as a hard stop.

The reason is simple. A lot on hold awaiting quality inspection must not reach a customer, even though it is physically on the rack and its barcode reads fine. If you rely on operators to remember which lots are on hold, an error is only a matter of time.

So the status check is done by the system on every scan, not by a list taped to the wall. Status changes, for example from on hold to available after inspection, should also record who changed it and when, so the lot history stays intact and can be shown when asked. The authority to change status should be limited to the roles responsible for quality.

Which Validations Stop an Issuing Scan?

As with receiving, separate conditions that are certainly wrong (hard stop) from conditions that may be legitimate (warning). The basic concept is covered in the barcode receiving scan article. The table below summarizes the rules for issuing. It lists general examples to adapt to each plant's policy. Every row has a reason that can be explained to the operator, so a rejection does not feel arbitrary. Conditions that are almost certainly wrong become hard stops; conditions that may be legitimate become warnings with a mandatory reason.

Why Does a FIFO Deviation Need a Recorded Reason?

A FIFO deviation can be legitimate. The oldest lot may have damaged packaging, be blocked by other stacks, or be requested by a specific customer. Because it can be legitimate, the deviation is a warning, not a hard stop: the operator may continue after writing a reason.

A recorded reason matters for two things. First, it turns a silent deviation into a decision that can be defended to supervisors and customers alike. Second, the collection of reasons reveals patterns, for example a particular lot that is always skipped. Such patterns often point to a root cause, like rack layout that blocks access to old lots.

The same applies to quantity outside tolerance, for example a small excess from packaging rounding. The tolerance threshold is kept as adjustable configuration, not a number in the program. A warning without a mandatory reason is just a box that gets clicked through; a warning with a reason becomes data that can be analyzed. Review the collected reasons regularly with the warehouse and quality teams, so findings lead to process improvement, not just an archive.

How Is the Stock Update Made Atomic When Issuing?

Why it must be one transaction

One issuing scan changes several things at once: the shipped quantity on the document goes up, lot stock goes down, and an audit record is written. If only some of them are saved, the data no longer matches. For example, the shipped quantity rises but lot stock does not fall, so recorded stock is larger than what is physically in the warehouse. Such a gap only shows during a physical count, long after the cause is forgotten.

Atomic means all those changes succeed together or fail together. In a database, this is achieved with a single database transaction. The operator does not need to know the mechanism; all they see is a scan that is saved completely or not saved at all, with no confusing half-done state. If something fails midway, every change is rolled back and the operator is asked to scan again. The failure message should clearly say the scan was not saved, so the operator does not assume the goods were recorded as issued.

What goes inside the transaction

In the design discussed here, three things are saved in one transaction, not split into separate steps that could fail independently: the recorded scan with the increased shipped quantity, the reduced lot stock, and the audit log row. The sufficiency check on stock should also run inside that transaction, so two operators picking from the same lot at nearly the same time cannot drive stock negative. This is common practice for operations that change shared numbers; the technical method depends on the database used.

The audit log is written in the same transaction so there is no issue without a record, and no record for an issue that was cancelled. This matters because per-lot stock is the foundation of FIFO itself. It also fits with stock taking and cycle counting: the fewer discrepancies the daily process creates, the lighter the recount and adjustment work.

How Do Barcode-Scanned Delivery Notes and Issuing Document Types Work?

A barcode-scanned delivery note means the delivery is built from scan results, not retyped. The operator selects an active delivery for a customer, and the system shows the part, planned quantity, stock, and the suggested FIFO lot. Each valid scan raises the shipped quantity on that document, so the delivery note always reflects what was actually scanned.

Issuing is not always a sale. Example document types in this flow are sales, sample, trial, exchange (tukar guling, where goods are swapped for other goods), and return. All types use the same scan pattern, so operators do not have to learn a different flow for each type. The difference lies in the purpose of the document and how reports are grouped, not in the steps at the shipping desk.

With clear document types, stock-out reports can be separated by purpose, for instance goods leaving as samples are not mixed with sales. Cross-module reporting is discussed in the WMS BI dashboard article.

How Is Lot Traceability Maintained from Receiving to Shipping?

Lot traceability is the ability to trace a lot forward and backward: which supplier it came from, when it arrived, and which customer it was shipped to. Tracing is only possible if the lot identity is recorded from receiving and carried through every movement.

At receiving, the lot is created or recognized when the goods are scanned. At issuing, the scan points to a specific lot, and the stock that decreases is that lot's stock. That way a question like which customer has this lot been shipped to can be answered from data, not from memory or a pile of documents. The result can also be rechecked by others.

Tracing also helps with quality problems, customer complaints, or external inspections. Instead of pulling all goods of the same kind, the plant can limit action to the affected lot. This depends on discipline in per-lot recording, so hard stop rules and the audit trail are part of traceability, not extras.

Case Study: The Issuing Flow in DAISHIN

Automata is building DAISHIN, a web-based warehouse and manufacturing system for PT Shinko Kogyo Indonesia, a manufacturing company. The system is in development and will replace a workflow based on Excel and VBA. No operational results are claimed here; what is described is behavior that has been implemented, not results from field use.

The operator selects an active delivery for a customer. The application shows the part, planned quantity, stock, and the suggested FIFO lot. A lot status other than AVAILABLE, a part or UOM mismatch, insufficient lot stock, and a duplicate barcode are hard stops. A FIFO deviation or a quantity beyond tolerance becomes a warning that may continue after a reason is recorded. The scan is saved, the shipped quantity goes up, lot stock goes down, and the audit log is written in one database transaction. Document types include sales, sample, trial, exchange (tukar guling), and return. Rule details can be adapted to plant policy.

10-Step Checklist for Designing FIFO Issuing by Lot

1. Keep stock per lot, with arrival date and lot status, as a single data source used by every screen.
2. Set the ordering rule for each type of goods, FIFO or FEFO, and record the decision as policy.
3. Let the system compute the suggested lot for every delivery.
4. Make any lot status other than available a hard stop.
5. Reject a part or UOM that does not match the document.
6. Reject the scan when lot stock is insufficient, so stock never goes negative and discrepancies do not pile up.
7. Make FIFO deviations and out-of-tolerance quantities warnings with a mandatory reason, and review the reasons regularly.
8. Save the scan, the lot stock reduction, and the audit log in one database transaction.
9. Keep tolerance thresholds as adjustable configuration.
10. Test with two operators picking from the same lot at nearly the same time, and test a failure mid-transaction to confirm everything rolls back.

Common Mistakes in FIFO Issuing

• FIFO as a recommendation only. Without a system check, the order depends on habit and operator memory.
• Stock not separated by lot. The oldest lot cannot be determined objectively.
• Lot status not checked at scan time. A held lot can be shipped.
• Deviations blocked entirely. Operators look for workarounds outside the system.
• Deviations allowed without a reason. Problem patterns are never seen.
• Stock update not atomic. Shipped quantity and lot stock drift apart, and the gap only shows during a physical count.

These mistakes are rarely deliberate. Most come down to one thing: the rule lives on paper, not in the system. A rule that exists only on paper depends on memory, and memory is weakest when the warehouse is busy or staff change shifts. The goods issued here arrived through the receiving process, covered in barcode scanning for goods receiving, and the same receipt data is used to calculate vendor KPIs.

Frequently Asked Questions

What is FIFO issuing by lot?

FIFO issuing by lot is issuing stock from the lot that arrived first, with stock and status recorded per lot. The system suggests the oldest available lot and asks for a recorded reason when the operator picks from another lot.

What is the difference between FIFO and FEFO?

FIFO orders by arrival date, while FEFO orders by expiry date. FIFO is common for goods without a limited shelf life, FEFO for goods that can expire. The system pattern is the same; only the sorting column differs.

Why is a lot with a status other than AVAILABLE rejected?

A lot on hold or under inspection is unfit to leave even though it is physically on the rack. A system check on every scan is more reliable than relying on operator memory, so any status other than AVAILABLE is a hard stop.

Why does a FIFO deviation need a recorded reason?

A deviation can be legitimate, for example when the old lot's packaging is damaged, so it is a warning. A recorded reason makes the decision defensible and reveals patterns, such as a lot that is always skipped because of rack layout.

What does an atomic stock update mean for issuing?

Atomic means the scan, the lot stock reduction, and the audit log are saved in one database transaction: all succeed or all are rolled back. That way shipped quantity and lot stock never drift apart because of a failure midway.

Is DAISHIN already in use at the factory?

No. DAISHIN, the warehouse and manufacturing system Automata is building for PT Shinko Kogyo Indonesia, is still in development. This article only describes behavior that has been implemented, without claims of operational results. Contact our team for a WMS demo.