Reporting and updating incorrect stock values in shopping cart

[WilsonMF]

I am working with an existing updated database for zen cart 1.5.3 using a fresh install of zen cart and the classic template. I am also using the Master branch for the plug in version 1.5.4. I am having a problem with the stock adjusting the amount in your cart based on the actual amount available. this feature will work sometimes and not others, meaning I will get the yellow pop up sometimes but not consistently. When I do get the yellow popup it will update my stock value in the cart to the total amount of all available attributes and not just the one attribute if i choose more then what is in stock. The red text under the product description will report the correct amount available for that attribute but the amount in the box will be the amount of all available attributes. Show available stock is the only item I have set to true in the configuration SBA Stock settings. When I also enable the show stock level on product page item it will also report correct stock values.

If I have a product with two colors (white and black) and I add more then I have of white item to my cart I do not get the yellow warning. It will report the amount I have in red text correctly below the description but not change the amount in the cart to the available qty consistently. If I attempt to add more of a different color (black) it will not even add the different color to my cart and oddly then give me the yellow warning yet still only show the original white item.

[WilsonMF]

Ok I think I know what is wrong with this, It appears to be in some cases looking at the total qty of all attributes instead of the attributes specific qty and in other cases looking at only the one attribute qty to make the decision as to whether or not to update the in cart amount to what is in stock. So if I have 5 blue , 5 red and 5 white I will get the popup and qty in cart adjustment if I exceed 5 for any attribute for that item. However if It will not allow me to add any other color to my cart.

If I add 2 blue, 1 white and 2 red that will work because it is looking at a single attribute as the total available qty for all attributes

[mc12345678]

Could you please identify your setup related to attributes from the product information page all the way through SBA setup/table data related to this and the purchase/selection conditions to reproduce this result. This may be either a setup condition (needing documentation to prevent) or a program logic issue (requiring recoding) or of course a mixture of both, but regardless is a condition to correct. Aspects of importance include the particular attribute settings on the product page including min/max/mix type settings; the sort order of the option name(s); the sort order of the option value(s) (these will help identify potential coding issues); option name data type; settings in attributes controller for things like default, display only, etc...; and if this is a multiple attribute product, the method of creating the combination(s) to be displayed, ie one combination at a time, using the "all attributes" or the second option of all attributes requiring a minimum of two attributes; were combinations created an attribute added/deleted and then additional combinations created/modified, and anything else that might be pertinent to reproduce this issue.

I realize it is a lot to ask, but so is finding a needle in a haystack. Seems like the needle has been found once, now the question/situation is to find it again and try to prevent it from being an issue. Your help in this matter is greatly appreciated.

[mc12345678]

Take a look at the mc12345678Mixed branch. This is the master branch with a modification to possibly work with mixed content like you may have setup. A discussion is had in issue #17 as well. It may be that these two issues are the same; however, issue #17 was "discovered" through code comparison not by system response, so really could use some feedback on the issue.

[mc12345678]

Also now take a look at the branch: mc12345678. I have incorporated notification of when adding a SBA tracked product to the cart and updating the product. The code basically overrides the default versions of the same code for update, but for adding SBA product to the cart, it overrides the ZC default code. Issue/pull request #15 includes this new code.

[WilsonMF]

I have been doing my own testing using a phpStorm debugging setup with an older simpler SBA version 1.5.1 and Zen Cart 1.5.3. I converted this version to work with 1.5.3 zen cart and everything works except the code below. The database I am using goes all the way back to the first SBA version so when I try to update my database using newer SBA versions I get hundreds of Unique Index errors. I also get a blank screen when I try to checkout with all versions and branches which I found out was due at least in part to a flat rate shipping module I had setup. After disabling I am able to get past this. I am not a php programmer but I have experience with C# and VB .net and some Java so I am able to muddle through the code now that I have a debugger environment setup. I found that my converted 1.5.1 SBA version and the original 1.5.4 SBA mod (Main) posted here did not update stock correctly for me because the code execution is bypassing This line in the

function zen_get_products_stock($products_id, $attributes = '')

// check if there attributes for this product if(is_array($attributes) and sizeof($attributes)

in the function_lookup.php and will not report the attribute stock, it instead bypasses that whole if statement and will only report the total amount in stock of all the attributes as if it was a non attribute stock. My guess is that the attribute parameter is being passed to the function by reference or value and is not getting initialized properly in the shopping_cart.php class

