Item Tracking & FEFO
How WarehouseQ handles lot, serial, and package numbers — and how it fits into Business Central’s own expiration-date enforcement — described at the level a customer needs, not an implementation level.
The claim, precisely
Item tracking — lot, serial, and package numbers — is attached the way Business Central actually requires it, through the platform’s own tracking mechanism, not just written onto a transaction line and hoped for. For background on why that distinction matters, and how a careless scanning tool can get it wrong without ever raising a visible error, see item tracking in Business Central, explained — that page describes the general mechanism this one describes WarehouseQ reaching.
What this looks like for an operator
When a scanned operation touches an item that requires tracking, the operator is prompted for whatever tracking information that item’s own setup requires — a lot number, a serial number, a package number, or a combination, plus an expiration date where the item is set up to carry one. That prompt isn’t a convenience field bolted on after the transaction; it reaches the same tracking mechanism Business Central’s own posting step reads, whether the transaction originates from a scan or from a desk-client page. An operator isn’t asked to type a tracking number into a field that merely resembles the real thing — they’re completing the actual record Business Central posts from.
For an inbound scan, that can mean selecting an already-known lot or serial (where the vendor or an earlier step already assigned one), or being prompted to assign a new one — the same two paths a desk-client user has when working an inbound document. For an outbound scan against tracked stock, the operator either selects from what’s already on hand or, where the source document already specifies a particular lot or serial, simply confirms the quantity against a tracking number the system already knows to expect.
FEFO, where the location supports it
At a location where Business Central’s own first-expired-first-out enforcement is turned on (see FEFO vs. FIFO, explained), a scanned pick sources from the lot expiring soonest — the same way it would if a warehouse manager ran the identical pick from the desk client — because it’s the same underlying enforcement mechanism, reached through a scan instead of through a desk-client page. WarehouseQ doesn’t run its own separate expiration-date logic alongside Business Central’s; it reaches the one Business Central already has.
Worked example
Vellano Imports’ EVOO-500 (a fictional example item, a 500 ml extra-virgin olive oil) sits in one bin as two lots:
| Lot | Expires |
|---|---|
| L2601 | 2027-07-15 |
| L2603 | 2027-11-01 |
A picker scans a pick for 6 units at a location with FEFO enforcement turned on. The pick is sourced from L2601 — the earlier-expiring lot — automatically, without the picker needing to check either date by hand or make a judgment call under shift pressure. If the two lots’ dates were reversed, the same automatic sourcing would follow the reversed order — the mechanism doesn’t depend on which lot happens to look older on the shelf, only on the expiration date each one actually carries in Business Central.
Scope, honestly stated
FEFO enforcement is a Business Central location setting, not something WarehouseQ invents independently on top of it. A location that doesn’t have FEFO turned on, or an item that isn’t tracked with an expiration date at all, won’t get FEFO-sorted picks just because WarehouseQ happens to be installed there — there’s nothing for the mechanism to enforce if the underlying setup doesn’t provide it. The same honesty applies more broadly to which operations are available where at all: see operations covered for how operation availability tracks a location’s actual setup in general, not a fixed assumption about what every customer’s warehouse looks like.
Related reading
Item tracking in Business Central, explained — the underlying mechanism and the trap careless tools fall into. FEFO vs. FIFO, explained — why first-in and first-expired aren’t always the same lot, and what Business Central’s native enforcement actually does. Operations covered — the full current operation list.