Jump to content

Next release - 1.6.0.12


Recommended Posts

Hi everyone,

 

We're now entering a new cycle of release with the 1.6.0.12.

This version is another great technical release with +160 fixed bugs & improvements.

 

You can find the first package through the download link below. Please note that the release date is planned for early February.

 

https://dl.dropboxusercontent.com/u/12171118/prestashop_1.6.0.12.zip

 

You will find the changelog doc inside the package. We highly encourage you to explore this new version, try it and bring back your feedback, which is extremely valuable to us. Please do so through the PrestaShop 1.6 Project on the Forge.

 

Thank you!

  • Like 2
Link to comment
Share on other sites

@McRoy: I read the post. The line you quoted is just an announcement of the next version. I meant an overview of the next versions with features which will be addressed. Somethink like this http://typo3.org/typo3-cms/roadmap/. And I am also interested in the release cycle, like is there one release every 6 month or after some milestones.

Edited by Konafets (see edit history)
  • Like 1
Link to comment
Share on other sites

Is there a roadmap for the upcoming versions? How is your release cycle?

 

If you can have an answer about this kind of things.. I'll be also very happy !

 

if the release could also fit the standards releasing sytem used by all other software makers... it would be almost like Xmas again :)

Link to comment
Share on other sites

If you can have an answer about this kind of things.. I'll be also very happy !

 

if the release could also fit the standards releasing sytem used by all other software makers... it would be almost like Xmas again :)

 

I speak about release cycle often but, so far unheard  :( I know that they aim for release every month, but it is ridiculous cycle in my opinion.

Link to comment
Share on other sites

case A/

Let's create a product.

Retail price with tax 4.95

Tax rate 20%

Avail. qty 500

 

Add it to your cart

 

Spot that the cart displays a total amount of 4.96!
proceed to checkout (free carrier) + check

 

Spot that the collected amount is 4.96 while the total product is 4.95
 

case B/

Let's create a product.

Retail price with tax 4.95

Tax rate 20%

Avail. qty 500

Add it to your cart

 

Let's create a product.

Retail price with tax 85.95

Tax rate 20%

Avail. qty 500

 

Add it to your cart

 

proceed to checkout (free carrier) + check

mark the order as paid

Open the invoice

Spot the VAT amount does not match in the two location it is displayed
Proceed to partial refund

 

Spot that every quantity field are prepopulated with 1
 - while 0 is more what business would have expected
Select to return 1x 85.95 only

Tick Restock

Tick Generate a voucher

Spot the amount of 85.95 the default!
Spot the proposed amount of 76.86 - weirdo (85.95 - 9.09)
Compute yourself the amount and conclude it should have been 77.35
 (81.81 - (4.95 - 10%)) - 1cts discrepency is expected here
Enter 77.35 in the voucher amount

Spot the radio box does not follow your choice
Tick the custom amount radio!

Press partial refund

Error - The following e-mail template is missing: /home/doekia/Projects/ps_nightly/1.6.x/mails/fr/voucher.txt
Ignore and return to the page

Open the credit slip

Don't even try to understand the math here! conclude that -77.35 gives -64.46 tax free -12.89 VAT
Return to the order and do yet another partial refund

Tick restock

Tick create voucher

Spot the Error. You cannot refund a negative amount.
Enter 4.46 in custom value

Tick the radio!

Press partial refund

Ignore the blank page

Return to the order page

Spot that the order summary displays still a product total, discount amount, total
Go to the dashboard

Spot the net profit 
Link to comment
Share on other sites

Hi Doekia,

 

Problem 1/ is indeed a rounding issue, well, kind of.

 

It arises because the cart computes separately the tax base and the tax then sums them :

 

round(4.125, 2) + round(4.125*20/100, 2) = round(4.125, 2) + round(0.825, 2) = 4.13 + 0.83 = 4.96

 

On the other hand, the product sheet computes :

 

round(4.125*120/100, 2) = 4.95.

 

So this is rounding related.

 

I'm working on the issue on this repository: https://github.com/djfm/PrestaShop/tree/taxes-patch, you're welcome to check it out and comment, keeping in mind that it is at this point still a work in progress, because changing the way the cart computes totals has a lot of consequences. Please feel free to contact me in private if you want to discuss the issue further!

 

And slight correction to Xavier's post, I'm not the one working on issue 2/ :)

Link to comment
Share on other sites

Yes and no:

OrderSlip is not a rounding issue
The different error faced are not rounding issues
The way doing thing in total contradiction with business use is not a rounding issue
Is this thread the prerelease community evaluation ?

 

Regarding rounding, rounding should be done in the proper place - it is time to stop fixing things the way they've been done for 7 years.

