Complex Shipping - ideas wanted

This is the way the real-world store works...

1. Free shipping on Product Group A and Product Group B in the UK.
2. Flat rate for Product Groups C, D & E, and a sub-group of Product Group F
3. Product Group F by quantity and postcode. * if sub-group of Product Group F is on same order as Panels, they are free.
4. Product Group G is based on the purchase costs.

Ideally, I want to end up with the customer seeing ONLY the shipping which applies to their order. I've spent a couple of days thinking about this and I'm starting to go round in circles, so I'm looking for ideas as to how to make it work.

I'm sure that it's feasible to display a shipping module dependant on Product Group (either by using a part of the model no as ref, or being from the same category, or perhaps as a product type) and realise that this will require coding, but suggestions will be welcome.

Free shipping on everything with price adjustment is NOT an option for my client.

Shipping has become a high priority for us recently, so I've had to put the reporting class on the back burner (although its only a few hours away from releasing to the community).

I have started a new "zone" system as follows.

Zone - Fields: Classification & Value
Group - Fields Group Name
GroupZone - links many Zones to a group (zones can belong to more then 1 group).

So far thats basically what we have in ZenCart.

ShippingModule - Zone : Fields ShippingModule_Id, Group_Id, InclusionFlag.

Now for example:

Zone - Classification can be PostalCode, Province/State, Country, City
Value - is a wild card value so things like T4C-1L6 can be done as T?C-*

So if I wanted all people in the city of Calgary to have flat pricing I can do that by saying I want the group "Calgary" included for this shipping module. I can then say I want the group "Calgary exluded from CanadaPost.

so what I have been building as step one is a class that can be linked into any existing shipping modules to allow more flexibility when it will show. THe problem with the current system is you can only select a single "zone".

What I have done is create my own set of tables for this so I'm not going to break any existing modules.

Now What RYK said is interesting as it falls into my next question, which is what types of shipping requirements are needed and then I want to create a "generic" set of classes that can be initially linked into existing modules, but eventually I want those to be re-written as well to be more flexible.

Now the discovery componend of this exersize:

1. Product requirements

   • Products should be able to link to different shipping methods, OR be excluded from shipping methods (individually or based on category).
   • Not sure what product groups are, so not sure how to implement on prod groupings.

2. Shipping criteria (on order).
   Attributes to manage:

   • Total Shipment (Size, Weight, & Cost)
   • Individual Product Size. Weight & Cost
   • Distance to ship.

   Each of the above can affect the shipping costs, and what shipping modules should be shown.

   Every shipment could have a component from each of these:

   • we control the shipping cost, or
   • 3rd Party controls (UPS, FedEx, Postal Service).

Types of shipping:
We have
* Free Shipping,
* Flat Rate per Region,
* Based on Purchase Cost
* Based on weight / size (total order or individual items)
* or totally based on 3rd Party.

So what other factors need to be considered?
What other conditions do we need to be concerned with? such as I want product a shipped free when linked to product B. Or if order is over X then shipping is free, etc.

Please list all you can think of and an importance factor to you. I will categorize them. and will try and plan out a way of implementing a core set of them. Now not all conditions will be implemented.

Once I have made a list then I'll ask for feedback on the recomendations. Then based on my non-existant time I'll work at implementing a module to make this work. (or beg other people to support this initiative and do some of the coding....hint..hint...hint...)

I was using the phrase Product Group to signify a collection of different products to avoid confusion with the ZC product types. I guess category would be as good as anything.

I've modified my "overview" slightly and spent a while figuring out the various options - I'm waiting for the client to get back to me with regards to accuracy, but the attached doc may be of interest (or it may not! :laugh: )...ahh, there's a ridiculously low filesize limit for doc (& pdf) files whioch must be less than a single page, so if you'd like a look at it quentin, please pm me with an e-mail address.

Unfortunately, I'm no coder myself so I'll not be a lot of use to you in that respect.

Well my resume is about 7 pages long, and thats after heavy pruning. I have everything from developer, business analyst to architect on there, whats missing is designer, graphic artist, webmaster and entrepeneur.

Anyways what ever you can provide will work to build the design requirements and then the implementation documents. I hope to build a framework using patterns and perhaps the neat NOS system (Notify & Observe System) that Zen has to make the shipping something very flexible and useful.

I hope the Zenners can provide input as well as they have been heavily involved in the system since before it was called Zen :-) and know a lot of gotchas that will save a lot of grief in the long run.

:P

I don't know if it'll help you in your efforts quentin, but I've managed to reduce my problem down to basically 5 groups of products with 4 different shipping charges (including FREE) to be applied (the fifth group is really a sub-group which attracts a FLAT rate when ordered separate from its parent group, but is FREE when with the parent group).

In my case, the client is prepared to utilise the Product Model Nos to identify which "group" a product belongs in e.g. by using the first character as the group identifier...so the logic is

"we" can now check each item in the cart to identify its group, apply the relevant shipping fee (one of which also has to be checked against postcode!) and total it up at the end and show it to the buyer. The charge for each group would only be applied once.

Can anyone knock holes in the logic/point out glaring errors before I start talking to coders?