Price by attrib pulling unknown price

[qhome]

http://www.raretvclassics.com/index....roducts_id=111

Note the cheapest case is 1.60, but it says starting at $3.00. The main product is set to 0.00. Where is it getting 3.00 from?

[g0d4lm1ty]

Just taking a wild guess here... but is that Starting at $3.00 hand typed in??? as a part of your script... when i goto check out the price is right.....


!--bof Product Price block -->
<h2 id="productPrices" class="productGeneral">
Starting at: $3.00</h2>
<!--eof Product Price block -->


look for that in your developers tool kit.... it may help you solve this.......

[qhome]

Just taking a wild guess here... but is that Starting at $3.00 hand typed in??? as a part of your script... when i goto check out the price is right.....


!--bof Product Price block -->
<h2 id="productPrices" class="productGeneral">
Starting at: $3.00</h2>
<!--eof Product Price block -->


look for that in your developers tool kit.... it may help you solve this.......

ya i know the price is right at checkout..and no its not typed.. it even shows 3.00 in the admin area when i preview changes, but when i see the full edit area it shows 0.00

[g0d4lm1ty]

can you cut and paste your admin screen.. just the pricing info.....

[gjh42]

Your cheapest case is the 2-disc case at $1.00, but you also have the attribute Case Art Upgrade (Title of show) with a price of +$2.00. This is apparently added in by the "starting at" logic, giving $1.00 + $2.00 = $3.00 minimum price.

It does work correctly in the shopping cart, adding the charge only when the field is not blank.

[qhome]

Your cheapest case is the 2-disc case at $1.00, but you also have the attribute Case Art Upgrade (Title of show) with a price of +$2.00. This is apparently added in by the "starting at" logic, giving $1.00 + $2.00 = $3.00 minimum price.

It does work correctly in the shopping cart, adding the charge only when the field is not blank.

aha! good catch! that makes sense. I guess its the logistics of "groups" of attribs. Thanks !

[gjh42]

If this is actually what's happening, it *is* a flaw in the code and ought to be reported in the Bug Reports section. I don't expect it would take Ajeh long to fix it, or give a workaround if there is one.

[Ajeh]

It is not a flaw in the code ...

It is a flaw in the user's set up of the Product ...

Sounds like you have said Priced by Attribute and the Product is not ...

[qhome]

It is not a flaw in the code ...

It is a flaw in the user's set up of the Product ...

Sounds like you have said Priced by Attribute and the Product is not ...

It's not?

I have a general description and 5 options that decide price. Another secondary option is the text part. Technically the product is set up correctly, but like I said I think its just not the way it was designed to work. I dont think its an easy fix nor do I think it is a bug.. its just a design issue. There is no such thing as a "secondary option" so it is trying to price by attribs from 2 different attrib sets, so the fact that it adds them together rather than just take note of the first attrib is a rather pleasant surprise.

But no biggie, I just wanted to figure it out.

[Ajeh]

Price by Attribute takes the lowest price of each Option Name group to build the Product Price ...

If you have an optional $2.00 charge ... plus the other group has the lowest price of the $1.00 that is $3.00 ...

If you have a Product Option where there is only 1 price and it is optional and your Product does not have a Product Price, then you can use the Priced by Attribute but you need to turn off the single Option Name Price from being included in the displayed Product Price or base price of the Product ...

Otherwise, the price will display as $3.00 when you really mean $1.00 with other choices to increase the price ...

As you are showing the prices as:
+2.00
+1.00
etc.

You could also make the Product not Priced by Attribute and set to the Products Price to $1.00 ...

Then set the attribute that costs $1.00 to 0.00 and the one that costs +2.00 to +1.00 ...