It been a mistake for ages by Prestashop to consider both problems separated. Rounding should occur only on specific place - close to the final totals - rarely on it btw

There is only a single way to compute amount on cart/invoice/order/orderslip - the right one - sorry to say that but it is time to accept it been done wrong

Feel free to download/comment the following tip sheet document that explains it:
https://drive.google.com/open?id=0B6wR-mUsKrvRWmlrdE9UR0NJb2M&authuser=0

Red cells are rounded. Those are the only place to round and it ensure order/orderslip are correct all the way thru.

  • Like 1
Link to comment
Share on other sites

Hi,

 

We run a PS 1.4 and we are planning to upgrade to 1.6. So we evaluated the version 1.6.9 and (again) we saw this VAT rounding issue. I just admit that we were very surprised to see this issue again (and again) and I just cannot understand how Prestashop can release a production version with this kind of issue. It's just unacceptable for real professionals. Futhermore, it seems that no sales professional (I mean other than developers) is consulted, because some functions (after sales service) prestashop are not at all adapted to the online sale of business processes.

 

So now, we are looking another platform and we evaluate the cost to change Prestashop (unless a significant effort is made in the next release).

 

Best Regards,

 

Vincent

Edited by NOVIYA (see edit history)
  • Like 1
Link to comment
Share on other sites

doekia is right.

problem is rounding are calculated on many places during order process.

This method should be totally reworked with the intention of simplification.

rounding must be calculated at the totally end of the process, I think.

Link to comment
Share on other sites

doekia is right.

problem is rounding are calculated on many places during order process.

This method should be totally reworked with the intention of simplification.

rounding must be calculated at the totally end of the process, I think.

 

This should be fixed indeed, but in major releases not in minor like 1.6.0.12. 

Link to comment
Share on other sites

This should be fixed indeed, but in major releases not in minor like 1.6.0.12. 

 

If so then stop using/distributing/advertising Prestashop. It is illegal to emit a wrong invoice here in France and presumably in any country all arround the world.

 

And for the record there have been several major release since this issue was first mentionned - up to 2009

So

1.2 did not fixed it

1.3 did not fixed it

1.4 did not fixed it

1.5 did not fixed it

1.6 did not fixed it

Edited by doekia (see edit history)
Link to comment
Share on other sites

The problem will never be solved as long as you will not have understood that the sum of the roundings is not equal to the rounding of the sum.

Then, the calculation of the VAT must be made only lastly whith the same method for all process.

  • Like 1
Link to comment
Share on other sites

Well that's what i said, it should be fixed in 1.5.x or 1.6.x when they arrive as major releases or now when 1.7 comes. You can't just change core in the middle of minor releases, simply because you will loose backward compatibility. How will you feel if your windows 7 or windows 8, release an update and suddenly you can't use any of your old programs? See, you can't just change such things without consequences, but it should be fixed indeed.

Link to comment
Share on other sites

The problem will never be solved as long as you will not have understood that the sum of the roundings is not equal to the rounding of the sum.

Then, the calculation of the VAT must be made only lastly whith the same method for all process.

 

I have submitted a document that explains where and when to round and how to calculate OrderSlip on any scenario

https://drive.google.com/open?id=0B6wR-mUsKrvRWmlrdE9UR0NJb2M&authuser=0

 

0/ Basically you round tax excluded price at display per line

1/You compute and round the sum of VAT per VAT type on order

2/You sum the previous all together to get the global VAT amount

3/You sum and round tax excluded price x qty on the order

4/You add the 2 previous which gives a gross total

5/ You compute and round discounts (%) on the gross total

6/ You sum the monetary discounts

7/ You sum the values of discounts (monetary+computed%) to get discount total

8/ You substract gross total with discount total to get real total to be payed

 

On order slip just use the initial product price, do the math the same up to discount

5/ using the initial total discount / real payed total to have a ratio recalculate this discount on this order slip gross total, round it

6/ does not exists on order slip the previous implies it

All the other maths are the same

Obviously the result is an amount to return, or so to speak all number are negated

 

This method give ALWAYS the good result.

Edited by doekia (see edit history)
  • Like 1
Link to comment
Share on other sites

Some of you think it is just a cent difference, acceptable so to speak - this is not

 

Look at this:

Product / Reference | Qty  | Price       | Price
                    |      |(Tax Excl.)  | (Tax Incl.)
--------------------+------+-------------+------------
P8595     -         |    1 |   -71,63 €  |   - 85,95 €
--------------------+------+-------------+------------
                                Shipping |   -  0,00 €
               Product Total (Tax Excl.) |   - 71,63 €
               Product Total (Tax Incl.) |   - 85,95 €
                               Total Tax |   - 14,33 €
                                   Total |   - 77,35 €  8.60€ math error here
                                                        but this amount is exact!

                                                        It is the amount
                                                        we returned to the client


