Magento Forum

Poll
Would you like a price class scheme?
Nope, why would I? 2
Absolutely, would save me hours of work and minimize mistakes. 5
I don’t understand what you mean. 2
Total Votes: 9
You must be a logged-in member to vote
Price-classes
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

I’d like to see a price classes scheme (utlising inheritance).

I would like to use it like this:
I would create a price class, give it a name and a price.

I would assign this price class to a group of products. Updating the price for all those products would be very simple since I would only have to update the price in the price class. If an individual product would have a price set, the individual price would override the price class.

I suppose one could bring price tiers and possibly other price-attributes into the same logic.

What do you guys think?

/ Ben

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

Ok, for you who don’t understand what I mean:

Instead of assigning a price to a product, one assigns a price-class so that one can update prices for groups of products all at once.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

So, you would have one default price for a group of products?

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

Correct.

The reasoning is in the seasoning.. smile Litterarily in my case.. I need to deliver a web shop by next summer for a customer of mine who deals in spices, herbs, teas and other food-related goods. The inventory is about 5K articles and you would typically have large groups of articles with same pricing - f ex there could typically be 200 tea blends with the same price by weight.

However, sometimes a particular article becomes expensive due to production shortage and one may need to jump in and raise the price immediately on that item - an item that would normally be part of a price group but that temporarily needs it’s own price. That’s why I ask for the inheritance thing (which obviously is common sense to do anyways, programming wise).

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

Oh, and answering your question in detail - Yes, I would have one default price for group of products, but I would prefer it to be realised like so, that when I create/import a product, I would assign a price class to it,rather than, say, having to organize products in a subcategory only so I can assign a default price to the subcategory. That might be better than nothing, but it would be far from ideal. What I’m saying (I’m sure you understand perfectly already, but just to be very clear) is that the price grouping needs to be totally separated from other groupings. / Ben

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

Hmm… thought experiment:

Let’s say we create a new attribute, and assign it group values. Then we create catalog price rules that in conditions we have value of this attribute and checking that regular price is 0, and then assign fixed price to these products. That means a price rule for each group. Does that work for you?

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

If I understand you correctly, it does. Can I ask you to try to rephrase your thought? I want to make sure I understand you completely.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

1. create attribute “price_group” as varchar (in later releases we are going to have proper functionality in price rules for dropdown attributes)
2. update your products with correct values for this attribute (for example MyPriceGroup) and 0.01 for regular price (i think the price is required by default)
3. in Promotions -> Catalog Price Rules create new rule and set correct selections for stores and customer groups.
4. put in conditions:
a. If “ALL” of these conditions are “TRUE”
a1. “Price Group” “is” “MyPriceGroup”
a2. “Price” “is” “0.01”
5. Put in actions: Update “Rule Price” “To Fixed Amount” “23.12”
6. Click “Save and Apply” button

Now all the products that have Price Group “MyPriceGroup” and Price “0.01” will get Sale price of “23.12” (Price title can be changed in template)
if you change one of the affected products’ price to something else than “0.01” the change in catalog will apear after midnight (or after next scheduled rules task)

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

Okay, I’m gonna try this out and post back later. Thx!

 
Magento Community Magento Community
Magento Community
Magento Community
 
brandondrew
Member
 
Avatar
Total Posts:  64
Joined:  2007-09-12
 

Hmmm… that would in my opinion muddy the interface, since you have to remember that 0.01 doesn’t REALLY mean 0.01, but is instead (sort of secretly) a code to allow another rule to work.  I think it’s important (just like in programming, since that’s basically what you’re doing with the rules) to keep things clear and straightforward and self-descriptive.  As soon as there’s some arcane thing that does something completely different from what it appears to do, things start to spin out of control.  You can get by with one or two such things, but the more you add, the more confusing it gets and the higher the probability of error.  Especially when you have multiple people administering the system, or a change in personnel.  I can just see spices appearing for $0.01 on the web site because someone goofed with a pricing rule, and customers ordering loads of them to stock up at this unbelievable price, and then hard feelings and lawsuits when the store refuses to honor the price.  (So that might be a bit melodramatic, but it’s certainly possible.)

How about this alternative:  have a price class attribute AND a price override attribute.  So if something is in price_class “Cheap Spice” and the attribute price_override is NOT “True” then it has price $X.YZ .  This way there is no (semi) secret ‘magic number’ that the price must be set to for the price class to take effect.  Each attribute is what it says it is, and nothing else.  That way you could also move things *out* of a price class, and know that they’d be going (back) to a sensible price.  So you could make a price class for sales, and when you move the spice out of the “Super Special” price class, you’d know it’s price would go back to what it was before the sale.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Moshe
Magento Team
 
Avatar
Total Posts:  1770
Joined:  2007-08-07
Los Angeles
 

yep, 0.01 was just a code, was thinking to suggest a 0, which would be clearer, but remembered that by default installation price is a required value attribute.

I’ve suggested using price attribute because i personally don’t like too many extra attributes. But it is also a good solution to have special attribute as a trigger.

 
Magento Community Magento Community
Magento Community
Magento Community
 
brandondrew
Member
 
Avatar
Total Posts:  64
Joined:  2007-09-12
 

Yes, you’re right that too many attributes is not good, but I think it’s better in the end to have one more attribute than to have an potentially confusing attribute.  (At least that’s my opinion on this sort of thing.)

On thinking about my suggested attributes, I think it can be improved.  How about price_class and price_class_override?  When price_class_override is TRUE, then the price for the class takes effect, and when FALSE, then the regular price attribute takes effect.  It seems pretty nearly self-documenting, or at least very easy to remember how it works.  And by having the second attribute start with “price_class”, they’ll always show up together in lists, and their relationship is is clearly marked.

 
Magento Community Magento Community
Magento Community
Magento Community
 
benjaminATwebbutvecklarnaDOTse
Jr. Member
 
Avatar
Total Posts:  23
Joined:  2007-10-11
 

Brandon, I kinda think your take on it is sensible and there may just be an additional feature in it - although, speaking of good programming, I’m partial to clean inheritance - basically, the more systems I’ve programmed, the more I’ve grown to like the clean logic structure of it. When it comes to a saleprice, I would want to do it exactly like on a single product:

We have product X, the price is NULL so the parser looks at the next level up - price class Y.
In Y we apply the same pricing logic as we would on an individual product, thus - tiers and sales rules are in effect, using the exact same logic we would use on any individual product.

That’s the beauty and simplicity of it - whenever you want to do something on one level in a system that also exists on some other level, you automatically know how to do it, since an apple is always an apple.

I would however be perfectly happy with your take too, it’s certainly viable enough.

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top