Jump to content

Recommended Posts

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

 

 

Share this post


Link to post
Share on other sites

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 :

 

14092303491917415112548911.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ?
 

Share this post


Link to post
Share on other sites

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é ???

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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 by Celou (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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 ??

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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".

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ;)

 
 

Share this post


Link to post
Share on other sites

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 ;-)

Share this post


Link to post
Share on other sites

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 !

Share this post


Link to post
Share on other sites

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 by doekia (see edit history)

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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 ? 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ??

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by Gooogor (see edit history)

Share this post


Link to post
Share on other sites

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 by natachaC (see edit history)

Share this post


Link to post
Share on other sites

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  :unsure:

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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
        );

Share this post


Link to post
Share on other sites

Merci Natacha,

 

Mais où se trouve le fichier à modifier ?

 

Salutations,

G.

Share this post


Link to post
Share on other sites

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 by ezcb (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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 by SimonBMC (see edit history)

Share this post


Link to post
Share on other sites

Vérifier les drapeau des statuts des commandes

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by SimonBMC (see edit history)

Share this post


Link to post
Share on other sites

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 by doekia (see edit history)

Share this post


Link to post
Share on other sites

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 by SimonBMC (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Rodolphe (see edit history)

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More