Messages

Thanks,  We have installed and tested and  I can confirm that the quick fix does work on the other versions.   

But thought other Admins might appreciate the clarity of the action needed.

Thank you for the heads up.   
But could you please provide guidance:
1. is this change ONLY for establishing new connections  or
2. if Admin is already using the PayPal Commerce,  eg since AbanteCart 1.3.3  which uses PayPal Commerce v. 1.0.0  does it need to be installed there also

Is the quick fix to be installed there?  I see the version  in quick fix is changing from 1.0.2  to 1.0.3,   but neither AbanteCart 1.3.3 or 1.3.4  are using v 1.0.2   --   1.3.3 is  PP commerce 1.0.0  and 1.3.4  is 1.0.1

thanks in advance for more clarity.

You can set the number of decimal places showing within the System > Settings> localization > currencies
https://abantecart.atlassian.net/wiki/spaces/AD/pages/15270043/Add+or+Edit+Currency

Please check to see if jpeg is set up in the allowed file extensions


https://abantecart.atlassian.net/wiki/spaces/AD/pages/24281122/Add+new+resource+type

Update  to Nuno report of "not working" :   somewhere along the line the file he used was corrupted,  It is unknown at what stage.

We have corrected the issue for him on his site.   And just in case  we have replaced the patch file in our site.

All seems to be working correctly now.

the WHY2 support team

FYI ,  an easy way to get the file and how to install it for 1.3.4 is on our Patch files link
https://why2central.net/patch/abantecart-v1-3-4-default-weight-path-file/

Regards,
The WHY2 support team

Is seems either you are not selecting the correct place to turn off the requirement for phone number,  OR  you have altered something in your installation that is causing the issue.

Refer to the attached images for "proof"

Perhaps you have adjusted something,  but I just went to your site  and I see the continue button,   see my screen shot of a few moments ago.

Have you tried completing the areas that need to be selected?   The newsletter  yes/no,   and the reCaptcha? 
If you have and settings that require a checkmark like I have read the Privacy etc.  Those have to be selected.   As soon as ALL the requirements are met you will see the continue button.

Updating -  AbanteCart v 1.3.4  requires a min of PHP 8.0

As to updating your PHP version here is my take after 40+ years in computers,  the number one reason is security, number two is performance.

Take a peek at this versions supported PHP info
https://www.php.net/supported-versions.php

Since we provide managed services as well as hosting to our clients we firmly support using current support OS and PHP versions again based on security and performance.

Unfortunately for most things in computer world as well as other areas of life - change is the only absolute.  But it does keep things interesting. 

Most hosting providers now have multi PHP versions.   And they can be applied to different domains.  So if you have one domain where you can install AbanteCart 1.3.4  -  and select PHP 8.0 at the minimum that would leave your other sites running different PHP versions,    Just a thought.

Hello OneMore,  been seeing your posts for a few days now.  I would like to suggest that you are using quite an old version of AbanteCart -  1.2.11 was release in 2017.

The most recent version is 1.3.4 released in 2023  You can check this page for more info of versions https://www.abantecart.com/shopping-cart-news

Based on your suggestions quite a few if not all have been added to the more recent versions over time. It is easy to update your version BUT you should consider doing in the proper methods -  one version at a time.   Or you can install the latest version  and reimport your product and update whatever you think still needs modification for your needs.   

Cheers and joyful holiday season to you.

See here for some info:

https://www.abantecart.com/
https://managed.abantecart.com/custom-ecommerce.html

Hi Core Devs,

Requesting some info on your Version 2.   You started posting on this board Nov 2017.  Been several posts over the years for suggestions and inquiries as to when it was coming out.

Now we see there is a Version 2,  but only as a managed service from AbanteCart.  Is it your current decision to only offer this as a paid platform?   If so,  would have been great to know that previously.

It would be appreciated to have a post on this forum as to your future plans.

Regards,
Lee

Hey Nuno,
I made the post here as this is a bit of a different issue -  we adjusted the core coding for your site for the Moloni invoicing  to work correctly on the product page etc.   But thought Devs should be aware of this for all admins using incl tax in the pricing.  The have moved the checkout issue to github for a solution and that will be a good thing.

You are still wanting to "back into" a retail price by adjusting the incl tax to be rounded.  The issue then becomes how many decimals for the retail price,  how to handle the rounding for display on the product page,   and how to work with the number of decimals places the Invoicing company (Moloni)  uses in their reconstruct of the line items.  Moloni  uses 6 decimals,  and refigures the line items then rounds.   You can see how there are several places that are concerned in the decisions. 

Cheers all, welcome to the confusion of decimals and rounding
Lee

One thing that must be reconsidered in the include tax in the pricing  is how the product page calculates if the quantity is more than one and displays on the checkout page.  Currently the algorithm used in core code is simply to multiply  the price inc tax by the quantity.   But this introduces a rounding error of .01
And if there is more than one item ,  the difference can even be larger.

A demo product of Skinsheen  is  29.50 ,  tax is 8.5%
Price incl tax  is 32.01
Currently -  the product page and the checkout page  with show 96.03  for a qty or 3
32.01 X 3 = 96.03
But the correct amount is 96.02 for qty
(29.50 x 3) x 1.085 = 96.02
Refer to the screen shot for more information as pricing is displayed to customers at checkout -  it is confusing for customers.   And somewhat problematic when pushing info to an invoicing processor like Moloni for Portuguese clients, as it introduces the .01 difference ,  if the core coding wasn't re-written for the Moloni push (which is what we had to do for our Moloni extension)

Additionally,  in Nuno's desire to round to even numbers with the INCL tax pricing -  the base price needs to have more than 2 decimals  or the rounding can make the difference even larger.