Inside the Infor WMS Wave Planning Algorithm: How Allocation, Labor Standards, and Release Logic Actually Work Together

If you already run Infor WMS, you have built waves hundreds of times. You know the Query Builder screen, you know the difference between Pre-Allocate and Allocate, and you have probably argued with a colleague about whether to release a wave to Task Manager before or after Calc Standards runs. This article is not an introduction to wave planning. It is a walk through the actual mechanics that sit underneath the screens you use every day, written for people who need to tune wave behavior, not learn what a wave is.

The reason this matters right now is that most facilities running Infor WMS are leaving throughput on the table not because the software lacks capability, but because the wave configuration was set once during implementation and never revisited as order profiles, labor pools, or carrier cutoffs changed. Understanding what each setting actually does inside the allocation and labor engine is what lets you fix that without opening a support ticket.

What the Wave Planning Algorithm Is Actually Doing

A wave in Infor WMS is not a single action. It is a sequence of discrete processing steps, each of which can be triggered manually from Wave Maintenance or chained together through the Job Scheduler. The Infor WMS Wave Planning User Guide structures the entire workflow around the Wave Workbench, which separates the planning phase from the execution phase, and that separation is the first thing worth understanding because it determines where you have control and where the system takes over.

In the planning phase, you are not moving inventory. You are defining a population of orders using either the Query Builder or the Graphical filter, and you are testing that population against wave limits before you commit to anything. In the execution phase, the wave becomes a live object that inventory gets reserved against, tasks get generated from, and labor standards get calculated for. If you have ever wondered why a wave you thought was “done” still shows orders sitting in Not Started status, it is almost always because a step in this sequence was skipped, not because of a bug.

The core sequence, in the order the system expects it, looks like this: build the order population, validate it against limits, confirm the wave, pre-allocate, allocate, calculate labor standards, release to Task Manager, then ship. Each of those steps is its own discrete process inside Infor WMS, and each one can fail independently, which is why diagnosing a stuck wave means checking status at each step rather than assuming the whole thing either worked or didn’t.

Building the Order Population: Query Builder and Graphical Filter

Every wave starts with a population of eligible orders, and Infor WMS gives you two ways to define that population. The Query Builder approach lets you specify selection criteria such as Owner, Order Date, and Requested Ship Date through Order, Operator, First Value, Second Value, and And/Or fields, building filter logic line by line. This is the same mechanism that underlies scheduled wave releases, because a saved filter from Query Builder can be reused directly inside the Scheduler workbench to trigger automatic wave creation on a recurring basis.

The practical implication for teams running multi-client or multi-channel operations is that your filter logic is the actual segmentation strategy for your facility. If you are running B2B pallet orders and B2C parcel orders through the same facility, the filter is what keeps a single-line e-commerce order from getting buried inside a 400-line wholesale wave. Infor’s own product documentation for the WMS platform describes this directly, noting that waves can be scheduled using filters such as number of lines, overall weight, and final destination, and that the same warehouse locations can run B2B, B2C, and 3PL waves side by side. If your facility runs distinct rate structures or SLAs for different client types, the way you structure these filters has a direct bearing on how cleanly your warehouse operations consulting engagement can map cost-to-serve back to each channel, since the wave is the unit that labor standards and billing data get attached to downstream.

The Graphical filter is the second path into the same population logic, and it exists for cases where a visual representation of order volume against a time axis is more useful than a tabular query, particularly when you are trying to spot a concentration of orders against a single carrier cutoff. Both paths feed the same wave limits validation step before a wave can be confirmed, so neither one is “more correct.” The choice is about which interface matches how your planners think about the day’s order book.

Wave Limits: The Constraint Layer Most Teams Under-Configure

This is the part of the algorithm that determines whether your waves are operationally realistic or just a database query with a name attached. Wave limits are the boundaries you set on a wave before it gets built, and the Infor WMS Wave Planning User Guide treats this as a distinct configuration step within the Query Builder workflow, separate from the filter criteria itself.

The mistake we see most often in facilities that have been running Infor WMS for several years is that wave limits were configured during go-live based on the labor pool and order volume at that time, and never adjusted as the business grew. A wave limit that made sense for a facility shipping 2,000 lines a day does not make sense at 6,000 lines a day, and an oversized wave does not fail outright. It just creates a backlog of orders sitting in Allocated status waiting for picks, which shows up as a productivity problem on the floor when the actual root cause is upstream in the wave configuration.

