Inventory expiry: how to test lots and FEFO before accepting the system

Apocalix — Mon, 26 Oct 2026 03:40:23 +0000

Jonathan Perez · Nightly Software. Originally published October 7, 2026, and last updated on that date in the original guide. This cross-post was prepared with AI assistance to format and adapt that existing guide for DEV.

An expiry alert does not prove that an inventory system prevents shipping an expired lot. Before accepting the system, test the decision it makes, the quantities it changes and the evidence it preserves.

This guide uses one complete, synthetic exercise. It tests FEFO picking, reservations, a quarantined return, partial release, expiry and a repeated event. You can run the same sequence against the software you already use. Passing it depends on the product, version, configuration and operating rules being tested.

First define the dates and eligibility policy

FEFO means first expired, first out, but the date driving a particular system must be checked. The original guide used Odoo 19 documentation, reviewed October 7, 2026: its expiry documentation distinguishes expiry, best-before, removal and alert dates, and its FEFO strategy prioritizes the assigned removal date.

A warning and a picking block are separate controls. Write down these decisions before the demonstration:

Where the lot date comes from. Compare it with the label or supporting documentation. Receiving an older lot today must not silently give it a new life.
Which date orders picking. Specify expiry or removal date and a tie-breaking rule. If removal is earlier than expiry, test that difference.
When eligibility ends. Specify the date, time and time zone. Include any minimum remaining life required at delivery: a lot valid today may be unsuitable for a future shipment.
What happens to missing or corrected dates. Define review, permissions and a reason for the change. A missing date must not be silently treated as approval where the operation requires expiry tracking.

Agree these rules with receiving, picking and exception-approval staff. A column labelled “expiry” is not an acceptance test.

Keep physical stock separate from available stock

In this exercise:

available = on-hand - reserved - blocked

Reserved and blocked are distinct groups. A piece cannot be deducted twice. If a reserved lot becomes blocked, review the commitment and move the affected pieces into the appropriate group.

Quarantine is a block while a responsible person reviews returned goods or a discrepancy. The pieces may still be physically present. Quarantine does not mean disposal, and a warning alone does not move a quantity.

Test fixture: 100 pieces in three lots

These are invented test data, not customer records or project results. Keep the exercise date at October 7, 2026 when reproducing it.

The SKU is INS-01, measured in pieces, in one warehouse. The exercise blocks a lot from 00:00 on its expiry date, Mexico City time. No additional minimum remaining life applies. Removal and expiry dates are identical, and there are no initial reservations. These are explicit test assumptions, not universal inventory or Odoo defaults.

Lot	Received	Expiry and removal	On-hand	Blocked	Available
V-01	Oct 2, 2026	Oct 7, 2026	20	20	0
P-01	Oct 6, 2026	Oct 10, 2026	30	0	30
C-01	Oct 1, 2026	Nov 1, 2026	50	0	50
C00 total			100	20	80

Order PED-45 needs 45 pieces. Reserve 30 from P-01, then 15 from C-01. C-01 arrived earlier but expires later. V-01 is already blocked and must not be used to complete the order.

Because expiry and removal dates coincide in this fixture, either date produces that order. If the dates differ in your configuration, repeat the test using the date that actually governs its strategy.

Run the whole event sequence

Step	On-hand	Reserved	Blocked	Available
C00: initial state on Oct 7	100	0	20	80
C01: reserve PED-45, using 30 P-01 + 15 C-01	100	45	20	35
C02: physically dispatch the 45 reserved pieces, SAL-45	55	0	20	35
C03: receive 5 returned P-01 pieces into quarantine, DEV-05	60	0	25	35
C04: resend DEV-05 without another physical receipt	60	0	25	35
C05: review releases 3; 2 remain blocked	60	0	22	38
C06: Oct 10 arrives; the 3 released pieces expire	60	0	25	35
C07: attempt to reserve 36; reject the request	60	0	25	35
C08: authorized physical removal of 20 V-01 pieces for disposal	40	0	5	35

Check the ledger after each event, rather than only the final dashboard total:

Reservation is not dispatch. C01 changes the commitment, leaving 100 pieces physically present. C02 records their physical departure: 20 V-01 and 35 C-01 pieces remain.
A return is not immediate availability. C03 receives five pieces, but all five enter quarantine. On-hand rises to 60; availability stays at 35.
A repeated event is not another return. C04 represents the same DEV-05 receipt. It must retain the existing reference and balance, adding no pieces. A different return needs its own reference and evidence.
Partial release needs an audit trail. C05 records who released three pieces, why and when, and why two remain blocked. The three released pieces are still eligible on October 7, so availability becomes 38.
Time can change eligibility without changing physical stock. On October 10, those three pieces expire. Availability returns to 35. The two already in quarantine are not deducted a second time.
Disposal needs a physical movement. C08 reduces on-hand and blocked stock by 20 each. It does not change the 35 available pieces. Keep the lot history; deleting a lot is not a substitute for recording its removal.

The final reconciliation is:

100 initial - 45 dispatched + 5 returned - 20 removed = 40 on-hand
40 on-hand - 0 reserved - 5 blocked = 35 available

Those 40 pieces are 35 C-01 pieces available and five P-01 pieces blocked. If the totals differ, keep the discrepancy open even if the screens look correct.

Inspect the return evidence

Record the product, lot, quantity, unit, original dispatch document and return reference before deciding what can be released. Changing an order status must neither recreate the goods nor renew their expiry date.

Under this exercise’s policy, the responsible person reviews the returned goods before releasing some, retaining a block or authorizing a physical removal. Preserve the original dispatch so the remaining distribution of that lot can be traced.

If your operation uses a different return policy, replace the assumptions in writing before running the tests. The fixture is a proposed acceptance model, not a statement that every inventory product behaves this way.

Turn the exercise into an acceptance checklist

Test	Evidence to inspect
Receive lots in a different order from their expiry dates	The eligible lot with earlier expiry/removal is selected first, even when received later.
Show an alert without relying on it as a block	An expired lot cannot be reserved or picked under the agreed policy.
Put removal before expiry	Priority and eligibility use the actual configured dates for the product and customer.
Cross the exact expiry boundary	Check before and from the cutoff, including a reservation made the day before.
Omit or correct a lot date	Visible review, authorized changes and a reason; preserve date history.
Split one order across lots	Quantities and documents retain the actual lot for each dispatch.
Receive a return and release only part	Only received goods increase on-hand; only approved, eligible goods increase availability.
Send the same event twice	One receipt or dispatch, with the original reference and unchanged balance.
Request more than is available	An explicit rejection or pending state; expired goods do not fill the gap.
Remove goods for disposal	Authorized movement, reconciled balances and accessible lot history.

Run the sequence with the people who will receive and pick, on the intended devices. Keep event references, expected balances, screenshots and discrepancies. Compare the physical label with the lot selected in the system. After a correction, repeat the affected steps and verify their balances again.

Configure first, then decide whether to extend

Start with the system you already use: lot tracking, dates, removal strategy, permissions and blocking rules. If configuration passes the agreed tests, you may not need another system.

If sales, the warehouse and a customer portal show different balances, identify the missing integration or extension before replacing everything. The decision should follow demonstrated rules and reconciled evidence, rather than the presence of an expiry screen.

This is an operational acceptance exercise. It does not certify sanitary, tax or regulatory compliance, and it makes no claim that Nightly delivered these rules for a previous customer. The original publication date, source-review date and synthetic exercise dates remain October 7, 2026.

DEV Community: Nightly Software