Sorry for my delay to reply your answer, It took long since I started digging into it and I want to share my findings:
In my company we implemented a sale list price based on ATG suggestion; it means on atg/commerce/pricing/ItemPriceInfo we'll populate listPrice from "List Price" list and salePrice from "Sale Price" list.
Across the site in order to display an item price we have to chose in between both lists by applying next logic to give priority to sale price:
isOnSale() && getSalePrice() < getListPrice ? getSalePrice() : getListPrice();
The problem comes when creating a new promotion on BCC and picked the option to apply the promotion to highest (or lowest) priced item since BCC by default will add in the PDML rules a XML tag like:
< up-to-and-including number="1" sort-by="priceInfo.listPrice" sort-order="descending" >
As you may notice, the trick the PDML does is to sort all items based on "priceInfo.listPrice" and then pick the first.
When the PDML is evaluated, ATG maps this XML tag by an instance of atg/commerce/pricing/definition/UpToAndIncludingElem; there the method "evaluate" will call the method "resolveCollectionList" living in atg/commerce/pricing.definition.CompoundPricingModelExpression which at the end ends up calling the method "sortList" of the same class.
- This is a hacky approach worked for me but I already dropped:
5.a I decompiled UpToAndIncludingElem.class and added its own version of the method sortList, since this method receives a parameter "sortBy" I added a condition so if its value is "priceInfo.listPrice" I changed it to acustom new attribute "priceInfo.finalPrice"
5.b Since we had already extended atg/commerce/pricing/ItemPriceInfo class I added a new attribute called "finalPrice" with its setter and a custom getter which evaluates if there is a sale price to use as I explained in step #2
Now every time a promotion with that XML tag within the PDML rules to apply the promotion to highest (or lowest) priced item, my custom UpToAndIncludingElem's sortList method will replace the sortBy parameter to use "priceInfo.finalPrice" which getter method will consider sale price.
Why am I dropping this approach?
- Because the way I overrode the class relies on order classes are added to the project within the class path and feels risky to me
- I used a decompiling tool which I can't guarantee is the optimal JAVA code
- If later with another ATG version this flow changes I may run into trouble
What am I going to do?
I'll keep the definition of "priceInfo.finalPrice" I added on our custom class from ItemPriceInfo class
I'll look how I can change the promotion template so hardcodes my custom attribute "priceInfo.finalPrice" rather than "priceInfo.listPrice"
Thanks to people who has taken the time to read and reply my question and I hope my discovery and approach could work to you.
Of course feel confident to ask or suggest things.