Displayed option price is 134.28 times the price entered for an option

Thanks for the thoughts.

I didn't load a currency conversion module unless core came with one?

Have made extensive use of options/attributes over past few months and definately says base price £9.95 + option price £1 = £134.28 :(

Have set to not display option prices for now, but not a good way forward...

Thanks again for your help with my recent issues, I appreciate it. :)

I wonder if it was caused by not being able to access a field in a product - it caused problems in various modules and I've been clearing up the mess.

See comments 128 and 129 of http://drupal.org/node/240828 for details.

Basically it's the organic groups global permissions controls field level access and when you add a new field it doesn't give the OG admin any access to the field. This meant when the product was used (purchases, OG admin edits, etc.) all went wrong.

I wonder if it affected your module too? It was the only thing other than the upgrade that I'm aware of affecting my system.

??

Could you point me to the correct php file name and line number(s) that calculate and display the prices of the options referenced in the main comment above #1 please - I'll see what affects it and try to track down how come £1 is being displayed as £134.28 yet when moving on to checkout, is being added as £1 correctly. It's just the display that's wrong, not the actual amount added at checkout, hence me thinking it's a bug that at least needs a further check to avoid the error. If it was adding £134.28 at checkout that would be different...

Many thanks

Got to sleep now so will test in morning but I suspect it's because you're using Display Price in teaser and I've got that hidden, using Sell Price only.

Tomorrow I'll try copying display price unhidden to teaser display and set price as per sell price and see if it fixes it.

(Fingers crossed)

Tried adding "Display Price" to teaser view, but can't see it in my EDIT or CREATE form to actually give it a value. Still giving prices too high.

Ok, have attached some screen prints and added some diagnostic echo's to the code to see what's going on.

I get:

• Variant of display price is 1932.8145
• Base price of display_price is 644.2715
• Adjustment of variant minus base is 1288.543

• Variant of sell price is 5.00000
• Base of sell_price is 5.00000
• Adjustment for SELL of variant minus base is 0

So it seems:

1. the display_price base and variant values are wrong, but then I haven't found how to set them yet in Ubercart since it doesn't list 'Display Price' as an option - just List Price, Cost Price and Sell Price.
2. the sell_price base is correct but the variant sell_price is wrong - same as sell_price
3. because the variant sell_price is wrong, the $Adjustment value is zero so it skips displaying any prices if I just replace the 'display_price' string with 'sell_price'

