Working with Item Lists
14 min
closing the technology gap between on floor sops and wms limitations in the paccurate pcs, the resource library can store editable carton lists, rules, rate tables, and box type generator assets that simplify your integration process and enable no code maintenance all of these types can be included by name on a per request basis by a client system along with item and quantity data to properly cartonize an order however, to get the most control and packing optimization, its critical for the paccurate api to know as much about the item as possible so it can apply criticial rules un codes, compressibility, orientation locking — any behavior associated with a specific item or group of items that contribute to optimal, compliant packs these item attributes can often be scattered across various systems of record, or exist simply as analog documents at a pack station how can paccurate collect and manage item information that will ensure proper packing? the item list resource what is an item list? an item list is, at its core, a table of item information relevant for packing identifiers (names, ids) and everything required to properly pack an item dimensional data, weight data, and any meta data that should inform how the item should pack, e g is it stackable, does it have inner space, can it compress, does it belong to a specific item or inventory category item list window item lists are saved in the paccurate api schema, making integrations simpler — simply include a reference to the list in your payload, and it will match items in the itemsets of your payload to the saved information in the item list { "itemsets" \[ { "quantity" 9, "name" "visor 1002" } ], "packresources" \[ 	 "3pl demo cartons demo wms cartons 162", 	 "hats apparel stacking hat cartons items xlsx 165" ], "orderid" "10142025 3" } json payload using an item list resource for item data { "itemsets" \[ { "orderid" "9119319", "refid" 7760001, "quantity" 9, "weight" 0 24, "dimensions" { "z" 7 5, "y" 7 8, "x" 4 3 }, "name" "visor 1002", "color" "#02b83d", "sequence" "" } ], "packresources" \["3pl demo cartons demo wms cartons 162"], "orderid" "10142025 2" } standard item set definition tem lists can function either as a replacement for the client system’s stored dimensions, or in addition to information stored in the client system it gives users the opportunity to augment limited sku data and inform the paccurate api that items contain special characteristics that inform its packing item lists can be manually uploaded and maintained, or programmatically updated using api credentials (available to enterprise users only, contact your cs manager or our sales team to learn more) how does it differ from an item master? an item list, unlike an item master, is used primarily for cartonization as opposed to inventory allocation, slotting, and replenishment tracking it serves the purpose of letting operators make adjustments to an item’s characteristics that are relevant for proper packing, without modifying anything upstream in an item master its objective is modularity and flexibility, and focuses primarily on the packing behavior of an individual unit when should i use an item list? during the integration process, outline the packing requirements (rules, sops) for your items consider the technical lift that may be needed to capture any item data that is necessary to achieve optimal packing inner space, fragility, orientation locking, stackability, soft goods — are these behaviors that are already available somehow in your client system? if the answer to that is no, an item list may be the right fit you can take institutional knowledge of these behaviors and attach them to records in the item list — either using the editor directly or doing it in excel and uploading in bulk the item list enables operators to tag and categorize their item data specifically for paccurate to use and without the required involvement of it post integration questions to ask when considering using the items list is all the data i need for cartonization easily accessible? do i need to store more item data than my wms can provide? would having more control over categorization / grouping simplify packing rule creation? matching and merging item data when using an item list as part of your resource enabled integration, it’s important to consider what value you want to use as the key to matching resource data up with your client system at present, we support matching on the refid and name fields for example, if your client system only has upc data available, you’ll likely want to use that as the source of truth { 	"itemsets" \[ 	 { 	 "refid" 325050, 	 "quantity" 4 	 	 } 	], 	"packresources" \["your item list", "your carton list", "your rules list"] } in the example above, we’ve provided a payload of just the item’s refid and quantity — the rest of the work will be handled by the api to reference the required resources in the packresources array and handle cartonization based on the combination of all of those resources example flow let’s use some item list captured values to cartonize and apply a rule consider the item in the item list screenshot below it has a refid, sequence, length, width, height, and additional properties — all captured as part of a dimensioning effort we want to change the dimensions based on a value that we know will be present in the item’s properties value, called “stack ” the items are going to be reduced in size to fit better into a box we’ll include in the payload with the resources created in the pcs, the client system can make the call to our resources enabled api (https //resources api paccurate io) { "orderid" "test property rules", "itemsets" \[ { "refid" 325050, "quantity" 3 } ], "boxtypes" \[{ "name" "big box", "dimensions" { "x" 200, "y" 300, "z" 400 } }], "packresources" \[ "auto generated from rave qboid test drzm8 178", "b44fea8e7e8b4d2c2b01358775353530 stack property resize 383" ] } once the resources are paired with the item, we get the following item definition { "dimensions" { "x" 169, "y" 244, "z" 374 }, "properties" { "image" "fullres/2025/09/17/image/79688463a2f64ebc974441220e5b952b jpeg", "stack" "internalspace" }, "quantity" 3, "refid" 325050, "sequence" "0502c001" } notice fully dimensions, full property object, and item sequence the rules payload expands as well "rules" \[ { "comment" "", "itemmatch" { "expression" "internalspace", "property" "stack" }, "operation" "alternate dimensions", "options" { "dimensionscalechanges" \[ { "x" 0 3, "y" 0 5, "z" 0 75 } ], "replaceoriginal" true } } ] and we wind up with the https //inspector manage paccurate io/config editor?packuuid=019d3f95 64ba 70d2 bf36 0192a62a6628\&embed=true our items fit in the “big box” and the alternate dimensions rule is applied to all 3 axes z (length) is reduced by 75% from 374 to 118 3 y (width) is reduced by 50% from 244 to 122 x (height) is reduced by 30% from 169 to 93 5 conclusion using the item list as an active resource type allows operators to let the pcs do the heavy lifting of storing any data needed for advanced packing custom properties, packing sequences, and rules can all live within the pcs resource library and any client system only needs to tell our api what items need to be cartonized and what resources are needed to do so this significantly reduces integration overhead and grants a lot more power to operations teams
