Double paiement et bon de livraison

Nicolas APOG · July 10, 2014

Bonjour à tous,

Mon client utilise la version 1.6.0.5 de Prestashop.

Voici mon problème :
Hier soir, trois commandes ont été passées et payées via le module Paybox.
Suite à un problème dont j'ignore la cause, l'enregistrement du paiement de ces trois commandes a été doublé. J'ai vérifié auprès de la banque, aucun double paiement n'a été effectué. A chaque fois, le bon montant a été crédité.

Dans le détail de ces commandes, je retrouve à chaque fois deux lignes indiquant le paiement du même montant. Un message d'avertissement du genre s'affiche : "Avertissement 52,00 € payé au lieu de 26,00 €"

A présent, la facture et le bon de livraison "buggent" et n'affichent pas la liste des articles commandes, et le mauvais montant du paiement est indiqué.

Y'a-t-il un moyen de supprimer cette deuxième ligne, afin de permettre le bon affichage de la facture et du bon de livraison ?

1. Y'a-t-il une ligne à supprimer dans la base de données ?

2. Y'a-t-il une opération à effectuer dans le back-office Prestashop. J'ai pensé à un remboursement, mais les clients de ces commandes n'ont pas payés plus que le montant indiqué...

Merci d'avance pour vos réponses

Hobbes · September 23, 2014

Bonjour,

J'ai le même problème sous PS 1.6.0.9 et paiement par Systempay.

Le dédoublement du règlement se produit lorsque je passe l'état de la commande à "Préparation en cours".

Capture du phénomène :

Artleast · September 26, 2014

Bonjour,

Problème similaire pour moi qui s'est produit soudainement aujourd'hui alors que tout fonctionnait très bien.

J'ai "paiement accepté" qui apparait 2 fois, comme si 2 transactions avaient été prise en compte en même temps et le message suivant "attention 178 € payé au lieu de 89 €"

Choix du paiement lors de mes deux dernières commandes qui posent problèmes = Multisafepay

Avez-vous trouvé une solution ?

Merci d'avance

Sous PrestaShop™ 1.6.0.9

rachel01 · October 23, 2014

Bonjour,

J'ai le même problème. Le paiement se dédouble au moment du statut "Préparation en cours" avec le paiement par chèque.

Quelqu'un de la team pourrait nous aider ?

Merci

Sylv1685 · November 5, 2014

Même Problème pour moi avec Paybox,

Sur deux commandes aujourd'hui des choses étranges se passent:

Au niveau du BO (cf screenshot):

1. facture non directement éditable via le menu du haut

2.1 message d'alerte : Attention 2*X € payé au lieu de X €

2.2 et 2.3 - deux lignes de paiement l'une avec un id de transaction et pas de facture associée et l'autre sans ID de transacton mais avec facture...

3. au niveau de ma facture le montant total est bon mais il manque un produit présent dans le panier.

Chez Paybox:

Le montant payé est le bon et n'a été pris en compte qu'une seule fois, contrairement à ce que pourrait laisser penser le message d'alerte.

Nous sommes plusieurs dans ce cas, quelqu'un aurait-il une solution / explication à nous proposer ???

Merci à ceux qui pourront faire avancer la résolution de ce problème.

PS: Ne serait-ce pas lier au temps de réponse du serveur de la banque ?

Sylv1685 · November 7, 2014

Je reviens aux nouvelles, voici ce que m'a répondu le développeur de mon module paybox :

"Ce problème arrive couramment sur Prestashop quand le montant du panier ne correspond pas au paiement.

Cela arrive quand il y à des réductions superposées avec du Ht et TTC ou des réductions promo ou groupes qui fait que le calcul global pose un problème d'arrondi de quelques centimes.

Ca n'est pas du au temps de réponse de la banque en tout cas.

Il faut augmentes les décimales d'arrondi de Prestashop lors du calcul panier"

Des nouvelles de votre côté ???

Had · December 5, 2014

up !

Exactement le meme probleme - presta 1.6 .0 .9 et module paybox activé

Quelqu'un a t-il testé la solution d'"augmenter les decimales d'arrondi lors du calcul panier ?"

Merci

Celou · December 11, 2014

Je me joins à votre topic pour vous dire que, suite au paiement de mes commandes, j'ai ce problème d'affichage en double dans le back-office dans la commande client de l'intitulé "paiement accepté" à quelque secondes d'intervalle. Le règlement sur mon compte Paypal s'effectue heureusement qu'une seule fois. De plus je n'ai pour ma part pas d'erreur de montant comme certains d'entre vous.

J'utilise Paypal depuis très longtemps sans incident et je rencontre ce problème depuis que j'ai mis à jour récemment mon module Paypal Paypal vers la dernière version soit la 3.8.1.

