Discussions

A alternative idea for attributes with price - line type, rules and product references

I hit a big problem recently with Commerce and attributes, that almost needed me to bin everything and go with a different system. I would like to describe the attribute idea / potential solution that might keep Commerce as a viable option in this use case.

Background
User experience has been an issue. Every solution I found to a problem in the form of a module presented it's own set of inconsistencies (based on the different in approach by Commerce and the module developer).

Original setup
Variations linked to product displays, Commerce Fancy Attributes to create a cool view of color variations. and Commerce Product Pricing Attributes for attributes that should not be variations but affect price, and Length and Width fields as line types with rules to adjust price (not using Physical Product or Physical Fields as I did not see the advantage).

What worked -> it functioned as it needed to, prices were updated.

What did not work -> the user experience was awful.

Why? Because Pricing Attributes updates the price dynamically, but the Commerce quantity field and line types do not. For the user, this is inconsistent and not logical. Change was needed. Either quantity and the length / width needed to adjust price dynamically, or everything else needed not to.

Research into dynamic price changes from quantity got nowhere. When asked it was generally misunderstood.

Potential solution

1) Not using Pricing Attributes (not because it is a bad module, but it's approach is different to Commerce. It also has the issue that prices in the drop down don't include tax / vat, which is important with EU VAT laws).

2) A taxonomy vocab with a Name and Price field.

3) A taxonomy term for each attribute with the price change difference

4) A line type field for the term reference, with 'Include this field on Add to Cart forms for line items of this type' checked.

5) A 'Calculating the sell price of a product' rule that adds the term price value to the unit price.

What do you think? Workable? I would love feedback on this, especially from others who see the issues due to inconsistency that come with this framework approach. As much as I want to love Commerce, I feel it needs more input from a user experience point of view, and up until now I was not sure how to help with this.

One issue I do see here is the display of the term price value in the product display. I haven't yet figured out how to do that.

mikeaja
Posted: Mar 21, 2014

Comments

mikeaja on March 23, 2014

Firstly, solving the term price value display was actually easy, buy accessing the term through MYTEMPLATE_field_widget_form_alter().

And..... I've tested something else that seems to have a lot of potential.

I experimented with adding a Product Reference field to the line item. I realise this is slightly backwards logic as the main product access the line item. However, it worked. I had a list of 'extra products' (variations I created within a new variation type, not linked to any display) as a checkbox list.

With a 'Calculating the sell price of a product' rule, I was able to add the extra product price to the main product price.

Perhaps this creates a very logical way to get attributes that should not be separate variations within the main product, but as a separate variation list (that can be used with many different products).

I've also just made a separate post (for clarity) regarding why some product attributes should not be product variations.

Feedback hoped for.....

joshmiller Josh Miller on March 27, 2014

This is a well documented process in Drupal Commerce where we add fields to a line item and pass those into the price calculation rule.

www.youtube.com/watch?v=j9KsyvQZaAY

I created a pizza store in the above video where you can add attributes to type of product via line item fields. Each taxonomy term has a price field. So, pepperoni costs $2 and sausage costs $3. There's a few limitations, a big one is the ability for fields on line items to trigger a price ajax refresh. Lots of people want this, not enough to push the work forward (perhaps you can share how you accomplishing your pricing scheme there?):

https://drupal.org/node/1541886

Josh

mikeaja on March 27, 2014

Thanks for the info and link. Sounds like my initial way was exactly the same - a price field in the taxonomy and a rule to add it to the price.

However........, I'm now using / experimenting with a different method.

The main problem with using taxonomy and price field was that the attributes could not be show including tax / VAT. I don't think there is a rule that activates on product page display that could modify a line item display (I tested a few and couldn't find one).

So, the solution was to add a product reference field to the line item, and using a similar rule to update the main product price. The advantage here is that tax / VAT can be shown on not on product display. Also, I think the logic is better when the attribute is some extra product add-on or service, because this fits with being a real-life product in itself or service as product (for example,. hooks for a picture frame, varnish added to the frame).

Note: for both the above solutions, I'm using code in the template form alter to take the price from the field and display it next to the name (in keeping with typical attribute style).

Further note: I'm not looking to do price ajax update at all. There is not point while quantity does not do that. In my opinion, it should be all or nothing. This and the tax issue are the two reasons I stopped using Pricing Attributes.

mikeaja on April 10, 2014

@joshmiller

I'd like to check something with you.

You specifically use taxonomies for the video demo for each pizza topping. This I get based on general Drupal principals. However, I am now thinking separate product variations for each topping is a more logical way to organise this, because pizza toppings are also a product.

So, imagining your demo, but with a product reference line item field linking to a product (variation) type instead of a term reference line item field. And each pizza topping stored as individual variations (perhaps not linked to a product display) instead of terms.

My question is, from your experience do you see any bigger issues with this approach compared with using term reference?

Jeremy Trudell on June 11, 2014

I'm working on a pizza site now. Just curious if you found using a product reference field to a pizza topping variation a better method than a taxonomy.

mikeaja on December 17, 2014

Apologies, I didn't see you post. How is it going? I'd be interested in a skype chat if you have moved forwards with this. Perhaps we can share ideas?

mikeaja on December 17, 2014

Hi

I'm confident my approach works, and will be used soon on a producion site.

I don't know if your situation is close to the one I resolved. I can't share the url on a public site. Do you have a way to contact?