If your facility has gone through any kind of volume growth, seasonal peak restructuring, or new client onboarding since your original Infor WMS implementation, that wave limits configuration is one of the first places worth auditing, because it is invisible in day-to-day operation until the gap between configured capacity and actual order volume becomes large enough to create a visible bottleneck.

Pre-Allocation and Allocation: Two Distinct Processes, Not One Step

This is the single most misunderstood part of the wave algorithm among teams who did not configure the system themselves. Pre-allocation and allocation are sequential but functionally separate processes, and conflating them is the source of most “why didn’t my wave allocate” support calls.

Pre-allocation reserves inventory for the orders on the wave based on availability at the lot level. It determines which system lot numbers should be used to satisfy the order quantity for each item, along with the units of measure that allocation will use. Allocation then takes the output of pre-allocation and determines the specific locations, license plates, and quantities used for picking. The Classic Allocation and Classic Pre-Allocation Overview in Infor’s documentation is explicit that these are two parts of one process, where pre-allocation answers the question of which lot and allocation answers the question of which physical location and license plate.

The distinction matters operationally because the two steps fail for different reasons. If pre-allocation succeeds but allocation fails, you usually have a lot that exists in your system but not in a location your allocation strategy is configured to search. If pre-allocation itself fails, you typically have an inventory availability problem, not a configuration problem. Knowing which of the two failed tells you whether to call your inventory team or your WMS configuration team, and that single distinction saves a meaningful amount of diagnostic time on a busy shipping day.

Allocation in Infor WMS comes in two strategic flavors that behave very differently on the warehouse floor. Firm allocation reserves a specific lot, location, and license plate for each item, placing what the documentation describes as a hard hold on inventory, meaning that reserved portion is not available for other orders and cannot be moved. Soft allocation, used by dynamic picking, checks only for availability by item rather than reserving a specific lot or location, which is what allows pallet swapping during picking as long as the substituted inventory still meets the item’s rotation requirements. If your facility runs a mix of case-pick and dynamic each-pick processes, you are very likely running both allocation types simultaneously without necessarily realizing the floor behavior difference is a direct consequence of which strategy is attached to which item.

Dynamic Allocation: How Rotation Rules Actually Drive Picker Behavior

Dynamic picking strategies sit inside the Dynamic Allocation module, and this is where rotation logic becomes operationally visible to your pickers in real time, rather than being an abstract configuration setting. The system supports multiple allocation strategies on the Outbound tab, including standard dynamic picking without cartonization and dynamic picking with cartonization, alongside FIFO rotation logic that determines which lot gets picked first.

What is worth understanding here is the Dynamic Picking Location Sort setting, which determines which locations get picked from first within a correct lot, and the Date Code Days field, which the system uses to calculate an upper and lower boundary date range to determine what product is eligible for picking. According to Infor’s documentation, this date range calculation is what allows the system to suggest a location where the lowest-dated, or FIFO, pallet sits, or conversely the highest-dated pallet for LIFO rotation, depending on how the item is configured. If your facility handles any kind of date-sensitive inventory, whether that is genuine shelf-life product or simply a customer requirement around code dates, this is the configuration layer that enforces it at the pick task level, not just at the allocation level, which means a picker scanning a location is being directed there because of this date math running in the background, not because of a static location assignment.

One operational detail that is easy to miss: administrators can change rotational selections without un-allocating existing shipment orders for an item, but if you are mid-pick on an order using dynamic allocation when that change happens, the documentation specifies you need to back out of the order completely and re-enter before the new rotation sequence takes effect. Teams that skip this step end up with inconsistent rotation behavior across a single wave, where some orders picked before the change reflect old rotation logic and orders picked after reflect the new logic, which looks like a system inconsistency but is actually expected behavior given how the change was applied mid-shift.

Cartonization Inside the Wave: Where Packing Logic Gets Decided

Cartonization is frequently treated as a packing-station concern, but the decision logic actually runs as part of the wave’s allocation output, and understanding this changes how you think about carton-related exceptions on the floor. Once an order is allocated, the application cartonizes the order by assigning unique case IDs to each line item that fits into a single carton type, based on the carton group configured for that item.

