Packing Apparel

apparel is one of the most challenging categories to cartonize well items are soft, compressible, foldable, and often shipped in poly bags or tissue that never show up in a wms item master this guide walks ops managers through the pcs rules that solve for those characteristics, and how to store apparel specific packing data so those rules keep working as your catalog grows each section below pairs a packing challenge with the rule that solves it, a working json example, and a link to the full rule documentation for deeper reference model the garment as it ships, not as it hangs the single most important decision in apparel cartonization happens before any rule is written what dimensions do you feed the api? a t shirt on a hanger might measure 24" x 18" x 1", but folded for shipping it's closer to 10" x 8" x 1 5" always define dimensions in the folded, as shipped state — that's the baseline every rule below builds on because folded dimensions, fold behavior, and stack behavior are rarely sitting in a wms or item master, most apparel operations store them in a paccurate item list instead an item list lets an ops manager maintain per sku packing data — dimensions, sequence, and custom properties like fold type or stackability — directly in the pcs, without asking engineering to change the integration payload see working with item lists for the full walkthrough of how matching and merging works a request only needs to send an identifier, quantity, and the relevant resources { "itemsets" \[ { "refid" 88213, "quantity" 6 } ], "packresources" \[ "apparel item list 142", "apparel carton list 118", "apparel rules 176" ], "orderid" "apparel 0001" } the api fills in dimensions, weight, sequence, and properties from the item list, then applies whichever rules match those values everything that follows in this guide assumes that setup — matching rules against a sequence or properties value that lives on the sku record handling multiple fold configurations with alternate dimensions some garments can be folded more than one way depending on the box they're going into — a hoodie folded flat versus rolled, for example alternate dimensions gives the engine a set of options to choose from instead of a single fixed size { "operation" "alternate dimensions", "itemmatch" { "property" "sequence", "expression" "hoodie" }, "options" { "dimensions" \[ { "x" 3, "y" 10, "z" 14 }, { "x" 5, "y" 8, "z" 10 } ], "replaceoriginal" true } } the engine tests each option and keeps whichever produces the best pack set replaceoriginal true when the item's default dimensions represent the unfolded or hung state and should never be used for packing on their own letting soft goods flow to fill the box with bounded fill alternate dimensions works well when you already know a garment's exact folded configurations most wms cartonization instead relies on liquid fill sum an order's total volume and find the smallest box it technically fits into that math can look perfect on paper while suggesting a single folded shirt gets split across two disconnected pockets of space in a box — a configuration no packer at a table can actually build bounded fill gives specific items that same liquid fill flexibility while keeping the result physically real you lock one dimension — typically whichever one matters most for that garment — and let the other two expand or compress to fill whatever contiguous space remains in the box nothing gets split across gaps; the item conforms to a single region, in one piece, the way a person would actually pack it { "operation" "bounded fill", "itemmatch" { "property" "name", "expression" "soft 10" }, "options" { "criticalaxis" 1 } } criticalaxis behaves like freeaxes on lock orientation the index you provide is the dimension that stays fixed 1 above locks the y (width) axis and lets x and z flow to fill the box applied to a mixed order, this pattern reduced shipping cost by about a dollar per shipment for one apparel retailer — by finding packs that were efficient and buildable at the pack station, not just efficient on paper bounded fill doesn't replace alternate dimensions — the two solve different parts of the same problem alternate dimensions is precise and explicit reduce by 10%, use these exact lengths and widths, when you already know a garment's specific fold states bounded fill is more general it lets an item flow into whatever space is left, which suits soft goods where you don't want to enumerate every possible folded configuration by hand many apparel catalogs end up using both — alternate dimensions for a handful of known fold types, bounded fill for the long tail of soft skus that just need to flex into the box full background on the rule is in bounded fill stacking soft goods with compact pattern folded dress shirts, stacked denim, and packed hats all compress when placed on top of one another — the tenth shirt in a stack doesn't add as much height as the first compact pattern models that compression so volume estimates stay accurate on high quantity, single sku orders like replenishment shipments { "operation" "compact pattern", "itemmatch" { "property" "category", "expression" "hats" }, "options" { "compactibleaxes" \[1], "compactproperties" \[ { "targetrefid" null, "compactibleaxisdimensionchange" \[{ "y" 6 }] } ] } } here, every additional hat placed on top of another instance of itself (targetrefid null) has its height reduced by 6" rather than adding its full width compactibleaxes and compactproperties support multiple axes and multiple target items — see stacking & nesting for the complete option reference, including how alternating behavior works for items that compact against different neighbors nesting accessories inside apparel packaging the same doc covers internal space, which creates a subspace inside a larger item — useful when a shoe box, garment bag, or hard sided case has room for smaller accessories (socks, laces, care cards) to be packed inside it rather than taking up separate cube in the outer carton it's a smaller use case in apparel than in categories like housewares, but worth knowing about if your catalog includes rigid packaging reserving space for poly bags and tissue with reservedspace apparel is almost always poly bagged or wrapped in tissue, and that material takes up real volume that item dimensions alone won't account for reservedspace is a top level, pack level parameter — not a rule — that reserves a percentage of every box for dunnage and packaging { "reservedspace" 0 05 } a value of 0 05 holds back 5% of each box's volume, which keeps the engine from overpacking cartons that look full on paper but aren't in practice most apparel operations land between 0 03 and 0 07 depending on how much packaging material is used per unit keeping branded packaging intact premium or gifted items — a branded shoe box, a jacket in its own retail carton — often can't be commingled with other skus two rules cover this exclude all keeps an item out of any shared carton entirely { "operation" "exclude all", "itemmatch" { "property" "sequence", "expression" "gift box" } } pack as is is for items whose own packaging is the shipping carton — no overboxing at all { "operation" "pack as is", "itemmatch" { "property" "sequence", "expression" "sioc" } } multi packs and case configurations with dimensionsets apparel frequently ships in more than one handling unit for the same sku — a 3 pack of socks versus a single pair, or a case of the same shirt style going to a store versus an each going direct to a consumer rather than creating separate skus for every pack size, dimensionsets lets one item definition carry multiple sets of dimensions, weights, and quantity divisors { "dimensionsets" \[ { "unitofmeasure" "each", "quantitydivisor" 1, "weight" 0 3, "dimensions" { "x" 8, "y" 6, "z" 1 } }, { "unitofmeasure" "case", "quantitydivisor" 24, "weight" 7 5, "dimensions" { "x" 18, "y" 14, "z" 10 } } ] } with a total order quantity of 30, the api returns one "case" unit and 6 "each" units automatically this is the same mechanism used for wholesale and store replenishment orders that mix eaches and cases in a single shipment — full detail, including how the api assigns and reports the chosen dimensionset, is in working with handling units bundling sets and kits with pack sequence apparel orders often need one packing step to happen before another — a bra and underwear set poly bagged as a kit before it goes into a shipping carton, or a set of matching separates bundled together ahead of final packout pack sequence handles this in a single api request instead of chaining calls { "rules" \[ { "operation" "exclude", "itemmatch" { "property" "sequence", "expression" "set bundle", "negate" true }, "targetboxmatch" { "property" "name", "expression" "kit bag" }, "comment" "non set items excluded from the kit bag" }, { "operation" "pack sequence", "itemmatch" { "property" "sequence", "expression" "set bundle" }, "options" { "index" 0, "reduce" "box to item", "reducedrefid" 1000, "comment" "bag the set first" } } ] } items tagged set bundle in sequence are packed into a kit bag boxtype first; that bagged kit is then reduced to a single item (reducedrefid 1000) and packed into the outer shipping carton alongside anything else in the order the full walkthrough — including a right sized kit box built with boxtypegenerators, and how to extend the pattern from carton to pallet — is in multi stage packing sorting and box strategy for mixed orders mixed apparel orders — multiple skus, sizes, and categories in one shipment — are sensitive to how items are sorted before packing a few starting points itemsort "largest cross section" — works well for flat, folded items itemsort "all" — exhaustive and highest quality; reserve this for batch or non real time runs itemsortdualdirection true — also tries the reverse of whichever sort you pick on the box side polybag mailers — define polybag dimensions as a boxtype with a weightmax, so the engine prefers them for small, single item soft goods orders multiple box sizes with boxtypechoicestyle "actual" — apparel order volume varies widely; giving the engine 3–4 box sizes and letting it evaluate the actual fit (slower, but worth it for dtc shipping cost) finds a tighter match than a single default carton usablespace set around 0 85 — soft goods compress and fill space well, so a higher usable space value helps the estimated box choice style make better calls without needing the slower actual style everywhere putting it together in the pcs every rule above — compact pattern, alternate dimensions, bounded fill, exclude/exclude all/pack as is, dimensionsets, pack sequence — can be saved as a resource in pacmanage™'s resource library and referenced by name instead of rebuilt in every request paired with an item list holding your apparel skus' folded dimensions and custom properties (fold type, stack behavior, kit grouping), a client system only needs to send an identifier and quantity { "rules" \[ { "operation" "exclude", "itemmatch" { "property" "sequence", "expression" "set bundle", "negate" true }, "targetboxmatch" { "property" "name", "expression" "kit bag" }, "comment" "non set items excluded from the kit bag" }, { "operation" "pack sequence", "itemmatch" { "property" "sequence", "expression" "set bundle" }, "options" { "index" 0, "reduce" "box to item", "reducedrefid" 1000, "comment" "bag the set first" } } ] } that separation matters operationally ops managers can update fold behavior, add a new kit grouping, or adjust reservedspace for a new poly bag vendor entirely inside pacmanage™'s inspector — testing the change against real orders before deploying — with no engineering involvement or wms change required summary checklist consideration recommendation item dimensions store folded/as shipped state in an item list compressible soft goods compact pattern multiple known fold configurations alternate dimensions soft goods without discrete fold states bounded fill accessories inside rigid packaging internal space dunnage / poly bags reservedspace 0 03–0 07 branded or gift packaging exclude all or pack as is multi packs and case packs dimensionsets kits and bundled sets pack sequence mixed sku orders itemsort "combined" box selection boxtypechoicestyle "actual" • multiple box sizes volume estimate tuning usablespace 0 85 conclusion apparel rewards the operations teams who model it precisely folded dimensions, compaction behavior, dunnage, and kit logic each pull cartonization in a different direction — but stored once in an item list and a handful of pacmanage™ resources, they stop being one off configuration and start being reusable packing logic that scales with the catalog start with folded dimensions and reservedspace, layer in compact pattern and dimensionsets as multi packs come online, and add pack sequence once kitting or bundled sets enter the mix