You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
Pages: 1
If the Product Sort/Search Price field tied to the retail price, what happens when a product line pricing is control only by product options?
Offline
The product sort/search price is not tied to the product price. You add/maintain the sort price separately. This is done to cover you in the situation where your product price is not really the price that's paid, or should be sorted on (like your case where the options contain the pricing).
Offline
Does the filtering code check through the various pricing fields to find the lowest active price? Or does the filter code only run on the product sort/search price field?
Offline
Wouldn't it be more logical to run on the current pricing method set for the product? One less data field to update.
Offline
You would think, but in your case, you really want control of that sort price because you'd like to make it scale down and possibly contain option pricing. Your case is a prime example of why it is like it is.
We've changed this a bit in V9, in that it auto-calculates when you update product offers based on the lowest calculated price for the product offer you've updated. In V9, options are pretty much replaced with inventory items - still there, but not used heavily. Sort and search price auto-calculation in V9 does not extend to options, but does (like V8) provide the entry field, if you want to use it.
Offline
So let me see if I understand this.
Widget A (old listing method)
Pricing Type: regular
Regular price: 19.95
Sort price is 19
Widget A (new listing method)
Pricing Type: option based
Regular price: 0.00
Sort price: 0
Option A: paper document price 19.95
Option B: pdf document price 9.95
This is how I have been currently listing newer products. Assuming the new method require a sort price of 9?
Offline
Pages: 1