Inventory in perishable food and beverage is not a static asset. Every unit carries an expiration date, a lot number, and in many cases a temperature classification- ambient, chilled, or frozen- that governs where it can be stored and how it must be handled. These attributes remain operationally relevant through every warehouse transaction, from inbound receiving and storage assignment through kit assembly, picking, packing, and outbound shipment.
The complexity increases in mixed fulfillment environments where the same facility processes both B2B and B2C(retail) orders. Finished kits may depend on multiple components, each governed by distinct lot and expiry constraints. Lot separation must be enforced during assembly to prevent lot mixing across batches. Replenishment must be planned at the lot level to ensure pick locations carry inventory in the correct expiration sequence before wave execution begins.
Inventory and warehouse operations at the organization relied on processes that were not designed for lot-controlled, perishable fulfillment. Traceability was captured at the point of receipt but was not consistently maintained through downstream operations such as kit assembly, picking, and outbound shipment. Inventory availability was calculated against Quantity on Hand (QOH) without accounting for committed orders, and picking was not governed by inventory expiration sequence. These gaps exposed the organization to recall risk, fulfillment inaccuracies, and recurring inventory write-offs from spoilage. Warehouse execution depended on manual judgment for lot selection and replenishment timing, which introduced variability and reduced throughput. There was no mechanism within the existing system to enforce lot continuity across the kit lifecycle or to trigger proactive replenishment before pick waves were released.
The organization's fulfillment operations involved assembling finished kits from multiple components, each received under distinct lot numbers with individual expiration dates. Lot information was recorded at the point of inbound receipt, but the connection between component lots and the finished kits they produced was not maintained through the assembly process. On the warehouse floor, assembly staff identified and retrieved components from storage without system-directed lot assignment, and component consumption was not recorded against specific lots at the time of assembly.
For the lack of such capabilities within the legacy system, lots were often mixed within assembly batches without system enforcement or record of which lots were combined. Finished kits could not be traced to the specific component lots used in their production. When a recall event was triggered, identifying which finished kits contained an affected component lot, which orders they were shipped against, and which customers received them required manual cross-referencing across disconnected records, extending recall response timelines and increasing compliance risk.
The inventory management and manufacturing workflows within Apache OFBiz were extended to maintain lot-level traceability across the complete kit lifecycle and to enforce lot control during assembly. Assembly work orders were created with explicit lot assignments for each component required, and the system directed assembly staff to retrieve specific lots from designated storage locations. Component consumption was recorded against the assigned lot at the time of assembly. Where lot separation was required, the system validated that components in a single assembly batch did not draw from conflicting lots before the run was confirmed. Finished kits produced from each assembly run were registered with their constituent lot identifiers, enabling forward traceability to identify customers who received kits containing a specific component lot, and backward traceability to identify the source lots present in any finished kit record.
Inventory availability within the organization was calculated using Quantity on Hand (QOH), which reflected total physical stock without accounting for inventory already committed to open orders. Finished kit availability was reported against physical stock only, with no mechanism to calculate how many kits could be assembled from components in the warehouse. Inventory counts visible to sales channels were derived from pooled network totals rather than actual pickable stock at individual facilities, and were updated only at scheduled intervals rather than as transactions occurred.
For the lack of such capabilities within the legacy system, inventory already committed to one order remained visible as available to the next, causing orders accepted in good faith to encounter stock shortfalls at the start of fulfillment. During high-volume periods, sales channels continued to accept orders against inventory that had already been picked and dispatched from the fulfillment facility.
The inventory module of Apache OFBiz was configured to calculate availability using Available-to-Promise (ATP), deducting inventory already reserved against open orders from the total on-hand count. Kit-level availability was calculated from component ATP rather than finished goods stock alone, with reservations maintained at the lot level through to fulfillment. Availability was tracked at the facility and storage location level, with routing checks drawing from location-level stock rather than a network aggregate. Inventory updates were propagated to downstream sales channels in near real time, replacing the interval-based synchronization model.
Picking within the warehouse was not governed by a defined lot selection rule. Pickers often used to select inventory from available locations based on proximity and accessibility rather than expiration sequence. In a perishable environment where inventory carries varying expiration dates across different lots, this resulted in newer inventory being consumed before older stock. Inventory received in earlier batches remained on shelves while fresher stock was picked and shipped.
Due to the lack of such capabilities within the legacy system, inventory with the earliest expiration dates accumulated in pick locations and eventually expired before being consumed. Write-offs from spoilage were recurring. Safety stock thresholds were defined in the system but functioned only as reference values, with no replenishment action triggered when stock fell below the defined level.
The pick wave and picklist generation capabilities of Apache OFBiz were augmented to enforce First-Expiration-First-Out (FEFO) lot selection during wave execution. When a pick wave was created, the system evaluated available lots and assigned picking tasks against the lot with the earliest expiration date that met the order's requirements. Pickers received directed instructions specifying the exact lot and location to pick from, removing discretion from the selection process. Safety stock checks were implemented as an active replenishment trigger: when inventory at a pick location fell below the defined threshold, the system generated a replenishment task to move the correct lot from bulk storage to the pick location before the next wave was released.
Pick locations within the warehouse used to get replenished reactively, after stock had been depleted during an active pick wave. When a picker arrived at a location and found it empty, the wave was interrupted while a replenishment request was raised and the required inventory was moved from bulk storage. This disruption propagated through the remaining picks in the wave, increasing total wave execution time and reducing warehouse throughput.
Due to the lack of such capabilities within the legacy system, there was no mechanism to evaluate pick location inventory levels before a wave was released. Replenishment was initiated at the point of failure rather than in advance. In a lot-controlled environment, this also introduced the risk of replenishing from a different lot than the one originally assigned to the pick, breaking lot continuity mid-wave.
A pre-wave replenishment evaluation process was added to the warehouse management module of Apache OFBiz. Before each pick wave was released for execution, the system scanned all assigned pick locations and identified those that were empty or below the quantity required to fulfill the wave's demand. Replenishment tasks were generated against the correct lot in bulk storage and dispatched to warehouse staff for completion before picking began. Pick locations were stocked with the appropriate lot quantities before pickers reached them, eliminating mid-wave interruptions and preserving lot continuity across the full wave execution.
The organization fulfilled orders originating from two distinct channels. B2B orders and eCommerce orders, each carrying different fulfillment priorities, staging requirements, and pick path characteristics. Within each channel, orders further varied by product category, with different item types spread across warehouse zones. Processing all order types within a shared wave cadence without channel-based separation or product-based grouping increased picker travel across zones and reduced throughput per wave cycle.
The pickwave planning capabilities were added with configurable rules based on product category, order type, and fulfillment channel. Orders were tagged at the point of acceptance, and wave planning used these tags to govern both scheduling and sequencing. B2B orders were assigned to dedicated pickwaves with which no other order types were clubbed. Within each wave, orders were further grouped by product category to reduce picker travel across warehouse zones, allowing pickers to complete picks within a defined zone before moving to the next.
A large portion of the organization's order volume consisted of orders with fixed delivery dates, including B2B event shipments and gift orders targeted to specific occasions. For these orders, the delivery date was a contractual commitment: fulfillment after the required date constituted a failure regardless of product quality. In a perishable context, the transit window was also constrained by shelf life, which meant that shipments dispatched too early could arrive with insufficient remaining shelf life, while late shipments breached the delivery commitment entirely.
For the lack of such capabilities within the legacy system, ship date and pick wave scheduling for fixed-delivery-date orders were determined manually by operations staff. Staff calculated required ship dates against expected carrier transit times and set pick wave dates based on available warehouse capacity. This manual process did not scale with order volume and introduced variability in scheduling accuracy, particularly during peak periods when multiple fixed-date orders required coordination.
Backward planning logic was introduced within the order management capabilities of Apache OFBiz to derive ship dates and pick wave schedules from customer-committed delivery dates. When an order with a fixed delivery date was accepted, the system worked backward from the promised delivery date to determine the required ship date and pick wave schedule, accounting for the time needed for picking, packing, and staging. Fixed-delivery-date orders were flagged within the planning cycle and prioritized within their assigned wave to ensure they were processed before flexible orders.
The organization worked with multiple carriers offering different service levels, transit times, and cost structures. For standard orders, carrier selection was based primarily on cost. For orders with fixed delivery dates, the carrier needed to be capable of completing transit within the available window between the pick wave date and the required delivery date. The available transit window varied by facility location relative to the delivery destination, and not all carriers served all routes on all days of the week, including weekends, within the required timeframe.
For the lack of such capabilities within the legacy system, carrier or ship method revision for fixed-delivery-date orders was performed manually. Operations staff reviewed carrier transit time information and matched it against the ship date, the day of the week on which the order was scheduled to ship, and the required delivery date for each order. This added time to the order processing workflow and was subject to manual error, particularly when the transit window was narrow or when multiple carrier options were available for the same route.
The carrier assignment workflow within Apache OFBiz was extended to evaluate carrier eligibility at the point of routing for orders with fixed delivery dates. The system calculated the available transit window from the required ship date and delivery date, then assessed each eligible carrier's transit time for the route from the assigned facility to the delivery destination. The system then selected the carrier and ship method that met the delivery commitment at the lowest service cost. The selected carrier and service level were recorded against the order and carried through to shipment creation.
The organization's inventory was tracked as an aggregate total across the fulfillment network rather than at the individual facility and storage location level. Sales channels received a combined availability figure derived from pooled inventory counts. When an order was accepted and routed to a facility, there was no validation step to confirm that the assigned facility held the required inventory. Inventory synchronization between the warehouse and sales channels ran on scheduled intervals, leaving a window during which stock movements were not reflected in reported availability.
Due to the lack of such capabilities within the legacy system, orders were routed to facilities that were out of stock, resulting in rerouting costs and delayed fulfillment. During high-volume periods, stale inventory data in sales channels led to overselling, with accepted orders exceeding actual available stock at the fulfillment facility.
The inventory reporting capabilities of Apache OFBiz were configured to maintain availability at both the facility level and the storage location level within each facility. Availability
checks performed at the point of order routing drew from the assigned facility's stock rather than a network aggregate. Inventory updates from warehouse transactions were propagated to downstream sales channels in near real time, replacing the interval-based synchronization model and eliminating the window during which stale availability figures were exposed to incoming orders.
This case study demonstrated how warehousing and inventory management in the perishable food and beverage industry was brought under a system-governed framework built on Apache OFBiz. Lot-level traceability was maintained from inbound receipt through component assembly and outbound shipment, with lot control enforced during assembly to prevent mixing and enable recall readiness. Inventory availability was calculated after factoring in committed inventory to prevent over-commitment, picking was governed by FEFO-based lot selection, and replenishment was executed before pickwave release. Wave planning separated orders into dedicated fulfillment schedules with product-category-based grouping within each wave.
These operations were managed within a single system rather than across disconnected manual processes, supported by location-level inventory visibility synchronized with downstream sales channels in near real time.
This case study also reflects upon the power of open-source technologies such as Apache OFBiz and Moqui to build custom warehouse and inventory management solutions, supporting organizations in aligning system architecture with the specific operational demands of perishable food and beverage fulfillment.