Tax Detail | Tax Rate | Total Tax Excl | Total Tax
-----------+----------+----------------+------------
Products   | 20.000 % |      - 71,63 € | - 14,33 €

Link to comment
Share on other sites

Well that's what i said, it should be fixed in 1.5.x or 1.6.x when they arrive as major releases or now when 1.7 comes. You can't just change core in the middle of minor releases, simply because you will loose backward compatibility. How will you feel if your windows 7 or windows 8, release an update and suddenly you can't use any of your old programs? See, you can't just change such things without consequences, but it should be fixed indeed.

https://www.prestashop.com/forums/topic/353653-corrections-taxes-et-arrondis-besoin-de-testeurs/

 

In plain english it says the 1.6.0.10 fixes all rounding issues we need you to test

  • Like 1
Link to comment
Share on other sites

Some of you think it is just a cent difference, acceptable so to speak - this is not

 

Look at this:

Product / Reference | Qty  | Price       | Price

                    |      |(Tax Excl.)  | (Tax Incl.)

--------------------+------+-------------+------------

P8595     -         |    1 |   -71,63 €  |   - 85,95 €

--------------------+------+-------------+------------

                                Shipping |   -  0,00 €

               Product Total (Tax Excl.) |   - 71,63 €

               Product Total (Tax Incl.) |   - 85,95 €

                               Total Tax |   - 14,33 €

                                   Total |   - 77,35 €  8.60€ math error here

                                                        but this amount is exact!

                                                        It is the amount

                                                        we returned to the client

 

Tax Detail | Tax Rate | Total Tax Excl | Total Tax

-----------+----------+----------------+------------

Products   | 20.000 % |      - 71,63 € | - 14,33 €

 

 

I didn't realize the problem is so big, the math is very wrong here. You can't add 100 + 20% and then 100 - 20% this will never give the same result. The correct math should be 100 x 1.2 and then 100 / 1.2 or 100 / 6

Link to comment
Share on other sites

Hi!

 

Yes one can otherwise ask why they should release a new version if they have not fixed it, which is a must in prioritizing example, advanced inventory management and more.

 
I am happy and grateful that we have access to a place like this wonderful team of PrestaShop who help us and fix it for us.
 
But one important thing that I personally think is that you can not just report it to the forum, but send in your reports to Github so they really get out what should be fixed.
 
Best regards
MacRoy
  • Like 1
Link to comment
Share on other sites

But one important thing that I personally think is that you can not just report it to the forum, but send in your reports to Github so they really get out what should be fixed.

A pretty valid argument but, the problem got numerous bug reports on the forge for ages.

It persists as if module onboarding or other been more important. It is there since the inception.

 

