Describe the bug
Different data in 'ps_currency' table when upgrading to PS 1.7.6.
precision
name
is not setnumeric_iso_code
is not setTo Reproduce
Steps to reproduce the behavior:
Scenary 1
ps_currency
Scenary 2
ps_currency
Hi @idnovate,
Thanks for your report.
I have the same issue with the ps_currency
table.
Fresh installation PS1.7.6.0
We have different numeric_iso_code
, precision
.
In the PS1.7.5.2, table ps_currency is different
Ping @PrestaShop/prestashop-core-developers what do you think?
Thanks!
Hi, reproduced the bug when passing from 1.7.5.1 to 1.7.6.0.
This is breaking the Paybox/e-transactions payment module which uses the numeric iso code.
Hi, reproduced the bug when passing from 1.7.5.1 to 1.7.6.0.
This is breaking the Paybox/e-transactions payment module which uses the numeric iso code.
And many others payment modules :worried:
Hello! I have had the exact same issue after upgrading from 1.7.5.2 to 1.7.6.0. In fact, we use a module developed by @idnovate and now orders do not update their status. Is there any solution at least by updating the field values numeric_iso_code to 978 and precision to 2 instead of 0 and 6 respectively? Thanks
@demperador Which module?
@idnovate
@demperador Which module?
Pago con tarjeta Redsys
v3.6.8 - de idnovate
When a payment is made, Redsys accepts the payment but I receive the following error: Error (-1 Server returned HTTP response code: 500 for URL: http://centrobell.com/index.php?fc=module&module=redsys&controller=ipn).
@demperador Please contact us at https://addons.prestashop.com/es/contacte-con-nosotros?id_product=6492 to fix the problem meanwhile
Hi, reproduced the bug when passing from 1.7.5.1 to 1.7.6.0.
This is breaking the Paybox/e-transactions payment module which uses the numeric iso code.And many others payment modules 馃槦
After correction of the table ps_currency the data is well transmitted to the bank (module E-transaction) but the return of the bank accepted or not is not taken into account by PrestaShop after the update of 1.7.5.2 -> 1.7 .6.0
LOG :
I had the same problem with two migrations from 1.7.5.2 to 1.7.6.0.
I think this is not related. Have you tried in a fresh PS 1.7.6.0 without the currency problem? Probably it will happen the same ;)
No I did not, my current concern is that our customers can order and pay for their purchases on the shop of prod ..
Hi,
We are currently investigating an issue during order validation, which seems to be your problem (Prestashop's order validation is triggered by our plugins when Instant Payment Notification is received).
somehow i believe it is related to the currency issue, probably a bug in prestashop. for information, reverting to 1.7.5 seems to correct the problem.
regards,
Paybox by Verifone
Test it in a fresh PS 1.7.6.0 where the current currency bug is not present. It should appear the same error.
374/5000
So as you ask I made a new installation of Prestashop 1.7.6.0 download to do this and we have exactly the same problem validation by the bank is OK but the Prestashop page displays "waiting for validation" it turns about 10 loops and there is no payment validation in Prestashop 1.7.6.0 administration orders
@flyman30, so after fresh installation PS.1.7.6.0, you create a new order => proceeded to checkout with the bank payment => in the BO => Order details page => there is no status displayed for these order?
Thanks!
374/5000
So as you ask I made a new installation of Prestashop 1.7.6.0 download to do this and we have exactly the same problem validation by the bank is OK but the Prestashop page displays "waiting for validation" it turns about 10 loops and there is no payment validation in Prestashop 1.7.6.0 administration orders
So as I said ;) This is a module bug not related with current currency issue
@flyman30, so after fresh installation PS.1.7.6.0, you create a new order => proceeded to checkout with the bank payment => in the BO => Order details page => there is no status displayed for these order?
Thanks!
Yes your right
@flyman30, what is the exact payment module did you use?
Thanks!
E-transaction V3.0.12
but
cmcicpaiement
Sogenactif 2.0
clicandpay
Are impacted too
@flyman30, did you tried to contact the module's authors about that issue?
Thanks!
Yes of course !
That's their answer:
We have just received the PHP logs from a client who is having the same problem.
There are actually loops at the time of validation of the payment.
One of the new parameters of Prestashop must act on the validateorder.
We invite you to get closer to Prestashop support.
We lack elements at our level to be able to bring you a solution.
Regards,
@flyman30 are you using E-transaction
module developed by PrestaShop?
I close this issue as the original subject "Different data in 'ps_currency' table when upgrading to PS 1.7.6" has been fixed by #14664
It seems there is an issue about payments modules here: #14648 Please follow & commment on this issue
J'utilise le module E-transaction 3.0.12 fournit par ma banque depuis que j'ai une boutique Prestashop (1.7.0.1) sans aucun soucis.
Ce n'est pas le module qui est en cause puisque TOUS les modules de paiement bancaire semble impact茅s !
Il faut comprendre pourquoi cette version PrestaShop pr茅sente un bug majeur dans la r茅ception des validations bancaire
exemple :
https://www.prestashop.com/forums/topic/997100-validation-commande-impossible-avec-e-transaction-paybox/
https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3138391
Hi, reproduced the bug when passing from 1.7.5.1 to 1.7.6.0.
This is breaking the Paybox/e-transactions payment module which uses the numeric iso code.And many others payment modules worried
After correction of the table ps_currency the data is well transmitted to the bank (module E-transaction) but the return of the bank accepted or not is not taken into account by PrestaShop after the update of 1.7.5.2 -> 1.7 .6.0
LOG :
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in聽/var/www/vhosts/*/httpdocs/classes/Tools.php:801\nStack trace:\n#0聽/var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1聽/var/www/vhosts/*/httpdocs/classes/PaymentModule.php(421): ToolsCore::displayPrice(9.6, Object(Currency), false)\n#2聽/var/www/vhosts//httpdocs/modules/etransactions/etransactions.php(925): PaymentModuleCore->validateOrder(1190, '2', 17.1, 'E-Transactions', 'Le paiement a \xC3...', Array, NULL, false, '01e083d45ca21d3...')\n#3聽/var/www/vhosts//httpdocs/modules/etransactions/classes/ETransactionsController.php(241): ETransactions->onMixedIPNSuccess(Object(Cart), Array)\n#4聽/var/www/vhosts//httpdocs/modules/etransactions/index.php(69): ETransactionsController->ipnAction()\n#5 {main}\n thrown in聽/var/www/vhosts/*/httpdocs/classes/Tools.php聽on line 801\n'
Banque return is made through Ajax, therefore the Context class is not instantiated correctly.
To avoid the error *PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null *, your bank module needs to instantiate the controller and language in Context.
Example :
Context::getContext()->language = new Language(Configuration::get('PS_LANG_DEFAULT'));
Context::getContext()->controller = new FrontController();
Context::getContext()->controller->init()
With that, it should be okay and ToolsCore::displayPrice() method should be not throw exception.
Hi @idnovate,
Thanks for your report.
I have the same issue with theps_currency
table.
Fresh installation PS1.7.6.0
- The name is empty
- After upgrade from PS1.7.5.2 to PS1.7.6.0
We have different
numeric_iso_code
,precision
.In the PS1.7.5.2, table ps_currency is different
Ping @PrestaShop/prestashop-core-developers what do you think?
Thanks!
Hi! i have the same problem, but i use USD, the iso code will be 978 too?
Hi! i changed the precision, and now works perfectly! Thank you very much!
Hi @idnovate,
Thanks for your report.
I have the same issue with theps_currency
table.
Fresh installation PS1.7.6.0
- The name is empty
- After upgrade from PS1.7.5.2 to PS1.7.6.0
We have different
numeric_iso_code
,precision
.
In the PS1.7.5.2, table ps_currency is different
Ping @PrestaShop/prestashop-core-developers what do you think?
Thanks!Hi! i have the same problem, but i use USD, the iso code will be 978 too?
Iso code for USD is 840
even with all things Ok in the table:
we continue to have round problems when there are discounts:
a difference not on decimals but consistent like in this case.
Most helpful comment
I close this issue as the original subject "Different data in 'ps_currency' table when upgrading to PS 1.7.6" has been fixed by #14664
It seems there is an issue about payments modules here: #14648 Please follow & commment on this issue