Shipping cost to weight

[Nordic]

Hi,

would really like to have a shipping logic so that it can be set as a factor of items weight. Also an extra COD fee that is a static fee on top of the wieght based fee.

Thanks,
-Nordic

[netman]

I, too, would like to see the ability to include a flat fee to be included when orders are paid COD

[coastalrugs]

Adding my vote here as well for a flat-fee portion inside a Shipping Rule.


Abstract:
In the Shipping Rules:
Adding a line 'per pound' (next to the current, 'per order' and 'per item').

Currently:
[ 1.25 ] ($) (per item)

Proposed Modification:
[ 1.25 ] ($) (per pound) ** [ 5 ] ($) ( first pound ) **

The [ 5 ] ( first pound ) is an area to define the base shipping fee for the order. If left blank, then the straight multiplier ( 1.25 x weight ) would be used.


Supplemental:
This field could actually be available with the other methods, and used as a COD fee. The actual wording of the option could probably be made more ambiguous, instead of 'first pound', perhaps 'first unit'. However, the field would not make much sense with a 'Per Order' shipping rule, so should be hidden in that case.


Details:
The numerical portion would selectively be be either a fixed ($) or percentage (%), independent of the of the adjacent scaling rate.

Options for the 'type' of flat fee could include:
'first pound' - which would effectively subtract a pound from the weight:
5lbs = (1lb x 5) + (4lb x 1.25) = 10.00

'flat fee' - does not affect total weight:
5lbs = (5 flat fee) + (5lb x 1.25) = 11.25

In conjunction with the 'Supplemental' information, the calculations could treat 'items' and 'pounds' equivalently.


Idealism:
The above represents an incorporation of the current structure of the Shipping Rule form. ideally, I would like to see a table-based solution:

'Per Pound' is chosen, and a text area is presented that the user could input something like the following:

Weight Rates:
5=1.25|5
10=2|2.5
X=1|2

(<=weight) = (per unit price [|base fee(optional)] )

The 'X' entry would be to control any weight that is beyond the defined table.

Double Idealism:
Perhaps instead of a table, the user could be presented with a polished JavaScript front-end that in effect does this same thing, just parses the data and presents to the user with checkboxes and text fields, etc. The DB entry would remain intrinsically a text field, but just with a JS form validation mask over top. So no new DB relationships need be established/maintained.

[coastalrugs]

However, the field would not make much sense with a 'Per Order' shipping rule, so should be hidden in that case.

Just realized, there may be times when this could be used/useful in a 'per order' situation. Think: base fee plus item/weight scalar, but on an order level:

[2] (%) (per order) ** [20] ($) (flat fee)

$100 product total = (2% x $100 = $2) + ($20 flat fee) = $22 shipping

The 'failure', if you want to call it that' is when a choice for 'per order' is selected with a 'per unit' choice in the requested be fee area. Since there is only one 'unit' (the order itself), a choice of 'first unit' would not make sense at all.


(sorry for quoting myself, since I can't edit the post)

[criznach]

I've implemented a dirty hack to make manual weight based shipping rules work. I've written a php script to add a bunch of flat rate shipping rules for weight ranges. I specify the cost per pound and the max weight, and it builds the rules. So far so good... This was done to allow manual shipping charge modifications per option, which squirrelcart does not support.

This was for an art gallery and gift shop client that has a variety of shipping needs and prefers to set shipping manually. They also needed to be able to track shipping cost per order, so working the shipping into the option price modifier wasn't good enough.