I came across this issue to begin with using the Wildcardbi_RulePriceAttribute module to be able to specify custom prices for specific customer groups (in this case, wholesale/trade pricing) without having to setup an entire new store view for it.
The problem was though, that the custom price would be applied in the catalog, but lost when the product was added to the cart. Nor would the custom price re-appear at any point during checkout. Doing a bit of digging, I found a (rather sloppy, IMHO) typo in Magento’s core which basically prevents any Catalog Price Rule targetting Customer Groups other than “General” from working. Just before writing this, I submitted a bug report to Magento’s bug tracker in the hopes that they can fix the core. But in the meantime, if you need to get around this issue, do the following:
- Copy app/code/core/Mage/CatalogRule/Model/Observer.php to app/code/local/Mage/CatalogRule/Model/Observer.php
- Open the copied file and navigate to line 105 where you (should) see this:
$gId = $product->hasCustomerGroupId();
- Replace the above line with the following:
$gId = $product->getCustomerGroupId();
- Save and add a product to your cart (or update your cart (forces a save where this code is triggered) that has it’s price affected by your customer group. And voila – custom price now in the basket.
If you want to know the reason why it doesn’t work, hasCustomerGroupId() only returns true or false, as to whether that attribute/key is set in the model’s data array. It’s doesn’t actually return the value. That’s what get*() is for. As this typo is in an if statement evaluating whether hasCustomerGroupId() is true or not, then $gId will ALWAYS be 1 when it’s casted to an integer later on in the code. It’s a rather crap typo to be honest, and reading some of the comments in the code, they’re not all that au-fait with the English language either. But oh well.