I am unclear exactly how you want to price shipping. The volume cost basis is about physical volume, not sales quantity.

On the cost basis, two of the options are By Item and By Product.

If you wanted a scale that adds up the number of different products in an order and reduces for larger numbers, I would select a cost basis by product and in the shipping cost rules handle that as a table that maps number of products to shipping cost.
1 product = $xx
2 products = $yy
...etc...

Is your cost based purely on number of different products in the order? or Is number of items also a consideration? Or the weight of the order?

You can select more than 1 cost basis, in which case any shipping cost rule is met only when all the cost basis measures for that rule are met.

So you could have a more complex table that has Items and Products.
1 item, 1 product = $xx
2 items, 1 product = $yy
2 items, 2 products =
3 items, 1 product =
3 items, 2 products =
3 items, 3 products =
.... etc....

You can do similar to incorporate weight, physical volume, or any other cost basis. For every cost basis measure added, the number of rules will obviously increase exponentially, so you probably want to keep it to 2 or 3 cost basis measures with occasional exceptions purely for your own convenience.

Thanks for the reply
I did some more button pushing after I posted. So far I am using the weight/ #of items / # of products and the total cost of the cart.
If I specify a weight of an item (AA) say 2.3lbs Would I be actually labelling that item as far as the zbs is concerned? So if I had two items of (AA) they would weight 4.6lbs . I could then have a rule that for 4.6lbs / two items/ one product/ value $XX the shipping cost is $YY.
Will the zbs logic lock on to exact weights eg: if I had another rule for 5lbs/ two items/one product/ value $XX. Then the order is for two items (AA) is placed should the zbs lock on the 4.6lb weight or will it go to the 5lb weight or is it a gray area?

Mike

The logic in the rules table is <= for comparisons and && (and) between comparisons. The rules are applied left to right. Unfortunately there are no grey areas in the way it works (computer programs don't do grey)

So your example is looking at a cost for: <=4.6lb && <=2 items && <=1 product.

If the weight is >4.6lb, the rule will fail and ZBS will go on to the next rule.

If the number of items is >2, the rule will fail and ZBS will go on to the next rule.

If the number of products is >1, the rule will fail and ZBS will go on to the next rule.

If you care to think of the process mathematically. Each cost basis adds a dimension to a matrix. You then flatten the matrix to just 2 dimensions to create the table, which means either (a) some cells within the matrix will be duplicated and you end up with an exponential size and a number of similar rows that only differ by 1 cell (Like in my items/products example above, where you can already see a lot of duplication/repetition); or (b) you had already duplicated information, so didn't need that many dimensions in the first place.

The duplication of cells and rows that differ by just one cell is not a bad thing. It is a necessary part of the process; if your calculation really is that complex then you will end up with lots of rows. Some users of zbs have 200+ rows. But maybe they also have much more complicated businesses. Rather than try and incorporate every small variable into their shipping their calculations, they have already reduced it to a few essential variables.

In your example, if you wanted 2 items of AA, 4.6/2.3 =2 is duplicating the information '2' of the items column. So perhaps if you took a step back and re-examined the overall problem, you will find that looking at it again leads to a simpler analysis. Before going to eCommerce, you had an office/shipping worker (maybe you) that worked out the cost of shipping an order. Was the mental gymnastics really that complex?

If you do actually need that complexity, then you can create a table of <= and && relationships between 3 different cost basis columns and a zone column to a shipping cost colum. Effectively flattening 5 dimensions of data into 2 dimensions.