http://www.ahamodernliving.com/store/pc/Roost-Flower-Frogs-Glass-Vases-2p368.htm" rel="nofollow - http://www.ahamodernliving.com/store/pc/Roost-Flower-Frogs-Glass-Vases-2p368.htm

The way apparel products are handled vis a vis sub-products (where each sub-product is the combination of options in one "bucket" as it were), and the additional price for that combination of options is stored in the sub-product record, I don't see where it's really possible to break down what each individual option is adding to the over-all price ... through I do see the confusion this causes for the user.

It seems to be that it wouldn't be too terribly challenging to do this as a merchant-specific customization IF it were the case that the additional price for any given option could be pulled from the options in the applicable option groups. The potential problem here is that this would mean that, say, Option Group A, option 1 would always have the same additional cost no matter which apparel product used it. For example, every product that had the price sensitive option of "Tall Feet" would always have to add the same price for that option. This would make it the same as non-apparel products with options that change price (at least in terms of the display in the drop down selects).

The JavaScript here is pretty complex, though, so I don't see it as something simple to accomplish ... but nothing near as expensive and complicated as upgrading to BTO and then having to reconfigure all of the products this would apply to. However, putting that aside, it does seem to me that these products would be nicely suited for the BTO version.

Sorry: long week. I didn't get that quite right.

The prices set at the Option Attribute level (and stored in the options_optionsGroups table) can be used to set pricing on sub-products (stored in the products table) when sub-products are batch generated, they are not actually used for anything else -- not the display of options on the product page nor the calculation of price. Those two things come from the sub-products.

Here's a little test you can do: Change the price of an Option Attribute assigned to one of these apparel products. View the product page, and you'll see no change. Now change the pricing for a sub-product of that product, view the product page, and you will see the change.

So, what would need to be done is to pull the price of the Option Attribute for apparel products (options_optionsGroups.price) -- as it is done for standard products -- to appear in the display of option items, but leave the rest of the price calculation and display as they are handled on apparel products (standard products don't dynamically change the price when price sensitive options are selected). 

In theory this sounds pretty simple. However, in practice there is a labyrinth of JavaScript to sort through to do it.

Switching up the display this way in general is not trivial. There's a fair deal of server-side logic and client-side logic to pick through and CSS to add to do this elegantly.

Doing it again for the mobi version is simple enough, though. Most all of the code to change is the same.

I have it demoed on both the full and mobi version of our infamous Ducky demo site now, including display for Wholesale & Customer Pricing Category users:

http://pc46a-wms-net.3060.wmsmerchantservices.com" rel="nofollow - http://pc46a-wms-net.3060.wmsmerchantservices.com

The JavaScript for Apparel products is quite a labyrinth. Turns out handling this issue wasn't so bad as I was fearing from experience modifying other display options here, though.

On the surface, it would seem that simple (I expect that's what Curt was thinking/hoping).

But these innerHTML's are rewritten on the fly on APP product pages. 

It's not trivial to modify the server-side and client side code here and to balance the CSS to do this.

I've had a good deal of experience working with changing up the display of APP product pages. The real kicker for me was the "Gap.com Style Color/Size Selectors" project I've been working on. Ultimately, there was no way to edit the PC code gracefully here, so I added a "remote control" layer over it that let's PC do it's thing and then "re-visualizes" it on a display layer. Here's an example with just the size part of it:

http://www.kickypants.com/shop/pc/viewPrd.asp?idproduct=37914&idcategory=61" rel="nofollow - http://www.kickypants.com/shop/pc/viewPrd.asp?idproduct=37914&idcategory=61

Haven't had time or demand to get back to the color option part of it yet, though.

Hi Hamish,

Yes, indeed this is exactly the case. I made sure that Avalight was clear on this, and indeed, they never ever adjust pricing at the sub-product level, but always does do by generating or regenerating from the options.

In their case that Premium White Leather may be $250 and feather cushions $150 and that this combo always adds exactly $400 to the base price, on every APP product with these options.

Ideally, BTO would be the better solution for this sort of thing; however, we've come up with an elegant "hack" for APP for those (like Curt @ Avalight) who might need to fall back on it.

It's a benefit to the entire community here to have great minds weighing in and kicking around ideas & alternatives.

PM me with your email and phone number if you'd like me to corroborate your BTO test issue.