A votre écoute pour toute solution, sachant que je ne manquerai pas de vous informer de mes investigations.

Celou.

Edited December 11, 2014 by Celou (see edit history)

sergem · December 24, 2014

Bonjour à tous,

je me mets dans la boucle car je rencontre le mm pb.

J'ai lu cette histoire d'arrondi, pour moi, cela ne doit pas venir de là, car mes prix sont sans chiffre après la virgule (c'est plus simple) mais j'ai qd mm tous mes paiements cb qui génèrent automatiquement 2 factures ... cela ne fait pas très sérieux.

En espérant que qqn aura une réponse à poster sur le forum/

Bonnes fêtes de Noel

Bonnes fêtes de Noel.

Sylv1685 · January 21, 2015

Sans réponse je me permet de relancer le sujet !!!

Même aprés avoir augmenté les decimales d'arrondi lors du calcul panier, le problème persiste et arrive de manière complètement aléatoire.

Est-ce que quelqu'un de la team prestashop pourrait nous éclaircir sur ce problème.

Merci

fulviods · February 6, 2015

Je relance également ce message car sur un PS 1.6.0.9 j'ai le même soucis avec les paiement par chèque....
C'est assez hallucinant qu'aucune solution existe pour un bug si important que plusieurs personnes ont

billoute51 · February 9, 2015

Bonjour à tous,

actuellement sur un prestashop 1.6.0.6 je rencontre un problème similaire. Dés qu'un client comande un produit qui faite l'objet d'une promotion via une règle de prix catalogue, cette commande apparait avec l'erreur "Avertissement XX,XX € payé au lieu de XX,XX €", le listing des produits est vide et la facture également.

Toujours pas de solution ??

doekia · February 9, 2015

Quels sont les version de vos modules de paiement (paypal, paybox, ...) repéré, Paypal3.81 d'autres versions?

Quels sont les modules attachés sur les hook action*Order*

principalement actionOrderStatusUpdate et actionOrderStatusPostUpdate et actionValidateOrder

Modules > Positions

fulviods · February 9, 2015

Quels sont les version de vos modules de paiement (paypal, paybox, ...) repéré, Paypal3.81 d'autres versions?

Quels sont les modules attachés sur les hook action*Order*

principalement actionOrderStatusUpdate et actionOrderStatusPostUpdate et actionValidateOrder

Modules > Positions

eh bien merci je constate que ces 3 hooks ne sont pas là

je pense que pas mal de soucis de mon shop viennent de la...

Comment les activer? je ne vois pas actionOrderStatusUpdate et actionOrderStatusPostUpdate et actionValidateOrder

dans les positions.... jai greffé "bloc meilleures ventes" à actionorderstatuspostupdate (comme sur un autre site) , je retourne dans les positions et ne voit pas ce hook...

J'ai attaché "expertise prestashop" sur le hook actionorderstatusupdate et là il me dit qu'il est déjà sur ce hook...mais si je vais dans position il n'y est pas !

Comment réactiver ces 3 hooks ? je pense que cest la source de plusieurs problèmes...

Merci bien

billoute51 · February 9, 2015

J'utilise le module de magavenue "CB avec Paybox" v10.6.

Au niveau des hook action*Order* rien n'est activé mise à part "meilleurs ventes" et "expertise prestashop".

fulviods · February 9, 2015

Est ce une bonne idée de réuploader les fichiers de la 1.6.0.9.11, par ex le dossier admin? je me dis peut être que des fichiers sont corrompus pour que je ne vois pas ces hook

doekia · February 9, 2015

Non réécrire par dessus ne résoudra rien

Si l'un d'entre vous veux bien me donner un accès FTP + skype (en MP), je regarde de quoi il en retourne exactement. Pour plein de raison je préfèrerais quelqu'un avec Paypal.

doekia · February 10, 2015

Après pas mal de temps a chercher avec fulviods corrigé quelques bugs qui n'avaient rien à voir on a enfin trouvé le coupable.

La boutique de fulviods avait le statut (etat) de commande sur "en attente de paiement par chèque" maladroitement configuré avec "considérer la commande comme validé".

Ce paramétrage erroné fait surgir cette erreur. Le fait que l'erreur soit là depuis un moment "masquée" provient du fait que maintenant Prestashop enumère différement les paiements.

Voici un requète permettant de voir les commandes impactées:

select * 
from ps_order_payment  op
left join ps_order_invoice_payment oip on oip.id_order_payment = op.id_order_payment
where oip.id_order_payment is null

Si cette requête ramène des éléments il est fort à pariier que vous soyez dans ce cas de figure.

billoute51 · February 11, 2015

OUF, je commence à avoir de l'espoir.

Après avoir lancé la requête je retourne 8 enregistrements :

4 ASZNTAIQA 1 45.50 CB avec Paybox 1.000000 250006252 2014-12-08 21:58:18 NULL NULL NULL 6 ERPMIDOXI 1 19.50 CB avec Paybox 1.000000 250114759 2014-12-09 16:43:37 NULL NULL NULL 14 FKCAMVTDW 1 71.50 CB avec Paybox 1.000000 253441032 2015-01-07 12:36:48 NULL NULL NULL 16 TKSSMAFYT 1 58.50 CB avec Paybox 1.000000 254684687 2015-01-16 15:11:31 NULL NULL NULL 18 TKSSMAFYT 1 58.50 CB avec Paybox 1.000000 254684687 2015-01-16 15:11:57 NULL NULL NULL 21 KMYQNXSGZ 1 36.50 CB avec Paybox 1.000000 256326790 2015-01-30 09:51:42 NULL NULL NULL 22 KMYQNXSGZ 1 36.50 CB avec Paybox 1.000000 256326790 2015-01-30 09:51:48 NULL NULL NULL 24 JIAQQJTVO 1 26.50 CB avec Paybox 1.000000 257639956 2015-02-09 10:00:11 NULL NULL NULL

Quelle solution faut-il apporter car je n'ai pas vraiment saisie la solution

doekia · February 11, 2015

Je n'ai pas vraiment posté de solution pour le passif afin d'éviter un remède pire que le mal.

Pour la suite aller dans "Commandes" / "Etats", cliquer le statut des commande pour lequelles l'argent n'est pas encore là:

Attente paiement par chèque

Attente paiement bancaire

...

Vérifier que la coche "Considérer la commande associée comme validée." est décochée

Pour le passif, je ne connais pas vos compétence SQL donc ... a moins d'intervenir chez chacun, je pense que vous devriez vivre avec

Si vous connaissez SQL vous avez sûrement déjà compris ce qu'il faut faire ;-)

Sylv1685 · February 11, 2015

Bonjour et merci pour à tous pour ces précisions qui semblent tendre vers une solution !

Mes commandes posant problème étant réglé via le module paybox (le problème est complètement alétoire et concerne un trés faible pourcentage de mes commandes , moins de 2%) , j'ai contrôlé le statut des commandes liés à paybox et je me rend compte que dans le statut "Payé partiellement via Paybox" l'option "considérer la commande comme validée" et "autoriser le client à télécharger sa facture" sont cochées.

Si je vous comprend bien l'erreur pourrait provenir de ce statut, et je dois décocher ces deux options ? est-ce bien la marche à suivre ?

Merci d'avance pour vos conseil !

doekia · February 11, 2015

Pour le paiement partiel je doute car dans ce cas il y a bien 2 paiement consécutif a prendre en compte.

Le truc c'est que lorsque tu passes la commande à prepa en cours ou en cours de livraison ces état considèrent également la commande comme validé et forcent un paiement en quelque sorte.

Là je pense que nous avons un bug core mais il faudrait que je plonge dans le code pour ce problème typique.

Si ça n'affecte que 2% je laisserai comme ça et ferai un bug report

Edited February 11, 2015 by doekia (see edit history)

fulviods · February 11, 2015

Je remercie INFINIMENT doekia pour son aide plus que précieuse !!! Faudrait que ça soit lui à valider les versions de PS qu'on nous donne

billoute51 · February 18, 2015

Re,

je reviens avec un peu plus d'infos. Je m'aperçois que la table ps_order_detail n'est pas rempli en BDD. Quelqu'un à t'il une idée et peu t'on via le panier enregistré sur le client régénérer la ou les ligne(s) manquante(s) dans la table ps_order_detail pour que les produits réapparaissent dans le détail de la commande SVP ?

doekia · February 18, 2015

Oui on peut en partie reconstruire au détail près des prix lors de la commande si ils ont changé entre temps

On peut mais ça dénote d'un gros problème par ailleurs qu'il faudrait corriger d'urgence

billoute51 · February 18, 2015

Alors j'utilise le module paybox de MagAvenue et après check des logs serveur : j'ai un "Premature end of script headers: validation_auto.php" Je pense que la validation n'a pas été jusqu'au bout mais pourquoi ??

doekia · February 18, 2015

Tellement de raisons possible que je peux pas toutes les énumérer... context/backward-compat/module-hook-crashant pour citer les plus courantes

Il faut faire du debug du bazar ...

Gooogor · April 4, 2015

J'ai exactement le même problème.

Qui arrive alléatoirement.

Je suis sous Prestashop 1.6.0.8

Je fais un test en enlevant l'Etat "Paiement à distance accepté" qui à l'air de faire doublon avec "Paiement accepté"

J'ai aussi remarqué que dans la base donnée ps_order_payment lorsque le problème survient il y a deux ligne pour le même paiement et la différence entre les deux se situe dans la colone transaction_id, il y a une des deux ligne qui reste vide pour cette entrée.

pixandweb · May 28, 2015

Bonjour,

Je me permets de relancer le sujet, j'ai un site client qui tourne sous prestashop 1.6.0.11, et j'ai le même problème.

De manière aléatoire, les paiements s'inscrivent en double, idem pour les bons de livraison.

Au niveau des paramètres des statuts de commande, tout semble bon (par rapport aux messages précédents dans le sujet)

( case "Considérer la commande associée comme validée." décochée pour les statuts 'En attente du paiement par chèque ' et 'En attente du paiement par virement bancaire ' )

Lorsque j'éxécute la commande sql

select * 
from ps_order_payment  op
left join ps_order_invoice_payment oip on oip.id_order_payment = op.id_order_payment
where oip.id_order_payment is null

J'ai une ligne de retour.

Mais alors que faire pour corriger ce problème ?

Si quelqu'un a trouvé la solution je veux bien un coup de main

Merci d'avance,

Thierry

Gooogor · June 13, 2015

Bonjour,

Mon problème semble avoir disparut. J'ai eue une bonne cinquantaine de commande et plus de doublons.

Le seul truc que j'ai fais c'est réinstaller le site suite à un autre soucis.

Bizarre mais je croise les doigts pour la suite.

Et bien Non les doublons sont revenue

Edited July 4, 2015 by Gooogor (see edit history)

natachaC · August 21, 2015

Bonjour
Presta 1.5.6.2

subitement même problème de commandes depuis 8/10 jours alors que la boutique fonctionne depuis 9 mois sans aucun soucis
pour l'instant que par le CMCIC

États : Paiement accepté affiché 2 fois à 13 secondes d'intervalle ( 20/08/2015 21:19:05 et 20/08/2015 21:19:18)

Paiement :
Attention 146,94 € payé au lieu de 73,47 € (soit le double alors qu'il n'y a qu'un paiement)

Date Méthode de paiement ID de la transaction Montant Facture
20/08/2015 21:19:05 CM-CIC 73,47 € #FA000485
20/08/2015 21:19:05 CM-CIC xxxx 73,47 € Pas de facture

il manque des produits (en stock) dans les factures et BL
dans order products le champs numéro de facture id_order_invoice est à 0 pour les produits manquants

merci d'avance pour vos idées
Natacha

Edited August 21, 2015 by natachaC (see edit history)

Gooogor · August 30, 2015

Bonjour,

De ce que j'ai compris le problème est assez insoluble sauf en changeant de prestataire de paiement. Cela viendrait du fait de client qui une fois sur la page du paiement reviendrait en arrière avec le bouton "précédent". Et après retournerai sur la page de paiement en n'ayant fait aucune modification dans le panier. Le serveur de paiement lui se dit Ok c'est toujours pareil (car il attends pendant 2 ou3 minutes) mais PS lui considère le produit virtuellement deux fois le panier et forcement après acceptation du paiement un seul est validé. J'espère avoir été clair

Bref pour remédier au problème des boutons de Facture et Bon de livraison qui n'apparaissent pas j'ai modifié le code.

Il y a 4 fichiers à modifier. Faites bien une sauvegarde de vos fichiers avant de les modifier.

Modification /classes/pdf/HTMLTemplateInvoice.php
   Pour faire apparaître les produits dans la facture si double paiement

   Trouver

$order_details = $this->order_invoice->getProducts();

Remplacer par

$order_details = $this->order->getProducts();

Modification /classes/pdf/HTMLTemplateDeliverySlip.php
   Pour faire apparaître les produits dans le bon de livraison si double paiement

   Trouver

 $order_details = $this->order_invoice->getProducts();

Remplacer par

$order_details = $this->order->getProducts();

Trouver

return Configuration::get('PS_DELIVERY_PREFIX', Context::getContext()->language->id, null, $this->order->id_shop).sprintf('%06d', $this->order->delivery_number).'.pdf';

Remplacer par

return Configuration::get('PS_DELIVERY_PREFIX', Context::getContext()->language->id, null, $this->order->id_shop).sprintf('%06d', $this->order_invoice->id_order).'.pdf';

Modification Admin /admin0119/themes/default/template/controllers/orders/helpers/view/view.tpl
   Si les boutons Facture et Livraison apparaissent grisé dans la commandes à cause des erreurs de double paiement

   Trouver

<span class="span label label-inactive">
    <i class="icon-remove"></i>
    {l s='No delivery slip'}
</span>

Remplacer par

<a class="btn btn-default _blank"  href="{$link->getAdminLink('AdminPdf')|escape:'html':'UTF-8'}&submitAction=generateDeliverySlipPDF&id_order={$order->id|intval}">
     <i class="icon-truck"></i>
     {l s='View delivery slip'}
</a>

Trouver

<span class="span label label-inactive">
     <i class="icon-remove"></i>
     {l s='No invoice'}
</span>

Remplacer par

<a data-selenium-id="view_invoice" class="btn btn-default _blank" href="{$link->getAdminLink('AdminPdf')|escape:'html':'UTF-8'}&submitAction=generateInvoicePDF&id_order={$order->id|intval}">
     <i class="icon-file"></i>
     {l s='View invoice'}
</a>

Modification admin?????/themes/default/template/controllers/orders/_print_pdf_icon.tpl
Si aucun bouton n’apparaît dans la liste des commandes à cause des erreurs de double paiement voici ce qui faut rajouter à la fin du fichier pour voir les boutons

{if $order->delivery_number == '0'}
    <a class="btn btn-default _blank" href="{$link->getAdminLink('AdminPdf')|escape:'html':'UTF-8'}&submitAction=generateInvoicePDF&id_order={$order->id}">
        <i class="icon-file-text"></i>
    </a>
    <a class="btn btn-default _blank" href="{$link->getAdminLink('AdminPdf')|escape:'html':'UTF-8'}&submitAction=generateDeliverySlipPDF&id_order={$order->id}">
        <i class="icon-truck"></i>
    </a>        
{/if}

Je suis sous PS 1.6.1

natachaC · September 3, 2015

une bonne piste merci
je viens de mettre en préprod mode TEST un paiement CMCIC et j'ai trouvé que l'interface de paiement était très longue

à priori la dernière commande en date qui a ce problème après questionnement auprès de l'utilisatrice et d'après ses dires elle n'a pas fait de retour à la boutique prématuré
mais c'est difficile car ça tiens à quelques secondes

gshds · September 19, 2015

Bonjour,

J'ai également le même problème qui est relativement aléatoire, mais qui est quand même + que 10% des commandes.

Ce qui est grave dans mon cas, c'est que le client reçoit deux factures avec deux numéros de facture différents et le montant est le double de ce qu'il doit vraiment payer, ce qui n'est pas juste au niveau comptable.

Si le client effectue un virement bancaire il reçoit une confirmation de commande indiquant "veuillez nous envoyer un virement bancaire avec : Montant le double de ce qu'il doit vraiment payer. Le client finalement abandonne le panier.

Mon problème ressemble beaucoup au vôtre, quel conseil pourriez-vous me donner ?

natachaC · September 21, 2015

Bonjour

testez cette modification sans garantie mais qui a l'air de fonctionner

Dans la classe Product fonction getPriceStatic (override pour rester un peu propre)
à la fin dans le return forcer la précision pour éviter les arrondies.
(on la force par ce que si on change la précision depuis le BO, tout le front se retrouve avec x décimales, et c'est moche)

        return Product::priceCalculation(
            $context->shop->id,
            $id_product,
            $id_product_attribute,
            $id_country,
            $id_state,
            $zipcode,
            $id_currency,
            $id_group,
            $cart_quantity,
            $usetax,
            6, //$decimals, // -> force decimal : hack for TVA calcul
            $only_reduc,
            $usereduc,
            $with_ecotax,
            $specific_price_output,
            $use_group_reduction,
            $id_customer,
            $use_customer_price,
            $id_cart,
            $quantity
        );

gshds · September 22, 2015

Merci Natacha,

Mais où se trouve le fichier à modifier ?

Salutations,

G.

natachaC · September 22, 2015

dans le dossier classes

Dans le fichier Product.php fonction getPriceStatic

ezcb · October 1, 2015

Bonjour,

En fait il y a 2 bugs qui peuvent générer l'erreur Attention XXX € payé au lieu de XXX €

Le premier bug est sur le calcul des factures qui est erroné.

En effet la requête renvoi null sur une sum de 0 résultat.

Pour corriger on ajoute la fonction COALESCE sur la requete SQL dans la fonction getSiblingTotal du fichier OrderInvoice.php

on remplace donc

public function getSiblingTotal($mod = OrderInvoice::TAX_INCL)
	{
		$query = new DbQuery();
		$query->select('SUM(oi.total_paid_tax_incl) as total_paid_tax_incl, SUM(oi.total_paid_tax_excl) as total_paid_tax_excl');
		$query->from('order_invoice_payment', 'oip1');
		$query->innerJoin('order_invoice_payment', 'oip2',
			'oip2.id_order_payment = oip1.id_order_payment AND oip2.id_order_invoice <> oip1.id_order_invoice');
		$query->leftJoin('order_invoice', 'oi',
			'oi.id_order_invoice = oip2.id_order_invoice');
		$query->where('oip1.id_order_invoice = '.$this->id);

		$row = Db::getInstance()->getRow($query);

		switch ($mod)
		{
			case OrderInvoice::TAX_EXCL:
				return $row['total_paid_tax_excl'];
			case OrderInvoice::TAX_INCL:
				return $row['total_paid_tax_incl'];
			default:
				return $row;
		}
	}

Par

public function getSiblingTotal($mod = OrderInvoice::TAX_INCL)
	{
		$query = new DbQuery();
		$query->select('COALESCE(SUM(oi.total_paid_tax_incl),0) as total_paid_tax_incl, COALESCE(SUM(oi.total_paid_tax_excl),0) as total_paid_tax_excl');
		$query->from('order_invoice_payment', 'oip1');
		$query->innerJoin('order_invoice_payment', 'oip2',
			'oip2.id_order_payment = oip1.id_order_payment AND oip2.id_order_invoice <> oip1.id_order_invoice');
		$query->leftJoin('order_invoice', 'oi',
			'oi.id_order_invoice = oip2.id_order_invoice');
		$query->where('oip1.id_order_invoice = '.$this->id);
		
		$row = Db::getInstance()->getRow($query);
		switch ($mod)
		{
			case OrderInvoice::TAX_EXCL:
				return $row['total_paid_tax_excl'];
			case OrderInvoice::TAX_INCL:
				return $row['total_paid_tax_incl'];
			default:
				return $row;
		}
	}

On va également corriger la fonction getRestPaid()

on remplace donc toujours dans OrderInvoice.php

public function getRestPaid()
	{
		return round($this->total_paid_tax_incl + $this->getSiblingTotal() - $this->getTotalPaid(), 2);
	}

Par

public function getRestPaid()
	{
	       return round($this->total_paid_tax_incl + (float)$this->getSiblingTotal() - $this->getTotalPaid(), 2);
	}

Pour le deuxième BUG et le plus important c'est la fonction getTotalPaid qui est mise en cache et qui pose problème.

Ce cache est unique par process http

Dans ce process, la même action est appelée 2 fois sans être rafraîchis.

En cas pratique ca donne

getTotalPaid = 0

Ajout de la facture etc ....

getTotalPaid = 0 alors qu'un paiement a été ajouté.

Donc pour corriger il suffit de commenter la mise en cache de la fonction getTotalPaid()

On remplace

public function getTotalPaid()
	{
		$cache_id = 'order_invoice_paid_'.(int)$this->id;
		if (!Cache::isStored($cache_id))
		{
			$amount = 0;
			$payments = OrderPayment::getByInvoiceId($this->id);
			foreach ($payments as $payment)
				$amount += $payment->amount;
			Cache::store($cache_id, $amount);
		}
		return Cache::retrieve($cache_id);
	}

Par

public function getTotalPaid()
	{
		$cache_id = 'order_invoice_paid_'.(int)$this->id;
		/*if (!Cache::isStored($cache_id))
		{*/
			$amount = 0;
			$payments = OrderPayment::getByInvoiceId($this->id);
			foreach ($payments as $payment)
				$amount += $payment->amount;
			Cache::store($cache_id, $amount);
		//}
		return Cache::retrieve($cache_id);
	}

Voila a présent vous n'aurez plus de problème du XXXXXX€ au lieu de xxxx€ .

Presta foire à la base.

Il crée le paiement (acquittement du solde du) si le statut de la commande à l'option :

"Considérer la commande associée comme validée" est activé.

Alors que Presta devrait créer le paiement que si l'option :

"Marquer la commande associée comme payée " est activé.

Pourquoi ? parce que on peut tout à fait avoir une commande qui est valide et non payée (B2B) alors que Presta considère systématiquement qu'une commande validée est payé et en plus il considère que la commande est réglée à 100%.

j'en déduit que l'ajout manuel de règlement partiel a une facture ne fonctionne pas.

Faites un test :

Prenez une commande et aller dans la table PS order paiement
Modifiez le montant du paiement en le divisant par 2 par exemple.
Revenez sur votre commande et dans l'onglet paiement vous verrez que le solde du paiement est divisé par 2 (donc en théorie le client a réglé 50% de la facture).
Changez le statut de votre commande vers un autre statut validé.

Et la Presta à créer à nouveau un paiement de la différence alors qu'il ne devrait pas y toucher.

Par définition ce bug nous empêche de saisir plusieurs règlements pour une commande car comme je viens de le dire Presta considère une commande comme 100% acquittée dès lors qu'il y a changement de statut vers un statut considéré comme validé.

Edited October 1, 2015 by ezcb (see edit history)

lechapelier · March 24, 2016

Bonjour,

pour ma part ce problème est intervenu après une mise à jour presta, une désinstallation et réinstallation des modules de paiement a résolu le problème de ce conflit de status qui bloque l’accès à l'impression de la commande, case grisée et la création d'un double paiement erroné avec des manques de produits dans les factures, à tester avant tout autre manipulation.

jojocarofr · July 8, 2016

Bonjour

Quelqu'un a une solution au problème facile à mettre en place

J'ai fait le test de retirer les modules de paiement et les remettre

Niet pour moi toujours le probleme

je suis en 1.6.1.6 et paypal en 3.10.10 et systempay en 1.7.0

Merci de vos aides

jojocarofr · July 8, 2016

Pour moi les modifs ne fonctionnent pas

SimonBMC · July 20, 2016

Bonjour,
Je rencontre également ce problème.

Sans aucune raison, depuis le 6 Juin, j'ai droit à un doublon de paiement.

Lorsque je passe ma commande dans l'état "En cours de préparation", prestashop m'affiche une seconde ligne de paiement dans cet onglet éponyme ainsi que le message "Attention XX€ payé au lieu de XX€".

Une idée ? J'ai parcouru les 3 pages de ce sujet, rien n'a été fructueux :/

PS 1.6.1.2 - Module de paiement CM-CIC P@iement

Merci par avance !
Simon

Edited July 20, 2016 by SimonBMC (see edit history)

Emil59 · July 20, 2016

Bonjour,

Même problème aujourd'hui pour moi

doekia · July 20, 2016

Vérifier les drapeau des statuts des commandes

Elle passent 2 fois dans l'état validé (un statut intermédiaire les ... dévalide)

Emil59 · July 21, 2016

Le souci c'est que je n'ai eut ce problème que pour une commande. Toutes les autres commandes ebay sont correctes.

SimonBMC · July 21, 2016

Vérifier les drapeau des statuts des commandes

Elle passent 2 fois dans l'état validé (un statut intermédiaire les ... dévalide)

Bonjour Doekia,

Merci pour votre réponse.

Je suis perplexe, mon état de commande "en cours de préparation" considère la commande comme validée ET payé (par défault dans prestashop).

Est-ce la raison ? je ne pense pas. En effet, l'état "expédié" considère lui aussi la commande comme validée ET payé, sauf qu'il ne me triple pas la ligne de paiement.

Voir Pièce jointe

Voir Pièce jointe pour un exemple de commande

Merci pour votre aide !

Edited July 21, 2016 by SimonBMC (see edit history)

doekia · July 21, 2016

Quand les drapeaux de statutx ne changent pas entre les états tout va bien - je te rapporte ce qui arrive quand état 1 - valide, état 2 - non valide, état 3 valide, les états 1 et 3 font des paiements

Si tu n'es pas dans ce cas là alors le problème vient d'ailleurs, c'est tout.

Vérifie quand même le drapeau sur paiement accepté ... il doit dire valide

PS: Vous êtes 2 mais il est probable que bien que les symptômes soient les même, vous n'avez pas le même problème. L'un fait un paiement systempay tandis que 'autre "injecte" via l'import ebay

Edited July 21, 2016 by doekia (see edit history)

SimonBMC · July 21, 2016

Doekia, qu'entends-tu par "drapeau" ?

Concernant ton "PS", j'en suis bien conscient. Ce problème peut venir d'un nombre incalculable de choses. Cependant, dans mon cas, cela doit sans doute venir des états de commande étant donné que le doublon est daté du même jour et à la même heure que le passage à l'état "En cours de préparation".

Edited July 21, 2016 by SimonBMC (see edit history)

doekia · July 21, 2016

http://awesomescreenshot.com/0cf61cg75f

SimonBMC · July 21, 2016

Merci,
Alors je te confirme que mon état de commande "paiement accepté" est bien sur validé.

>> Screenshot de mes états de commande

doekia · July 21, 2016

Donc le problème ne vient pas en soi des états.

Je pencherais pour une bug dans un module hook sur validateOrder qui empèche le champ valid de ps_orders d'être correctement mis à jour à creuser

nabil509 · September 7, 2018

Bonjour,

Le post est relativement ancien mais j'apporte une réponse au cas où des personnes atterrissent ici en cherchant à propos de ce problème.

Le problème est bien relatif à l'activation de l'option « considérer la commande associé comme validé » sur plusieurs statuts de commande. En fait, lors du passage de la commande vers un nouveau statut, si celui-ci possède l'option en question activée, PrestaShop crée systématiquement une nouvelle entrée dans le détail du paiement alors que la méthode de paiement a déjà créé la ligne de paiement juste à la fin du paiement (généralement lors du passage au statut "Paiement accepté").

En règle générale, un seul statut devrait avoir l'option « considérer la commande associé comme validé » activée.

Je pense que PrestaShop devrait revoir sa gestion des statuts. Le fait de permettre de configurer tout sur un statut peut produire des confusions et des situations incohérentes. On peut par exemple considérer le statut "Annulée" comme "payée" ou "validée" en cochant les options qui correspondent. Or dans le code, ce statut s'appelle PS_OS_CANCELLED et correspond donc toujours à une annulation (même si on change son libellé dans l'administration de PrestaShop.

En attendant, je pense qu'il vaut mieux laisser les options par défaut en ce qui concerne la gestions des statuts et pour les besoins les plus complexes, préférer la création de nouveaux statuts plutôt que de recourir à la configuration des statuts existant mais il faut bien sûr être capable de prendre en compte ces nouveaux statuts dans le code.

doekia · September 7, 2018

Désolé @nabil509, mais ce n'est pas exactement comme celà que ça fonctionne.

Prestashop crée un nouveau paiement chaque fois qu'une commande passe d'un statut non validé à un statut validé

Autrement dit, dans ta chaine de statuts a partir du paiement (validé) tous les autres statuts doivent avoir le drapeau.

nabil509 · September 7, 2018

OK @doekia. Merci pour cette précision.

Mais le problème qui se pose c'est que la création du détail du paiement doit être du ressort de la méthode de paiement. C'est elle qui possède les informations sur le paiement. Et la méthode de paiement ne s'occupe pas de statuts comme "Préparation en cours" ou "Expédiée". Le statut le plus important pour une méthode de paiement est "Paiement accepté" et ce statut doit considérer la commande comme validée ou alors il faut dé-corréler la création de paiement et la validation de la commande.

nabil509 · September 7, 2018

Après l'autre remarque que j'ai soulevé c'est que la configuration des statuts est très discutable: doit-on se fier au sens du statut (Paiement accepté, Annulé, ...) ou à sa configuration (validée, payée, ...) ? Ces deux notions peuvent être très contradictoires vu que le marchand peut faire tout ce qu'il veut.

Rodolphe · September 19, 2018

Bonjour.

À mon tour de rencontrer ce problème.

Testé avec différents mode de paiement qui ont tous un point commun, quand la facture est passée elle n'est pas encore payée (virement, chèque ou paiement CB différé).

Je passe au statut suivant (paiement accepté), ça créé le paiement. Ok pourquoi pas même si ça ne devrait pas le faire en automatique il me semble, ce sont des paiements qu'il faudriat enregistrer manuellement.

Mais passons, pourquoi pas.

Ensuite quand je passe en préparation, rebelote, paiement en double !

J'ai déjà installé pas mal de Prestashop dont deux que j'utilise tous les jours, sans jamais rencontrer ce problème.

J'avoue que je ne trouve pas...

Ce nouveau site est en 1.6.1.20.

EDIT : J'ajoute que si je créé d'abord le paiement manuellement, le passage ne paiement validé le double aussi. Alors que sur mon prestahsop habituel, aucun souci. Si je créé manuellement le paiement ou si je laisse Presta le créer au changement de statut, tout va bien. Là c'est Presta qui ne "voit" pas qu'il y a déjà un paiement !

Rodolphe

Edited September 19, 2018 by Rodolphe (see edit history)

Rodolphe · September 19, 2018

Bon, je suis un âne.

Il manquait la table ps_order_invoice_payment, qui fait justement le lien entre les paiements et la factures, donc forcément ça ne pouvait pas aller...

Pfff à force de vouloir être sur plusieurs fronts en même temps, on fait des co.....es !

Rodolphe

Delphine78 · September 28, 2018

Bonjour, j'ai le même problème, pour 1 commande de 100 euros par exemple, 2 factures éditées: une de 30 et une de 70 euros. Avec des messages d'erreur, des frais de port en double sur les 2 factures; tout devient incohérent pour la comptabilité.

Pouvez-vous m'aider et me dire où allez exactement pour modifier ce pb? Mille mercis

Je suis sous Prestashop 1.6.1.20

Double paiement et bon de livraison

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment