Dynamic Pricing Frustrations

[koala]

I've been trying to work with Miva Support on this, but I haven't gotten anywhere close to a workable solution.

In a nut shell, dynamic product pricing will not work when a swatch drop down attribute is assigned to the product.

The only way to actually get it to "work" is to generate inventory variants. I don't want to do this - it can create literally hundreds of variants for one product.

Here is a good example: http://dev.tmasc.ca/team-7-dining-ch...ing-chair.html

This chair comes in 7 types of wood and 20 leathers. It's made to order, so tracking inventory isn't needed. Try selecting a wood type which has an upcharge and you'll see the "price as selected" js doesn't dynamically update. It will only do so if I generate variants.

I'd really like to be able to use the built-in swatch drop down without resorting to generating variants, but I don't know how to accomplish this!

[Rick Wilson]

By definition to have a dynamic price you should use Variants even if you're not tracking inventory with them (that way there's specific selection tied to a specific price).

[koala]

This is why I'm confused, though. If I have several drop down lists on a page, the dynamic price updates just fine. It's only specifically when a swatch drop down is in the mix, that this no longer works.

[Rick Wilson]

I'll ask Brennan to chime in.

[koala]

Thanks Rick. I'd love to find a solution to this. Variants are nice if you have, say, 5 colours and 3 sizes. But if you have 10 or 20 product sizes + 40 colours, the number of variants is insane and totally not necessary.

[Bruce - PhosphorMedia]

I know Brennen will have a more accurate and detailed explanation, but I believe the problem is the data and structure of the data produced by the built in image swap is not compatible with the dynamic attribute pricing. I believe you least frustrating answer to this would be a custom solution for image swap that works with the built in Dynamic Attribute Pricing or a new DAP function.

[lesliekirk]

This is why I'm confused, though. If I have several drop down lists on a page, the dynamic price updates just fine. It's only specifically when a swatch drop down is in the mix, that this no longer works.

How did you get the dynamic pricing to work without the inventory variants? I have a site that I have generated millions of variants just to make the dynamic pricing work.

[koala]

How did you get the dynamic pricing to work without the inventory variants? I have a site that I have generated millions of variants just to make the dynamic pricing work.

It just worked out of the box. I didn't have to change or modify anything. This is why I think there is something amiss specifically with the swatch drop down. Unfortunately my knowledge of javascript is too basic to likely figure it out on my own.

As an aside - how enjoyable is it using the autocomplete search feature in the admin when you have so many variants? I could see this being a total nightmare.

[koala]

I know Brennen will have a more accurate and detailed explanation, but I believe the problem is the data and structure of the data produced by the built in image swap is not compatible with the dynamic attribute pricing. I believe you least frustrating answer to this would be a custom solution for image swap that works with the built in Dynamic Attribute Pricing or a new DAP function.

You may very well be 100% right on this. It's kind of unfortunate as I just "assumed" it would work. This was one of the main reasons we were finally ditching MMUI. I'm building swatch arrays manually in our current live website and it's a total PITA :)

[Brennan]

Normally in order to get the price to change automatically based on the attribute selected you must use inventory variants. This is the only method miva supports by default. There are some use cases where you don't want inventory variants for whatever reason.

Because of that in a few of the readythemes (suivant, optics, iron & wool, coustic and levels) we added custom javascript specific to those themes which will do this price change for you without inventory variants. This is why it is working for you on some products even though do you don't have variants.

I'll check and see why it does not work with swatches but it may need to be customized to support those.

[koala]

Thanks Brennan. I'm happy to hire Miva to do the changes if needed, but I was hoping there might be a simple way to just get it to work.

inventory variants are fantastic for our products when we want to filter one attribute based on another (ie: correct sized box spring for the selected mattress size). But if you have two or three attributes and there are zero dependencies, it's really not a needed feature for us.

[koala]

Has there been any progress on this? We've really hit a bit of a wall in the development of our new Miva site.

[inger]

I have a problem related to this. In the development store I'm working on we have a lot of products that come in just one size, colour, shape or whatever. I would think that there is no needs for using attributes. But the price next to the product does not update dynamically if someone wants to buy 2 or 3 or several of the same product. Miva support told me, when I called them, that this is correct, but it would be possible to edit the file scripts.js to enable the dynamical update. I'm not that much js savvy, is there anyone out there who could help?

As to the swatches radio buttons: I tried it, and as people here also found, it didn't work as to updating prices. I changed it to regular radio buttons without removing the swatches, and it works fine. The swatches are still to be seen, but not as pretty as it was with the swatches radio buttons.

Inger, Norway

[lancermedia]

Would love an update on this as well. We are seeing the same using Levels. The dynamic pricing will only change on a non inventory tracked product if it doesn't have a Swatch attribute on it.

And to be clear, Miva really wants us to always use inventory variants for this? So if we did use inventory variants, the pricing boxes on the attributes config aren't used? You have to manually go into each inventory variant inactive product that was generated, add up the price choices for that combined generated product, and use that as the variants price?

The current store I'm working on sells glasses. One of the attributes is frame color. We really want to use swatches and image machine to swap out the color images. Seems like the way Miva has this setup, you can do both - use image machine AND use dynamic pricing?

-Kevin

[koala]

Hi Kevin,

Yes, you have to painfully go and update every variant when your price needs to be changed. If you try to generate variants and use the "use master product + it's attributes" - it doesn't work.

It's super frustrating :(