De temps en temps, un client obtiendra une erreur lors de la tentative de soumission d'une commande indiquant PayPal Gateway a rejeté la demande. La transaction a été refusée à la suite d'un identifiant de facture en double fourni. après avoir creusé cela un peu, je crois que j'ai réduit le problème. Dans les cas les plus récents, un client avait tenté de passer une commande il y a 4 mois et a reçu une erreur interne Avance rapide à aujourd'hui ... Même client, nouvelle commande. Magento a toujours eu l'ancienne citation de septembre dans la table Je vois dans la classe MAGE_SALES_MODEL_OBSERVER qu'il existe une méthode CleanExpiredQuotes appelée d'un travail cron. Cependant, ces seules effets citations avec "is_actif" = 0. Comme cette citation est considérée comme active, elle n'a jamais été effacée.
Si clairement, il y a une déconnexion entre le code Magento et PayPal. Mais c'est à peu près aussi loin que j'ai eu avec ça. Quelqu'un d'autre a-t-il vécu cela? Si oui, toute suggestion?
Je suis un peu plus loin avec ça. J'ai ajouté du code à l'indextrexController de paiement pour attraper l'erreur et, s'il s'agit d'une erreur de facturation en double, il désintègre le réservé_order_id dans la citation A appelle à nouveau à nouveau. Cela entraîne la citation de réserver un nouvel identifiant de commande, qu'il soumet ensuite à PayPal. Le problème que j'ai maintenant, c'est que lorsqu'il essaie la deuxième fois avec le nouveau numéro de facture, tous les totaux sont 0. J'ai essayé de définir la définition des totaux Évidemment, après la première tentative, quelque chose désintoge toutes les valeurs, mais je ne sais pas quoi ou où. Si quelqu'un a des idées, j'aimerais les entendre! sale_flat_quote . Lorsqu'ils sont connectés, il a chargé la citation du client (qui était toujours active) et a tenté de l'utiliser pour cette commande. Cela a abouti à la EDIT:
CollectTotaux () de la citation.
5 Réponses :
Je ne l'ai pas encore fait, mais semble être installé sur cette Extension de FOOMAN serait potentiellement corriger les citations à l'aide de la mauvaise commande #. Est-ce que cela fonctionne pour vous? J'adore entendre de toute façon. Je suis prêt à s'attaquer à cela et à faire de nos exceptions de PayPal plus lisibles (en utilisant certaines des explications de PayPal de ici . Donc, si vous trouvez cela aide, j'aimerais savoir. EDIT:
Trouvé quelques informations supplémentaires ici . Apparemment, l'extension de Fooman aide, mais ne résout pas les problèmes complètement. Cela aide-t-il à résoudre votre problème? EDIT:
Par peut-il confirmer que la mise à niveau de la mise à niveau Magento 1.7 corrige effectivement le problème? Chaque fois que je l'ai examiné, cela semble être un problème de Paypal Express (nos paiements passent normalement par PayPal Pro et cela ne semble pas avoir des erreurs).
Non, nous avons déjà eu l'extension de FOOMAN et cela n'a pas aidé. Je suis à 99% sûr que le problème est causé par ce qui suit ... Lorsqu'un client tente une commande et qu'il échoue, PP considère que la facture # comme déjà utilisé pendant que Magento ne le fait pas. La prochaine fois que le client tente une commande, Magento trouve l'ancien enregistrement dans la table de devis et tente de l'utiliser. PP renvoie l'erreur DUP, que Magento ignore et continue d'utiliser le même numéro. Je l'ai "corrigé" en incrémentant le nombre si je reçois l'erreur du DUP, mais cela ne répond pas à la cause de la racine, alors les clients voient toujours au moins une erreur.
Si vous trouvez de bonnes informations ou une vraie solution pour cela, veuillez le poster ici car c'est toujours un problème pour nous.
Brian, vient de découvrir que Magento 1.7 peut avoir la solution (voir mon édition). Avez-vous essayé encore de la mettre à niveau?
Merci, Acorncom, c'est de superbes infos! Je n'ai pas encore essayé de mettre à niveau, et ce n'est probablement pas dans les cartes à tout moment. Mise à niveau Magento peut être un cauchemar. L'a déjà fait une fois de 1,4.2.0 à 1.5.0.1. Je n'attends pas avec impatience une autre mise à niveau à tout moment. Avez-vous confirmé que cela corrige effectivement le problème? Si oui, j'aimerais savoir ce qu'ils ont changé et peut-être appliquer cela au code 1.5.0.1.
Ce problème n'est pas fixé en 1.7.
@Corncom vient de recevoir une solution de travail - je suppose que je le posterai même si op est probablement depuis longtemps!
Cela se produit dans Magento 1.9.1.0 aussi.
Cela ne résoudra pas le problème si vous avez plusieurs installations Magento pointées sur un seul compte PayPal.
C'est un peu risqué pour pouvoir les permettre, mais je suppose que ma solution fait fondamentalement la même chose. Merci d'avoir posté ça! Je ne connaissais pas ce réglage, je vais garder cela à l'esprit.
Je ne sais pas pourquoi cela pourrait être risqué. Pourriez-vous expliquer? IMHO, il est risqué de laisser un client bloqué par un message d'erreur sans possibilité d'utiliser le site et d'acheter des produits.
Cela me semble risqué de ne pas avoir ce chèque en place afin qu'un client ne puisse pas payer pour une facture deux fois. Mais, comme je l'ai dit, mon "correction" fait essentiellement la même chose, bien qu'il connecte le fait qu'il a eu l'erreur dupliquée afin que je puisse revenir en arrière et suivre tous les paiements en double. Je conviens que permettant à un client de faire un achat est de la plus haute importance, mais les ennemis avec des frais en double n'aident pas non plus.
Eh bien, je comprends votre préoccupation. Mais avez-vous eu un cas de paiement en double? Je pense que c'est surtout une fausse alarme. Peut-être que la meilleure chose à faire est de signaler ce bogue à Magento (et peut-être à PayPal aussi).
Je pense que cela peut être un changement nécessaire lorsque vous avez plusieurs installations magento toutes pointées vers le même compte PayPal. Je viens de déployer une nouvelle installation de Magento et j'ai reçu l'erreur du nouveau magasin. Je suppose que l'un des identifiants de facture précoce sur la nouvelle installation a chevauché avec un identifiant de facture précoce de l'une de mes installations existantes ... à moins que vous n'ayez quelque chose qui conserve des identifiants de facturation uniques sur plusieurs installations de magentas, je ne sais pas comment vous D Évitez ce problème.
Quel essentiel ce qui se passe est que Magento envoie à PayPal un ordre de commande (numéro de facturation) qui a déjà été payé dans le système. Cela provoque PayPal de retourner une réponse indiquant que ce numéro de facture est un duplicata. Donc, ce que je fais ici, c'est essayer de détecter cette réponse du message, générer une nouvelle commande et resoumettre à PayPal pour le retraitement.
Voici l'action qui commence toute la chaîne d'informations d'envoi à Magento. Il est situé à 'mage_paypal_controller_express_abstract'. J'ai modifié le «jeton» généré par la réponse PayPal. Ce jeton contiendra des informations sur l'erreur survenue. P> à: p> Ce jeton est généré par le début () Méthode dans 'mage_paypal_model_express_checkout'. Démarrer () gère également l'ensemble du processus de manipulation d'objet. Ici, nous modifierons de manière conditionnellement la production. P> La fonction modifiée ressemblera à ceci: p> maintenant, la partie finale gère l'appel PayPal et réponse. Ceci est fait avec la fonction Call () situé à 'mage_paypal_model_api_nvp'. P> Une fois la réponse générée, nous vérifierons la réponse d'erreur et, au lieu de rediriger, nous le retournerons simplement la chaîne. situé autour de la ligne 997: p> de sorte qu'il va comme ça: p> s'il y a Une erreur d'entrée en double, cela fera cela. P> startaction()->start()->call(error)->start()->call()->start()->staraction()->redirect();
Merci pour cela en réponse en profondeur. Superficiellement, cela a l'air bien, bien que je n'ai pas le moyen de le tester facilement. J'ai récemment mis à niveau à 1.9 et eut toujours ce problème, alors ce que j'ai fini par faire était de modifier la fonction de chargement dans le contrôleur de paiement pour se rappeler si cette erreur est déclenchée. Juste avant que je déteste l'ID de commande réservé et que vous repartiez un, qui incrémente le nombre. Cela ressemble beaucoup à votre solution, juste dans le contrôleur au lieu du code PP. Le tien est probablement plus élégant;). Merci d'avoir posté! J'y ai accepté cette réponse depuis que c'est fondamentalement ce que j'ai fait.
La solution présentée est Seulement de contournement pour le problème sous-jacent qui est que le Il n'y a rien de mal avec le code Magento, c'est la Base de données dans un état problématique. Cela se produit généralement après une mise à jour de Magento. Pour résoudre le problème, il vous suffit de définir votre facture update Comme indiqué par d'autres, il est normal que ces identifiants ne soient pas en synchronisation, mais si l'identifiant de facture est trop derrière l'identifiant de la commande (et non l'inverse autour) Les problèmes liés à PayPal peuvent se produire (plus d'informations ici ).
Avant de faire tomber cette solution, essayez-le, cela fonctionnait parfaitement pour moi et d'autres. Comment corriger: Utilisez votre outil de gestion de DB préféré ( phpmyadmin , Administrateur , ...) Allez dans la table Les valeurs intéressantes sont: Donc, la seule chose que nous devons faire ici est de définir la valeur de facture sur l'une de la valeur de la commande. Nous pouvons le faire avec n'importe quel outil de gestion de DB, ou directement avec la commande SQL si vous avez plusieurs magasins, vous devez modifier le magasin_id. Cette réponse est basée sur les informations de Cet article . incrément_last_id pour les factures est À la traîne derrière le incrément_last_id pour les commandes. incrément_last_id sur la même valeur que la commande. EAV_ENTITY_STORE et vérifiez les valeurs. Ça devrait regarder qc. Comme ceci:
Je pense qu'il est tout à fait normal que order_id et invoice_id ne sont pas synchronisés.
Oui, mais un problème avec PayPal peut se produire lorsque l'ID de facturation est derrière l'ID de commande. Plus d'informations ici: Magestricks.com/tricks/...
Je pense que cela peut être un changement nécessaire lorsque vous avez plusieurs installations de magentas, tous ont pointé vers le même compte PayPal. Je viens de déployer une nouvelle installation de Magento et j'ai reçu l'erreur du nouveau magasin. Je suppose que l'un des identifiants de facture précoce sur la nouvelle installation a chevauché avec un identifiant de facture précoce de l'une de mes installations existantes ...
une option Comme mentionné par @george ici consiste à modifier vos paramètres PayPal, qui vous permettront d'exécuter dès que possible. . Cela ouvre la porte pour certains risques cependant. Ce qui est probablement mieux consiste à installer un plugin tel que préfixe de commande personnalisée Sur toutes vos installations Magento. De cette façon, chaque installation passera à la facture ID avec un préfixe différent malgré les identifiants de facture se chevauchant.
Grande question. J'ai rencontré cela moi-même. Quelle version de magento utilisez-vous? J'ai vu cela avec Magento 1.4 et 1.5 (la version utilisée actuellement).
Nous sommes sur 1.5.1.0, mais je vais probablement nous améliorer dans un mois ou deux. Postera si j'arrête de voir cela arriver.
@Brianvps avez-vous résolu cela?
Comme je l'ai indiqué dans votre réponse, je suis venu avec un travail, mais j'aime votre réponse. En fin de compte, cela fonctionne maintenant, je suis juste surpris que je devais faire de tels changements.
rakeshjesadiya.com/error-10412-paypal-duplicate-invoice-php résoudre l'erreur par étape donnée dans le lien