Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
Marc Boon
We have this problem only with products that use SBA.
The price in orders_products gets rounded to 2 decimals somehow, where the pricein orders_products_attributs is shown correctly
see icture, top is orders_products, below orders_products_attributes
Attachment 17999
For your system, can you show data for a product that is setup with similar price-by-attributes conditions but is not assigned to SBA as a comparison? Please include both the data of the page information (whether it shows 24.99 or 25.00) and the purchase result data as provided above.
When the product is not tracked by SBA, then the built in ZC calculations and processing are used. If there is a difference in display of the two product (tracked with SBA and not) at the product page display, then please identify the number of attributes assigned to the product and the configuration settings for Dynamic Dropdowns. This last piece of information is to understand the setup and either provide guidance on a change or correct the code, it is not to suggest (yet) changing those settings.
1 Attachment(s)
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Attachment 18001To partially answer the above question, from my mobile device I setup a product that was not tracked by SBA on a ZC 1.5.5f system that has Dynamic Price Updater installed (note that DPU uses the shopping cart class to identify the price which is displayed at the upper portion of the screen). Added a tax class and associated settings for a 6% sales tax, display the price on the store front with tax included, and added a product priced by attributes with a single attribute having the price of 23.5849.
The result (seen in the attached image) is that the product price is shown as 24.99, but the attribute's price shows as 25.00 which is the same values reported in the previous posting.
Conclusion? SBA does not cause the displayed price difference. Unfortunately it also doesn't "fix" it either (yet). As said before there are some calculation differences that have been identified in the software that show themselves in different areas. For the most part it is a result of the multiple ways that calculations are performed, carrying of significant figures and various independent and integrated methods of calculations. For those that remember their math days, generally speaking the system of equations is overdetermined causing there to be insufficient degrees of freedom to find the one solution to each of the sought after number values. Ie. In one case looking for the exact value of the tax and at the same time the overall price to pay or in the case of VAT the price of each product before taxes and after taxes as well as the tax itself. There is likely to exist one or more occurrences where quantity, price, and tax will not all "add" up. This is pretty much regardless the software system being used. There are ways to prevent such issues from generally being seen, but...
I'll give a quick example. Went to somewhere where a product was 0.40 and had I think 11% sales tax... buy one item and the cost is 0.44 (0.444)... but buy 2 and the total cost is 0.89 (0.888 which is effectively 0.444 each or after purchase is 0.445 each)... as a consumer, buy two but one at a time and save money, right??? But I go so far as to ask how is that "penny" handled? Who gets it? Who has to "pay" extra? (ie. Those single purchases add up over time and if one were to count the number of single purchases, add up the sale price and then try to determine the amount of tax to have been collected, the store comes out short... but if many buy 2 at a time, the reverse is true isn't it? The store comes out ahead... but if the quantity of single item purchases and the tax collected for each of those is added together and the same done with the 2 item purchases, then the books balance from that perspective if ignore the total money collected for the product and the total tax collected... it's an accountant's issue in my mind, but...)
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
mc12345678
For your system, can you show data for a product that is setup with similar price-by-attributes conditions but is not assigned to SBA as a comparison? Please include both the data of the page information (whether it shows 24.99 or 25.00) and the purchase result data as provided above.
When the product is not tracked by SBA, then the built in ZC calculations and processing are used. If there is a difference in display of the two product (tracked with SBA and not) at the product page display, then please identify the number of attributes assigned to the product and the configuration settings for Dynamic Dropdowns. This last piece of information is to understand the setup and either provide guidance on a change or correct the code, it is not to suggest (yet) changing those settings.
We are using the ZEN cart to sell tickets for our steamtrain.
there are multiple products that sufferfrom this problem.
when i look in orders_porducts table i see all SBA related prices at 2 decimals rounded
the products that are affecte have two options,
the customer has to select a date and a type of card ( children, adults etc )
prices for products without SBA get noted in orders_products with all 4 decimals
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
Marc Boon
We are using the ZEN cart to sell tickets for our steamtrain.
there are multiple products that sufferfrom this problem.
when i look in orders_porducts table i see all SBA related prices at 2 decimals rounded
the products that are affecte have two options,
the customer has to select a date and a type of card ( children, adults etc )
prices for products without SBA get noted in orders_products with all 4 decimals
-so that last remark points to SBA imho...
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
Marc Boon
We are using the ZEN cart to sell tickets for our steamtrain.
there are multiple products that sufferfrom this problem.
when i look in orders_porducts table i see all SBA related prices at 2 decimals rounded
the products that are affecte have two options,
the customer has to select a date and a type of card ( children, adults etc )
prices for products without SBA get noted in orders_products with all 4 decimals
Do these product (SBA/not SBA) have the same prices? Need to be sure that we are comparing same numerical values.
Also to be sure, the only issue of difference being discussed or of concern between how the standard ZC works and how it appears that SBA is working is the storage of the orders_products data, correct?
2 Attachment(s)
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
mc12345678
Do these product (SBA/not SBA) have the same prices? Need to be sure that we are comparing same numerical values.
Also to be sure, the only issue of difference being discussed or of concern between how the standard ZC works and how it appears that SBA is working is the storage of the orders_products data, correct?
here is the product with the SBA
Attachment 18002
here a test-product without the SBA
Attachment 18003
both have the same bruto pricing, but different results as seen
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
I realize that you have a problem that you want fixed and while SBA doesn't currently fix the problem, contrary to the original post about the problem, SBA doesn't cause it and truly is unrelated to it. I am able to say this from independently performing the following tests:
It appears that I didn't give good direction on how to setup a product that has all of the same characteristics as the original reported, but is not Stocked by Attributes. So, I did this, but it also means that you should still do this to prove to yourself what I am saying.
Starting with a ZC 1.5.5f system. I went into configuration->my store and set the display price with tax for store and admin to true. I then created a tax rate and associated zoning to be able to apply a 6% tax rate to product. I then created a product that is enabled, priced-by-attributes, has a 0 price, has the tax rate just created, and has a quantity of 100.
I then went through the save process.
I went into the attributes controller for that product and added a single attribute of option name size and option value of small. I set all buttons on the attribute except for display only and required. I added a price to the attribute of 23.5849.
I saved the attribute.
I verified that I had the shipping option of in store enabled and the payment of check/money order enabled. Neither of these adds a price to the overall operation working like a digital product (for shipping).
On the store side, I now went through the purchase process for the product. The product page showed a product price of 24.99, the attribute showed 25.00. Going through checkout, using pickup in store and check/money order, the shopping cart showed 24.99 all the way through to checkout success with tax being 1.41. After checkout, looking at the orders_product for the order, it was shown as 23.5800, the orders table reflected a total price of 24.9948 and the orders_products_attributes shows 23.5849. This is before SBA was even installed. Which means that SBA as I said, does not cause the pricing problem that you are seeing... it is something that exists already in the ZC software.
Further, when I attempted to create a product that didn't have attributes (and therefore wasn't priced-by-attributes and also not controlled by SBA) that had a "final" (gross) price of 25.00, it had a net price of 23.5849. On every page except for the confirmation page the price showed as 25.00. On the confirmation page the price showed as 24.99...
The rounding is occurring in includes/classes/order.php within the function cart() where the final_price is being set at:
Code:
'final_price' => zen_round($products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']), $decimals),
and where $decimals is set at the beginning of the function as:
Code:
$decimals = $currencies->get_decimal_places($_SESSION['currency']);
For the Netherlands this results in a 2 decimal quantity being set for the products final price. SBA doesn't modify either of these values. Then after the assignment of final_price to the product, the overall price to collect from the customer is "calculated" which in this case results in the loss of a "penny". Perhaps ZC should behave differently when the price of the product includes the taxes (such that the ORDER_PRODUCTS table is populated with the four decimal value instead of rounding to the current currency).
Anyways, most of the above really should be addressed outside of this forum and I recommend that you continue to seek resolution and perhaps a global solution for all conditions, but outside of the Stock By Attributes forum.
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
error in logs
zc 1.5.5f, classic responsive clone, php 7.1.1
Found this error from a few days back in my log folder:
HTML Code:
[01-Jun-2018 08:30:38 America/Chicago] PHP Warning: Invalid argument supplied for foreach() in root/includes/classes/class.products_with_attributes_class_stock.php on line 1285
[01-Jun-2018 08:30:38 America/Chicago] Request URI: /index.php?main_page=product_info&cPath=26&products_id=500&number_of_uploads=0&action=add_product, IP address: 209.5.238.12
#1 products_with_attributes_class_stock->zen_get_sba_attribute_info() called at [root/includes/extra_cart_actions/stock_by_attributes.php:883]
#2 include(root/includes/extra_cart_actions/stock_by_attributes.php) called at [root/includes/main_cart_actions.php:26]
#3 require(root/includes/main_cart_actions.php) called at [root/includes/init_includes/init_cart_handler.php:44]
#4 require(root/includes/init_includes/init_cart_handler.php) called at [root/includes/autoload_func.php:48]
#5 require(root/includes/autoload_func.php) called at [root/includes/application_top.php:170]
#6 require(root/includes/application_top.php) called at [root/index.php:26]
Checking on site - I am able to add product (has one attribute variable only - size) to cart without throwing error. The product cateogy 26 is Qiviut Socks on site in my sig.
Thx
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
soxophoneplayer
error in logs
zc 1.5.5f, classic responsive clone, php 7.1.1
Found this error from a few days back in my log folder:
HTML Code:
[01-Jun-2018 08:30:38 America/Chicago] PHP Warning: Invalid argument supplied for foreach() in root/includes/classes/class.products_with_attributes_class_stock.php on line 1285
[01-Jun-2018 08:30:38 America/Chicago] Request URI: /index.php?main_page=product_info&cPath=26&products_id=500&number_of_uploads=0&action=add_product, IP address: 209.5.238.12
#1 products_with_attributes_class_stock->zen_get_sba_attribute_info() called at [root/includes/extra_cart_actions/stock_by_attributes.php:883]
#2 include(root/includes/extra_cart_actions/stock_by_attributes.php) called at [root/includes/main_cart_actions.php:26]
#3 require(root/includes/main_cart_actions.php) called at [root/includes/init_includes/init_cart_handler.php:44]
#4 require(root/includes/init_includes/init_cart_handler.php) called at [root/includes/autoload_func.php:48]
#5 require(root/includes/autoload_func.php) called at [root/includes/application_top.php:170]
#6 require(root/includes/application_top.php) called at [root/index.php:26]
Checking on site - I am able to add product (has one attribute variable only - size) to cart without throwing error. The product cateogy 26 is Qiviut Socks on site in my sig.
Thx
I was able to reproduce this error locally if a product with attributes, that is tracked by SBA and has radio attributes was attempted to be added to the cart but without any selections made. (Was able to use the browser editor to remove selected="selected" from the option value... The error was generated and the product was added to the cart without any attributes present. Will look into it though on preventing the processing/issue.
Re: Stock by Attribute v4.0 addon for v1.3.5-1.3.9
Quote:
Originally Posted by
mc12345678
I was able to reproduce this error locally if a product with attributes, that is tracked by SBA and has radio attributes was attempted to be added to the cart but without any selections made. (Was able to use the browser editor to remove selected="selected" from the option value... The error was generated and the product was added to the cart without any attributes present. Will look into it though on preventing the processing/issue.
Thank you.
I use the radio button for size select and I have one size set as default, along with default quantity of 1. I guess some one must have back-spaced the quantity out but not selected (or wearing tri-focals like me and thought they hit the selection button but missed) and then hit add to cart. Orders have gone through fine on this product so the error threw up an 'oh no somethings gone wrong' moment for me. Thanks again for looking at this.