What catch weight actually is
Start with the definition: catch weight is the actual recorded weight of an individual unit of a product that naturally varies in weight, used as the basis for pricing and inventory valuation instead of a fixed or nominal weight.
An example makes it clearer. Think of a filet mignon. No two cuts are identical, and in the food business every ounce is money. Without catch weight, every "8 oz" filet sells for the same $20 whether the cut actually weighs 6.5 oz or 9.5 oz. With catch weight, the item carries a weight tolerance (commonly +/- 20%), and each steak is priced by what it actually weighs. The same item number might invoice anywhere from $16 to $24 depending on the specific cut that was picked for that specific customer.
The customer pays for the steak they got. You get paid for the steak you shipped. That's the whole idea, and it's why catch weight is table stakes for meat, seafood, cheese, and produce distributors.
Now let's walk through the three areas where it matters most: product setup, order entry, and warehouse picking.
Product setup: get it right the first time
Catch weight starts on the released product, with a checkbox on the new-product dialog. Pay attention to that checkbox, because it's about as close to permanent as a setting gets in D365.
Next, units — the part of setup that trips up almost everyone. The inventory unit is the weight unit: pounds, kilograms, whatever you weigh in. The catch weight unit is the unit you actually buy and sell in, typically a case or a piece. We set the sales and purchasing units to the weight unit as well, because food pricing is almost always per pound. It feels backwards the first time you see it. It makes sense once you watch an order flow through, which we'll do in a minute.
Last up: nominal weight. The nominal weight comes from your unit conversions, so defining a conversion for every catch weight item isn't optional — it's the foundation. The bare minimum is the conversion between your catch weight unit and your inventory unit: 1 PC = 40 LB. With the nominal weight in place, you can set the minimum and maximum weight allowed per unit. Those boundaries are what keep a fat-fingered entry from turning a 40-pound case into a 400-pound one.
Order entry: two quantities, one line
Enter an order for a catch weight item and you'll see extra fields on the line. Which ones you can edit follows a pattern nobody guesses on the first try:
| Field | What it holds | Editable? |
|---|---|---|
| CW quantity | How many cases or pieces | Yes |
| CW unit | The catch weight unit | No |
| Quantity | The weight | No |
| Unit | The weight unit | Yes |
Most users live in the CW quantity field: the customer wants 15 cases, you type 15, and the weight fields take care of themselves. Until the pattern clicks, expect some "why is this field greyed out?" tickets. After it clicks, order entry is smooth.
Now, a recommendation born from experience: make your catch weight unit the lowest unit you could ever sell. For warehouse-enabled items, D365 requires the catch weight unit to be the lowest unit in the unit sequence group, and there is no going below it later. If your catch weight unit is piece, a small modification can enforce ordering in case multiples where you need it — you keep both options. If your catch weight unit is case and a customer wants to buy by the piece next year, you're looking at a second product or an ugly modification to the CW unit field on order lines. We've scoped that mod. You don't want it.
One more thing to set expectations on with your users: the weight that defaults onto a sales or purchase line is the nominal weight from the product setup. The real weight gets captured out in the warehouse during picking (or at the packing station), and you'll see it on the order once the packing slip posts. That actual weight is what gets invoiced. And in base D365, only the total weight per line is captured — which brings us to the warehouse.
Warehouse picking: where the gaps are
Two gaps in base D365 come up on nearly every food implementation we run.
Per-pick weight detail. If you want to know what each individual case or piece weighed, base D365 gives you one route: catch weight tags, which assign a tag and a weight to every catch weight unit received. Tags do the job, but they bring their own list of restrictions and add labor at receiving, so plenty of distributors pass on them. Beyond tags, capturing each pick's weight means a code modification that logs it to a separate table. For food distributors staring down traceability requirements, that detail is often worth the investment either way.
Cluster picking. Standard picking for catch weight items through the Warehouse Management mobile app works fine out of the box. Cluster picking does not — it's on Microsoft's documented list of unsupported scenarios for catch weight products. That one stings, because cluster picking is exactly what a food warehouse wants: one picker running two skids at once, position 1 and position 2, picking for both orders in a single pass through the warehouse. Out of the box, catch weight items force separate passes.
The practical workaround: set up a standard picking menu item for your catch weight items and keep a cluster picking menu item for everything else. Not elegant, but it keeps the warehouse moving without custom code on day one. If clustering catch weight picks is a must-have, budget for the modification.
Wrapping up
Catch weight solves a real problem well. It prices and values the product you actually shipped instead of pretending every case weighs the same, and for meat, seafood, cheese, and produce, that accuracy shows up directly in margin.
The cost of getting it wrong shows up early and is hard to unwind: the flag is permanent, the unit setup runs against instinct, and warehouse picking has holes around per-pick weights and cluster picking. So make the unit decisions deliberately — catch weight unit at the lowest level you could ever sell — and budget for a modification or two around order entry and picking.
Frequently asked questions
What is catch weight in Dynamics 365?
Catch weight is the actual recorded weight of an individual unit of a product that naturally varies in weight — a case of steaks, a wheel of cheese — used as the basis for pricing and inventory valuation instead of a fixed or nominal weight. In D365, a catch weight item carries two quantities on every transaction: a handling quantity in the catch weight unit (cases, pieces) and a weight quantity in the inventory unit (pounds, kilograms). The customer is invoiced for the actual weight shipped.
Can you turn catch weight on or off for an existing product?
Effectively no. The flag is set when the product is created, and an item with existing inventory transactions can't be changed in either direction. Once a catch weight item has been released, changing the designation requires deleting the item in every company where it exists — only possible if it has never been transacted on. Otherwise your option is to create a new product and transfer the inventory. Make the call during design.
How should units be set up for catch weight items?
The inventory unit is the weight unit (pounds, kilograms) — the unit the product is weighed and invoiced in — and the catch weight unit is the handling unit you buy and sell in, like a case or piece. A unit conversion between the two is required and defines the nominal weight (for example, 1 PC = 40 LB), and minimum and maximum quantities define the allowed weight range. For warehouse-enabled items, the catch weight unit must be the lowest unit in the unit sequence group, so choose the lowest unit you could ever sell.
Does D365 capture the individual weight of each case picked?
Out of the box, a sales line captures only the total weight for the line. The native route to per-unit weights is catch weight tags, which assign a tag and a weight to every catch weight unit received — but tags carry their own restrictions and add work at receiving. Many food distributors instead invest in a small code modification that records each pick's weight to a separate table, especially with traceability requirements in play.
Does D365 support cluster picking for catch weight items?
No — cluster picking is a documented unsupported scenario for catch weight products in D365 warehouse management. Standard sales order picking on the mobile device works fine. A common workaround is to route catch weight items through a standard picking menu item and keep cluster picking for everything else, or budget for a code modification if clustering catch weight picks is a must.
Caf2Code implements Dynamics 365 Supply Chain Management for food and beverage distributors — catch weight, advanced warehousing, and the modifications that bridge the gaps between them. If your products don't weigh what the item card says they do, we should talk.