Actually it was finaly promised in 1.6.0.10, then .11, then .12 and now we enter the probable .13 (I fear that withou some pressure 1.7 will be having this "illegal" invoices.

 

From 2009 till now 7 years and no fix ... it is not as if we were planning a lunar mission it is the basic of accounting. It is almost pure arithmetic that a 5th grade can follow.

 

So please join me pushing this so they understand it has to be top priority amongst the top priorities. We are talking the very essence of the solution here selling product !

Edited by doekia (see edit history)
  • Like 4
Link to comment
Share on other sites

Hi!

 

Why not put up a vote Braking System so that all of us on this wonderful forum can vote for them, say, five (5) most important things that need to be addressed ASAP.

 
So that each one of us just tick those things that we think should be corrected ASAP.
 
Just a suggestion.
 
Best regards
MacRoy
  • Like 3
Link to comment
Share on other sites

 

Hi!

 

Why not put up a vote Braking System so that all of us on this wonderful forum can vote for them, say, five (5) most important things that need to be addressed ASAP.

 
So that each one of us just tick those things that we think should be corrected ASAP.
 
Just a suggestion.
 
Best regards
MacRoy

 

 

I like this. 

Link to comment
Share on other sites

 

Hi!

 

Why not put up a vote Braking System so that all of us on this wonderful forum can vote for them, say, five (5) most important things that need to be addressed ASAP.

 
So that each one of us just tick those things that we think should be corrected ASAP.
 
Just a suggestion.
 
Best regards
MacRoy

 

 

Uh, the same questionnaire was held for 1.5 and left to oblivion ...

  • Like 2
Link to comment
Share on other sites

Uh, the same questionnaire was held for 1.5 and left to oblivion ...

 

The same is true for the release cycle intervals, there was a vote poll, and then it was completely ignored. The developer team is doing amazing job in my opinion, however i fear the management who gives them priorities need to listen to us.

  • Like 1
Link to comment
Share on other sites

Let me try to synthetize the nexus of this issue

 

I can easily write a getInvoiceOrderCartTotal() method. The problem is that for it to be operative it need to be glued almost anywere.

Including portions of code that are in commit/update at this very moment.

 

Only the team can decide to make a freeze on other changes, and proceed this one in a proper way.

 

Calls to Cart should be reviewed, and fixed

Calls to Order

Calls to CartRule for voucher creation

AdminOrderController to be reviewed

 

etc etc

 

Any other way of looking at the problem will lead the exact same issues or even worst!

Personnaly I cannot think of anything worst since in this stage the code is just dead beef ...

Edited by doekia (see edit history)
Link to comment
Share on other sites

Bonjour,

 

Je tombe sur ce topic qui tombe à pic si j'ose dire puisque j'ai justement soulevé ce problème sur mes factures ici et j'attends toujours des réponses :

 

https://www.prestashop.com/forums/topic/396597-bug-factures-fausses/

 

TVA fausse.

 

Frais de port gratuit sur lequel on applique de la TVA.

 

Je dis quoi à mes clients?

Je dis quoi en cas de contrôle de la TVA au contrôleur qui est susceptible de délivrer une amende de 15€ par facture fausse : http://bofip.impots.gouv.fr/bofip/724-PGP.html

 

Que compte faire l'équipe Prestashop pour régler ces problèmes qui sont quand même extrêmement risqués pour une entreprise française?

 

Merci d'avance.

 

Romain 

Link to comment
Share on other sites

Some of you think it is just a cent difference, acceptable so to speak - this is not

 

Look at this:

Product / Reference | Qty  | Price       | Price

                    |      |(Tax Excl.)  | (Tax Incl.)

--------------------+------+-------------+------------

P8595     -         |    1 |   -71,63 €  |   - 85,95 €

--------------------+------+-------------+------------

                                Shipping |   -  0,00 €

               Product Total (Tax Excl.) |   - 71,63 €

               Product Total (Tax Incl.) |   - 85,95 €

                               Total Tax |   - 14,33 €

                                   Total |   - 77,35 €  8.60€ math error here

                                                        but this amount is exact!

                                                        It is the amount

                                                        we returned to the client

 

Tax Detail | Tax Rate | Total Tax Excl | Total Tax

-----------+----------+----------------+------------

Products   | 20.000 % |      - 71,63 € | - 14,33 €

 

 

Hi doekia,
 
Can you please explain how you get the 77.35 total to pay?
 
I have a feeling it might be a template issue (are you using the default one?), because here is how it looks like on my PrestaShop 1.6.0.11 :
 
post-343766-0-73597900-1422454548_thumb.png
 
 
 
Yes, there is a 1 cent error, and we're on it. But where is the 8.6€ error you report here?
 
Here is the corresponding invoice, (still 1.6.0.11, with the 1 cent error that we're working on):
 
post-343766-0-40980000-1422454567_thumb.png
 
 
 
And here is what it will look like after the next tax iteration (can you see anything wrong ?) :
 
post-343766-0-82364200-1422454604_thumb.png
 
 
 
The rounding errors that you see today should never exceed 1 cent per tax rate. They are only due to the fact that tax bases are rounded before the rounded VAT is added.
 
If you have 2 different tax rates in your cart you might have a 2 cent error, but no more. By default, in 1.6.0.11, rounding is done at the latest possible time.

post-343766-0-94943300-1422454497_thumb.png

Link to comment
Share on other sites

Can you please explain how you get the 77.35 total to pay?

It is simply the order slip converted to text from the test recipe on entry #10 of this topic

 

I have a feeling it might be a template issue (are you using the default one?), because here is how it looks like on my PrestaShop 1.6.0.11 :

Pristine .12 install from the download link on entry #1

 

If you have 2 different tax rates in your cart you might have a 2 cent error, but no more. By default, in 1.6.0.11, rounding is done at the latest possible time.

Did you read my mail response?

Link to comment
Share on other sites

Hello guys, after upgrading to 1.6.0.12 all of my images became unavalible. I found the problem. For some reason there are being added those characters "g8UGRbzOLR" in every url to picture. Like this

 

http://lolko-shop.cz/642-large_default-g8UGRbzOLR/league-of-legends-lol-naramek-jungle-fialovy.jpg

and should be this:

http://lolko-shop.cz/642-large_default/league-of-legends-lol-naramek-jungle-fialovy.jpg

 

I have no idea how to fix this.

Edited by sooly (see edit history)
  • Like 1
Link to comment
Share on other sites

Hi everyone,

 

We're now entering a new cycle of release with the 1.6.0.12.

This version is another great technical release with +160 fixed bugs & improvements.

 

You can find the first package through the download link below. Please note that the release date is planned for early February.

 

https://dl.dropboxusercontent.com/u/12171118/prestashop_1.6.0.12.zip

 

You will find the changelog doc inside the package. We highly encourage you to explore this new version, try it and bring back your feedback, which is extremely valuable to us. Please do so through the PrestaShop 1.6 Project on the Forge.

 

Thank you!

Hi!

 

When are you releasing next?

 

Regards

MacRoy

Link to comment
Share on other sites

my crystal ball tells me that After 1.6.0.12 will be tested and modified it will be out in february and named : 1.6.0.12, AMAZING PRESTASHOP :P

Hi!

 

I ask for the beta version!

 

I know they release it at the beginning of February.
 
Regards
MacRoy
Link to comment
Share on other sites

 

Hi doekia,
 
Can you please explain how you get the 77.35 total to pay?
 
I have a feeling it might be a template issue (are you using the default one?), because here is how it looks like on my PrestaShop 1.6.0.11 :
 
 
 
 
Yes, there is a 1 cent error, and we're on it. But where is the 8.6€ error you report here?
 
Here is the corresponding invoice, (still 1.6.0.11, with the 1 cent error that we're working on):
 
 
 
 
And here is what it will look like after the next tax iteration (can you see anything wrong ?) :
 
 
 
 
The rounding errors that you see today should never exceed 1 cent per tax rate. They are only due to the fact that tax bases are rounded before the rounded VAT is added.
 
If you have 2 different tax rates in your cart you might have a 2 cent error, but no more. By default, in 1.6.0.11, rounding is done at the latest possible time.

 

multiple sources of errors do exist, the least one being the 1 eurocent round mistake

check that one out ! some of my invoices are correct though : it seems systematic audit of the situation should be engaged, it is a real 1st level priority now

post-483133-0-01030100-1422391774_thumb.jpg
  • Like 1
Link to comment
Share on other sites

 

Hi!

 

I ask for the beta version!

 

I know they release it at the beginning of February.
 
Regards
MacRoy

 

 You dare ask for beta version... let me put it again for you : Prestashop never release BETA versions, only stables versions, the old one was 1.6.0.11, modified several times, the current one in test is 1.6.0.12 and will be release after modifications with the label : 1.6.0.12  very soon, that's magic isn't it ?

 

For Xavier : last time I gave you wiki link for release system, now please have a look at this site : http://semver.org/

And I am sure you'll understand what I am trying to tell, for start 1.6.0.x is out the rules, it should be only X.Y.Z, that means only 2 dots, never 3 !

 

quote : "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.".. oops :)

 

Best Regards :)

Link to comment
Share on other sites

.... for release system, now please have a look at this site : http://semver.org/

I do agree the current versioning (version tagging) is bad and lead to confusion, not only on end-user/community side, but also with the addons auto pull system.

 

To be honest, the semantic versionning, should it been applied to PS will mean version 7.x.y today due the nature of the community project.

 

4 numbers is not an issue per se.

No Alpha, Beta, RCx tainting is one.

Number not changing (I join you here) for totally different code is major hassle.

Edited by doekia (see edit history)
Link to comment
Share on other sites

+1 for going to use semantic versioning. Additionally you should consider to setup a quality management of the codebase. I found some Unit Tests but didn't get them to work due missing namespaces. (Maybe somebody can give me a hint how to make them work). But they are not executed after every commit/merge, so they are not taken into account for new releases.

Link to comment
Share on other sites

 You dare ask for beta version... let me put it again for you : Prestashop never release BETA versions, only stables versions, the old one was 1.6.0.11, modified several times, the current one in test is 1.6.0.12 and will be release after modifications with the label : 1.6.0.12  very soon, that's magic isn't it ?

 

For Xavier : last time I gave you wiki link for release system, now please have a look at this site : http://semver.org/

And I am sure you'll understand what I am trying to tell, for start 1.6.0.x is out the rules, it should be only X.Y.Z, that means only 2 dots, never 3 !

 

quote : "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.".. oops :)

 

