Datatype to handle product options

Monday 01 December 2003 2:00:10 pm

Hi,

In my opinion, the webshop module of ezP is seriously comprimised as long as it can't handle product options (colors, sizes and so on).

I would therefore like to start a discussion on this topic, and hopefully enough people will share my opinion to capture ez systems attention on this topic. Isn't a new datatype and some modifications to the shop module all we would need? (I'm not sure as I'm still inexperienced when it comes to expanding ezp.)

Sincerely,

Eirik Johansen
Netmaking AS

http://www.netmaking.no/

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Monday 01 December 2003 2:23:34 pm

I agree wholeheartedly Eirik.

At this point I am unable to use the shopping cart as I need the ability to display/store multiple products and variants of a product on a single node. The commerce capabilities of eZ publish aren't as flexibile as the content capabilities sadly. It is great if you are selling CDs, but not great if you are selling a product that offers the customer a choice of options.

But I have a feeling that this wouldn't be an easy change as it would require a major change in how data is stored within the cart.

Someone please correct me if I am wrong.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Monday 01 December 2003 2:48:23 pm

We need to look this product problem soon with an upcoming project. We need multi-colour products to be handled properly otherwise the clients will be a little frustrated. But im afraid i dont know enough of the ins-and-outs to say more yet.

The category datatype is a quick workaround to allow us to edit categories per object. Before we used an enum datatype to define categories but soon realised that if wanted to make changes (edits/additions/deletions) we would need to republish every product.

This datatype is a little like the keyword datatype. It has its own table and objects can add and remove categories from a single text box: eg

object 1 => "nature, work, miscellaneous"

which you can edit. The code will add and remove appropiately.

The next stage is to throw in a management screen to show the clients how many products are in each categroy, allow name changing of a category in a simple way. Another table might be required to make this change simple.

Hope this gives you an idea.

Paul

Tuesday 02 December 2003 12:32:30 am

Possibly. One our options was to consider the object relation list and have some smart way of relating the objects easily. This would require a special function to choose possible related objects and present them to the user when they are constructing the product.

In this way you could edit your paint pot, and the function would inform you of the colours available for it that you can select.

What do you think?

paul

Tuesday 02 December 2003 1:19:45 am

There are shop views for discounting:

kernel/shop/

----------discountruleedit.php
----------discountgroup.php
----------discountgroupmembershipview.php
----------discountruleedit.php

I wonder if these can be used in a way with the related object list to include rebates and discounts.

As for putting it into its own datatype, that may be good. I think the discount rules incorporate some kind of management - after all they are views. So, for the admin you could set it up to view which products are discounted and by how much. Most products wont be discounted of course (unless you have a general sale on) so the micro-management shouldn't be too hard.

Again, this is hypothetical as i can't test at the moment. But it should be possible.

paul

Wednesday 03 December 2003 12:30:23 am

The category datatype is an important improvement, but I would like to point out an everyday problem which I always face.
Suppose you have a company producing footwear or underwear or even computers.
They want to use eZ publish 3 because they need a complete content management system with e-commerce engine inside, but they sell their products to resellers, not to end users.
They want to receive orders from their resellers through their portal, but when they create the product they must be able to manage different variations (sizes, colors, etc.), and let the resellers order inside the same product different variations in different quantities; for instance:

Product n. 00514......Price: 12,00 Eur

Colors:....Black....White.....Red.....Brown
Quantity:...5 .......4...........3..........6

The shopping cart will display:

Total items............Total Cost
......18..................216,00 Eur

I think that in order to build effectively an e-commerce solution with these functions you must be able to construct the sequence : categories-->groups-->products

The variations can be inherited by all the products belonging to the same group, for instance:

Category: Footwear
Group: Woman Shoes
Group Variations Type: Sizes........Values: 36; 37; 38; 40; 41

Then you must link to each value a corresponding quantity field in the product class to be displayed in the shopping cart.

What do you think? Is it possible to do this with eZ publish 3?

Sandra Parente
www.netbliss.it

Wednesday 03 December 2003 7:00:27 am

Bård, that would be a great start. I believe it would address a lot of the key problems I face. Specifically I need the ability to associate different attributes to an item including, but not limited to:
- Different item numbers
- Different pricing (up or down)
- Increased or reduced shipping costs for a particular item number as well as rebates
- Different materials (sometimes several different sets of materials for different parts of the item)
- Ability of the customer to purchase different quantities of the various options

From the other posts on this thread I believe it would meet the needs of a lot of people, making it much easier for us to use the e-commerce capabilities of eZ publish instead of using/hacking a third-party or custom solution.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Friday 05 December 2003 5:06:12 am

Hi,
Just wanted to add a note on the numbers of option fields to describe a product. If these are physical options you only need one field. In fact, more fields will give you trouble, because then you don't necessarily have an unique product.

Lets say you sell T-shirts and have 2 physical options, size and colour. Sizes are small, medium and large for the white T-shirt, and only large for the black. You can't use two option fields, because someone can select small/black, which you don't have. You can't use JavaScript to update them either, because of the users that turns it off.

It's better (and simpler) to use one option field with the combinations. In my experience I've never needed more than one.

What we really need is a stock field for each combination.

Roy

Friday 05 December 2003 6:57:36 am

Roy, we need the flexibility to have multiple options. As Mark pointed out, some of us do need the ability to assign a unique product name and a unique product number. In our case we may actually have a few variants that establish which product number/name combination to add to the cart: size, color, shape of the blade (we sell knives) and handle material could all be options for a single product. A single option field doesn't work, causing us to create several sets of fields for each product on our site to cover all of the possible variations. A new datatype that was flexible enough for us to define the amount and purpose/name of the fields would allow us to meet our needs, without limiting anyone selling products vastly different than ours.

Ultimately eZ publish is a framework, so key elements like e-commerce datatypes shouldn't limit the developer to a certain way of selling or organizing their products. A new flexible datatype will ensure eZ publish works for all.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Friday 05 December 2003 7:22:42 am

I agree. In your case you need several options, price modifiers and not a stock field. In others a stock field is mandatory to run the business, because they can't get orders on products not in stock.

Roy