modules partenaires Paypal et Colissimo WebServices (So flexibilité) incompatibles : que faire ?

ChDUP · September 1, 2016

Bonjour à toutes et tous

Suite à l'installation du module Colissimo WebServices (ex So Flexibilité) version 3.1.08, je me suis aperçu que mes commandes Paypal (Integral Evolution) ne remontaient pas.

Le paiement passe bien, les transactions sont visibles sur le BO Paypal, mais aucun mail ne part et la commande n'est pas créée dans le BO Prestashop.

J'ai mis à jour Paypal en 3.10.10, ce qui n'a pas solutionné le problème.

Le problème se produit sur tous les transporteurs, y compris des transporteurs "non-modules" à partir du moment ou WebServices est installé.

En revanche, pas de problème avec mon autre moyen de paiement (SystemPay)

Pas de problème non plus avec Paypal et mon ancien module de transporteur So Colissimo par Quadra.

Après investigations, nous avons pu cerner le problème autour de la fonction getOrderTotal de la class Cart.

Au retour IPN Paypal, celui-ci vérifie les détails de la commande (ce que ne fait pas SystemPay, ce qui explique pourquoi le problème ne se produit qu'avec Paypal)

le détail panier est récupéré via getSummaryDetails

$cart_details = Context::getContext()->cart->getSummaryDetails(null, true);

getSummaryDetails fait appel au getOrderTotal du Cart qui semble perdre le Context.

pas de Context, pas d'id_order

Ce qu'on peut verifier d'ailleurs dans l'URL de redirection après le paiement Paypal, sur /modules/Paypal/submit.php

En paramètre, l'id_cart est bon, la key aussi, mais l'id_order est à 0.

Donc page de confirmation pour le client "vide".

Je suis en contact depuis bientôt 3 semaines avec common-services, développeur de ce module partenaire vendu sur add-ons et donc ayant passé les "tests de validité". Mais visiblement pas testé avec Paypal.

A ce jour, aucune avancée.

Colissimo webservices fonctionne si on utilise pas Paypal

Paypal fonctionne si on utilise pas Colissimo webservices

Le problème semble être la triangulation Presta - Paypal - Colissimo webservices.

D'autres dans le même cas ?

Comment faire avancer les choses, vu que 202 e-commerce et common-services ne semblent vraiment pas se préoccuper du souci ?

Merci

ma version de Presta : 1.6.0.9

Edited September 4, 2016 by ChDUP (see edit history)

BrunoJWest · September 1, 2016

Bonjour,
les commandes ne remontent pas du tout, ou elles remontent, mais sans validation ? (j'essaie de rapprocher de mes soucis depuis ma mise à jour en 1.6.1.6)

ChDUP · September 1, 2016

elles ne remontent pas du tout.

ydkjphilly · September 3, 2016

Je suis pas sur que cela t'avance beaucoup, mais sur notre boutique (PS 1.6.1.4), nous avons Paypal 3.10.10 + Colissimo WS 3.1.06 et nous ne rencontrons pas ce problème. Tu as essayé avec une autre version de PS en local ?

ChDUP · September 4, 2016

Etes-vous bien en Integral Evolution ?

(je vais modifier mon titre d'ailleurs)

simuler la remontée Paypal en local, ça va être difficile.

Et puis je ne peux pas me créer un compte sandbox Integral Evolution, donc les conditions seront différentes.

edit : ah ben je ne peux pas modifier, titre trop long !

Edited September 4, 2016 by ChDUP (see edit history)

ydkjphilly · September 4, 2016

Arf, nop désolé, on est en Intégral classique.

ChDUP · September 5, 2016

202 e-commerce ne répond bien entendu pas à mes mails.

Prestashop non plus

et common-services patauge.

common-services · September 8, 2016

Bonjour ChDUP,

Nous ne pataugeons pas, il s'agit d'un problème de conflit entre deux modules et donc d'intégration. Cela rend ce cas de support plus pénible qu'un autre, car nous devons tenir compte d'un autre module que nous n'avons pas développé.

Toutefois, notez qu'à ce jour le ticket est ouvert chez nous et que nous nous en occupons activement, je comprends bien que la notion de temps soit un problème, mais nous ne la maîtrisons pas car elle dépend des délais de réponse des autres intervenants, délais de réponse que vous connaissez.

J'espère que vous pourrez revenir ici dans quelque jours indiquer que le problème est résolu, cela nous ferait plaisir à nous aussi, soyez en certain.

Cordialement,

Olivier

ChDUP · September 8, 2016

Bonjour Olivier

oui le ticket est ouvert chez vous depuis le 18/08.

Et c'est le 2/09 seulement que vous avez commencé à entrer en contact avec 202 e-commerce à ma demande.

Alors oui, tout le monde connait ~~le peu~~ l'absence de réactivité de cette agence, raison de plus pour laquelle vous auriez du vous mettre en relation avec eux au plus tôt.

Alexandre fait ce qu'il peut mais à ce jour, aucune procédure de test de commande Paypal n'a pu être mise en place sur le serveur preprod à disposition.
(J'ai d'ailleurs appris qu'avant cela, common services n'avait pas de compte sandbox Paypal ?)

Pour solutionner un souci, il faut déjà réussir à le reproduire.

Donc oui, common-services patauge.

Vous parlez d'un problème de délais de réponses des intervenants ?

Si vous souhaitez le réduire, ma demande Skype est en attente sur votre compte et celui d'Alexandre depuis le 22/08.

Je ne manquerai pas de marquer comme résolu ce topic et également de citer les personnes qui se seront bougées pour sa résolution ne vous inquiétez pas.

cedced · September 20, 2016

Bonjour,

Nous avons eu l'occasion de converser sur mon propre topic. De notre côté nous étions en contact avec 202-ecommerce et Paypal. Paypal a rapidement trouvé que le problème venait du fichier ipn.php du module de 202-ecommerce et eux ont mis 4 mois à trouver que le problème venait du module de Common Service (peut-être grace à vous et CS). Je n'ai pas été en contact avec CS, mais mon expérience avec 202-ecommerce a été assez incroyable. En bref, ça a duré 4 mois comme je l'ai dit. Une chose qui a semblé accélérer un peu les choses, c'est d'avoir poussé un peu une gueulante sur leur page Facebook. Si ça peut aider... En tout cas bonne chance.

Je confirme que nous avons eu le même problème sur Presta 1.6.1.5 avec un Paypal Integral Evolution. Et à ce jour, nous n'utilisons plus pour le moment le module Colissimo WebServices (So flexibilité).

Mais à ce que j'ai pu donc lire ici, si on est en Integral normal, il n'y a pas de problème?

ChDUP · September 21, 2016

Oui le probleme ne se produit qu'avec Intégral Évolution.

A ce jour, et plus d'un mois apres avoir remonté le probleme, je n'ai eu absolument aucune reponse de la part de 202.

Je n'en suis pas étonné mais ce qui est révoltant, c'est que Prestashop continue de travailler avec ces personnes...

On se doute des intérêts qu'il y a derrière, dans lesquels la satisfaction de l'utilisateur presta n'entre absolument pas en considération...

Pour ce qui est de Commonservices, Alexandre me tient au courant de temps en temps, mais uniquement pour me dire que rien n'avance.

Et Prestashop ? Bien trop occupé à négocier avec ses pseudo-agences "partenaires" pour prêter attention aux problèmes de ses véritables clients.

Bref, si certains lecteurs de ce post se posent encore des questions sur le choix de leur CMS e-commerce, fuyez !

202ecommerce · September 23, 2016

Bonjour Laurent,

Pas de trace de demande de votre part dans notre outil de ticketing, à quel email avez-vous envoyé un message ?

Le support Paypal est joignable sur support-paypal chez 202-ecommerce.com

Merci,

ChDUP · September 23, 2016

Bonjour

Donc vous m'annoncez que vous n'avez même pas encore commencé à travailler là dessus ?

J'ai joint par téléphone puis par mail M. Paul Tosend chez vous le 1er septembre. Sa reponse par mail indique noir sur blanc qu'il a transféré la demande au support technique.

Et les mails d'Alexandre de Commonservices, vous allez me dire que vous ne les avez pas reçus ?

Et ceux de Yousri Benghorbal de Prestashop addons non plus ?

Ça vous sert à quoi de chercher des excuses bidons? Vous voulez gagner du temps pour quoi ? Faites votre boulot et tout le monde sera content.

202ecommerce · September 27, 2016

Bonjour @ChDUP,
je reviens vers vous concernant votre demande, la demande est bien en cours chez nous.

Nous avons ouvert un incident chez nous depuis le mail direct de Yousri qui nous à été envoyé jeudi.

Par ailleurs, je viens de vous contacter afin d'avoir des accès au FTP et BO, car nous n'arrivons pas à reproduire sur nos environnements.

Ps : mon collègue qui vous a répondu précédemment ne savait pas que la demande était déjà en cours.

Keith - 202 ecommerce

Stéphane Cataldi · September 28, 2016

Bonjour,

Je ne sais pas si ça peut aider mais j'ai eu un problème similaire quand je suis passé en 1.6. Les commandes paypal ne remontaient plus dans le BO. Après investigation, je me suis rendu compte qu'un module avait installé un override pour la fonction de création de commandes, qui n'était pas compatible avec la 1.6, ce qui entrainait un problème lors de la création de la commande dans le BO au retour de paypal. Regardez, par rapport à une clean install, si vous n'avez pas de fichiers ajoutés dans le répertoire override. Et si oui, vérifiez ce qu'il fait et d'où il vient.

ChDUP · September 28, 2016

Merci Stephane mais le souci ne vient pas de ça.

Le probleme a été reproduit sur une install vierge.

common-services · September 29, 2016

Bonjour M. ChDUP,

Vous indiquez dans votre signature que vous ne répondez pas au MP non sollicités ; vous indiquez dans ce topic que vous déplorez que nous ne répondons pas à vos invitations Skype ; il en est de même ; nous n'avons jamais assuré de support par Skype, donc votre remarque m'interpelle.

Le problème rencontré est très précis, nous sommes dans un soucis d'intégration de deux modules de deux agences réputées et uniquement dans un mode de fonctionnement bien précis.

Vous avez remonté le problème au niveau national à la direction de Coliposte, chez Prestashop, chez 202 Commerce et chez nous. Ce ne sont pas vos interventions qui ont accéléré l'investigation, bien au contraire, au plus les sujets sont diffusés, au plus il y a d'interlocuteurs au plus il y a de confusions et au plus cela prend de temps !

Finalement, Alexandre a installé le module Paypal sur un Prestashop cloud neuf et le problème était le même, donc le problème ne venait pas de chez nous. Cependant, peut importe, nous n'abandonnons jamais un cas de support, car un cas se reproduit toujours, au moins, une fois.

Nous avons pour habitude de collaborer avec les agences quand il y a des problèmes d'incompatibilité, quand bien même ce ne soit pas une prescription de Prestashop.

Vous devriez avoir sous peu des nouvelles de 202 Commerce qui a réagit très professionnellement de mon point de vue, ou de chez nous, ... et tout devrait rentrer dans l'ordre.

Malgré tout, vous me voyez vraiment désolé des tracas, des désagrément causés, du temps perdu, mais comprenez bien que ces inconvénients sont réciproques et que nous n'aimons pas non plus ni perdre du temps, de l’énergie, de l'argent... et par conséquent nous faisons toujours tout le nécessaire pour que ce genre de situation n'arrive jamais.

Cordialement,

Olivier Baquet

ChDUP · October 1, 2016

Bonjour Olivier

Vous indiquez dans votre signature que vous ne répondez pas au MP non sollicités ; vous indiquez dans ce topic que vous déplorez que nous ne répondons pas à vos invitations Skype ; il en est de même ; nous n'avons jamais assuré de support par Skype, donc votre remarque m'interpelle.

Aucun rapport puisque j'utilise bien les MPs.

La signature est là pour réduire les demandes d'aide que je reçois directement par MP. Alors que le principe d'un forum est de partager les infos.
De votre côté, vous n'utilisez pas Skype. C'est votre choix, pas de problème.
Je répondais simplement à votre première remarque sur "les délais de réponse des différents intervenants" et je proposais cette solution pour les réduire.

Vous avez remonté le problème au niveau national à la direction de Coliposte, chez Prestashop, chez 202 Commerce et chez nous. Ce ne sont pas vos interventions qui ont accéléré l'investigation, bien au contraire, au plus les sujets sont diffusés, au plus il y a d'interlocuteurs au plus il y a de confusions et au plus cela prend de temps !

Oui j'ai effectivement brassé tout ce que j'ai pu.

Selon vos propos, c'est donc à cause de moi que 6 semaines plus tard, rien n'est résolu ?

Et qu'aurais-je du faire ?

En tant qu'utilisateur lambda de Presta, j'ai un problème qui survient suite à l'installation d'un module de l'agence commonservices et que je n'avais pas auparavant.

J'aurai donc du uniquement vous contacter, et personne d'autre, et aujourd'hui tout serait rentré dans l'ordre ?

common-services · October 3, 2016

Bonjour M. ChDUP,

Je dis simplement que nous nous sommes retrouvés dans une situations compliquée avec énormément d'intervenants donc le délai de résolution fût proportionnel quand bien même il soit anormal.

Le plus important est que le problème ait été géré par toutes les parties et donc je tiens à vous remercier pour votre patience et à remercier nos confrères aussi.

Cordialement,

Olivier

ChDUP · October 3, 2016

Bonjour Olivier

à vous lire, on dirait que le problème est réglé ?

romain_kasdesign · October 3, 2016

Bonjour,

Je suis dans le même cas que vous et attends la correction du conflit entre les 2 modules avec impatience.

Si vous avez des nouvelles n’hésitez pas à nous les communiquer, j'en ferai de même de mon coté.

Cdl

common-services · October 6, 2016

Bonjour Messieurs,

Bonjour Olivier

à vous lire, on dirait que le problème est réglé ?

Bien c'est ce que me répond Thoma de chez 202-ecommerce.

Bonjour,

Je suis dans le même cas que vous et attends la correction du conflit entre les 2 modules avec impatience.

Si vous avez des nouvelles n’hésitez pas à nous les communiquer, j'en ferai de même de mon coté.

Cdl

Je le signale à 202-ecommerce et l'URL de ce topic nous allons ainsi faire la lumière sur le sujet.

Cordialement

ChDUP · October 6, 2016

j'ai eu hier au telephone une personne de chez 202

Apparemment, Alexandre s'est embrouillé en confondant avec un problème d'une autre personne. (d'après eux)

On dirait que 202 prend connaissance hier seulement de mon veritable probleme.

Toujours est-il qu'à ce jour, j'en suis toujours au même point.

common-services · October 6, 2016

Bonjour ChDup,

Le problème c'est qu'ici on a votre pseudo et que sur notre helpdesk nous avons un numéro de ticket, un nom, un numéro de commande !

Comprenez bien que les forums avec des pseudonymes ne sont pas le meilleur moyen pour nous tous pour régler les problèmes.

Prestashop, 202-ecommerce et nous même mettons toute notre meilleure volonté pour le résoudre, mais si il y a eu un problème sur l’identité de la personne vous ne pouvez pas nous blâmer !

Cordialement

ChDUP · October 6, 2016

Je ne blâme personne, c'est vous qui répondez à ce topic en disant que selon 202, mon problème est résolu.

Donc je vous répond ce qu'il en est réellement.

Dans tous les cas, mon ticket ouvert chez vous depuis le 18 aout n'est toujours pas résolu.

BM Services · October 10, 2016

Bonjour,

juste pour vous informer que nous rencontrons le même problème avec le module de paiement Paybox. Le contexte saute lors de la validation de commande via un appel IPN (appel à $this->context->cart->getDeliveryOptionList() dans le ValidateOrder de la classe PaymentModule) et l'id_cart est perdu entraînant des montants à 0, un statut en Erreur de paiement...

Le problème se pose même si un autre transporteur est sélectionné pour la commande. Par contre, aucun souci avec les modules de paiement Chèque et Virement où tout se passe dans des FrontController avec un client loggué.

Cordialement,

Equipe Support BM Services

ChDUP · October 11, 2016

Attention à ne pas ramener toutes les erreurs à la même cause.

En fait Paypal Integral Evolution, tout comme Paybox probablement font une verification de la commande au moment du retour. (il vérifie le montant de la commande et du panier associé notamment pour que ces montants n'aient pas été changés entre temps et éviter des fraudes)

Ce que ne font pas les modules de paiement cheque et virement (et systempay apparemment)

Colissimo webservices interroge les serveur Colissimo afin de créer la commande avec les bonnes infos de livraison.

Suivant les délais de réponse, cela peut prendre plus ou moins de temps.

Si Paypal fait son retour alors que nous n'avons pas encore le retour de Colissimo, alors la commande ne peut être créée.

Il semblerait donc qu'il suffirait de faire une boucle en début de submit.php de Paypal afin de verifier la presence de l'id_order avant de sortir de la boucle et ça solutionnerait le soouci.

common-services · October 14, 2016

Bonjour ChDup,

Dans tous les cas, mon ticket ouvert chez vous depuis le 18 aout n'est toujours pas résolu.

Ce n'est pas faute d'avoir fait tous les efforts, nous avons contacté Prestashop qui nous a mis en contact avec le chef de projet chez 202-ecommerce qui nous indique qu'il sont en cours d'analyse.

Le problème ne semble pas venir de chez nous puisque nous avons reproduit exactement le même problème sur un Prestashop Cloud sans que notre module soit installé.

Nous nous efforçons simplement de vous être le plus utile possible afin que votre problème soit résolu le plus rapidement possible, toutefois je ne peux pas vous indiquer de délai puisque, encore une fois, cela ne concerne pas directement notre module.

D'ailleurs, à ce titre, si vous pouviez éditer le titre de votre sujet ce serait fort sympathique car cela nous fait erronément une mauvaise publicité.

Merci d'avance,

Cordialement,

Olivier

ChDUP · October 14, 2016

Bonjour Olivier

Le problème ne vient ni de chez vous, ni de chez eux, c'est bien une incompatibilité entre les 2, d'où le titre de ce topic.

Le souci est apparu le jour où j'ai installé votre module, donc même si ça ne signifie pas obligatoirement qu'il vient du module, le lien ne peut être nié.

En fait, la réponse du webservices pouvant être longue et variable suivant l'accessibilité du serveur colissimo, le module Paypal s'execute avant cette reception.

La solution pour l'instant est d'ajouter un sleep(10) à l'execution du submit.php Paypal mais ça n'est pas vraiment satisfaisant.

Le problème ne semble pas venir de chez nous puisque nous avons reproduit exactement le même problème sur un Prestashop Cloud sans que notre module soit installé.

Exactement le même problème ?

Si il n'a pas identifié la cause ni de l'un ni de l'autre, je vois mal comment affirmer qu'il s'agisse du même problème.

Si il peut m'envoyer l'adresse de ce presta, j'aimerai bien tester.

common-services · October 14, 2016

Bonjour,

Si il peut m'envoyer l'adresse de ce presta, j'aimerai bien tester.

Oui, Alexandre le tient à votre disposition et vous avez les coordonnées d'Alexandre.

Cordialement,

Olivier

Jal-art · October 19, 2016

Hello la communauté

J'ai le même problème de remonter des commandes payées par PayPal, mais pas toutes.

Je suis sous PayPal Intégral évolution et j'utilise également le module SoColissimo Webservice.

Par contre, je ne saurais dire s'il s'agit d'un problème d'incompatibilité, d'ailleurs je follow un autre topic à ce sujet :
https://www.prestashop.com/forums/topic/547204-paypal-les-paniers-ne-passent-pas-en-commande/

Bien cordialement

ChDUP · October 20, 2016

Perso, aucune commande ne remontait.

Mais j'ai vite coupé Paypal, donc peut être que certaines seraient remontées, impossible à dire.

Si certaines passent et d'autres pas, ça peut eventuellement être lié à ce "délai" que j'expliquais plus haut.

Quand le serveur Colissimo n'est pas trop chargé et répond assez vite, peut être que les remontées sont ok et dans ce cas votre problème a peut être la même cause que le mien.

De toute façon, toutes les configs avec Paypal Integral Evolution et Colissimo webservices sont potentiellement touchées.

romain_kasdesign · October 20, 2016

Bonjour,

Encore merci @ChDUP pour les différents retours et le suivi du problème.

Pour revenir sur votre solution du sleep(10) si je comprends bien, il faut mettre l'attente avant la ligne 70 [$id_cart = Tools::getValue('id_cart');] du fichier submit.php dans le répertoire "paypal\integral_evolution"

et mettre un code du style :

$id_order = Tools::getValue('id_order');
$time = 0;
while (!$id_order && $time < 10)
{
	sleep(1);
	$id_order = Tools::getValue('id_order');
	$time++;
}

ChDUP · October 20, 2016

la solution "crade" que j'ai actuellement est de mettre un sleep(10); tout en haut de ce fichier avant les include_once

La solution plus propre serait effectivement de faire une boucle while, mais dans celle-ci vous devez toutes les secondes allez verifier si vous avez en base de donnée un id_order qui correspond à l'id_cart récupéré par Tools::getValue('id_order')

et sortir de la boucle dès qu'il est existant.

Ca permettra de n'attendre que le temps qu'il faut, et pas systematiquement 10 secondes.

romain_kasdesign · October 25, 2016

Bonjour,

J'ai modifié mon code car il ne marchait pas. Ce que j'ai fait c'est de rendre la fonction 'hookActionValidateOrder' atomique.

En faite je dis au fichier submit.php d'attendre que la fonction soit entièrement finie.

au tout début du fichier submit.php :

if(isset($_SESSION) && isset($_SESSION['socolissimoflexi_on']) && $_SESSION['socolissimoflexi_on'])
{
	$t = 0;
	while ($_SESSION['socolissimoflexi_on'] && $t < 100)
	{
		$t++;
		sleep(1);
	}
}

Dans ma fonction hookActionValidateOrder :

public function hookActionValidateOrder($params)
{
// debut de la fonction 
$_SESSION['socolissimoflexi_on'] = true;

// !!!! avant chaque return ce trouvant dans la fonction (il y en a 5)
$_SESSION['socolissimoflexi_on'] = false;


// a la fin de la fonction
$_SESSION['socolissimoflexi_on'] = false;
}

au début du fichier soflexibilite.php :

if(!isset($_SESSION))
{
  session_start();
}

En faite la fonction hookActionValidateOrder du module soflexibilité à un traitement super long (à comparer du module de mondial relais qui a une seule fonction).

common-services · November 17, 2016

Bonjour ChDUP,

la solution "crade" que j'ai actuellement est de mettre un sleep(10); tout en haut de ce fichier avant les include_once

Oui ce n'est pas une solution. Par contre Alexandre a identifié et corrigé un problème d'inclusion multiple de fichier init.php qui pourrait être à l'origine du problème.

Et il semble que ce ne soit pas lié à notre module en particulier ; mais à tous les modules qui interagissent avec Paypal évolution qui inclue ce fichier aussi et par conséquent parce-que il l'inclue !

Je vous conseille donc de rentrer en contact avec lui pour qu'il vous fournisse la mise à jour.

Cordialement

ChDUP · November 17, 2016

Oui il m'en a parlé et m'a envoyé la dernière version.

J'hésite tout de même à retirer mon sleep (sans jeu de mot :-) foireux)

Jal-art · December 25, 2016

Salut à tous,

Je continue la conversation sur un sujet qui n'est pas liée au problème d'enregistrement des commandes, réglé depuis la MAJ mais avec un autre problème d'incompatibilité des deux modules.

Lorsqu'un client sélectionne Colissimo Point Retrait ou Colissimo Bureau de Poste, l'adresse de livraison sur PayPal (et non sur Presta) correspond à l'adresse de facturation. Ce qui n'est pas conforme avec la politique de protection des marchands sur PayPal.

Une commande frauduleuse livrée dans un Point Retrait (ce qui est très souvent le cas) n'est pas protégée par PayPal.

J'ai un ami qui a le même problème que moi, donc je pense que cela vient d'un des deux modules.