cartRule is not taken into account when tggatos module payment is chosen

[Mat-o]

Hi,

since I have added a cart rule to my shop, invoices paid using your module tggAtos go wild : 1/ In the invoice, discount appears in products table, but not in totals, where there is no "Discount Totals" line. So the invoice total is wrong (no discount). 2/ 2 payments are created in the database : 1 with the correct reduced amount, 1 with the content of the discount (!!!). Fortunately, the payment is OK : only the first payment is actually really done by the client. But where does this second payment log comes from ?? 3/ In the database, I see the order

I would like to add that : 3/ Everything works well without the cart rule 4/ The invoices generated after Paypal payment are OK : discount is taken into account, invoice total is ok in the PDF and the database, only one payment appears in B.O.

My guess : maybe some variables regarding discounts have been updated in PS 1.6.1.1 and your module doesn't use them.

Bonjour, je sais que vous parlez français, je vais donc traduire ce qu'il y a ci-dessus pour être sûr d'être compris (mon anglais est un peu approximatif). Déjà, bravo pour ce module complexe. Une fois mis en place correctement, il fonctionne très bien. Le problème évoqué plus haut est arrivé lors de l'introduction d'une règle dans le panier (50% sur une catégorie de produits). Celle-ci est correctement comprise par le système, et je dirais même que lors du paiement, aucun défaut n'est visible en F.O. : le montant à payer prend bien en compte la réduction.

En revanche, la facture générée est fausse :

• pas de ligne "Discount Totals" dans le bloc des totaux, donc la facture affiche un total sans réduction. Un client nous a appelé en croyant à une arnaque (!).
• Et il apparait 2 paiements : un du montant réduit (qui apparait dans le log ATOS), un second du montant de la réduction, qui lui n'apparait pas dans le fichier de log (et heureusement !).

Après étude de la BDD, je trouve ces anomalies :

• aucun numéro de CB pour ces 2 paiements, alors que les paiements des commandes sans réduction sont OK. Plus précisément : rien dans "card_number, ni "card_brand" de la table xxxx_order_payment, et pas de transaction_id pour le 2ème paiement.
• les montants "total_paid", "total_paid_incl_tax" de la table xxxx_orders ne prennent pas en compte la réduction ! En fait, aucun total dans les tables order et invoice n'ont pris en compte la réduction, il faut retrouver le payment # 1 de la facture pour retrouver le montant réellement payé, il ne s'affiche nulle part ailleurs.

À permière vue, je me serais penché sur un problème de Prestashop, mais les factures générées après un paiement par PayPal sont parfaites : prise en compte de la réduction partout, que ce soit dans le bloc des totaux dans la facture, ou dans les tables de la BDD...

Mon hypothèse est que de nouvelles variables concernant les réductions ont pu être introduites avec la version 1.6.1, et que votre module ne les prend pas correctement en compte. Ce qui m'inquiète surtout est la création systématique de ce 2ème paiement, qui est du montant de la réduction (comme si la variable du montant, au lieu de servir au calcul du total_paid, était utilisée pour créer un second paiement ??). Je vous remonte ce bug dans l'espoir que vous y compreniez quelque chose... Et que vous puissiez garder votre module fonctionnel. Je suis prêt à répondre rapidement à vos questions ou pour des tests, car la réduction ne peut pas être mise en œuvre en l'état sur mon site.

-Mato (en pj vous trouverez 2 factures anonymisées qui montrent bien le problème : 1 payée avec votre module, une en utilisant le module Paypal officiel) Conditions :

• PS 1.6.1.1, tggatos 3.4
• php 5.4 et Mysql 5.5
• pas d'overrides
• "free shipping" activé à partir de 40 €.

[TrogloGeek]

Thanks for providing so many informations, replicating and fixing the issue should be fast enough due to this.

Unfortunately I am moving to a new home this week, I hope being able to handle this by the next week.

[Mat-o]

Hi, did you manage to replicate the problem ? By the way, the cart rule I used is a simple 50% over a specific category of products. Please keep us posted, even with W.I.P.

[TrogloGeek]

Sorry, I forgot to update: I failed to replicate using a local (non accessible from internet) PrestaShop 1.6.1.1. I have suspicions that customer context is the difference here (because I use a virtual machine the bank cannot contact, in my tests orders were validated by customer return, so customer cookie was available, which is not when the silent request (autoresponse) from the bank validates the order. Could you please try to replicate preventing the silent response from being successful (you can mess with "Silent return front office domain" advanced parameter, setting an erroneous value here will make it fail) and let me know if the problem happens or not?

[TrogloGeek]

Did not reproduce even with bank silent response

I will need you to provide me with a step by step configuration from a clean PS 1.6.1.1 install (using demo products) to reproduce

[Mat-o]

OK, I guess my setup must be wrong somewhere. Il will try another payment module to test the problem again and will come back to you if I find something.

[TrogloGeek]

Adding a trace log of every OrderPayment::add() and OrderPayment::update() would be really useful, letting us know how you managed to get two different entries for one order. The issue with several payments being recorded remind me something bu I can't manage to remember where and how it happened.

[TrogloGeek]

If you can clone your shop to create a dev instance able to replicate the issue and give me access to it I would be able to nail down the issue.

[Mat-o]

Well I could clone it, but the bank is now in "Production" mode and I don't want any trouble on my client's bank account. Do you think you could test it in pre-prod mode with your own certificate/ ATOS bank?

[TrogloGeek]

I do not own an ATOS/SIPS payment certificate. But we shouldn't need to use your certificate on your shop clone to replicate the problem, I intend to use a bank demo certificate.

[Mat-o]

Hi, i would like to come back to you regarding your proposition. I will tried to get in touch with you by email. Hopefully this bug will be squashed !

[Mat-o]

Hi, I guess I juste have to close the issue, as I was not able to reproduce the bug on a fresh install. I must have a custom file somewhere causing this issue. Sorry for the trouble, your module works very well !

[TrogloGeek]

I guess I juste have to close the issue, as I was not able to reproduce the bug on a fresh install. I must have a custom file somewhere causing this issue.

We shouldn't close this as their are still chances that the issue lays in the module. Not replicating it on a fresh install does not prove that my code is not faulty, it just let us know that replicating it is not easy : there may be a bunch of configuration options (of both PrestaShop and the payment module) that has to be set the same way, a module interfering...

I'm still interested by a shop clone to pin down where the issue happens. If you want to send me private message, you can obtain my email address from the author field of my commits (GitHub won't show it, but you can have it using a desktop client on a clone from this repository). Or you can obtain another valid email address from my outdated resume here: http://www.capillotracteur.fr/ (I won't post it here as it could be scrapped by a robot, the one on my resume is protected from simple HTTP scrapping using javascript)

[TrogloGeek]

Seems to be caused by an override of CartRule relying on user cookies on this shop. Awaiting override fix verification before closing or looking further.