SaleMaker only discounts base price, not attributes?

[mc12345678]

Ignore Specials Price - Apply to Product Price and Replace Special

No special associated, I only use SaleMaker

Try either changing it to the last one or simply circling back through the salemaker. After doing each of these, I was able to get/show that the base product and attributes were both on sale. Before that saw the same issue described.

[FueledByMatt]

SWEET!

Yeah I didn't try that last option before....Now i know what to do from now on, lol...thank you!

[mc12345678]

SWEET!

Yeah I didn't try that last option before....Now i know what to do from now on, lol...thank you!

Glad it worked, I knew it should somehow and was also surprised when I tried a similar setup on a brand new install... FYI, I did not look through the code posted above to validate or identify any issues. I had found "a solution" that was independent of that modification; however, it may still help others. :)


Where in that file did that additional code need to go?

[lat9]

This issue is still present in Zen Cart 1.5.5b. Here's a scenario:

A product, priced by attributes with a base price set to 0.00, includes two radio-button type attributes (Color: Red, Color: Black). Each of those attributes' prices are set as 50.00 (no price prefix) and the Discounted and Base Price flags are set.

Ensure that there are no "specials" associated with the product.

Set a SaleMaker sale for 50%, selecting Ignore Specials Price - Apply to Product Price and Replace Special from the drop-down selection that will apply to the product.

View the product on the storefront: Its price shows the salemaker price ($50.00 (struck-out), $25.00) ... but each of the attributes' prices still show the non-salemaker price of $50.00; the price when the product is placed in the cart is correct at $25.00.

The source of the issue is in the zen_get_discount_calc function, present in /includes/functions/functions_prices.php (both admin and storefront versions). Under the above scenario, the "discount_type_id" being returned is 5, taking the code down this fragment:

      case ($discount_type_id == 5):
        // No Sale and No Special
//        $sale_maker_discount = 1;
        if (!$attributes_id) {
          $sale_maker_discount = $sale_maker_discount;
        } else {
          // compute attribute amount
          if ($attributes_amount != 0) {
            if ($special_price_discount != 0) {
              $calc = ($attributes_amount * $special_price_discount);
            } else {
              $calc = $attributes_amount;
            }

            $sale_maker_discount = $calc;
          } else {
            $sale_maker_discount = $sale_maker_discount;
          }
        }
//echo 'How much 3 - ' . $qty . ' : ' . $product_id . ' : ' . $qty . ' x ' .  $attributes_amount . ' vs ' . $check_discount_qty_price . ' - ' . $sale_maker_discount . '<br />';
        break;

... and executing the highlighted portion of that code-block, essentially not applying the SaleMaker discount to the attribute's price. Part of the issue is that the $special_price_discount value (calculated earlier in that function) is set to (int)1.

There's a lot going on in that function and I don't (yet) have a proposed solution, but I do believe that this should be moved to the "Bug Reports".

[stxmona]

I just ran into this problem using Salemaker.
I have attributes that deduct an add on (deduct the pattern etc) that should always be deducted using the discount amount of the inventory item. Yes I have the "Apply Discounts Used by Product Special/Sale:" toggled to Yes just for this attribute.
I recently used Salemaker to put a category of kits On Sale and it won't deduct the attribute properly.

Is there a fix for this yet? I browsed thru the forum and didn't see it. Pardon me if there is and post a link please.
If there isn't, I know I will have to do my flash sales on kits using a different method.

Still love the Zencart and appreciate everyone's hard work!
Thank you,
Mona
www.QuiltsInMontana.com

[mc12345678]

I believe that the code modification shown in this post and presented as a pull request to the ZC development team fix this issue. In total there were basically three functions that seemed to be problematic, although one thing I'm trying to identify is if the solution provided which moves processing further into the zen_get_attributes_price_final functions_prices function to then call the zen_get_discount_calc function from within in there (and some modifications to that function as well) is the direction desired to go or instead to perform (reperform?) calculations in the attributes.php file to properly calculate/display the value(s) that would otherwise be expected.

With the proposed solution I was able to obtain the desired/expected results in the testing that was performed, though still wondering if the testing was extensive enough. Tried a lot of variables and changes to them, between price-by-attributes with a base price on the product, no base price on the product and just attribute price(s), sales, and specials...

While I indicates in that thread that the solution likely would support what was requested here, in closing browsers I realized I probably should cross post this for others to test it out and see. While the changes were made in ZC 1.5.5, it seems that the issue has existed for some time.

[mc12345678]

Seems that the following ZC commits/pulls might correct both of the issues described here. The commits/pulls are based on changes made from ZC 1.5.5 to ZC 1.5.6 (and corrections made to the first pull to ZC 1.5.6):
https://github.com/mc12345678/zc-v1-...726016a5fe4b5a
https://github.com/zencart/zencart/pull/1404/files
https://github.com/zencart/zencart/pull/2075/files