Salemaker / products priced by attribute where master category amended

[slf]

My theory is that Salemaker does not work properly for products created in one category, and then copied to another new category which is then made the master category.

Here's why I think this...

Today I have created a small sale using Salemaker (15% off every item in two categories, each category having around 6 products, each product being priced by attributes, each product being in at least 2 and often up to 8 categories covering collection, size, colour, style etc). Zen version is 1.3.7.

For one master category (let's call it CUBA) everything works fine in that every product in the category has the 15% discount applied to every attribute.

For the other master category (let's call it PULSE) the overall product price on the product info page is shown with a 15% discount, but the discount is not applied to any of the attributes.

All products in both categories are set up in the same way. See below for details. The key item being 'priced by attributes' = yes.

The one difference I can see is the way MASTER CATEGORY has been set up.

- For the category items that apply the sale discount to all attributes correctly, the MASTER CATEGORY (CUBA) is the one that the product was originally created in (ie the master category has never been changed, although the product has been copied to other categories with higher category id numbers).

- For the category items that do not apply the sale discount to the attributes at all, the MASTER CATEGORY (PULSE) is not the original. The product was created in a different category and later moved or copied to a new category which has become the master category (ie we found a better logical place to put the product). If copied we then had to change the master category via the product page.

To test this I amended my sale using Salemaker, but this time applying the 15% discount to the category that the PULSE products were originally created in. This (mostly) worked in that the 15% discount was now successfully applied to all attributes for all products. However the overall product price at the top of the product info page was no longer showing as 15% off, but at least customers could now buy at the discounted price.

So I looked at the SQL DB and saw that the products_to_categories table does not store a master category field, so if that is used it looks like the first entry (keyed on products_id, categories_id) will be used in all cases. If so, that would explain the problem. However my PHP knowledge is limited, so I can't work out if this is actually happening.

Anyway, many apologies if I have explained this badly, or if someone has already solved it, or if I've just misunderstood the way Salemaker works. I did look at the forums for a solution or bug report, and there was a close one but I tried the solution in that one and it did not work for me so I think this is a different problem. Hopefully there is enough here to enable the error to be reproduced should anyone wish to try.

SETUP
Zen version is 1.3.7. It was a fresh install but using an import file from an earlier implementation (sorry, before my time so I'm not sure which version). There are many add ons, sorry - too many to list here. We have around 10 Zencart sites and have been using them for a few years now (many thanks to all at Zencart!).

Product Master Category: (Either "CUBA" for products in the first category, or "PULSE" for products in the second category)
Product is Free: No
Product is Call for Price: No
Product Priced by Attributes: Yes
Tax Class: VAT
Products Price (Net): 0.00
Products Price (Gross): 0
Product is Virtual: No, Shipping Address Required
Always Free Shipping: No, Normal Shipping Rules
Products Quantity Box Shows: Yes, show Quantity Box
Product Qty Minimum: 1
Product Qty Maximum: 0
Product Qty Units: 1
Product Qty Min/Unit Mix: Yes

[Ajeh]

Check the Known Bug Fixes for v1.3.8 about SaleMaker:
http://www.zen-cart.com/forum/showth...924#post697924

Post #28 sounds like one that might help ...

NOTE: all of the updates are a good idea to add ...

[slf]

Many many thanks Ajeh, fix 28 worked fine!

BTW sorry for delay replying, haven't had a minute to test it and wanted to give accurate feedback...

[Ajeh]

Not a problem ... the update is much appreciated that this was able to help resolve your issue ...