Properties and Constraints

learn how to use custom item properties to drive more precise and sophisticated packing behavior the paccurate api has robust support for packing rules and procedures you can squish, stack, and exclude items, force items to pack alone or with extra dunnage, or pack in fully custom box sizes as our customer base has grown, so has the complexity of packing requirements variable limits on attributes like ice for cold chain or q value for hazmat shipments additionally, customers often want to track item attributes wherever the cartonization response is stored in order to handle these requirements, we have introduced new attributes to our api schema properties and constraints to better understand how properties and constraints work with each other, let’s start with a scenario a shipper called modern electronics supplies myriad rechargeable items — laptops, cell phones, power banks, etc, each with varying sizes of batteries while all of these items can be shipped with one another, no shipped carton can exceed a battery weight of 3lbs, per federal safety regulations as we know, carton’s typical weight limit is much higher than that, and electronics often exceed that weight already how can we make sure items are packed logically, while respecting these battery weight constraints? enter item properties properties are simple a map of key/value pairs keys are strings, and values can be any number type or a string item properties are returned in the pack response regardless of type number types are used in conjunction with propertyconstraints , which we’ll address shortly here’s an example of an order from modern electronics with properties defined on each item json { 	"itemsets" \[ 	 { 	 "name" "pear laptop", 	 "quantity" 2, 	 "weight" 4 01, 	 "dimensions" { 	 "x" 2, 	 "y" 6, 	 "z" 11 	 }, 	 "properties" { 	 "battweight" 0 55, 	 "hd" "ssd512", 	 "bin location id" "c 8902" 	 } 	 }, 	 { 	 "name" "robo tablet", 	 "quantity" 4, 	 "weight" 1 89, 	 "dimensions" { 	 "x" 1 3, 	 "y" 5, 	 "z" 8 	 }, 	 "properties" { 	 "battweight" 0 37, 	 "hd" "ssd64", 	 "bin location id" "h 1730" 	 } 	 }, 	] } in the snippet above, we’ve added a property called battweight to track the battery weight of each item, along with additional properties flagging the type of hard drive contained in the item and bin location to be tracked in client systems or added to a print ticket at packout next, let’s see how to leverage the properties to drive cartonization decisions modern electronics only has 3 different handling units, and each one has different limits on how much battery weight can be shipped within it let’s define them below json { 	"boxtypes" \[ 	 { 	 "name" "med heavy", 	 "weightmax" 50, 	 "dimensions" { 	 "x" 11, 	 "y" 6, 	 "z" 12 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 1 2 	 } 	 ] 	 }, 	 { 	 "name" "lg heavy", 	 "weightmax" 50, 	 "dimensions" { 	 "x" 13, 	 "y" 11, 	 "z" 17 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 1 3, 	 "aggregate" "sum" 	 } 	 ] 	 }, 	 { 	 "name" "sm mailer", 	 "weightmax" 8, 	 "dimensions" { 	 "x" 4, 	 "y" 13, 	 "z" 15 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 0 5, 	 "aggregate" "sum" 	 } 	 ] 	 } 	] } the propertyconstraints attribute is an array of constraint definitions each constraint has 4 attributes key the property to be constrained max the maximum allowed value for the property in the carton aggregate defines how to combine new property values (currently only "sum" is available) value the initial property value to which item properties will aggregate (for example, an ice pack's starting value) as items are packed into a box, packer’s algorithm monitors their constrained properties while our example only tracks one property ( battweight ), you can monitor and constrain multiple properties once a constraint's max value is reached, the box won't accept any additional items that would exceed that limit json { 	"itemsets" \[ 	 { 	 "name" "pear laptop", 	 "quantity" 2, 	 "weight" 4 01, 	 "dimensions" { 	 "x" 2, 	 "y" 6, 	 "z" 11 	 }, 	 "properties" { 	 "battweight" 0 55, 	 "hd" "ssd512", 	 "bin location id" "c 8902" 	 } 	 }, 	 { 	 "name" "robo tablet", 	 "quantity" 4, 	 "weight" 1 89, 	 "dimensions" { 	 "x" 1 3, 	 "y" 5, 	 "z" 8 	 }, 	 "properties" { 	 "battweight" 0 37, 	 "hd" "ssd64", 	 "bin location id" "h 1730" 	 } 	 } 	], 	"boxtypes" \[ 	 { 	 "name" "med heavy", 	 "weightmax" 50, 	 "dimensions" { 	 "x" 11, 	 "y" 6, 	 "z" 12 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 1 2 	 } 	 ] 	 }, 	 { 	 "name" "lg heavy", 	 "weightmax" 50, 	 "dimensions" { 	 "x" 13, 	 "y" 11, 	 "z" 17 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 1 3, 	 "aggregate" "sum" 	 } 	 ] 	 }, 	 { 	 "name" "sm mailer", 	 "weightmax" 8, 	 "dimensions" { 	 "x" 4, 	 "y" 13, 	 "z" 15 	 }, 	 "propertyconstraints" \[ 	 { 	 "key" "battweight", 	 "max" 0 5, 	 "aggregate" "sum" 	 } 	 ] 	 } 	] } \\ as we can see in the api response https //inspector manage paccurate io/config editor?packuuid=cd440d1cbd4db9b0a0447ef91fec6e8f0c5a058ac60e11a981e1b0d455ad203c3b1124ab599b76dd7530e749ccd0424f715108268149b87f382c160601f13927 , this order requires three different containers due to battery weight limits the pear laptop has a battery weight of 55 , which immediately disqualifies it from the sm mailer the med heavy box can accommodate exactly two laptops, as their combined battery weight of 1 1 approaches the box's maximum constraint of 1 2 the four tablets have a total battery weight of 1 48—exceeding both the med heavy and lg heavy box limits as a result, three tablets are packed in the med heavy box, while the fourth goes into the sm mailer box let's examine the response for this request while the api returns comprehensive data about cost, volume, and item placement for each packed box, it now also includes calculated properties within the propertyconstraints attribute here's what the api returns for the first box's constraints json { "propertyconstraints" \[ { "key" "battweight", "max" 1 2, "value" 1 1 } ] } the value is the total value of the key property in the box — in this case, it is 55 x 2 = 1 1 remember the other properties we sent along with each item? they are also present in the box’s items array for each instance of the item to be tracked by any system that may need to save and consume the pack response the properties are present in the json response shown below json { "item" { "centerofmass" { "x" 3, "y" 3, "z" 5 5 }, "color" "aqua", "deltacost" 0, "dimensions" { "x" 2, "y" 6, "z" 11 }, "globalid" 1, "index" 2, "message" "packed #1 in 9 222µs at 2 479486ms in box(name\ med heavy dimensions \[11,6,12] weight 50 index 0)", "name" "pear laptop", "origin" { "x" 2, "y" 0, "z" 0 }, "packedindex" 1, "properties" { "hd" "ssd512", "battweight" 0 55, "bin location id" "c 8902" }, "quantity" 1, "refid" 0, "sequence" "", "uniqueid" "0 1", "virtual" false, "weight" 4 01 } } this example demonstrates how to use item properties and constraints in your cartonization process the key/value pair system allows you to include any wms or erp system attributes in your cartonization requests for advanced packing rules here are some common applications of property limits cold chain coolant limiting hazmat q value tracking kitting limiting number of specific skus a carton could contain contact us if you need help implementing these features