Price increase to attributes

I am about to add some products that will priced by attributes (no base price), but I am also thinking ahead as to how I will be able to increase the attribute prices if done this way.
There will be too many to do it one at a time.

There are a number of ways to make up 1 Product with all of its Attributes ... then copy that to another Product or Category of Products ... would that work?

No, I don't think it would.

The product is Matisse Acrylic Paint, and it has about 80 colours. all made up of 7 different series.

series 1 $4.90
series 2 $5.10
series 3 $6.20
series 4 $7.80
....and so on.

I have will all the colours listed in a dropdown with the cost next to it

australian blue ($4.90)
Red oxide ($5.10) ....and so on. It makes it easier for the customer that way.

do I make any sense

Could you not increase your price with something like:

update products_attributes set options_values_price = options_values_price * 1.1;

(assuming this is how you use attribute pricing - there are many ways)

Make a backup of your database and try this out to see if it gives you what you want.

Scott

Where would I find

update products_attributes set options_values_price = options_values_price * 1.1;

It's a SQL command. You would enter it in phpMyAdmin or whatever your SQL client is.

Good luck,
Scott

Ok, it looks a bit scarey in phpMyAdmin. It gives me 7 tabs to choose from, so which is the right tab to choose. SQL, Query, Import, Operations........

Jodie

trueblue:

I am about to add some products that will priced by attributes (no base price)
...

The product is Matisse Acrylic Paint, and it has about 80 colours. all made up of 7 different series.

series 1 $4.90
series 2 $5.10
series 3 $6.20
series 4 $7.80
....and so on.

you can choose **any **one of your series prices as the 'base' price and come up with some formula that the rest of them are priced at with respect to the base price.

although zc by default accomodates only simple arithmetic functions for pricing (good for most of us), you can come up with more complicated pricing structures if you want to go with what swguy is suggesting.

ignore the following if you're not a math nerd: you have a base price for 'series 1' (s1) and 'series 2' (s2) is based on s1. let's say that s2 primarily determined by the current market price of s1 at some fixed point in time and you don't have your pricing hedged to the volatility of market prices as time passes. s2 can be updated dynamically in your zen cart (!) database as some family member of an autocorrelation estimate:

» coming soon: zen cart 7.3.5: zen cart world exchange

What?? No partial differential equations? I'm disappointed. :)

i can post the heat equation if that will tickle your noob's doobs.

aside: you know why the normal distribution (the ubiquitous probability distribution) is a solution to the 1-d heat equation?

??????????? you have gone way over my head.
I thought my question was easy

sorry Jodie.

without more information on what your objectives are, i say you can price your paints by series with the **catalog **» **attributes controller **as easily as you can paint by number.

however, if you need to change your paint prices by the 80 colors as well, you may want to consider inserting attributes programatically as swguy was suggesting. definitely consider this route if you update prices by color frequently.

there are other advantages in pricing programatically, such as having greater control over setting profit margins.

I'm am going to do it the easy way and list each series as a seperate product. If the customers don't like the way it is set up, I'll look at doing it a different way another time.

Thanks for your help
Jodie