attributes + price factor + special price = incorrect totals

[balihr]

Zen Cart 1.5.5d vanilla install

Option name "Color" and "Size" changed from dropdown to checkbox.

Inserted new product, set "Product Priced by Attributes" to YES. Product price is set to 0.

Going to Attribute Controller. Assigned "Size: Large". Then, new attribute as follows:
Color: Black, price +15, price factor 5, Default Selected YES
Color: Red, price +15, price factor 5, Default Selected YES



Frontend is fine, product info page:



Adding to cart, subtotal is $180 and I go through checkout with $180.

Now, problem.

I go to Price Manager for that product and set a Special Price to 33.33%



Product page is fine and I add the item to cart. Subtotal is $120.



I start checkout, get to checkout_payment page and my subtotal is now $170.



What happened, where is that subtotal coming from? It's not the regular price (that would be $180) and it's not the discounted price (that should be $120 as shown on shopping cart page). Shopping cart sidebox is still showing the correct $120. If I go through checkout, I'm charged $170 (tested on a live site with auth.net and PayPal). Any help would be appreciated.
And, yes, price factor is important because in reality, this is a "bundle" where color:red stands for 6 individual items and we want to show the "per item" price, which is in this case $15 ($10 when discounted). What's most confusing is that shopping_cart page is showing the correct subtotal so that part is working fine...

[mc12345678]

Not easy to test, but what if the two check boxes under the one option name were each applied to a dropdown, does the full setup work? I ask, because until recently, ZC checkbox attributes didn't fair well generally speaking for such calculations/determinations. Grr, I know I didn't say that right, but basically determination of "combinations" or something similar didn't work out well. Curious if it would work at all with another option name type that would allow the selection(s) you are wanting to offer even if offered a different way.

[balihr]

mc, I'm not sure I follow the idea... But, thing is - it DOES calculate correctly on the shopping_cart page and that's what is confusing me. I'd say the shopping_cart class is doing it properly, but then for some reason the order_total modules mess it up, and I don't get it...

Splitting the checkboxes into separate dropdowns is a very impractical setup, although it might be OK as a temporary solution... I'll test and report back.

[balihr]

OK, the idea with separating the options into 2 dropdowns made things even worse...

Here's the admin setup:



Both red and black have price factor 5:



Adding to cart with Black and Red selected, cart shows $100 subtotal.



Going to checkout, subtotal is $0!



Now, if I remove the special price, price factor doesn't work at all on the dropdowns, it just takes the $15 and cart shows $30, checkout subtotal is OK.

There's something REALLY weird going on here...

[lat9]

@balihr, I'd previously isolated the issue to the zen_discount_calc function, see here, but have not had a chance to go back and unravel that logic to understand the flow.

[lankeeyankee]

After setting up your original scenario I can repeat the bug. And I can confirm it is caused by the price factor and special price combination after changing the item to not have a price factor. I tried this in my old site on my test server which is 1.3.7.1 and get the exact same result so this has been going on for that long.

What I notice is when you apply the special price then look at it in the attributes controller the total/disc amounts are unexpected. With no special it shows correctly $90. With the 33.333% discount it now shows $65/$43.33. It should show $90/$60, or it would if there is no price factor involved. I have never used the price factor feature so I am not familiar with it's logic. So why is it showing this price of $65/$43.33? I get the same thing in the 1.3.7.1 test store, too.

Now, try the original setup but instead of special use salemaker. I get a price of $65 for each attribute and a price of $130 in the cart. It also shows $65 in the attributes controller. But going to checkout I get a total of $180, the original price, so there is no salemaker price applied.

It could be that the $65 special/salemaker prices are derived from the (factor) 5 being calculated at the sale price (5 x $10) and then added to the 1 at regular price. But why there is a $50 discrepancy with special price during checkout is hard for me to figure out.

In looking at the code I see there is a function zen_get_attributes_price_factor in includes/functions/functions_prices but it is only called in the shopping cart class which is probably why the cart is showing the correct price. So it looks like it needs to be added elsewhere, like perhaps the order class? I'm way too rusty with the code and zen cart file tree/structure to offer any advice.

[mc12345678]

