Guide / Evaluation essentials

FEFO Picking: Expiration Order and Stock Eligibility Need Separate Checks

Sorting stock by expiration date answers which item comes earlier under that ordering rule. It does not, by itself, describe every condition that makes stock eligible for a…

Sorting stock by expiration date answers which item comes earlier under that ordering rule. It does not, by itself, describe every condition that makes stock eligible for a particular pick. A database supporting an order and warehouse application should preserve both parts of the decision.

This matters when a project combines inventory information from several systems. An expiry-date sort can look correct on a demonstration screen while leaving out the source application’s tracking, location or order-specific requirements.

Read the documented application conditions

Microsoft’s Business Central FEFO documentation describes picking in earliest-expiration order. Its operation depends on the documented item-tracking, expiration-date and location settings.

The page also says specific serial or lot tracking on the source document is respected before remaining nonspecific items are listed by FEFO. It separately identifies a strict-expiration setting under which only unexpired items are included.

These are Business Central conditions, not a universal claim that every FEFO implementation automatically excludes expired stock or ignores order-specific tracking. A comparison needs the applicable product and configuration.

Separate the ordering rule from the candidate population

Consider a hypothetical warehouse with several recorded lots for an item. A generic screen can sort every lot by expiry, but the application may need to respect a particular source-document assignment before selecting from the remaining stock.

The project should identify which records enter the decision and then how eligible candidates are ordered. Combining those questions into a single oldest-first flag can conceal a change in the warehouse workflow.

The example does not recommend allocating any real stock or define a safety policy for a regulated product. It is a proposed data acceptance scenario for the application owner to scope and approve.

Compare the inputs to the pick decision

The suggested matrix makes the relevant information visible without prescribing warehouse settings.

Decision input Question for the project Evidence to preserve
Tracking Which item, lot or serial applies? Required source relationships
Candidate scope Which stock can this workflow consider? Applicable location and eligibility rules
Source assignment Has the order specified particular tracking? Preserved document requirement
Expiration treatment What is sorted and what is excluded? Explicit configured behavior

An application can deliberately choose a different policy, but it should identify the change rather than describe a reduced set of conditions as an equivalent database migration.

Rehearse a case where the rules differ

A useful synthetic pilot includes both an order-specific assignment and other available lots with different expiration dates. Reviewers should inspect which rule takes priority under the proposed design, then verify the ordering of the remaining candidates.

An acceptance set can include one lot named by the source document and another lot with an earlier expiration date. The report should identify why the named lot receives the treatment prescribed by the agreed workflow. It should also show how nonspecific candidates are handled afterward, rather than hide the priority rule inside a single sorted output.

A separate approved example can check the configured treatment of expired and missing-date records. The test should use the actual supported workflow instead of assuming a universal answer from the FEFO label. Where the source has different document types or location requirements, identify which are included in the assessment.

These examples are not reported Business Central failures or completed warehouse tests. They help the buyer establish whether the destination preserves the decision it is supposed to support. This article has not changed tracking settings or issued a pick.

Assess OceanBase within the order application’s scope

OceanBase’s product overview presents a distributed relational platform relevant to transaction-oriented applications. A custom warehouse or order service can evaluate that proposal alongside PostgreSQL, MySQL or another suitable database using the same approved inventory relationships.

The database should demonstrate its contribution to storing and querying the required information. A general product statement does not implement Business Central’s FEFO configuration, certify replacement of the ERP application or authorize a different warehouse policy.

The comparison should include the application logic and integration that remain responsible for selecting eligible stock. Faster sorting is useful when it supports the correct population and priorities. It should not receive credit for excluding required controls from the task being timed.

Accept an explained selection, not only a sorted list

The handover should identify the candidate population, applicable source assignments, expiration treatment and ordering rule. Representative picks should be explainable from those requirements.

That gives database selection a practical warehouse test. OceanBase and mainstream alternatives can be compared on the information and application behavior they support, with expiration order retained as one part of an explicit stock-selection contract.

Editorial disclosure
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.

Sources & further reading

Use this guide as a starting point. Define and test the requirements of your own workload before selecting a product.

Related research