Best Regards :)

Hi!

 

You should probably make sure to read on!

 
Start by reading the headline that PrestaShop own making.
 
See attached picture.
 
Regards
MacRoy

post-413956-0-79024600-1422709787_thumb.jpg

Link to comment
Share on other sites

 

Hi!

 

You should probably make sure to read on!

 
Start by reading the headline that PrestaShop own making.
 
See attached picture.
 
Regards
MacRoy

 

 

Thank you so much for that screen shot.. so Now I GOT the Point, "beta" is written in the forum section.. We are all saved now, it looks like everything is good and on correct track now...  :P

 

by the way.. 1.6.0.7..etc are also beta then ?? so 1.6.0.11 is beta version too... where are the STABLE releases then ?

Link to comment
Share on other sites

+1 for going to use semantic versioning. Additionally you should consider to setup a quality management of the codebase. I found some Unit Tests but didn't get them to work due missing namespaces. (Maybe somebody can give me a hint how to make them work). But they are not executed after every commit/merge, so they are not taken into account for new releases.

 

 

humm "Unit Tests", that is also something !

 

I am sure that the Prestashop team will explain their own protocol very soon !

Link to comment
Share on other sites

Thank you so much for that screen shot.. so Now I GOT the Point, "beta" is written in the forum section.. We are all saved now, it looks like everything is good and on correct track now...  :P

 