Infor’s documentation on cartonization is specific that the logic reviews critical dimensions first rather than liquid volume when identifying eligible cartons, and that the process depends on data sent from the host system with shipment order details to identify when commodities must ship in separate cartons or when a specific item quantity must be packed into a single carton. This is the layer of the wave algorithm that determines whether your packing team is fighting the system or working with it. If carton group configuration on the item master is incomplete or outdated relative to your current carton inventory, the cartonization step inside the wave will produce suboptimal carton assignments that surface as manual repacks downstream, and that gap is invisible in the Wave Maintenance screen because the wave still shows as successfully allocated even when the carton assignment underneath it is wrong. Teams running supply chain technology consulting engagements around fulfillment cost reduction often find this is one of the highest-leverage, lowest-visibility configuration gaps, because the cost shows up as labor minutes at pack, not as a wave error anywhere in the system.

Labor Standards and the Labor Engine: Calc Standards Explained

This is the part of the wave algorithm that turns a list of pick tasks into a labor forecast, and it is the piece most facilities either ignore entirely or only partially configure. Calc Standards is an action available on a wave, but it can only be selected once the wave is in Release to Task Manager status, which is itself a meaningful constraint, because it means labor standards calculation is tied to task generation, not to wave confirmation.

When you trigger the Calc Stds action, the system calls the Labor Engine to calculate standards across all picking assignments and full pallet picks on the wave, using the STARTLOC location as the initial starting point for each assignment and pallet pick when determining travel-based standards. A full pallet pick is specifically defined as a pick task where the quantity equals the pallet quantity configured on the pack, which matters because full pallet picks get evaluated separately from assignment-based picks in the standards calculation. The Labor Engine returns Estimated Labor values that populate the Total Expected Labor Time for Assignments and Total Expected Labor Time for Full Pallet Picks fields on the Wave Summary tab, giving you a labor forecast before a single pick is actually executed.

The detail that changes how teams operationally use this feature is that the entire calculation can run automatically at the moment a wave is released, rather than requiring a manual Calc Stds action, if the system setting CALCPICKLBRSTDSWAVE is turned on. Facilities that have this setting off are manually triggering labor forecasting as a separate step, which adds a point of human error into the workflow where someone forgets to run it, and the wave releases to the floor with no labor estimate attached at all. Turning this setting on converts labor forecasting from an optional manual step into a guaranteed output of every wave release, which is the difference between having labor data sometimes and having it every time, and that consistency is what actually makes labor variance reporting meaningful rather than a partial dataset with gaps you have to explain in every weekly review.

Wave Actions and the Release Sequence

Once a wave is built and allocated, the Wave Maintenance screen exposes a set of actions that move the wave through its lifecycle, and the sequencing of these actions is not arbitrary. Pre-allocate reserves inventory at the lot level, Allocate reserves the specific location and license plate, Release initiates the release process that generates pick tasks, Ship initiates the shipping process, and Close Order forces the shipping process to complete even for orders carrying an open quantity.

Un-allocate is worth a specific mention because of a behavior that catches teams off guard: it does not remove allocation information for the portion of an order already updated to Picked status. It only un-allocates records still in Allocated or Released status. This means if you need to fully reverse allocation on an order that has partial picks already recorded, Un-allocate alone will not get you there. You need the Unallocate Pick Details screen, or you need to delete the pick details within the shipment order directly, according to Infor’s own action reference. Teams that try to use a simple Un-allocate to back out a partially picked order end up confused when the order still shows picked quantity sitting against it, and that confusion is entirely avoidable once you understand Un-allocate was never designed to touch completed pick records in the first place.

Close Order carries its own cascade of automatic events that are worth knowing in advance rather than discovering during a live exception. When you close an order, the wave status updates to shipped once picked items ship, the open quantity on each line gets reduced to match what was actually picked, and any inventory that was allocated but never picked gets automatically un-allocated. If your Owner and Ship To configuration allows back ordering, a new order gets created automatically to capture the open quantity that did not ship. Picking against a closed wave is explicitly not permitted after this point, which is the system’s way of preventing a half-finished wave from silently absorbing late picks that nobody would otherwise notice were happening against an order that should have already shipped complete.

Wave-to-Load Integration for Outbound Planning

For facilities coordinating outbound trailers across multiple waves, the Load Maintenance screen provides a direct mechanical link between waves and loads that is easy to miss if you are only working inside Wave Maintenance. From Load Maintenance, selecting Release will both allocate the orders on the load and release the resulting tasks to Task Manager in a single action, while selecting Allocate performs allocation only, without generating tasks. Either action creates a wave automatically in the background and populates the new wave number directly on the Load Maintenance screen, which is what gives you a traceable link between a specific load and the wave that fulfilled it.

