Discussions

Product entities and/or product nodes??!! ... how to handle my bookstore catalogue in DCommerce?

Hi, thank for this great work ... but I really feel confused about the new way of handling with product entities and product nodes.

I thought that the D7 structure would have allowed to simply face a product class as a content type node, and a product instance as a node content instance itself,
but it seems not so obvious ... it seems we need the product entity.

I have read all you posts regarding the product entity/node topic, also the brainstorming ones ... to better get the sense and the advantages of this approach. But still I have great doubts if I have succeded in making it mine too.

I have to implement a library catalogue for a publisher (first task), with ecommerce (bookstore) functionalities (second phase task), also with authors and so on ...
The catalogue contains some pubblications (products) and that contain "articles" (1-n relationship) that would be products themeselves too. A structure similar to a music store that sells cds and single tracks belonging to them ...

Now please help me! Because this is not so clear at all.

Is the store the place where I should define just the "product types" entities (with basic information and basic price ... ecc.), and product would be datailed and istanced as nodes, or the store is the place where to input all the single items of the bookstore catalogue, with all the characteristics and details attached to them?

The first approach (define in the store just the product classes with basic attributes) would be for me the best and more flexible one.
In the product nodes I would be able to "extend" the product entities (classes) in the store and instance them several times.
This would also help me to more easily create the library catalogue, without ecommerce functionalities, at the beginning, and implement commerce beaviours and attributes in a second time. Something similar to what is actually possible in Ubercart with classes definition (http://www.ubercart.org/docs/user/10963/understanding_product_classes).
But how to differentiate prices and other characteristics for specific instances (nodes?) of the single products?

I am seriously worrying if in this DC framework I should instead put all the specific definitions (and instances?) of the products in my library catalogue in the store, as product entities …
But I don't see how this store interface would accomplish to manage (list, filter, search, ecc.) a great amount of product classes and instances …
Should we write down all the views for the store lists?

I am worrying also regarding the ones (bookstore managers) that will have to implement the catalogue and the instances of the store.
Their process and workflow should the easiest possible … and for sure shouldn't include a double entries for the same catalogue item …

Sorry for my written english, and for the quite confused explanation, but I feel seriously disoriented:
it seems to me not clear at all the use of the store and the single-product-entity definition workflow in it,
potentially too much complicate, to be real.

I can understand the need from a developer point of you (after reading your posts and video presentation) but should sound really less complicate to the store manager point of you, at the same time. Or at least much more clear …

Really would like to get the proper way in understanding the natural workflow of DC … because I really feel there is something I am not getting,

Hope someone might give "the light" … as really feel in some dark now.

Thanks in advance

Italo

Posted: Feb 28, 2011

Comments

itamair on February 28, 2011

Ok … just to be more pragmatic

My library catalog hierarchy would be done as follows, for instance:

Magazine 1 issues (each issue made by articles, products themselves … )
Magazine 2 issues (each issue made by articles, products themselves … )
etc …

So that the taxonomy might be represented by this:

- Catalog of Products
- Magazine 1
- Artcle of the Magazine 1
- Magazine 2
- Article of the Magazine 2
- …
- etc.

In a traditional way, using Ubercart for example, I would then create Product classes corresponding to that taxonomy.

At the same time I would create new content types corresponding to each possible Magazine and to each article belonging to each magazine. That's because each magazine might have different prices, shipping conditions, etc and specific fields/attributes
And that's it …
I would then input every product (magazine or article) as a product type, flagged with its specific taxonomy term …

How to proceed in Dcommerce instead ?
It is not clear to me where to create product types and specific instances of the product types. All in the store as product entities, and products … or products as content type nodes referring to products entities initially created in the store?
In this latter case, how to differentiate special fields for specific product instances? … let's say the price for the January Magazine 1 issue?

I hope I was more pragmatic and clear this time … counting the confusion I feel in the head with this apparent logic dichotomy in DCommerce (product contents(entity and product views/node)

Thanks for any advice and help … really welcome and needed in my case

Italo Mairo
www.italomairo.com

gmopinillosv on March 17, 2011

Hello there

I subscribe with you (Itamair).
I think It will not work until all DC and Drupal 7 is complete (not alfa, beta and so on). It has many mistake. I have been working in this issue for several days and I don't get create an e-commerce with catalog how i did it with drupal 6 and Ubercart. You can see here: www.earflap-hat.com

All what I find is to have to pay so they could teach you how to do it. This doesn't make sense.

Thank you.

Scott J on March 18, 2011

I don't see anything too complicated at earflap-hat.com that can't be done with Drupal Commerce. You don't need to pay anyone. Have you managed to get started at all?

eg. from http://drupal.org/node/1051964
Go to admin/commerce/products/types and add a new product type named T-shirt, save and add text-list fields named color and size.

Then every single item that is for sale must be entered at admin/commerce/products form, because that is where you give it a price.
So:
SKU - Title - Type - Price
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
M1BS - TShirt Blue Small - $24
M1BM - TShirt Blue Medium - $26
M1BL - TShirt Blue Large - $28
M1RS - TShirt Red Small - $24
M1RM - TShirt Red Medium - $26
M1RL - TShirt Red Large - $28
etc.

Scott J on March 17, 2011

itamair,
Don't compare too much with Ubercart, as Commerce is quite different, but for your example, Ubercart product class is similar to Commerce product type.

First at admin/commerce/products/types add two product types named 'magazine' and 'article'. Add appropriate fields for 'date' 'image' 'weight' etc.

Then every single item that is for sale must be entered at admin/commerce/products form, because that is where you give it a price.
So:
SKU - Title - Type - Price
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
mag1 - Magazine 1 - $5.00
art1 - Article of the Magazine 1 - $1.00
mag2 - Magazine 2 - $5.50
art2 - Article of the Magazine 2 - $1.50
mag3 - …
- etc

Later you can decide how to display them to the public, but I imagine you would only need one content type called 'Product display'.

itamair on March 21, 2011

No sorry ... but after days dedicated to assess you solution, I was really unable to find a reasonable solution. I also called your technical support, but, notwithstanding their kindness, that didn't help me and gave me any believable solution. May be I should have paid for deeper support, and I would have had .. but felt that wouldn't have solved completely. I feel some structural lack of "out of the box" functionalities.

DCommerce looks very sofisticated but at the same time very complicate. Too much for the developer himself, and better not to think about the site's administrator with less technical skills. Besides the unusual mechanism to input things twice (entity and nodes ...), I experienced some issues in the actual implementation ... Ok I know, it is still in beta. But I would/should start and use it now ...

I hope what I write will help you make it much better (and easier).
Some great concerns for me regards:

- two unusual steps to create items in the catalog and in the shop itself (really hardly acceptaple).;
- where to put specific fileds of each item type? In the entity or in the node?
Nowhere is clearly explained and adviced this. I tried but I didn't learn by doing at all. For instance, the taxonomy term wouldn't work properly if put in the entity. I had to realize facing it. And this is not cleared and explained anywhere;
- if I change the name of a product in it's node (product view) the title would remain unchanged in the cart, that would still point to the entity title ... very confusing. Is it an easy way to change and adapt the cart view?

And then I stopped, without going too much deeper. Was enough for me. I have to build the catalog of my publishing company, and then make the components as product. Now.
I can get the innovative sense of your approach, I saw so many videos abou it (Copenhagen, Paris, Chicago ...) ... and hope will give the expected fruits in the close future.

But compared to this, really is so simple to manage everything (in my case) with UBERCART ...

I can create content types for each type of my catalog. Create taxonomies to tag them ...
and then make them becoming products with Ubercart product classes. Great!
May be not the best approach for a developer point of view (because products should be entities and not nodes), but so logic and easy from the Drupal user point of view (even 7 release) ... Tis means to have full advantage of the power and flexibility of Drupal, linked with proper simplicity at the same time.

Last thing. I got in some web posts that DC is NOT the natural future of Ubercart, as somebody seems to show here. Better and more fair would be to to say that is a FORK ... an alternative or even a competitor. Ubercart development seems to be still very active, luckely.

Sorry as I am so straight. But I really spent many days in assessing DC ... didn't get the light, and had to wait quite a lot to have any answer to this posts. And any solution so far, too.

I really hope DC will make me changing my mind soon, hoping that time I will have proper tools easily switch to it from UC ...

PS: last critic from me. When documenting DC, try to use some more implementation use case besides the only T-Shirts (Large, medium, small) example. E Shops are not based just on T Shirts ... That didn't help me form my bookstore. :-)

Best best best wishes

Italo

Ryan Ryan Szrama on March 21, 2011

Thanks for all the great feedback. I'll pass this post on to Bojhan from the usability team so he can take it into consideration. The 1.0 is as you've found a developer oriented release - the usability for the store administrator isn't there yet and, maybe even more important, the library of contributed modules we've used on D6 isn't available on 7. We're well aware of these pain points and hope to correct them in the coming months.

A lot of contrib work is already going on, and we'll be using a sprint at DrupalCamp Colorado (first week of June) to do some usability testing and plan out our targeted contrib / usability development. I anticipate the 2.0 later this year to be more for someone in your situation, and I'm sorry you weren't able to use Commerce as is. No hard feelings, though! I'd probably still recommend Drupal 6 + Ubercart for someone in your shoes.

And point well taken on the documentation... it's a bit of a mess and super high on my priority list. We'll definitely include multiple use cases based on your post. : )

latulipeblanche on March 29, 2011

I juste want to say "Tnx for all energy you CommerceGuys put in the project". Not everything is already working, not everything is already well documented (up to the DrupalCommunity to help) but it's moving very fast.
I followed a training in the Paris-Office of CommerceGuys and i saw the energy of you Guys to make it work.
{go on because i want to put a working D7+Commerce site online end of Mai :-) }

bharata on April 16, 2013

So, has the terminology changed? Has "product types" become "product variation types"? The url you mentioned "admin/commerce /products/types" gives me a 404. Has it now become "admin/commerce/config/product-variation-types"?

Thanks!!

itamair on March 19, 2012

After many months of assessing and developing activities, I should apologize for my first opinions on DC and say, really say sorry.
I really was far from getting the concepts, the working workflow and the innovative functional approach of Drupal Commerce.
Drupal Commerce really rocks, and made me able to do what any other solution (Ubercart included) might have allowed …

here you can read much about my story … http://drupal.org/node/1199602#comment-5365636