Product Option Pricing Defect or Design Alteration?

[Nimitz1061]

I am attempting to setup some product attributes / options and have run into problems with price handling.

The instructions read as though the option "price" field is a modification of the base product price.  Whether the modification acts as a price increase or decrease appears to depend on the setting of the prefix.  The current user documentation reads:

Prefix: If you wish to ADD the extra amount, i.e. $2 MORE for this option, select "+" If you wish to DISCOUNT this option, select "-"

However, the actual prefix settings in 1.0.3  read either a dollar sign

$

or a percent sign

%

.

In either case, only the base product price is ever entered into the cart.

The sample product I am working with can be seen at:

https://lifesolutionsplus.strikehawk.com/dev/index.php?rt=product/product&product_id=12

Can someone clarify what is supposed to happen here ??

David

[Nimitz1061]

Looked at http://demo.abantecart.com/index.php?rt=product/product&product_id=64 as an example of a product with options in the demo site.

Adding to cart appears to work as I'd expect here, even after adding weights and separate sku's to various options.

The only remaining difference I see is that one of the options has a price modifier of 0 and no weight...

[abolabo]

hello.
sorry, i don't understand what's problem.
If you set -22 "$" in your's product option which have base price $200 after option choose you will have price $178
If +22 "$"     ->    $222

If -22 "%"     ->     $156
If +22 "%"    ->     $244

[MLCS]

I cant see what you are meaning...
However...please fix one problem I noticed by what I asked here

http://forum.abantecart.com/index.php/topic,228.0.html

[abantecart]

I think we finally identified the problem.

Simple explanation to the bug: Adding options to the cart do not work if global attribute used with multiselect field values.

We are working on the issue resolution.

[Nimitz1061]

hello.
sorry, i don't understand what's problem.
If you set -22 "$" in your's product option which have base price $200 after option choose you will have price $178
If +22 "$"     ->    $222

If -22 "%"     ->     $156
If +22 "%"    ->     $244

One problem is that what you are describing is NOT the functionality described in user documentation for products Option Tab.  It appears that a UI control was re-purposed without a documentation update.  This is not good as it increases uncertainty as to the usability of the cart, and presents as a possible bug when it does not need to do so.

Note that "prefix" is NOT a good description for this feature in any case, as it has nothing to do with whether or not the price is prefixed with anything.  This is a calculation method toggle.  Not a bad feature, but not what the label leads the user to expect.

David

[Nimitz1061]

I think we finally identified the problem.

Simple explanation to the bug: Adding options to the cart do not work if global attribute used with multiselect field values.

We are working on the issue resolution.

I should have mentioned that the option type is checkboxgroup. 

David

[Nimitz1061]

I've tried using a select box and encountered another oddity.

In setting up a global attribute (which seems to be necessary before you can add options to a product), I created a selectbox with 4 options.  Once I add this attribute to a product, none of these options show up.

So, I'm not sure why selectbox global attributes even offer the ability to add element values....

David

[Nimitz1061]

I've now tried a simple checkbox.

This works, for some value of works.  But once again, there is a problem.  Now that I've set these options up to use price off sets, the absence of the +/- prefix in the cart makes it appear that the price offset is the actual product price.

[abantecart]

David

Thank you for all the comments. Here is a summary with reply to all your posts in this topic.

- Yes. Manual needs to be updated. We are working on it.
- You are right about "prefix" it has to be renamed. Good catch. We will rename it
- Regarding Global options. Let me clarify.
Global Attributes set the template that can be used for grouping and unifying option value name. Once added to the product you need to select actual option values based on given product. System can not copy all option values, because this is something that requires specific setting.
Important to notice that it is not required to create global options. You can add new option and values directly in the products.

Global Attributes are begin used across other areas, such as customer, order, product attributes. These are to extend details in other areas across application.
They simply bare responsibility to set a template data that can be used (copied or linked) to other areas.

- For setting up option values with positive (no sign) or negative (-) values. If you put "-" sign in the number it works just fine. Price is adjusted according.
See images attached.

[Nimitz1061]

David

Thank you for all the comments. Here is a summary with reply to all your posts in this topic.

- Yes. Manual needs to be updated. We are working on it.
- You are right about "prefix" it has to be renamed. Good catch. We will rename it

Actually, renaming may not do it.  I'll expand on this below.

- Regarding Global options. Let me clarify.
Global Attributes set the template that can be used for grouping and unifying option value name. Once added to the product you need to select actual option values based on given product. System can not copy all option values, because this is something that requires specific setting.
Important to notice that it is not required to create global options. You can add new option and values directly in the products.

I'm familiar with the concept.  This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type.   If the values can't be copied, why ask for their input in the first place?  Does your development team understand the concepts as they apply to a single, unified implementation?

Global Attributes are begin used across other areas, such as customer, order, product attributes. These are to extend details in other areas across application.
They simply bare responsibility to set a template data that can be used (copied or linked) to other areas.

- For setting up option values with positive (no sign) or negative (-) values. If you put "-" sign in the number it works just fine. Price is adjusted according.
See images attached.

I'll grant you that the pricing adjusts accordingly, when the code works.  What does not happen is any clear indication in the presentation  that the price adjustment IS an adjustment from a base price.  This is just silly on two levels. Just doing it this way in the first place. Compare with what happens in a brick and mortar store when you shop.  Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price??  Doing it poorly in the second place.  Some language in the option block that price is "base price +  X" or "base - X" or 'base price' itself would be more clear.  Notice also that the drop down select box offers no information about pricing adjustments whatsoever, even when there is one.   These are going to become bigger conversion blockers as the number of older users increases, which it has been doing rapidly for several years.