[mc12345678]

Not sure why this was closed, but in answer to why this is happening, Basically if the SBA table doesn't have the variant in it. As a result of the variant not being present, the function that calls the shopping cart also identifies the product as not being in the SBA table/tracked by SBA. At the moment, this is something that is possible by the store owner deleting a single line item of the SBA attribute table. Some that come to mind are to delete the variant from the admin panel window, in creation of the variants, one or more are omitted, download and subsequent upload results in a variant not existing.

These issues are all "admin" controlled aspects and can be caused much like entering phpmyadmin or similar and editing the database. Otherwise, the program will return information based on what it is able to find and when a product is found to not be sba tracked then the stock comes from the product's quantity.

[WilsonMF]

Are you referring to the problem with the Unique Index?

Also after doing more testing I found out that it will only bypass the

function zen_get_products_stock($products_id, $attributes = '')

// check if there attributes for this product if(is_array($attributes) and sizeof($attributes)<<<< bypasses this line if you exceed total product qty

only if you exceed the total product quantity of all the attributes otherwise it will correctly return the attribute variable.

Please keep in mind I am only testing with products that have variants, products without variants work correctly. The problem only occurs when you add or update more in your cart then the total qty of all the attributes for that item. At this time zen cart will report that you have exceeded the amount in stock and change the qty in your cart to the qty of all the attributes. Its because will not update the $attribute variable in the shopping cart class so it becomes null when passed in the function zen_get_products_stock($products_id, $attributes = '') even though there is in fact attributes. If you do not exceed the total of all attributes it will work correctly but not update your cart to what is left in stock for that attribute but it will report that you have exceeded the stock attribute amount and allow you to adjust it.

I am not sure if this has been fixed in later versions but it should be tested in your current branches

[mc12345678]

I haven't looked into indexing issues; however, that will definitely need to be something to address as the attribute concepts increase (ie., more attributes expected the greater the need to be able to quickly look them up in the database to be accomplished via index.)

The other aspect, so, one could use an SBA tracked item but not provide data for every variant, the absence of that variant could cause some of the above.

That said, one of the changes made in the mc12345678 thread is to prevent adding a product variant quantity that exceeds the available quantity for that variant in the add_product and update_product subroutines; however, the user_action version does not have an applicable override per se as that option itself is an override.

So the issues observed when the total number of a product exceeds the available quantity is not sustained to allow the problems that have been observed above if they are only seen when exceeding the available quantity.

Also, now and depending on the admin setting of if it is possible to complete the order while product is out-of-stock, then the quantity should get reset following the ZC standard method(s).

Also in saying that have been testing with variants, have you tested a product that has attributes, where the mixed Product Qty Min/Unit Mix has been tested with it set to yes and perhaps a minimum quantity of a product then try adding different quantity of attribute products to see if the conditions are satisfied for products not tracked by SBA while SBA is installed? Basically came across a condition in the code that was different between what ZC had provided and what SBA was trying to add into the process.

[mc12345678]

Just completed some testing using the branch mc12345678_ZC154 on a brand new ZC 1.5.4 installation, regarding stock reports and options for a product that has two attributes, each attribute having three options, each combination having a total of 175 items causing the grand total available to be 2100: 1) A quantity of 5000 was selected to add to the cart.

1.A) If configurations->stock->allow checkout was set to true, then a red indicator would appear, the total number to add to the cart showed 5000, but there was warning text that there were only 175 available. 1.B) if configurations->stock->allow checkout was set to false, then a yellow indicator would appear stating that the quantity add to the cart had been modified. 1.C) when 1.A above was first performed, without clearing the cart, and then selecting a variant different than before and performing 1.B above, the original quantity of 1.A remained, the quantity in 1.B was maxed at 175, but when the refresh button was selected next to the first product selection, the quantity for that was then modified to 175 and the yellow message notification was also provided.

2) A total greater than 175 but less than the max for all products is selected while not possible to checkout more than available (350 selected):

2.A) cart got updated to show only 175...

Unless some other condition can be identified, I believe this issue is now resolved for standard product. (Example used was a copy of the ZC default product: Hewlett Packard - by attributes SALE with Special

[mc12345678]

Seeing no further comment and unable to reproduce any issues associated, with the code captured in issue #23, this issue is considered closed. If it needs to be reopened, please start a new issue with detailed information to reproduce the problem and to identify what "version" of software was used.