Anyone who has stood at the end of a pick run knows the moment. The order is picked, the cases are staged, and now someone has to work out how they actually go on a pallet. Do you stack by weight or by what fits? Do you split the order across two pallets or try to cram it onto one? Get it wrong and you end up with a pallet that is too tall for the truck, too heavy for the customer's dock, or crushed because something delicate ended up on the bottom.
TBO4's Pick & Pack Manager now takes that decision away from guesswork. A new pallet calculation engine splits a released sales order into optimised shipping pallets before picking even starts, so the picker builds straight onto the pallet that was designed for that order, rather than figuring it out case by case.
Built on the data you already have
The engine draws everything it needs from data that already exists in your system: case dimensions and weight from the item master, stacking limits from the same source, and pallet weight, height and volume limits that can be set at the order, customer or warehouse level. Because it works off the item, order and warehouse master data rather than a third-party lookup service, it runs with any ERP that TBO4 integrates with. There is no external dependency to manage and nothing extra to maintain once the master data is set up correctly.
Two strategies, chosen per release
Not every order should be palletized the same way, so TBO4 gives you two strategies and lets you pick the right one for the job.
Fastest Pick puts one item on each pallet. It produces more pallets, but each one is simple to build and there is no stacking sequence to think about, which makes it well suited to local deliveries, pickups and short-haul freight where speed through the pick face matters more than freight efficiency.
Minimum Pallets mixes items on the same pallet to bring the pallet count down, building the heaviest product on the bottom and lighter product on top. It takes a little more care to build, but it is the better choice for LTL, interstate and long-haul freight, where every pallet position saved is a real reduction in freight cost.
Which strategy applies can be set per release, so a business shipping both local pickups and interstate freight from the same warehouse does not have to compromise on either.
How the engine actually builds a pallet
The calculation works in layers rather than loose cases. A layer is a set number of cases of one item, based on how many cases fit across a pallet footprint, and a pallet is simply a stack of layers. Before any layer is added to a pallet, it is checked against four limits: the pallet's weight capacity, its height limit, its volume capacity and, critically, how much weight the layer underneath can actually support. That last check matters more than it might sound. A layer of cases can hold up under its own limit but still fail if something heavier is stacked on top of it, so the engine checks cumulative load on every layer as it builds, not just the pallet total. If a layer would breach any of those limits, it does not get added. The rest of the quantity rolls onto a new pallet instead.
What that looks like on a real order
On a recent test order with two products, a fast-moving rice line and a lighter packaged goods line, the difference between the two strategies was concrete rather than theoretical. Built as single-item pallets, the order came to seven pallets. Built as mixed pallets under Minimum Pallets, heaviest product on the bottom, lighter product stacked on top, the same order came to five, with every pallet sitting comfortably within its weight, height and volume limits. That is two fewer pallet positions on the truck for the exact same order, with the stacking sequence worked out automatically so the picker never has to decide what goes where.
The same order also showed why the checks matter. One combination of products left less than three inches of clearance under the height limit before the calculation was even finished, which is the kind of margin that a taller pallet base or a bit of case variance can eat into completely. Rather than let a pallet get built that might not clear the limit in practice, the engine holds that clearance in the calculation from the start.
Failing safely, not silently
The engine is also built to stop rather than guess when the data it needs is not there. If an item's weight unit is missing or not recognised, if pallet dimensions have not been set at any of the order, customer or warehouse level, or if an item's cases per layer cannot be worked out from the master data, palletization stops and tells you exactly what is missing and where. That might feel like an extra step, but it is the deliberate trade-off behind the whole feature. A pallet quietly built on a bad assumption, an ounce treated as a pound, a missing stacking limit ignored, is far more expensive to discover on a loading dock than a validation message is to fix at the desk.
Why this matters beyond the pallet
Palletization is a small-looking step in the warehouse, but it sits right at the point where picking accuracy, freight cost and customer receiving requirements all meet. Getting it right automatically, using data you already hold rather than a separate calculation tool, is one more piece of the same story we keep coming back to: warehouse execution only gets faster and cheaper when the data behind it is trustworthy enough to act on without a person double-checking it by hand.
If you are palletizing by feel today, this is worth a look at what automating it could save on your next long-haul run.