by the way.. 1.6.0.7..etc are also beta then ?? so 1.6.0.11 is beta version too... where are the STABLE releases then ?

 

+1

Link to comment
Share on other sites

Downloaded the github version of PS aprx 1 hour ago (16.00) and installed it. When going to products (and then"Edit") it takes insanely long time before saving changes is possible. The prestahand at the left top corner and the "Save and stay" & "Save" buttons at the bottom right spins for about 25 seconds before they're ready. This happens in both Chrome (Version 40.0.2214.94, 64-bit) and FF (35.0) Currently running OpenSuse 13.2. No modificaions is done to any ps files on the server. Server is running PHP 5.6. Any idea what's causing this?

 

Regards

Link to comment
Share on other sites

Downloaded the github version of PS aprx 1 hour ago (16.00) and installed it. When going to products (and then"Edit") it takes insanely long time before saving changes is possible. The prestahand at the left top corner and the "Save and stay" & "Save" buttons at the bottom right spins for about 25 seconds before they're ready. This happens in both Chrome (Version 40.0.2214.94, 64-bit) and FF (35.0) Currently running OpenSuse 13.2. No modificaions is done to any ps files on the server. Server is running PHP 5.6. Any idea what's causing this?

 

Regards

The guilty is the new admin-products.js, it's a new feature :)

Link to comment
Share on other sites

It is not a solution, but an analysis of the problem.

Nemops gives actually, the good approach to be had.

 

But the problem should be rethought.

Only the 1st tab should be loaded with the global menu.

The call to the ajax function should be made only during the click on one of the elements of the menu.

Because, at this moment, all the page is loaded. And if you click "Save and stay ", all the page is reloaded!

  • Like 1
Link to comment
Share on other sites

I would like to add my dime on the issue of rounding.

 

Perhaps, it's right time to remember so named "BANKER'S ROUNDING"? It wouldn't decide the problem completely, but banking automation area facing rounding issues every day, which are especially acute because of sufficient cash flow.

Edited by DaoKakao (see edit history)
Link to comment
Share on other sites

I would like to add my dime on the issue of rounding.

 

Sorry to say so but everytime some claims the issue is related to rounding, it may only come from someone not understanding neither the issue, neither how to calculate an invoice, nor having take any time within the code chasing it (I'm not pointing at you here)

 

Banking rounding, you are right may solves issues but not in this area.

 

Let's look at the invoice I posted previously. 2 line of product, 50.01€ error and a line of VAT exhibiting 45.86+2.50 = 20 !!

That is not a rounding issue, or a pretty big one ;-) or the math I've learned were pretty bad.

Link to comment
Share on other sites

Sorry to say so but everytime some claims the issue is related to rounding, it may only come from someone not understanding neither the issue, neither how to calculate an invoice, nor having take any time within the code chasing it (I'm not pointing at you here)

 

Banking rounding, you are right may solves issues but not in this area.

 

Let's look at the invoice I posted previously. 2 line of product, 50.01€ error and a line of VAT exhibiting 45.86+2.50 = 20 !!

That is not a rounding issue, or a pretty big one ;-) or the math I've learned were pretty bad.

 

I meant to point that the problem (as it seems to me) slightly deeper, than simple correct order slip generation. It also (as i think) important, that total turnover of store (registered in PrestaShop) should match with the bank account turnover (registered in bank) as well as with any bookkeeping automation system (in order to provide annual balance sheet report, for instance).

 

In this case we've got not only need of simple rounding, but also need to voluntary/manual fit of debit and credit in a balance sheet

 

Another words, it's not just math task and it depends on country-specific bookkeeping rules as well.

 

And yes, I didn't saw the source code before writing my posts, sorry ;) Promise to try to fix that my issue soon :)