After a little code following and a few failed attempts, I found this to be a solution to the "central" issue described, though still need to identify a solution to the "difference" in price display/change of an attributes applied price... Ie. when looking in the attributes controller and seeing two prices in the Total | Disc column... It appears that when that is so, that the product page doesn't show the proper information to relate back to the actual total that will be seen once the product is added to the cart/displayed in checkout... But that's still somewhat of a separate issue.

So the "fix" is/was to duplicate an action that is in the includes/classes/shopping_cart.php file within the function cart(). Just prior to iterating each of the product a constant is defined:

if (!defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL')) define('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL', 1);

This causes the calculations on the shopping cart page to come out correctly as this affects the results of the includes/functions/functions_prices.php file's function zen_get_attributes_price_factor which in turn affects the function zen_get_attributes_price_final in the same file and also the shopping_cart class in multiple locations...

Well, one place in which that function is called is within the shopping_cart class' function attributes_price... Okay, no big deal right? Except, in the order class when generating the order price values, this class function is called to assign the final_price for each product... Thus... In order for the same "calculation" to be performed in the order class as is/was done in the shopping_cart class, a similar assignment of the constant is needed... Now.. The question becomes, should it be entered only in the shopping_cart class (three times: once in the cart function, once in the attributes_price function), should an instance be added to the order class just before the assignment of the total price so that it is defined for the attributes_price calculation as the order class uses the shopping_cart class to generate the values, or should it be applied site wide???

I chose to add it to the attributes_price calculation seeing as other functions call this class/function to perform calculations on the product and therefore it seems to make sense to apply it only there... (Yes in initial testing I did make it a global constant to see what/if anything would change in site operation.) The function is not used on the admin side, and the following store side files use this function in a default install:
includes/classes/shopping_cart.php
includes/classes/order.php
includes/modules/payment/sagepay_zc/SagepayBasket.php (Appears that the below correction will ensure proper pricing there for this setup.)

Now, using a setup similar to what has been described of a product having attributes with a price factor applied I've gone through a normal purchase without any further deductions, a sale (with a few variations of how to apply the sale), a special, combination of the two and while I did see a little oddity in calculating a sale where the new price was identified and the above setup established, it didn't seem directly related to the change (could include/exclude the constant and the result was effectively the same at the product level and responded as expected at the checkout area), but instead either my understanding or the setup... But that seems to also be a different issue.

So anyways, modifying the includes/classes/shopping_cart.php code to include the below highlighted item seemed to "fix" the issue of attributes + price factor + special price coming out to be the incorrect total at checkout.

function attributes_price($products_id) {
 	global $db, $currencies;
 	
	$total_attributes_price = 0;
 	$qty = $this->contents[$products_id]['qty'];
 	
	if (isset($this->contents[$products_id]['attributes'])) { 	
 	if (!defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL')) define('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL', 1); // mc12345678 Added to apply the attribute's price factor and price factor offset against the provided special price if a special is present otherwise against the provided price when returning the value from the function zen_get_attributes_price_factor found in includes/functions/functions_prices.php 
	reset($this->contents[$products_id]['attributes']);
 	while (list($option, $value) = each($this->contents[$products_id]['attributes'])) {
 	  $attributes_price = 0;

Perhaps an improved solution would be to include some "flag" on each product such that the use of the specials price for attributes could be applied or not with the input to the function zen_get_attributes_price_factor would have the $price modified for that product such that

if (defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL') && ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL == 1) {
  if ($product[$i]['attribute_special_flag']) {
    // do nothing but provide the $normal and $special values
  } else {
    $special = $normal;
  }
} else {
  if ($product[$i]['attribute_special_flag']) {
    $normal = $special;
  } else {
    // do nothing but provide the $normal and $special values
  }
}
zen_get_attributes_price_factor($normal, $special, $attributes_price_factor, $attributes_price_factor_offset);

That way, the individual product could be targeted, of course an alternative is to add a parameter to the function which when provided would allow lookup of that factor "on the spot" rather than having to modify other code to swap/consider the possibility... Whatever, just some thoughts. :)

[mc12345678]

After a little code following and a few failed attempts, I found this to be a solution to the "central" issue described, though still need to identify a solution to the "difference" in price display/change of an attributes applied price... Ie. when looking in the attributes controller and seeing two prices in the Total | Disc column... It appears that when that is so, that the product page doesn't show the proper information to relate back to the actual total that will be seen once the product is added to the cart/displayed in checkout... But that's still somewhat of a separate issue.

So the "fix" is/was to duplicate an action that is in the includes/classes/shopping_cart.php file within the function cart(). Just prior to iterating each of the product a constant is defined:

if (!defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL')) define('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL', 1);

This causes the calculations on the shopping cart page to come out correctly as this affects the results of the includes/functions/functions_prices.php file's function zen_get_attributes_price_factor which in turn affects the function zen_get_attributes_price_final in the same file and also the shopping_cart class in multiple locations...

Well, one place in which that function is called is within the shopping_cart class' function attributes_price... Okay, no big deal right? Except, in the order class when generating the order price values, this class function is called to assign the final_price for each product... Thus... In order for the same "calculation" to be performed in the order class as is/was done in the shopping_cart class, a similar assignment of the constant is needed... Now.. The question becomes, should it be entered only in the shopping_cart class (three times: once in the cart function, once in the attributes_price function), should an instance be added to the order class just before the assignment of the total price so that it is defined for the attributes_price calculation as the order class uses the shopping_cart class to generate the values, or should it be applied site wide???

I chose to add it to the attributes_price calculation seeing as other functions call this class/function to perform calculations on the product and therefore it seems to make sense to apply it only there... (Yes in initial testing I did make it a global constant to see what/if anything would change in site operation.) The function is not used on the admin side, and the following store side files use this function in a default install:
includes/classes/shopping_cart.php
includes/classes/order.php
includes/modules/payment/sagepay_zc/SagepayBasket.php (Appears that the below correction will ensure proper pricing there for this setup.)

Now, using a setup similar to what has been described of a product having attributes with a price factor applied I've gone through a normal purchase without any further deductions, a sale (with a few variations of how to apply the sale), a special, combination of the two and while I did see a little oddity in calculating a sale where the new price was identified and the above setup established, it didn't seem directly related to the change (could include/exclude the constant and the result was effectively the same at the product level and responded as expected at the checkout area), but instead either my understanding or the setup... But that seems to also be a different issue.

So anyways, modifying the includes/classes/shopping_cart.php code to include the below highlighted item seemed to "fix" the issue of attributes + price factor + special price coming out to be the incorrect total at checkout.

function attributes_price($products_id) {
 	global $db, $currencies;
 	
	$total_attributes_price = 0;
 	$qty = $this->contents[$products_id]['qty'];
 	
	if (isset($this->contents[$products_id]['attributes'])) { 	
 	if (!defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL')) define('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL', 1); // mc12345678 Added to apply the attribute's price factor and price factor offset against the provided special price if a special is present otherwise against the provided price when returning the value from the function zen_get_attributes_price_factor found in includes/functions/functions_prices.php 
	reset($this->contents[$products_id]['attributes']);
 	while (list($option, $value) = each($this->contents[$products_id]['attributes'])) {
 	  $attributes_price = 0;

Perhaps an improved solution would be to include some "flag" on each product such that the use of the specials price for attributes could be applied or not with the input to the function zen_get_attributes_price_factor would have the $price modified for that product such that

if (defined('ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL') && ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL == 1) {
  if ($product[$i]['attribute_special_flag']) {
    // do nothing but provide the $normal and $special values
  } else {
    $special = $normal;
  }
} else {
  if ($product[$i]['attribute_special_flag']) {
    $normal = $special;
  } else {
    // do nothing but provide the $normal and $special values
  }
}
zen_get_attributes_price_factor($normal, $special, $attributes_price_factor, $attributes_price_factor_offset);

That way, the individual product could be targeted, of course an alternative is to add a parameter to the function which when provided would allow lookup of that factor "on the spot" rather than having to modify other code to swap/consider the possibility... Whatever, just some thoughts. :)

[lat9]

@mc12345678, I think that you're "over thinking" the solution. As I'd noted in my previous response, the issue lies in the zen_discount_calc function.

[mc12345678]

@mc12345678, I think that you're "over thinking" the solution. As I'd noted in my previous response, the issue lies in the zen_discount_calc function.

Yet to be seen. Say that because was able to successfully carry the prices from shopping cart to checkout when the constant was set either in whole on the site or just in the identified function when using a special (further the post referenced related to a sale which is a value of 5 as compared to 59 for a special, not saying that either is returning the expected result, but still a different issue).