Attached is a screen shot of the base price (attachment #1); a screen shot of the adjustments (attachment #2); and a screen shot of the customer view of the product (attachment #3).

p.s. the php diagnistic code I temporarily added to get this is all in $tmp variables and echos is:

foreach ($attribute->options as $option) {
$display_price = '';
$tmpvariant = '';
$tmpbase = '';
$tmpadjust = '';
if (in_array($attribute->aid, $priced_attributes)) {
$variant = node_view(uc_product_load_variant($product->nid, $skip_flag + array('attributes' => array($attribute->aid => $option->oid))), 'teaser');
switch (variable_get('uc_attribute_option_price_format', 'adjustment')) {
case 'total':
if (count($priced_attributes) == 1 && $attribute->display != 3) {
$display_price = uc_currency_format($variant['display_price']['#value']);
break;
}
case 'adjustment':
$base = node_view(uc_product_load_variant($product->nid, $skip_flag), 'teaser');
$adjustment = $variant['display_price']['#value'] - $base['display_price']['#value'];
$tmpvariant = $variant['display_price']['#value'];
$tmpbase = $base['display_price']['#value'];
echo "Variant of display price is $tmpvariant";
echo "Base price of display_price is $tmpbase";
echo "Adjustment of variant minus base is $adjustment";
$tmpvariant = $variant['sell_price']['#value'];
$tmpbase = $base['sell_price']['#value'];
$tmpadjust = $variant['sell_price']['#value'] - $base['sell_price']['#value'];
echo "Variant of sell price is $tmpvariant";
echo "Base of sell_price is $tmpbase";
echo "Adjustment for SELL of variant minus base is $tmpadjust";
if ($adjustment != 0) {
$display_price = $adjustment > 0 ? '+' : '-';
$display_price .= uc_currency_format(abs($adjustment));
}
break;
}
}

I know you've tested it from a vanilla install, but something is going wrong somewhere and unfortunately I'm very new to php so don't stand a chance of working out what!

Hope my limited php abilities have shed some light on what's going wrong? :o)

Best wishes

Hi longwave, sorry didn't see your reply. Thanks for prompting me.

I have the following contrib modules:

• uc_affiliate2-7.x-1.2
• uc_product_power_tools-7.x-1.x-dev
• uc_recurring-7.x-2.0-alpha2
• uc_ssl-7.x-1.01

I have used uc tax rules to add a site 'commission/charge' on to the sub-total by percentage. There are a lot of them because I can't have the commission falling below 50 pence (UK stirling) as the credit card provider charges a fixed fee for debit cards and there is a risk that low cost products (e.g. 20 pence) may appear, in which case they'd make us a loss. So my rules are along the lines of if less than £3 and more then £2 then instead of charging (e.g.) 5% (10 to 15 pence), charge 20% (40 to 60 pence). I have checked them all three times and believe them all to be correct. Also, they affect only the total price not the option prices as the condition I use is "[order: order total]", as in the example screen shot attached.

The only rule I have manually added is triggered by "A payment gets entered for an order" (it sends an email to an administrator role notifying of a specific type of purchase). I think this is not related (but then Drupal is full of interesting little tricks). ;)

I also had a problem with UC recurring (not sure if relevant) where a recurring order with interval of zero was created all by itself. It created lots of recurring orders and caused an on-screen fatal error. I tracked down cause as being OG global permissions having default permission of no access to anyone for new fields created on an OG product/content item. When I added permission to product owner (view/edit/delete) and customers (view), and deleted the recurring orders to stop them propogating, the error went away. However, errors were also caused in UC when I tried to use the tax module's clone button - it failed with a screen full of errors and left orphan records in the sql db. I removed the orphan records (titled clone of...) manually. All seems ok but it's possible this affected it.

Having said that, my previous posting shows incorrect 'display price' option and incorrect option price for sell price, being same as actual product price, leaving adjustment value of zero. Which I can't see why that would be if not some kind of bug...?

Many thanks for your help

Best wishes

p.s. not an expert on this - not sure what you mean by inclusive taxes, but if you mean the tick box that includes tax in the current rule tax calculation, then no, I've left all three boxes there unticked (shipping, line and tax all unticked). ??

Thx

Also, the main reason I had ruled out my tax rules as relevant was that I had used [order: order_total] and had assumed that this would therefore only add tax to the order total (which when you get to the cart, is absolutely correct). See attachments based on attachments 1 to 3 on comment #9, showing order as placed with option prices (£1,200+ options), cart and checkout (cart and checkout views correct). Actual values are £5 for product and £10 for option, giving £15 x quantity of 2 = £30 total. Then a 4.95% site fee bringing total to £31.49. So tax rule I've added works as intended in cart and checkout. It's just the values in $variant['display_price']['#value'] and $base['display_price']['#value'] from the line in comment #10 ($adjustment = $variant['display_price']['#value'] - $base['display_price']['#value'];) that are wrong (and with the diagnostic lines I added, the content of $variant['sell_price']['#value'] which is same as base price (£5) not the option price of £10 (multiplied by 2 as quantity is 2 in this example).

Oh, and I have not enabled the UC SSL module.

Just to be sure I've given right info, I've attached screen shot of modules for UC EXTRAS.

That check box was ticked, but I cleared it on all tax rules that could conceivably had an effect, and re-tested and no effect. :(

I still think it's a bug of some description rather than a conflict.

I use the List Price, the Cost Price and the Sell Price. It is the Sell Price I want to be next to each Option.

But when specifying the options it does not specifically say which price it is - you get a column called "Cost" (cost price) and "Price" (??? assume it's the sell price but could be display price maybe?).

In either case, the prices of everything are correct, except for the screen that displays the option prices.

I have looked at the mysql tables and in the uc_product_options table, which lists the available options for purchase, it uses COST and PRICE fields. If you look in the uc_order_products table, this lists the PRICE field as being "The price paid for the ordered product." In the uc_products table, it uses LIST, COST and SELL prices as you would expect. This suggests to me that the uc_product_options table is using the wrong fields (the fields that say what someone paid as part of an order rather than the fields that list the list, cost and sell prices). But if that is the case, I wonder why it isn't always wrong (TR said vanilla install worked). Worth a look though.

If I disable the taxes module, will it lose my current config data? It took ages to set up all the rules.

Thinking on from #20, it would explain why it works at cart and checkout but not at view screen of product - because the PRICE field is not set until someone places an order.

Ah, ok, thanks.

(You're a genius, by the way!!!)

When I switched off the taxes and tax reports modules, all was fine.

Before, when you mentioned this, I just switched off the checkbox for "Include this tax when displaying product prices." for the tax rules that specifically applied to that product and its options, but this didn't solve the problem.

So I've switched the taxes and tax reports modules back on, and am currently going through all my tax rules (about 60 of them), switching off every occurrance of this checkbox I can find!

I'll confirm if it clears the problem in a little while when I'm finished.

Many thanks for your time and explanation.

Best wishes

Hehe, very happy!

I cleared every checkbox in all 60 rules, and all is working fine now.

Many thanks for your help!

:o)

Ref. my comment 13, I am still getting this error.

I wonder if it is an invalid RULE set up? Not sure why. Will investigate this.

Will also try to work out the (no doubt very basic for someone more familiar with php) method of putting an IF statement around whatever bit of code sets up the recurring payment, to not do so if the interval is zero. This is of course a symptom fix not fixing the bug that is causing the invalid recurring fee on a product without a recurring fee 'feature' set up, but is a good safety fall back for a live system (would upset my customers being charged £20,000 for a 75p product! ;)

If anybody else more familiar with php is able to take a look and fix this in a better way, please do so.

Best wishes