Edited by DaoKakao (see edit history)
  • Like 2
Link to comment
Share on other sites

were seen significant slowdown

 

when using

 

1. The standard top menu (with many tabs)

2. When the site is well done (with the attributes, features, discounts, reviews)

 

grows much response from the site.

I have 500 pages on the site - and what will happen if even make multi. Version with 1,4.11 faster to deal with it

 

Make caching in html. for example when loading a page - it is created on the basis of statischesky file with all fields. Which changes only if there was a change in the dynamic.

Edited by NIKS (see edit history)
Link to comment
Share on other sites

I meant to point that the problem (as it seems to me) slightly deeper, than simple correct order slip generation. It also (as i think) important, that total turnover of store (registered in PrestaShop) should match with the bank account turnover (registered in bank) as well as with any bookkeeping automation system (in order to provide annual balance sheet report, for instance).

 

In this case we've got not only need of simple rounding, but also need to voluntary/manual fit of debit and credit in a balance sheet

 

Another words, it's not just math task and it depends on country-specific bookkeeping rules as well.

 

And yes, I didn't saw the source code before writing my posts, sorry ;) Promise to try to fix that my issue soon :)

 

Was not my intent that you take my remark for you B) , more about some member that dismiss the issue behind the rounding smoke!

 

You point is valid, and Bank rounding is already possible by changing the setting for it to be use by Prestashop.

Assuming the other math are correct, we are all set.

 

 

Country specific is not that of a deal:

  • 1+1=2 in any country I know
  • VAT/GST are VAT all around the globe by mean that, point of sale collects tax for the state/country and should return that money to it. The calculus here have to be right to the cent, no country/state will ever accept discrepancy in the calculation.
  • And unless I'm wrong, everywhere customer should only pay for the price displayed.

 

Country specific are more related to the way of displaying compulsory information on the invoices.  That is where some "per country templates" may help, but totally irrelevant when calculation get screwed.

 

AFAIK, the only case that could be country specific is on green tax, in France and most of EU, green tax is not really a tax. It is part of the non taxed price. It is an information carried on by the product that should be reflected on the invoice as is. It has been paid by the manufacturer. There could be a chain of brokers/resaler the information stays unchanged. If at the factory the product got 1$ of the so called eco-tax it still be 1$ of eco-tax even if you multiply the price of the product ten times ... even more if you resale without tax the eco-tax summary should be printed on the invoice (1$ in our case here).

Multiple additive tax like Danemark or US splittable regional tax is also country specific, but since PS does not allow piling/splitting tax it could be put out of the equation at the moment.

 

And last but not least the calculation and result are wrong all the way long, cart,order,invoice,credit slip, refund, ...

Link to comment
Share on other sites

multiple sources of errors do exist, the least one being the 1 eurocent round mistake

check that one out ! some of my invoices are correct though : it seems systematic audit of the situation should be engaged, it is a real 1st level priority now

 

I love this example:

35.00 tax included at 5.5% VAT means really 33.17535545 tax excluded, correctly displayed  33.18.

33.17535545 x 4 = 132.701421801 displayed wrongly 132.72

132.701421801 * 0.055 = 7.298578199 not 7.28 not even 6.92

assuming 132.72, 132.72 * 0.055 = 7.2996

assuming 35 * 4 = 140, 140 / 1.055 = 132.701421801, and 140 - 132.701421801 = 7.298578199

assuming 35 - 33.18 = 1.82 and 1.82 * 4 = 7.28 at least this one sound good but we have stolen 2 cents to the state ...

assuming 33.18, 33.18 * 0.055 = 1.8249 yes so close be almost an extra 1/2 cent par product

assuming 35 - 33.17535545 = 1.82464455 again pretty to the half cent

 

The correct method is for tax and VAT: 33.17535545 * 4 = 132.701421801, rounded 132.70 then 132.701421801 * 0.055 = 7.298578199 rounded 7.30

The correct method for tax included total is: 33.17535545 * 0.055 * 4 = 139.999999999 rounded 140

Some times the total price without tax + the total vat is 1cent over but you absorb this (partial) cent in your margin. The tax amount is fine and the customer price is fine, you just committed a 0.5 cent < extra fuzzy voucher < 1 cent on this. 

If you keep track of the entire calculation over a year with 6 decimals and compare, you will barely get 1€ difference from what you've given compared to what you'd give.

  • Like 2
Link to comment
Share on other sites

Hi everyone,

 

We're now entering a new cycle of release with the 1.6.0.12.

This version is another great technical release with +160 fixed bugs & improvements.

 

You can find the first package through the download link below. Please note that the release date is planned for early February.

 

https://dl.dropboxusercontent.com/u/12171118/prestashop_1.6.0.12.zip

 

