Adresse e-mail manquante dans l'ordre

10

Nous avons 2 magasins (une mise à niveau 1.7.0.2 à partir de 1.5.1 et une installation 1.6) qui ont tous deux un problème qui, pour certaines commandes, a une adresse e-mail manquante (customer_email dans sales_flat_order) . Les magasins sont deux installations complètement différentes et la seule chose que j'ai trouvée identique dans les deux versions est qu'elles utilisent toutes les deux OneStepCheckout (dernière version) et que le problème n'est visible que pour les clients (mais pas tous) qui ont déjà un compte client . Je suppose que le problème est dans le compte client, mais je ne trouve rien d'étrange avec ces comptes.

Des idées sur où vérifier ou comment déboguer ce problème?

Merci.

orders ce-1.7.0.2 upgrade

— Vladimir Kerkhoff
source

Le mode de paiement de la commande est-il Paypal, par hasard?

— philwinkle

Non, c'est avec différentes méthodes de paiement

— Vladimir Kerkhoff

des personnalisations (sauf OneStepCheckout) qui interagissent avec les commandes ou le compte client?

— FlorinelChis

J'ai le même problème. Je suis sur OSC 4.0.9 (supérieur à la version avec le correctif). J'ai également installé un nouveau Magento 1.7.0.2 et passé deux commandes avec le même e-mail: d'abord en tant que client, puis en deuxième (en mode Incognito - pas de cookies) en tant qu'invité. Les deux avaient une adresse e-mail. Je ne sais toujours pas quelle est la cause.

— Aaron Pollock

3

Assurez-vous que vous exécutez OSC 4.0.7.

Nous avons eu ce problème en utilisant Magento 1.7.0.2 et OSC 4.0.6. Il s'est avéré être un bogue dans OneStepCheckout où il ne gérait pas correctement les utilisateurs reconnus par le panier d'achat persistant. Nous avons communiqué cela à OSC et ils nous ont donné un correctif (mais je pense que cela a été corrigé dans 4.0.7: http://www.onestepcheckout.com/wiki/index.php/Changelogs#OneStepCheckout_4.0.7_changes

Grep pour $this->getQuote()->setCustomerId(0);dans app \ code \ local \ Idev \ OneStepCheckout \ Block \ Checkout.php (devrait donner 5 correspondances), car il s'agissait essentiellement du correctif.

Edit: cela aurait dû être un commentaire .. pas vraiment une réponse.

— Erfan
source

7

REMARQUE: Ce n'est pas une réponse en soi, mais je voulais ajouter mes propres expériences avec ce problème où je peux le formater plus facilement.

J'ai vu le même problème. C'est quelque chose que je n'ai pas eu l'occasion d'approfondir, mais d'après ce que j'ai vu, c'est une combinaison des facteurs suivants:

Un client enregistré.
Panier persistant.

Si un client s'est déjà inscrit sur le site, mais n'est pas connecté et que le panier persistant est activé (ou bien le cookie est présent pour le client après la désactivation du panier persistant), le problème semble se produire.

Je n'ai pas vu cela se produire avec des clients qui ne se sont pas enregistrés, mais je me demande si cela a quelque chose à voir avec un compte d'ordinateur partagé et deux clients différents, l'un qui s'est inscrit et l'autre qui ne l'a pas fait.

Je vais continuer à enquêter également, nous lions automatiquement un client à un groupe de clients, ce problème signifie que la commande n'est pas affectée à un groupe de clients.

Edit: nous utilisons Firecheckout, pas OSC

— CCBlackburn
source

Je peux confirmer que cela se produit également, dans un magasin sans OSC, un client enregistré vérifiant en tant qu'invité a fait exactement cela.

— benz001

0

Nous utilisons également OSC et ce problème se produit sur notre site. Je pense que cela se produit dans les extensions de paiement non essentielles. Dans le cœur de Magento, si vous activez le panier persistant, les clients invités sont obligés de s'inscrire ou de se connecter, donc l'adresse e-mail existera toujours. Plusieurs extensions de paiement (comme OSC) n'appliquent pas cette restriction, vous entrez donc dans un scénario auquel le code principal ne s'attend pas.

— clonétopie
source