The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart.  Example:  The base price could be labeled as a base price with its own prefix.  "As low as $xx.xx", "From $x.xx", "Starting at $x.xx"  or something similar makes it clear that the parent product price is not fixed.  This has legal ramifications for the store owner, and probably should not be left to a template designer.

The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system.  I have grave doubts about the usefulness of this approach.  In practice, it is highly annoying to the store owner, and very time consuming to all involved.   My main concern at this time is getting the existing system to work well enough to get this store deployed within the next week or two. 

David

[abantecart]

This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type.   If the values can't be copied, why ask for their input in the first place?

Option values are available to be selected  once you add global option to the product. User needs to select option value that applies to given product and set other data.
Pretend that we load all option values from global option. There are no details about other information for these values. User needs to populate and delete unneeded values. it is extremely easy to pre-populate values.
Any suggestions to make it UI friendlier are welcome.

Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price??  Doing it poorly in the second place.  Some language in the option block that price is "base price +  X" or "base - X" or 'base price' itself would be more clear.

I am not sure this is applicable to large retailers. They use SKU based products that will be new product for each variation and later combined to 1 set. I was looking for any large online retailer to see example with option and price modifier and could not find any. If you have link to some, example would be great.
I understand what you say and we will try to put it more clear.

Notice also that the drop down select box offers no information about pricing adjustments whatsoever, even when there is one.

Confirmed bug.

The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart.  Example:  The base price could be labeled as a base price with its own prefix.  "As low as $xx.xx", "From $x.xx", "Starting at $x.xx"  or something similar makes it clear that the parent product price is not fixed.  This has legal ramifications for the store owner, and probably should not be left to a template designer.

I propose to have this as a set up:
Price Modifier: -$, +$, -%, +% (this will be as current prefix select box)
What is your take on this?

The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system.  I have grave doubts about the usefulness of this approach.

I am sorry, but I do not understand your comment. please clarify.

[Nimitz1061]

This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type.   If the values can't be copied, why ask for their input in the first place?

Option values are available to be selected  once you add global option to the product. User needs to select option value that applies to given product and set other data.
Pretend that we load all option values from global option. There are no details about other information for these values. User needs to populate and delete unneeded values. it is extremely easy to pre-populate values.
Any suggestions to make it UI friendlier are welcome.

I think I've already acknowledged that it makes little sense to pre-populate option values from the global attributes.  I'm taking it that you are accepting that this is a bug where it occurs and that the behavior will be removed from the cart.  I'd agree with this approach.

Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price??  Doing it poorly in the second place.  Some language in the option block that price is "base price +  X" or "base - X" or 'base price' itself would be more clear.

I am not sure this is applicable to large retailers. They use SKU based products that will be new product for each variation and later combined to 1 set. I was looking for any large online retailer to see example with option and price modifier and could not find any. If you have link to some, example would be great.
I understand what you say and we will try to put it more clear.

All inventoried products everywhere are sku based.  SKU is the Stock Keeping Unit number used in counting products.   That you don't find any big box retailers using this approach is confirmation of my point - that this type of approach makes little sense when trying to communicate a clear offer to buyers.  Any attempt at clarification will be welcome.

The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart.  Example:  The base price could be labeled as a base price with its own prefix.  "As low as $xx.xx", "From $x.xx", "Starting at $x.xx"  or something similar makes it clear that the parent product price is not fixed.  This has legal ramifications for the store owner, and probably should not be left to a template designer.

I propose to have this as a set up:
Price Modifier: -$, +$, -%, +% (this will be as current prefix select box)
What is your take on this?

I wouldn't do it.  There are two aspects to be managed here - the sign of the modifier in the calculation, and the display of it in the catalog.  Handling the issue this way tends to create confusion in both aspects.  Developers will be tempted to flip the sign of the input based on the sign indicated in the selector.  It would be more clear to say "Modify Price By" or "Price Modification Type" rather than just "Price Modifier".  In any case, this decision may not need to be made.

The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system.  I have grave doubts about the usefulness of this approach.

I am sorry, but I do not understand your comment. please clarify.

I'll try.  The global attribute system is basically used to select a form input method (check box, radio button, dropdown, text, text box, etc).  The basic approach here is "I have a page, this is what I want it to look like".    It switches the store operators mindset towards page display, rather than product offer construction.

Two major problems with this are that the offer construction is the actual make or break process that the store owner has to perform and that this approach splits that process up, asking them to map out the page, BEFORE asking them to map out the offer.  Another way to put this is that the application is asking store owners to use page design terms to draft a product offer.  This is bad in that few store owners KNOW how to use page design terms.  In a brick and mortar environment, no one maps their shelving placement by option or option value.  Its done by a number of approaches centered around things like the products department, style and sku.

It may be helpful to start with looking at how global attributes addresses the issue of offerings which:

A.  Allow the selection of a quantity (any quantity) of one item from a simple list of selections (as in, do you want red, blue or green pants?).

B. Allow the selection of  a quantity of more than one item from a simple list of selections (would you like some red pants, blue pants  AND green pants?)

C.  Allow the selection of a quantity of one item from a layered list of selections  (Would you like your red pants with a 32 inch waist and 38 inch leg length or ??)

As we examine these carefully, you will often find that the logic in defined selection options simply can't or don't match the real world relationships between inventory on hand and a complex product offering.

[abantecart]

Thank you for your help and effort to explain this.

I am working on this section now and I think it is all clear what needs to be done. We will be included in version 1.1 (next one).