You will find the changelog doc inside the package. We highly encourage you to explore this new version, try it and bring back your feedback, which is extremely valuable to us. Please do so through the PrestaShop 1.6 Project on the Forge.

 

Thank you!

 

Hi!

 

There seems to be standard now more to the PrestaShop not answer questions or even reading what's on this board!
 
You would like to have reports of PrestaShop 1.6.0.12, but you do not care to even respond to questions asked or put up the next beta release. Sure, you say of course that it released the full version in early February, but it sure would be better if you posted a final beta before relese?!?! ...
 
You can not expect that testers should take this seriously, if you yourself do not do it!
 
Sharpening!
 
Best regards
MacRoy
Edited by MacRoy (see edit history)
  • Like 1
Link to comment
Share on other sites

Guys, no use whining in this thread about lack of feedback. The Prestashop developers aren't reading this anyway.

 

Quoting from Xavier's message that started this thread:

"We highly encourage you to explore this new version, try it and bring back your feedback, which is extremely valuable to us. Please do so through the PrestaShop 1.6 Project on the Forge"

 

So use the forge for reporting errors. That's where the Prestashop developers hang out, not here.

Link to comment
Share on other sites

May I ask who you are referring to in your statement?

 
Here we complain not, but we only give our opinions on what would be better or maybe worse! But it can not seem make sense at expressing their opinions, because it seems anyway not be someone who cares.
 
Reporting, we have always left to the Forge!
 
 
Regards
MacRoy
  • Like 1
Link to comment
Share on other sites

Hi everyone!

 

This is the package we want to release today: https://www.dropbox.com/s/llbmscipc3klhvj/prestashop_1.6.0.12.zip?dl=0

 

You're welcome to do a quick install test, check if you see anything critical before we make it officially available. Anything non critical or not related to the install or update is off topic for today, please ;)

 

Cheers!

  • Like 3
Link to comment
Share on other sites

This is the package we want to release today: https://www.dropbox.com/s/llbmscipc3klhvj/prestashop_1.6.0.12.zip?dl=0

That is pretty scary

 

The release number has changed 5 days ago in the GitHub so what is this version ? I runned daily test on the yesterday github version and still zillions of issues on pricing!

Adding yet another mess on the pile of bug deserves no purpose but yet again loosing creditibility.

 

That is a show stopper to me!

Link to comment
Share on other sites

Hi everyone!

 

This is the package we want to release today: https://www.dropbox.com/s/llbmscipc3klhvj/prestashop_1.6.0.12.zip?dl=0

 

You're welcome to do a quick install test, check if you see anything critical before we make it officially available. Anything non critical or not related to the install or update is off topic for today, please ;)

 

Cheers!

 

 

Brand new install 1.6.0.11.

Install module 1 click upgrade

Page adminselfupgrade cannot be found..

 

Pristine install from the dropbox archive.

Similar translation bug as with 1.6.0.11 (PEAR pull request https://github.com/PrestaShop/PrestaShop/commit/25cf853f9e32439cadb7c75a4544cd16738bc0ba)

Blank field translation everywhere

Nope my bad, only not a single french translation

 

Tried install 1 click upgrade module 1.4.7 - bump too

Page adminselfupgrade cannot be found..

 

Product 4.95 tax inc. (VAT 20%) still cart/order = 4.96 still illegal in most - if not all - country arround the world!

 

Partial refund = Error - The following e-mail template is missing: /home/doekia/Projects/ps_nightly/1.6.x/mails/fr/voucher.txt

 

Order (price tax included, @ is vat rate)

1x4.95@20% + [email protected]% + 2x 85.95@20% + free shipping 6@20%

Partial refund 1x85.95, create voucher + restock

=> Order split = - 71,63 € while proposed and accepted amount was 85.95 !!

 

Anything non critical or not related to the install or update is off topic for today

What is critical upon your standards? As regarding install let say it went all green smileys - since most of the version

Edited by doekia (see edit history)
Link to comment
Share on other sites

Hi everyone!

 

This is the package we want to release today: https://www.dropbox.com/s/llbmscipc3klhvj/prestashop_1.6.0.12.zip?dl=0

 

You're welcome to do a quick install test, check if you see anything critical before we make it officially available. Anything non critical or not related to the install or update is off topic for today, please ;)

 

Cheers!

 

Hi Xavier!

 

I found this.

 

If I turn on the Enable productImage on Invoice, I get the following error message:

TCPDF ERROR: [image] Unable to get image: /img/tmp/product_mini_4_16.jpg
This I have also reported before, but is still not resolved!
 
Best regards
MacRoy
Link to comment
Share on other sites