This wave-to-load connection is also what makes Pick by Load cluster picking viable as a staging strategy, since it lets associates pick directly against the structure of a specific outbound load rather than against an arbitrary wave grouping. For multi-stop or multi-carrier facilities, this is the mechanism that keeps load-level visibility intact even though the underlying execution is still happening through standard wave processing.

Putting the Algorithm to Work: Where Most Configuration Gaps Actually Live

None of the individual pieces described above are complicated in isolation. The Query Builder is a filter tool, pre-allocation and allocation are a two-step reservation process, the Labor Engine is a calculation service, and Wave Actions are a defined state machine. What makes the wave planning algorithm genuinely difficult to optimize is that these pieces interact, and a configuration decision made in one module quietly changes outcomes in another module that nobody is watching at the same time.

A wave limit set too high creates allocation backlogs that look like picking productivity problems. A rotation strategy changed mid-shift creates inconsistent pick behavior that looks like a data error. An incomplete carton group configuration creates pack-station delays that never show up as a wave-level exception anywhere in the system. None of these show up as errors in Infor WMS, because none of them are errors. They are the predictable downstream consequences of configuration choices that were correct at one point in your facility’s operating history and have not been revisited since.

This is the actual value of treating wave planning as an algorithm rather than a screen you click through. Once you understand the sequence, the dependencies, and where each step’s output feeds the next step’s input, auditing your own configuration against your current order profile becomes a structured exercise rather than a guessing game, and that structured approach is usually where the largest, fastest throughput gains in an already-implemented Infor WMS environment actually come from.

Frequently Asked Questions

Why does my wave show as allocated but pickers cannot find inventory at the suggested location?

This almost always traces back to the difference between pre-allocation and allocation. Pre-allocation determines the lot, and allocation determines the physical location and license plate based on that lot. If the lot pre-allocation selected exists in your system but not in a location your allocation strategy’s select-by criteria can find, allocation can complete against incorrect or stale location data. Check the allocation strategy’s location category and select-by configuration before assuming it is an inventory accuracy problem.

Why did Calc Standards not run on my wave even though I released it?

Calc Standards only runs automatically on release if the system setting CALCPICKLBRSTDSWAVE is turned on. If it is off, labor standards calculation requires a manual Calc Stds action from Wave Maintenance, and that action is only available once the wave has reached Release to Task Manager status. Confirm this system setting first before assuming the Labor Engine itself is malfunctioning.

Can I change rotation rules mid-shift without disrupting orders already being picked?

You can change rotational selections on an item without un-allocating existing shipment orders. However, if an associate is actively mid-pick on an order using dynamic allocation when the change is made, that order needs to be backed out completely and re-entered before the new rotation sequence applies. Orders picked before the change will reflect the old rotation logic for that pick session.

Why does Un-allocate not fully reverse an order I need to cancel?

Un-allocate intentionally does not touch line items already in Picked status. It only reverses records still in Allocated or Released status. For an order with partial picks that needs full reversal, use the Unallocate Pick Details screen, or delete the pick details directly within the shipment order, rather than relying on the standard Un-allocate action.

What is the actual difference between firm and soft allocation in practice?

Firm allocation reserves a specific lot, location, and license plate, placing a hard hold so that inventory cannot be moved or claimed by another order. Soft allocation, used in dynamic picking, only checks item-level availability rather than reserving a specific location, which is why dynamic picking allows pallet swapping during the pick as long as the substitute inventory still satisfies the item’s rotation requirement.

Why are my waves taking longer to allocate as order volume grows, even with no configuration changes?

Wave limits configured during initial implementation are based on the order volume and labor pool at that time. As volume grows without a corresponding review of wave limits, waves can become oversized relative to what your facility can realistically allocate and pick in a normal cycle, creating backlogs in Allocated status that present as a picking slowdown even though the root cause sits in the wave limits configuration, not on the floor.

Does cartonization happen before or after allocation?

Cartonization happens after allocation completes. Once an order is allocated, the system reviews critical dimensions and assigns unique case IDs to line items based on the carton group configured for each item. This means carton assignment quality is directly dependent on allocation having already produced an accurate, complete picture of what is being picked for that order.