Starting at pricing using Inventory Variants

[lesliekirk]

Is it possible to display a "Starting at" price on the CTGY Page that is pulled from the Inventory Variant (if there is one)?

[Bruce - PhosphorMedia]

If your not using (or need to account for) customer discounts, what we do is stuff the lowest price (from) into a product custom field. You can populate that field by creating a product listing page that has protected access and run through the product/attribute listing then save it to the product custom field. This has the advantage of reducing processing time on the Category Page.

[lesliekirk]

If your not using (or need to account for) customer discounts, what we do is stuff the lowest price (from) into a product custom field. You can populate that field by creating a product listing page that has protected access and run through the product/attribute listing then save it to the product custom field. This has the advantage of reducing processing time on the Category Page.

Yeah, I need to account for that "stuff" too.

[Jim Cockerham]

Yeah, I need to account for that "stuff" too.

Did you ever find a solution for this Leslie?

[William Davis]

I've seen some sites displays both lowest to highest price.

Walmart Example:
image_2471.png

[lesliekirk]

I've seen some sites displays both lowest to highest price.

Walmart Example:
image_2471.png

Have you seen any Miva stores? Examples of those are what we need and then to find out "how did they do that?"

[Kent Multer]

I've done this sort of thing for a couple of clients, as part of a custom module. But a module isn't always needed; I can write some template code to pull the number from the store's DB. As Bruce mentioned, this could slow down the page load somewhat. But I know some shortcuts to improve the performance, as long as the number of products per page isn't too high, and the products don't have large numbers of variants. You can PM or email me for details.

[Brennan]

Here is an code sample to calculate the high/low range for a product:

https://docs.miva.com/code-samples/variant-price-range

Keep in mind this is an "expensive" calculation to make since you're loading and looping though all variants. If a product has 10 variants its not an issue. If a product has 1000 variants its will add some load time to a page. If you're doing this dynamically on a category page with a lot of products there is going to be a negative impact on load time,

The better method I would recommend would be to have a feed that has this code and calculates the lowest price or range then saves that value back to a custom product field. Then you can load that data on any page you need it and set the feed to re-run nightly.

[Bruce - PhosphorMedia]

he better method I would recommend would be to have a feed that has this code and calculates the lowest price or range then saves that value back to a custom product field.

Can confirm, this is the way to go. We do this with almost all of these types of items. You can then set the feed to run every day or whenever (or remember to do it manually after updating pricing for example.

[lesliekirk]

I'd like to circle back to this but for the use in a PROD page. The snippet Brennan referenced uses the EP Toolkit. I have another snippet that also uses the Toolkit. The site I need this for doesn't have the Toolkit and I know it really should not be added at this point in time. The bigger question is, is there an easier way other than having to do what I would consider "jumping through hoops" just to display a price range?

[Nick]

lesliekirk Here is a snippet that will work without the use of Toolkit and is probably the most efficient way to process the data: https://snippets.cacher.io/snippet/704a08a947a98e6d1155

That being said it would be best to use a feed to process that code then save the value in a custom product field. For even better optimization the Product Data Fields and Feed module can be used to update the custom field each time the price of the master or variant has been updated.

[Bruce - PhosphorMedia]

Wow! How did i miss that?

Storing 'semi dynamic' data in custom fields is a great way to speed up/compartmentalize code. We do this a lot for semi dynamic data especially at the category/product level when the routine would have run dozens of times for each product. Have always just relied on using a standard template (we call it workbench) that gets triggered through CRON.

This cuts out a lot of extra steps.