User Group only Shipping costs?

I've set up a store for a manufacturer who also uses it to resupply his resellers. Using Joomla, there is a user-group protected inventory of reseller products (display boxes, multipacks, etc.)

His postage on international orders is already determined by weight ( 17 zones by 7 tiers = 119 Shipping Rules. You really need a reasonable way to manage that.), fixed price with tax on orders from his state, fixed price with no tax on orders from continental US.

What he is asking for is free shipping for resellers who order more than 12 items. I know I can enter a volume of 1 on all items and tally them to trip a rule, but I can't see a way to limit this rule to members of a certain User Group, "Resellers." Is that possible?




I have attempted to write my own shipping plugin with his price matrix, but failed: your API encourages the determination among existing shipping rules, not the calculation of a shipping amount on the fly. This doesn't save me any time or effort. I managed to get one that DID this calculation and delivered it to the Usable Rates array, Shipping selection screen and pre-selected rate value, but upon selection/order creation, HS apparently went back to its shipping rules and recalculated shipping for the order without using the plugin overrides. It was as if the cart rendering view was entirely isolated from the Shipping processes I was working on. I was not even able to confirm that onShippingSave() was ever called - I could complete an order without a die() statement within that method ever being tripped. It's like trying to build watches in an unlit room.

Please write a tutorial or two for the shipping and payment APIs. A definition of the two or three method calls is not enough for most of us: If you actually want the API calls to be used, we need a bit more context of what is going on around those processes and what variables/objects we need to juggle.

Thanks.

OK, I'll relay the Business Edition news to the customer. He's a bit cranky and was trying to avoid that step.

On the UsableMethods part, that's precisely the behavior I hoped for except it didn't work out that way. I had a working plugin that overrode the necessary UsableMethods values (as well as in the matching entry of the methods list) and the constructed shipping portion of the view worked as expected. It even posted the appropriate information. The problem was that my checkout process is "login_address_shipping,payment_cart_coupon_confirm_status_fields,end".

The login/address/shipping page behaved as I expected, but when the order proceeded to the payment/cart/coupon/confirm/status page, it recalculated the shipping amount according to the flat rules, not the selection made on the previous view - the plugin calculated rate according to weight/nationality with an override for Resellers with carts with over a specified number of items.

My customer's retail audience is largely elderly and often discouraged by long complex form pages, so I broke the checkout process into less visually intimidating steps. Setting usableMethod values on the first page had no effect on the shipping value displayed in the second page. That's where I gave up. I'd love it if there's a piece I'm missing that would resolve that. I hope you can help me find it.

I'm sorry if my message seemed terse: I couldn't tell from the documentation whether I had interpreted the work which needed to be accomplished correctly or not, and had already resolved myself to defeat.

OK, that description makes sense to me: The manual plugin was far easier to dissect, so that's where I started. I see a few changes to try.

With your suggestions, I will try again. But I want to reiterate, documentation that includes a more robust explanation of the entire checkout process would make customizing such plugins much easier and faster. I know that there's never enough time, but this floundering around is frustrating.

Thank you for your help.